T 1346/10 (Tracking Resource Status/CONTENTGUARD) 28-03-2014

Procedural situation

1. Since Vodaphone has withdrawn its appeal the proprietor is the sole appellant and the former opponent Vodafone has ceased to be party in the appeal proceedings as far as the sub­­stan­tive issues are concerned (see T 789/89, head­­note).

The late filed requests

2. In the annex to the summons, the board questioned that the then pending claims supported the appellant's alle­gation "that the state controller is remote from the usage rights expression" and addressed the breadth of the claimed step of "enforcing". The board also ex­pressed its preliminary view that the last feature of the pending independent claims consti­tu­ted added sub­ject matter, Article 123 (2) EPC. Thus the amendments made to the claims of what was filed as first aux­il­iary request on 28 February 2014, namely explicitly specify­ing the state controllers to be "rem­ote", the "enfor­cing" to comprise "evaluating [a] usage right" and the deletion of said last feature, are appa­rently made in direct response to the board's concerns raised in the summons. Since they also do not introduce any inappro­pri­ate complexity the board exercises its discretion under Rule 13 (1) RPBA and admits this first auxiliary re­quest into the procedure. Consequently, it replaces the main request according to the appellant's request. No decision about admission of the further auxiliary re­quests is required.

The invention

3. The patent generally relates to the specification and ma­nage­­ment of digital usage rights which regulate the access to and use of a pro­tec­­ted resource according to certain, potentially dynamic con­di­tions: For instance, the right to use a protected resource may be limited to a number of times or to a specified period of time, or it may be granted only if no other users are logged in­to the pertinent network at the same time (see pars. 18, 19 and 61 of the published application). The status of these conditions is tracked by so-called "state vari­ables" (see pars. 19 and 35).

3.1 It is described that a user operates within a client environment from which a protected resource is accessed or used, for instance via some software application such as a rendering engine installed on the client (see pars. 21 and 24; fig. 1, no. 12 and 30). In order to access a protected resource, say to view a protected do­cument on the client screen, a request is issued (par. 38, lines 4-6; par. 40, lines 3-7; and par. 41, lines 1-2).

3.2 Access to the protected resource is controlled by a so-called "state manager" (see fig. 1, no. 40) comprising, inter alia, a "condition validator" 44 and a "resource manager" 42. The condition validator monitors the con­di­tions regulating individual usage rights and the current values of the state values of these rights and interacts with the resource manager to control access to the protected resource, especially notifying it when access is no longer allowed (pars. 22 and 48).

3.3 The state manager also comprises a so called "state of rights framework" 20 which provides an API to what are called "state controllers" 22 (see par. 49). Each state controller is a component that manages the state of a given state variable, i.e. allows its value to be que­ried or updated (see e.g. par. 50). Where a state va­riable is actually stored and how it may be accessed is encapsulated in the corresponding state controller and state variables can only be accessed through the per­tinent state controllers. That is, the location of the state variables is "transparent" to the state of rights framework (loc. cit.). The state of rights framework will, in res­ponse to a request, "determine what state controller is res­pon­sible for [a] request and then lo­cate, authen­ticate and load that specific state con­troller 22 and pass the request to the state controller 22 for pro­cessing" (par. 58). The location of the state con­troller itself or the communi­cation pro­tocol re­quired to communicate is specified in the usage rights (see par. 34). It is specifically disclosed that a state con­troller may be "local or remote" (loc. cit.; see also par. 34, lines 7-12; and par. 51); in the gi­ven context this must mean local or remote relative to the state of rights framework.

4. Original independent claims 1 and 9 already referred to a "resource control device coupled to [a] resource" and to an "interface framework operative to receive a message related to [a] state variable from said re­source [control] device" and to act on it. Literally, this lan­guage was not con­tained anywhere in the body of the pa­tent specifi­ca­tion except in the section entitled "summa­ry of the in­ven­tion" but was maintained in the independent claims as gran­ted and in the present inde­pendent claims.

4.1 In the board's view, the skilled person would interpret the claimed term "resource control device" as the "cli­ent" device 30 which, according to figure 1, is also "coupled" to a resource and take the claimed "interface framework" to mean the "state of rights framework" and its API, i.e. applica­tion programming interface (see esp. par. 58). Furthermore, the skilled person would understand the "message", claimed to be "from [the] resource [control] device" and to be "related to the state variable", to be part of the condition validation process, noting that the condition validator 44 is de­scribed inter alia to manage the state of the rights" (see par. 22), and therefore be bound to con­clude that at least this part of the state manager had to be local to the resource control device, i.e. the client.

