• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04W
審判 査定不服 2項進歩性 取り消して特許、登録 H04W
管理番号 1320162
審判番号 不服2015-15969  
総通号数 203 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-11-25 
種別 拒絶査定不服の審決 
審判請求日 2015-08-28 
確定日 2016-10-26 
事件の表示 特願2013-541281「サービング・ネットワーク・ノードの動的な割り当て」拒絶査定不服審判事件〔平成24年 6月 7日国際公開、WO2012/072407、平成26年 1月16日国内公表、特表2014-501095、請求項の数(22)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1.手続の経緯
本願は、平成23年(2011年)11月14日(パリ条約による優先権主張 2010年11月30日(EP)欧州特許庁、2011年6月24日(EP)欧州特許庁)を国際出願日とする出願であって、手続の概要は以下のとおりである。

平成25年 5月30日 国内書面
平成26年 5月15日 拒絶理由通知
平成26年11月21日 意見書、手続補正書
平成27年 4月24日 拒絶査定
平成27年 8月28日 審判請求、手続補正書
平成27年12月28日 前置報告
平成28年 6月 8日 拒絶理由通知
平成28年 9月 6日 意見書、手続補正書

第2.特許請求の範囲の記載
本願の特許請求の範囲の記載は、平成28年9月6日付けの手続補正書の特許請求の範囲に記載された以下のとおりのものである。

