T 1806/06 (Session Initiation Protocol ID/RESEARCH IN MOTION) 13-11-2009
Download and more information:
System and method for allocating session initiation protocol (SIP) identification (IDs) to user agents
Late filed amendments (admitted)
Inventive step (no)
I. This appeal is against the decision of the examining division dispatched 14 July 2006, refusing the European patent application No. 04255619.1 for the reasons that independent claims 1 and 6 did not involve an inventive step having regard to the disclosure of
D3: WO 01/31472 A and
D4: IETF RFC 2131.
During the examining proceedings the further documents were considered:
D1: J. Rosenberg, "URI Leasing in the Session Initiation Protocol (SIP) draft-rosenberg-sipping-lease-00", SIPPING Internet-Draft, 12 February 2003;
D2: J. Rosenberg, "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) draft-ietf-sip-gruu-02", SIP Internet-Draft, 2 July 2004 and
D5: IETF RFC 3261, pages 147 to 159.
II. Notice of appeal was filed on 12 September 2006. With letter of 13 September 2006 the appellant specified that the notice of appeal was intended to be against the decision in its entirety. The appeal fee was paid on 14 September 2006. The statement setting out the grounds of appeal was submitted on 14 November 2006. The appellant requested that the decision under appeal be set aside and that the patent be granted based on claims 1 to 10 filed with the statement setting out the grounds of appeal. An auxiliary request for oral proceedings was made.
III. The Board issued an invitation to oral proceedings accompanied by a communication. In the communication the board, making use of its competence under Articles 111(1) and 114(1) EPC 1973, introduced document
D5': IETF RFC 3261, pages 1 to 236,
which was cited in the description as incorporated by reference, formally into the proceedings and referred to documents D3, D4 and D5'.
IV. The board expressed the preliminary view that the description failed to define the term "Session Initiation Protocol ID", and that for this and other reasons claims 1 and 6 did not comply with the provisions of Article 84 EPC 1973. Further the subject-matter of claims 1 and 6 did not appear to involve an inventive step having regard to the disclosure of documents D3 and D4 or, in the alternative, D5' and D4.
V. With its letter of 12 October 2009, in response to the communication, the appellant filed claims 1 to 12, which were said to overcome the objection under Article 84 EPC 1973, and commented on the interpretation of "Session Initiation Protocol ID" and on novelty and inventive step.
VI. In its communication of 6 November 2009 the board announced that the admissibility of the amended claims, which changed the focus of the claimed subject-matter, into the proceedings under Article 13(1) and (3) RPBA would be an issue at oral proceedings. If they were admitted, D1 and D2 would be discussed.
VII. At the oral proceedings which took place as scheduled on 13 November 2009 the appellant filed amended claims 1 to 10, corresponding to the set of claims filed with the statement setting out the grounds of appeal with in addition the amendments made in the claims of 12 October 2009 to overcome the board's objections under Article 84 EPC 1973. On the basis of these claims the case was discussed with the appellant. After deliberation the board announced its decision.
VIII. Claim 1 reads as follows:
"A method of enabling communication on an Internet Protocol based network which comprises:
receiving a request from a Session Initiation Protocol user agent for a Session Initiation Protocol ID, said request being received via a communications connection between a Session Initiation Protocol user agent and a server via an Internet Protocol based network;
querying a database associated with the server, the database containing data relating to free Session Initiation Protocol IDs that are available to be allocated to the Session Initiation Protocol user agent and data relating to allocated Session Initiation Protocol IDs, for determining a free Session Initiation Protocol ID that can be allocated to the Session Initiation Protocol user agent;
allocating the determined free Session Initiation Protocol ID for use by the Session Initiation Protocol user agent;
moving the determined free Session Initiation Protocol ID to the data relating to allocated Session Initiation Protocol IDs;
sending the allocated Session Initiation Protocol ID to the Session Initiation Protocol user agent; and
after the Session Initiation Protocol user agent to which the Session Initiation Protocol ID was originally allocated has completed a communications session using SIP, returning the Session Initiation Protocol ID to the data relating to free Session Initiation Protocol IDs for use by another Session Initiation Protocol user agent."
Claim 6 is directed to a communications system comprising a server that is operable for communicating with a Session Initiation Protocol user agent, wherein the server is operative to execute a method according to claim 1.
1. Admissibility
The appeal complies with the provisions of Articles 106 to 108 EPC 1973, which are applicable according to J 0010/07, point 1 (see Facts and Submissions, point II above). Thus, it is admissible.
2. Late filed amendments
According to Article 13(1) RPBA, it is in the discretion of the board to admit any amendments to a party's case after it has filed its grounds of appeal.
The appellant filed an amended set of claims at the oral proceedings. As claims 1 to 10 merely correspond to the set of claims filed with the statement setting out the grounds of appeal with amendments made to overcome the objections under Article 84 EPC 1973 presented in the communication of the board, the board could deal with the amended claims without adjournment of the hearing and admitted the set of claims into the proceedings, (Article 13(3) RPBA).
3. Interpretation
The board interprets the term "Session Initiation Protocol ID" as "SIP identity", called SIP URI, in accordance with D5', page 11.
4. Inventive Step
As acknowledged in the application, the SIP architecture includes user agents to which unique Session Initiation Protocol ID's (SIP ID's) are allocated. The SIP ID's are stored in a SIP registrar server which contains the locations of all user agents within a domain. For SIP-enabling of a device, a server must contain an entry that associates to the SIP ID a unique identifier for the device. According to the application this mapping usually is manually entered. On the device, a user must also know its own SIP ID, which typically is manually entered before any registration occurs with the SIP registrar server. See paragraphs [0005] to [0007] of the application as published.
The problem underlying the claimed subject-matter is to provide a method of enabling communication on an Internet Protocol based network according to SIP which avoids the requirement for manually entering SIP ID's on a SIP server and the requirement for a user agent to know its own SIP ID in order to communicate using SIP and which allows allocation of a limited number of SIP ID's to a larger group of user agents, which are not always connected. See [0011] to [0013] of the application as published.
This problem is solved inter alia by allocating an SIP ID from a database by a server on request from the SIP user agent, the database containing data relating to free SIP ID's that are available to be allocated to the SIP user agent and data relating to allocated SIP ID's.
D3 discloses a method of enabling communication with a roaming mobile station in a SIP-compliant network. The SIP registrar is equipped with DHCP functions. The SIP REGISTER method is modified such that, if required by the mobile station, the SIP registrar shall request an IP address for the mobile station under DHCP and subsequently assign it to the mobile station, (see D3, page 25, line 8 to page 26, line 9).
D4 is the standardization document specifying DHCP. D4 discloses that DHCP defines mechanisms through which clients can be assigned a network address for a finite lease, allowing for serial reassignment of network addresses due to exhaustion of available addresses, (see page 8, third paragraph and page 12, last paragraph). Thus, D4 addresses a problem similar to the one underlying claim 1. The skilled person would therefore consult D4.
The appellant argued that SIP and DHCP were different protocols and the skilled person working on SIP was not aware of DHCP. Consequently, the skilled person would not combine the disclosure of D3 and D4. Although D4 had been published seven years prior to the filing date of the present application, a solution as claimed had not been suggested. The combination of SIP and DHCP assumed in the board's argumentation was therefore made by hindsight. This argument does not convince the board, since SIP is used in Internet Protocol communications systems as also acknowledged in the present application (see paragraph [0001] of the application as published), and the skilled person working on SIP has to be aware of basic features of the Internet protocol, such as dynamic allocation of addresses under DHCP. In fact, as mentioned above, the method disclosed in D3 makes use of DHCP for assigning IP addresses to a mobile station roaming in an SIP-compliant network. Even if D3 discloses a different application of DHCP than claimed, it shows that the skilled person working on SIP was aware of DHCP.
Starting from a method of communication in an SIP-compliant network as disclosed e.g. in D3, the skilled person would thus apply the method disclosed in D4 to replace the manual entering of the SIP ID's by an allocation of free SIP ID's on request from an SIP user agent. This implies that the server receives the request and sends the allocated SIP ID to the SIP user agent.
D4, page 22, second to last paragraph discloses that the DHCP server may have a block of network addresses from which it can satisfy requests for new addresses. Each server also maintains a database of allocated addresses and leases in local permanent storage. This implies a database containing data relating to free SIP ID's that are available to be allocated to the SIP user agent and data relating to allocated SIP ID's and querying the database associated with the server for determining a free SIP ID that can be allocated to SIP user agent.
If the client no longer requires use of its assigned network address, the client sends a DHCPRELEASE message to the server, (see D4, page 41, last paragraph). Upon receipt of the DHCPRELEASE message the server marks the network address as not allocated, (see page 33, third paragraph). Applying this teaching to SIP user agents implies that after the SIP user agent to which the SIP ID was allocated has completed a communications session using SIP, the SIP ID is returned to the data relating to free SIP ID's available for use by a different client.
Thus, the subject-matter of claim 1 does not involve an inventive step (Article 56 EPC 1973).
Similar arguments apply to the system claim 6 corresponding to claim 1.
Thus, the claimed subject-matter does not comply with the provisions of Article 52(1) EPC.
Order
For these reasons it is decided that:
The appeal is dismissed.