T 1986/12 (Digital content distribution/APPLE) of 30.9.2015

Summary of Facts and Submissions

I. The appeal lies against the decision of the examining division, with reasons dated 23 April 2012, to refuse European patent application No. 07 075 884.2 for lack of inventive step of the main request over the document

D2: WO 02/01330 A,

and for lack of compliance with Article 123(2) EPC for two auxiliary requests.

II. A notice of appeal was filed on 22 June 2012, the appeal fee being paid on the same day. A statement of grounds of appeal was received on 3 September 2012. The appellant requested that the decision under appeal be set aside and that a patent be granted based on claims 1-12 accor­ding to a main request or one of four auxiliary requests filed with the grounds of appeal. The re­maining pending application documents were draw­ing sheets 1-10 and description pages 1, 8-10 and 13-17 as originally filed, pages 2, 5-7 and 11-12, as filed with the letter of 8 June 2009, and pages 3-4, filed with the letter of 4 November 2010. The second and third auxiliary requests were filed as fallback po­si­tions should the board confirm the decision with re­gard to the objection under Article 123(2) EPC.

III. In an annex to a summons to oral proceedings, the board set out its preliminary opinion. It tended to agree with the appellant that the main and first to third auxiliary requests complied with ­Article 123(2) EPC but raised objections under Articles 84 EPC 1973 and 123(2) EPC regarding the fourth auxiliary re­quest. As to inventive step, the board tended to share some of the appellant's objections against the interpretation of D2 in ­­the decision, but still tended to agree with the conclusion in the decision that the claimed in­ven­tion lacked inventive step in view of D2. The board also introduced a new document into the pro­ce­dure pur­su­ant to Article 114(1) EPC, namely

D3: Network Associates Inc., "An Introduction to Cryp­tography", Copyright 1990-2000, retrieved from (and avai­lable online, on the date of this decision, at) ftp://ftp.pgpi.org/pub/pgp/7.0/docs/english/

and raised an inventive step objection based on D3 and common knowledge.

IV. In response to the summons, with a letter dated 28 Au­gust 2015, the appellant filed a new set of claims accor­­ding to a fifth auxiliary request, intended to address the board's concerns concerning the fourth auxiliary request.

V. During the oral proceedings, which were held as scheduled on 30 September 2015, the appellant withdrew the second to fourth auxiliary requests.

VI. Claim 1 of the main request reads as follows:

"A method (600) for encrypting and downloading a media file for use at a local machine (112, 114) from a central server machine (102, 200) via a data network (108), the central server machine having user accounts for users of the system and each user account having at least one user key assigned thereto, the central server storing user keys for each of the users of the system, the central server being coupled to media storage (110) which stores a plurality of media files, said method comprising:

identifying (604) a media file from the plurality of available media files for purchase from the central server machine, each of the media files having at least media content data;

after access to the identified media file has been purchased through online interaction of the local machine with the central server machine (102, 200) via the data network;

retrieving (608) a user key from the user keys stored at the central server, the user key being associated with a user of the local machine, and the user key being assigned to the user account for the user of the local machine;

generating (612) a content key that is substantially random or pseudo-random;

encrypting (614) the media content data of the identified media file with the content key;

encrypting (616) the content key with the user key to produce an encrypted content key;

modifying (618) the identified media file to further include a user key reference and the encrypted content key, the user key reference allowing the local machine to locate the user key and;

downloading (620) the modified media file to the local machine of the user for storage."

Claim 1 of the first auxiliary request additionally states that there are a plurality of user keys for each user. The amended preamble now refers to "[...] the central server storing respective pluralities of user keys [...]", the amended retrie­ving step now specifies "[...] retrieving (608) a plurality of user keys from the user keys stored at the central server, the plurality of user keys being associated with a user of the local machine, and the plurality of user keys being assigned to the user account for the user of the local machine [...]", a step of "[...] selecting a user key from the plurality of user keys;" was added and the encrypting and modifying steps now refer to the "selected user key" instead of "user key".

In claim 1 of the fifth auxiliary request the selecting step reads as follows:

"selecting a user key, wherein the selection is based on cycling through the plurality of user keys;".

All three requests also contain, in addition to an inde­pendent claim 11 to a computer readable medium, an independent system claim 12 whose wording corresponds to that of the respective independent method claim 1. In particular claim 12 of the fifth auxiliary request specifies that

"[...] the central server is operable to: [...]

selecting [sic] a user key, wherein the selection is based on cycling through the plurality of user keys;".

VII. 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 to the secure de­li­very or dis­tri­bution of purchased digital media files, such as for music or videos, from a central server to a user at a local client machine (see description as originally filed, esp. paragraphs 1 and 2).

