T 2764/19 (Header-embedded control data/STARKEY) 11-06-2021

1. Technical background

The invention underlying the opposed patent concerns wireless communications, in particular audio streaming, between, for instance, hearing aids and a remote control as shown in the drawing below. According to the patent's description, it relates to the technical problem of how to allow for new forms of content and communication within the context of wireless packet transmission involving a so-called "packet protocol" relating to data packets made up of a header and a payload section. This technical problem is addressed by embedding audio control and status information in the header.

FORMULA/TABLE/GRAPHIC

2. Main request: claim 1 - feature labelling

Claim 1 of the main request, i.e. claim 1 as granted, comprises the following limiting features (as labelled by the board):

(a) A system for radio communications of audio information from a remote source, comprising:

(b) a plurality of wireless hearing aids each having a microphone and a radio receiver for reception of communications,

(c) the plurality of hearing aids configured to receive information relating to a mute state and configured to generate an output signal based upon at least the mute state, the mute state specifying that the output signal is either: (i) the audio information, the output of the microphone being muted; or (ii) an output of a microphone of the hearing aid, the audio information being muted; or (iii) the audio information blended with the output of the microphone of the hearing aid,

(d) an interface including a first port adapted to receive the audio information from the remote source, a second port adapted to wirelessly communicate the audio information to the plurality of wireless hearing aids,

(e) the interface including digital electronics to provide a plurality of packet transmission modes and providing at least one packet protocol comprising a header including embedded data used to provide a plurality of bits for control and status information to one or more of the plurality of hearing aids.

3. Main request: claim 1 - inventive step

3.1 Claim construction

3.1.1 Claims of a European patent application are typically directed to a reader skilled in the field (and aware of the respective terminology) of that application (i.e. the field of hearing aids in this case). Consequently, given that such a technically skilled reader does normally not need any further description-based guidance, claims should essentially be read and interpreted on their own merits, rather than with the aid of the description and drawings as suggested by appellant I (see e.g. T 223/05, Reasons 3.5; T 1404/05, Reasons 3.6; T 1127/16, Catchword 1). When doing so, the wording of the claims should typically be given its broadest technically sensible meaning by such a skilled reader.

In the current case, this means that the listed alternatives for the mute state in feature (c) do not require all three alternatives (i) to (iii) to be present: to anticipate the subject-matter expressed by the listed alternatives, it suffices when one alternative is shown. Contrary to what is asserted by appellant I, the term "specifying" of feature (c) does not imply that all three alternatives are mandatorily present: the skilled reader would readily understand that the "mute state" of feature (c) can specify, for instance, that the "output signal" according to this feature constitutes invariably alternative (iii), where the audio information is blended with the output of the microphone of the hearing aid.

Hence, the board endorses the interpretation of granted claim 1 adopted in point 12.1 of the reasons of the decision under appeal regarding feature "F2.2" that feature (c) does not require all of the three alternatives to be actually present.

3.1.2 The board also agrees with the interpretation of the opposition division adopted in point 12.1 of the reasons of the decision under appeal with respect to feature F3.3 that feature (e) contains two unrelated features, namely

- a plurality of packet transmission modes

and

- at least one packet protocol with a header including embedded data for providing control and status information.

The "packet transmission modes" do not necessarily involve a transmission to one or more of the plurality of hearing aids. Appellant I referred to granted claim 5 to argue to the contrary, but this claim seems to specify a further transmission mode, namely a "unicast packet transmission mode", which is not necessarily embraced by the "packet transmission modes" of granted claim 1.

3.2 Reference to D10 concerning "Bluetooth"

The board considers the reference to D10 within the novelty analysis of granted claim 1 in view of D6 to be legitimate as far as it concerns features that are mandatorily present when referring to "Bluetooth" in, for instance, paragraph [0034] of D6. The board agrees with appellant I that the reference to the Bluetooth standard does not necessarily imply that all of its features are implemented. However, the composition of the "packet header" as shown in point 6.4 on page 282 of D10 (i.e. page "116 of 814" of volume 3 of that document) as referred to by the opposition division in point 12.1 of the appealed decision regarding feature F3.3 is a mandatory feature (see the phrase "Bluetooth devices shall use the packets as defined in the following sections" in point 6 of page 275 of D10, i.e. page 109 of 814 of volume 3 of that document).

3.3 Inventive-step analysis

3.3.1 Although the decision under appeal does not explicitly state which document is taken to be the closest prior art, the opposition division probably considered this to be D6, given that it devoted a good many arguments on inventive step starting from D6. The board also considers D6 to constitute the closest prior art and agrees with most of the novelty analysis of the opposition division as regards this document.

