T 1198/14 (Rights object acquisition/SAMSUNG) of 10.1.2017

Summary of Facts and Submissions

I. The appeal lies against the decision of the examining division, dispatched with reasons on 2 January 2014, to refuse European patent applica­tion No. 08 150 273.4 for lack of inventive step over the document

D1: US 2006/0053079 A1.

II. A notice of appeal was filed on 12 March 2014, the appeal fee being paid on the same day. A statement of grounds of appeal was received on 12 May 2014. The appellant requested that the decision be set aside and that a patent be granted on the basis of claims according to a main or one of two auxiliary requests as filed with the grounds of appeal, in combination with the description and drawing sheets on file.

III. In an annex to a summons to oral proceedings, the board, pursuant to Article 114(1) EPC, introduced documents relating to a standard which is mentioned in the description and which had been referred to during examination, in particular

D3: Open Mobile Alliance, "DRM Specification V2.0. Draft Version 2.0", 20 April 2004.

It informed the appellant of its preliminary opinion that the subject-matter of claim 1 lacked inventive step over D3, Article 56 EPC, and also raised objections under Articles 84 and 123(2) EPC.

IV. In response to the summons, with a letter dated 9 December 2016, the appellant filed amended claims 1-28 according to a main and a first auxiliary request, and claims 1-27 according to a second auxiliary request.

Claim 1 of the main request reads as follows:

"A rights object acquisition method performed by a mobile terminal (200) in a digital right management, DRM, system, in response to a group rights acquisition command corresponding to multiple DRM contents, the method comprising

generating and transmitting (S407, S910), a rights object acquisition protocol, ROAP, trigger request to a rights issuer, RI, server (250), wherein the mobile terminal (200) acquires multiple rights objects, ROs, using a uniform resource locator of the RI server, BatchRIURL, wherein at least one BatchRIURL is included in a header of a DRM content format, DCF, structure, wherein the RI server is for issuing multiple ROs in a composite manner;

receiving a ROAP trigger corresponding to the multiple DRM contents from the RI server in response to the ROAP trigger request, wherein the ROAP trigger is generated and sent from the RI server;

generating and transmitting (S415, S930) an RO request referencing at least one DRM content to the RI server (250) after receiving the ROAP trigger;

receiving an RO response containing at least one RO corresponding to the at least one DRM content from the RI server (250); and

acquiring (S419) the at least one RO for the at least one DRM content from the RO response."

Claim 1 of the first auxiliary request differs from claim 1 of the main request in that the first "receiving" step now reads as follows (the insertion being underlined):

"...

receiving a ROAP trigger containing a plurality of RO identifiers, roIDs assigned to the ROs corresponding to the multiple DRM contents from the RI server in response to the ROAP trigger request, wherein the ROAP trigger is generated and sent from the RI server;

...",

and in that the occurrences of "RO request" and "RO response" in the last three steps have been replaced by "RO request message" and "RO response message", respectively.

Claim 1 of the second auxiliary request reads as follows:

"A rights object acquisition method performed by a mobile terminal (200) in a digital right management, DRM, system, in response to a group rights acquisition command corresponding to multiple DRM contents, the method comprising

generating and transmitting (S407, S910), a rights object acquisition protocol, ROAP, trigger request including a plurality of content identifiers, CIDs, assigned to the multiple DRM contents to a rights issuer, RI, server (250), wherein the RI server for acquiring ROs is selected by the mobile terminal using a common uniform resource locator of the RI server, BatchRIURL, (1310) indicating an address of the RI server which is included in a header of a DRM content format, DCF, structure, wherein the RI server is for issuing multiple ROs in a composite manner and wherein transmitting an ROAP trigger request comprises:

transmitting the ROAP trigger request to the RI server (250) using a RI server address attached to at least one of the multiple DRM contents;

if the RI server has no multiple RO transmission capability, receiving from the RI server a redirection message including a new RI server URL; and

transmitting the ROAP trigger request to a new RI server with reference to the new RI server URL;

receiving a ROAP trigger containing a plurality of RO identifiers, rolDs, assigned to the ROs corresponding to the multiple DRM contents from the RI server in response to the ROAP trigger request, wherein the ROAP trigger is generated and sent from the RI server;

generating and transmitting (S415, S930) an RO request message containing the rolDs assigned to the ROs and referencing at least one DRM content selected by a user to the RI server after receiving the ROAP trigger;

receiving an RO response message containing at least one RO corresponding to the at least one DRM content from the RI server (250); and

acquiring (S419) the at least one RO for the at least one DRM content from the RO response message."

All three sets of claims also contain a second independent method claim setting out a method performed by a digital rights management, DRM, system ..."

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

Reasons for the Decision

The invention

1. The application relates, in the context of digital rights management DRM, to a protocol for obtaining "rights objects" RO for desired digital content.

