T 1043/08 (Programming interface for licensing/MICROSOFT) of 2.12.2011

Summary of Facts and Submissions

I. The appeal lies against the decision of the examining division, posted on 11 December 2007, to refuse the European patent application 04021618.6.

II. An appeal was filed on 20 February 2008 and the appeal fee was paid on the same day. A statement of grounds of appeal was filed on 21 April 2008. It was requested that the decision be set aside and that a patent be gran ted based on the main or 1st auxiliary request sub ject to the decision or, as a 2nd auxiliary request, on the basis of a new set of claims filed with the grounds of appeal.

III. With summons to oral proceedings, the board referred to the following documents:

D1: US 5,204,897 A

D6: Oberg R. J. et al., "Application Development using Visual Basic and .NET", Prentice Hall, 2002; Excerpt relating to Asynchronous Programming

and explained its preliminary opinion that the inde pen dent claims of all requests appeared to lack an inven tive step over D1 in view of D6 and common knowledge in the art. In addition, objections under Articles 84 EPC 1973 and 123(2) EPC were raised.

IV. In response and with letter of 2 November 2011, the appellant filed two amended sets of claims to replace all claims on file so as to overcome the objections under Article 84 EPC 1973 and 123(2) EPC.

During the oral proceedings the appellant requested that a patent be granted based on the following application documents:

description, pages

1, 1a-1c received on 10 October 2006

28 received on 23 October 2007

2-27 as originally filed

claims, numbers

1-12 according to a main or an auxiliary re quest, labelled "No. 1" and dated 2 November 2011

drawing, sheets

1/5-5/5 as originally filed

V. Claim 1 according to the main request reads as follows:

"A system (110) for supporting the enforcement of a license for a computer program, the system comprising:

a licensing component (202) that maintains a license store (204) in which the license is stored, the license comprising a right in the software and a set of data associated with said right, the licensing component exposing a callable interface to the computer program (135), said callable interface comprising:

a right-consumption method which receives an identifier of said right from the computer program and determines whether the right can be exercised; and

an information-retrieval method which receives an identifier of said right from the computer program and provides said set of data, or information based on said set of data, to the computer program,

wherein said licensing component (202) is usable by a plurality of computer programs, the computer program being included among said plurality of computer programs, wherein said callable interface further compri ses:

a handle-opening method that provides a handle to the computer program;

wherein the rights-consumption method receives the handle from the computer program and uses the handle to identify the computer program from which a call to the rights-consumption method is received,

wherein the license is one of a plurality of licenses that are stored in said license store, and wherein the rights-consumption method causes the licensing component to select the license based on one or more factors comprising:

whether the license store is associated with the computer program; and

a conflict rule that determines which license to select from among a plurality of license that are associated with the computer program,

and wherein said callable interface further comprises:

an asynchronous-context-initiator method that establishes a context for asynchronous processing and provides an identifier of said context to the computer program;

wherein said rights-consumption method receives the identifier of said context from said computer program and processes a right-consumption request asynchronously in response to receipt of the identifier of said context."

Claim 1 according to the auxiliary request differs from that of the main request only in the paragraph defining the rights-consumption method, now reading as follows:

"a right-consumption method which receives an identifier of said right from the computer program and determines whether the right can be exercised by checking (a) a binding of the license to a product key of a computer program, (b) a binding of the license to the system (110) on which the computer program is running, and (c) a validity that the right has not expired, wherein the computer program is notified on the result of the determination of whether the right can be exercised;"

VI. At the end of the oral proceedings, the chairman announced the decision of the board.

Reasons for the Decision

Articles 84 EPC 1973 and 123 (2) EPC

1. The board is satisfied that the amended claims fulfill the requirements of Article 123(2) EPC and that the amendments also overcome the objections under Article 84 EPC raised in the summons.

The Invention