In particular, features (a) to (d) are disclosed in paragraphs [0026] and [0030] to [0034] and Figure 2 of D6, except for the wording "plurality of wireless hearing aids": D6 shows merely a single wireless hearing aid as set out in paragraph [0026]. Paragraph [0051] of D6 may indicate that a CD player can be attached to the aided ear bud, but this does not imply that a plurality of wireless hearing aids is present. The teaching of paragraph [0051] relates to attaching analog devices or the analog output from a digital device to the aided ear bud, rather than to performing stereo reproduction. In particular, paragraph [0051] refers, similarly to the rest of D6, to a single aided ear bud. A CD player may be able to output a stereo signal, but this does not directly and unambiguously mean that an output device to which this CD player is connected must inevitably reproduce the stereo signal via a binaural configuration.

The board also agrees that the reference to the Bluetooth standard in paragraph [0034] of D6 implies the use of a header as in point 6.4 of page 282 of D10, wherein the field "FLOW" constitutes control information and the field "ARQN" constitutes status information as in feature (e). Table 65 on page 76 of the original application underlying the patent in suit may disclose status information in the form of the respective status of volume, memory, mute, battery, microphone and environment, but the board notes that feature (e) does not specify to which entity the status information relates. The acknowledgement indication under the field "ARQN" informs, as set out in point 6.4.4 of page 283 of D10, the source of a successful transfer of payload data and, hence, represents a status of this transfer.

3.3.2 Hence, D6 only does not disclose the feature that a plurality of wireless hearing aids is present, contrary to what is stated in features (b) to (e).

3.3.3 Claim 1 is silent as to the purpose and use of having multiple wireless hearing aids in the underlying system: these hearing aids have no functional relationship whatsoever and could, for instance, be worn by the same person or by multiple persons and could be used at the same time or at different times.

Appellant I's argument that the occurrence of multiple packet-transmission modes as per feature (e) only makes sense if multiple hearing aids are present does not convince the board because these packet-transmission modes are not necessarily related to the transmission to the hearing aids, as already pointed out by the opposition division in the first two lines of page 6 of the appealed decision. Rather, the packet transmission modes can virtually relate to any connection set up from the interface of feature (d) to another component.

As a result, based on the features of present claim 1, the skilled reader would not have been able to identify the actual technical effect that is to be associated with the feature that distinguishes the subject-matter of claim 1 from that of D6, thereby rendering this distinguishing feature completely arbitrary. It is generally accepted that such arbitrary features are disregarded in the assessment of inventive step (see e.g. T 206/91, Reasons 5.5; T 2044/09, Reasons 4.6; T 1009/12, Reasons 2.7).

3.4 In conclusion, no inventive step can be acknowledged for claim 1 as granted (Articles 100(a) and 56 EPC).

4. Auxiliary requests: claim 1 - insufficiency of disclosure

4.1 Claim 1 of the first and third auxiliary requests differs from claim 1 of the main request in that it no longer includes the expression "one or more" in feature (e) and in that it further specifies that

(f) the embedded data includes the information specifying a particular mute state.

4.2 Claim 1 of the second and fourth auxiliary requests differs from claim 1 of the first auxiliary request in that

- the wording "relating to a mute state" used in feature (c) has been replaced by "capable of conveying any one of three mute states"

and

- the wording "specifying a particular mute state" recited in feature (f) has been replaced also by the wording "capable of conveying any one of three mute states".

4.3 Claim 1 of all auxiliary requests therefore requires the interface of feature (e) to provide a packet protocol with a header including embedded data specifying or conveying at least one "mute state". Stated differently, the header must include an embedded mute command.

As regards feature (e), appellant II convincingly argued that, contrary to Article 83 EPC, there is no sufficiently clear and complete disclosure in the original application underlying the opposed patent for the skilled person to implement the aspect of how a receiver being in communication with the interface is actually informed about the header comprising an embedded mute command.

The board notes in particular that feature (e) involves the use of a so-called "packet protocol" comprising a header, where, typically, decoding at the receiver side takes place under the basic assumption that the payload data follow the header bits, which in turn convey information for properly interpreting, i.e. parsing, the successive payload data. In claim 1 of all four auxiliary requests, the payload data are partly embedded in the header, thereby deviating from this basic assumption. The decoder at the receiving end must evidently be informed about this fundamental deviation to avoid that the header is simply discarded upon arrival. This information is however missing from the application as filed. Therefore, the board holds that appellant II raised serious doubts, substantiated by verifiable facts, as to sufficiency of disclosure in the current case.

For the following reasons, appellant I was unable to address these doubts in a convincing way.

4.3.1 Appellant I referred to the paragraph bridging pages 70 and 71 of the original application underlying the opposed patent, from which the board understands that the source address which is typically part of the header is sometimes replaced by audio control information, thereby effectively leading to the use of two different headers within a particular transmission. From lines 6 to 9 of page 72 of the original application, to which appellant I also referred, the board further understands that two examples are described in the original application:

(i) a first example with a "remote control message" being embedded within the header as shown in Table 62

