T 1414/10 (Accessing data tags/SAP) of 23.3.2015

Summary of Facts and Submissions

I. The applicant (appellant) appealed against the decision of the Examining Division refusing European patent application No. 04014443.8.

II. The Examining Division decided that the subject-matter of claim 1 of both a main request and an auxiliary request lacked inventive step in view of the following documents:

D1: US-B1-6 172 596; and

D2: US-B1-6 400 272.

III. With the statement of grounds of appeal, the appellant filed a main request and first to fourth auxiliary requests. The main request corresponded to the main request considered in the decision under appeal.

IV. In a communication accompanying a summons to oral proceedings, the Board expressed the provisional opinion that the subject-matter of claim 1 of each request either was not new or lacked inventive step in view of document D1.

V. With a letter dated 27 January 2015, the appellant replaced its substantive requests with a new main request and new first to third auxiliary requests.

VI. With a letter dated 19 March 2015, the appellant informed the Board that it would not attend the oral proceedings.

VII. Oral proceedings were held on 23 March 2015 in the absence of the appellant. At the end of the oral proceedings, the chairman pronounced the Board's decision.

VIII. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the claims of the main request or, in the alternative, on the basis of the claims of one of the first to third auxiliary requests.

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

"A computer-implemented method for mapping data between a wirelessly accessible data carrier, and a database application using a mapping interface, comprising:

- exchanging messages compliant to a data carrier query protocol with the data carrier via a wireless interface;

- exchanging queries compliant to a database query protocol with a database application via a database interface, the database query protocol being a structured query language (SQL) protocol;

- reading a mapping definition;

- exchanging data between the wireless interface and the database interface by mapping between the queries and the messages within the mapping interface using the mapping definition; and,

- storing the mapping definition separately from the mapping interface thus providing separation between the mapping interface and the mapping definition,

wherein said exchanging data between the wireless interface and the database interface including [sic]:

providing the data of a data carrier to the database interface formatted as database data;

providing data of the data carrier as one row of a database to the database interface; and

providing a defined byte area of the data carrier as one column of a respective row to the database interface."

X. Claim 1 of the first auxiliary request differs from claim 1 of the main request in the addition of the following text at the end of the claim:

", and

wherein the mapping definition is stored within the data carrier and wherein the mapping definition is read from the data carrier."

XI. Claim 1 of the second auxiliary request differs from claim 1 of the main request in the addition of the following text at the end of the claim:

"wherein the mapping definition is stored within the data carrier and wherein the mapping definition is read from the data carrier, and

wherein the mapping definition defines how to map messages between the data carrier query protocol and the database query protocol."

XII. Claim 1 of the third auxiliary request differs from claim 1 of the main request in the addition of the following text at the end of the claim:

"wherein the mapping definition is stored within the data carrier and wherein the mapping definition is read from the data carrier,

wherein the mapping definition defines how to map messages between the data carrier query protocol and the database query protocol, and

wherein the mapping definition provides mapping information for mapping certain data blocks with the data carrier onto application fields within the database application."

Reasons for the Decision

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

2. The invention

2.1 The invention relates to communication between software applications and physical data carriers (or data tags) storing wirelessly accessible data. Examples of such tags are radio-frequency identification (RFID) tags. Conventionally, applications exchange data with a data tag using a known wireless communication protocol. Since different data tags use different wireless technologies and protocols, applications may need to support many different protocols, each protocol requiring a dedicated implementation.

2.2 The present invention aims to provide applications with access to data tags using a "standard database query protocol". To this end, a "mapping interface" is provided. The mapping interface exchanges "messages" with the data tag via a wireless interface using a data carrier query protocol and exchanges "queries" with software applications via a database interface using a database query protocol. In order to convert between messages and queries, a "mapping definition" is used. This mapping definition is stored separately from the mapping interface, thus providing separation between the mapping interface and the mapping definition.

3. The term "mapping definition"

