T 2164/19 (Single content list/SAMSUNG) 21-06-2022

1. MAIN REQUEST

1.1 Claim 1 - inventive step starting out from D1 (Article 56 EPC)

1.1.1 Using the wording of claim 1, document D1 discloses (board's outline):

A method for sharing content of a user between a computer ("user's desktop computing device"; FIG. 1) and a mobile handset ("the client device 110"), comprising:

(a) storing, on the computer, a plurality of pieces of content of the user ([0110]: "... a host device 108 includes one or more pre-existing host applications 122 with information (or data), such as one or more media collections ... ");

(b) displaying, [deleted: in a single list] on the mobile handset, one or more pieces of content stored on the mobile handset (Fig. 7: "Dance", "80's music", "Jazz vocalists", "Latin") and the plurality of pieces of content stored on the computer (Fig. 7: "Vic's Work PC - Favorite Pics");

(c) requesting a piece of content stored on the computer and displayed on the mobile handset ([0115]: "... the host application may respond to other actions requested by the client application such as, for example, to retrieve a specific media file to be downloaded to the client device 110");

(d) storing the requested piece of content on the mobile handset ([0115]: "... and placed in storage memory on the client device by the client application ..."),

(e) [deleted: in the single list], the one or more pieces of content stored on the mobile handset are visually distinguished from the plurality of pieces of content stored on the computer (Fig. 7: "Vic's Work PC - Favorite Pics").

1.1.2 The subject-matter of claim 1 thus differs from D1 solely in that

A) the content is displayed in a single list on

the mobile handset (i.e. features (b) and (e)).

1.1.3 With respect to feature (b), the appellant submitted that it was not directly derivable from D1 that Fig. 7 showed an interface designed to concurrently show lists of content accessible via various directories and libraries. On the contrary, in D1, as shown in Fig. 7, the user had to navigate through different screens, each corresponding to a different folder or category. Rather than browsing a single list of individual items, if the desired item did not exist in the chosen source, the user had to go back to the preceding screen(s). Thus, D1 did not disclose "displaying [...] one or more pieces of content stored on the mobile handset and the plurality of pieces of content stored on the computer". The conjunction "and" in the claim clearly underlined that displaying the different pieces of content was performed at the same time. In D1, it was simply disclosed that either entries from the host device 108 (i.e. "Vic's Work PC"; cf. middle screen in the second row of Fig. 7) or entries from the client device 110 (i.e. "Favorites"; cf. right screen in the first row of Fig. 7) were shown. It was not even clear whether the entries from "Vic's Work PC" were still to be downloaded to the client device or had been already synchronised and locally stored. In addition to that, the categories shown in Fig. 7 of D1 could not be mapped to the claimed "piece of content". This interpretation was different from the consistent disclosure throughout the description of the present application. In the sense of the present application, content referred to a "file" (having a certain format or file name extension such as "*.mp3"), e.g. a video file or an audio file.

1.1.4 The board does not find these arguments persuasive, for the following reasons:

First, there is no reason to consider that the wording of feature (b) requires a simultaneous display of pieces of content stored on the mobile handset and pieces of content stored on the computer. Although a claim should generally be interpreted on the basis of its wording alone, such a limitation cannot be derived from the embodiments of the description either. For instance, it is apparent that screen 60 of Fig. 4 of the present application need not fit all the digital content at once. Rather, as the user browses through the list, some individual items will appear while others disappear. It could even happen that, on a given screen and as the user browses through, only pieces of content stored at the same place are shown.

Second, the appellant narrowly interprets a piece of content as a "file" corresponding to a song title, in line with the example of Fig. 4 of the application. However, the wording piece of content as it appears in claim 1 also encompasses a category or a playlist comprising one of more individual titles (be it songs, videos or pictures). On this interpretation, the different categories of content appearing in Fig. 7 of D1 already disclose one or more pieces of content. Moreover, paragraph [0115] of D1 unambiguously discloses that the client application may request the retrieval of a specific media file to be downloaded to the client device from the host device. "Vic's Home PC" and "Vic's Work PC" in Fig. 7 of D1 are examples of such host devices.

1.1.5 With respect to feature (e), the appellant submitted that the content stored on the mobile handset in D1 was "visually distinguished" from the content stored elsewhere by virtue of the name of the source and/or the "Source" menu item. However, the source (e.g. "Vic's Work PC" in bold in one of the screens of Fig. 7 of D1) was not content in the claimed sense.

1.1.6 This argument is not convincing either. Although in some embodiments of the description the visual distinction is achieved through the use of either gray or black text for each piece of content depending on where the content is stored (see e.g. Fig. 4), the broad expression "visually distinguished" as claimed encompasses any possibility that enables the user to identify the source of the content through visual inspection. This includes showing the content "Favorite Pics" under the heading "Vic's Work PC" as in the middle screen in the second row of Fig. 7 of D1. Hence, present claim 1 is indeed distinguished from the disclosure of D1 solely by feature A).