1.1 The central server provides "accounts" for the users of the system in which, inter alia, user keys are stored. The account of an individual user may contain several keys (see paragraph 38, page 9, lines 3-4 from the bottom).

1.2 Whenever a user purchases a media file, one of the user keys stored at (and retrieved from) the central server is selected. It is also disclosed that the "user keys can be ro­ta­ted (e.g., cycled) for improved securi­ty" (see paragraphs 48, 57 and 64).

1.3 Then, "after the user has selected [...] one of the user keys", a "random content key" is generated and used to encrypt the "media portion of the media file" (see para­graphs 49, 58 and 65). The random key itself is encryp­ted with the selected user key and included in the media file trans­mitted to the user, together with a "user key reference" (see paragraphs 50, 59, 66 and 70).

1.4 The user, in order to utilize the media file on the client machine, needs "the appropriate user key", and "the user key reference allows the user key to be lo­cated" (see paragraphs 51, 60, 68 and 70, and figure 7, Nos. 708 and 716). Eventually, the encryp­ted random key is "decrypted with the user key" so-ob­tained and then used to decrypt the media file (see paragraph 72).

Claim construction

All requests, symmetric or asymmetric encryption?

2. According to claim 1 of the main request, "a user key" is retrieved and "the user key" is used to encrypt the content key. Included in the "modified media file" to be downloaded is "a user key re­ference" which is speci­fied as "allowing the local machine to locate the user key". Claim 1 does not detail what it means to "locate the user key" and how, having located the key, decryp­tion takes place.

2.1 During oral proceedings, the appellant argued that, accor­ding to claim 1 of the main request, the user keys had to be symmetric encryption keys because the user key re­fe­rence allowed the local machine to locate "the" same key that was used for encryption, thus implying that that key was used for decryption. In this context, the appellant referred to figure 7 and the correspon­ding de­scription of the de­cryption opera­tion, and ar­gued that they taught the skilled person without doubt that the decryp­tion key had to be the same as the en­cryp­tion key. In this context, the appellant stressed that the disclosure of the decryp­tion operation had to be read in the con­text of the entire application and that the description of the decryption operation expli­cit­ly referred back to the encryption operation (see, in particular, paragraphs 70, "As previously noted [...]" and 72, "Again, [...]").

2.2 The board is not convinced by this argument and takes the view that the skilled person would interpret the "user key reference" as an identifier distin­guishing one user key from other possible ones and ipso facto allowing it to be identified when needed. The board further takes the view that this does not imply symme­tric en­cryp­tion. Rather, any "user key reference allow­ing the local machine to locate" an encryption key would also be suitable for locating the decryption key when using asymme­­tric encryption. For example, if the user key reference were "5" and meant to identify (lo­cate) the fifth of ten public keys known for that user, the reference "5" would also identify (locate) the corres­ponding private key as the appropriate decryption key.

2.3 The board therefore concludes that claim 1 of the main request leaves open whether the user keys are symmetric or asymmetric keys.

2.4 The board considers that this assessment also applies to the auxiliary requests which specify that the user key reference allows "the local machine to locate the selected user key".

3. This interpretation is consis­tent with the description as a whole which, in the board's judgment and contrary to the appellant's asser­tion, does not imply that the user keys are symmetric encryption keys. With reference to the encryption pro­cess, the descrip­tion refers to "a user key reference" without defining it further (see, e.g., paragraph 50). It is with regard to the decryp­tion process only that the user key refe­rence is ex­plained further. It is specified that, for decryption, "the appropriate user key will be needed" and it is that key, i.e. the key appropriate for decryption, that the user key reference permits locating (see, e.g., para­graph 51). Likewise, in paragraph 70 it is dis­closed that "[A] user key is [...] located [...] in the client machine [...] based on the user key re­ference". This need not be, in the board's opinion, the encryp­tion key but could also be a pri­vate de­cryp­tion key. Also, the fact that figure 7 refers back to the pre­ce­ding en­cryption is in­sufficient to im­ply symmetric en­cryption. The encryp­tion and de­cryp­tion operations are linked by the user key reference even if the same refe­rence may iden­tify different, albeit corresponding, keys in the two opera­tions.

Fifth auxiliary request, cycling through user keys

4. The description states that "one of the user keys is selected" and that "[T]he user keys can be rotated (e.g. cycled) for improved security" (see, e.g., para­graph 48).

4.1 Neither "rotating" nor "cycling" is defined in the application. The board understands the description to suggest (by using "e.g.") that cycling is a special instance of rotating, but it does not explain in what way the meanings of these terms differ.

