T 0178/14 (Peer-to-peer MFP network/KONICA MINOLTA I) 06-07-2021

The application and the prior art

1. The aim of the invention is to provide a system which allows a plurality of image processing apparatuses to share data without the use of a server. In all the embodiments of the original description, the image processing apparatuses are MFPs (Multi Function Peripherals) with identical arrangement and function (see description par. [0037]).

1.1 To achieve said aim, the apparatuses store a list of registered user information, with user identification information for identifying each user. It is then possible for a first such apparatus to request a second one to transmit its registered user information. In this way a separate server is not needed.

1.2 The embodiments differ in how the user registration data is stored and communicated.

1.2.1 In the first embodiment the users have a home terminal each and all MFPs intercommunicate to obtain and store this information. Each MFP then stores two types of user registration data, the first type for the users having that terminal as home terminal, and the second type for the others, including the home terminal information.

1.2.2 In the second embodiment, the home terminal information is not shared at installation, but discovered when needed using a detection service.

1.2.3 In the third embodiment there is no home terminal. Once a user is registered, this information is broadcast to all terminals and stored on each of them in the same manner.

2. The application describes the invention starting from document D6. This document teaches a client-server architecture for copying machines, wherein a user can scan an image on one of the machines and send it to another for printing. The image data is stored on the server, including information about the destination machine, and retrieved using a pull mechanism by that machine.

3. Of relevance to the present decision is also document D7. This document is an overview of peer-to-peer (P2P) systems which are said to offer an alternative to client-server systems, every node acting as both client and server. As explained on the first two pages, these systems solve (through decentralization) both the bottleneck and the single point of failure problems characteristic of client server configurations, but at the price of computational complexity.

Admittance of requests based on claim sets A to D as filed in response to the summons

4. The Board notes that a first summons to oral proceedings for the present case was issued on 5 December 2019, before the entry into force of the RPBA 2020, and the requests based on claims sets A-D were filed in response to this summons. The second summons, of 12 February 2021, became necessary for reasons internal to the Board of Appeal and was further delayed due the COVID-19 pandemia. The Board thus considers that, according to the transitional provisions (Article 25(1) and (3) RPBA 2020), Article 13(2) RPBA 2020 does not apply, and that the admittance of these requests is governed, inter alia at least, by Article 13(1) RPBA 2020.

5. The Board also considers that the amendments are bona fide responses to the clarity objections first raised by the Board in the first summons at point 6 ("without a server" and "scanner, printer or facsimile" - 6.1; removal of the or from the and/or conjunction - 6.2), and admits these requests (Article 13(1) RPBA 2020).

Main request: inventive step (Article 56 EPC 1973)

6. As a starting point for the discussion the Board uses document D6. The difference with the system of claim 1 is that the latter system contains features related to receiving, transmitting and storing the user registration information and sharing the image data between the terminals. These features serve to define a system wherein the terminals can communicate directly with each other, as opposed to the client-server configuration of D6.

7. Client-server configurations have known pitfalls, such as bottlenecks and single point of failure issues (D7, section 1; D7 section 2). The skilled person will search for a solution to these issues. A well known alternative to client-server systems avoiding these pitfalls is the P2P decentralised system (D7, section 2). When modifying the system of D6 from client-server to P2P, it becomes necessary for the imaging apparatuses themselves to take over the functionality previously provided by the server. This means that the information regarding allowed end users should be stored on the imaging apparatuses. Furthermore, under the assumption that users wish to be granted access to different apparatuses, it is obvious that such information should be transmitted from an apparatus on the system on which it is stored to an apparatus which requests it, to allow the apparatuses to grant, or not, user access.

8. The features of claim 1 define nothing more than this, which means that they constitute a straightforward technical implementation of the requirement to distribute the role of the server over the imaging apparatuses in a P2P setup.

9. The appellant contested the above analysis in that MFP systems were small scale systems and did not have the same problems as large scale systems such as those discussed in D7. The skilled person would not have considered bottlenecks as a real problem in D6 and would anyway not have considered D7, which was about large scale systems.