2. The invention concerns a "callable" application programming interface (API) that enables computer pro grams to access software licensing services in a uni form manner. According to the invention, a central store holds licen ses which express whether and under what con ditions an individual computer program has the right to perform certain functions. Programs in need of a speci fic right can request it from the licensing ser vice which will inform the caller whether a suitable license exists or not.

2.1 According to independent claim 1 of both requests, the interface comprises a right-consumption method, an infor mation-retrieval method and a handle-opening method.

2.2 According to claim 1 of the main request, the right-consumption method "determines whether the right can be exercised". According to claim 1 of the auxiliary request this involves checking for a license which is correctly bound to a particular computer program and system and has not yet expired. The description explains the term "consume" to mean the "exercise of a specified right" (see par [0006]). It is a design deci sion that the licensing server in general and the right-consumption method in particular do not enforce the rights in question, but that the caller is relied upon to respect the license or its absence (see par. [0007]). As a consequence, "consuming" or "exer cising" a right does not mean exercising the action to which the right refers: For example, exercising a print right does not subsume the printing.

2.3 The handle-opening method provides a "handle" to the calling computer program which is used subsequently to identify the computer program in calls to the rights-consumption method and, as the description explains, to other methods of the interface (cf. hSLC e.g. in pars. [0032]-[0034], [0066]-[0067], [0087]-[0088]).

2.4 The information-retrieval method returns information associated with the pertinent right. While the claims do not specify this information in more detail, the description explains that it may contain information about the permissibility of performing certain actions within the "consume[d] right" (par. [0008]).

Inventive Step

3. It is common ground that D1 is a suitable starting point for the assessment of inventive step.

3.1 D1 discloses a licensing infrastructure (see esp. fig. 7) with "licensing component" (no. 10) maintaining a "license store" (no. 23) which can be accessed by a plurality of computer programs (nos. 17a and 17b) to assess whether they can exercise certain required rights. Access to the licensing component is through a "callable interface" (col. 21, lines 20-24).

3.2 The interface provides a method lm_request_allocation which is called to de ter mine whether the use of a desired product or product feature is (in principle) permitted (col. 21, lines 44-49). It is determined whether sufficiently many so-called "li cense units" are available to autho rize the requested use (col. 14, line 67 - col. 15, line 3). If so, the appropriate number of license units is either "alloca ted" - in which case they are "unallo ca ted" after use - or "consumed" - in which case they cannot be returned (cf. col. 15, line 17-63).

3.3 If a call to lm_request_allocation succeeds, a "grant handle" is returned that can be referred to later (col. 22, lines 2-8). For example, the grant handle can be passed to the method lm_query_allocation, inter alia to obtain further information about the grant (col. 22, lines 51-53). Such information may relate either to conditions under which the right can be exercised (cf. "product use authorization"; col. 22, lines 55-58) or whether transi tive licensing is allowed (cf. "calling card request"; col. 22, lines 55-68, col. 25, line 62 - col. 26, line 30, and col. 8, lines 4-22).

3.4 While thus both methods of D1, lm_request_allocation and lm_query_allocation, determine whether a pro gram may exercise a desired right, only lm_request_allocation actually selects a li cense from the license store (see e.g. col. 24, lines 27 ff.) while lm_query_allocation allows its further in spection. Accordingly, the board agrees with the appellant that the claimed right-con sumption method corres ponds to lm_request_allocation whereas the claimed information-retrieval method cor responds to lm_query_allocation (cf. grounds of appeal, e.g. p. 3, 4th par.).

3.5 D1 discloses that both methods must identify the rele vant right: lm_request_allocation the required "li cense units" and lm_query_allocation the "subject argu ment" (col. 21, lines 44-46 and col. 22, lines 55-58). It is further disclosed that a call to lm_request_allocation must iden tify the calling program via a so-called "pro duct identifier" (cf. col. 24, line 27-33). This product identifier corresponds in the present description to the "appli ca tion GUID" which identifies the application to the handle opening method (cf. pars. 32-33).

