The European Patent Office refused to grant a software patent on a method of providing a unique code for identifying product data. Here are the practical takeaways of the decision T 1201/10 (Personalised interactive automated marketing/JEAN-LUC ROCHET) of 20.5.2019 of Technical Board of Appeal 3.5.01:

Key takeaways

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

The invention

This European patent application 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, also called “MInfo code”, is a unique alphanumerical code which is integrated and visualised on each publication and advertisement of the product. 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. This can be done by means of “modern communication tools”, e.g. fax, e-mail and/or via the end-user’s homepage on the marketing website.

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.

Fig. 1 of EP 1 402 441
Fig. 1 of EP 1 402 441

Here is how the invention is defined in claim 1 (main request):

  • Claim 1 (main request)

Is it technical?

The first-instance 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.

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.

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

Concerning specifically the differences over the closest prior art as argued by the appellant, the Board took the following view:

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 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.

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

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.

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

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.

The Board therefore concluded that claim 1 of the main request lacks an inventive step over D2 in combination with common general knowledge.

More information

You can read the whole decision here: T 1201/10 (Personalised interactive automated marketing/JEAN-LUC ROCHET) of 20.5.2019

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy *
* = Required field

Please share this article if you enjoyed it!