T 0504/18 (Linking an address/BLACKBERRY) 18-06-2021

The invention

1. The application relates to linking an address in a message such as an email (description of the application as published, paragraphs [0001] and [0005]).

According to the technical background disclosed in the application, users of communication devices or computers may send messages such as emails that include phone numbers, email addresses or web addresses. Applications on some devices create hyperlinks for phone numbers, email addresses and web addresses, so that the user can click on the link within the message and the device will respond by respectively either placing a call, opening an email to be sent or opening the browser to the linked web page (paragraph [0005]).

Known mobile devices can obtain position or location information from a GPS (Global Positioning System) receiver or the like. A mapping application may use this information to display a map showing a mobile device's current position (paragraphs [0002] and [0003]). Many mobile devices also have address books stored thereon that contain information such as street addresses, cities, postal codes, provinces, states, countries and telephone numbers for each entry in the respective address book (paragraph [0004]).

The application proposes detecting a physical address such as a street address within a text message, creating a link for this physical address so that selecting the link will result, for example, in the address location being displayed on a map (description, paragraphs [0029] and [0030]).

Main request and first to third auxiliary requests -admissibility

2. Claim 1 of the present main request differs from claim 1 of the main request considered by the examining division in that it clarifies that the method is "computer-implemented". This clarification also appears in the present first to third auxiliary requests. Moreover, the present first to third auxiliary requests contain a further minor clarification of the menu options feature. Apart from these clarifications, the first and second auxiliary requests correspond respectively to the first and second auxiliary requests considered by the examining division.

As the board considers that the above amendments to the main request and the first and second auxiliary requests are minor clarifications in the context of the present case, it admits these requests into the appeal proceedings under Article 12(4) RPBA 2007.

By comparison with the third auxiliary request underlying the contested decision, the present third auxiliary request has been further amended by the applicant with a view to overcoming the lack of "convergence" of the third auxiliary request as considered in the contested decision. In particular, it has added to the then third auxiliary request the feature added by the then second auxiliary request (see statement of grounds of appeal, page 10, second paragraph; see contested decision, point 18.2). As this amendment overcomes the reasons for not admitting the then third auxiliary request, and as the clean version of the third auxiliary request filed with the appellant's letter dated 10 May 2021 is identical to the marked-up version of the third auxiliary request already filed with the statement of grounds of appeal, and as the admission of requests is at the board's own discretion under Article 12(4) RPBA 2007, the board admits the third auxiliary request into the appeal proceedings.

Main request - inventive step

3. Document D1 as starting point

3.1 According to the contested decision (see point 15.1), the subject-matter of claim 1 lacked inventive step when starting from D1. The contested decision essentially identified features D, E, K and L as distinguishing features (see above, point IX. for the itemisation of the features of claim 1). The examining division argued that these distinguishing features solved the problem of how to recognise an address in the text message. The skilled person was able to come up with the claimed algorithm according to the distinguishing features without exercising inventive skill based on his or her common general knowledge on pattern matching, for example.

3.2 The appellant argued that document D1 did not disclose automatically converting a text document into an interactive document with links for addresses (see statement of grounds, pages 2 to 5). Rather, features B, C, F, I, J and M were not disclosed in D1, which merely disclosed receiving a message already comprising an address with a link. Hence, claim 1 involved an inventive step over D1.

3.3 The street address link to open Google maps, disclosed in the cited passage of D1, is configured to open an application (Google maps) for displaying a menu of options related to an address (a menu within Google maps), which is part of features I and M. However, the board agrees with the appellant that features B, C, F, J and part of features I and M are not disclosed in document D1. Indeed, document D1 discloses (in the last four lines of the sole page provided by the department of first instance) only that a street address sent in a text message can be tapped with a finger to open it in Google maps. According to document D1, links with a telephone number or a web address can be used.

3.4 In the oral proceedings, the appellant agreed that the links according to claim 1 work in the same way as the usual links well known for internet applications, such as the link known from document D1. As discussed in the oral proceedings, this understanding of the claimed links is confirmed by the description, paragraph [0035], which discloses hyperlinks as an example of links. Consequently, the claimed invention is not directed to providing a new kind of link having a different functionality.

3.5 The board and the appellant agree that D1 does not disclose how the links for street addresses are created. In particular, D1 does not disclose any algorithm for automatically detecting an address in a text.

However, the board regards the problem of detecting street addresses in text as non-technical. A street address consists of data in an administrative, non-technical data format. In respect of the specific algorithm for recognising a street address, specified in claim features B to G and J to L, the board sees no "further technical considerations" (see opinion G 3/08, OJ EPO 2011, 10, Reasons 13.5 and 13.5.1) underlying this algorithm, relating for example to functioning of the computer, but rather considerations relating to "merely" finding an algorithm in a non-technical field.