3.6 The "grant handle" of D1 is ge ne rated by the license server and used for subsequent API calls (col. 22, lines 24-26 and 53-55), in par ti cular those for accessing information about granted rights. In this regard hence the grant handle plays the same role as the handle according to the invention. However, the grant handle of D1 is returned only after a success ful grant allocation request, where as the handle according to claim 1 is produced by a "handle-opening method" before the right consumption method is called.

3.7 The license store may contain several licenses asso ci ated with the same computer program from which accor ding to certain criteria a suitable one will be selec ted (cf. col. 24, lines 34 ff.). In the board's view, these criteria qualify as "con flict rules" as claimed.

4. The appellant argued in oral proceedings that for a program to exercise a right it would be obligatory to call both lm_request_allocation and lm_query_allocation. According to the appellant the call to lm_query_allocation was necessary so as to ensure that license units which lm_request_allocation may have allocated at some point were still available for the calling program when needed later and had not meanwhile been "unallocated".

4.1 The board cannot follow this argument for two reasons. Firstly, D1 explicitly discloses that the call to lm_query_allocation is "optio nal and in most cases not needed" (col. 23, lines 18-21). Secondly, neither the claims nor, in fact, the description specify precisely what happens during the rights-consumption method - which could, hence, include the allocation and/or consumption of license units accor ding to D1; And the claims leave open what the calling program is to do with a granted right (see also point 2.2 above) so that the claims do not exclude the possi bility that a second method call might be obligatory to exercise a right.

4.2 Therefore, even if D1 were inter preted to disclose both method calls as obligatory, the board does not see that this would establish a difference over the independent claims of both requests.

Main Request

5. In the board's view, claim 1 according to the main request differs from D1 by the following features.

a) D1 does not disclose a handle-opening method and a handle as claimed.

b) The claimed interface comprises an "asynchronous-con text-initiator method" establishing a "context for asynchronous processing".

c) The right-consumption method executes asynchro nous ly if it receives such a context as an argument.

6. It is a common programming paradigm to organize access to data structures via handles and an asso ci ated open function. In particular this is the case for files - which the description appears to acknow ledge when stating that the handle should operate "like a file handle" (see par. 41) - but also for sessions, threads, devices, objects or other data struc tures. It is also well-known in the art to have integrated methods for opening and directly accessing a data structure.

6.1 The claims specify an open method separate from a right consumption method whereas D1 can be viewed as integra ting the open function into the request allocation method. The board considers these to be obvious alter na tives which would be immedia tely available to the skilled person.

6.2 More specifically, if the skilled person were to extend the interface of D1 by additional methods, which is in the board's view per se an obvious desirable, for example by one which would allow a client to inspect the reason why a request could not be granted, the board judges that it would be ob vious for the skilled person to consider rearranging the interface of D1 by providing a handle and a handle-opening method as claimed.

7. Regarding features b) and c) the appellant argues essentially as follows. The initial determination whether a caller has a license to exercise a desired right is a costly procedure (grounds of appeal, p. 3, last par.). According to D1, the caller can have the initial determination via lm_request_allocation executed early and perform only the supposedly less costly rights in spection via lm_query_allocation during program run-time. The two methods of D1 thus provide some "kind of asynch ronous processing" (grounds of appeal, p. 4, lines 14-16), and the claimed method via features b) and c) provides an alternative and non-ob vious way to avoid blocking of the calling program.

7.1 The board does not follow this argument. The claimed invention also requires an "information-retrie val" method for the inspection of a granted right (cf. pars. 87-94: SLGetInformation) which can be executed separa te ly and possibly long after the right-consump tion me thod. These two methods provide the same "kind of asyn chronous processing" which the appellant attributes to D1 and which thus cannot be identified with the claimed asynchronous processing of the right-consump tion method itself. Also, D1 does not disclose when precisely the method lm_request_allocation is called, except "before use of a licensed product or product feature" (col. 21, lines 55-57) which could be at any time during run-time of the caller. If it is costly to check for a license then a synchronously executing lm_request_allocation in D1 would block the caller in much the same way as the right-consumption according to the invention.