4.2 The board notes that this is consistent with the de­scription which discloses that, in general, the various compo­nents can be "combined or segregated as hardware and/or software modules and devices in any manner" and "be stored on the same device or on different devices" (pars. 65 and 66).

Added subject matter

5. The independent claims according to the main request have been limited over the independent claims as gran­ted by specifying that the state controllers are "re­mote" and that "said enforcing comprises evaluating said usage right". The former is disclosed in para­graphs 34 and 58 of the application as originally filed, and the latter is disclosed in the original application in paragraph 45 in combination with the fact that, according to the above interpretation, the condition validation is claimed to be located at the client, i.e. the resource control device. The board is thus satisfied that these amendments conform with Article 123 (2) and (3) EPC.

6. The independent claims as maintained in oppo­sition (and, in fact, as granted) contained the following fea­ture which was not originally claimed, namely that the "method spe­ci­fication includ[e] a location where the values of said s[t]ate variables are stored or inclu­ding a communica­tion protocol to communicate with said state con­troller". With regard to this feature, the for­mer opponent Vodafone argued that the origi­nal appli­­cation discloses only the method speci­fi­ca­tion to comprise location and (rather than: or) communication protocol so that claim 1 as maintained in opposition went beyond the content of the appli­ca­tion as origi­nally filed.

6.1 Article 100 (c) had not been invoked as a ground for oppo­­­si­tion by the former opponent Vodafone. While it had been invoked by the other former opponent Nokia, this specific objection of added sub­ject matter was not raised. More­over, Nokia had with­drawn its opposition and did not participate in the oral proceedings before the opposi­tion division. During these oral proceedings, the opposition division treated added subject matter as a fresh ground for opposition and decided not to admit it into the procedure (see minutes, p. 2, lines 15-18). Consequently, the decision under appeal did not address added subject matter of the granted claims as a ground for opposition. Under these circumstances, the board has to treat the above objection as a fresh ground for opposition which, since the proprietor dis­agrees with its in­­troduction, has to be dismissed in accor­dance with G 10/91 (headnote 3 and grounds 18). It is there­fore irrelevant that the board also tends to agree with the appellant/proprietor in substance, as set out in the summons (see point 7.2).

The prior art

7. E1 discloses a system allowing only authorized users to access a protected resource, for example a DVD, accor­ding to certain usage rights which specify certain "manners of use" (free play mode, charged mode, limi­ted-attached play; see abstract). This permission is negotiated between the user's client and one of possib­ly several servers (see fig. 1, nos. 2 and 8; p. 3, line 7).

7.1 The rights are expressed in a so-called "distribution descriptor" which, inter alia, defines the "terms-of-use" (TOU) for the entire volume or for individual appli­ca­tions on the volume (see fig. 4, nos. 34-35, fig. 23). The terms of use can in­clude "use-limiting fac­tors" such as an expiration date, a use period or a ma­xi­mal number of accesses (see p. 5, lines 21-37; p. 10, lines 26-28). These rights are expressed on the "volume" (e.g. the DVD) and thus read and accessed by the client (the DVD player; fig. 1, no. 2), even though they may also be kept in a server "from the beginning" (p. 10, lines 22-23).

7.2 To enforce the rights, some kind of meter is necessary (calendar, usage meter, access count). These are stored on a server (see e.g. p. 6, lines 36-43; and fig. 1, no. 8). Also the maintenance of the meters and the "en­forcement" of the rights is under the control of a ser­ver. When a server receives a service request (see e.g. p. 6, line 54), it will retrieve the relevant me­ter val­ue and check whe­ther the request can be gran­ted (see e.g. p. 10, lines 11-16). Eventually, the meters are also updated at the server side (see e.g. p. 7, lines 20-28).

8. E2 discloses a system for regulating access to a pro­tec­ted resource, esp. a software product (col. 3, line 26-30), via what is called a "battery". This term is used metaphorically, the "vir­tual battery" (col. 3, lines 11-13) representing the notion that the allowed use of the resource is limited and how much. The "batte­ry value" may be implemented as a counter which is decreased over time or according to use, i.e. when the battery is "discharged", but which may also be in­creased by some form of "charging" (see col. 3, lines 14-25; figs. 1 and 3). The battery regulates only the use of some "manners of use", others are unli­mi­ted (see "target functions", "non-target functions", col. 9, lines 26-39). The check whether a function is allowed is performed by an "operation management program" (see also col. 8, lines 40-57), and so is the charging pro­cess, which uses a so-called "battery value manage­ment means" (col. 8, lines 20-39; col. 2, line 58 - col. 3, line 5 and col. 3, lines 31-34). While the "managed software product" and the "manage­ment soft­ware" may be "separate", both are maintained at the user's machine (see fig. 3, nos. 18, 36, 38; col. 7, lines 28-31).