1.1.7 The subject-matter of claim 1 does not involve an inventive step (Article 56 EPC) starting out from D1 for the following reasons:

Distinguishing feature A) relates exclusively to the manner in which available content is presented to the user (i.e. to "how" it is presented rather than to "what" is presented). Such a feature can only be considered to produce a technical effect if it credibly assists the user in performing a technical task by means of a continued and/or guided human-machine interaction process (see T 1802/13, Reasons 2.1.5). In this particular case, the cognitive content (i.e. the "what") presented to the user is the same as in D1 (e.g. available content and storage location), whereas the "how" (i.e. "a single list") cannot be considered to resolve any conflicting technical requirements, given that the claim does not even impose any particular limitation with respect to the characteristics of the display (like its size) of the mobile handset. It follows that the technical effect asserted by the appellant ("more efficient management of content stored on different devices") cannot be credibly achieved by the content being displayed "in a single list", which is rather to be regarded as a layout of information aimed exclusively at the human mind and devoid of any technical contribution.

In other words, merely presenting certain content on a device screen in the form of a "single list" rather than by means of distinct screens through which a user may navigate does not credibly assist the user in performing a technical task by means of a continued and/or guided human-machine interaction process. Thus, the question whether a user may retrieve the desired piece of content in an easier and faster way on the basis of distinguishing feature A), as invoked by the appellant, depends on the particular user's personal preferences and skills in using a respective GUI. As such, they are related to user preferences and/or the look-and-feel design of the user interface (cf. T 1579/07, Reasons 12.1), rather than credibly providing device-specific and performance-oriented technical improvements as to the efficient implementation of the underlying GUI of the electronic device.

1.1.8 The appellant submitted the following arguments in favour of the presence of an inventive step:

i) The distinguishing features synergistically contributed to the solution of one and the same objective technical problem ("more efficient management of content stored on different devices") and thus might not simply be assessed separately from one another with respect to their isolated contribution to the solution of the aforementioned objective technical problem (see Guidelines for Examination, G-VII, 6 and T 389/86).

ii) The underlying invention fulfilled the criteria of a "graphical shortcut" as described in the Guidelines, G-II, 3.7.1. In a situation in which a user did not remember the location of a piece of content but its title (for whatever reasons), the underlying invention objectively provided an advantage, presenting merely the titles of the pieces of content in a single list and indicating the respective location of a piece of content by visually distinguishing them. The user only had to scroll down rather than going back and forth. The underlying invention required much less user interactions to retrieve the content.

iii) The indication where in the system which content was stored should "relate to an internal state prevailing in the system" in the sense of the Guidelines for Examination, G-II, 3.7.

iv) The main concept in D1 was completely different. The person skilled in the art had no motivation to entirely disrupt the "directory structure/logic" (having specific content at a specific storage location) described in D1 when trying to solve the objective technical problem.

1.1.9 The appellant further argued that the skilled person starting out from D1 and tasked with the problem enounced in point 1.1.8 i) above would not arrive at the claimed solution because they would not depart from the underlying "folder-based approach". The five screenshots shown in Fig. 7 of D1 pertained to different situations in which different data sources had been selected. Furthermore, D1 required that a certain source PC/host device 108 be explicitly selected in order to view or obtain folders/categories from such source. This clearly underlined the "source separation-based approach" of D1 and rather led away from a solution in which actual contents from two different data sources were (simultaneously) displayed in a single list and visually distinguished from each other.

1.1.10 These arguments are not persuasive, for the following reasons:

On the one hand, "visually distinguishing" the content according to the location where it is stored, which could arguably relate to a technical condition of the system, is already disclosed in D1 (see point 1.1.6 above).

On the other hand, even assuming arguendo that, in line with allegations i) to iii), a technical effect was achieved by displaying a "directory structure" as a "single list", the person skilled in the field of graphical user interfaces (GUIs) starting out from D1 would consider the introduction of a single list in accordance with the circumstances (e.g. number of items, display characteristics) as a straightforward design option (e.g. the so-called "tree view") in the exercise of what is considered customary practice. Contrary to the appellant's allegation, a single list is not inherently incompatible with a folder-based approach. A fully-expanded tree can also be scrolled as a single list. This argument is valid even if "piece of content" is considered in the more limited sense of a file corresponding to a song title, given that Fig. 7 read in combination with paragraph [0148] of D1, indicating that

"... the displays may be configured in a similar fashion to many MP3 players currently available in the market and include additional options to select source PC (or host device 108) and-content [sic] types ...",

at the very least strongly suggests listing content at the song-title level, as it was customary for MP3 players at the application's priority date.

