The application underlying this decision relates to the area of electronic communication, such as emails and the like. However, the European Patent Office refused to grant a patent that specifically deals with detecting street addresses in a message text. Here are the practical takeaways of the decision T 0504/18 (Linking an address/BLACKBERRY) of June 18, 2021 of Technical Board of Appeal 3.5.07:
According to the Board in charge, the claimed invention relates to linking an address in a message such as an email. The Board summarized the invention as follows:
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 ).
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  and ). 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 ).
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  and ).
Fig. 1 of EP 2 246 793 A1
Here is how the invention is defined in claim 1:
Claim 1 (main request - numbering added by the Board)
[A] A computer-implemented method (400, 700) for use on a mobile device comprising a display, the method comprising on the mobile device:
[B] searching a text, wherein said searching comprises:
[C] finding a number in the text,
[D] when the number is found, searching forward in the text within a predetermined number of words of the number,
[E] identifying at least two character strings during said search forward, each character string being of a different predefined address indicator type (120), and
[F] selecting a segment of the text including the number and said at least two character strings;
[G] assessing whether or not the segment comprises an address (130);
[H] displaying the segment on the display of the mobile device (150); and
[I] if the segment is assessed as comprising an address, including a link for display, the link pointing to at least one application (140),
[J] wherein assessing whether or not the segment comprises an address comprises:
[K] determining a probability that the segment comprises a valid address based on at least: a number of character strings of different predefined address indicator types within the segment, a number of character strings of different predefined address indicator types within the segment that are cross-referenced in a database, and proximities of the at least two character strings to each other; and
[L] if the probability is above a threshold probability, assessing the address as valid;
[M] further comprising configuring the link to start an application to present a menu of options related to the address on the display, when selected.
Is it technical?
During the oral hearing, both the Board in charge and the Appellant agreed that the closest prior art document D1 fails to teach how the links for the street addresses are generated. This is because D1 lacks any disclosure about an algorithm that is capable of detecting street addresses in text. However, according to the Board, detecting street addresses in text would not be technical:
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.
To convince the Board, the Appellant argued that including links in the text of a message would make the message interactive, rendering it technical:
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, according to the Appellant, the structure of the claimed algorithm to generate the links would be efficient due its specific 2-step structure and thus would involve further technical considerations. To substantiate its position, the Appellant pointed to a decision of 1992:
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).
However, the Board did not follow the arguments of the Appellant. First of all, the Board expressed that the findings of T 769/92 would be obsolete in view of G 3/08. Furthermore, the alleged improved efficiency could only provide a further technical effect if it is based on further technical considerations, which would not be the case here:
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.
Therefore, according to the Board, features B to J and feature G of claim 1 of the main request, relating to the algorithm for generating links of the addresses in the text of the message, have to be considered non-technical and thus have to be ignored for the assessment of inventive step:
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.
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.
Since all other features are known from D1, as a result, the appeal was dismissed due to lack of inventive step within the meaning of Article 56 EPC.
You can read the whole decision here: T 0504/18 (Linking an address/BLACKBERRY) of June 18, 2021