T 0036/19 (Entering free form information in URL address/SPRING VENTURES) of 13.9.2019

Summary of Facts and Submissions

I. The applicant (appellant) appealed against the decision of the Examining Division refusing European patent application No. 10000433.2. The application is a divisional application of European patent application No. 99901873.2, which was filed on 28 January 1999 as international application PCT/IL99/00055.

The decision cited the following document:

D3: GB 2 312 975 A published on 12 November 1997

The Examining Division decided that the subject-matter of claims 1 and 5 of the main request and of the auxiliary request did not involve an inventive step (Article 56 EPC) in view of document D3.

II. With the statement of grounds of appeal, the appellant filed an amended main request (correcting a minor typographical error in claim 1), as well as an amended auxiliary request, and requested that the decision be set aside in its entirety and a patent be granted on the basis of one of these requests.

III. In a communication under Article 15(1) RPBA (2007) accompanying a summons to oral proceedings, the Board expressed, inter alia, its provisional opinion that the subject-matter of claims 1 and 5 of the main and auxiliary requests was not inventive with regards to the disclosure of document D3.

In addition, the Board introduced the following document:

D12: EP 0 817 099 A2 published on 7 January 1998

The Board indicated that it might have to be discussed during the oral proceedings whether the subject-matter of claims 1 and 5 of the main and auxiliary requests was inventive with regards either to D3 in combination with D12 or, alternatively, to D12 in combination with D3 (Article 56 EPC).

IV. During the oral proceedings before the Board, the appellant filed second and third auxiliary requests. At the end of the oral proceedings, the chairman pronounced the Board's decision.

V. The appellant's final requests were that the decision under appeal be set aside and that a patent be granted on the basis of the claims of the main request filed with the statement of grounds of appeal or, in the alternative, of one of the (first) auxiliary request filed with the statement of grounds of appeal and the second and third auxiliary requests filed in the oral proceedings.

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

"A method of web page retrieval for enabling a user, using a computer having a connection to the Internet to retrieve a desired webpage, comprising providing a translator (12; 22; 32; 42; 52) receiving information entered by a user in a URL entry field of a web browser (10; 20; 30; 50) operated on the user's computer, said translator being configured to determine a URL address for a web page which is most likely to be a desired webpage associated with the information received from the user and send the URL address to the web browser of the user's computer to enable retrieval of the web page responsive to the URL address to be directly displayed on the user's browser, without any additional user intervention beyond the entry of said information, wherein the determination of the URL address by said translator (12; 22; 32; 42; 52) is also based on one or more of the group consisting of:

(a) determining a geographical location of the user and using the determined geographical location in selecting the URL address;

(b) analyzing URL associations stored in a database that are logically associated with the user; and

(c) user-dependent information stored in a database including at least one of geographical location of the user, a customer club to which the user is associated, user profile, user age, and user browsing habits."

VII. Claim 1 of the first auxiliary request differs from claim 1 of the main request in:

- the addition of "wherein the information is entered at least in part by typing by the user, and wherein said information is free-form information that does not meet URL specifications" after "a web browser operated on the user's computer"; and

- the replacement of "said translator being configured to determine a URL address for a web page which is most likely to be a desired webpage associated with the information received from the user" by "said translator being configured to analyze said information to determine a single translation, the translation being a URL address for a web page associated with the information received from the user".

VIII. Claim 1 of the second auxiliary request differs from claim 1 of the first auxiliary request in the replacement of "wherein said information is free-form information that does not meet URL specifications" by "wherein said information is free-form information and comprises a plurality of words in any order".

IX. Claim 1 of the third auxiliary request reads as follows:

"A method of web page retrieval for enabling a user, using a computer having a connection to the Internet, to retrieve a desired webpage, comprising providing a translator (12; 22; 32; 42; 52) receiving information entered by a user in the URL entry field of a web browser (10; 20; 30; 50) operated on the user's computer, wherein the information is entered at least in part by typing by the user, and wherein said information is free-form information that does not meet URL specifications,