3.1 According to page 6, lines 21 to 23, of the description of the application as filed, a mapping definition "may define how to map messages between the data carrier query protocol and the database query protocol". A similar statement is made on page 25, lines 2 to 4. These passages suggest that a mapping definition somehow completely defines how a message formatted in accordance with a particular data carrier query protocol is to be transformed into a message formatted in accordance with a particular database query protocol, and vice versa.

3.2 However, this suggestion is not confirmed by the exemplary mapping definition shown in Figure 5. According to the description on page 27, lines 6 and 7, Figure 5 depicts an XML file with a mapping definition for the memory layout shown in Figure 4. As explained on page 26, lines 1 to 14, Figure 4 depicts a table with the memory layout of an exemplary data carrier. This data carrier stores 32 bytes numbered from 0 to 31. The memory layout defines a mapping between groups of bytes and (names of) data fields (or "application fields"). For example, bytes 0 to 7 correspond to a data field named "EQUINR" and bytes 8 and 9 correspond to a data field named "LASTDAMCODE". The mapping definition shown in Figure 5 correspondingly defines a field named "EQUNR" (evidently containing a typographical error), which starts at byte 0 and is 8 bytes in length, and a field named "LASTDAMCODE", which starts at byte 8 and is 2 bytes in length.

The mapping definition shown in Figure 5 hence defines a mapping between blocks of bytes stored in a data carrier and (names of) data fields. This mapping definition is essentially the memory layout shown in Figure 4 encoded in XML. While it is easily seen that this mapping definition may be used by the mapping interface to map messages between the data carrier query protocol and the database query protocol, as it provides the information necessary for locating, within the bytes stored in a data carrier, the data bytes corresponding to the data fields being requested, the mapping definition, being merely a specification of a memory layout, does not completely define a transformation from data carrier query protocol messages into database query protocol messages. In particular, the mapping definition shown in Figure 5 is independent of the specific database query protocol used.

3.3 Since the application as filed contains no other detailed disclosure of a mapping definition, the Board will interpret this term in accordance with the above considerations as a data structure defining a mapping between blocks of bytes stored in a data carrier and data fields.

4. Main request - inventive step

4.1 The Examining Division considered document D1 to be the closest prior art. The appellant has not contested this choice and the Board agrees with it.

4.2 Document D1, column 3, lines 23 to 35, discloses a base station configured to wirelessly communicate with a number of different types of tag. Tags may differ in hardware type in that they use a different physical means of communication or a different modulation method (column 3, lines 58 to 65). In a preferred embodiment, tags use the same physical means of communication and the same modulation method, but have different amounts of read/write memory and/or different functional capabilities (column 3, line 66, to column 4, line 4). In this embodiment, tags of different types use different protocols for storing information in the tag memory. Each tag stores a "tag type number", which identifies the layout of the information in the memory of the tag, as well as hardware characteristics of the tag such as the amount of memory the tag holds and the command set recognised by the tag. See column 4, lines 16 to 29.

Document D1, column 7, lines 35 to 57, explains that a base station communicates with a tag by first reading its tag type number. On the basis of this number, it looks up the protocol for communicating with the tag. This protocol is stored in the base station in the form of a "memory map" and hardware configuration of the tag type. According to column 9, lines 5 to 14, the memory map is used to interpret data going to or coming from the tag, which would be impossible to do "[w]ithout knowing where data fields reside in the tag memory".

4.3 In terms of claim 1, the base station of document D1 wirelessly exchanges "messages compliant to a data carrier query protocol" with a data tag. This implies the presence in the base station of a "wireless interface".

In addition, the base station reads a "mapping definition" in the form of a memory map on the basis of the tag's tag type number. This memory map defines where data fields reside in the tag memory and is therefore indeed a "mapping definition" within the meaning of claim 1 (cf. points 3.23.2 and 3.33.3 above).

The software routines in the base station performing the retrieval of the memory map and the interpretation of data going to or coming from the tag by means of the memory map correspond to the claim's "mapping interface". The memory map is a separate data structure that is not part of these routines, so may be considered to be stored "separately from the mapping interface", thereby "providing separation between the mapping interface and the mapping definition".

