T 0984/15 (Configuring proximity indication/HTC) of 8.9.2020

Summary of Facts and Submissions

I. This case concerns the appeal filed by the opponent against the interlocutory decision of the opposition division to maintain the opposed patent in amended form on the basis of the claims of a "second auxiliary request".

II. The appealed decision made reference inter alia to the following prior-art document:

O1: 3rd Generation Partnership Project; Technical

Specification Group Radio Access Network; Evolved

Universal Terrestrial Radio Access (E-UTRA) Radio

Resource Control (RRC); Protocol specification

(Release 9); 3GPP TS 36.331 V9.1.0; (2009-12).

III. Oral proceedings before the board were held on 8 September 2020.

- The appellant (opponent) requested that the decision under appeal be set aside and that the patent be revoked.

- The respondent (proprietor) requested that the appeal be dismissed.

At the end of the oral proceedings, the board's decision was announced.

IV. Claim 1 of the patent as maintained by the opposition division reads as follows:

"A method for configuring proximity indication reporting in a wireless device (100) as part of an inter-radio access technology, inter-RAT, handover, HO, procedure, the method comprising:

receiving a HO command (408), containing a

message (406) generated by a second RAT system (204), at a first RAT system (202) as part of an inter-RAT handover procedure to hand over the wireless device (100) from the first RAT system (202) to the second RAT system (204),

wherein the message (406) contains a plurality of

data sets (502-508),

wherein a first data set (502) of the plurality

of data sets contains information to hand over the wireless device (100) from the first RAT system (202) to the second RAT system (204), and

wherein a second data set (504) of the plurality

of data sets contains proximity indication reporting information to configure proximity indication reporting in the wireless device (100) as part of the inter-RAT handover procedure; and

as part of the Inter-RAT handover procedure, in

response to receiving the message (406), the wireless device (100) configures the proximity indication reporting; and

performing a handover of the wireless device (100)

from the first RAT system (202) to the second RAT system (204);

wherein the second RAT system (204) is an E-UTRAN system."

Reasons for the Decision

1. Claim 1 - Novelty (Article 54 EPC) in view of O1

1.1 Claim 1 of the opposed patent as maintained by the opposition division evidently relates to an inter-RAT (radio access technology) handover procedure. The board agrees with the opposition division and the respondent that the method for configuring "proximity indication reporting" is disclosed in section 5.3 of the technical specification O1 only for an intra-RAT handover procedure. Section 5.4 of O1 addresses the inter-RAT scenario, but does not touch upon the issue of "proximity indication reporting".

1.2 In particular, the method for configuring proximity indication reporting in a wireless device as part of the handover procedure as disclosed in section 5.3.5.4 of O1 does not mention specifically inter-RAT handover. On the other hand, the method for inter-RAT handover described in section 5.4.2 of O1 does not mention specifically the presence of proximity indication reporting information in a RRCConnectionReconfiguration message and the subsequent configuration by the wireless device. Hence, O1 separately discloses a method for configuring proximity indication reporting in a wireless device as part of a handover process, on the one hand, and a method for inter-RAT handover, on the other hand.

1.3 According to the established case law, an alleged disclosure can only be considered "implicit" if it is immediately apparent to the skilled person that nothing other than the alleged implicit feature forms part of the subject-matter disclosed. In this case, even if the optional character of the "reportProximityConfig-r9" might suggest its combination with other fields present in the RRCConnectionReconfiguration message, this alone - contrary to the appellant's view - cannot amount to a direct and unambiguous disclosure of its appearance in the RRCConnectionReconfiguration message specifically used in the intra-RAT handover procedure according to section 5.4 of O1.

1.4 The subject-matter of present claim 1 is therefore new (Article 54(1) and (2) EPC) in view of O1.

2. Claim 1 - Inventive step (Article 56 EPC) in view of O1

2.1 O1 as starting point

Document O1 is a 3GPP (3rd Generation Partnership Project)-related technical specification readily available and specifically describing the use of "RRC connection reconfiguration messages" for proximity indication and for inter-RAT handover, which corresponds to the background art provided in the underlying application (see paragraphs [0003] and [0004] of the description as published). There exists thus a reasonable expectation as to the use of this document as a basis for further developments.

This point has not been challenged by the respondent.

2.2 The person skilled in the art

2.2.1 In the case at hand, it is particularly important to establish which attributes can be ascribed to the notional person skilled in the art within the meaning of Article 56 EPC.