1.2 Hence, the main request is not allowable under Article 56 EPC.

2. FIRST AUXILIARY REQUEST

Claim 1 of the first auxiliary request comprises the same limiting features as claim 1 of the main request, except for the following additions (board's outline and emphasis):

(f) receiving a selection of a piece of content being displayed in the single list from a user;

and the following modification in feature (c):

(c) requesting [deleted: a] the selected piece of content stored on the computer and displayed on the mobile handset.

2.1 Claim 1 - inventive step starting out from D1 (Article 56 EPC)

2.1.1 Features (f) and (c) are also disclosed by D1 (see paragraph [0148]: "... A 5-way button currently found on most cell phones (depicted in Fig. 7 as button 702 with various options such as scrollup, scrolldown, back, play/pause and select) may serve as a primary control for the client device 110 ..."; emphasis added). Hence, the subject-matter of claim 1 does not involve an inventive step for the same reasons as set out in point 1.1 above.

2.1.2 In that regard, the appellant merely submitted that the subject-matter of claim 1 of the first auxiliary request did further extend and clarify the actual interaction between the user and the mobile headset, and that what had been mentioned with respect to the main request should also be valid with respect to the first auxiliary request.

2.2 It follows that the first auxiliary request is likewise not allowable under Article 56 EPC.

3. SECOND AUXILIARY REQUEST

Claim 1 of the second auxiliary request comprises all the limiting features of claim 1 of the main request and the following additions (board's outline and emphasis):

(g) streaming the requested piece of content to the mobile handset,

(h) the requested piece of content is downloaded as a plurality of segments,

wherein streaming the requested piece of content to the mobile handset further comprises

(g1) downloading a first portion of the plurality of

segments into a first buffer;

(g2) playing the first portion of the plurality of

segments contained in the first buffer;

(g3) downloading, while the first portion of the

plurality of segments contained in the first

buffer is being played, a second portion of the

plurality of segments into a second buffer so that

the plurality of segments of the piece of content

are streamed to the mobile handset while

minimizing silence gaps.

3.1 Claim 1 - inventive step starting out from D1 (Article 56 EPC)

3.1.1 Features (g), (h), (g1) and (g2) are already disclosed by D1 in at least paragraph [0021], which reads:

"... the media content being downloaded and saved may also be buffered so that it can be played

and/or viewed as it is still in the process of being downloaded, if so desired by the user ...".

3.1.2 Hence, the subject-matter of claim 1 now differs from D1 in that:

A) the content is displayed in a single list on

the mobile handset (i.e. features (b) and (e));

B) the second portion of the plurality of segments into

a second buffer (i.e. feature (g3)).

3.1.3 However, the subject-matter of claim 1 does not involve an inventive step (Article 56 EPC) starting out from D1 for the following reasons:

3.1.4 It was uncontested that distinguishing features A) and B) are related to two distinct technical problems ("partial problems") which could be solved independently of each other ("juxtaposition"). Therefore, the assessment of their contribution to inventive step can be conducted separately.

3.1.5 With respect to difference A), no credible technical effect can be ascribed to this feature (see point 1.1.7 above), nor does any particular synergy result from its combination with the "double buffering" scheme as proposed in feature (g3).

3.1.6 As to difference B), the board has no doubt that, in D1, the "buffering" of paragraph [0025] and the transmission "in streaming fashion" of paragraph [0121] necessarily involve downloading a second segment of the media content while a first segment is being played. However, D1 does not provide details as to how many buffers are required for this purpose.

3.1.7 The appellant formulated the objective problem associated with feature (g3) as "how to allow in D1 the consumption of content which is not yet fully available". To the extent that the term streaming implies the reproduction of content that is

not-yet-fully-available at a client device, the board finds this problem equivalent to the problem of "how to implement the streaming at the client device of D1".

3.1.8 Yet, the claimed solution does not involve an inventive step (Article 56 EPC):

At the application's priority date, both "progressive downloading" and "double buffering" (see e.g. paragraphs [0024] and [0025] of the present application), were well-known buffering techniques to be used at a client device for streaming. When the first one is used, a single buffer suffices, but it must support simultaneous read-and-write operations. The second one requires two separate buffers which, in return, do not need to support simultaneous

read-and-write actions. The skilled person would have been well aware of the advantages and drawbacks associated with each of the options at the application's priority date. This was not contested by the appellant. It follows that the skilled person starting out from D1 and being confronted with the objective technical problem of implementing the streaming at a client device would have selected either of the known techniques in accordance with the specific circumstances (e.g. hardware and speed requirements), arriving thereby at the introduction of feature (g3) into the system of D1 without the involvement of any inventive skills.