said translator being configured to analyze said information to determine a single translation, the translation being a URL address for a web page associated with the information received from the user, and send the URL address to the web browser of the user's computer to enable retrieval of the web page responsive to the URL address, the web page being directly displayed on the user's browser, without any additional user intervention beyond the entry of said information, wherein the determination of the URL address by said translator (12; 22; 32; 42; 52) comprises performing an automatic web search and returning the address of a single hit."

Reasons for the Decision

Admissibility of appeal

1. The appeal complies with the provision referred to in Rule 101 EPC and is therefore admissible.

Procedural issue

2. The filing date of the present (divisional) application is 28 January 1999. As the term of a European patent amounts to 20 years from the date of filing (Article 63(1) EPC), a patent which may eventually be granted for the present application will have already expired. The Board nevertheless considers that the appellant still has a legitimate interest in the continuation of the grant and the appeal proceedings. Since a European patent application already confers rights after its publication pursuant to Article 67 EPC, a grant decision by the European Patent Office, even if taken only after expiry of the patent term, may become relevant for the determination of these rights.

The application

3. The application relates to World Wide Web (WWW) page retrieval and to methods for performing such retrieval using a "minimally restrictive" syntax (description of

the application as filed, page 1, lines 3 and 4).

4. The usual mode of operation for WWW page retrieval includes opening a web browser, entering a Uniform Resource Locator (URL), and viewing the page fetched by the browser. The actual pages of information are located on physical host machines, each of which may be mapped to one or more domain names (description, page 1, lines 6 to 11). The naming conventions for domains (and consequently sites and URLs) are rather restricted. The restrictions allow creating a one-to-one mapping between web addresses and a particular site. However, these addresses must be entered accurately. Any mistake will result in the site not being located (description, page 1, lines 24 to 31).

5. A particular site might be identified by using the name of a particular site owner in an attempt to render the address meaningful (for example, "http://www.ibm.com" for IBM, "http://www.microsoft.com" for Microsoft, however "http://www.msn.com" for Microsoft Network). But in many cases there is no direct relationship between the name of the site owner and the address of the site and it is often impossible to reconstruct the correct address from the name of the site owner (description, page 2, lines 6 to 12).

6. Thus, search engines and WWW directories have been developed in which a user enters a name and/or other information regarding the site owner and a WWW page containing a list of possible site addresses is generated and presented to the user (description, page 2, lines 13 to 16).

7. In some browsers, an incompletely typed URL may be automatically expanded by the addition of a standard suffix or postfix. Another helpful feature is automatic completion of URLs: if a URL has been previously used, entering its first few characters will cause the entire URL to be suggested to a user (description, page 2, lines 20 to 25).

8. The invention proposes a method to allow a user to retrieve a WWW page using a native language that is not English and which may use non-Latin characters, such as Cyrillic, Hebrew and Arabic, and to enter partial information regarding a site owner, preferably without imposing an order on the information. The user enters the information into a standard portion of a browser, a location entry window, just as where a standard URL would be entered. This information allows the direct retrieval of a home page which belongs to a site matching the entered information (description, page 3, lines 19 to 28). The entered information may not meet domain name specifications or URL specifications. It may comprise a partial street address or a telephone number of the owner (description, page 6, lines 5 to 11). For example, the pages are selected according to the geographical location at which the information is entered (description, page 7, lines 9 to 10).

9. In one embodiment, the entered information is analysed to determine a single translation thereof by, for example, correcting spelling in said information (description, page 6, lines 12 to 14).

10. Thus, the present invention relates to a method of enabling a user to enter a "substantially" free-form designation of a WWW site, preferably in the user's native language, and directly obtain the information from the site, without the necessity of using an exact site address (description, page 11, lines 10 to 13).

Claim 1 of the main request - inventive step

Document D12 as starting point