4.2 The phrase "the user key is selec­ted" leaves open whe­ther the key is selected by the user or the system. Elsewhere the description discloses at least the option of selection being done by the user (e.g. paragraph 49). This fact raises the question of how the "cycling" feature is to be construed in the context of the claims. For instance, if cycling were achieved by the user making choices according to a pre­scribed security policy, but without any system support, then the selected key would, from the system perspective, be just any key and the cycling step would not imply any system feature. One might thus find that system claim 12 is unclear due to its reference to the cycling. This issue was raised during oral proceedings but was not further pursued in view of the board's conclusion on inventive step.

4.3 In the board's view the skilled person would interpret the cited passages as specifying that the user keys are selected in some cyclic order but leaving open how this is achieved and by whom.

The prior art

5. D2 also discloses a system for protecting pur­chased digi­tal content, in particular electronic books, de­li­vered from a server to a customer to a client computer (see, inter alia, page 6, line 19, to page 7, line 3). It is disclosed that, according to the cir­cumstan­ces, different security levels may be required (see page 7, line 22, to page 9, line 5). One of these levels, re­ferred to as "fully individualized" or "owner exclu­sive" (see page 8, lines 28-29), ensures that content can only be opened by a particular user (page 8, line 30, to page 9, line 1). It is also disclosed that pub­lic key encryption may be used to achieve this effect (see, e.g., page 9, lines 19-21; page 32, lines 18-24).

6. D3 explains some of the background of the popular cryp­to­­system PGP in its version 7.0 (see 2nd page). PGP has made cryptography services available to a broad pub­lic since its creation in 1990.

6.1 Although the copy­right date (1990-2000) of D3 does not constitute a definitive publication date, the board is satisfied that D3 was made available to the public be­fore the present priority date in 2003. This was sta­ted in the annex to the summons to oral proceedings and not challenged by the appellant.

6.2 PGP is based on asymmetric (i.e. public key) encryption in combination with one-time only session keys (see D3, pages 16-18). That is, for each communication session, a (pseu­do-)ran­dom session key is generated (see also page 46, first three paragraphs) which is used to en­crypt the ex­changed messages. The session key itself is exchanged using the receiver's public/private key pair.

6.3 PGP also provides support for one user having multiple private keys (and thus multiple key pairs; see page 19, 3rd paragraph).

Inventive step

7. The board agrees with the decision under appeal that D2 is a suitable starting point for assessing inven­tive step.

8. However, rather than starting from an individual detailed embo­diment of D2, the board prefers to start from the gene­ral context described in D2, namely a client-ser­ver ar­chitecture for the purchase and distribution of digital media content, i.e. an online shop. D2 also discloses user accounts (see page 45, Users Table) which are, how­ever, also commonly known.

8.1 In such a context, the claimed invention constitutes an "approach [...] that provides users the ease and con­ve­nience of downloading media files, while at the same time provides [sic] a secured and controlled environment to protect copyright holders' rights to the content con­tained within the media files" (see the present appli­ca­tion, para­graph 5).

8.2 This idea is, in the board's view, well-known in the art and also disclosed in D2.

8.3 The board therefore considers that the objective techni­cal problem solved by the invention over the online shop known from D2 can be seen as implementing secure delivery of digital content.

8.4 The board appreciates that D2 discloses solutions for this problem. This would however not prevent the skilled person from seeking a simpler solution than those disclosed in D2, or simply an alternative.

9. For the online shop, D2 spe­ci­fically mentions the idea of owner-exclusive delivery of con­tent. The skilled person would thus consider implemen­ting this idea in particular.

9.1 Public key encryption was introduced inter alia to achieve just that: owner-exclusive delivery of messa­ges. And PGP is a well-known and widely used tool im­plemen­ting public key encryption.

9.2 It would thus have been obvious for the skilled person to consider using PGP to solve the problem posed.

9.3 The appellant has argued that the skilled person would not consider using PGP for the download of purchased media files because it was devised for secure private commu­ni­cation, i.e. for the exchange of private text messa­ges.

9.4 The board agrees that this was the historical back­ground that led to the introduction of PGP (see D3, chap­ter 2, starting on page 39). However, also private messages may contain media content, and media files may vary conside­rably in size. The board is thus not con­vinced that the skilled person would limit the use of PGP to certain applications or types of content as a matter of prin­ciple in view of the history of PGP; nor has the appellant convinced the board that there are any tech­nical properties of PGP which would imply such a limi­tation.

10. By using PGP in the given context, the skilled person would have arrived at the invention without the exercise of an inventive step.

10.1 The use of PGP for owner-exclusive delivery requires the sender, in the given context the delivery server, to encrypt the content with the receiver's public key. Hence the key must be available via the user's identity and thus via the information available in the user accounts of the online shop. The board con­siders that the user's public keys are, in the terms of the claim and on a broad reading, "assigned" to the user accounts. For ease of accessibility, however, the board also regards it as obvious to store the users' public keys in their respective accounts (as is also done in D2; see again page 45).