3.1.9 The appellant argued that, whilst it might be true that "buffering" is generically mentioned in paragraphs [0025], [0038], [0099] and [0167] of D1, this document failed to disclose any hint towards "double buffering" techniques, as required by claim 1. Furthermore, the disclosure of D1 failed to bring the mentioned buffering into a context with the GUI as shown in Fig. 7 of D1. It was not correct to consider paragraphs [0024] and [0025] of the application to set a starting point for the objective technical problem in view of D1. The skilled person starting out from D1 would have used "progressive downloading". It was the most convenient approach, there would have been no incentive whatsoever to implement a more complex solution like "double buffering".

3.1.10 The board disagrees. Admittedly, paragraphs [0024] and [0025] of the present application explain that "progressive downloading" is indeed a straightforward measure. However, they also state that it cannot be used "if the mobile handset does not support progressive downloading (which is the case for most mobile handsets such as mobile phones)". Given that D1 explicitly mentions that the client device can be a cell phone (see e.g. paragraph [0138]), the skilled person would have identified the same drawback when implementing streaming at a cell phone in D1, thus being naturally led in this case to the known alternative of "double buffering" without the involvement of any inventive skills.

3.2 It follows that the second auxiliary request is not allowable under Article 56 EPC either.

4. THIRD AUXILIARY REQUEST

Claim 1 of the third auxiliary request comprises all the limiting features of claim 1 of the main request and the following additions (board's outline and emphasis):

(i) playing a first piece of content on the mobile handset, wherein the first piece of content is being streamed to the mobile handset as a plurality of segments into a first and second buffer,

(j) downloading, while the first piece of content is being played from the first buffer, a second piece of content in a list of contents into a second buffer,

(k) playing the second piece of content in the second buffer when the second piece of content is already downloaded to the mobile handset so that the second piece of content does not have silence gaps when the same is played.

4.1 Claim 1 - inventive step starting out from D1 (Article 56 EPC)

4.1.1 Features (i) to (k) refer to the existence of a separate ("second") buffer used for pre-fetching a second piece of content, while a first piece of content is being played from "the first buffer". D1 anticipates in paragraph [0099] the use of "... read-ahead (or preload) buffering and caching techniques which permits songs to be downloaded before they need to be played and stored ..." and proposes in paragraph [0142] that "... a client application may cache favorite songs and pre-fetch songs in the active playlist into a media player's memory ...".

4.1.2 The appellant indicated that features (g3) and (i) to (k) avoided silent gaps in-between content items and formulated the corresponding objective technical problem now as "how to allow in D1 the consumption of content which is not yet fully available considering a plurality of content items". Since the plurality of content items can be assimilated to a playlist in D1, the board finds this problem equivalent to the problem of "how to implement the streaming of a playlist at the client device of D1 considering multiple content items".

4.1.3 However, D1 explicitly discloses the streaming of content based on a playlist (see e.g. Fig 4: "New Media Content directly streamed to phone based on playlist link ..." and paragraph [0114]: "... media and other information, such as playlists (and other indexes) of the media, may be transmitted (preferably in streaming fashion) to one or more authorized users ..."). The use of a second buffer to preload a song, while the preceding one is still being played, is a straightforward extension of the "double buffering" scheme for the case where the content to be played comprises a series of pieces (e.g. in a "carousel-mode") rather than a single piece (see also point 3.1 above).

4.1.4 The appellant submitted that D1 only disclosed that a song might be locally stored after a complete download, namely in order to allow a playback of it even in situations without network coverage. This process of locally storing the song was rather referred to as "pre-fetching" or "caching". However, this text passage had nothing to do with "double buffering" either. "Double buffering" was a completely different technique, which allowed to stream content while the same is still being downloaded. The claimed solution, i.e. alternately downloading pieces of content into different buffers and playing a piece of content from the buffer to which no download is ongoing, was clearly not disclosed or suggested in D1.

4.1.5 The board is not persuaded. D1 discloses preload in the context of a complete download of the items of a playlist (e.g. the "large cache of preloaded songs" of paragraph [0099] of D1) as well as in the context of the streaming of a playlist (e.g. the "small preload buffer" of paragraph [0099] of D1).

4.2 Hence, the third auxiliary request is likewise not allowable under Article 56 EPC.

5. FOURTH TO SIXTH AUXILIARY REQUESTS

5.1 Claim 1 of the fourth auxiliary request is identical to claim 1 of the second auxiliary request. Hence, it is likewise not allowable under Article 56 EPC (see point 3.1 above).

5.2 Claim 1 of the fifth auxiliary request is identical to claim 1 of the third auxiliary request. Hence, it is likewise not allowable under Article 56 EPC (see point 4.1 above).

5.3 Claim 1 of the sixth auxiliary request is identical to claim 1 of the main request. Hence, it is likewise not allowable under Article 56 EPC (see point 1.1 above).

6. Since there is no allowable claim request, the appeal must be dismissed.