11. While the Examining Division has based its negative assessment of inventive step on document D3, the Board's analysis in its communication accompanying the summons also focused on the newly introduced document D12. During the oral proceedings the Board expressed its opinion that the teaching of the latter document came closer to the claimed invention and discussed it in detail with the appellant. For assessing inventive step with respect to the main, the first and the second auxiliary request, the Board therefore uses document D12 as starting point. Document D3 will nevertheless have to be considered with respect to the third auxiliary request.

12. Document D12, in its introduction, discloses that "[i]n order to access specific World-Wide-Web (WWW) pages, users must often enter the Uniform Resource Locator (URL) which provides the address of the page on a remote server" (column 1, lines 13 to 16) and explains that "[a] major problem with the manual entry of URLs is the introduction of spelling errors, which are particularly common because of the characteristics of URL syntax and structure" (column 1, lines 29 to 32).

12.1 Document D12 therefore proposes an improved method for spell checking the URL entered by a user to increase the probability of finding the desired web page in a timely fashion (column 2, lines 31 to 35). The method of document D12 uses three components that may work in concert, individually or in pairs: a client-side component which operates in conjunction with the user's browser, a server-side component operating on a server containing WWW pages, and a "collaborative" component which is located on an Internet Service Provider (ISP) server or an organization's proxy server. The three components represent three unique but complementary methods of providing spelling check services to the user. Each component addresses the spelling check problem differently (column 2, line 56, to column 3, line 3).

12.2 The environment in which the method of D12 operates is illustrated by Figures 1A and 1B reproduced below:

FORMULA/TABLE/GRAPHIC

12.3 In the methods proposed by document D12, if the entered URL is not correct, a list of potential URLs is generated by any one of the components. If the list is not empty, it is displayed to the user in a hypertext format where the user can either select one of the URLs or cancel the operation. Selecting a URL from the list results in an attempt to retrieve the document using the selected URL. If the document is successfully retrieved then the document is displayed by the browser (column 7, line 7, to column 8, line 46, in conjunction with Figures 2 and 3; column 12, line 45, to column 13, line 47, in conjunction with Figures 10 and 11; column 14, line 3, to column 15, line 5, in conjunction with Figure 12).

12.4 As regards the spell checking performed by the client-side component, D12 makes the general statement (both in the abstract and in the summary of the invention in the last paragraph of the description, see column 17, lines 5 to 7) that "[a]t a client level, the specified URL is compared with URL's [sic] previously successfully used to find candidate misspellings." According to the description of the preferred embodiment, this comparison is done in a specific way. Figures 8A to 8C illustrate the databases required by the client-side component.

12.4.1 The database of Figure 8A is a list of WWW protocols (like "http", "gopher", "ftp", etc.). The database of Figure 8B is a list which is updated dynamically with the server names of all URLs that have been successfully accessed and viewed (like "www.sun.com", "www.xyz.edu", "www.abc.gov"). The database of Figure 8C which is reproduced below contains (server name, component name) tuples and is also updated dynamically.

FORMULA/TABLE/GRAPHIC

12.4.2 If a webpage has been previously accessed, its "complete and correct" URL (for example www.sun.com/foo/bar/file.html) is used as input data for this database. As shown in Figure 8C, a plurality of (server name, component name) tuples may be generated from a single URL (column 10, line 57, to column 11, line 12). The Board understands this as not implying that the URL is stored as such.

12.4.3 When the spell checking is done at the client level, the entered URL is parsed and compared with the tuples contained in database C. Thus, at least in the context of the preferred embodiment, there is no comparison of the entered URL with a complete URL previously accessed.

12.5 As regards the spell checking by the collaborative component, document D12 discloses that the component inter alia utilises knowledge from other users' behaviour (i.e. the knowledge about the WWW pages that all users have successfully retrieved in the past) to provide a knowledge base for the spelling checker (column 2, lines 36 to 55).

12.5.1 Figure 14 of D12 reproduced below illustrates the databases required by the collaborative component of the method of D12 at an Internet Service Provider (ISP) or an organization's proxy server. The database of Figure 14A contains previously valid server names and the dates they were last accessed. The database of Figure 14B contains previously valid URLs for documents that have been successfully retrieved and the dates they were most recently retrieved. Both databases are located at the ISP's side. They might be updated (column 15, line 46, to column 16, line 11; Figure 15).