10.2 PGP will then, for each communication session, generate a "session key" which, in the board's view, constitutes a "content key" as claimed. Furthermore, the public key with which the session key is encrypted qualifies as a user key as claimed.

10.3 The appellant has argued that the claimed content key is not a "session key" in the sense of PGP because, according to the invention, the encrypted media files are meant to be permanently stored on the user's local hard disk so that the content key remains necessary for long after the communication "session" discussed in PGP. The board does not accept this argument for three reasons. Firstly, the claims do not specify that the user permanently stores the encrypted media files. Claim 1 only specifies that the data is downloaded "for storage" but not whether the storage actually takes place and whether the intended storage is temporary or permanent. Secondly, it may also be necessary to retain the "session key" of PGP after the communication session, if users of PGP keep encryp­ted messages in their mail boxes. And thirdly, the application does not disclose or even hint at the encryption method being adap­ted for long-term storage, if desired.

10.4 The appellant's further argument that the user's public key cannot be the claimed user key because the latter must be a symmetric key did not convince the board, as explained above.

11. The use of PGP for delivering digital content in a client-server system thus covers all features of claim 1 of the main request except the use of a user key reference.

11.1 In the board's view, it is only useful to include a user key reference in the media file if "locating" the "appro­­priate key" is not implicit anyway, for example due to the fact that each user has only one key or key pair. If, on the other hand, there is a choice of en­cryption keys, then the receiver needs to know which key to use for decryption. The user key refe­rence is an indica­tion to this effect and thus allows the flexible use of several keys per user.

12. The board considers it obvious for users to wish to have several keys or key pairs.

12.1 For example, it may be desirable for the user to have keys of different lengths to balance efficiency and se­cu­rity of encryption against each other, depending, for instance, on the value of the purchased goods or on legal require­ments. For instance, a short key might be prescribed for a purchase when shop and customer are located in different jurisdictions, while a long key might be allowed when the same customer is in the same jurisdiction as the shop. It is also noted that PGP an­ticipates the possi­bility of users having several pri­vate keys at the same time (see D3, p. 18, 3rd para.).

12.2 If mul­tiple keys are available for an indivi­du­al user, then one of them must be "selected", and it is obvious to make the selection result known to the receiver so that the media content can be decrypted.

12.3 Hence the board considers that it would have been obvious to include a "reference" in the downloaded file to "allow[] the local machine to locate the [pertinent] user key".

13. Summarizing, the board finds that claim 1 of the main request lacks an inventive step over D2 in combination with D3, Article 56 EPC 1973.

First auxiliary request

14. The feature added to the independent claims details the selection of a user key from a plurality of user keys. This aspect is covered by the above discussion, so that the assessment of the main request also applies to the first auxiliary request.

Fifth auxiliary request

15. The feature added to the independent claims of the fifth auxiliary request is that the user keys are selected by cycling through them. This feature is not disclosed in either D2 or D3.

15.1 According to the problem-solution approach, the board has to determine the effect of this difference.

15.2 The description states, without further explanation, that this may be done "for improved security". During oral proceedings, the appellant explained that, due to the use of several keys, one compromised key gives access only to some but not all protected media files.

15.3 The board agrees that this is one possible advantage of using several keys. However, this effect is achieved by changing the keys, whereas the reuse of earlier keys as implied by the claimed cycling does not contribute to this effect but, in fact, limits it.

15.4 The board considers that changing keys is an obvi­ous measure to reduce the damage of losing one key (spread the risk, don't put all your eggs in one basket). The board notes that the session keys themselves are an in­stance of the general idea of avoiding the repea­ted use of the same key.

15.5 In theory, the security gain would be maximal if no key were to ever be reused. This, however, would obviously require that new keys be generated every once in a while. The generation of new keys requires compu­ta­tio­nal effort and may involve a third party (a certifi­ca­tion autho­ri­ty). New keys need to be exchanged, which causes addi­tio­nal effort and is a security risk in it­self. Moreover, an old key cannot be deleted as long as there is data en­crypted with it. At some point, this might become a problem of limited me­mory space. There­fore, the board regards it as obvious for the skilled person that the continuous need to gene­ra­te new keys is a nuisance.

15.6 The skilled person would therefore seek a trade-off between changing the user keys and having to gene­rate too many new keys and, in the board's view without exer­cising an inventive step, provide a limited number of keys and change amongst them. This idea does not itself imp­ly "cycling", since, for example, the user key could always be selected randomly from the avai­lable ones. Nonetheless, the skilled person would find cycling through the user keys an obvious way to imple­ment the mentioned trade-off.

15.7 Therefore, the board concludes that also claim 1 of the fifth auxiliary request lacks an inventive step over D2 and D3, Article 56 EPC 1973.

Order

For these reasons it is decided that:

The appeal is dismissed.