T 0178/14 (Peer-to-peer MFP network/KONICA MINOLTA I) of 6.7.2021

Summary of Facts and Submissions

I. The appeal is against the decision of the Examining Division to refuse the application. The decision cited in particular the document

D1: EP 0 929 023 A

and found that the requests underlying the decision lacked either novelty (main and first auxiliary) or inventive step (second auxiliary) starting from D1.

II. The appellant initially requested that the decision be set aside and that a patent be granted on the basis of a main request, filed with the statement of grounds and based on the second auxiliary request rejected by the Examining Division, or on the basis of two auxiliary requests filed with the subsequent letter of 18 March 2014.

III. The Board issued a summons to oral proceedings in which it indicated that all requests lacked clarity. It also stated that, for all requests, even in the claim construction advanced by the appellant, though the claims might involve an inventive step starting from D1, they would not involve an inventive step starting from document

D6: JPH1042114 A,

cited in the description of the original application,

in view of document

D7: K. Aberer, M. Hauswirth, "An Overview on Peer-to-

Peer Information Systems", Workshop on Distributed Data and Structures, 2002, Paris, France,

introduced by the Board.

IV. In response to the summons the appellant filed sets of claims A to D forming in the alphabetical order of the letters a main and three auxiliary requests. The previous requests were withdrawn if the new requests were admitted. The Board admitted those requests during the oral proceedings.

After discussion of these requests, the appellant replaced claim 1 of the set of claims D, thereby formulating a new auxiliary request 3.

V. The appellant's final requests were that the decision under appeal be set aside and a European patent be granted on the basis of the set of claims A (main request) or B, C or D, labelled auxiliary request 1, 2 and 3, respectively, all filed with a letter of 29 January 2020, with claim 1 of auxiliary request 3 being replaced by claim 1 as filed during the oral proceedings of 6 July 2021.

VI. Claim 1 of claim set A reads:

System comprising a network and

a first multi function peripheral which is connected to a network (2)

and a second multi function peripheral which is connected to the network

wherein the first multi function peripheral communicates with the second multi function peripheral (l00A),

and allows sharing data with said second multi function peripheral,

wherein the first and the second multi function peripherals comprise:

a registered user information storage portion (S02) to store registered user information including user identification information for identifying each user;

a request portion (S04) to request the other multi function peripheral to transmit the registered user information stored in the other multi function peripheral and a transmission portion (S04) to transmit the registered user information stored in the registered user information storage portion to the other multi function peripheral;

a reception portion (S05) to receive the registered user information stored in the other multi function peripheral in response to the request;

and a user data storage portion (S09) to store user data including the registered user information received in the reception portion.

VII. Claim 1 of claim set B differs from that of set A in that the feature and allows sharing data.... now reads

and allows sharing data with said second multi function peripheral and allows sharing the data without the use of a single server...

VIII. Claim 1 of claim set C differs from that of set A in that the following feature is added at the end of the claim:

wherein 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.

IX. Claim 1 of claim set D reads

Method for transmitting image data to one of the registered users of a system comprising a network and

a first multi function peripheral which is connected to a network (2)

and a second multi function peripheral which is connected to the network

wherein the first multi function peripheral communicates with the second multi function peripheral (l00A),

and allows sharing data with said second multi function peripheral,

wherein the first and the second multi function peripherals comprise:

a registered user information storage portion (S02) to store registered user information including user identification information for identifying each user;

a request portion (S04) to request another multi function peripheral to transmit the registered user information stored in the the other multi function peripheral and a transmission portion (S04) to transmit the registered user information stored in the registered user information storage portion to the other multi function peripheral;

a reception portion (S05) to receive the registered user information stored in the other multi function peripheral in response to the request; and

a user data storage portion (S09) to store user data including the registered user information received in the reception portion, wherein 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,

by transmitting image data from one of the multi function peripherals to the other multi function peripheral which transmitted the registered user information of the one of the registered users after a user inputted the image data at one of the multi function peripherals and the registered user information of one of the registered users.

Reasons for the Decision

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).

Order

For these reasons it is decided that:

The appeal is dismissed.