1.1 More specifically, the application refers to the OMA DRM, "an open DRM standard invented by the Open Mobile Alliance", in particular in its version 2.0 (see page 2, line 12, to page 5, line 1, and figure 1b). It is stated that in the OMA DRM "each content is individually protected by one RO", and that the "RO acquisition process [...] is laborious and time-consuming", in particular when acquiring "mul­tiple RO objects", e.g. in order to extend their validity (page 4, last paragraph).

1.2 In view of this, the invention proposes a "more user convenient method that provides effective protection of content" (see sentence bridging pages 4 and 5).

1.3 The OMA DRM specifies a rights object access protocol ROAP, a modification of which according to the invention is illustrated in figures 4 to 10 (see also page 14, line 12, to page 18, line 17). A mobile terminal sends a "ROAP trigger request" message which lists the IDs of content items selected by the user (page 14, lines 16-20). The RI returns a "ROAP trigger" message, listing the IDs of the corresponding available ROs (hence also referred to as "roIDs"), including inter alia their respective costs (page 15, lines 4-13). The mobile terminal presents this list to the user (page 15, lines 15-17) to obtain his/her consent (see figures 4 to 8, nos. S413, S527, S613, S731, and S817 respectively). If the user does not approve the purchase at this point, the content selection and the ROAP trigger exchange may be repeated. If the purchase is approved, however, the mobile device requests and receives the desired ROs by issuing a suitable "RO request" message to and receiving a corresponding "RO response" message from the RI.

1.4 The RI server is identified by its URL, referred to as "BatchRIURL", which is packaged with the content in a file in a suitable "DRM content format" DCF (see figure 13). Several such URLs can be contained in one DCF and hence packaged with one piece of content (page 29, line 25, to page 30, line 1). Two pieces of content can be "acquired in a composite manner" if they share the same "BatchRIURL" (see page 30, lines 2-7).

1.5 Not all RI servers may have the "multiple RO transmission capability" proposed by the invention. If the selected content refers to an RI server which does not, this server will respond to an ROAP trigger request by returning to the mobile device a "redirection message" comprising the URL of an RI server which does. The mobile device will then automatically send a new ROAP trigger request to the latter RI server, without even informing the user (see page 35, 2nd paragraph, and figure 12).

The prior art

2. According to D3, users browse through a content portal and select content (see e.g. page 134, first bullet point, and page 135, item 1). The DCF files associated with the selected content identify the pertinent rights issuer (see page 24, section 5.2.2, paragraph 4).

2.1 On request by the user, the thus-identified rights issuer sends a ROAP trigger to the user's device to initiate the "ROAP protocol exchange" (see sections 5.1.6, 5.2 and 5.2.1; but also page 134, last two bullet points, page 135, items 3 and 4, and page 138, figure 22). The ROAP trigger contains one or more so-called roIDs (see page 23, line 10 in the code, and paragraph 3 in the text), based on which the user's device requests the desired ROs from the RI with an RO request message (which must contain all received roIDs, loc. cit., and section 5.4.3.1.1, item RO Info) and eventually receives them via an RO response message.

2.2 Before the RO request message is sent, it is determined whether the device is registered with the RI and hence whether a valid "RI context" exists. If not, user consent must be acquired, typically by performing registration and establishing a valid RI context at that point (see section 5.1.1, paragraphs 1 and 2, sections 5.1.2 and 5.1.6, section 5.2.1, page 23, last paragraph, section 5.2.2, page 135, sentence before the first bullet point, and page 136, sentence before point 5).

3. D1 discloses an online shop for digital content. The customer can tick items (e.g. digital music files, see figures 3a and 3b, and paragraph 64) in a list of media files available for purchase and move them into an online "shopping cart" (see e.g. figure 3a and paragraph 58). Also entire music albums can be selected (see figure 3b, item 345, and paragraph 66). Subsequently, the license corresponding to the selected media files is transmitted to a central server and to the customer's computer (see paragraph 62; e.g. right column, lines 6-12). D1 also discloses that a retailer server may redirect a first-time customer "to the central server [...] to obtain user registration information" or a registered user for login at "a web page associated with the central server" (see paragraph 59, lines 1-12), and that users may be "redirected" to a web page so that they can build their own web store there (paragraph 67, lines 1-4).

Clarity, Article 84 EPC, and

added subject-matter, A123(2) EPC

4. In the summons to oral proceedings, the board raised a number of objections under Articles 84 and 123(2) EPC. Some of these were addressed by the amendments filed with the letter of 9 December 2016. During oral proceedings, the issues of clarity and added matter were left open in favour of the discussion on inventive step.

Inventive step, Article 56 EPC