「 【請求項1】
所定の数のサービング・ネットワーク・ノードを備える通信ネットワークにおいてサービング・ネットワーク・ノードを動的に割り当てるための方法であって、当該方法が、
前記通信ネットワーク内のネットワーク・ノードにおいて、ユーザ機器、他のネットワーク、またはネットワーク・ノードに関連付けられたサービス要求を受信するステップであって、前記サービス要求が登録または再登録要求ではない、ステップと、
前記サービング・ネットワーク・ノードに関連付けられた負荷情報を、少なくとも1つの前記ネットワーク・ノードに提供するステップと、
前記サービス要求の受信に応答して、前記所定の数のサービング・ネットワーク・ノードの内1つを、前記負荷情報に基づいて前記ユーザ機器、前記他のネットワーク、または前記ネットワーク・ノードに割り当てるステップと、
を含む、方法。
【請求項2】
前記負荷情報が前記サービス要求に応答して提供される、請求項1記載の方法。
【請求項3】
前記負荷情報が所定の時間間隔で提供される、請求項1記載の方法。
【請求項4】
請求項1?3のいずれか一項に記載の方法において、前記通信ネットワークが、更に、前記所定の数のサービング・ネットワーク・ノードに関連付けられた位置情報と、任意で、前記所定の数のサービング・ネットワーク・
ノードの内少なくとも1つに割り当てられたユーザ機器、他のネットワー
ク、またはネットワーク・ノードを識別する割当情報とを収容する位置データベースを備える、方法。
【請求項5】
請求項1?4のいずれか一項に記載の方法において、前記負荷情報が、前記サービング・ネットワーク・ノードの少なくとも一部に関連付けられた応答時間情報および/またはCPUリソース情報を含む、方法。
【請求項6】
請求項1?5のいずれか一項に記載の方法であって、
前記所定の数のサービング・ネットワーク・ノードの少なくとも一部を識別するリストを受信するステップであって、該リストが前記サービング・
ネットワーク・ノードに関連付けられた位置情報を更に含む、ステップと、
前記所定の数のサービング・ネットワーク・ノードの少なくとも一部に関連付けられた負荷情報を受信するステップと、
サービング・ネットワーク・ノードを、選択規則および前記負荷情報に基づいて前記リストから選択するステップと、
前記選択したサービング・ネットワーク・ノードを前記ユーザ機器、前記他のネットワーク、または前記ネットワーク・ノードに割り当てるステップと、
を含む、方法。
【請求項7】
請求項1?6のいずれか一項に記載の方法であって、更に、
前記通信ネットワークに関連付けられたアクセス・ネットワーク・ノードに基づいて、
ユーザ機器を登録するステップと、任意で、
前記割り当てられたサービング・ネットワーク・ノードに関連付けられた位置情報を前記位置データベースに格納するステップと、
を含む、方法。
【請求項8】
請求項7に記載の方法であって、
前記通信ネットワークの境界におけるアクセス・ネットワーク・ノードを前記ユーザ機器に割り当てるステップと、
前記アクセス・ネットワーク・ノードに付随する登録機能を実行するス
テップと、
前記登録を、前記通信ネットワークのサービスへの加入者に関連付けられたユーザ・プロファイルを含む加入者データベースに格納するステップと、
位置情報を前記位置データベースに格納するステップと、
を含む、方法。
【請求項9】
請求項1?8のいずれか一項に記載の方法であって、更に、
前記サービス要求を、前記割り当てられたサービング・ネットワーク・
ノードに送るステップと、
前記割り当てられたサービング・ネットワーク・ノードのメモリがユー
ザ・プロファイルを含まない場合に、前記割り当てられたサービング・ネットワーク・ノードが前記ユーザ機器に関連付けられた前記ユーザ・プロファイルを要求するステップと、
を含む、方法。
【請求項10】
請求項1?9のいずれか一項に記載の方法であって、更に、
前記サービス要求を、該サービス要求に関連付けられたサービスを含むアプリケーション・サーバにルーティングするステップを含む、方法。
【請求項11】
請求項4に記載の方法において、前記サービス要求がサービス終了要求であり、前記位置データベースが、更に、前記通信ネットワークに登録されたユーザ機器に割り当てられたアクセス・ネットワーク・ノードに関連付けられる位置情報を含み、当該方法が、更に、
サービス終了要求に関連付けられた終端ユーザ機器が前記通信ネットワークに登録されている場合に、前記終端ユーザ機器に割り当てられた前記アクセス・ネットワーク・ノードに関連付けられた前記位置情報について前記位置データベースに要求するステップを含む、方法。
【請求項12】
請求項11に記載の方法であって、
前記サービス終了要求を、前記アクセス・ネットワーク・ノードを介して前記終端ユーザ機器にルーティングするステップを含む方法。
【請求項13】
請求項1?12のいずれか一項に記載の方法であって、
前記通信ネットワークのサービスへの加入者に関連付けられたユーザ・プロファイルを更新するステップと、
前記ユーザ・プロファイルの更新に応答して、前記所定の数のサービン
グ・ネットワーク・ノードの少なくとも一部についてメモリに格納された1以上のユーザ・プロファイルを削除するステップと、
を含む、方法。
【請求項14】
請求項13記載の方法において、更に、
ユーザ・プロファイル更新メッセージを、前記通信ネットワークのサービスへの加入者に関連付けられたユーザ・プロファイルを含む加入者データ
ベースに送るステップと、
前記加入者データベース内の前記ユーザ・プロファイルを更新するステップと、
前記加入者データベースが、前記所定の数のサービング・ネットワーク・ノードの少なくとも一部に関連付けられた位置情報を要求するステップと、
ユーザ・プロファイル・リフレッシュ・メッセージを前記サービング・
ネットワーク・ノードに送信するステップと、
前記ユーザ・プロファイルがメモリに格納されている場合に、前記ユー
ザ・プロファイル入力を前記メモリから削除するステップと、
を含む、方法。
【請求項15】
請求項1?14のいずれか一項に記載の方法において、前記サービス要求がSBC、P-CSCF、IBCF、S-CSCF、またはI-CSCFによって受信される、方法。
【請求項16】
請求項4、6、7、8または11に記載の方法において、前記位置データベースが加入者データベースと同一場所に位置し、または、前記位置データベースが別のネットワーク・ノードに位置する、方法。
【請求項17】
通信ネットワークにおいてサービング・ネットワーク・ノードを動的に割り当てるように構成されるネットワーク・ノードであって、当該ネットワーク・ノードが、
ユーザ機器、別のネットワークまたはネットワーク・ノードに関連付けられるサービス要求を受信する手段であって、前記サービス要求が登録または再登録要求ではない、手段と、
所定の数のサービング・ネットワーク・ノードの少なくとも一部に関連付けられる負荷情報を受信する手段と、
前記受信する手段がサービス要求を受信したときに、前記所定の数のサービング・ネットワーク・ノードの内1つを前記ユーザ機器、前記別のネットワーク、または前記ネットワーク・ノードに割り当てる手段であって、該割当が前記負荷情報に基づく手段と、
を備える、ネットワーク・ノード。
【請求項18】
請求項17に記載のネットワーク・ノードであって、更に、
ユーザ機器、別のネットワーク、または前記所定の数のサービング・ネットワーク・ノードの内少なくとも1つに割り当てられるネットワーク・ノードを識別する割当情報を送る手段を備える、ネットワーク・ノード。
【請求項19】
請求項17または18に記載のネットワーク・ノードであって、更に、
ユーザ・プロファイル・リフレッシュ・メッセージを受信する手段と、
メモリが前記ユーザ・プロファイル・リフレッシュ・メッセージにおいて識別される前記ユーザ・プロファイルを含む場合に、前記ネットワーク・
ノードのメモリからユーザ・プロファイル入力を削除する手段と、
を備える、ネットワーク・ノード。
【請求項20】
請求項17?19のいずれか一項に記載のネットワーク・ノードと共に用いるための位置サーバであって、当該位置サーバが、前記所定の数のサービング・ネットワーク・ノードに関連付けられた位置情報と、ユーザ機器、他のネットワーク、または前記所定の数のサービング・ネットワーク・ノードの内少なくとも1つに割り当てられるネットワーク・ノードを識別する識別情報と、前記通信ネットワークに登録されたユーザ機器に割り当てられるアクセス・ネットワーク・ノードに関連付けられた位置情報とを含む位置データベースを備え、当該位置サーバが、
ユーザ機器、他のネットワーク、または前記所定の数のサービング・ネットワーク・ノードに内少なくとも1つに割り当てられたネットワーク・ノードを識別する割当情報を受信および送信するための手段と、
前記所定の数のサービング・ネットワーク・ノードに関連付けられ、および/または前記通信ネットワークに登録されたユーザ機器に割り当てられた前記アクセス・ネットワーク・ノードに関連付けられた位置情報を受信および送信する手段と、
を備える、位置サーバ。
【請求項21】
通信システムであって、サービング・ネットワーク・ノードを少なくとも1つのユーザ機器、他のネットワーク、またはネットワーク・ノードに動的に割り当てるように構成され、当該通信ネットワークが、請求項17?19のいずれか一項に記載の少なくとも1つのネットワーク・ノードと、請求項20に記載の位置サーバとを備える、通信システム。
【請求項22】
コンピュータによってランされる時に、請求項1?16のいずれか一項に記載の方法を実行するように構成されるソフトウェア・コード部を備える、コンピュータ・プログラム。」

