T 2376/22 (UPF-based address assignment/HUAWEI) 24-06-2024
Download and more information:
Address management method, device and system
Clarity - all requests (yes, after amendment)
Added subject-matter - all requests (no, after amendment)
Inventive step - all requests (no)
I. The appeal is directed against the examining division's decision to refuse the present European patent application.
II. The examining division decided that the present application, according to a main and an auxiliary request, did not meet the requirements of Articles 123(2), 84 and 56 EPC.
III. The prior-art documents referred to by the examining division included:
D1: US 2017/019874 A1.
IV. With its statement of grounds of appeal, the appellant submitted amendments according to a new main request as well as new auxiliary requests I to III.
V. The board summoned to oral proceedings and provided its preliminary opinion under Article 15(1) RPBA.
VI. In reply to the board's communication, the appellant filed further amendments according to a main request as well as auxiliary requests I to IV. Subsequently, the appellant indicated that it would not be attending the oral proceedings and requested a decision based on the documents on file.
VII. The scheduled oral proceedings were then cancelled.
VIII. Claim 1 of the main request reads as follows:
"An address management method performed by a session management function, SMF, network element, the method comprising:
- obtaining (S602), from a user plane function, UPF, network element, or an operation administration and maintenance, OAM, network element, a correspondence between an address pool identifier, an identifier of an user plane function network element, UPF, and session information, wherein the session information comprises at least one of a data network name, DNN, or an IP address version;
- receiving a PDU session establishment request message from a terminal, wherein the PDU session establishment request message comprises the session information (S605);
- selecting the UPF network element serving the terminal (S 606);
- determining, based on the identifier of the selected UPF network element, the received session information, and the correspondence, the address pool identifier corresponding to the session (S 607);
- sending a request message to a dynamic host configuration protocol, DHCP, server, wherein the request message carries the determined address pool identifier (S 608); and
- receiving, a response message from the server, wherein the response message carries an unused IP address for the session (S 610), wherein the unused IP address for the session is an IP address of an address pool having the determined address pool identifier."
Claim 1 of auxiliary request I reads as follows:
"An address management method performed by a session management function, SMF, network element, the SMF network element storing a correspondence, the correspondence including:
- for each address pool identifier among a plurality of address pool identifiers:
- an identifier of a user plane function, UPF, network element among a plurality of UPF network elements and session information of a session of a terminal, wherein the session information contained in the correspondence comprises at least one of a data network name, DNN, or an IP address version,
the method comprising the steps of:
- obtaining an identifier of a user plane function, UPF, network element serving the terminal and session information of a to-be established session of the terminal, wherein the session information comprises at least one of a data network name, DNN, or an IP address version
(S 505, S 506, S 507, S 605, S 606);
- determining, based on the correspondence, and the obtained identifier of the UPF network element and the obtained session information, an address pool identifier among the plurality of address pool identifiers (S 508, S 607);
- sending a first request message to a server, the first request message containing the determined address pool identifier, wherein the server is either a dynamic host configuration protocol, DHCP, server or a network repository function, NRF, network element (S 509, S 608);
- receiving, from the server, an unused IP address for the to-be established session (S 510, S 610), wherein the unused IP address for the to-be established session is an IP address of an address pool having the determined address pool identifier."
Claim 1 of auxiliary request II reads as follows:
"An address management method performed by a session management function, SMF, network element, the method comprising the steps of:
a.) obtaining (S 502, S 602), from a user plane
function, UPF, network element, or an operation
administration and maintenance, OAM, network
element, a correspondence, the correspondence
including:
- for each address pool identifier among a plurality of address pool identifiers:
- a same identifier of the user plane
function, UPF, network element and
session information of a session,
wherein the session information
contained in the correspondence
comprises at least one of a data
network name, DNN, or an IP address
version,
b.) determining that an IP address needs to be
assigned to a to-be established session of a
terminal (S 504, S 605);
c.) obtaining session information of the to-be
established session of the terminal, wherein
the session information of the to-be
established session comprises at least one of a
data network name, DNN, or an IP address
version of the to-be established session
(S 505, S 605);
d.) obtaining an identifier of a user plane
function, UPF, network element serving the
terminal (S 506, S, 507; S 606);
e.) determining, based on the correspondence, the
obtained identifier of the UPF network element
and the obtained session information, an
address pool identifier among the plurality of
address pool identifiers (S 508, S 607);
f.) sending a first request message to a server,
the first request message containing the
determined address pool identifier, wherein the
server is either a dynamic host configuration
protocol, DHCP, server or a network repository
function, NRF, network element (S 509, S 608);
g.) receiving, from the server, an unused IP
address for the to-be established session
(S 510, S 610), wherein the unused IP address
for the to-be established session is an IP
address of an address pool having the
determined address pool identifier."
Claim 1 of auxiliary request III reads as follows:
"An address management method performed by a session management function, SMF, network element, the method comprising the steps of:
a.) obtaining (S 602), from a user plane function,
UPF, network element, or an operation
administration and maintenance, OAM, network
element, a correspondence, the correspondence
including:
- for each address pool identifier among a plurality of address pool identifiers:
- a same identifier of the user plane
function, UPF, network element and
session information of a session,
wherein the session information
contained in the correspondence
comprises an IP address version,
b.) determining that an IP address needs to be
assigned to a to-be established session of a
terminal (S 604);
c.) obtaining session information of the to-be
established session of the terminal, wherein
the session information of the to-be
established session comprises an IP address
version of the to-be established session
(S 605);
d.) obtaining an identifier of a user plane
function, UPF, network element serving the
terminal (S 606);
e.) determining, based on the correspondence, the
obtained identifier of the UPF network element
and the obtained session information, an
address pool identifier among the plurality of
address pool identifiers (S 607);
f.) sending a first request message to a server,
the first request message containing the
determined address pool identifier, wherein the
server is a dynamic host configuration
protocol, DHCP, server (S 608);
g.) receiving, from the server, an unused IP
address for the to-be established session
(S 610), wherein the unused IP address for the
to-be established session is an IP address of
an address pool having the determined address
pool identifier."
Claim 1 of auxiliary request IV differs from claim 1 of auxiliary request III in that the two occurrences of the feature "comprises an IP address version" have been replaced by "comprises a data network name, DNN" and "comprises a DNN", respectively.
1. Background of the application
The present application concerns IP address management for a PDU session of a terminal based on using address pools and facilitated by a user plane function (UPF).
2. Main request
Present claim 1 differs from claim 1 of the previous main request in that the steps performed by the "DHCP server" have been excised.
2.1 Added subject-matter (Article 123(2) EPC)
2.1.1 The board concurs with the appellant that the
subject-matter of claim 1 is disclosed in Figure 6 in combination with Figure 5 and the corresponding passages of the description. Notably, Figures 5 and 6 allow, when viewed in combination, for determining that the claimed steps are disclosed in both embodiments and thus only in combination, whereas the omitted steps are not disclosed in both embodiments and are thus not disclosed as occurring only in combination with the claimed steps.
2.1.2 Consequently, the board holds that the arguments provided by the appellant are rebutting all of the objections pursuant to Article 123(2) EPC raised in the decision under appeal against claim 1 of either claim request.
2.2 Clarity (Article 84 EPC)
2.2.1 The board holds that the appellant's amendments and arguments render moot the objections raised hitherto as to lack of clarity.
2.2.2 Hence, claim 1 complies with Article 84 EPC.
2.3 Inventive step (Article 56 EPC)
2.3.1 Distinguishing features
In line with the decision under appeal, the board holds that the subject-matter of claim 1 differs from the disclosure of document D1 in that an "SMF network element" and a "DHCP server" are employed. Furthermore, the board concurs with the appellant that document D1 fails to explicitly disclose at least the alternative that the "IP address version" is taken into account during the IP address assignment.
2.3.2 As to the respective argument of the appellant, the board emphasises that document D1 discloses that the "location area" is used, rather than the "geographic location". As shown, e.g., in paragraph [0208] of document D1, there exists a correspondence between "location area" and an "IP area". The latter is administered by a particular "packet data gateway" (see in particular Figure 14 and paragraphs [0307] and [0311]). The "location area" identifier is thus also identifying the particular "packet data gateway". Therefore, the appellant's argument is not convincing.
2.3.3 Furthermore, the appellant argues that the passages cited by the board (Figure 14 and paragraphs [0307] and [0311]) did not disclose administering an "IP area" by a P-GW. The board holds that paragraph [0307] explicitly mentions "IP address assignment". In addition, paragraph [0208] - which has also been previously cited by the board - describes the notion of "IP areas". For the sake of completeness, the board notes that the P-GW is commonly known to provide for the IP address assignment (see also step 1207 in Fig. 12A of D1). And even if this were not the case, the board considers that no technical effect would arise from the IP address assignment being performed by the P-GW and the appellant did not argue to the contrary.
2.4 Inventive step (Article 56 EPC)
2.4.1 The board holds that the differences "SMF" and "DHCP server" are not linked by a synergistic concept, as evident from the fact that, according to the application, the "DHCP server" as well as the "SMF" may be replaced by different entities.
2.4.2 As to the "SMF" unit, the board concurs with the examining division that applying a method known in the context of a 4G-element to its 5G-successor would have been obvious and cannot contribute to an inventive step. This is in line with the disclosure of the present application, according to which the use of the "SMF" as such is not decisive for achieving a particular technical effect (see paragraph [0110] as filed). At any rate, the board considers that an "SMF" was commonly known to the skilled person.
2.4.3 As to the use of the DHCP scheme, the board notes that, at the time of filing, it was already part of the skilled person's common knowledge that DHCP is readily used in the 3GPP context and takes account of the IP version.
2.4.4 The appellant argues that there would be "no pointer in the prior art or common knowledge for the specific usage of such an IP address version in the claimed context". The board is not convinced by this argument. First, it notes that 3GPP is commonly known to support both protocols, i.e. IPv4 and IPv6. In addition, 3GPP is known to make use of DHCP, which is also commonly known to support both, IPv4 and IPv6. Therefore, the board considers that the skilled person would have readily facilitated the selection of an IP version should the need have arisen.
2.4.5 Moreover, the appellant argued that the distinguishing features solved the objective problem "to provide an improved address management method". The board is not convinced that the distinguishing features actually provide the alleged improvement. Notably, the appellant did not indicate which specific aspect of the address management would in fact be improved. Hence, it cannot be objectively verified whether the distinguishing features actually achieve the alleged improvement over the address management method of document D1.
2.4.6 For the sake of completeness, the board notes that it cannot perceive any improvement caused by the distinguishing features. In particular, the claimed aspects relating to "DHCP" in combination with determining the "address pool identifier" from the "session information" (which comprises, according to one alternative, an "IP address version") fail to specify further constraints for the received "unused IP address for the session". Thus, since it is not further specified how the "address pool identifier" is determined, apart from the "IP address version", the received "unused IP address for the session" does not necessarily possess properties which are different from those of the IP address assigned in document D1.
2.4.7 Lastly, with respect to the appellant's observation that the board did not deal with the "DNN"-alternative, the board notes that it provided a reasoning with respect to obviousness of the alternative "IP address version". In the case of a claim specifying two alternatives, its subject-matter is rendered obvious if at least one of the claimed alternatives is obvious.
2.4.8 Consequently, the board holds that the subject-matter of claim 1 is not inventive over the disclosure of document D1.
2.5 In view of the above, and regardless of the admittance issues under Article 12 and 13 RPBA (including that of "exceptional circumstances"), the main request is not allowable under Article 56 EPC.
3. Auxiliary requests I to III
3.1 Claim 1 of each of auxiliary requests I to III differs from claim 1 of the previous auxiliary requests I to III in that the steps performed by the "DHCP server" have been excised, i.e. the same amendment as in claim 1 of the main request has been made.
3.2 In particular, in claim 1 of auxiliary request I, the reference to a "plurality of sessions" has been removed and the sole remaining "session" renamed as the "to-be established session", i.e. the wording already used in claim 1 of auxiliary requests II and III.
The claims of auxiliary request II are based on those of auxiliary request I. The appellant brought forward that, compared to auxiliary request I, claim 1 as amended was better aligned with the disclosure of Figures 5 and 6 as well as the corresponding passages of the description as filed.
Claim 1 of auxiliary request III differs from claim 1 of auxiliary request II in that the alternatives "DNN" and "NRF" have been deleted.
3.3 The board holds that the amendments and arguments provided by the appellant are rebutting all of the objections pursuant to Articles 123(2) and 84 EPC raised hitherto against claim 1 of those requests.
3.4 Inventive step (Article 56 EPC)
3.4.1 In the written response to the board's preliminary opinion as to inventive step of claim 1 of each of auxiliary requests I to III, the appellant refers to the arguments provided with respect to claim 1 of the main request.
3.4.2 The board holds that its considerations regarding claim 1 of the main request apply likewise to claim 1 of auxiliary request I to III.
3.5 Hence, and regardless of the admittance issues under Article 12 and 13 RPBA (including that of "exceptional circumstances"), auxiliary requests I to III are not allowable under Article 56 EPC for the same reasons as set out for the main request.
4. Auxiliary request IV
4.1 The appellant submitted that the board's preliminary opinion did not comment on the "DNN"-alternative in the respective claims, which therefore had to be considered as support for the presence of an inventive step. As to the arguments in favour of an inventive step, the appellant referred to those provided in the statement of grounds of appeal. Therein, the appellant emphasised that, although one could "equate somehow an APN with a [data network name] DNN", the received connection establishment request message of document D1 did not contain an APN. Hence, according to D1, the determination of the "address pool identifier" was only based on the received location of the terminal. On the other hand, according to what was claimed, the determination of the "address pool identifier" was inter alia based on the session information containing the DNN. This allowed for an accurate way of determining an address pool identifier and solved the problem of "how to provide an improved address management method".
4.2 For the reasons already provided in point 2.4.5 above, the board does not consider that the alleged improvement is actually achieved. Rather, since it is not further specified how the "address pool identifier" is actually determined from the DNN, the board holds that - similarly to the reasoning set out in point 2.4.6 above - the received "unused IP address for the session" does not necessarily possess properties which are different from those of the IP address assigned in document D1.
4.3 Consequently, the subject-matter of present claim 1 is not inventive over the disclosure of document D1 either.
4.4 In view of the above, and regardless of the admittance issues under Articles 12 and 13 RPBA (including that of "exceptional circumstances"), auxiliary request IV is likewise not allowable under Article 56 EPC.
For these reasons it is decided that:
The appeal is dismissed.