FORMULA/TABLE/GRAPHIC

FORMULA/TABLE/GRAPHIC

12.5.2 Thus, at the ISP's side, the entire URL is used for the spell checking as a single string, see column 2, lines 51 to 55: "The collaborative component of the invention utilizes knowledge from other users' behavior (i.e. the WWW pages they have successfully retrieved in the past by all users) to provide a knowledge base for the spelling checker", and column 14, lines 34 to 44, in conjunction with Figure 12: "Alternatively, if the service receives a "Document Not Found" error as a response from the remote server (1205), then the collaborative component will spell check the user-supplied URL. This is accomplished by using the service's Database B which contains all valid URLs that have been retrieved from remote servers and passed back to users via the service for some specified period of time.

Comparison of the invention as defined in claim 1 with the teaching of D12

13. Using the wording of claim 1, document D12 discloses a method of web page retrieval for enabling a user, using a computer having a connection to the Internet to retrieve a desired webpage, comprising providing a translator receiving information entered by a user in a URL entry field of a web browser operated on the user's computer. It is noted that the term "translator" is, in the light of the description of the present invention, to be understood broadly (see e.g. the passage on page 14, lines 28 to 31, according to which "the translator may perform one or more of the following functions: (a) Correct spelling errors, especially those caused by transliteration errors. As a result, many near misses in site address entry will connect to the correct site."). Thus, it encompasses spell checking software such as that disclosed in D12.

13.1 Both in the method of D12 and in the claimed invention, URL addresses which are most likely to be desired webpages associated with the information received from the user are returned to the web browser of the user's computer. However, in D12 the user receives a list comprising one or a plurality of URL addresses and the display of one of the corresponding web pages requires a selection made by the user, whereas, according to claim 1, the web page responsive to the URL address will be directly displayed without any additional user intervention (which implies that the claim feature "determining a URL address" is to be read as "determining a sole URL address").

13.1.1 The distinguishing feature described above is devoid of inventive merit. Since there is no certainty that a suggested URL address is the one in which a user is interested, it is immediately apparent to the skilled person that there are two basic ways how the method can be implemented. Either one requires a confirmatory action by the user with respect to the suggestion(s) made or one renounces on this requirement so that the web page corresponding to the suggested URL address can be immediately retrieved and displayed. The skilled person is aware of the trade-off between these two implementations. The first alternative has the advantage that due to the required intervention the method is more transparent to the user and helps in avoiding the retrieval and display of web pages in which he is not interested. The second alternative has the advantage that in cases where the suggested URL address is indeed the one in which the user is interested, the method is more rapid and avoids a further input action by the user. The choice between these two implementations is a routine task for the skilled person. The description of the application does not point to any unexpected advantage of opting for the second alternative.

13.1.2 In addition, the skilled person would notice that there are situations where the spelling check operation of D12 will return a list comprising only one URL address. For this case, the skilled person would consider directly displaying the web page corresponding to this single URL address without further user intervention beyond the entry of the information (i.e. the misspelt URL) since the user would not be able to select any other URL.

13.2 According to claim 1, the determination of the URL address has to be also based on one or more of three specific alternatives (a) to (c). Thus, realising only one of these alternatives falls under the claim. Alternative (b) reads "analyzing URL associations stored in a database that are logically associated with the user". In order to understand the meaning of these terms, it is useful to consult the embodiments described in the passages on page 4, line 19, to page 5, line 5; page 12, lines 8 to 15; and page 15, lines 22 to 29 of the description.

