T 0929/15 (Identifying a user issuing a voice request/ACCENTURE) 17-11-2020
Download and more information:
Client and server system for natural language-based control of a digital network of devices
Amendments - allowable (yes)
Claims - clarity after amendment (yes)
Inventive step - after amendment (yes)
I. The appeal is against the decision of the examining division to refuse the application on the grounds that the requests then on file did not meet the requirements of Articles 123(2) and 84 EPC.
II. The contested decision also includes comments on novelty and inventive step as obiter dicta, based on the following documents:
D1: US 2010/151889
D2: US 2009/043404
D3: US 6 198 479 B1
D4: US 2004/100492
III. With its statement setting out the grounds of appeal, the appellant filed an amended main request and an amended auxiliary request. It requested that the decision be set aside and that a patent be granted on the basis of one of these requests. It requested oral proceedings as an auxiliary measure.
IV. In its preliminary opinion issued in preparation for the oral proceedings, the board raised objections under Articles 84 and 56 EPC.
V. In response to the summons to oral proceedings, the appellant filed two further auxiliary requests.
VI. Oral proceedings were held before the board. At the oral proceedings, the appellant filed a new main request to replace all requests on file, which the board found allowable.
VII. Claim 1 of the new main request reads as follows:
"Computer network for natural language-based control of a digital home network (400), the network comprising:
a digital home network (400) comprising a plurality of devices (410, 420, 430, 440, 450, 460) and operable to provide sharing of Internet (500) access between the plurality of devices (410, 420, 430, 440, 450, 460);
a client (100) installed in the digital home network (400) comprising:
a unified natural language interface operable to receive a natural language-based voice user request (12) for controlling the digital home network (400)
using natural language; and
a module management component (140) operable to provide an interface to a plurality of software agents (300a, 300b, 300c, 300d, 300e, 300f) for publishing one or more actions offered by the software agents (300a, 300b, 300c, 300d, 300e, 300f) to the client (100); and
a server (200) connected to the client (100) over the digital home network (400) operable to process the natural language-based voice user request (12) received from the client (100); and
the software agents (300a, 300b, 300c, 300d, 300e, 300f), wherein each of the software agents (300a, 300b, 300c, 300d, 300e, 300f) is operable to execute at least one action on at least one of the plurality of devices (410, 420, 430, 440, 450, 460) which is controlled by said corresponding one of the software agents (300a, 300b, 300c, 300d, 300e, 300f) based on a command received by the module management component (140) of the client device (100);
wherein the server (200) is operable to process the natural language-based user request (12) received from the client (100) resulting in a processed user request (12) comprising a list of tags and an identification of a user (10) that provided the user request (12) identified by a voice identification component (220) of the server, wherein the user is identified based on the natural-language based user request (12) and wherein the voice identification component (220) is operable to identify users issuing user requests by:
- processing incoming voice samples of each user request;
- extracting features from the incoming voice samples; and
- matching the extracted features against voice prints of users stored in a database;
wherein, based on the processed user request (12) received from the server (200), the client (100) is operable to select a target device of the plurality of devices (410, 420, 430, 440, 450, 460) and a corresponding action to be performed;
wherein the client (100) is operable to perform the action by forwarding a corresponding command to the module management component (140);
wherein the module management component (140) is operable to trigger a corresponding software agent to perform the action on the target device (410, 420, 430, 440, 450, 460) which is controlled by said corresponding one of the software agents (300a, 300b, 300c, 300d, 300e, 300f);
wherein the action serves the natural language-based voice user request (12);
wherein the client (100) comprises further, a graphical user interface, GUI, (170) operable to be exposed to the user (10) for specifying user-defined settings of actions to be executed by the plurality of software agents (300a, 300b, 300c, 300d, 300e, 300f) on at least one of the plurality of devices (410, 420, 430, 440, 450, 460); and
wherein the client is operable to expose a single point of contact through the module management component (140) to the software agents (300a, 300b, 300c, 300d, 300e, 300f) by providing services to the software agents (300a, 300b, 300c, 300d, 300e, 300f) in order to allow the software agents (300a, 300b, 300c, 300d,
300e, 300f) to access the GUI via the module management component (140)."
The new main request has corresponding independent claims 5 and 6 in other claim categories.
1. Admissibility of the new main request
The new main request was submitted in response to objections raised for the first time by the board in its preliminary opinion, representing in the present case exceptional circumstances. Therefore, the board admits the new main request into the proceedings under Article 13(2) RPBA 2020.
2. Amendments and clarity (Articles 123(2) and 84 EPC)
1.1 Claim 1 of the new main request is the result of extensive amendments to the claims of the requests on which the contested decision is based. The natural language-based user request is now specified as a voice request, addressing the objection of lack of support in the description for text requests; and the reference to the user of the claimed apparatus in terms of functional features has been replaced by structural features from former dependent claims 4 and 5. The details of how a user who issues a request by speaking is identified from their voice, as described on page 23, lines 16 to 20 of the description as filed, were also added to claim 1. Furthermore, the consolidation of former independent apparatus claims 1, 2 and 3 into a single independent apparatus claim for a computer network comprising a server and clients has clarified the relationship between the individual components of the system and the interaction of the clients with the server within the system, rendering the objections in the contested decision moot. Corresponding amendments were made in the corresponding independent method claim wherever necessary.
1.2 Therefore, the board is satisfied that the claims of the new main request meet the requirements of Articles 123(2) and 84 EPC.
2. Inventive step (Article 56 EPC)
2.1 Document D4 represents the closest prior art to the subject-matter of claim 1.
2.2 Claim 1 comprises a number of features which are not disclosed in D4. The distinguishing feature that is worth further consideration is that the processing of a natural language-based voice request, besides producing a list of tags, also results in the identification of the user that provided the request. In particular, the user is identified by processing incoming voice samples of each request, extracting features therefrom and matching the extracted features against stored voice prints of users.
2.3 This distinguishing feature has the technical effect that each voice request is associated with the identity of the user who issued it, without the need for the user to explicitly input their identity.
2.4 The objective technical problem solved by this feature can thus be regarded as how to reliably and conveniently map a voice request to the user who issued the request.
2.5 The solution suggested in claim 1 is to biometrically identify the user who issued the voice request, based on features of the voice sample.
2.6 D4 suggests in several paragraphs, notably [0089] and [0092], that a group of users can each have a respective companion, or make use of a central companion running multiple processes for each user. However, it is silent on the complications that may arise in these scenarios, in particular how the companion(s) is/are to map a received voice request to a particular user. The appellant convincingly argued that even though D4 suggests, notably in paragraph [0094], that user authentication be required in order to access a companion - an authentication which might also take the form of an audio signature or a biometric signature - D4 consistently teaches (e.g. paragraph [0035]) that in such cases user identification is a precondition for accepting any request from the user. This teaches away from identifying the user while the received request is being processed.
2.7 Therefore, the claimed solution would not be obvious to the skilled person based on D4 alone. Nor would the skilled person be guided by the remaining documents on file to arrive at the solution in claim 1, since these documents are either entirely silent on providing a voice user interface or do not suggest user identification based on voice.
2.8 Consequently, based on available prior art, the subject-matter of claim 1 of the new main request involves an inventive step (Article 56 EPC).
For these reasons it is decided that:
1. The decision under appeal is set aside.
2. The case is remitted to the examining division with the
order to grant a patent on the basis of the following documents:
- claims 1 to 6 of the new main request submitted at oral proceedings before the board,
- description and figures to be adapted.