7.2 The board agrees with the decision under appeal that features b) and c) address the problem that the caller of lm_request_allocation may want to avoid blocking.

7.3 It is commonly known in the art that asynchronous pro cessing can solve this problem. Also D6 mentions this fact in general terms (p. 1, 1st par. in section "Asyn chronous Programming").

7.4 In the board's view it is also obvious for the skilled person to observe that some callers may be able to to le rate blocking (or prefer blocking to the synchro ni sation effort involved in asynchronous processing) while others do not. The board thus sees it as an obvious measure to enable the caller to choose it self whether or not lm_request_allocation should exe cute asynchronously.

7.5 The board concedes that there are several ways of im ple menting this functionality, but considers that the claimed implementation follows in an obvious manner from certain design decisions required from the skilled person.

7.5.1 First, the program developer will have to decide whe ther asynchronous processing should be an option for all methods or only for certain ones. D6 discloses a scheme applicable to any given method, while the inven tion supports asynchronous processing only for the in di vidual right-consumption method. The solution accor ding to D6 is more flexible since the method defini tions need not anticipate the possibility of asynch ro nous processing, while the invention provides a de di ca ted additional para meter to right-consumption just to support this possi bi lity. This flexibility of D6 how ever comes at the price of requiring a complex dedi ca ted library infrastructure. In the board's view, the choice between these alternatives according to circum stances is obvious for a person with the pertinent pro gramming skill.

7.5.2 Second, if only individual functions should be execu table asynchronously and this is to be supported by a de dicated parameter, there are further design decisions to make, such as what type such a parameter should have, where and when the asynchronous context (conventionally called a thread or a process) should be generated and whether that con text should remain available for later refe rence, for in stance in order to cancel it before termi na tion (see e.g. D6, CancelXXX as mentioned in the middle of p. 1).

The invention claims a specific solution, accor ding to which the context is created before the call to right-consumption and then passed to that function to request asynchronous execution (within that context). An alternative would be, for instance, to provide a Boolean argument to indicate that asyn chro nous processing is required but have the right-consumption method generate the context and return it to the caller for later reference. Other alternatives exist.

Each of these alternatives makes specific trade-offs between flexibility and simp li city of use for the caller and development effort on the side for the library developer. In the board's view, a person with the required programming skill would make such trade-offs as a matter of course.

7.6 The board therefore concludes that the independent claims of the main request would have been obvious over D1 for the person skilled in the art and hence do not comply with Article 56 EPC 1973.

7.7 In view of this result it can be left open whether, as the appealed decision argues (point 10.5), the claimed imple men tation de tails of the asynchronous processing have a technical effect and could, therefore, in principle con tribute to inventive step at all.

Auxiliary Request

8. Over claim 1 of the main request, claim 1 of the auxilia ry request adds the features that the calling computer program is notified whether the right can be exercised or not, and makes explicit that the right-consumption method checks (a) a binding of the license to a product key of a computer program, (b) a binding of a license to the system on which the computer pro gram is running, and (c) a validity that the right has not expired.

8.1 According to D1, the request for a license "returns a grant or denial status" (col. 21, lines 46-49). In the board's view this constitutes a notification as claimed.

8.2 D1 discloses that lm_request_allocation decides about the returned grant or denial status "based on the exis tence of an appropriate product use authorization" (col. 21, lines 49-50), which is defined (col. 7, lines 3-40) to relate inter alia to the used CPU (i.e. the system; col. 7, esp. lines 15-18; col. 16, lines 20-27; see al so col. 1, lines 59-64), the product iden ti fier (i.e. a "product key"; col. 24, see lines 28-32), and the va li dity of the requested right (see col. 12, lines 14-24).

8.3 Accordingly, the features added to the claim 1 of the auxiliary request are all known from D1 and thus insufficient to establish an inventive step over D1.

9. As there is no allowable request, the appeal must be dismissed.

ORDER

For these reasons it is decided that:

The appeal is dismissed.