第3.当審の拒絶理由の概要
平成28年6月8日付けで通知した当審の拒絶理由は、特許請求の範囲の請求項1、17、20及び23の記載が不備のため、特許法第36条第6項第2号に規定する要件を満たしていないという理由1、及び請求項1、1
7、及びそれら引用する他の請求項と、請求項20とは、単一の一般的発明概念を形成するように連関している技術的関係にないので、特許法第37条に規定する要件を満たしていないという理由2である。
上記「第2.特許請求の範囲の記載」に記載したように、本願の特許請求の範囲の記載は、補正によって明確なものとなり、理由1は解消した。
また、補正前の請求項20は削除されたので、理由2も解消した。
よって、当審の拒絶理由は解消した。

第4.原査定の理由の概要
原査定の理由の概要は、本願の請求項1-23に係る発明は、その出願前に外国において、頒布された欧州特許出願公開第1973295号明細書
(以下、「引用例」という。)に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができないというものである。

第5.当審の判断
1.引用発明
原査定の拒絶の理由に引用された引用例には、図面とともに以下の記載がなされている。

(1)「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.」

(2)「[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.」

(3)「[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.」

(4)「(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.」

引用例のパテントファミリである特開2008-236183号公報の対応する記載は以下のとおりである。

(1’)「【特許請求の範囲】
【請求項1】
IMS(IP Multimedia Subsystem)アークテキチャを実現するIP網に
おいて、ユーザ端末の登録時に、複数の呼セッション制御サーバ(S-CS
CFサーバ)の中から、当該ユーザ端末を登録し、当該ユーザ端末に関する呼セッション制御を司る呼セッション制御サーバを割り当てる呼セッション制御サーバ割り当て方法であって、各ユーザ端末ごとのユーザ情報を記憶するホーム加入者サーバ(HSSサーバ)に、呼セッション制御サーバそれぞれの現在の稼働状況に応じてユーザ端末を割り当てる際の優先順位を示す優先情報を呼セッション制御サーバごとに対応付けて記憶する呼セッション制御サーバ選択テーブルを備え、ユーザ端末の登録時に当該ユーザ端末を登録する呼セッション制御サーバを決定する問い合わせセッション制御サーバ
(I-CSCFサーバ)から、前記ホーム加入者サーバに対して問い合わせがあった際に、前記ホーム加入者サーバは、前記呼セッション制御サーバ選択テーブルを参照して、各呼セッション制御サーバの現在の稼働状況に応じて、割り当てるべき呼セッション制御サーバを選択して、問い合わせ元の前記問い合わせセッション制御サーバに返送することを特徴とする呼セッション制御サーバ割り当て方法。」

(2’)「【0036】
以上のようなネットワーク構成を有するIMSアークテクチャにおいて
は、各ユーザ端末UEのSIPプロトコルを用いた発着信動作に先立って、各ユーザ端末UEのホーム網に配置されている複数のS-CSCFサーバ
(呼セッション制御サーバ)のうち、各ユーザ端末UEの呼セッション制御を司るS-CSCFサーバを決定する手続き(つまり、REGISTER
メッセージによる登録要求)をユーザ端末UEが実施しておくことが必要である。
【0037】
このとき、従来の技術では、ユーザ端末UEからREGISTERメッ
セージによる登録要求を受け取ったP-CSCFサーバは、I-CSCF
サーバに対して問い合わせを行い、問い合わせを受け取ったI-CSCF
サーバが、HSSサーバからホーム網に属するすべてのS-CSCFサーバの一覧を転送させ、あらかじめ定めた一定の順序で、順番に、登録要求を送信してきたユーザ端末UEの登録を担当するすなわちユーザ端末UEの呼
セッション制御を司るS-CSCFサーバを決定していた。
【0038】
しかしながら、ユーザ端末UEの登録要求のみならず、登録抹消などによりユーザ端末UEの登録状況がS-CSCFサーバごとに動的に変動を伴っているので、従来の技術のように、一定の順序で順番にS-CSCFサーバを割り付けていく方法では、各S-CSCFサーバ間で、登録するユーザ端末UEの個数を均等に配分することができず、特定のS-CSCFサーバに負荷が集中してしまうという問題が避けられない。
【0039】
本発明は、かかる問題を解決するためになされたものであり、各S-CSCFサーバ(呼セッション制御サーバ)におけるユーザ端末UEの登録状況や各S-CSCFサーバの負荷発生状況を勘案して、各S-CSCFサーバへのユーザ端末UEの登録先を割り当てることにより、各S-CSCFサーバの負荷の均等化を可能とする呼セッション制御サーバ割り当て方法および呼セッション制御サーバ割り当てシステムを提供することを、その目的としている。」

(3’)「【0065】
図3に示すように、図2のシーケンスSQ4において、I-CSCFサーバ30が、HSSサーバ40より、ユーザ端末UE201の通信に利用するS-CSCFサーバ20,21,22,…の候補を、一覧の形で、DiameterプロトコルのUAA(User Authorization Answer)により受け取っ
た際に、UAAには、S-CSCF情報として、S-CSCFサーバ20,21,22,…ごとの現在の登録加入者数(登録ユーザ端末UE数)が含まれている形で受信するように構成されている。
【0066】
つまり、I-CSCFサーバ30からの問い合わせを受け取るHSSサーバ40には、S-CSCF選択用のS-CSCF選択テーブル41が備えられており、S-CSCF選択テーブル41には、登録S-CSCFサーバとしての割り当てが可能な各S-CSCFサーバ20,21,22,…ごとの現在の登録加入者数(登録ユーザ端末UE数)を登録記憶している。HSSサーバ40は、I-CSCFサーバ30からの問い合わせを受け取った際
に、S-CSCF選択テーブル41を参照して、S-CSCFサーバ20,21,22,…ごとの現在の登録加入者数(登録ユーザ端末UE数)を含む形式でS-CSCF情報を編集してUAAとしてI-CSCFサーバ30に返送する。
【0067】
HSSサーバ40から現在の登録加入者数(登録ユーザ端末UE数)を含むS-CSCF一覧情報を受信したI-CSCFサーバ30は、S-CSCFサーバ20,21,22,…の中から、現在の登録加入者数(登録ユーザ端末UE数)が最も少ないS-CSCF(図3の例では、S-CSCF#2と表示されているS-CSCFサーバ21)を、REGISTERメッセージを送信してきたユーザ端末UE201の呼セッション制御を司るS-CSCFとして割り付ける。しかる後、I-CSCF30は、新たに割り当てたS-CSCFサーバに関する情報をHSSサーバ40に通知するとともに、図2のシーケンスSQ5に示すように、割り付けたS-CSCFサーバ(図3の例ではS-CSCFサーバ21)に対して、当該ユーザ端末UE201の登録を行わせるために、S-CSCFサーバに対して、受信していたREGISTERメッセージを送信する。
【0068】
I-CSCFサーバ30において、以上のようなS-CSCFサーバ選択処理をHSSサーバ40と連携して行うことにより、各S-CSCFサーバ20,21,22,…に登録する加入者数(ユーザ端末UE数)を均等化することができ、負荷の平滑化を図ることが可能となる。」

(4’)「【0078】
(その他の実施例)
図6は、本発明による呼セッション制御サーバ(S-CSCFサーバ)の割り当て方法の図3とは異なる例を説明するための概念図であり、HSS
サーバ40に備えられるS-CSCFサーバ選択用のS-CSCF選択テーブル41Aへの登録内容が、図3のS-CSCF選択テーブル41の場合とは異なっている。つまり、図6に示すS-CSCF選択テーブル41Aは、各S-CSCFサーバ20,21,22,…の現在の稼働状況に応じた情報を、S-CSCFサーバ選択時の優先順位を示す優先情報として用い、図3のS-CSCF選択テーブル41の場合の登録加入者数(登録ユーザ端末UE数)の代わりに、パラメータ1、パラメータ2、…として登録されている例を示している。
【0079】
ここで、S-CSCF選択テーブル41Aに登録するS-CSCFサーバ選択用の優先情報としては、例えば、各S-CSCFサーバ20,21,22,…の現在の単位時間当たりの呼量や同時接続数やメッセージ送受信数などの呼セッションに関する情報を、登録加入者数(ユーザ端末UE数)の代わりに用いても良いし、あるいは、各S-CSCFサーバ20,21,2
2,…の現在の単位時間当たりの処理プロセッサ(CPU)の使用率やメモリ使用率や保守用のメッセージも含む単位時間当たりの総メッセージ送受信数や総送受信メッセージサイズなどの総合的な負荷に関する情報を用いても良い。かくのごとき総合的な負荷に関する情報をS-CSCFサーバ選択用の優先情報として用いることにより、例えば、あるS-CSCFサーバの現在の状態が、呼セッションによる負荷が少なくても、バックアップ処理や輻輳・障害からの回復処理などの保守用の処理が実施されていて、トータルとしてかなりの負荷状態になっている場合には、ユーザ端末UEの割り当て優先順位を、適切な順位まで下げるように設定することができる。」

したがって、引用例には、次の発明(以下、「引用発明」という。)が記載されているといえる。

IMS(IP Multimedia Subsystem)アークテキチャを実現するIP網に
おいて、ユーザ端末の登録時に、複数の呼セッション制御サーバ(S-CS
CFサーバ)の中から、当該ユーザ端末を登録し、当該ユーザ端末に関する呼セッション制御を司る呼セッション制御サーバを割り当てる呼セッション制御サーバ割り当て方法であって、各ユーザ端末ごとのユーザ情報を記憶するホーム加入者サーバ(HSSサーバ)に、呼セッション制御サーバそれぞれの現在の稼働状況に応じてユーザ端末を割り当てる際の優先順位を示す優先情報を呼セッション制御サーバごとに対応付けて記憶する呼セッション制御サーバ選択テーブルを備え、ユーザ端末の登録時に当該ユーザ端末を登録する呼セッション制御サーバを決定する問い合わせセッション制御サーバ
(I-CSCFサーバ)から、前記ホーム加入者サーバに対して問い合わせがあった際に、前記ホーム加入者サーバは、前記呼セッション制御サーバ選択テーブルを参照して、各呼セッション制御サーバの現在の稼働状況に応じて、割り当てるべき呼セッション制御サーバを選択して、問い合わせ元の前記問い合わせセッション制御サーバに返送する呼セッション制御サーバ割り当て方法であって、
前記優先情報は、各呼セッション制御サーバ(S-CSCFサーバ)の現在の単位時間当たりの処理プロセッサ(CPU)の使用率やメモリ使用率や保守用のメッセージも含む単位時間当たりの総メッセージ送受信数や総送受信メッセージサイズなどの総合的な負荷に関する情報であることを特徴とする呼セッション制御サーバ割り当て方法。

2.対比
本願の請求項1-22に係る発明は、本願の特許請求の範囲の各請求項に記載された事項により特定されるとおりのものであり、その記載は前記「第2.特許請求の範囲の記載」のとおりである。
本願の請求項1に係る発明(以下、「本願発明」という。)と引用発明とを対比する。
引用発明の「呼セッション制御サーバ(S-CSCFサーバ)」は、サービング・ネットワーク・ノードといえ、引用発明は「IMS(IP Multimedia Subsystem)アークテキチャを実現するIP網において、ユーザ端末の登
録時に、複数の呼セッション制御サーバ(S-CSCFサーバ)の中から、
当該ユーザ端末を登録し、当該ユーザ端末に関する呼セッション制御を司る呼セッション制御サーバを割り当てる呼セッション制御サーバ割り当て方
法」であるから、本願発明とは、所定の数のサービング・ネットワーク・
ノードを備える通信ネットワークにおいてサービング・ネットワーク・ノードを割り当てるための方法である点で共通する。
引用発明は「ユーザ端末の登録時」に呼セッション制御サーバを割り当てるものであり、そのような登録が「ユーザ端末」の要求によるものであること、及び「IP網」のネットワーク・ノードといえる、いずれかの制御サーバがそのような要求を受信することは明らかであるので、本願発明とは、通信ネットワーク内のネットワーク・ノードにおいて、ユーザ機器に関連付けられた要求を受信するステップを含む点で共通する。
引用発明の「優先情報」は、「各呼セッション制御サーバ(S-CSCFサーバ)の現在の単位時間当たりの処理プロセッサ(CPU)の使用率やメモリ使用率や保守用のメッセージも含む単位時間当たりの総メッセージ送受信数や総送受信メッセージサイズなどの総合的な負荷に関する情報」であるから、サービング・ネットワーク・ノードに関連付けられた負荷情報とい
え、「各ユーザ端末ごとのユーザ情報を記憶するホーム加入者サーバ(HSSサーバ)に、呼セッション制御サーバそれぞれの現在の稼働状況に応じてユーザ端末を割り当てる際の優先順位を示す優先情報を呼セッション制御
サーバごとに対応付けて記憶する呼セッション制御サーバ選択テーブルを備え」とするものであるから、「優先情報」である負荷情報が、ネットワー
ク・ノードといえるホーム加入者サーバ(HSSサーバ)に提供され、本願発明とは、サービング・ネットワーク・ノードに関連付けられた負荷情報
を、少なくとも1つのネットワーク・ノードに提供するステップを含む点で共通する。
引用発明は「ユーザ端末の登録時に当該ユーザ端末を登録する呼セッション制御サーバを決定する問い合わせセッション制御サーバ(I-CSCF
サーバ)から、前記ホーム加入者サーバに対して問い合わせがあった際に、前記ホーム加入者サーバは、前記呼セッション制御サーバ選択テーブルを参照して、各呼セッション制御サーバの現在の稼働状況に応じて、割り当てるべき呼セッション制御サーバを選択して、問い合わせ元の前記問い合わせ
セッション制御サーバに返送する」ものであり、上記のとおり「優先情報」は負荷情報といえるので、本願発明とは、要求の受信に応答して、所定の数のサービング・ネットワーク・ノードの内1つを、負荷情報に基づいてユーザ機器に割り当てるステップを含む点で共通する。
したがって、本願発明と引用発明とを対比すると、以下の点で一致し、また相違する。

(1)一致点
所定の数のサービング・ネットワーク・ノードを備える通信ネットワークにおいてサービング・ネットワーク・ノードを割り当てるための方法であって、当該方法が、
前記通信ネットワーク内のネットワーク・ノードにおいて、ユーザ機器、他のネットワーク、またはネットワーク・ノードに関連付けられた要求を受信するステップと、
前記サービング・ネットワーク・ノードに関連付けられた負荷情報を、少なくとも1つの前記ネットワーク・ノードに提供するステップと、
前記要求の受信に応答して、前記所定の数のサービング・ネットワーク・ノードの内1つを、前記負荷情報に基づいて前記ユーザ機器、前記他のネットワーク、または前記ネットワーク・ノードに割り当てるステップと、
を含む、方法。

(2)相違点
本願発明は要求が「登録または再登録要求ではない」とする「サービス要求」であり、その受信に応答して、サービング・ネットワーク・ノードを動的に割り当てるのに対して、引用発明は要求がユーザ端末の登録に関するものであり、「サービス要求」の受信に応答して動的に割り当てることについての特定がない点。

3.判断
上記相違点について検討する。
前置報告書には「サービス要求」に関連して以下の記載がある。

「出願人は、この審判請求において、本願の請求項に係る発明が、「サービス要求が(再)登録要求ではない」ことにより「「ネットワーク・ノードに割り当て」られる「サービング・ネットワーク・ノード」は流動的に都度変更することができる」点で、引用文献1とは異なる旨、主張している。

しかしながら、下記で挙げる引用文献2(たとえば第7ページ第10行?第8ページ第25行参照)には、UEに対してS-CSCFが割り当てられた後、地理的な要因や負荷分散等を考慮して最適なS-CSCFが存在することを検出した場合、HSSにS-CSCFへ信号を送信させる再登録や
セッションの終了などのイベントをトリガとしてS-CSCFの再割り当てを行う技術が記載されている。すなわち、引用文献2には、(再)登録に限らず様々なサービス要求を受信した場合にS-CSCFの再割り当てを流動的に行う技術が記載されている。
また、引用文献3には、UEに対するS-CSCFの固定的な登録による弊害を回避し(たとえば[0004]段落参照)、障害時やIMSの構成変更時などに流動的にS-CSCFの変更を可能とする(たとえば[001
4]?[0015]段落参照)技術が記載されている。

引用文献1記載の方法においてS-CSCFサーバの割り付けを行う際
に、引用文献2または引用文献3に記載の前記技術を適用して、適宜サービス要求を受信することにより流動的にS-CSCFサーバの変更を可能とする構成とすることは、当業者が容易に想到し得たことと認められる。」

引用文献2として引用された国際公開第2010/105643号には、以下の記載がある。

「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.」

引用文献2のパテントファミリである特表2012-521115号公報の対応する記載は以下のとおりである。

「【0029】
図3は、S-CSCFを再度割り当てる手続きについての基本的なシグナリングフローを説明する。ネットワークエンティティおよびUE22は、図2に示されるものと同一の参照番号を伴う。最初に示されるように(ステップ301)、第1のS-CSCF20であるS-CSCF1がユーザ22に割り当てられる。当該S-CSCF1は、最適ではない(例えば、上記のように、ユーザ22は、元々割り当てられたS-CSCFがダウンした結果としてS-CSCF1 20に移動し得る)。代わりに、S-CSCF2 24は、(例えば、地理的な位置/ユーザ22への近接に起因して)使用するのに好適なプロキシである。上記のように、ユーザ22へのS-CSCF1 20の割当ては、ユーザ22がS-CSCF1 20と共に登録されるから、またはS-CSCF1 20がS-CSCF1 20が未登録サービスの提供のためにユーザに指定されたからのいずれかであってもよい。
【0030】
ある時点で、割当てを変更することが決定され、それにより、最適なS-CSCFとしてみなされるS-CSCF2 24がユーザ22に割り当てられる。図3で説明される例では、ステップ302で、ユーザのHSS26
は、再割当てについての指示を出す。当該指示は、Cxインターフェースを通じてS-CSCF1 20に送信される。変更することの決定は、HSS26自体により行われる必要はないが、IMSネットワークの中の別のどこかで発生してもよい、ということに留意する。例えば、負荷分散機能が用いられてもよい。当該負荷分散機能が、各S-CSCFにおける負荷を監視
し、不均衡が検出される場合に、負荷を再分散させるようにプログラムされる。この種類の機能の一例は、3GPPのTR23.812で説明される。別の可能性は、割り当てられたユーザが別のS-CSCFに移動すべきであると判定することを可能にするローカルロジックがS-CSCFの中で用いられてもよいということである。
【0031】
ステップ302での再割当ての指示は、割当て解除(すなわち、S-CSCF1 20からのユーザ22の登録取消し、またはユーザ22からのS-CSCF1 20の指定取消し)をトリガ(trigger)する。しかしなが
ら、上記指示は、割当て解除が実行される前に満たされなければならない基準を含む。単純な形式では、指示および基準は、アクティブなセッションがない場合の登録取消し(DE-REGISTER-IF-NO-ACTIVE-SESSIONS)を開始する
新たな値を伴う管理登録解除(Administrative Deregistration)要求であることも可能である。より進化した基準は、存在し得る異なる種類のセッ
ションおよび/または対話を考慮することを含むことが可能である。例え
ば、上記基準は、SIP INVITEセッションが存在しない場合にの
み、またはサービスMMTELのSIP INVITEセッションが存在しない場合にのみ、S-CSCFがユーザの登録を取り消すべきであることを示してもよい。
【0032】
図3に示される実施形態では、再割当ての指示および基準は、ステップ302でS-CSCF1 20に共に送信される。しかしながら、例えば、S-CSCF1 20が最適でないという判定は初期段階で行われることができるが、ユーザからのS-CSCF1 20の割当て解除についての基準は他の要素(信号トラフィックの量、または他のS-CSCFの可用性、等)に依存できる、ということが可能である。その場合に、HSS26は、S-CSCF1 20に割当て解除の基準を送信する前のしばらく後まで、待機することができる。別の可能性は、HSS26にS-CSCF1 20へ信号を送信させる別のイベント(再登録またはユーザによるセッションの終
了、等)が発生するまでHSS26は待機することができ、HSS26はその段階でS-CSCF1 20に基準を送信する、とういことである。代わりに、命令が予約されることが可能であり、それにより、割当て解除の基準がまずS-CSCF1 20に送信され、例えば別のイベントが発生する場合に実際の再割当ての指示がその後送信される。」

引用文献3として引用された特開2010-263597号公報には、以下の記載がある。

「【背景技術】
【0002】
従来から知られているSIP(Session Initiation Protocol)は、IP
上における呼制御に用いられるプロトコルであり、通信を行なう端末間で通信に必要なIPアドレスやポート番号、エンコーディング等のネゴシエー
ション、発呼、着呼などの制御を行なう際に用いられる。これに加え、IMS(IP Multimedia Subsystem)では、このSIPの情報に基づいて、通信
に必要なネットワークリソースの割り当て、ゲート制御を行なう。
【0003】
IMSでは、SIP処理を行なうノードとして、複数のCSCF(Call Session Control Function)を定めている。そのうち、P-CSCF(Proxy CSCF)は、端末から直接接続されるノードであり、暗号化やメッセージの
フィルタリング等を行なう。また、I-CSCF(Interrogating CSCF)
は、SIPのルーティングを行なう際、転送先の解決や、他ドメインへ転送するときの処理を行なう。S-CSCF(Serving CSCF)は、端末の登録やアプリケーションサーバとの連携、相手の解決などSIPの主要な機能を備える。
【0004】
これらのノードが、一度端末を登録し、サービスを開始すると、その後に端末の処理を行なうノードが変更されることはない。そのため、障害等で
ノードでの処理継続が困難となった場合、IMSが、その異常を検知して他のノードへ処理を割り当て直し、その後、端末が、その異常を検知して再度登録を行なうまで、サービスが遮断されてしまう。例えば、待ち受け状態の端末へ通信できなくなるなど、サービスへの影響は大きい。これらに対し現在では、ホットスタンバイなどを導入し、ノード自体に堅牢性を与えてい
る。」

「【0014】
(4)また、本発明のノード変更方法は、SIP(Session Initiation Protocol)処理を行なう少なくとも一つのP-CSCF(Proxy Call Session Control Function)および複数のS-CSCF(Serving Call Session Control Function)を含むIMS(IP Multimedia Subsystem)ネットワークにおけるノード変更方法であって、前記P-CSCFにおいて、前記S-CSCFに登録しているIMS端末の情報を保持するステップと、いずれかの前記S-CSCFの異常が検知されたときに出力されるノード変更指示を受信するステップと、前記保持されているIMS端末の情報に基づいて、前記異常が検知されたS-CSCFに登録しているIMS端末に対して、再登録通知メッセージを出力するステップと、前記IMS端末において、前記再登録通知メッセージに基づいて、前記異常が検知されたS-CSCF以外のS-CSCFに再登録を行なうステップと、を少なくとも含むことを特徴としている。
【0015】
このように、異常が検知されたS-CSCFに登録しているIMS端末に対して、再登録通知メッセージを出力し、IMS端末は、再登録通知メッ
セージに基づいて、異常が検知されたS-CSCF以外のS-CSCFに再登録を行なうので、IMSノード(S-CSCF)に障害が発生した場合であっても、迅速にIMS端末へ通知して、サービスを再開することができ
る。また、障害時以外でも、メンテナンスやIMSの構成変更を、サービスを中断することなく、すなわち、サービスを継続しながら行なうことができる。さらに、高度な対障害性をもたない汎用PCを用いて、可用性の高いIMSを構築することができる。さらに、IMS端末へ通知する際に、既存のSUBSCRIBEセッションを用いることで、既存システムへのインパクトを小さくできる。」

上記引用文献2及び3には、サービング・ネットワーク・ノードであるS-CSCFの割当てに関する記載があるが、「サービス要求」の受信に応答して動的に割り当てることについては、記載も示唆もない。
上記引用文献2及び3を考慮しても、ユーザ端末の登録に関する要求に替えて「サービス要求」の受信に応答してサービング・ネットワーク・ノードを動的に割り当てることに、困難な点はないということはできないので、本願発明は、引用発明に基づいて当業者が容易に発明をすることができたものとすることはできない。
請求項2-22に係る発明についても同様である。

第5 むすび
以上のとおり、本願の請求項1-22に係る発明は、引用発明に基いて、当業者が容易に発明をすることができたものとすることができないから、原査定の理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2016-10-14 
出願番号 特願2013-541281(P2013-541281)
審決分類 P 1 8・ 537- WY (H04W)
P 1 8・ 121- WY (H04W)
最終処分 成立  
前審関与審査官 倉本 敦史  
特許庁審判長 近藤 聡
特許庁審判官 吉田 隆之
加藤 恵一
発明の名称 サービング・ネットワーク・ノードの動的な割り当て  
代理人 竹内 茂雄  
代理人 末松 亮太  
代理人 小野 新次郎  
代理人 小林 泰  
代理人 山本 修  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