2.2.2 As to the relevant person skilled in the art, the appellant indicated in their statement of grounds of appeal the following (see section IV.19; board's emphasis):

"The patent opposed thus is directed to a person of average skill in the art, i.e. an expert in the field of telecommunications engineering, who typically is a graduate engineer in electrical engineering, physics or informatics with a focus on telecommunications and has several years of practical experience in the field of communication networks, e.g., in a development department of a company specialized in this field. Thus, the skilled person has a fundamental theoretical understanding and a broad knowledge regarding the implementation of such theoretical knowledge. An implementation may comprise, e.g., development and/or testing of hardware and/or software. The skilled person is also able to work with and understand the telecommunication standards, in particular the technical specifications of the 3rd Generation Partnership Project. He is aware of the interrelation of various documents belonging to the same technical sphere of a standard. He can be a member of the 3GPP RAN (Radio Access Network) Working Group 2 dealing with the Evolved Universal Terrestrial Radio Access (E-UTRA), in particular handover mechanisms between various radio access technologies."

2.2.3 The respondent argued that the relevant skilled person would be an engineer in telecommunications who is familiar with existing wireless communications systems and who might have some knowledge of new technologies, but no detailed knowledge of the upcoming LTE standard.

2.2.4 In that context, the board recalls that the technical field and general knowledge associated with the notional skilled person within the meaning of Article 56 EPC should be defined on the basis of the objective technical problem to be solved by that skilled person in the framework of the problem-solution approach. This is because the skilled person under Article 56 EPC is the person qualified to solve the established objective technical problem (see e.g. T 32/81, OJ 1982, 225, Reasons 4.2; T 422/93, OJ 1997, 25, headnote I; T 1140/09, Reasons 4.4; T 1523/11, Reasons 4.4; T 1450/16, Reasons 2.1.4). Therefore, the board will revisit this issue when the objective technical problem has indeed been established in this case (see point 2.5 below).

2.3 Distinguishing features

It follows from the preceding novelty analysis that the subject-matter of claim 1 differs from O1 in that:

(i) configuring proximity indication reporting is specifically done as part of an

inter-RAT handover procedure.

2.4 Technical effect and objective technical problem

2.4.1 The technical effect achieved by distinguishing feature (i) is that it avoids multiple separate messaging instances to handover the UE to the second RAT system, i.e. the EUTRAN, and to configure the UE to report proximity indications, reducing the time and power consumption required (see paragraph [0009] of the underlying application as published).

2.4.2 The objective technical problem to be solved can thus be framed as "how to reduce the delay and power consumption required to handover the UE from one RAT system to another one in the inter-RAT system of O1."

2.5 Definition of the person skilled in the art

In view of this objective technical problem, the notional skilled person, for the purpose of assessing inventive step under Article 56 EPC, is a telecommunications engineer working in the field of 3GPP-based mobile networks.

The board does not agree with the quite limited set of skills attributed to the skilled person by the respondent and rather concurs with the appellant that the skilled person could even be a member of the 3GPP RAN Working Group 2.

2.6 Could-would approach

2.6.1 The solution proposed in claim 1 of the patent as maintained cannot be considered to involve an inventive step (Article 56 EPC), for the following reasons:

2.6.2 The skilled person starting from document O1 and seeking to reduce the delay and power consumption incurred by an inter-RAT handover according to section 5.4 of O1 would have noticed that sending a first RRCConnectionReconfiguration message to trigger the handover procedure and sending a separate RRCConnectionReconfiguration message to signal the proximity indication reporting to the UE entails an overhead that substantially increases delays and power consumption. Accordingly, the skilled person attempting to avoid the overhead created by the use of the separate messages for configuring proximity indication reporting and for performing inter-RAT handover not only could but also would have considered including proximity indication reporting information in the RRCConnectionReconfiguration message received by the wireless device as part of the inter-RAT handover procedure.

Moreover, in response thereto, the skilled person would likewise have envisaged configuring the proximity indication reporting, using the same technique already known from the RRCConnectionReconfiguration message disclosed for general (same-RAT) handover and arriving thereby at the subject-matter of claim 1 without the involvement of any inventive skills. Put differently, the skilled person being aware from section 6 of O1 that the RRCConnectionReconfiguration message (optionally) includes a "reportProximityConfig-r9" data field (see page 102), would have immediately noticed that the following technical instruction, taken from the intra-RAT case as described in section 5.3.5.4 and being made up of two lines, is to be applied to the inter-RAT case in order to solve the above objective problem:

"1> if the RRCConnectionReconfiguration message includes the reportProximityConfig:

2> perform the proximity indication procedure as specified in 5.3.5.7;".

2.6.3 The respondent argued that the skilled person starting out from O1 would have had no motivation to diverge from the "two-step approach" presented in this document for inter-RAT communication and would have looked into different prior-art documents instead. Furthermore, the "one-step approach" proposed in claim 1 could not be achieved without hindsight, because handover was just one of many possible applications of the RRCConnectionReconfiguration message.

In addition, intra-RAT handover was much simpler than inter-RAT handover, and therefore the skilled person would not find it evident that the proximity indication mechanism used for intra-RAT handover could be also applied to inter-RAT handover. The respondent further submitted that, when the RRCConnectionReconfiguration message was used in section 5.4 for the inter-RAT handover procedure, the "reportProximityConfig-r9" field was not present. The description in O1 was written in a way to specify what actions the UE shall perform, which implied that the UE should not perform an action not listed in a particular section for a particular functionality. Even though the "reportProximityConfig-r9" field was specified in the message format of RRCConnectionReconfiguration message, the skilled person would have followed the texts specified in sections 5.3.5.4 and 5.4.2.3 to capture how to use the RRCConnectionReconfiguration message for the different functionalities (i.e. intra-LTE handover and inter-RAT handover to LTE, respectively).

In other words, the skilled person would have known that the "reportProximityConfig-r9" field was not used in the inter-RAT handover to an LTE-based RAT when following section 5.4.2.3 of O1. On the other hand, the skilled person would have been aware that the "reportProximityConfig-r9" field was used in the intra-LTE handover procedure when following section 5.3.5.4 of O1. Thus, the skilled person would have used the two-step approach as described above to configure the proximity configuration for the UE.

2.7 The board is not persuaded by these arguments. It is first noted that adapting or improving a certain proposal to a telecommunications standard in view of all likely scenarios (such as intra-RAT, inter-RAT, etc. in this case) constitutes a task with which a skilled person working in the field of 3GPP-based wireless systems may have reasonably and realistically be faced at the patent's priority date (see T 1439/13, Reasons 2.2.5).

Moreover, section 6, pages 102 and 103, of O1 defines a common message format in which only certain elements are specific to the handover type (see e.g. "SecurityConfigHO", which presents two alternatives according to the value of handoverType). Even if this cannot be considered to necessarily imply a proximity indication in RRCConnectionReconfiguration messages used in inter-RAT HO (see point 1.3 above), the common message format makes apparent, at the very least, that this could well be done, i.e. that the message format is capable, without further modification, of supporting the presence of the "reportProximityConfig-r9" field likewise in the RRCConnectionReconfiguration message used for inter-RAT HO.

2.8 As to whether or not the skilled person confronted with the defined objective technical problem would actually arrive at this solution without hindsight, the respondent implied that the UE shall not perform an action not listed in a particular section of the relevant technical specification for a particular functionality.

This is not convincing.

- First, absolute prohibitions in a technical specification are explicitly indicated by means of the terms "MUST NOT" or "SHOULD NOT", rather than being merely implied.

- Second, the primary purpose of a technical specification stemming from a standardisation group is to provide interoperability between products from different vendors. Standardisation groups are not to be equated with research institutions, nor are technical specifications written for the same purposes as research papers. Instead, technical solutions are introduced in the technical specifications on the basis of their degree of acceptance among the group members rather than on their originality.

The fact that something is not explicitly disclosed, or even that it is explicitly prohibited, in a technical specification must not be necessarily interpreted as a prejudice of technical nature. There might be other non-technical reasons, such as circumventing a patented technology or simply lack of time in the meetings for further discussions that led the drafting group to dismiss or ignore an otherwise valid technical option. The skilled person is well-aware that performing obvious modifications in a technical specification could result in a working device which does no longer conform to the specification and, as a consequence, cannot interoperate with legacy devices.

2.9 In conclusion, the fact of O1 being a technical specification drafted by a standardisation group would not deter the skilled person from carrying out obvious improvements of that specification. Thus, the technique used in section 5.3.5.4 of O1 for intra-RAT handover presents itself as the most obvious manner to optimise also the inter-RAT handover procedure of section 5.4.2 of O1.

3. Hence, the patent as maintained by the opposition division cannot be upheld under Article 56 EPC.

4. As there is no allowable set of claims, the opposed patent must be revoked.

Order

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The patent is revoked.