3.6 In the oral proceedings, the appellant argued that the claimed automated creation of links to an application made a text document interactive, and therefore provided a technical purpose. The claim features relating to the algorithm for address detection, even if they were themselves regarded as non-technical by the board, contributed to achieving the overall technical purpose of the claimed method and thus also contributed to the technical character of the claimed method. In this context, the appellant referred to decision G 1/19, Reasons 112 and 113. The appellant argued that non-technical features could make a

technical contribution if they interacted with technical features such as the menu of options to achieve a technical purpose.

Furthermore, referring to decision T 769/92, the appellant argued that "technical considerations" did not need to relate to computer hardware, but more generally to the processing of data. In particular, the claimed address detection algorithm involved "further technical considerations", as it had been structured in a two-step approach to make it efficient. In a first step, the algorithm identified a segment of the text comprising a number and at least two character strings using fast, simple pattern matching (see steps B to F of claim 1). Only in a second step did the algorithm involve more complex processing, such as accessing a database in order to validate the segment as an address (see steps G and J to L of claim 1).

3.7 In respect of the appellant's argument regarding technical considerations, the cited decision T 769/92 can no longer provide a basis in view of opinion G 3/08, Reasons 13.5 and 13.5.1, which states that technical considerations are not sufficient and raises the bar for technical character to "further technical considerations". The recent decision T 2825/19, Reasons 5.3.6, considered that "further technical considerations" could be considerations that specifically exploit technical properties of the computer system hardware to solve a technical problem related to the internal operation of the computer system. In that cited decision the board saw no support for interpreting the concept "further technical considerations" to give a broader meaning that would also cover considerations aiming to solve problems "merely" relating to programming. Consequently, in agreement with the reasoning of that decision, the board does not accept the appellant's view that the processing of data in general implies "further technical considerations" (see also decision T 598/14, Reasons 2.3).

In respect of the improved efficiency of the claimed algorithm as a technical effect, the board holds the view that improved efficiency of a computer-implemented method due to algorithmic features of the program can normally only be considered a "further" technical effect if it is based on "further technical considerations" (see decisions T 1924/17, Reasons 21; T 697/17, Reasons 5.2.3), but that is not the case here.

In view of the above, the board is not convinced by the appellant's argument.

3.8 In respect of the appellant's argument that the algorithm for detecting an address contributed to the overall technical purpose of providing an interactive text document, the board sees no such contribution in the present case, since the relationship between automated address detection and configuration of the link is a mere aggregation of activities. Enabling interactivity by using links was already known from document D1 (and well known in general, as admitted by the appellant). It is clear that the selectable links work independently of the automatic detection of any street addresses; they might just be added manually to such an address, for example. Moreover, D1 discloses that the links can also be used for other kinds of data such as web addresses or phone numbers. Hence, the board is not convinced that the alleged technical purpose of generating interactive text documents by means of links could somehow lend technical character to the algorithm for automated address detection.

This argument can be further illustrated by the following hypothetical example: a computer-implemented business method of auctioning steel can be aggregated with an industrial production method of using the steel acquired in an auction to build a car. While building a car using steel is technical, clearly this does not lend a technical character to the computer-implemented auction method for selling steel (a computer-implemented business algorithm), even if the steel ultimately serves the technical purpose of building a car (see also decision T 1670/07, Reasons 9, technical leakage fallacy: "[...] the mere 'interaction' with technical elements is not enough to make the whole process technical as required by the jurisprudence").

3.9 According to the established case law of the boards of appeal, when assessing inventive step in accordance with the problem-and-solution approach, an aim to be achieved in a non-technical field may legitimately appear in the formulation of the problem as part of the framework of the technical problem to be solved, as a constraint that has to be met (see decisions T 641/00, OJ EPO 2003, 352; T 154/04, OJ EPO 2008, 46).

Consequently, when starting from document D1, the objective technical problem to be solved is how to automatically provide selectable links in the text messages of D1 for the known street address, given the algorithm for detecting street addresses in a text according to features B to G and J to L of claim 1.

3.10 The claimed solution is a straightforward implementation in the mobile device known from D1 of the given algorithm for address detection, which the skilled person performs without exercising inventive skill. Consequently, the subject-matter of claim 1 of the main request lacks inventive step (Article 56 EPC).

First to third auxiliary requests - inventive step

4. The first to third auxiliary requests essentially add one or more of features AX1 to AX3 to the subject-matter of claim 1 of the main request (see above, points X. to XII.).

5. Regarding feature AX1, in its decision (see point 16.2) the examining division argued among other things that the issue of what to display when the link of the address was selected was non-technical.

5.1 In its statement of grounds of appeal (page 8, third and last paragraphs), the appellant argued that feature AX1 increased the "interactiveness of the resulting interactive text document" and that it interacted with the further features to provide a synergistic effect. It also submitted that the menu options did not relate to the presentation of information as such, but allowed the selection of further processing activities with the extracted address information. In the oral proceedings, the appellant further submitted that feature AX1 emphasised the linking aspect as the technical context for the address-detection steps of the method according to claim 1 of the first auxiliary request.