9.1 The objective technical problem was therefore rather the one presented in the description in relationship with D6, i.e. that system modifications could not be accommodated with flexibility (end of paragraph 3). D7 did not address this problem, so the skilled person would not have taken D7 into account.

9.2 Even if they had considered D7, there are systems in D7 which are still partly centralized (Napster), so it would not have been obvious to build a fully decentralized system, taking account of the fact that this comes at the expense of higher computational complexity and security issues (D7, section 1).

10. The Board does not accept this argumentation, because, even if bottlenecks may be a lesser issue in D6, at least the single point of failure problem remains present, and applies equally to small and large scale systems. Thus the skilled person would consider D7 and the decentralised P2P approach in order to solve this problem, and would thereby arrive at the claimed features.

11. It is concluded that claim 1 of the main request lacks inventive step starting from D6 in view of the common general knowledge as evidenced by D7.

Auxiliary request 1

Clarity (Article 84 EPC 1973)

12. The Board considers that the term "server" is very general, and that the use of a server does not, by itself, define a standard client-server configuration (each terminal in a P2P setup is also a server, see D7 as discussed above). The negative limitation introduced in this request, i.e "without a single server", while aiming to exclude such standard configuration, does not clearly exclude it for similar reasons - a client-server configuration may use multiple servers, e.g. for redundancy. The corresponding architecture remains therefore undefined. As a consequence, the claim lacks clarity.

Inventive step (Article 56 EPC 1973)

13. As noted above, the limitation introduced in this claim is not clear, and thus cannot be used to support a finding of inventive step. But even if the intended interpretation, i.e. not using a standard client-server configuration, was taken, this does not change anything to the discussion on inventive step as to the main request, wherein the claimed features were mapped onto a P2P system.

Auxiliary request 2: inventive step (Article 56 EPC 1973)

14. The feature added in this request is that

the user data storage portion stores (S09) the registered user information received in the reception portion associated with apparatus identification information for identifying the multi function peripheral which stored the registered user information.

The appellant explained that this feature enables sending image data to the home terminal of a specified user, and that such feature would not be obvious, even when considering P2P systems.

15. The Board remarks that the claims do not actually define a home terminal, but merely terminals storing user registration information and means for communicating that information. That the user registration information is previously stored on some other terminal may simply mean that the user is known to that terminal. For instance, when a new terminal is plugged in, all the existing terminals may already know all users. Thus storing information about the terminal which previously stored the user registration data does not identify a home terminal. The technical effect is therefore not achieved by the claimed features, which means that an inventive step cannot be acknowledged on that basis.

16. No other technical effect has been brought forward by the appellant, the application itself does not point to another one either, and the Board cannot see one itself. Thus this feature cannot be considered to contribute towards solving a technical problem and has no significance for assessing inventive step (T 641/00, point 6). The features that do contribute towards solving a technical problem have been found to be obvious (see discussion on the main request). Consequently, claim 1 of this request lacks inventive step in the meaning of Article 56 EPC.

Auxiliary request 3: admittance

17. This request was filed during the oral proceedings. As for the other requests discussed above, its admittance is governed by Article 13(1) RPBA 2020. The appellant indicated that the amendments were made in order to clarify the features relating to the home terminal, in relationship with the scenario where one user sends an image to another user by indicating its user ID (paragraph 67, first embodiment).

18. The Board notes that the fact that the features related to the home terminal were not clearly claimed was already set out in the summons to oral proceedings (points 8.2 and 8.3). The appellant thus could - and in the board's judgment should - have filed these amendments in response to the summons, when filing the other requests. Moreover, it is clear that this amendment is a generalization of the scenario in paragraph 67, pertaining to the first embodiment; however, it is not clear if the claim is restricted to that first embodiment, taking account of the fact that the claim does not define the different types of user registration data required by that first embodiment. This raises prima facie issues under Article 123(2) EPC.

In view of the very late state of the proceedings when the amendment was filed and the fact that the amendment gives rise to new objections, the Board declines to admit this request (Article 13(1) RPBA 2020).