9. E5 is an excerpt (several individual pages) of a stan­dard textbook on C++ meant to establish that message queries to obtain variable values are common knowledge. As such value queries are not contained in the indepen­dent claims of the main request, E5 is not relevant for the present decision. A decision on whether to admit E5 is thus also not required.

Inventive step

10. The former opponent Vodafone argued, inter alia, that "the under­ly­ing objective problem addressed by the main­tained claims is non-technical in nature" and suggested that, therefore and in view of G 3/08, their matter lacks an inven­tive step in view of common know­ledge alone. This approach was not contained in the grounds for opposition and results in a new legal and factual framework which was only sketched in the sub­mission by the former opponent. The board thus agrees with the appellant that this approach is not to be ad­mitted in accordance with the case law in T 1002/92 (head­note 2).

11. It has always been common ground between the parties to start the assessment of inventive step from document E1. The board concurs that this is a suitable choice.

11.1 The board agrees with the decision under appeal in finding the following:

The client of E1 constitutes a "re­source control de­vice" in that it acts according to a message from the server to allow or prohibit access to the protected re­source (see E1, p. 10, lines 14-16). This amounts to "enfor­cing the usage right" in a broad sense. The ser­ver of E1 runs a "state controller" insofar as it com­prises software accessing and manipulating the (val­ues of) state variables stored at the ser­ver. More­over, the server is remote from the client, i.e. it is known from E1 that the state controller is remote from the re­source control device.

The server of E1 provides some kind of "interface frame­­work" defining and managing the exchange of DRM messages between client and server.

The "distribution descriptor" of E1 (see fig. 4) com­­­pri­ses the server public key, and the EEPROM fur­ther com­­prises (see p. 5, line 16) the server ID and the ser­ver network address (p. 6, lines 44-47). Hence, E1 discloses that at the client side a "method specifica­tion" is stored specifying both the location of the state variables (the ser­ver = the location of the state controller) and how to communicate with it (via which encryption keys).

11.2 E1 does not disclose however

a) that the remote state controller is loaded when it is nee­ded, more specifically that the "interface frame­work ... load [the needed] state controller",

b) while at the same time the evaluation of the usage rights is performed at the resource control device, i.e. at the client.

11.3 In the system of E1, all clients have to negotiate with a server whether the requested resource may be accessed. If too many clients communicate with one server at the same time, response times may suffer. The board considers that having the client evaluate the user's rights contributes to a better load balancing by unburdening the server.

11.4 The board notes that E1 anticipates the provision of several servers, apparently as an alternative way of addressing possible server overload. Nonetheless, the board considers that, in general, it would have been an obvious op­tion for the skilled person to improve load balancing to move work from the server to the client.

11.5 However, instead of moving the entire rights management to the client, the claimed invention specifies to keep the state controllers, and thus the handling of the state variables, remote from the evaluation of the usage rights. In the board's view this contributes to security in reducing the risk that a fraudulent user at a client circumvents the rights enforcement by manipu­la­ting the state variables. Furthermore it means that the value of state variables can be changed at the server, without requiring any "push" mechanism to communicate the change to the client. In commercial terms the (in itself non-technical) desire to do this might arise because for example a content provider might want to give a "bonus", in terms of a number of accesses or additional time.

11.6 The board thus considers that differences a) and b) in combination can be considered to solve the problem of an improved load balancing while maintaining control and safety of state variables.

11.7 The board is of the opinion that E1 does not suggest to split the evaluation of rights and the handling of the state variables in this manner. Neither does E2 suggest this as it discloses that the battery value management is stored and run at the client computer.

11.8 The board therefore comes to the conclusion that the subject-matter according to claims 1 and 10 shows the required inventive step over E1 and E2, Article 56 EPC 1973.

12. The decision under appeal states it to be "obvious for a pers­on skilled in the art to load a state controller when it is needed" without however elaborating on this argument further or citing any document to establish it. In view of the board's finding above, this question did not have to be discussed during oral proceedings and was left open.

Adaptation of the description

13. The board notes that the description has not yet been adapted to the amended claims. For instance, it is now an obligatory feature of the invention for the "state controller" to be remote and no longer merely an option as disclosed in paragraph 58 of the description. And the location of functions at devices in the invention as now claimed is not as free as paragraphs 65 (last sentence) and 66 state. The appellant agreed to post­pone the adaptation of the description to the prosecu­tion after remittal.