4.4 The focus of document D1 is on the communication between data tags and the base station. Although it envisages the use of this base station in various business settings (see e.g. Figures 7A and 7B), it does not discuss the exchange of data between the base station and (business) applications. For the skilled person it is nevertheless obvious that if the base station of document D1 is used in a business setting, it is connected to at least one (business) application that reads data from and/or stores data in data tags. This application then communicates with the "mapping interface" by exchanging messages using a suitable protocol.

4.5 According to claim 1, the application is a "database application". In the context of the present invention, the term "database application" is not to be understood as a "database" or database management system, but as an application that accesses one or more databases. Indeed, the description of the present application on page 6, lines 8 to 15, explains that database applications include business applications. Examples of such applications include product life cycle management and supply chain management applications (page 3, lines 1 to 3).

Since business applications typically access databases, this claim feature is obvious in itself.

4.6 Claim 1 further specifies that the messages are "queries compliant to a database query protocol" which are exchanged "via a database interface". In addition, the database query protocol is "a structured query language (SQL) protocol" and the exchange of data includes:

- providing the data of a data carrier to the database interface formatted as database data;

- providing data of the data carrier as one row of a database to the database interface; and

- providing a defined byte area of the data carrier as one column of a respective row to the database interface.

The Board observes that, as a consequence of these features, the mapping interface exchanges "data between the wireless interface and the database interface by mapping between the queries and the messages using the mapping definition" as further required by claim 1. Indeed, the database application reads data from and/or stores data in data tags by exchanging queries with the mapping interface, and the mapping interface responds to these queries by exchanging appropriate messages with the data carrier. In this process, the mapping interface "uses the mapping definition" in the sense that it uses the memory map for interpreting data going to or coming from the data carrier (cf. points 3.23.2 and 3.33.3 above).

4.7 The differences listed in the previous paragraph follow in a straightforward manner from the choice of the SQL database query protocol as the protocol for exchanging messages between the (database) application and the mapping interface included in the base station. In fact, it is common general knowledge that an SQL query returns a result table which inherently is "formatted as database data" and comprises rows and columns, the rows corresponding to data records and the columns corresponding to fields of the data records. When querying a data tag of document D1, it is obvious to regard the data stored in the data tag as a record comprising a number of fields, each field corresponding to a byte area of the data tag. Indeed, the data tags of document D1 store a number of data fields organised as a series of bytes (see document D1, column 5, lines 1 to 26).

4.8 Hence the assessment of inventive step comes down to the question whether it was obvious to select the SQL database query protocol as the protocol for exchanging messages between the (database) application and the base station of document D1.

4.9 The appellant essentially argued that document D1 did not suggest using the SQL database query protocol and that many other options were available to the skilled person. He could, for example, have selected a protocol that had nothing to do with database queries. Since many implementations were possible, the skilled person would not have been led to the subject-matter of claim 1.

However, the mere fact that other solutions were at the disposal of the skilled person does not imply that the choice of a particular one is non-obvious. In addition, while it is true that document D1 is silent on the use of the SQL protocol, account must also be taken of the common general knowledge of the skilled person.

4.10 It is undisputed that the SQL database query protocol was well known at the filing date of the present application. This is confirmed on page 2, first full paragraph, of the present application, which states that SQL is a standardised database query protocol. In addition, database query protocols are suitable for exchanging data with any data source.

The skilled person was hence aware of the SQL protocol and the technical feasibility of using it as the protocol for exchanging messages between an application and the base station of document D1. It follows that the specific choice of the SQL protocol amounts to the obvious use of a known measure to achieve a known result, unless this choice in the context of the claimed invention results in an unexpected technical effect.

The description of the present application does not disclose such an effect, and in its submissions the appellant did not suggest one either. The only effect of the choice of the SQL protocol that the Board is aware of is improved compatibility with existing database applications. However, this is the expected advantage of the use of a standardised protocol.

4.11 The Board therefore concludes that the subject-matter of claim 1 lacks inventive step (Articles 52(1) and 56 EPC).

5. First auxiliary request - inventive step