13.2.1 In these embodiments, URLs are associated with partial information, native language information or nicknames indicative of the site owners. In one embodiment, a local database is maintained in which each partial entry by a user is associated with the actual site that the user connected to (a site being usually denoted by its URL address). In this case the associations are constituted by tuples of a partial information and a URL name or actual site that the user connected to, and these tuples are linked to a specific user. When the user enters the partial information, the site can be connected to without any additional input by the user (see description of the application, on page 15, lines 22 to 25). In another embodiment, a user may enter a personal preference for an association between a URL name and partial and/or native language information and/or nicknames indicative of the site owners (see page 4, lines 19 to 21, and page 12, lines 10 to 12). In the Board's understanding, in both embodiments the URL associated with the partial information, the native language information or the nickname is a complete URL.

13.2.2 The Board is not fully convinced that the rather vague term "URL associations" has to be interpreted in the narrow sense as disclosed in the above embodiments. One could e.g. take the view that associations of several parts of a URL (as disclosed in the user-specific database 8C of the client-side component of D12) might equally fall under this term. Furthermore, since according to alternative (b) URL associations are associated with the user, one might also consider that the term "URL associations" simply expresses in a somewhat redundant manner that there is an association between URLs and the user.

13.3 Nevertheless, for the sake of argument the Board assumes in the following that the term is to be understood in a more restricted sense in line with the disclosed embodiments. Thus, the implementation according to alternative (b) is considered to distinguish over the teaching of document D12 since the database 8C of the client-side component does not store the complete URL address but only parts of it (see point 12.4 above).

13.4 The inventive merit of this distinguishing feature can be assessed separately from the feature discussed in point 13.1 since no synergy between them is apparent. The Board furthermore notes that the appellant itself, when discussing inventive step, did not put any weight on the distinguishing feature.

13.5 As explained in detail above (points 12.4 and 12.5), document D12 already discloses methods where the spell checking is based on URLs that have been successfully accessed in the past. In the context of the client-side component, a database is used which contains tuples formed by the server-name part of a URL which has been successfully accessed by the individual user and some associated component. In the context of the collaborative component, a database is used which contains previously valid URLs for documents that have been successfully retrieved by all users. In the Board's view, it would have been a standard modification and thus obvious for the skilled person to store the entire retrieved URL in the database of Figure 8C instead of only the server name's part of it in association with the components, thereby arriving at the distinguishing feature.

13.6 The Board furthermore notes that the background section of the description of the present application, which describes features of state-of-the art browsing technology, contains the following passage (see page 2, lines 20 to 22): "Some Web browsers allow a user to maintain a local list of preferred locations, which are stored and accessed by selection of a nickname and/or a description from a list, rather than by entering a complete URL." This passage implies that it was well-known to store URL associations (in the sense of URL addresses associated with e.g. nicknames) associated with an individual user. It would have been obvious to use these stored associations in the context of a spell checking method such as that disclosed in D12 in order to take into account the possibility that a misspelling occurs when a user wishes to enter a nickname for a URL address.

13.7 It follows from the above that claim 1 of the main request is not inventive in view of document D12.

First auxiliary request - inventive step

14. Claim 1 of the first auxiliary request differs from claim 1 of the main request in that

(a) the information is entered at least in part by typing by the user,

(b) said information is free-form information that does not meet URL specifications, and

(c) the expression "said translator being configured to determine a URL address for a web page which is most likely to be a desired web page associated with the information received from the user"

has been replaced by the expression

"said translator being configured to analyze said information to determine a single translation, the translation being a URL address for a web page

associated with the information received from the user".

14.1 The features (a) and (c) do not add anything which distinguishes the claimed subject-matter further over the teaching of document D12. Feature (a) is at least implicitly disclosed in D12 since the spell-checking of the client-side component requires that the user manually enters the URL (see column 8, lines 10 and 11). Feature (c) makes explicit that the translator determines a single URL address. However, this only corresponds to the interpretation which the Board has already given to claim 1 of the main request (see the two ultimate lines of point 13.2 above).

14.2 During the oral proceedings, the appellant argued with respect to feature (b) that the expression "free-form information" encompassed inputs by the user that were neither a correct nor an incorrect URL address. D12 required that the input was very similar to a manually entered URL. In particular, D12 described parsing the complete URL to obtain components. The appellant referred to column 8, first full paragraph, and column 11, lines 45, to column 12, line 20 of D12.

