T 1806/20 (Rain-sensitive parcels/IVECO) 17-11-2023
Download and more information:
SYSTEM FOR MANAGING A VEHICULAR MISSION OF A GOODS DELIVERY VEHICLE
Inventive step - delaying the delivery of rain-sensitive parcels until it stops raining (no
Inventive step - not technical)
Decision T 1194/97 established at point 3.3 of the reasons that data was functional if its loss impaired the technical operation of a system in which it was used.
...It is self-evident that if a piece, either technical or non-technical, of any invention is taken out, it would not work as designed. In the Board's view, what T 1194/97 is saying is rather that the loss of functional data would make the system inoperable at the technical level. In contrast, if cognitive data is lost, the system would still work but possibly produce results that would be unintended for non-technical reasons.
(See point 3.8 of the reasons)
I. This is an appeal against the decision of the examining division to refuse European patent application No. 15741333.7 for lack of inventive step.
II. The examining division held that the main, first and second auxiliary request then on file lacked an inventive step (Article 56 EPC) over a conventional general purpose networked computer system. The decision also mentioned that technical means disclosed in the application were known from documents D1 (US 2009/0192702 A1), D2 (US 8,588,821 B1), D3 (US 2004/0054468 A1), D4 (US 2008/0167937 A1) and D5 ("Assessing the Need for Storing Data on Radio Frequency Identification (RFID) Tags", E. Ergen & G. Guven, published in 2009).
III. In the statement setting out the grounds of appeal, the appellant requested that the decision be set aside and a patent be granted on the basis of the refused requests, re-filed therewith.
IV. In the communication accompanying the summons to oral proceedings, the Board expressed its preliminary view that all requests lacked an inventive step over document D3.
V. By letter of 28 August 2023, the appellant filed a new third and fourth auxiliary request and provided arguments in favour of their allowability.
VI. On 13 November 2023, the appellant's representative asked the rapporteur by email to confirm that the oral proceedings would take place and provide any general comments on the case. In an email reply, the rapporteur confirmed that the oral proceedings would take place as scheduled. In addition, he stated that he could not make any case-related comments on behalf of the Board.
VII. The oral proceedings took place on 17 November 2023 by videoconference. During the oral proceedings, the Board cited document D5 as evidence of the skilled person's common general knowledge in the field of RFID tags.
At the end of the oral proceedings the appellant renumbered the requests, as follows:
- The third and fourth auxiliary requests filed with the letter of 28 August 2023 became the main and first auxiliary requests, respectively.
- The refused main, first and second auxiliary requests became the second, third and fourth auxiliary requests respectively.
The appellant's final requests were that the decision be set aside and a patent be granted on the basis of the main request or, alternatively, on the basis of one of the auxiliary requests.
VIII. Claim 1 of the main request reads:
"A system for managing a vehicular mission of a goods delivery vehicle, said goods being defined by a plurality of parcels to be delivered, the system comprising:
- a cartographic satellite navigation system adapted to drive said vehicle along a route comprising a plurality of stops corresponding to the delivery places of one or more of said parcels,
- means for calculating an interval of time needed to cover the distance between each of said stops,
- means for acquiring weather forecasts of geographical areas containing each one of said stops at least for an interval of time when the vehicle is expected to be travelling through said geographical areas,
and characterized in that it comprises:
- a respective RFID associated to each of said parcels parcel, for storing a feature of sensitivity to water and a destination place of each respective parcel;
- means for sending a warning message when rain is expected at the delivery place of a parcel sensitive to water during the time interval when the delivery of said parcel sensitive to water is expected;
- processing means at a remote server programmed to, when said rain is expected at the delivery place of the parcel sensitive to water, recalculate the vehicular route inclusive of individual stops by entering the delivery of such a parcel sensitive to water in the current mission of the same vehicle or if there is a sufficient interval of time for the following day in which rain is not expected in the delivery place."
IX. Claim 1 of the first auxiliary request deletes the alternative of the last feature that comes after "the same vehicle".
X. Claim 1 of the second auxiliary request differs from claim 1 of the main request in that the characterising portion is replaced by the following:
"it comprises means for storing a feature of sensitivity to water of one or more of said parcels and means for sending a warning message when rain is expected at the delivery place of a parcel sensitive to water during the time interval when the delivery of said parcel sensitive to water is expected and processing means programmed to assess if it is possible to reschedule the delivery in one same mission or if there is a sufficient interval of time for the following day in which rain is not expected in the delivery place, and programmed to plan the management of the daily deliveries by considering such a constraint."
XI. Claim 1 of the third auxiliary request differs from claim 1 of the second auxiliary request by the addition of the wording ", through Application Programming Interfaces which are accessible via Internet," after "means for acquiring" in the third feature.
XII. Claim 1 of the fourth auxiliary request differs from claim 1 of the second auxiliary request by:
- the double replacement of the term "system" by "method" in the opening portion and the addition of the wording "the steps of" at the end of this portion
- the deletion of the wording "a cartographic satellite navigation system adapted to" at the beginning of the first feature and addition of the wording ", by a cartographic satellite navigation system," after "drive" in this feature
- the deletion of "means for" in the second and third claim features
- the replacement of the characterising portion by
"it comprises the further steps of storing, by storing means, a feature of sensitivity to water of one or more of said parcels; sending a warning message when rain is expected at the delivery place of a parcel sensitive to water during the time interval when the delivery of said parcel sensitive to water is expected;
assessing, by processing means, if it is possible to reschedule the delivery in one same mission or if there is a sufficient interval of time for the following day in which rain is not expected in the delivery place; and planning, by said processing means, the management of the daily deliveries by considering such a constraint."
XIII. The appellant argued as follows:
The features distinguishing the invention from the closest prior art D3 had technical character.
Firstly, the prevention of damage to physical objects was a fundamental technical problem that was addressed throughout various areas of technology. Recognising that a parcel could be damaged by rain and avoiding such damage was a specific example of addressing this problem. To deny that this solution was technical in nature would be similar to arguing that protecting electrical circuits from overload damage was not technical - a clearly unsound conclusion.
Secondly, as was set out in T 2035/11 - Navigation system/BEACON NAVIGATION at points 5.2.1 and 7.4 of the reasons, the calculation of a route, along which a vehicle was guided in real-time, based on real-world conditions, in that case congestion information, was a technical task. Since water-sensitivity features of parcels and rain forecast were real-world conditions comparable to congestion information, recalculating a delivery route based thereon had technical character.
Thirdly, using a distinction made in decisions T 1194/97 - Data structure product/PHILIPS and T 424/03 - Clipboard formats I/MICROSOFT, the water-sensitivity features and rain forecast were functional data having an inherent technical character, rather than non-technical cognitive data. The former decision established at point 3.3 of the reasons that data was functional if its loss impaired the technical operation of a system in which it was used. The water-sensitivity and the rain forecast met this criterion, since their loss would make it impossible for the navigation system to recalculate the route.
Fourthly, the parcels' water-sensitivity features were of a technical nature because the server received them from RFID tags attached to the parcels.
1. Admittance
The Board admits the main and first auxiliary requests into the proceedings under Article 13(2) RPBA 2020. These requests are a bona fide attempt to overcome the objection under Article 56 EPC raised by the Board for the first time on the basis of D3. This is an exceptional circumstance in the sense of Article 13(2) RPBA 2020.
2. The invention
2.1 The invention claimed in the main request concerns a parcel delivery system that seeks to prevent damage to water-sensitive parcels by avoiding delivery to rainy destinations, see the published application, page 1, line 24 to page 2, line 9.
2.2 A delivery vehicle is equipped with a satellite navigation system, for example within a tablet (not claimed), that is connected to a remote server, see page 6, lines 18 to 24. The system calculates a route for the delivery destinations of the parcels on board and acquires weather forecasts for the areas at these destinations at the estimated arrival times (second and third claim features), see page 3, lines 16 to 20. Although not explicitly claimed, the application discloses that these steps are performed by the remote server, which provides the calculated route, the weather forecasts and each parcel's water sensitivity feature to the satellite navigation system, see page 6, line 18 to page 7, line 7.
2.3 Each parcel has an RFID tag that stores its delivery destination and a water-sensitivity feature, see page 7, lines 18 to 19 and page 8, lines 6 to 9. Although the appellant argued that the water-sensitivity features in the RFID tags were uploaded to the server (see section XIII above), this is neither claimed nor disclosed. Instead, the Board understands, in light of the application (page 7, lines 6 and 7), that the remote server stores the parcels' water-sensitivity features independently of the RFID tags and performs all processing using the internally-stored features.
2.4 The navigation system guides the driver along the received route, see page 3, lines 8 to 11. If rain is expected at a delivery destination for a water-sensitive parcel, the navigation system provides a warning message to the driver, see page 7, lines 8 to 14. Furthermore, in such a case, the remote server reschedules the delivery of the parcel to another time during the same day or to the following day, provided that no rain is expected for that time or day, see page 2, lines 19 to 25 and page 8, lines 10 to 13.
3. Main request, Article 56 EPC
3.1 The examining division assessed inventive step starting from a general purpose networked computer system (decision, points 2.11 and 2.14). However, since claim 1 defines a vehicle navigation system presenting rain forecasts along a route traveled by the vehicle, the Board prefers to start from D3 which discloses these features and is much closer to the invention.
3.2 D3 discloses an on-board terminal for guiding a vehicle from a present position, detected using a GPS, to a destination, see paragraphs [29] and [73]. This terminal corresponds to the cartographic navigation system in claim 1. The destination might be a post office at which a parcel is to be sent ([50], last sentence) and, therefore, the vehicle of D3 is used, like the one in claim 1, for goods delivery.
The terminal is connected to a remote server which calculates a route to the destination ([43]), estimates the arrival time ([41]) and provides the route and a weather forecast for the area around the destination to the terminal for display ([102], [103], and [106]). It is implicitly disclosed that the weather forecast includes rain, and, therefore, presenting it corresponds to "sending a warning message when rain is expected at the delivery place of a parcel", as defined in claim 1. Furthermore, the server uses rain forecast data for route recalculation ([96]) rendering the appellant's arguments concerning the inventive step of this feature moot.
3.3 Hence, the subject-matter of claim 1 differs from D3 (lettering added by the Board):
A) In that the vehicle delivers a plurality of parcels, whereas in D3 the vehicle delivers only one parcel.
B) In that the route includes multiple destinations and the weather forecasts and time intervals are provided for each of these destinations, whereas in D3 the weather forecast and the time interval are provided for one destination.
C) By an RFID tag associated with each parcel that stores the water-sensitivity feature of the parcel and its destination.
D) By means for sending a warning message when rain is expected at the destination of a water-sensitive parcel at its expected delivery time.
E) In that the remote server recalculates in such a case the route by postponing the parcel's delivery in the current mission of the same vehicle or to the following day, provided that no rain is expected for that time or day.
3.4 The Board agrees with the examining division (see decision, points 2.6 and 2.7) that the distinguishing features implement a non-technical logistics scheme, wherein:
- Multiple parcels are delivered.
- One or more of these parcels are labelled as water-sensitive and the deliverer is notified if there is rain at the destinations of these parcels.
- In such a case, the delivery rescheduling according to feature E takes place.
- Each parcel bears information about its water sensitivity and destination.
3.5 The appellant did not dispute that delivering multiple parcels at different destinations and planing such delivery constituted a non-technical logistics scheme. The point of dispute was whether the rescheduling of the delivery based on the parcels' sensitivity to water and the rain forecast also formed part of this scheme.
3.6 Contrary to the appellant's view, the Board judges that the requirement to ensure that parcels do not get damaged forms part of the logistics scheme. Considering that logistics is about the delivery of intact goods, there are evident business reasons for this requirement.
The labelling of certain parcels as rain-sensitive and not delivering such parcels in the rain is a common-sense measure to meet this requirement. The Board judges that this kind of interacting with and exploiting knowledge about the physical world falls under a business activity, cf. T 154/04 - Estimating sales activity/DUNS LICENSING ASSOCIATES, reasons, point 20.
Applying this common sense measure does not require technical considerations, for example appreciation of why rain can damage some things while being harmless to others. This distinguishes the present case from the appellant's example, where protective measures against overload damage to an electric circuit could only be taken after certain technical aspects had been understood.
3.7 The Board is also not convinced by the argument that the technical effects in the present case are similar to those in case T 2035/11, supra.
Firstly, in that case, technical character was found to result from the dynamic recalculation of a route along which a vehicle was guided. In contrast, in the present case there is no recalculation, but merely a rescheduling which covers following the same route, but not dropping some parcels off. Thus, for this reason alone, the conclusions drawn in T 2035/11 are not applicable to the present case.
Secondly, even assuming that rescheduling parcel delivery involves some route modification, this still does not help the appellant's case. T 2035/11 states that a route recalculation has technical character only insofar as it is based on technical considerations (reasons, point 5.2.3). However, the route recalculation in the present case would be based on the avoidance of rain damage to parcels, which, as discussed above, is not a technical consideration.
3.8 Furthermore, the Board is not convinced by the argument that information about a parcel's water-sensitivity is functional technical data in the sense of decisions T 1194/97, supra, and T 424/03, supra, because its loss would impair the technical operation of the system (cf. T 1194/97, reasons, point 3.3).
It is self-evident that if a piece, either technical or non-technical, of any invention is taken out, it would not work as designed. In the Board's view, what T 1194/97 is saying is rather that the loss of functional data would make the system inoperable at the technical level. In contrast, if cognitive data is lost, the system would still work but possibly produce results that would be unintended for non-technical reasons. Thus in T 1194/97, the loss of functional data prevented the system from generating any television picture, whereas the loss of cognitive data only resulted in a meaningless television picture resembling snow.
In the present case, the loss of water-sensitivity information would not cause the system to stop working; the vehicle would still be guided, and parcels would be delivered. However, it would result in leaving water-sensitive parcels standing in the rain - an unintended operation comparable to producing a television picture that resembles snow. The reasons why these outcomes are unintended are non-technical. In T 1194/97, it was the cognitive meaninglessness of the television picture to a human viewer; in the present case, it is the prevention of rain damage to a parcel. Hence, judged by the consequence of its loss, the water-sensitivity data is equivalent to cognitive rather than functional data.
3.9 Applying the COMVIK approach (decision T 641/00 - Two identities/COMVIK), once the business requirement, set out at point 3.4 above, has been given to the skilled person to implement, enhancing the server of D3 to calculate routes including multiple parcel destinations and acquiring rain forecast for those destinations would have been obvious. It would also have been obvious to store the parcels' water-sensitivity features at the server and to adapt it to reschedule parcel delivery in case of rain. Adapting the terminal of D3 to provide a warning message in such a case directly follows from the requirement specification.
Furthermore, the Board agrees with the decision (points 2.13 and 2.20.6) that the use of RFID tags to store features of parcels would have been obvious in view of D5, in particular pages 1 and 2, which summarise the skilled person's common general knowledge.
3.10 Hence, claim 1 of the main request lacks an inventive step (Article 56 EPC).
4. First, second and fourth auxiliary requests, Article 56 EPC
Since claim 1 of these requests is broader than claim 1 of the main request, they lack an inventive step for the above reasons.
5. Third auxiliary request, Article 56 EPC
Claim 1 of this request adds to the main request that the weather forecasts are acquired through Application Programming Interfaces (APIs) accessible via Internet. Like the examining division (decision, point 3.7), the Board judges that this feature would have been obvious in view of paragraph [30] of D1.
The remaining part of claim 1 of the third auxiliary request is broader than claim 1 of the main request and these features are obvious for the reasons given above (Article 56 EPC).
6. Since none of the appellant's requests are allowable, it follows that the appeal must be dismissed.
For these reasons it is decided that:
The appeal is dismissed.