T 1201/10 (Personalised interactive automated marketing/JEAN-LUC ROCHET) 20-05-2019

1. Background of the invention

1.1 The invention relates to providing a user with information about a product when he or she inputs a product code into a mobile phone. The product code, called "MInfo code", is a unique alphanumerical code which is "integrated and visualised on each publication and advertisement of the product" (page 6, line 10 of the published application). A marketing website, called "MInfo portal", of a marketing service provider, maintains a marketing database with product data information. It receives the "MInfo code" per SMS via an SMS gateway from the mobile phone of the end-user and transmits the requested product data information to the end-user, page 6, lines 11ff. This can be by means of "modern communication tools", e.g. fax, e-mail and/or via the end-user's homepage on the marketing website, page 6, lines 14ff.

1.2 According to the appellant the invention does not require any prior set-up or registration on the part of the user. A user's account and webpage are accessible from the home page of the MInfo portal (computer), just by entering a user's mobile phone number (as authorisation data). There is no need for a user to set up an account with a username and password.

2. Article 123(2) EPC - "sending an SMS"

2.1 The feature "sending an SMS message to the end user's mobile phone" as an explicit step of the method of claim 1 of the main and auxiliary request does not find a basis in the application as filed.

2.2 The appellant presented Figure 1 as basis where a user's mobile phone is shown to send and receive SMS messages from a SMS gateway. The appellant argued that, while not explicitly described in the application, SMS messaging was a standard feature of mobile phones and its use in the method of claim 1 did not require further explanation. On the Board's request, the appellant explained that in the context of the claimed method, the SMS message contained the address of the MInfo portal computer to which the user made the subsequently specified connection from his or her PC.

2.3 In the Board's judgement, even if mobile phones were known to be capable of sending and receiving SMS messages, there is no basis for the specific "SMS sending" method step in the application, notably not in the claimed sequence and with the stated purpose. This feature is not directly and unambiguously derivable from the application as filed in the absence of any further information in the application. The schematic illustration in Figure 1 is not a sufficient basis.

2.4 The subject-matter of claim 1 of the main and auxiliary request therefore extends beyond the content of the application as filed, contrary to Article 123(2) EPC.

3. Interpretation of "user's mobile phone number" as authorisation data

3.1 The appellant argued that claim 1 of the auxiliary request implied a key feature of the invention that the end-user's phone number alone was used in the above-mentioned process for retrieving and accessing the product data information from the MInfo portal computer. However, in the Board's judgement, this does not find a basis in the application as filed.

3.2 In the summary of the invention, the original application, page 4, lines 13ff., discloses that the SMS gateway exchanges "authorisation data" with the "integral marketing website (MInfo portal)" computer by means of request related to the product data information, and later on, lines 18 to 19, that the connection between the PC and the MInfo portal computer initially commences by means of exchange of the authorization data such as phone number and name.

3.3 This is consistent with original claim 1 on page 9, lines 2 to 4, where "authorization data" is defined as a mobile phone number and name which is exchanged between an end-user's PC and the MInfo portal computer prior to transmitting product data information from the MInfo portal computer to the end-user's PC.

3.4 The Board concludes that the purpose of the user's mobile phone number and name serves only for establishing a connection between the user's PC and the MInfo portal computer, which implies that a user has to be registered with the MInfo portal computer in order to access product data information. This interpretation is justified in view of the use of the other means of modern communication, such as fax or email, which require the user's email and fax number to be known by the MInfo portal computer.

3.5 While Figure 1 illustrates that the phone number and MInfo code are "extracted" by the SMS gateway from a received SMS and thereafter sent to the MInfo portal computer, it cannot be derived that the user's mobile phone number represents the access "authorization data" used to view the personalised user homepage.

3.6 The Board does therefore not agree with the appellant that page 4, lines 16 to 19, of the original application provides a basis for the feature that the mobile telephone number alone is used to "unlock" the webpage containing the requested product information on the MInfo portal (computer).

3.7 The appellant argued that the feature was supported because the application did not explicitly disclose that a user has to be registered. However, the Board considers that this does not automatically imply that he does not, especially in view of the above mentioned fact that the application always mentions the user's mobile phone number in combination with the user's name. In fact, if the lack of registration was a key aspect of the invention, one would expect it to be described and explained in an embodiment of the invention. In the present application, however, the single embodiment described on page 6 does not mention authorisation at all.

3.8 The Board concludes that it cannot be directly and unambiguously derived that the "authorisation data" is only the mobile phone number and that the mobile phone number alone enables the user to view the personalised user home page.

4. Interpretation of "creating a personalized user homepage"