5.1 Claim 1 of the first auxiliary request adds to claim 1 of the main request that the mapping definition is stored within the data carrier and that the mapping definition is read from the data carrier.

5.2 Document D1, column 9, lines 15 to 28, discloses an embodiment in which tags that have sufficient tag memory and sufficient processing power in their tag logic section carry a directory of the information that they contain. The base station accesses these tags by sending a command to read or write a field having a particular name. The tag contains the logic necessary for looking up that name in the directory in order to locate the location in tag memory where the field is stored.

Document D1, column 9, lines 29 to 39, explains that a less costly way of ensuring that data is read from and written to the right memory location is to use the tag type to specify a memory mapping essentially as discussed in point 4.24.2 above, since that approach requires the necessary intelligence to be present in the base station rather than the more numerous tags. This paragraph then mentions that in order to allow the base station to work with a mixed group of tags "the 'smart' tags which carry their own memory maps or directories would still need to carry a tag type number, which would inform the base station of the 'smart' tag's capabilities".

This passage hence discloses "smart" data tags that store memory maps.

5.3 The appellant submitted that, although the memory maps or directories of smart tags indicated the location in the tag memory where each field is stored, this information enabled neither mapping between queries compliant to an SQL protocol and messages compliant to a data carrier protocol, nor provision of data formatted as database data.

However, as explained in points 3.13.1 to 3.33.3 above with reference to Figures 4 and 5 of the application, the mapping definition of the present application is essentially indistinguishable from such a memory map and, in particular, is independent of the database query protocol used. The mapping interface uses the mapping definition to read data fields from (and write to) the data carrier; the mapping definition does not contain information relevant to formatting retrieved data fields as "database data" in compliance with the SQL protocol.

From this it also follows that the features added to claim 1 of the first auxiliary request do not interact with the distinguishing features discussed in relation to the main request. They can therefore be treated separately in the assessment of inventive step.

5.4 As the appellant pointed out, storing the mapping definition within the data carrier has the advantage that no "central storage" is required for the mapping definition. In addition, this feature has the clear advantage that introducing a new type of data carrier does not require the separate provision of a corresponding mapping definition; the mapping definition comes automatically with the data carrier. However, these advantages are also achieved, and in the same manner, by the smart tags of document D1.

5.5 The difference between the method of claim 1 and the "smart tag" embodiment discussed in column 9, lines 15 to 39, of document D1 is that the memory maps stored in the smart tags are not read by (the mapping interface software routines included in) the base station. Instead, the smart tags themselves contain the mapping logic necessary for mapping data fields to memory locations.

Nevertheless, since the same passage also discloses that it is less costly if the base station contains both the memory map and the logic for mapping data fields to memory locations on the basis of the memory map, the Board considers that the skilled person would, as an obvious trade-off, consider keeping the memory maps in the data tags and equipping the base station of document D1 with the required mapping logic and the ability to read these memory maps from the data tags.

5.6 The subject-matter of claim 1 of the first auxiliary request hence lacks inventive step (Articles 52(1) and 56 EPC).

6. Second and third auxiliary requests - inventive step

6.1 Claim 1 of the second auxiliary request adds to claim 1 of the first auxiliary request that the mapping definition "defines how to map messages between the data carrier query protocol and the database query protocol".

As explained in points 3.13.1 to 3.33.3 above, in the light of the description this feature is to be understood as meaning that the mapping interface uses the mapping definition to locate, within the bytes stored in a data carrier, the data bytes corresponding to the data fields being requested. This feature is hence disclosed in document D1 (see point 4.34.3 above).

6.2 Claim 1 of the third auxiliary request further adds that the mapping definition provides mapping information for mapping certain data blocks with the data carrier onto application fields within the database application.

Since the mapping definition of document D1 defines where data fields reside in the tag memory (see column 9, lines 5 to 14), this feature likewise does not further distinguish the claimed invention from what is disclosed in document D1.

6.3 The subject-matter of claim 1 of the second and third auxiliary requests hence likewise lacks inventive step (Articles 52(1) and 56 EPC).

Conclusion

7. Since none of the requests on file is allowable, the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.