and

(ii) a second example where a "remote control message" including an "embedded command message" comprising a "mute state" is part of a payload as shown in Table 63 (see also page 73, line 22 and page 74, line 26 to page 75, line 2; Table 64),

where in both examples a particular bit is present, namely "bit 6".

Those examples are illustrated in the original application (cf. Tables 62 and 63) as follows:

FORMULA/TABLE/GRAPHIC

FORMULA/TABLE/GRAPHIC

4.3.2 The requirement of sufficiency of disclosure may, as brought forward by appellant I, indeed be met when merely one particular embodiment is disclosed that is sufficiently clear for the skilled person to carry out the invention. However, the board notes that in the present case such an embodiment can solely rely on the first and not on the second example, given that sufficiency of disclosure is to be assessed here for the situation where a "mute command", i.e. the "remote control message", is embedded in the header.

Appellant I highlighted several parts of the application as filed in support of sufficiency of disclosure, namely

- the term "Frame Descriptor" in Table 7 and in lines 8 to 10 of page 21;

- the term "Embedded Data" in bit 6 of Table 8;

- the indication in page 70, line 27 to page 71, line 10 that audio control information is contained in the header as "embedded data" in place of the usual source address;

- the term "Remote Control message (Embedded Data)" in Table 62;

- the clause that the "message type 0 is an embedded command message" of page 73, lines 13 and 14 together with Table 64;

- the term "message type 1" of Table 65 of the application as filed,

but the board cannot recognise any clear indication for the skilled person that the message of Table 64, i.e. of the second example, could be somehow embedded in the header of Table 62, i.e. of the first example. The board notes in this respect that these two examples are clearly described as two separate examples in lines 11 to 20 of page 71 of the application as filed, where lines 11 to 14 correspond to the first example and lines 15 to 20 to the second one.

While appellant I asserted that the term "payload" used in line 22 of page 73 of the original application with respect to the second example referred to the payload in a header and not to the payload of the packet, the board could find no associated passage in the application as filed from which the skilled person could derive this. Quite to the contrary, lines 15 to 17 of page 71 of the original application, upon which appellant I also relied, mention that "[t]his message type can also be sent in the payload of a normal wireless packet and is identified by the extended data type within the Protocol identifier bits of the frame descriptor (FD) field of the header PDU" (emphasis by the board), from which the board can only conclude that the second example referred to with respect to Table 63 in lines 7 to 9 of page 72 of the application as filed refers to what the skilled person would understand to be the regular payload section of a packet, i.e. the part of the packet following the header.

4.3.3 With respect to the first example, appellant I put forward that "bit 6" mentioned in point 4.3.1 above is the bit which informs the receiver which of the two headers is used in the packet that is currently being decoded. However, the board is not convinced that there is a sufficiently clear and complete disclosure for the skilled person to understand that "bit 6" fulfils this role for the reasons set out below.

4.3.3.1 While, as apparent from line 27 of page 74 of the original application, "bit 6" of the second example unequivocally indicates a change in the mute state, the same does not hold for "bit 6" of the first example. The passages in the original application cited by appellant I relating to the content of this "bit 6", namely Table 8, lines 13 to 16 of page 23, and lines 11 to 14 of page 71 do not provide the skilled person with the teaching that the receiver communicating with the interface of feature (e) is informed about the fact that the "source address" of the header is replaced by a "mute command".

4.3.3.2 Rather, the passages mentioned above in point 4.3.3.1 merely provide the skilled person with conflicting or at least confusing teachings, contrary to the requirement of a sufficiently clear and complete disclosure enshrined within Article 83 EPC. In particular, the board highlights that the skilled person learns from lines 11 to 14 of page 71 of the original application that "bit 6" indicates "an embedded data type" (emphasis by the board), indicating, for instance, that the embedded data is of the type of control data, of error correction data or of status information. By contrast, lines 13 to 16 of page 23 of the application as filed states that bit 6 "is used to indicate whether the data in the Embedded Channel field is valid" (emphasis by the board), whatever may be meant by the term "valid" in this context. Moreover, arguendo, it would make no technical sense for a skilled person in the field of data communications to include both the "bit 6" field (i.e. indicating a data type or a mute state change for enabling the receiver to properly interpret the packet's respective payload section) and the mute state information itself in the header.

4.3.4 In conclusion, there is no embodiment in the application as filed teaching how a receiver, which is in communication with the interface of feature (e), could in fact know that the header of a particular incoming packet comprises embedded information in the form of a "mute command". Hence, the disclosure of the application as filed is not sufficiently clear and complete for the skilled person to carry out the invention defined by claim 1 of all four auxiliary requests.

4.4 Consequently, claim 1 of all auxiliary requests on file is not allowable under Article 83 EPC.

5. Without any allowable set of claims on file, the patent is to be revoked.