4.1 Claim 1 of both the main and auxiliary request contains a step of creating a personalized user homepage on the Minfo portal computer. Here again, claim 1 of the auxiliary request seems to suggest that access authorisation to this homepage is via the user's mobile phone number.

4.2 Firstly, the only basis for the creation of a personalised homepage is original claim 2. However, this claim only defines that a homepage is created by the end-user himself and not automatically, which is a possible interpretation of claim 1.

4.3 Secondly, the homepage requires both unspecified "personal data" and the mobile phone number in order to retrieve the requested product data information and to visualise it. The mobile phone number as the sole piece of information is not sufficient for retrieving the product data information. Moreover, there is no basis in the application as filed that the view of the personalised user home page depends on, or the access to it is limited by, the input of a user's mobile phone number alone.

4.4 The Board concludes that it cannot be directly and unambiguously derived that the creation of the personalised user homepage is automatic, or that access to it is possible using only the user's mobile phone number.

5. Main request - Article 56 EPC

5.1 The examining division took the position that claim 1 of the main request consisted of a mixture of technical and non-technical aspects to address a problem of a business nature, namely that consumers showed an unsatisfactory level of confidence in e-commerce, which required expensive conventional marketing operations, e.g. the advertisement of products in the media, printing of brochures and others. Furthermore, access to product data in prior art systems was time consuming. This, in summary, represented a marketing method.

5.2 The examining division then reasoned that the invention solved a business problem rather than a technical one by providing product codes, so-called MInfo product codes, which were unique for each product and which were integrated on each publication and/or advertisement of product appearance. Each code allowed a customer to indicate interest in information on the particular product identified by the product code.

5.3 The Board agrees that the provision of a unique code for the identification of product data is a marketing and business idea.

5.4 D2 also concerns a method for requesting and subsequently transmitting [product] data information stored in a database by an end-user by inputting a [product] code into a mobile phone, Figure 2, page 23, line 20ff.

The method comprises the steps of sending the alphanumerical [MInfo product] code in an SMS by the end user by using a mobile phone to an SMS gateway, page 23, lines 22 to 26, extracting by the SMS gateway of the [MInfo] code and the end user's phone number, lines 27 to 29, sending by the SMS gateway of said extracted code and phone number to the [MInfo] portal computer, lines 35 to 36, creating a personalised user homepage on the [MInfo] portal computer for which the access authorisation data is the user's mobile phone number, page 23, line 36 to page 24, line 7, providing of the [product] data information on the personalised user homepage upon the portal computer, page 24, lines 7 to 21, making connection between a user's PC and the [MInfo] portal computer by inputting the user's mobile phone number to enable the user to view the personalised user home page, page 24, lines 7 to 21, page 22, lines 1 to 10.

The introductory portion of D2 mentions that a user directly accesses with a code the webpage for a given product range, for example, telephones, see page 3, lines 1 to 9. For that purpose, the code, see page 4, second and third paragraphs, is associated with a URL which can be associated with "product data", see page 3, lines 1 to 9. The code can further be associated with specific data, for example, the data of a text or image of the print medium in which the code was printed; see also page 17, third paragraph. The code, see page 4, second paragraph, is any combination of numbers and letters, in machine-readable format and is printed on a print medium, such as a newspaper, catalogue or journal; it is included in a visual or audiovisual medium, like television, a homepage, online or offline services, or it is transmitted via audio channels. Whether this code is used as a product code and whether it is integrated on each publication and/or advertisement of a product appearance does not lead to a technical effect.

MInfo code / combination of embodiments

5.5 The appellant argued that claim 1 differed from D2 in that the invention employed a "unique code" for a given product. This reduced the number of database entries, improved efficiency and reduced storage space. The embodiment in Figure 2 of D2 did not disclose the provision of product information, but was rather a technique for the shortening of URL addresses. The code ("Kennung") in Figure 2 of D2 was therefore different from the code mentioned in the introductory part of D2. The appellant further argued that the embodiment in Figure 2 could not be combined with the introductory part of D2.

5.6 The Board disagrees. Both codes ("Kennungen") in Figure 2 and the introductory part of D2, have the same function and the person skilled in the art would combine the disclosure of the introductory part with the one of Figure 2.

5.7 The introductory part of D2, pages 2 to 21, describes the overall concept of simplifying the access to information by the use of alphanumeric codes ("Kennungen"). Each one of these codes is associated with specific information about a user, a product or the like and a URL to retrieve this information in a simplified way. The introductory part also mentions that these codes are integrated on publications, videos and the like. The code of D2 is unique ("eindeutig") for a given URL. The bridging sentence on pages 12 and 13 of D2 mentions that each keyword and each code exists only once. Page 18, lines 12 to 16, describes that each code exists only once.

