Information
This decision is only available in German.
T 2162/18 (Interworking for call waiting/BLACKBERRY) 26-02-2021
Download and more information:
Method and apparatus for interworking with circuit switching and packet switching nodes for call waiting
Novelty - (yes)
Inventive step - (no): difference obvious in view of common technical knowledge
I. The appeal was lodged by the applicant against the decision of the examining division refusing the present European patent application for lack of novelty (Article 54 EPC) with respect to the independent claims of a main request and for lack of inventive step (Article 56 EPC) with respect to the claims of an auxiliary request.
II. In their decision, the examining division referred inter alia to the following prior-art documents:
D1:|"3rd Generation Partnership Project; Technical Specification Group Services and System Asp; IP Multimedia Subsystem (IMS) Centralized Services; Stage 2 (Release 8)", Technical Specification 3GPP TS 23.292 (2008-04) V0.4.0, 2 May 2008; |
D2:|"3rd Generation Partnership Project; Technical Specification Group Core Network; Call Waiting (CW) and Call Hold (HOLD) supplementary services; Stage 3 (Release 7)", Technical Specification 3GPP TS 24.083 (2007-06) V7.0.0, 1 June 2007. |
The following additional prior-art documents, cited in the present application, will be referred to as follows:
D3: "3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals; Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification; (Release 8)", Technical Specification 3GPP TS 24.615 (2008-10) V1.1.0, 16 October 2008;
D4: "3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals; Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and MSC Server for IMS Centralized Services (ICS) (Release 8)", Technical Specification 3GPP TS 23.292 V1.1.0 (2008-10), 16 October 2008;
D5: Rosenberg, J. et al.: "SIP: Session Initiation
Protocol", RFC 3261, Network Working Group, June 2002 (referred to in the decision under appeal).
III. Oral proceedings before the board were held on 26 February 2021 by videoconference in accordance with the appellant's request (cf. Article 116(1) EPC).
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 subject to the decision under appeal and re-submitted with the statement of grounds of appeal.
At the end of the oral proceedings, the board's decision was announced.
IV. Claim 1 of the main request reads as follows:
"A method for interworking a session by a Mobile Switching Center, MSC, server enhanced for IP Multimedia Subsystem, IMS, Centralized Services, ICS, the method comprising:
receiving (11) at the MSC a Session Initiation Protocol, SIP, invite message for a user equipment, UE, involved in a call being served in a circuit switched, CS, domain by the MSC, wherein the SIP invite message is received from an IMS network comprising a call waiting application server;
when the SIP invite message comprises a MIME body including a communication-waiting indication element, the MSC:
sending (12) to the UE a CS setup message comprising an information element indicating a
call-waiting-tone-on, and
storing an indication that the session includes a call waiting application server;
receiving a CS message from the UE including call waiting information;
and
sending a SIP response message to the IMS network, the SIP response message including message information mapped from the call waiting information."
1. MAIN (AND SOLE) REQUEST
1.1 Claim 1 - Novelty
1.1.1 Using the wording of present claim 1, D1 discloses (board's outline and strike-through indicating missing features):
A method for interworking a session by an MSC server enhanced for ICS (Figure 7.6.2.6-1: "MSC Server"), the method comprising:
(a) receiving at the MSC a SIP invite message (page 54, Figure 7.6.2.6-1: "4. INVITE (A)"; page 54, section 7.6.2.6: "... 4. The S-CSCF forwards the INVITE to the MSC Server ...") for a UE involved in a call being served in a CS domain by the MSC, wherein the SIP invite message is received from an IMS network comprising a call waiting application server (Figure 7.6.2.6-1: "SCC AS");
(b) [deleted: when the SIP invite message comprises a MIME body including a communication-waiting indication element], the MSC:
(b1) sending to the UE a CS setup message
(Figure 7.6.2.6-1: "5. Setup"; section 7.6.2.6:
"... 5. The MSC Server sends a Setup message to
UE A to inform it of the waiting call as specified
in 3GPP TS 24.083 [18] ...") comprising an
information element indicating a
call-waiting-tone-on (the SETUP message in
accordance with 3GPP TS 24.083 referred to in D1 is
described in D2, page 7, Figure 1.1: "NOTE: The
SETUP message shall include a "Signal Information"
element with value #7 (call waiting tone on) ..."),
(b2) storing an indication that the session
includes a call waiting application server (section 7.6.2.6: "... 7. The MSC Server sends an indication that the call is waiting ...", this step requires some kind of knowledge of the MSC server that the session includes a call waiting application server);
(c) receiving a CS message from the UE including call waiting information (Figure 7.6.2.6-1: "6. Alerting"; section 7.6.2.6: "... 6. UE A sends an Alerting message for the waiting call ...");
(d) sending a SIP response message to the IMS network (Figure 7.6.2.6-1: "7. Call is Waiting Indication"), the SIP response message including message information mapped from the call waiting information (see section 7.6.2.6: "... 7. The MSC Server sends an indication that the call is waiting ...").
1.1.2 The subject-matter of claim 1 thus differs from D1 by feature (b), i.e. that steps (b1) and (b2) are carried out "when the SIP invite message comprises a MIME body including a communication-waiting indication element".
1.1.3 Section 7.4.1 on page 33 of D5, referred to by the examining division in point 10 of the impugned decision, states that "... The 'multipart' MIME type defined in RFC 2046 [11] MAY be used within the body of the message ...". It is clear that the use of MIME in the body of a SIP message is not mandatory in general, and the examining division did not provide any additional evidence to the contrary with respect to the specific SIP invite messages described in D1.
Further, the board agrees with the appellant's argument advanced during the oral proceedings before the board that even if the SIP invite message of Figure 7.6.2.6-1 of D1 comprised a MIME body, there is no disclosure or hint at the presence of a "communication-waiting indication element", be it in a MIME body or elsewhere in the SIP message.
1.1.4 The appellant further argued in the written proceedings that the "alerting message" of Figure 7.6.2.6-1 could not be equated with "call waiting information" because claim 1 recited the message "including call waiting information" and a message could not include itself. It was logically impossible for "message 7" of D1 to include message information mapped from such
non-existent information. D1 did therefore not disclose features (c) and (d) either.
1.1.5 Account being taken of the fact that claim 1 does not give any precise indication as to what is to be understood as "call waiting information" or information "mapped" therefrom, the board holds that the "Alerting message for the waiting call" of step 6 of D1 must comprise at least some information field identifying the message as such, and this alone already constitutes "call waiting information" in the claimed sense. Since the "indication that the call is waiting" is sent by the MSC server in step 7 of Figure 7.6.2.6-1 in reaction to the "Alerting message for the waiting call", it comprises "message information mapped from the call waiting information" within the meaning of feature (d) of claim 1.
Hence, the board considers feature (b) to be the only difference between D1 and the subject-matter of claim 1, which is considered new (Article 54 EPC).
1.2 Claim 1 - Inventive step starting from D1
1.2.1 The technical effect achieved by feature (b) is explained in paragraphs [0059]-[0063] of the description as filed. A MIME body, including a communication-waiting indication element, comprised in the SIP invite message received by the MSC server allows the MSC server to recognise that the "Communication Waiting" service should be interworked (i.e. in a backwards-compatible manner), since MSC servers enhanced for ICS will be able to properly decode the indication and interact accordingly with the CS network, whereas MSC servers that do not understand the SIP message elements received will simply generate a "SIP 415 (Unsupported Media Type) response", a "488 (Not acceptable here) response" or a "606 (Not acceptable) response", and send it back to the PS network.
1.2.2 The objective technical problem associated with feature (b) can thus be defined as "how to provide interworking for the communication-waiting service of D1 in a backwards-compatible manner".
1.2.3 The board concludes that, when starting from D1, the solution proposed in claim 1 cannot be considered to involve an inventive step (Article 56 EPC) for the following reasons:
1.2.4 D1 teaches in section 7.6.2.6 on page 54 that "... [f]or IMS sessions established by UEs using the I2 reference point, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling described in 3GPP TS 24.083 [18] to allow Communication Waiting (CW) to be controlled by the IMS". Although it is apparent that the MSC server receiving the SIP invite message from the SCC AS through the S-CSCF also recognises the CW service, D1 does not disclose any specific message format to be used for this purpose, or how other
non-enhanced MSC servers should react to such a SIP invite message.
1.2.5 However, the skilled person starting from D1 and seeking to fill this gap would have known, from the common general knowledge in the field of telecommunication networks, that the customary way to add a functionality in SIP, while retaining
backwards-compatibility, is to extend the SIP invite message through the addition of message bodies (see e.g. D5, page 33, second paragraph and page 79, fourth paragraph: "The UAC MAY choose to add a message body to the INVITE ..."), and, in particular, of a MIME body (see e.g. D5, page 33, paragraph 7.4.1: "... The 'multipart' MIME type defined in RFC 2046 [11] MAY be used within the body of the message ..."; see also 3GPP TS 24.615 = D3, cited in paragraph [0059] of the application as filed, page 10, section 4.5.5.2, last paragraph: "... insert a MIME body ... in the INVITE request, with the 'call-waiting-indication' element contained in a 'action' element, with that 'action' element in turn contained in a 'alternative-service' element, with that 'alternative-service' element in turn contained in the 'ims-3gpp' root element ..."). Hence, the skilled person starting from D1 would have incorporated feature (b) into the underlying system of D1 to arrive thereby at the subject-matter of claim 1 without the involvement of any inventive skills.
1.2.6 The appellant submitted that D1 contained no hint or suggestion that would obviously lead a skilled person to make the required, multiple modifications to its disclosure in order to arrive at the claimed
subject-matter.
1.2.7 The board does not find this argument convincing. In particular, the SIP protocol was designed from the outset with the aspect of extensibility in mind, with MIME bodies being prominently used for this purpose. In this context, the skilled person would have been naturally led to the introduction of a
"communication-waiting indication element" in a MIME body of the SIP invite message of D1 just by mimicking analogous measures described in the prominent IETF and 3GPP standards constituting the common general knowledge in the field of telecommunication networks.
1.3 The main request (sole request) is therefore not allowable under Articles 52(1) and 56 EPC.
2. As there is no allowable claim request on file, the appeal must be dismissed.
For these reasons it is decided that:
The appeal is dismissed.