5. The appellant argued that "neither the scenario nor the respective solution" according to D1 was "comparable to the claimed invention", because the invention related only to the download of rights objects rather than media files, and because D1 did not "refer to requesting multiple rights objects" (see grounds of appeal, page 3, paragraph 2, esp. lines 6-8 and last sentence).

5.1 The board notes that none of the requests excludes the download of the media files. In fact, the user is only interested in the rights objects as a means to gain access to the content, irrespective of whether the rights objects are obtained earlier, later or at the same time as the content (see also D3, section 4, paragraph 3).

5.2 The board also notes that D1 discloses the selection of multiple content files and thus seems to also imply the download of multiple "media file licenses" (see e.g. D1, paragraph 62).

5.3 The board accepts, however, that the interaction between customer and online shop according to D1 is different from the claimed message exchange. In D1 the customer selects the desired content - and, implicitly, the desired media licenses - by interacting with an online shop at a server. In contrast, the invention requires that the user specify the desired content in a message (ROAP trigger request), to receive rights object identifiers in response (ROAP trigger), and only then to select, request and eventually receive a desired rights object (RO request, RO response) at the user's end.

5.4 The board agrees with the examining division that D1 is a suitable starting point for assessing inventive step of the present invention, but is also of the opinion that the claimed invention is more easily compared to the OMA DRM standard referred to in the application itself. The board thus decided to start its assessment of inventive step from document D3. In oral proceedings, the appellant expressed its agreement with that choice.

6. According to D3, a ROAP trigger may be generated in response to the user selecting content and an exchange of an RO request and an RO response message may follow (see section 5.1.6), possibly conditional on user consent being given at that point (see point 2.2 above).

6.1 Therefore, the central difference between the claimed invention and D3 - and indeed the only difference for the main and first auxiliary requests - is that it proposes a ROAP trigger request message that may comprise multiple content identifiers whilst the prior art only allowed the user to request individual pieces of content one by one.

6.2 The description states that "the RO acquisition process [...] when acquiring multiple ROs [...] is laborious and time-consuming", and the claimed method is meant to be faster and more convenient (see page 4, last paragraph, to page 5, line 1).

6.3 The board takes the view that, if it was perceived as "laborious" that separate message exchanges were required when multiple rights objects (for multiple pieces of content) were desired, it would be obvious for the skilled person to consider providing a "ROAP trigger request" message in the protocol according to D3 which could refer jointly to several desired pieces of content.

7. During oral proceedings, the appellant argued that the invention was particularly advantageous in scenarios such as the following one.

7.1 A user might select several pieces of content (100, say) and, on receipt of the corresponding list of roIDs, and especially in view of the price information contained therein, make an informed decision as to whether he/she wants to proceed with the purchase or instead to select a smaller number (10, say) of content items. According to the invention, this scenario would require a mere two ROAP trigger requests and ROAP trigger messages and two decisions by the user as to whether to approve the purchase, whereas in the prior art D3 it would require 110 ROAP trigger requests and ROAP trigger messages and the same number of purchase approval decisions by the user.

7.2 The board agrees that the invention saves a substantial number of messages and user decisions in such a scenario. However, the board takes the view that this is an immediate consequence of the proposed batch processing and, effectively, precisely the desired improvement in convenience and efficiency of the known method for which batch processing is, in the board's conviction, an obvious solution.

7.3 In summary, the board comes to the conclusion that claim 1 of the main and first auxiliary requests lacks inventive step over D3, Article 56 EPC.

8. Claim 1 of the second auxiliary request contains the additional feature that an RI server without the "multiple RO transmission capability" sends a redirection message with a new RI server URL to the mobile terminal.

8.1 In this regard, the appellant argued that the invention made it possible, during a transitional phase, that a mobile device operating according to the new protocol could obtain content associated with an RI server operating according to the old protocol.

8.2 The board agrees that the problem of servers which were not (yet) equipped to serve a newly introduced type of request would have arisen and had to be addressed. The board notes, in passing, that the invention does not allow the use of "old" servers without change. Rather, they have to be modified so as to produce the redirection message, if required.

8.3 At any rate, it would be obvious to enable "old" servers to interact with "new" mobile device. The rights issuer would, for commercial reasons, not want to lose a purchase and therefore want to suitably adapt the server software to "new" mobile devices in use.

8.4 If it was impossible or undesirable to upgrade any old server on the spot, it would have been obvious that any new ROAP trigger request had to be delegated to an already upgraded server. Simply returning the URL of such an upgraded server to the requesting mobile device and having it send a new ROAP trigger request to that server is, in the board's view, an obvious solution for the skilled person, in particular, being the smallest possible change for the old server.

8.5 The board therefore concludes that the subject-matter of claim 1 of the second auxiliary request also lacks inventive step over D3, Article 56 EPC.

Order

For these reasons it is decided that:

The appeal is dismissed.