T 2150/18 (Ranked in order of severity/AETHON) 28-06-2021
Download and more information:
MONITORING, DIAGNOSTIC AND TRACKING TOOL FOR AUTONOMOUS MOBILE ROBOTS
Inventive step - main request and auxiliary request 1 (no)
Claims - clarity
Claims - auxiliary requests 2 and 3 (no)
I. The appeal is against the decision of the examining division to refuse the application on the grounds that the main request and auxiliary requests 1 to 3 did not meet the requirements of Article 56 EPC in view of the following document:
D1: WO 2007/047510 A2
II. With its statement setting out the grounds of appeal, the appellant requested that the decision be set aside and that a patent be granted on the basis of one of the requests on which the contested decision is based. It requested oral proceedings as an auxiliary measure.
III. In its preliminary opinion issued in preparation for the oral proceedings, the board raised objections inter alia under Articles 84 and 56 EPC.
IV. With its letter of reply dated 28 May 2021, the appellant filed additional auxiliary requests 0, 1a, 2a, 3a and 4.
V. Oral proceedings were held before the board, during which the appellant withdrew its additional auxiliary requests filed with the letter of 28 May 2021.
VI. Claim 1 of the main request reads as follows:
"A system (100) for managing and prioritizing for action fleets of mobile robots deployed at numerous locations, the system comprising:
a plurality of homebase servers (105), each corresponding to a different location, wherein each of the homebase servers receives and processes raw operational parameter data from a plurality of mobile robots (110) operating at a particular location; and
a central server (135) receiving the operational parameter data from the plurality of homebase servers, the central server including a data analysis module (145) processing the operational parameter data and prioritizing the mobile robots operating at the various locations based on the received operational parameter data using a set of business rules that are location and mobile robot specific,
wherein the operational parameter data comprises information regarding operational and navigational issues experienced by the mobile robots, and
wherein the data analysis module prioritizing the mobile robots comprises generating a prioritized list ranking the mobile robots in order of severity of operational and navigational issues experienced by the mobile robots based on the operational parameter data."
VII. Claim 1 of auxiliary request 1 differs from claim 1 of the main request in that it has the following additional text at the end:
"wherein the data analysis module displays the list prioritizing the mobile robots and ranking them in order of importance for action by support staff, and
wherein the list generated by the data analysis module includes operational information about the mobile robot, wherein the operational information comprises at least one of idle time of the mobile robot, status of the mobile robot, itinerary of the mobile robot, communication status of the mobile robot, whether an alert has been issued, a task of the mobile robot, where the mobile robot is at in its task, a cause of delay of the mobile robot, and a cause of idle time of the mobile robot, and wherein the operational information is visually coded to identify potential critical issues."
VIII. Claim 1 of auxiliary request 2 differs from claim 1 of the main request as follows (with the additions underlined):
"[...]
a central server (135) receiving the operational parameter data from the plurality of homebase servers, the central server including a data analysis module (145) processing the operational parameter data and prioritizing the mobile robots operating at the various locations based on the received operational parameter data using a set of business rules that are location and mobile robot specific, the business rules including at least one of mobile robot pathways, pathway properties, pathway sensor settings, destination and locking point wait times, lock point and staging area locations, elevator interactions, and minimum charging times,
[...]
wherein the data analysis module prioritizing the mobile robots comprises generating a prioritized list ranking the mobile robots in order of severity of operational and navigational issues experienced by the mobile robots based on the operational parameter data for action by support staff and displaying the prioritized list to the support staff."
IX. Claim 1 of auxiliary request 3 differs from claim 1 of the main request as follows (with the additions underlined and the deletions [deleted: struck through]):
"[...]
a plurality of homebase servers (105), each corresponding to a different location, wherein each of the homebase servers receives [deleted: and processes raw] operational parameter data from a plurality of mobile robots (110) operating at a particular location and operational status information of an elevator cabin, wherein each of the homebase servers syncs the received data and sends the synced data to a central server at regular intervals; and
[deleted: a] the central server (135) receiving the [deleted: operational parameter] data from the plurality of homebase servers, the central server including a data analysis module (145) processing the [deleted: operational parameter] data and prioritizing the mobile robots operating at the various locations based on the received [deleted: operational parameter] data using a set of business rules that are location and mobile robot specific,
[...]"
1. Main request
1.1 The contested decision found that claim 1 of the main request lacked an inventive step over D1. The appellant's objection to this finding is twofold.
1.2 Firstly, the appellant sees a difference in the system architecture. It argues that, in the system of claim 1 of the main request, data flows hierarchically through three tiers, namely from the robots to the homebase servers, and from the homebase servers to the central server. It argues that this is not the case in D1, referring in particular to paragraphs [013], [089] and [104] to [106], according to which the "remote host" can receive notifications directly from the robots. In the appellant's opinion, therefore, the "remote host" in D1 does not qualify as a "central server" within the meaning of claim 1. A "central server" should be able to collect and process operational data from all robots. The appellant also questions whether the system in D1 has a plurality of homebase servers, as required by claim 1.
The board is not convinced by these arguments. Firstly, labelling a server as a "central server" does not restrict that server in a technical sense. Instead, it appears to be a mere matter of nomenclature. In terms of system architecture, the "home base computer" (825 in figure 8, or 1230 in figure 12) of the hospital in D1 clearly corresponds to the "homebase server (105)" in claim 1, and the "remote host" (1250 in figure 12) in D1 to the "central server (135)" in claim 1. D1 discloses this architecture from the viewpoint of an existing hospital network (1210 in figure 12; see also paragraph [112]). However, it is at least obvious, if not already implicit, e.g. in paragraph [009], where the "remote host [...] oversees the implementation and monitoring of robotic tugs at a variety of different physical locations", that a help desk at a remote host can serve a plurality of hospitals, each with its own "home base computer". Regarding the hierarchical flow of data according to the appellant's argumentation, a direct communication between a robot and a remote server or an indirect communication via a local server constitute alternatives that are obvious to a skilled person.
1.3 The second part of the appellant's argumentation relates to prioritising the mobile robots to generate a list ranking them in order of severity of the operational and navigational issues they are experiencing.
1.3.1 In the system of D1, operational or navigational issues experienced by robots can trigger notifications to the help desk at the remote host, which come into a "queue" displayed to help desk operators (paragraphs [104] to [106]). The appellant argues that, with a plurality of notifications coming in from a plurality of robots, the help desk operators in D1 would have no way of quickly prioritising the notifications for action other than by spending time analysing the incoming notifications to determine which robot to serve first. At the oral proceedings, the appellant further argued that in D1, paragraphs [104] to [106], the remote host, unlike the central server of claim 1, did not even receive, let alone process, operational parameter data from the robots, and that the queue of notifications was not ranked.
The board is not convinced by these arguments. Firstly, the example notifications received at the help desk in D1, paragraph [105], namely "blocked hallway" and "elevator malfunction", include at least some information as to the type of operational issue faced by the robots. This information readily qualifies as operational parameter data. Secondly, in order to display the notification to the help desk operator, the remote host must process the data it receives. Thirdly, a queue is indeed a ranking on the basis of the chronological order of arrival time. Finally, there is a very simple and quick way of prioritising a queue, namely by following the queue itself. Therefore, the argument that a help desk operator would avoid wasting time with the help of a ranking that differed from that of a queue is not convincing.
1.3.2 The appellant further argues that the list ranking the robots in order of severity of the operational and navigational issues they are experiencing has a technical effect, as the generated information relates to the internal state prevailing in a technical system (a robot fleet) and assists the support staff in performing a technical task (troubleshooting the robot fleet) in a more efficient manner. It does this by identifying robots experiencing the most severe issues which need action first. This leads to increased system uptime and reduced costs. The appellant submits that, although the claim wording refers to "business rules", in the context of claim 1 this means technical rules, according to which operational parameter data is processed. However, at the level of generality of the term "rule", the board is not convinced that the alleged technical effect can be achieved over the entire breadth of the claim. In particular, the claim does not specify what these alleged technical rules for prioritisation and ranking are.
1.4 For these reasons, the subject-matter of claim 1 of the main request does not involve an inventive step (Article 56 EPC).
2. Auxiliary request 1
2.1 Apart from some additional features already taken into account in the assessment of claim 1 of the main request, namely that the prioritised list of robots is displayed to the support staff and ranked in order of importance for action by support staff, or the list including operational information about at least the status of the robots, claim 1 of auxiliary request 1 differs from claim 1 of the main request in that the operational information is visually coded to identify potential "critical" issues. The appellant relies, for this visual coding, on a similar line of argumentation to that used for the ranked list in order of severity (see 1.3.2 above). It thus argues that the visual coding relates to an internal state prevailing in the technical system and assists the support staff in performing the technical task of troubleshooting that system.
2.2 The appellant explained that the terms "severity" and "critical[ity]" were to a certain extent overlapping, but not identical. For instance, the prioritised list of robots experiencing operational and navigational issues could consist entirely of robots experiencing non-critical issues, ranked in order of "severity". If a critical issue were to arise in such a situation, the visual coding would make the support staff aware of it in a more timely manner.
2.3 The board is not convinced by these arguments. To the extent that severity and criticality are overlapping, the "visual coding", by which the application means a colour coding or other formatting, is nothing but a presentation of information providing the same information as the list ranked in order of severity (e.g. page 12, lines 13 to 15, of the description). To the extent that severity and criticality are different, the appellant's arguments are self-contradictory. Indeed, if the list of robots ranked in order of severity were to assist the support staff in deciding which issue to address first, then the visual coding of potential critical issues conflicting with the ranking of the list would rather confuse the support staff by suggesting a different ranking. Therefore, this feature does not have any credible technical effect.
2.4 For these reasons, the subject-matter of claim 1 of auxiliary request 1 does not involve an inventive step (Article 56 EPC).
3. Auxiliary request 2
3.1 Claim 1 of auxiliary request 2 specifies some examples of "business rules", namely "mobile robot pathways, pathway properties, pathway sensor settings, destination and locking point wait times, lock point and staging area locations, elevator interactions, and minimum charging times". This is a selection from a list on page 10 of the description. As the contested decision correctly noted, it is unclear how this list could be seen as a list of rules. Whereas rules can normally be expressed in IF-THEN format, the items in this list cannot. Instead, they are parameters. At the oral proceedings, the appellant acknowledged that the list given in claim 1 did not comprise complete rules, but argued that they were parameters to be taken into account by the rules and therefore "portions of rules". However, a rule is a rule and a parameter is a parameter. They are different things. Such an indiscriminate choice of terms renders claim 1 of auxiliary request 2 unclear (Article 84 EPC).
4. Auxiliary request 3
4.1 In claim 1 of auxiliary request 3, each of the homebase servers "syncs the received data" and sends it to a central server. The contested decision correctly observed that it was not clear from this wording which two data sets were synchronised with each other. The board added in its preliminary opinion (and further elaborated at the oral proceedings) that data synchronisation was normally understood in the relevant art to be a procedure for ensuring consistency between multiple copies of a data set. However, in the present case it was unlikely that data sets mentioned in claim 1 would be copies of each other. Therefore, it was not clear in which sense the term "sync[ing]" was used. The appellant argued that it was clear from the claim wording that homebase servers received data from two different sources, namely operational parameter data from robots and operational status information from an elevator cabin. Since these are two different types of data, "to sync" meant in the present context to link or to interrelate. However, using a term in such a speculative sense instead of its established technical meaning renders claim 1 of auxiliary request 3 unclear (Article 84 EPC).
5. Since there is no allowable request, the appeal has to be dismissed.
For these reasons it is decided that:
The appeal is dismissed.