5.2 The board considers that the menu options according to feature AX1 relate to non-technical tasks. As the use of menus is common general knowledge, and the displayed options relate to non-technical tasks such as obtaining a name of a person associated with the address, the board does not see any synergistic technical effect to which feature AX1 contributes, or any non-obvious technical contribution.

6. The examining division considered that feature AX2 was obvious when starting from document D1 in view of document D8, which disclosed that hash functions were commonly used to speed up table lookup tasks.

6.1 In its statement of grounds of appeal (page 9, third paragraph), the appellant argued that feature AX2 increased the efficiency of identifying a text string corresponding to an address (see description, page 11, lines 24 to 30). In the oral proceedings, the appellant agreed that hashing was known, but argued that feature AX2 was based on an inventive application of hashing to compare data with data stored in a database as hashcodes. The effects of hashing according to feature AX2 were improved efficiency and a smaller storage requirement, which was important on a mobile device. According to the appellant, the database of addresses could have a large number of entries, and using the database of address indicators in the mobile device reduced the amount of storage space used in the mobile device.

6.2 The board notes that the claim does not mention where the database of addresses and the database of address indicators are stored. Moreover, the board considers that even if it is accepted that feature AX2 increases the efficiency of database lookups and thus the overall efficiency of identifying a text string corresponding to an address, and that hashing involves "further technical considerations", document D8 provides evidence that this was within common general knowledge of the skilled person. As explained in the oral proceedings, D8 (a Wikipedia article on hash functions published before the filing date of the application) explains on page 1, first and second paragraphs, that hash functions convert large amounts of data into a small datum such as a single integer and are used among other things for data comparison tasks such as finding items in a database. In this context, the board notes that the application itself (see the description, paragraph [0056]) does not disclose any details of the conversion of character strings into hashcodes, e.g. a specific hash function to be used in the context of the claimed invention. Hence, the application appears to assume that the skilled person is familiar with hashing and its application for database lookup. Moreover, the board considers that the use of hashcodes to save storage space (as disclosed in the description, paragraphs [0054] and [0056]) was well known as the hashcodes are usually integers, so the skilled person only obtains the usual advantage provided by hash functions.

In view of the above, at the filing date feature AX2 was an obvious implementation option when starting from document D1.

7. Regarding feature AX3, the appellant argued that this feature underlined the fact that the forward search was limited to the vicinity of an identified number, thus increasing the efficiency of the first step of address detection. Feature AX3 contributed to solving the single objective technical problem of deriving an interactive text document from a simple text document

in a reliable and efficient manner. The feature was not a well-known technique, but specifically created for the two-step pattern matching approach claimed. Consequently, feature AX3 was inventive.

7.1 In the board's view, feature AX3 is in the area of non-technical algorithmic improvements, since the underlying considerations for aborting the search are related to the format of street addresses, i.e. non-technical issues, rather than to "further technical considerations", as discussed above in more detail. In any case, even if feature AX3 were considered to contribute to the technical character of the invention, it would have been a straightforward routine development for the skilled person. In particular, it was obvious to consider stopping the search a number of words after identifying a number as a possible starting point of an address, because it was well known that the length of street addresses is generally limited to a small number of words.

8. As none of the features AX1 to AX3 can be a basis for acknowledging an inventive step, the subject-matter of claim 1 according to each of the first to third auxiliary requests lacks inventive step in view of document D1 (Article 56 EPC).

Fourth auxiliary request - admissibility

9. The fourth auxiliary request was filed for the first time with the appellant's reply to the board's communication, i.e. after oral proceedings had been arranged.

9.1 The appellant argued that, in its preliminary opinion, point 14.2.2, the board presented a fresh objection to feature AX2, i.e. the additional feature of the second auxiliary request (see above, point XI.), for the first time. In direct response to the board's fresh objection, the appellant had submitted its fourth auxiliary request to explicitly recite the comparing of the hashcodes with a database of address indicators that were stored as hashcodes. The appellant argued that the fourth auxiliary request should be admitted, because no new aspects were added to the appeal procedure: the claim element was merely reformulated to make use of the hashcodes more explicit.

Moreover, the amendments in the fourth auxiliary request had been filed in time before the oral proceedings and had no detrimental effect on procedural economy, since the board had already dealt with the inventive step of the claimed subject-matter in its preliminary opinion. Consequently, the new fourth auxiliary request did not fall under the strict regime of Article 13(2) RPBA 2020.

9.2 Contrary to the appellant's view, the board did not raise a fresh objection in its communication in point 14.2.2, but merely provided its preliminary interpretation of feature AX2 in relation to assessing inventive step. Thus, the board sees no exceptional circumstances that could justify admitting the fourth auxiliary request under Article 13(2) RPBA 2020. Consequently, the board does not admit the fourth auxiliary request into the appeal proceedings.