14.3 The Board understands the expression "free-form information" as designating some information that does not have or follow a particular style or structure (see e.g. the Online Cambridge Dictionary). In view of the further definition provided in feature (b), the information entered by the user should not have a URL structure as generally required by URL specifications.

14.4 In the Board's view, at least certain misspellings which occur when a user tries to type a URL address have the consequence that the entered information does not meet URL specifications. An example are misspellings of the protocol portion of the URL. This problem is explicitly addressed in D12 (column 7, lines 23 to 28: "Alternatively, if the URL was manually entered by the user (206) then the client-side component of the invention performs a spelling check on the protocol and domain-name portion of the URL (208) and creates a list of potentially valid URLs (210)." Feature (b) therefore encompasses at least some incorrectly entered URL addresses and does not distinguish further over the teaching disclosed in D12. As an aside, the Board observes that the application itself also proposes correcting spelling errors (see page 14, lines 30 and 31, of the description).

14.5 Therefore, the subject-matter of claim 1 of the first auxiliary request is not inventive in view of document D12 for the reasons set out above for the main request.

Second auxiliary request

15. Claim 1 of the second auxiliary request replaces feature (b) of the first auxiliary request by defining that the entered information is "free-form information and comprises a plurality of words in any order" (= feature (b')). This amendment finds support in the passages on page 6, lines 5 to 11, and page 14, last two lines, of the description as filed.

15.1 The second auxiliary request was filed in the oral proceedings before the Board. Since the amendment made only amounts to a minor modification of the first auxiliary request and can be dealt with by the Board without any difficulty, the request is admitted into the proceedings in accordance with Article 13(1) and (3) RPBA (2007).

15.2 During the oral proceedings, the appellant argued that feature (b') distinguished the claimed method over spell checking of incorrectly entered URLs. The merits of this argument largely depend on the correct claim interpretation. It might have been the appellant's intention to restrict the claim to a method which is able to translate user information (always) independently of its form and of a particular order of words. However, the Board does not read feature (b') so narrowly.

15.3 According to standard claim construction, if a claim uses a broad and generic term, everything more specific which falls under the claim is encompassed by its scope. In the Board's understanding claim 1 merely defines the information very broadly and does not exclude embodiments where the information has a particular form and/or comprises words in a particular order. Rather, the expression "in any order" inherently refers to some kind of order between words, for example an order which yields a (semantic) meaning to the collection of words, or an order related (or conforming) to some convention such as the URL addressing scheme. Thus, spell checking an entered URL with a misspelt protocol or domain-name portion, as disclosed for the client-side component in D12 (column 7, lines 3 to 28; see also above point 14.4), is encompassed by feature (b').

15.4 It follows that feature (b') does not distinguish the claimed method further over that disclosed in D12. Therefore, the subject-matter of claim 1 of the second auxiliary request is not inventive in view of document D12 for the reasons set out above with respect to the main request and first auxiliary request.

Third auxiliary request

16. Claim 1 of the third auxiliary request differs from claim 1 of the first auxiliary request essentially in that the alternatives (a), (b) and (c) have been replaced by the feature "performing an automatic web search and returning the address of a single hit", which was taken from page 16, line 8, of the description as originally filed.

In the Board's understanding the new feature implies that, according to claim 1, the entered information is "translated" to a URL address by automatically submitting it over the Internet as a query to a web search engine and retrieving the address of a single hit (i.e. search result).

17. The third auxiliary request was only filed in the oral proceedings before the Board and introduces a feature taken from the description. The Board nevertheless exercises its discretion under Article 13(1) RPBA (2007) in the appellant's favour and admits the request into the proceedings. Although the Board had already indicated in its communication under Article 15(1) RPBA (2007) that the newly introduced document D12 might have to be discussed during oral proceedings, the appellant was confronted with the board's detailed inventive-step reasoning over D12 for the first time in the oral proceedings. In these circumstances the Board considers that a new request taking into account this reasoning should be admitted even at a late stage.

Inventive step

Document D12

18. Due to the introduction of the new feature into claim 1 of the third auxiliary request, document D12 is no longer a suitable starting point for assessing inventive step. There is nothing in D12 which hints at performing an automatic web search in the context of the disclosed spell checking methods.

Document D3

19. Document D3, on which the Examining Division based its inventive-step reasoning, discloses a client computer 22 including "conventional hypermedia retrieval and rendering software 26 for retrieving hypermedia content from information provider 24 and for rendering it in accordance with conventional HTML instructions", i.e. a web browser application program (page 8, line 20, to page 9, line 5). The web browser of document D3 is, in addition, capable of resolving "soft hyperlinks", which are links that do not contain a resolved target specification, i.e. a full URL address, but specify elements that allow the client 22 to resolve the hyperlink when it is activated (page 9, lines 13 to 16; page 10, lines 8 and 9). A soft hyperlink may be included in a hypermedia document (such as a HTML document) and is activated by the user in a conventional manner when the document is displayed (page 9, lines 17 to 22).

When a soft hyperlink is activated, the client 22 performs a query for one or more hypermedia targets (page 9, line 24, to page 10, line 1). This query is formulated using attributes associated with the user, attributes specified in the hypermedia document, and attributes specified in the activated soft hyperlink (page 10, lines 1 to 3). It is submitted to a database 36 of the information service provider for identification of possible hyperlink targets meeting the search criteria (page 11, lines 4 to 9).

19.1 Document D3 thus discloses, in response to the activation by the user of a (soft) hyperlink that does not contain a full URL address, automatically submitting over a network a query to a database and retrieving a list of matching hyperlink targets. Hence, document D3 discloses "performing an automatic web search".

However, the soft hyperlinks of document D3 are included in HTML documents and not entered by the user in the URL entry field of the web browser.

19.2 In its communication, the Board essentially suggested that the skilled person, when reading document D3, would consider modifying the web browser to treat a (malformed) URL entered into the URL entry field of the web browser in the same way as a (malformed) URL in a (soft) hyperlink encountered in a HTML document.

However, as the appellant has pointed out, the soft hyperlinks of document D3 do not contain free-form queries, which could conceivably be entered by a user in the URL entry field, but are "partially-specified" queries, expressed in terms of attributes supported by the database, and may contain one or more executable rules and "a specification of bound attributes for temporary inclusion in the list of bound attributes maintained by the user's computer" (page 6, lines 19 to 25). In other words, the soft hyperlinks of document D3 have to be carefully constructed by the authors of the HTML documents containing them. They are therefore neither intended nor suitable to be entered by a user in the URL entry field of a web browser. The Board therefore agrees with the appellant that the skilled person would not modify the web browser of document D3 in the manner suggested in the Board's communication without hindsight knowledge of the invention.

19.3 Hence, the subject-matter of claim 1 is not rendered obvious by document D3.

Remittal

20. The following documents, cited in the communication of the Examining Division of 21 April 2016, have not been considered in the decision under appeal:

D10: "ISYS HindSite - Text Search & Retrieval Browser Plug-in", 10 December 1997, retrieved from https://web.archive.org/web/19971210161525/http://www.isysdev.com/products/hindsite.htm;

and

D11: C. Thomas and G. Fischer: "Using Agents to Improve the Usability and the Usefulness of the World-Wide Web", Proceedings of the Fifth International Conference on User Modeling, 1996.

The Examining Division might consider these documents for assessing novelty and inventive step of the third auxiliary request.

20.1 Furthermore, the feature added to claim 1 of the third auxiliary request was taken from the description and may not yet have been searched.

20.2 Therefore the case is to be remitted to the department of first instance for further prosecution on the basis of the third auxiliary request. The Board expects that in view of the filing date of the present application (see point 2 above) the department will deal with it expeditiously.

Order

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.