T 0505/13 (Adaptive web browser/NOKIA TECHNOLOGIES) 06-06-2018
Download and more information:
An adaptive web browser
Amendments - added subject-matter
Amendments - main request and second auxiliary request (yes)
Amendments - third auxiliary request (no)
Inventive step - third auxiliary request (yes)
I. The applicant (appellant), which at the time was Nokia Corporation, appealed against the decision of the Examining Division to refuse European patent application No. 03712163.9, which was filed as international application PCT/FI03/00220 and published as WO 03/085553. The Examining Division found that the subject-matter of claim 1 of the main request was not inventive and that of claim 1 of the auxiliary request extended beyond the content of the application as originally filed.
The subject-matter of claim 1 of the main request was considered to lack inventive step over the prior-art network browser acknowledged in the application. The following document was among those cited during the examination proceedings:
D2: Henricksen, K. et al.: "Adapting the Web Interface: An Adaptive Web Browser", Proceedings of the Second Australasian User Interface Conference AUIC 2001, Gold Coast, Qld., Australia, pages 21 to 28, 29 January to 1 February 2001.
II. With effect from 18 June 2015, the EPO registered a transfer of the application to Nokia Technologies Oy, which thereby acquired the status of appellant.
III. In the statement of grounds of appeal, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of a main request or of one of four auxiliary requests, all five requests filed with the grounds of appeal. The third auxiliary request essentially corresponds to the main request considered in the contested decision.
IV. In a communication accompanying a summons to oral proceedings, the Board introduced into the proceedings copies of the following documents illustrating web technology commonly known at the date of priority of the present application:
D4: Wikipedia: "Web browser", 25 March 2002;
D5: Wikipedia: "Internet Explorer 5", 30 December 2017;
D6: "Guide to What's New: Netscape Communicator", retrieved from http://web.archive.org/web/19961230204630/http://www.netscape.com/comprod/products/communicator/guide.html, 30 December 1996.
The Board questioned whether the main request should be admitted into the proceedings and expressed its preliminary opinion that the subject-matter of claim 1 of each of the requests was not clearly defined and extended beyond the content of the application as originally filed. The subject-matter of claim 1 of the main request, as far as it could be understood, did not seem to be novel over a well-known web browser, and that of claim 1 of each of the auxiliary requests did not seem to involve an inventive step.
V. With a letter of reply the appellant filed three new sets of claims as fifth, sixth and seventh auxiliary requests.
VI. In the course of oral proceedings held on 6 June 2018 the appellant withdrew the first auxiliary request. At the end of the oral proceedings, the chairman pronounced the Board's decision.
VII. The appellant's final requests were that the contested decision be set aside and that a patent be granted on the basis of the claims of the main request or, in the alternative, on the basis of the claims of one of the second, third or fourth auxiliary requests filed with the statement of grounds of appeal or the fifth, sixth or seventh auxiliary requests filed with the letter of 4 May 2018.
VIII. Claim 1 of the main request reads as follows:
"A method, comprising:
providing an address field (22) [i]n a network browser;
detecting data input into the address field by a user; and
providing at least one virtual function key (23), associated with the address field of the network browser, wherein a function provided by the at least one virtual function key relates to a service that depends upon the data input into the address field by the user."
IX. Claim 1 of the second auxiliary request reads as follows:
"A method, comprising:
providing an address field (22) in a network browser;
detecting data input into the address field by a user in order to use a service, wherein the data input into the address field by the user is different from a network address; and
providing at least one virtual function key (23), associated with the address field of the network browser, which provides a function that depends upon the data input into the address field by the user and relates to the service."
X. Claim 1 of the third auxiliary request reads as follows:
"A method, comprising:
providing an address field (22) and a plurality of virtual function keys (23) in a network browser, wherein the plurality of virtual function keys is associated with the address field;
detecting data input into the address field by a user in order to use a service, wherein the data input into the address field by the user is different from a network address; and
modifying the virtual function keys by providing at least one virtual function key, associated with the address field of the network browser, which provides a function that depends upon the data input into the address field by the user and relates to the service."
Method claims 2 to 8 are dependent upon claim 1. Claims 9 and 10 define computer program instructions and an information processing device by reference to the method claims. Claim 11 is dependent upon claim 10.
XI. In view of the outcome of the appeal proceedings, the claims of the fourth to seventh auxiliary requests are not relevant for the present decision.
XII. The appellant's arguments, where relevant to this decision, are discussed in detail below.
1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.
The invention
2. The invention concerns a web browser with an "adaptive address field" and a plurality of virtual function keys which are modified in accordance with the service used (see page 5, lines 15 to 18, page 6, lines 1 to 9, and claim 1 of the international publication).
2.1 The user at a terminal may enter in the address field information relating to a service. When data is entered into the address field of the browser, it is checked whether a network address was entered (page 5, lines 7 to 11).
If a network address was entered, a connection is established to the web page. If the web page is an "adaptive web page" supporting a service application, then the browser's function keys and/or menus associated with the address field are adapted in accordance with that application (page 5, lines 11 to 18; page 5, line 30, to page 6, line 14; Figures 1a and 1b).
If the data entered by the user is not a network address, a software application at the terminal decides how the input data should be interpreted and, in particular, to which service the data input by the user relates. The network browser then enters an "adaptive state" in which the function keys and/or menus associated with the address field turn into keys/menus needed in that particular service (page 4, line 28, to page 5, line 2; page 5, lines 19 to 25; Figure 1a).
2.2 The description gives examples of services and respective adapted address fields on page 6, line 15 to page 7, line 21, with reference to Figures 2a and 2b. The function description 21 on the left of the address field of Figure 2a, the input field 22 in the middle, and the virtual function keys 23 on the right are adapted to each particular service. For example, if the user enters digits that can be interpreted as a phone number in the address field of the web browser, the function keys are adapted such that they can be used to make and reject a call, mute the device and clear a digit entered in the address field (page 6, lines 27 to 30; Figure 2b, first example "").
Main request - admission into the appeal proceedings
3. At the oral proceedings the appellant was heard on the question of admissibility of the main request which had been raised in the Board's communication.
3.1 Claim 1 of the main request differs significantly from, and has a broader scope than, claim 1 of the requests considered by the decision under appeal (e.g. it is no longer specified that the data input is different from a network address). In addition, the main request is very similar to the request submitted by the applicant with the letter of 17 October 2011, which was later replaced by the refused requests. That earlier request was hence not further defended by the applicant before the department of first instance.
3.2 According to Article 12(4) RPBA, the Board has the power to hold inadmissible facts, evidence or requests which could have been presented in the first instance proceedings. In the Board's view, that provision applies in the present situation in which the main request is essentially identical to a request which had been previously filed but later withdrawn or replaced.
3.3 Claim 1 of that earlier request had been objected to under Article 123(2) EPC for omitting the "modification" or "adaptation" of the virtual function keys. That objection was overcome by later amendments. By returning to a claim similar to the earlier claim and which also omits that feature, the old objection becomes relevant again.
3.4 It is against the principle of procedural economy to re-introduce previous deficiencies in the claims, or to return to broader claims without a special reason for doing so.
3.5 Exercising its discretion under Article 12(4) RPBA, the Board nonetheless decides to admit the main request into the appeal proceedings because it can be dealt with efficiently together with the second auxiliary request.
Main and second auxiliary requests
4. Article 123(2) EPC
4.1 The application as originally filed, including the passages cited by the appellant as basis for claim 1 of the main request, consistently disclose a step of modifying or adapting the virtual function keys according to a service in response to data entered in the address field causing the browser to change to a mode in which that service is supported.
4.1.1 Indeed, the description as originally filed discloses two such modes of "adaptive operation" of the browser according to the invention. The first mode is started when the user enters a network address in the address field and the corresponding web page is an adaptive web page (page 5, lines 10 to 18; page 5, line 30, to page 6, line 9; Figure 1b). The browser works in the second adaptive mode of operation if the data entered by the user in the address field is not a network address but requests a service (page 5, lines 19 to 25, Figure 1a).
In both adaptive modes the virtual function keys are associated with the address field and are adapted or modified in accordance with the service corresponding to the data entered by the user into the address field (page 4, line 28, to page 5, line 2; page 5, lines 19 to 25; page 6, lines 6 to 9).
4.1.2 Claim 1 as originally filed defines a method which uses a network browser comprising "at least an address field (22) and virtual function keys (23) associated with it", the method being characterised in that "the address field (22) and virtual function keys (23) are modified so as to be in accordance with the service used at that time".
Similarly, each of original independent claims 6, 7 and 12 and dependent claim 15 refers to the modification of the address field and associated virtual function keys according to a service. Original independent claim 14 does not define a step of modifying the virtual function keys, only one of modifying the user interface in accordance with the service used. But that claim is much broader and does not refer to a browser.
4.2 Claim 1 of both the main request and the second auxiliary request concern the browser's adaptive mode, but neither claim defines a step of modifying or adapting the virtual function keys associated with the address field of the browser in reaction to the step of detecting data input into the address field. In particular, the step of "providing at least one virtual function key (23), associated with the address field of the network browser" does not imply a step of adapting or modifying the virtual function keys which are associated with the address field.
4.3 The Board thus concludes that the main request and second auxiliary request do not fulfil the requirements of Article 123(2) EPC.
Third auxiliary request - claim 1
5. Claim 1 of the third auxiliary request differs from claim 1 of the second auxiliary request in that it additionally specifies, in the step of providing an address field, that a plurality of virtual function keys is provided, wherein the plurality of virtual function keys is associated with the address field. Furthermore, it explicitly defines a step of modifying the virtual function keys.
6. Article 123(2) EPC - claim 1
6.1 As a result of these amendments, claim 1 of the third auxiliary request defines a step of modifying the virtual function keys associated with the address field in reaction to detecting input into the address field of data other than a network address and therefore overcomes the objection under Article 123(2) EPC raised above against claim 1 of the main request and the second auxiliary request.
6.2 In the Board's view, the subject-matter of claim 1 is originally disclosed e.g. on page 5, line 3, to page 6, line 14; and in Figures 1a and 1b.
6.3 The Board is therefore satisfied that claim 1 fulfils the requirements of Article 123(2) EPC.
7. Article 84 EPC - claim 1
7.1 At the oral proceedings the appellant stated that a "network address" within the meaning of the claims encompassed also input data for protocols other than Hypertext Transfer Protocol (HTTP). In the Board's opinion, the skilled reader indeed clearly understands from the claim as a whole that data "different from a network address" is any data immediately triggering a switch by the local software application from the conventional network-browser mode of operation, which does not require any changes of the virtual function keys, to the adaptive mode. The Board therefore agrees that also a standard uniform resource location (URL) other than HTTP, e.g. a file transport protocol (FTP) URL, has to be seen as a "network address" within the meaning of the claim. The Board notes that this is in line with the description which refers on page 5, lines 10 and 11, to the network address as a "server's network address or the like".
7.2 The Board does not maintain any other lack-of-clarity objection and is therefore satisfied that claim 1 fulfils the requirements of Article 84 EPC.
8. Novelty and inventive step - claim 1
8.1 In the decision under appeal, inventive step was assessed starting from a conventional web browser such as the "network browser" acknowledged on page 1, lines 24 to 33, of the application. That passage describes "so-called network browsers [which] have been developed" as follows:
"When using a network browser, the pages visited will be saved in the memory of the device, from where they can be retrieved by means of virtual keys in the network browser or by typing the address of a page in the address field in the network browser. In some browsers some of these virtual keys will change their appearance according to whether the function associated with a particular key can be used or not. In some browsers data entered in the address field will automatically start a search engine operating in the network, which search engine will then suggest a network address to connect to."
Since these "virtual keys" perform a function, e.g. moving backwards, they are "virtual function keys". The passages cited above thus disclose that the acknowledged network browser supports
(i) virtual function keys which can be used to revisit a page,
(ii) virtual function keys the appearance of which changes depending on whether the associated function can be used or not; and
(iii) automatically starting a search engine on the basis of data entered in the address field.
The Board agrees with the decision under appeal that such a well-known web browser, or the corresponding well-known method performed by a conventional web browser, is an adequate starting point for the assessment of novelty and inventive step.
8.2 The well-known web browser has an address bar including an address field and detects data input into the address field by a user. The address field also includes buttons (i.e. "virtual function keys" in the language of the claim), such as stop download, reload, home, back and forward buttons. This is acknowledged in the application (see page 1, lines 31 to 33, page 4, lines 23 and 24, and Figure 2a). At least some of these buttons are disclosed in documents D5 and D6 with regard to two browsers that were well known at the time: Internet Explorer 5 and Netscape Navigator (see D5, picture on page 1, and D6, page 4, "Smart Stop/Reload button").
Claim 1 further defines the following features:
(a) the data input by the user into the address field is in order to use a service,
(a.1) the browser detects data input into the address field by the user which is different from a network address; and
(b) the virtual function keys are modified
(b.1) by providing at least one virtual function key, associated with the address field of the network browser,
(b.1.1) which provides a function that depends upon the data input into the address field by the user and
(b.1.2) relates to the service.
Some of these features were arguably known from well-known web browsers supporting the functionality described under points (i) to (iii) above. Browsers which automatically start a search engine on the basis of data entered in the address field (function (iii) above) appear to do this because they recognize that the data input into the address field is different from a network address. Thus, features (a) and (a.1) may be regarded as implicit in web browsers supporting function (iii). In that case, the web browser can be considered to offer two services, visiting web pages and searching in a search engine. Furthermore, when interpreting the change of a key's appearance as a modification of a virtual function key, feature (b) may be regarded as present in browsers that disable buttons if their function is not available (function (ii) above).
8.3 However, the well-known web browser does not modify the virtual function keys by providing at least one virtual function key to support a function that depends upon the data input into the address field by the user and relates to a service (see features (b.1), (b.1.1) and (b.1.2)), where the service is that determined by the data input by the user in feature (a).
In the decision under appeal, the subject-matter of claim 1 was considered to differ from a well-known method performed by a conventional web browser in that a function provided by the at least one virtual function key depended upon the data input into the address field. The virtual function keys or their functions were thus adapted according to the "kind of data" input by the user. That adaptation was not guided by technical considerations, but amounted to a requirements specification formulated by the end user. Its underlying concept - that of providing suitable keys according to specific user wishes, wherein the kind of data input was specified by the end user in advance - was non-technical. The objective technical problem was that of implementing the requirements specification consisting of adapting the virtual function keys or their functions in accordance with the kind of data input.
The Board does not agree with this formulation of the objective technical problem. In general, the implementation of a user interface includes non-technical aspects of the GUI layout but also technical aspects regarding user-computer interaction (for an overview of decisions see Case Law of the Boards of Appeal, 8th edition, July 2016, I.D.9.1.6). For example, the choice of where to provide a control button was regarded as a matter of user preferences in T 478/06 of 30 June 2009 (reasons 6 and 11), but in the same decision the board appears to have taken the view that providing "some sort of control button" was part of the technical solution (reasons 10). The graphical design of menus was considered, as a rule, to be a non-technical aspect of a menu-driven control system in T 244/00 of 15 November 2001 (reasons 12). In decision T 1214/09 of 18 July 2014 the present Board found that a particular arrangement of thumbnail file images did not contribute to the technical solution of the problem of enabling more efficient image retrieval (reasons 4.8.8), but that providing a mechanism for inputting a selection from a number of items was a technical task (reasons 6.3).
In the present case, the Board agrees with the Examining Division that the invention fulfils user requirements of a non-technical nature, basically the desire of the user to be able to easily carry out tasks of different types, e.g. calling a person, translating a word, making a calculation. However, the decision of what input mechanism to use, and how to modify the software applications to support a task required by the user, in particular whether the task should be specified e.g. by an additional button, a menu, or the "kind of data" entered in the address field, may be determined by technical considerations. In the present case, the decision to use virtual function keys associated with the address field of the web browser for supporting those tasks does not merely relate to the layout or graphical design of the user interface. It requires technical considerations regarding different interaction mechanisms.
The distinguishing features solve the problem of extending the well-known web browser with functionality required by the user. In the Board's view, this formulation corresponds essentially to that of "expanding the utility of a network browser" used in the grounds of appeal.
8.4 None of the cited prior-art documents discloses or suggests the distinguishing features in combination.
Document D2 is the most relevant of the cited documents and discloses an adaptive web browser, where adaptation refers to the alteration of an application's behaviour or interfaces in response to arbitrary context changes (see title, abstract and page 21, section 2). Different types of adaptation are listed including "User" adaptation concerned with user experiences and capabilities as well as user context (page 22, Table 1, Sections 2.3 and 2.4). This user adaptation may take into account the activities in which the user is participating and tailor the user interface accordingly (section 2.4). The web browser may adapt its user interface by changing the widgets used (page 23, right column, first paragraph of section 3.1). Since virtual function keys are normal GUI elements (see present application, page 1, lines 20 to 23), document D2 can be considered to suggest, at least implicitly, the adaptation of virtual function keys. However, it does not disclose the adaptation of the virtual function keys depending on the data entered by the user in the address field. The user activities can be seen as relating to services, but document D2 does not suggest any way of deriving the user activity.
8.5 The solution is not obvious when taking into account the standard practice of the skilled person either.
As the Board argued in its communication, the address field of a web browser is the main element of its user interface. The data entered in the address field, e.g. a URL, is used to command the browser to perform an operation. The prefix of the URL identifies a protocol, e.g. HTTP and FTP, which determines how a browser interprets the URL. However, in these cases the browser is not adapted to provide new functionality requiring an adapted user interface but merely supports a further network protocol with the same browser functionality.
In its preliminary opinion the Board argued with regard to the then main request that a backwards button (function (i) above) could be considered to offer a function the result of which depended upon the last visited web page and thus upon the network address input into the address field by the user. However, that known browser functionality does not encompass detecting input data different from a network address and modifying the virtual function keys by providing at lest one virtual function key. As argued by the appellant at the oral proceedings, in that case the function provided by the virtual function key is the same, only the parameters taken into account by the function are changed, and those parameters do not directly depend on the data input into the address field by the user, but on the last network address stored in the browsing history of the web browser. In the Board's view, without inventive step the skilled person would not arrive at the distinguishing features from such a remote functionality.
8.6 The Board therefore concludes that the subject-matter of claim 1 is inventive over the prior art considered in the present case and fulfils the requirements of Articles 52(1) and 56 EPC.
Final remarks - remittal
9. The Board does not maintain the ground for refusal of the impugned decision and is satisfied that claim 1 of the third auxiliary request overcomes all the objections raised.
However, further issues may need to be solved e.g. with regard to the other claims and the adaptation of the description.
10. The case is therefore to be remitted to the department of first instance for further prosecution on the basis of the third auxiliary request.
11. Given the long duration of the proceedings thus far, the Board hopes that the Examining Division expedites the examination of the remitted case.
For these reasons it is decided that:
1. The decision under appeal is set aside.
2. The case is remitted to the department of first instance for further prosecution.