5.8 Figure 2 illustrates a particular realisation of the overall concept of D2 in the form of a mobile telephone (8) which communicates by SMS via a mobile communication gateway (9) with a webserver (4). A user transmits codes ("Kennungen") by SMS to the webserver (4) which can also be accessed from a number of PCs (5, 6, 7). The webserver has a user-specific webpage for an authorized user which provides information which corresponds to a list of user-transmitted codes. The association between codes, URL and further information is retrieved from a database (3). The D2 code is stored on a server in a database table, see Figure 5, which includes the code, the associated URL and additional information, see page 22, lines 14 to 24. The advantage is that the URL and the additional information can be retrieved by using the code ("Ziffernfolge"). The server also stores in another database table, see Figure 4, and page 22, lines 2 to 9, the caller id (mobile phone number), the user name and his or her transmitted codes.

5.9 The appellant argued that the MInfo code was not the database keycode.

5.10 The Board does not see that there are two different codes existing in the present application; one attached to the product data and a different one for retrieving the product data stored in a database. The application, page 6, second paragraph, does not make such a distinction; the user inputs a "product code" which is the same as the one which is integrated and visualised on each publication.

Authorization data

5.11 The appellant further argued that the term "authorization data" did not correspond to the password in D2.

5.12 The Board disagrees. In the invention "authorization data" is exchanged between a user's PC and the MInfo portal, see page 9, lines 1 to 4, prior to transmitting requested product data from the marketing database server. The purpose of "authorization data" is to limit access to the product data. As discussed above, throughout the description, the feature "authorization data" is described "such as phone number and name". In D2, access to product data is restricted and the identification of a user and a password is required, see page 22, lines 9 to 14.

5.13 The appellant further argued that D2 did not disclose using a caller ID as "authorisation data". This had the advantage that a user is not required to register with the MInfo portal (computer) prior to requesting product information. The appellant also pointed out that the telephone number was known to the MInfo portal, but not the user name. No registration of a user was required.

5.14 The Board disagrees. As discussed above, the feature "authorization data" in the present application cannot be limited to a telephone number alone since the application always mentions telephone number and name of a user in combination. If, for the sake of argument, the term "such as phone number and name" implies two separate options, then access to product data would be possible by providing the name of a user. However, this would require prior registration of a user with the MInfo portal, because otherwise the portal would have no knowledge about which MInfo codes, sent by SMS from a specific phone number, correspond to the user who wants to view his personalised home page with the product data information.

Creation of a personalized webpage

5.15 As discussed above, the Board understands that the feature of creating a personalised user homepage does not imply additional access control which goes beyond the identification of the information requested. Furthermore, a personalised webpage is disclosed in D2, see page 22, lines 9 to 24. D2 even goes a step further as it discloses the use a password, bridging line between pages 23 and 24, or a user-id of the PC, page 24, lines 36f., for controlling access to the personalised user home page.

5.16 The appellant argued that there were two steps in the claimed method: first, the creation of a webpage by the user, and, second, its population with data. The feature "personalised webpage" meant a user-specific template with no data. The invention then operated with two steps; in a first step only the telephone number was provided, in a second step the telephone number and user name were provided. The user might also complete his or her profile data as part of the second step and provide an e-mail address, fax number and address for further information delivery. The invention aimed at reducing the number of interactions between a user and the information delivery system; it gave user a direct link to the information.

5.17 The Board does not agree. The arguments of the appellant are merely speculative, as he was not able to indicate a basis in the application as filed for such an interpretation. For example, the application does not disclose the use of user-specific templates. The Board interprets the invention - as the person skilled in the art would do - in light of the overall disclosure of the application.

5.18 The Board therefore concludes that claim 1 of the main request filed during appeal lacks an inventive step over D2 (Article 56 EPC) in combination with common general knowledge.

6. Rule 139 EPC

6.1 The appellant requested correction of the wording "number and name" to "number" throughout the description because this was an obvious error. He motivated this request with the explanation that it was at the heart of the invention to permit a user to directly access information by simply using his or her mobile telephone number without any registration.

6.2 The Board observes that for a correction to be allowable under Rule 139 EPC the presence of an error must be obvious in the sense that it is immediately evident that nothing else would have been intended. In addition, a correction is an amendment which has to comply with the requirements of Article 123(2) EPC (G 11/91). For the reasons set out in point 3 above, the Board concludes that these requirements have not been met. The request for correction thus has to be refused.