【事件の表示】
　特願２０１３−５４１２８１「サービング・ネットワーク・ノードの動的な割り当て」拒絶査定不服審判事件〔平成２４年　６月　７日国際公開、ＷＯ２０１２／０７２４０７、平成２６年　１月１６日国内公表、特表２０１４−５０１０９５、請求項の数（２２）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１．手続の経緯　
　本願は、平成２３年（２０１１年）１１月１４日（パリ条約による優先権主張　２０１０年１１月３０日（ＥＰ）欧州特許庁、２０１１年６月２４日（ＥＰ）欧州特許庁）を国際出願日とする出願であって、手続の概要は以下のとおりである。
平成２５年　５月３０日　国内書面
平成２６年　５月１５日　拒絶理由通知
平成２６年１１月２１日　意見書、手続補正書
平成２７年　４月２４日　拒絶査定
平成２７年　８月２８日　審判請求、手続補正書
平成２７年１２月２８日　前置報告
平成２８年　６月　８日　拒絶理由通知
平成２８年　９月　６日　意見書、手続補正書
第２．特許請求の範囲の記載
　本願の特許請求の範囲の記載は、平成２８年９月６日付けの手続補正書の特許請求の範囲に記載された以下のとおりのものである。
「　【請求項１】
　所定の数のサービング・ネットワーク・ノードを備える通信ネットワークにおいてサービング・ネットワーク・ノードを動的に割り当てるための方法であって、当該方法が、
　前記通信ネットワーク内のネットワーク・ノードにおいて、ユーザ機器、他のネットワーク、またはネットワーク・ノードに関連付けられたサービス要求を受信するステップであって、前記サービス要求が登録または再登録要求ではない、ステップと、
　前記サービング・ネットワーク・ノードに関連付けられた負荷情報を、少なくとも１つの前記ネットワーク・ノードに提供するステップと、
　前記サービス要求の受信に応答して、前記所定の数のサービング・ネットワーク・ノードの内１つを、前記負荷情報に基づいて前記ユーザ機器、前記他のネットワーク、または前記ネットワーク・ノードに割り当てるステップと、
を含む、方法。
　【請求項２】
　前記負荷情報が前記サービス要求に応答して提供される、請求項１記載の方法。
　【請求項３】
　前記負荷情報が所定の時間間隔で提供される、請求項１記載の方法。
　【請求項４】
　請求項１〜３のいずれか一項に記載の方法において、前記通信ネットワークが、更に、前記所定の数のサービング・ネットワーク・ノードに関連付けられた位置情報と、任意で、前記所定の数のサービング・ネットワーク・
ノードの内少なくとも１つに割り当てられたユーザ機器、他のネットワー
ク、またはネットワーク・ノードを識別する割当情報とを収容する位置データベースを備える、方法。
　【請求項５】
　請求項１〜４のいずれか一項に記載の方法において、前記負荷情報が、前記サービング・ネットワーク・ノードの少なくとも一部に関連付けられた応答時間情報および／またはＣＰＵリソース情報を含む、方法。
　【請求項６】
　請求項１〜５のいずれか一項に記載の方法であって、
　前記所定の数のサービング・ネットワーク・ノードの少なくとも一部を識別するリストを受信するステップであって、該リストが前記サービング・
ネットワーク・ノードに関連付けられた位置情報を更に含む、ステップと、
　前記所定の数のサービング・ネットワーク・ノードの少なくとも一部に関連付けられた負荷情報を受信するステップと、
　サービング・ネットワーク・ノードを、選択規則および前記負荷情報に基づいて前記リストから選択するステップと、
　前記選択したサービング・ネットワーク・ノードを前記ユーザ機器、前記他のネットワーク、または前記ネットワーク・ノードに割り当てるステップと、
を含む、方法。
　【請求項７】
　請求項１〜６のいずれか一項に記載の方法であって、更に、
　前記通信ネットワークに関連付けられたアクセス・ネットワーク・ノードに基づいて、
ユーザ機器を登録するステップと、任意で、
　前記割り当てられたサービング・ネットワーク・ノードに関連付けられた位置情報を前記位置データベースに格納するステップと、
を含む、方法。
　【請求項８】
　請求項７に記載の方法であって、
　前記通信ネットワークの境界におけるアクセス・ネットワーク・ノードを前記ユーザ機器に割り当てるステップと、
　前記アクセス・ネットワーク・ノードに付随する登録機能を実行するス
テップと、
　前記登録を、前記通信ネットワークのサービスへの加入者に関連付けられたユーザ・プロファイルを含む加入者データベースに格納するステップと、
　位置情報を前記位置データベースに格納するステップと、
を含む、方法。
　【請求項９】
　請求項１〜８のいずれか一項に記載の方法であって、更に、
　前記サービス要求を、前記割り当てられたサービング・ネットワーク・
ノードに送るステップと、
　前記割り当てられたサービング・ネットワーク・ノードのメモリがユー
ザ・プロファイルを含まない場合に、前記割り当てられたサービング・ネットワーク・ノードが前記ユーザ機器に関連付けられた前記ユーザ・プロファイルを要求するステップと、
を含む、方法。
　【請求項１０】
　請求項１〜９のいずれか一項に記載の方法であって、更に、
　前記サービス要求を、該サービス要求に関連付けられたサービスを含むアプリケーション・サーバにルーティングするステップを含む、方法。
　【請求項１１】
　請求項４に記載の方法において、前記サービス要求がサービス終了要求であり、前記位置データベースが、更に、前記通信ネットワークに登録されたユーザ機器に割り当てられたアクセス・ネットワーク・ノードに関連付けられる位置情報を含み、当該方法が、更に、
　サービス終了要求に関連付けられた終端ユーザ機器が前記通信ネットワークに登録されている場合に、前記終端ユーザ機器に割り当てられた前記アクセス・ネットワーク・ノードに関連付けられた前記位置情報について前記位置データベースに要求するステップを含む、方法。
　【請求項１２】
　請求項１１に記載の方法であって、
　前記サービス終了要求を、前記アクセス・ネットワーク・ノードを介して前記終端ユーザ機器にルーティングするステップを含む方法。
　【請求項１３】
　請求項１〜１２のいずれか一項に記載の方法であって、
　前記通信ネットワークのサービスへの加入者に関連付けられたユーザ・プロファイルを更新するステップと、
　前記ユーザ・プロファイルの更新に応答して、前記所定の数のサービン
グ・ネットワーク・ノードの少なくとも一部についてメモリに格納された１以上のユーザ・プロファイルを削除するステップと、
を含む、方法。
　【請求項１４】
　請求項１３記載の方法において、更に、
　ユーザ・プロファイル更新メッセージを、前記通信ネットワークのサービスへの加入者に関連付けられたユーザ・プロファイルを含む加入者データ
ベースに送るステップと、
　前記加入者データベース内の前記ユーザ・プロファイルを更新するステップと、
　前記加入者データベースが、前記所定の数のサービング・ネットワーク・ノードの少なくとも一部に関連付けられた位置情報を要求するステップと、
　ユーザ・プロファイル・リフレッシュ・メッセージを前記サービング・
ネットワーク・ノードに送信するステップと、
　前記ユーザ・プロファイルがメモリに格納されている場合に、前記ユー
ザ・プロファイル入力を前記メモリから削除するステップと、
を含む、方法。
　【請求項１５】
　請求項１〜１４のいずれか一項に記載の方法において、前記サービス要求がＳＢＣ、Ｐ−ＣＳＣＦ、ＩＢＣＦ、Ｓ−ＣＳＣＦ、またはＩ−ＣＳＣＦによって受信される、方法。
　【請求項１６】
　請求項４、６、７、８または１１に記載の方法において、前記位置データベースが加入者データベースと同一場所に位置し、または、前記位置データベースが別のネットワーク・ノードに位置する、方法。
　【請求項１７】
　通信ネットワークにおいてサービング・ネットワーク・ノードを動的に割り当てるように構成されるネットワーク・ノードであって、当該ネットワーク・ノードが、
　ユーザ機器、別のネットワークまたはネットワーク・ノードに関連付けられるサービス要求を受信する手段であって、前記サービス要求が登録または再登録要求ではない、手段と、
　所定の数のサービング・ネットワーク・ノードの少なくとも一部に関連付けられる負荷情報を受信する手段と、
　前記受信する手段がサービス要求を受信したときに、前記所定の数のサービング・ネットワーク・ノードの内１つを前記ユーザ機器、前記別のネットワーク、または前記ネットワーク・ノードに割り当てる手段であって、該割当が前記負荷情報に基づく手段と、
を備える、ネットワーク・ノード。
　【請求項１８】
　請求項１７に記載のネットワーク・ノードであって、更に、
　ユーザ機器、別のネットワーク、または前記所定の数のサービング・ネットワーク・ノードの内少なくとも１つに割り当てられるネットワーク・ノードを識別する割当情報を送る手段を備える、ネットワーク・ノード。
　【請求項１９】
　請求項１７または１８に記載のネットワーク・ノードであって、更に、
　ユーザ・プロファイル・リフレッシュ・メッセージを受信する手段と、
　メモリが前記ユーザ・プロファイル・リフレッシュ・メッセージにおいて識別される前記ユーザ・プロファイルを含む場合に、前記ネットワーク・
ノードのメモリからユーザ・プロファイル入力を削除する手段と、
を備える、ネットワーク・ノード。
　【請求項２０】
　請求項１７〜１９のいずれか一項に記載のネットワーク・ノードと共に用いるための位置サーバであって、当該位置サーバが、前記所定の数のサービング・ネットワーク・ノードに関連付けられた位置情報と、ユーザ機器、他のネットワーク、または前記所定の数のサービング・ネットワーク・ノードの内少なくとも１つに割り当てられるネットワーク・ノードを識別する識別情報と、前記通信ネットワークに登録されたユーザ機器に割り当てられるアクセス・ネットワーク・ノードに関連付けられた位置情報とを含む位置データベースを備え、当該位置サーバが、
　ユーザ機器、他のネットワーク、または前記所定の数のサービング・ネットワーク・ノードに内少なくとも１つに割り当てられたネットワーク・ノードを識別する割当情報を受信および送信するための手段と、
　前記所定の数のサービング・ネットワーク・ノードに関連付けられ、および／または前記通信ネットワークに登録されたユーザ機器に割り当てられた前記アクセス・ネットワーク・ノードに関連付けられた位置情報を受信および送信する手段と、
を備える、位置サーバ。
　【請求項２１】
　通信システムであって、サービング・ネットワーク・ノードを少なくとも１つのユーザ機器、他のネットワーク、またはネットワーク・ノードに動的に割り当てるように構成され、当該通信ネットワークが、請求項１７〜１９のいずれか一項に記載の少なくとも１つのネットワーク・ノードと、請求項２０に記載の位置サーバとを備える、通信システム。
　【請求項２２】
　コンピュータによってランされる時に、請求項１〜１６のいずれか一項に記載の方法を実行するように構成されるソフトウェア・コード部を備える、コンピュータ・プログラム。」　
第３．当審の拒絶理由の概要
　平成２８年６月８日付けで通知した当審の拒絶理由は、特許請求の範囲の請求項１、１７、２０及び２３の記載が不備のため、特許法第３６条第６項第２号に規定する要件を満たしていないという理由１、及び請求項１、１
７、及びそれら引用する他の請求項と、請求項２０とは、単一の一般的発明概念を形成するように連関している技術的関係にないので、特許法第３７条に規定する要件を満たしていないという理由２である。 
　上記「第２．特許請求の範囲の記載」に記載したように、本願の特許請求の範囲の記載は、補正によって明確なものとなり、理由１は解消した。
　また、補正前の請求項２０は削除されたので、理由２も解消した。
　よって、当審の拒絶理由は解消した。
第４．原査定の理由の概要
　原査定の理由の概要は、本願の請求項１−２３に係る発明は、その出願前に外国において、頒布された欧州特許出願公開第１９７３２９５号明細書
（以下、「引用例」という。）に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないというものである。
第５．当審の判断
１．引用発明
　原査定の拒絶の理由に引用された引用例には、図面とともに以下の記載がなされている。
　
（１）「Claims
1. A call session control server assignment method for assigning a particular call session control server (S-CSCF server) that registers a user equipment and administrates call session control on the user equipment from a plurality of S-CSCF servers in an IP network for achieving IMS (IP Multimedia Subsystem architecture, comprising the steps of: providing a S-CSCF server selection table that stores in correspondence with each S-CSCF server priority information indicating the order of priority when assigning user equipment in accordance with the current operation condition of each S-CSCF server in a home subscriber server (HSS server) that stores user information for each user equipment;;
referring to the S-CSCF server selection table by the HSS server when it receives an interrogation from an interrogating session control server (I-CSCF server) for determining a particular S-CSCF server that registers the user equipment at the time of registration thereof; and
selecting the S-CSCF server to be assigned by the HSS server in response to the current operation condition of each S-CSCF server for sending the selected S-CSCF server back to the I-CSCF server from which the interrogation is sent.」
（２）「[0037] In the IMS architecture having the network construction as described hereinabove, it is required that the user equipment UE performs proceedings (i.e., registration request by REGISTER message) to determine the S-CSCF server for making a call session control for each user equipment UE among a plurality of S-CSCF servers (call session control servers) disposed in the home network of each user equipment UE prior to transmission and receiving operations of each user equipment UE using the SIP protocol.
[0038] At this time, in a prior art, the P-CSCF server that received the REGISTER message from the user equipment UE for requesting registration interrogates the I-CSCF server. Then, the I-CSCF server that received the interrogation causes the HSS server to transfer a list of all S-CSCF servers in the home network and determines the S-CSCF servers in charge of the user equipment UE that sends the registration request, i.e., the S-CSCF servers that administrate call session controls of the user equipment UE in a predetermined sequence or order.
[0039] However, since the registration status of the user equipment UE dynamically changes in each S-CSCF server due to not only the registration request of the user equipment UE but also erasing of such registration, the conventional method of allocating the S-CSCF servers in a predetermined sequence results in incapability of evenly distributing the number of user equipment UE that are registered in the S-CSCF servers, thereby unavoidably encountering a trouble of concentrated loads in a particular S-CSCF server.
Summary of the Invention 
[0040] In consideration of the above problem associated with the prior art, it is an object of the present invention to provide a call session control server assignment method and a call session control server assignment stem for controlling the loads of the S-CSCF servers substantially equal by properly assigning the S-CSCF servers (Call Session Control Servers) in which the user equipment UE are registered in consideration of the registration status and the load status in each S-CSCF server.」
（３）「[0065] As shown in　Fig. 3 , at the time when the I-CSCF server 30 received from the HSS server 40 the candidates, in a form of list, of the S-CSCF servers 20, 21, 22 and the like to be used in communications of the user equipment UE by the UAA (User Authorization Answer9 of the Diameter protocol in the sequence SQ4 that has been described hereinabove with reference to　Fig. 2 , the UAA is constructed to receive in a form of including the currently registered subscribers (the number of registered user equipment UE) for each S-CSCF server 20, 21, 22 and the like as the S-CSCF information.
[0066] In other words, the HSS server 40 that receives interrogations from the I-CSCF server 30 is provided with an S-CSCF selection table 41 for selecting a particular S-CSCF server. The S-CSCF selection table 41 has the registered and memorized number of currently registered subscribers (i.e., the number of registered user equipment UE) for each S-CSCF server 20, 21, 22 and the like that is able to assigned as the registration S-CSCF server. When an interrogation is received from the I-CSCF server 30, the HSS server refers to the S-CSCF selection table 41 and returns to the I-CSCF server 30 the S-CSCF information as the UAA after editing in a form that includes the number of currently registered subscribers (the number of registered user equipment UE) for each S-CSCF server 20, 21, 22 and the like.
[0067] The I-CSCF server 30 that received the S-CSCF list information including the number of currently registered subscribers (the number of registered user equipment UE) from the HSS server 40 assigns one of the S-SCSCF servers having the minimum number of currently registered subscribers (the number of user equipment UE) from the S-CSCF servers 20, 21, 22 and like (the S-CSCF server 21 indicated as the S-CSCF #2 in the particular example as shown in　Fig. 3 ) as the particular S-CSCF server that administrates call session control for the user equipment UE 201 that sends the REGISTER message thereto. Subsequently, the I-CSCF server 30 informs the HSS server 40 the information for the newly assigned S-CSCF server and also sends the received REGISTER message to the S-CSCF server for causing the registration of the user equipment UE 201 to the assigned S-CSCF server (the S-CSCF server 21 in the particular example in　Fig. 3 ).
[0068] In performing the S-CSCF server selection procedures by the I-CSCF server 30 in cooperation with the HSS server 40 in the above manner, it is possible to equalize the number of registered subscribers (the number of user equipment UE) in each S-CSCF server 20, 21, 22 and the like, thereby effectively achieving smooth load distributions.」
（４）「(Other embodiments) 
[0078] Fig. 6　is a conceptual diagram of an example different from　Fig. 3　of the call session control server (S-CSCF server) assignment method according to the present invention. Contents of registration in an S-CSCF selection table 41A for selecting S-CSCF servers provided in the HSS server 40 differ from those in the S-CSCF selection table 41 in　Fig. 3 . In other words, the S-CSCF selection table 41A as shown in　Fig. 6　utilizes information representing the current operating condition of the respective S-CSCF servers 20, 21, 22 and the like as priority information that indicates the order of priority in selecting the S-CSCF servers. Such priority information is registered as parameter 1, parameter 2 and the like in place of the number of registered subscribers (the number of registered user equipment UE) in the S-CSCF selection table 41 in　Fig. 3 .
[0079] It is to be noted herein that the priority information for S-CSC server selection to be registered in the S-CSCF selection table 41A may be, for example, the information on call sessions such as the current amount of calls per unit time, the number of simultaneous connections or the number of transmitted or received messages of the respective S-CSCF servers 20, 21, 22 and the like to be used in replace of the number of registered subscribers (the number of registered user equipment UE). Alternatively, it is possible to use the information on the total loads such as the current rate of use of the processing processor (CPU) per unit time, the rate of use of memories, the number of total transmitted or received messages including maintenance messages per unit time, the total size of transmitted and received messages or the like of the respective S-CSCF servers 20, 21, 22 and the like. The use of such information on the total loads as the priority information for selecting the S-CSCF servers enables to set the order of priority for assigning the user equipment to an appropriate low order, for example, when the current condition of a certain S-CSCF server has a low load of call sessions but is in a considerably high total load condition due to maintenance procedures such as backup procedures and recovery procedures from confusions and troubles.」
　引用例のパテントファミリである特開２００８−２３６１８３号公報の対応する記載は以下のとおりである。
（１’）「【特許請求の範囲】
【請求項１】
　ＩＭＳ（IP Multimedia Subsystem）アークテキチャを実現するＩＰ網に
おいて、ユーザ端末の登録時に、複数の呼セッション制御サーバ（Ｓ-ＣＳ
ＣＦサーバ）の中から、当該ユーザ端末を登録し、当該ユーザ端末に関する呼セッション制御を司る呼セッション制御サーバを割り当てる呼セッション制御サーバ割り当て方法であって、各ユーザ端末ごとのユーザ情報を記憶するホーム加入者サーバ（ＨＳＳサーバ）に、呼セッション制御サーバそれぞれの現在の稼働状況に応じてユーザ端末を割り当てる際の優先順位を示す優先情報を呼セッション制御サーバごとに対応付けて記憶する呼セッション制御サーバ選択テーブルを備え、ユーザ端末の登録時に当該ユーザ端末を登録する呼セッション制御サーバを決定する問い合わせセッション制御サーバ
（Ｉ−ＣＳＣＦサーバ）から、前記ホーム加入者サーバに対して問い合わせがあった際に、前記ホーム加入者サーバは、前記呼セッション制御サーバ選択テーブルを参照して、各呼セッション制御サーバの現在の稼働状況に応じて、割り当てるべき呼セッション制御サーバを選択して、問い合わせ元の前記問い合わせセッション制御サーバに返送することを特徴とする呼セッション制御サーバ割り当て方法。」
（２’）「【００３６】
　以上のようなネットワーク構成を有するＩＭＳアークテクチャにおいて
は、各ユーザ端末ＵＥのＳＩＰプロトコルを用いた発着信動作に先立って、各ユーザ端末ＵＥのホーム網に配置されている複数のＳ−ＣＳＣＦサーバ
（呼セッション制御サーバ）のうち、各ユーザ端末ＵＥの呼セッション制御を司るＳ−ＣＳＣＦサーバを決定する手続き（つまり、ＲＥＧＩＳＴＥＲ
メッセージによる登録要求）をユーザ端末ＵＥが実施しておくことが必要である。
【００３７】
　このとき、従来の技術では、ユーザ端末ＵＥからＲＥＧＩＳＴＥＲメッ
セージによる登録要求を受け取ったＰ−ＣＳＣＦサーバは、Ｉ−ＣＳＣＦ
サーバに対して問い合わせを行い、問い合わせを受け取ったＩ−ＣＳＣＦ
サーバが、ＨＳＳサーバからホーム網に属するすべてのＳ−ＣＳＣＦサーバの一覧を転送させ、あらかじめ定めた一定の順序で、順番に、登録要求を送信してきたユーザ端末ＵＥの登録を担当するすなわちユーザ端末ＵＥの呼
セッション制御を司るＳ−ＣＳＣＦサーバを決定していた。
【００３８】
　しかしながら、ユーザ端末ＵＥの登録要求のみならず、登録抹消などによりユーザ端末ＵＥの登録状況がＳ−ＣＳＣＦサーバごとに動的に変動を伴っているので、従来の技術のように、一定の順序で順番にＳ−ＣＳＣＦサーバを割り付けていく方法では、各Ｓ−ＣＳＣＦサーバ間で、登録するユーザ端末ＵＥの個数を均等に配分することができず、特定のＳ−ＣＳＣＦサーバに負荷が集中してしまうという問題が避けられない。
【００３９】
　本発明は、かかる問題を解決するためになされたものであり、各Ｓ−ＣＳＣＦサーバ（呼セッション制御サーバ）におけるユーザ端末ＵＥの登録状況や各Ｓ−ＣＳＣＦサーバの負荷発生状況を勘案して、各Ｓ−ＣＳＣＦサーバへのユーザ端末ＵＥの登録先を割り当てることにより、各Ｓ−ＣＳＣＦサーバの負荷の均等化を可能とする呼セッション制御サーバ割り当て方法および呼セッション制御サーバ割り当てシステムを提供することを、その目的としている。」
（３’）「【００６５】
　図３に示すように、図２のシーケンスＳＱ４において、Ｉ−ＣＳＣＦサーバ３０が、ＨＳＳサーバ４０より、ユーザ端末ＵＥ２０１の通信に利用するＳ−ＣＳＣＦサーバ２０，２１，２２，…の候補を、一覧の形で、ＤｉａｍｅｔｅｒプロトコルのＵＡＡ(User Authorization Answer)により受け取っ
た際に、ＵＡＡには、Ｓ−ＣＳＣＦ情報として、Ｓ−ＣＳＣＦサーバ２０，２１，２２，…ごとの現在の登録加入者数（登録ユーザ端末ＵＥ数）が含まれている形で受信するように構成されている。
【００６６】
　つまり、Ｉ−ＣＳＣＦサーバ３０からの問い合わせを受け取るＨＳＳサーバ４０には、Ｓ−ＣＳＣＦ選択用のＳ−ＣＳＣＦ選択テーブル４１が備えられており、Ｓ−ＣＳＣＦ選択テーブル４１には、登録Ｓ−ＣＳＣＦサーバとしての割り当てが可能な各Ｓ−ＣＳＣＦサーバ２０，２１，２２，…ごとの現在の登録加入者数（登録ユーザ端末ＵＥ数）を登録記憶している。ＨＳＳサーバ４０は、Ｉ−ＣＳＣＦサーバ３０からの問い合わせを受け取った際
に、Ｓ−ＣＳＣＦ選択テーブル４１を参照して、Ｓ−ＣＳＣＦサーバ２０，２１，２２，…ごとの現在の登録加入者数（登録ユーザ端末ＵＥ数）を含む形式でＳ−ＣＳＣＦ情報を編集してＵＡＡとしてＩ−ＣＳＣＦサーバ３０に返送する。
【００６７】
　ＨＳＳサーバ４０から現在の登録加入者数（登録ユーザ端末ＵＥ数）を含むＳ−ＣＳＣＦ一覧情報を受信したＩ−ＣＳＣＦサーバ３０は、Ｓ−ＣＳＣＦサーバ２０，２１，２２，…の中から、現在の登録加入者数（登録ユーザ端末ＵＥ数）が最も少ないＳ−ＣＳＣＦ（図３の例では、Ｓ−ＣＳＣＦ＃２と表示されているＳ−ＣＳＣＦサーバ２１）を、ＲＥＧＩＳＴＥＲメッセージを送信してきたユーザ端末ＵＥ２０１の呼セッション制御を司るＳ−ＣＳＣＦとして割り付ける。しかる後、Ｉ−ＣＳＣＦ３０は、新たに割り当てたＳ−ＣＳＣＦサーバに関する情報をＨＳＳサーバ４０に通知するとともに、図２のシーケンスＳＱ５に示すように、割り付けたＳ−ＣＳＣＦサーバ（図３の例ではＳ−ＣＳＣＦサーバ２１）に対して、当該ユーザ端末ＵＥ２０１の登録を行わせるために、Ｓ−ＣＳＣＦサーバに対して、受信していたＲＥＧＩＳＴＥＲメッセージを送信する。
【００６８】
　Ｉ−ＣＳＣＦサーバ３０において、以上のようなＳ−ＣＳＣＦサーバ選択処理をＨＳＳサーバ４０と連携して行うことにより、各Ｓ−ＣＳＣＦサーバ２０，２１，２２，…に登録する加入者数（ユーザ端末ＵＥ数）を均等化することができ、負荷の平滑化を図ることが可能となる。」
（４’）「【００７８】
　（その他の実施例）
　図６は、本発明による呼セッション制御サーバ（Ｓ−ＣＳＣＦサーバ）の割り当て方法の図３とは異なる例を説明するための概念図であり、ＨＳＳ
サーバ４０に備えられるＳ−ＣＳＣＦサーバ選択用のＳ−ＣＳＣＦ選択テーブル４１Ａへの登録内容が、図３のＳ−ＣＳＣＦ選択テーブル４１の場合とは異なっている。つまり、図６に示すＳ−ＣＳＣＦ選択テーブル４１Ａは、各Ｓ−ＣＳＣＦサーバ２０，２１，２２，…の現在の稼働状況に応じた情報を、Ｓ−ＣＳＣＦサーバ選択時の優先順位を示す優先情報として用い、図３のＳ−ＣＳＣＦ選択テーブル４１の場合の登録加入者数（登録ユーザ端末ＵＥ数）の代わりに、パラメータ１、パラメータ２、…として登録されている例を示している。
【００７９】
　ここで、Ｓ−ＣＳＣＦ選択テーブル４１Ａに登録するＳ−ＣＳＣＦサーバ選択用の優先情報としては、例えば、各Ｓ−ＣＳＣＦサーバ２０，２１，２２，…の現在の単位時間当たりの呼量や同時接続数やメッセージ送受信数などの呼セッションに関する情報を、登録加入者数（ユーザ端末ＵＥ数）の代わりに用いても良いし、あるいは、各Ｓ−ＣＳＣＦサーバ２０，２１，２
２，…の現在の単位時間当たりの処理プロセッサ（ＣＰＵ）の使用率やメモリ使用率や保守用のメッセージも含む単位時間当たりの総メッセージ送受信数や総送受信メッセージサイズなどの総合的な負荷に関する情報を用いても良い。かくのごとき総合的な負荷に関する情報をＳ−ＣＳＣＦサーバ選択用の優先情報として用いることにより、例えば、あるＳ−ＣＳＣＦサーバの現在の状態が、呼セッションによる負荷が少なくても、バックアップ処理や輻輳・障害からの回復処理などの保守用の処理が実施されていて、トータルとしてかなりの負荷状態になっている場合には、ユーザ端末ＵＥの割り当て優先順位を、適切な順位まで下げるように設定することができる。」
　したがって、引用例には、次の発明（以下、「引用発明」という。）が記載されているといえる。
　ＩＭＳ（IP Multimedia Subsystem）アークテキチャを実現するＩＰ網に
おいて、ユーザ端末の登録時に、複数の呼セッション制御サーバ（Ｓ-ＣＳ
ＣＦサーバ）の中から、当該ユーザ端末を登録し、当該ユーザ端末に関する呼セッション制御を司る呼セッション制御サーバを割り当てる呼セッション制御サーバ割り当て方法であって、各ユーザ端末ごとのユーザ情報を記憶するホーム加入者サーバ（ＨＳＳサーバ）に、呼セッション制御サーバそれぞれの現在の稼働状況に応じてユーザ端末を割り当てる際の優先順位を示す優先情報を呼セッション制御サーバごとに対応付けて記憶する呼セッション制御サーバ選択テーブルを備え、ユーザ端末の登録時に当該ユーザ端末を登録する呼セッション制御サーバを決定する問い合わせセッション制御サーバ
（Ｉ−ＣＳＣＦサーバ）から、前記ホーム加入者サーバに対して問い合わせがあった際に、前記ホーム加入者サーバは、前記呼セッション制御サーバ選択テーブルを参照して、各呼セッション制御サーバの現在の稼働状況に応じて、割り当てるべき呼セッション制御サーバを選択して、問い合わせ元の前記問い合わせセッション制御サーバに返送する呼セッション制御サーバ割り当て方法であって、
　前記優先情報は、各呼セッション制御サーバ（Ｓ−ＣＳＣＦサーバ）の現在の単位時間当たりの処理プロセッサ（ＣＰＵ）の使用率やメモリ使用率や保守用のメッセージも含む単位時間当たりの総メッセージ送受信数や総送受信メッセージサイズなどの総合的な負荷に関する情報であることを特徴とする呼セッション制御サーバ割り当て方法。
２．対比
　本願の請求項１−２２に係る発明は、本願の特許請求の範囲の各請求項に記載された事項により特定されるとおりのものであり、その記載は前記「第２．特許請求の範囲の記載」のとおりである。
　本願の請求項１に係る発明（以下、「本願発明」という。）と引用発明とを対比する。
　引用発明の「呼セッション制御サーバ（Ｓ−ＣＳＣＦサーバ）」は、サービング・ネットワーク・ノードといえ、引用発明は「ＩＭＳ（IP Multimedia Subsystem）アークテキチャを実現するＩＰ網において、ユーザ端末の登
録時に、複数の呼セッション制御サーバ（Ｓ-ＣＳＣＦサーバ）の中から、
当該ユーザ端末を登録し、当該ユーザ端末に関する呼セッション制御を司る呼セッション制御サーバを割り当てる呼セッション制御サーバ割り当て方
法」であるから、本願発明とは、所定の数のサービング・ネットワーク・
ノードを備える通信ネットワークにおいてサービング・ネットワーク・ノードを割り当てるための方法である点で共通する。
　引用発明は「ユーザ端末の登録時」に呼セッション制御サーバを割り当てるものであり、そのような登録が「ユーザ端末」の要求によるものであること、及び「ＩＰ網」のネットワーク・ノードといえる、いずれかの制御サーバがそのような要求を受信することは明らかであるので、本願発明とは、通信ネットワーク内のネットワーク・ノードにおいて、ユーザ機器に関連付けられた要求を受信するステップを含む点で共通する。
　引用発明の「優先情報」は、「各呼セッション制御サーバ（Ｓ−ＣＳＣＦサーバ）の現在の単位時間当たりの処理プロセッサ（ＣＰＵ）の使用率やメモリ使用率や保守用のメッセージも含む単位時間当たりの総メッセージ送受信数や総送受信メッセージサイズなどの総合的な負荷に関する情報」であるから、サービング・ネットワーク・ノードに関連付けられた負荷情報とい
え、「各ユーザ端末ごとのユーザ情報を記憶するホーム加入者サーバ（ＨＳＳサーバ）に、呼セッション制御サーバそれぞれの現在の稼働状況に応じてユーザ端末を割り当てる際の優先順位を示す優先情報を呼セッション制御
サーバごとに対応付けて記憶する呼セッション制御サーバ選択テーブルを備え」とするものであるから、「優先情報」である負荷情報が、ネットワー
ク・ノードといえるホーム加入者サーバ（ＨＳＳサーバ）に提供され、本願発明とは、サービング・ネットワーク・ノードに関連付けられた負荷情報
を、少なくとも１つのネットワーク・ノードに提供するステップを含む点で共通する。
　引用発明は「ユーザ端末の登録時に当該ユーザ端末を登録する呼セッション制御サーバを決定する問い合わせセッション制御サーバ（Ｉ−ＣＳＣＦ
サーバ）から、前記ホーム加入者サーバに対して問い合わせがあった際に、前記ホーム加入者サーバは、前記呼セッション制御サーバ選択テーブルを参照して、各呼セッション制御サーバの現在の稼働状況に応じて、割り当てるべき呼セッション制御サーバを選択して、問い合わせ元の前記問い合わせ
セッション制御サーバに返送する」ものであり、上記のとおり「優先情報」は負荷情報といえるので、本願発明とは、要求の受信に応答して、所定の数のサービング・ネットワーク・ノードの内１つを、負荷情報に基づいてユーザ機器に割り当てるステップを含む点で共通する。
　したがって、本願発明と引用発明とを対比すると、以下の点で一致し、また相違する。
（１）一致点
　所定の数のサービング・ネットワーク・ノードを備える通信ネットワークにおいてサービング・ネットワーク・ノードを割り当てるための方法であって、当該方法が、
　前記通信ネットワーク内のネットワーク・ノードにおいて、ユーザ機器、他のネットワーク、またはネットワーク・ノードに関連付けられた要求を受信するステップと、
　前記サービング・ネットワーク・ノードに関連付けられた負荷情報を、少なくとも１つの前記ネットワーク・ノードに提供するステップと、
　前記要求の受信に応答して、前記所定の数のサービング・ネットワーク・ノードの内１つを、前記負荷情報に基づいて前記ユーザ機器、前記他のネットワーク、または前記ネットワーク・ノードに割り当てるステップと、
を含む、方法。
（２）相違点
　本願発明は要求が「登録または再登録要求ではない」とする「サービス要求」であり、その受信に応答して、サービング・ネットワーク・ノードを動的に割り当てるのに対して、引用発明は要求がユーザ端末の登録に関するものであり、「サービス要求」の受信に応答して動的に割り当てることについての特定がない点。
３．判断
　上記相違点について検討する。
　前置報告書には「サービス要求」に関連して以下の記載がある。
「出願人は、この審判請求において、本願の請求項に係る発明が、「サービス要求が（再）登録要求ではない」ことにより「「ネットワーク・ノードに割り当て」られる「サービング・ネットワーク・ノード」は流動的に都度変更することができる」点で、引用文献１とは異なる旨、主張している。
　しかしながら、下記で挙げる引用文献２（たとえば第７ページ第１０行〜第８ページ第２５行参照）には、ＵＥに対してＳ−ＣＳＣＦが割り当てられた後、地理的な要因や負荷分散等を考慮して最適なＳ−ＣＳＣＦが存在することを検出した場合、ＨＳＳにＳ−ＣＳＣＦへ信号を送信させる再登録や
セッションの終了などのイベントをトリガとしてＳ−ＣＳＣＦの再割り当てを行う技術が記載されている。すなわち、引用文献２には、（再）登録に限らず様々なサービス要求を受信した場合にＳ−ＣＳＣＦの再割り当てを流動的に行う技術が記載されている。
　また、引用文献３には、ＵＥに対するＳ−ＣＳＣＦの固定的な登録による弊害を回避し（たとえば［０００４］段落参照）、障害時やＩＭＳの構成変更時などに流動的にＳ−ＣＳＣＦの変更を可能とする（たとえば［００１
４］〜［００１５］段落参照）技術が記載されている。
　引用文献１記載の方法においてＳ−ＣＳＣＦサーバの割り付けを行う際
に、引用文献２または引用文献３に記載の前記技術を適用して、適宜サービス要求を受信することにより流動的にＳ−ＣＳＣＦサーバの変更を可能とする構成とすることは、当業者が容易に想到し得たことと認められる。」
　引用文献２として引用された国際公開第２０１０／１０５６４３号には、以下の記載がある。
「Figure 3, illustrates the basic signalling flow for the procedure of re-allocating an S-CSCF. The network entities and UE 22 carry the same reference numerals as shown in Figure 2. As shown at the outset (step 301) a first S-CSCF 20, S- CSCF1 , is allocated to a user 22, which is not optimal (for example, as described above the user 22 may have been moved to S-CSCF1 20 as a result of an originally allocated S-CSCF going down). Instead, S-CSCF2 24 would be the preferred proxy to use (for example due to its geographical location/proximity to the user 22). As explained above the allocation of the S- CSCF1 20 to the user 22 may either be because the user 22 is registered with the S-CSCF1 20, or because the S-CSCF 1 20 has been assigned to the user for the provision of unregistered services.
 
At some point in time, it is decided to change the allocation so that S-CSCF 2 24, which is seen as the optimal S-CSCF, is allocated to the user 22. In the example illustrated in Figure 3, at step 302 the user's HSS 26 issues an instruction for the re-allocation, which is sent to the S-CSCF1 20 through the Cx interface. Note that the decision to change need not have been made by the HSS 26 itself, but may have originated somewhere else in the IMS network. For example, a load balancing function might be employed, that would monitor the load on each S-CSCF and would be programmed to re-distribute the load in the event of a detected imbalance. One example of this type of function is described in 3GPP TR 23.812. Another possibility is that local logic may be employed in the S-CSCF that enables it to determine that a user allocated to it should be moved to another S-CSCF.　The re-allocation instruction at step 302 will trigger the de-allocation (i.e. the de- registration of the user 22 from S-CSCF1 20, or de-assignment of S-CSCF1 20 from user 22). However, the instruction includes criteria that must be met before the de-allocation is implemented. In a simple form the instruction and criteria could be an Administrative Deregistration request with a new value stating DE- REGISTER-IF-NO-ACTIVE-SESSIONS. More advanced criteria could include taking account of different types of session and/or dialogs that may exist. For example the criteria might indicate that the S-CSCF should only de-register the user if no SIP INVITE sessions exist, or if no SIP INVITE sessions of service MMTEL exist.
 
In the embodiment shown in Figure 3, the re-allocation instruction and the criteria are sent together to the S-CSCF1 20 in step 302. However, it is possible that, for example, a determination could be made at an early stage that the S-CSCF1 20 is not optimal, but the criteria for de-allocating S-CSCF1 20 from the user could depend on other factors (such as the amount of signal traffic, or the availability of other S-CSCFs, etc.). In that case, the HSS 26 could wait until a later time before sending the de-allocation criteria to the S- CSCF1 20. Another possibility is that the HSS 26 could wait until another event arises that causes it to send a signal to the S-CSCF1 20 (such as re-registration or termination of a session by the user) and the HSS 26 sends the criteria to the S-CSCF1 20 at that stage. Alternatively, the order could be reversed such that the de-allocation criteria are sent first to the S-CSCF1 20, and the actual re- allocation instruction is sent later, for example when another event arise
s.」
　引用文献２のパテントファミリである特表２０１２−５２１１１５号公報の対応する記載は以下のとおりである。
「【００２９】
　図３は、Ｓ−ＣＳＣＦを再度割り当てる手続きについての基本的なシグナリングフローを説明する。ネットワークエンティティおよびＵＥ２２は、図２に示されるものと同一の参照番号を伴う。最初に示されるように（ステップ３０１）、第１のＳ−ＣＳＣＦ２０であるＳ−ＣＳＣＦ１がユーザ２２に割り当てられる。当該Ｓ−ＣＳＣＦ１は、最適ではない（例えば、上記のように、ユーザ２２は、元々割り当てられたＳ−ＣＳＣＦがダウンした結果としてＳ−ＣＳＣＦ１　２０に移動し得る）。代わりに、Ｓ−ＣＳＣＦ２　２４は、（例えば、地理的な位置／ユーザ２２への近接に起因して）使用するのに好適なプロキシである。上記のように、ユーザ２２へのＳ−ＣＳＣＦ１　２０の割当ては、ユーザ２２がＳ−ＣＳＣＦ１　２０と共に登録されるから、またはＳ−ＣＳＣＦ１　２０がＳ−ＣＳＣＦ１　２０が未登録サービスの提供のためにユーザに指定されたからのいずれかであってもよい。
【００３０】
　ある時点で、割当てを変更することが決定され、それにより、最適なＳ−ＣＳＣＦとしてみなされるＳ−ＣＳＣＦ２　２４がユーザ２２に割り当てられる。図３で説明される例では、ステップ３０２で、ユーザのＨＳＳ２６
は、再割当てについての指示を出す。当該指示は、Ｃｘインターフェースを通じてＳ−ＣＳＣＦ１　２０に送信される。変更することの決定は、ＨＳＳ２６自体により行われる必要はないが、ＩＭＳネットワークの中の別のどこかで発生してもよい、ということに留意する。例えば、負荷分散機能が用いられてもよい。当該負荷分散機能が、各Ｓ−ＣＳＣＦにおける負荷を監視
し、不均衡が検出される場合に、負荷を再分散させるようにプログラムされる。この種類の機能の一例は、３ＧＰＰのＴＲ２３．８１２で説明される。別の可能性は、割り当てられたユーザが別のＳ−ＣＳＣＦに移動すべきであると判定することを可能にするローカルロジックがＳ−ＣＳＣＦの中で用いられてもよいということである。
【００３１】
　ステップ３０２での再割当ての指示は、割当て解除（すなわち、Ｓ−ＣＳＣＦ１　２０からのユーザ２２の登録取消し、またはユーザ２２からのＳ−ＣＳＣＦ１　２０の指定取消し）をトリガ（trigger）する。しかしなが
ら、上記指示は、割当て解除が実行される前に満たされなければならない基準を含む。単純な形式では、指示および基準は、アクティブなセッションがない場合の登録取消し（DE-REGISTER-IF-NO-ACTIVE-SESSIONS）を開始する
新たな値を伴う管理登録解除（Administrative　Deregistration）要求であることも可能である。より進化した基準は、存在し得る異なる種類のセッ
ションおよび／または対話を考慮することを含むことが可能である。例え
ば、上記基準は、ＳＩＰ　ＩＮＶＩＴＥセッションが存在しない場合にの
み、またはサービスＭＭＴＥＬのＳＩＰ　ＩＮＶＩＴＥセッションが存在しない場合にのみ、Ｓ−ＣＳＣＦがユーザの登録を取り消すべきであることを示してもよい。
【００３２】
　図３に示される実施形態では、再割当ての指示および基準は、ステップ３０２でＳ−ＣＳＣＦ１　２０に共に送信される。しかしながら、例えば、Ｓ−ＣＳＣＦ１　２０が最適でないという判定は初期段階で行われることができるが、ユーザからのＳ−ＣＳＣＦ１　２０の割当て解除についての基準は他の要素（信号トラフィックの量、または他のＳ−ＣＳＣＦの可用性、等）に依存できる、ということが可能である。その場合に、ＨＳＳ２６は、Ｓ−ＣＳＣＦ１　２０に割当て解除の基準を送信する前のしばらく後まで、待機することができる。別の可能性は、ＨＳＳ２６にＳ−ＣＳＣＦ１　２０へ信号を送信させる別のイベント（再登録またはユーザによるセッションの終
了、等）が発生するまでＨＳＳ２６は待機することができ、ＨＳＳ２６はその段階でＳ−ＣＳＣＦ１　２０に基準を送信する、とういことである。代わりに、命令が予約されることが可能であり、それにより、割当て解除の基準がまずＳ−ＣＳＣＦ１　２０に送信され、例えば別のイベントが発生する場合に実際の再割当ての指示がその後送信される。」
　
　引用文献３として引用された特開２０１０−２６３５９７号公報には、以下の記載がある。
　
「【背景技術】
【０００２】
　従来から知られているＳＩＰ（Session Initiation Protocol）は、ＩＰ
上における呼制御に用いられるプロトコルであり、通信を行なう端末間で通信に必要なＩＰアドレスやポート番号、エンコーディング等のネゴシエー
ション、発呼、着呼などの制御を行なう際に用いられる。これに加え、ＩＭＳ（IP Multimedia Subsystem）では、このＳＩＰの情報に基づいて、通信
に必要なネットワークリソースの割り当て、ゲート制御を行なう。
【０００３】
　ＩＭＳでは、ＳＩＰ処理を行なうノードとして、複数のＣＳＣＦ（Call Session Control Function）を定めている。そのうち、Ｐ−ＣＳＣＦ（Proxy CSCF）は、端末から直接接続されるノードであり、暗号化やメッセージの
フィルタリング等を行なう。また、Ｉ−ＣＳＣＦ（Interrogating CSCF）
は、ＳＩＰのルーティングを行なう際、転送先の解決や、他ドメインへ転送するときの処理を行なう。Ｓ−ＣＳＣＦ（Serving CSCF）は、端末の登録やアプリケーションサーバとの連携、相手の解決などＳＩＰの主要な機能を備える。
【０００４】
　これらのノードが、一度端末を登録し、サービスを開始すると、その後に端末の処理を行なうノードが変更されることはない。そのため、障害等で
ノードでの処理継続が困難となった場合、ＩＭＳが、その異常を検知して他のノードへ処理を割り当て直し、その後、端末が、その異常を検知して再度登録を行なうまで、サービスが遮断されてしまう。例えば、待ち受け状態の端末へ通信できなくなるなど、サービスへの影響は大きい。これらに対し現在では、ホットスタンバイなどを導入し、ノード自体に堅牢性を与えてい
る。」
「【００１４】
　（４）また、本発明のノード変更方法は、ＳＩＰ（Session Initiation Protocol）処理を行なう少なくとも一つのＰ−ＣＳＣＦ（Proxy Call Session Control Function）および複数のＳ−ＣＳＣＦ（Serving Call Session Control Function）を含むＩＭＳ（IP Multimedia Subsystem）ネットワークにおけるノード変更方法であって、前記Ｐ−ＣＳＣＦにおいて、前記Ｓ−ＣＳＣＦに登録しているＩＭＳ端末の情報を保持するステップと、いずれかの前記Ｓ−ＣＳＣＦの異常が検知されたときに出力されるノード変更指示を受信するステップと、前記保持されているＩＭＳ端末の情報に基づいて、前記異常が検知されたＳ−ＣＳＣＦに登録しているＩＭＳ端末に対して、再登録通知メッセージを出力するステップと、前記ＩＭＳ端末において、前記再登録通知メッセージに基づいて、前記異常が検知されたＳ−ＣＳＣＦ以外のＳ−ＣＳＣＦに再登録を行なうステップと、を少なくとも含むことを特徴としている。
【００１５】
　このように、異常が検知されたＳ−ＣＳＣＦに登録しているＩＭＳ端末に対して、再登録通知メッセージを出力し、ＩＭＳ端末は、再登録通知メッ
セージに基づいて、異常が検知されたＳ−ＣＳＣＦ以外のＳ−ＣＳＣＦに再登録を行なうので、ＩＭＳノード（Ｓ−ＣＳＣＦ）に障害が発生した場合であっても、迅速にＩＭＳ端末へ通知して、サービスを再開することができ
る。また、障害時以外でも、メンテナンスやＩＭＳの構成変更を、サービスを中断することなく、すなわち、サービスを継続しながら行なうことができる。さらに、高度な対障害性をもたない汎用ＰＣを用いて、可用性の高いＩＭＳを構築することができる。さらに、ＩＭＳ端末へ通知する際に、既存のＳＵＢＳＣＲＩＢＥセッションを用いることで、既存システムへのインパクトを小さくできる。」
　上記引用文献２及び３には、サービング・ネットワーク・ノードであるＳ−ＣＳＣＦの割当てに関する記載があるが、「サービス要求」の受信に応答して動的に割り当てることについては、記載も示唆もない。
　上記引用文献２及び３を考慮しても、ユーザ端末の登録に関する要求に替えて「サービス要求」の受信に応答してサービング・ネットワーク・ノードを動的に割り当てることに、困難な点はないということはできないので、本願発明は、引用発明に基づいて当業者が容易に発明をすることができたものとすることはできない。
　請求項２−２２に係る発明についても同様である。
第５　むすび
　以上のとおり、本願の請求項１−２２に係る発明は、引用発明に基いて、当業者が容易に発明をすることができたものとすることができないから、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。