• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1321957
審判番号 不服2015-19692  
総通号数 205 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-01-27 
種別 拒絶査定不服の審決 
審判請求日 2015-11-02 
確定日 2016-11-24 
事件の表示 特願2014-540302「認証情報を転送するための方法、中継装置、およびサーバ」拒絶査定不服審判事件〔平成25年 5月16日国際公開、WO2013/067884、平成26年12月 8日国内公表、特表2014-533054〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本件出願は,2012年10月22日(パリ条約による優先権主張外国庁受理2011年11月8日,中華人民共和国)を国際出願日とする出願であって,平成27年4月10日付け拒絶理由通知に対して同年6月4日に意見書及び手続補正書が提出されたが同年7月3日付けで拒絶査定がなされ,これを不服として同年11月2日に審判請求がなされるとともに手続補正書が提出されたものである。

第2 補正却下の決定
[補正却下の決定の結論]
平成27年11月2日に提出された手続補正書による手続補正(以下,「本件補正」という。)を却下する。

[理由]
1 本願発明と補正後の発明
本件補正は,平成27年6月4日に提出された手続補正書の特許請求の範囲の請求項1に記載された
「 IPｖ6向け動的ホスト構成プロトコル(DHCPｖ6)中継装置によって,AAAサーバにより配信された認証情報を受信するステップであって,前記認証情報は,プレフィックス・プール名,アドレス・プール名,指定IPｖ6プレフィックス,または指定IPｖ6アドレスを含む,受信するステップと,
DHCPｖ6中継装置によって, オプションをDHCPｖ6中継転送メッセージに挿入し,前記認証情報を前記オプションにカプセル化し,前記オプションをDHCPｖ6サーバに送信するステップと,
を含む,認証情報転送方法。」
という発明(以下,「本願発明」という。)を,補正後の特許請求の範囲の請求項1に記載された
「IPｖ6向け動的ホスト構成プロトコル(DHCPｖ6)中継装置によって,認証認可アカウンティング(AAA)サーバにより配信された認証情報を受信するステップであって,前記認証情報は,プレフィックス・プール名,アドレス・プール名,指定IPｖ6プレフィックス,または指定IPｖ6アドレスを含む,受信するステップと,
DHCPｖ6中継装置によって, オプションをDHCPｖ6中継転送メッセージに挿入し,前記認証情報を前記オプションにカプセル化し,DHCPｖ6クライアントからの要請メッセージと前記オプションとの両方を含むDHCPｖ6中継転送メッセージをDHCPｖ6サーバに送信するステップと,
を含む,認証情報転送方法。」
という発明(以下,「補正後の発明」という。)に変更することを含むものである。

2 新規事項の有無,シフト補正の有無,補正の目的要件について
本件補正は,願書に最初に添付した明細書,特許請求の範囲若しくは図面に記載した事項の範囲内において,補正前の特許請求の範囲の請求項1に記載された「中継転送メッセージ」についてが「DHCPｖ6クライアントからの要請メッセージと前記オプションとの両方を含む」点を付加してこれを限定することにより特許請求の範囲を限定的に減縮するものであって,特許法第17条の2第3項(新規事項)及び特許法第17条の2第5項第2号(補正の目的)の規定に適合している。
また,特許法第17条の2第4項(シフト補正)に違反するものでもない。

3 独立特許要件について
上記補正は特許請求の範囲の限定的減縮を目的とするものであるから,上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。

(1)補正後の発明
上記「1 本願発明と補正後の発明」の項で「補正後の発明」として認定したとおりである。

(2)引用発明
原査定の拒絶の理由に引用された米国特許第7502929号明細書(以下,「引用例」という。)には,「Method and apparatus for assigning network addresses based on connection authentication(当審仮訳:接続認証に基づくネットワークアドレス割当てのための方法及び装置)」(発明の名称)に関し,以下の事項が記載されている。

ア 「 1.2 DHCP
The Dynamic Host Configuration Protocol (DHCP) is an open standard protocol for dynamic host configuration described in RFC 2131 and RFC 2132, which are available at the time of this writing as documents rfc2131.html and rfc2132.html, respectively, on the World Wide Web (www) at domain and directory ietf.org/rfc. A DHCP server process operates on a DHCP server host that is conveniently located for several hosts on one or more local networks. One or more DHCP server hosts and processes are set up by a system administrator with information to configure the hosts on one or more local networks to reflect the current architecture of those local networks. A DHCP client process operates on each host of the local networks.
When a host begins operations on the local network, the DHCP client on that host requests configuration information from one of the DHCP servers. In response to the request from the DHCP client, one or more of the DHCP servers respond with configuration information to be used by the host of the DHCP client for a pre-determined period of time ("lease time"), including an IP address for the host of the DHCP client. Such responses take the form of "offers" of leases of addresses. The DHCP client notifies the servers that one of the offers is accepted. The host that is executing the DHCP client then uses the configuration information including the address. The configuration information is bound to the particular DHCP client, and the DHCP server that offered the lease records the binding.
(当審仮訳:
1.2 DHCP
ダイナミックホストコンフィギュレーションプロトコル(DHCP)は,本件執筆時点でワールドワイドウェブ(www)上のietf.org/rfcというドメイン及びディレクトリでそれぞれ文書rfc2131.htmlとrfc2132.htmlとして入手可能なRFC2131とRFC2132に記載されたダイナミックホストコンフィギュレーションの公開標準プロトコルである。DHCPサーバプロセスは,1またはそれ以上のローカルネットワーク上の複数のホストにとって便利な位置にあるDHCPサーバホスト上で動作する。1またはそれ以上のDHCPサーバホストとプロセスは,1またはそれ以上のローカルネットワークの現在のアーキテクチャを反映させるように,これらのネットワーク上のホストを設定するための情報を有したシステム管理者によってセットアップされる。DHCPクライアントプロセスは,そのローカルネットワークの各ホスト上で動作する。
ホストがローカルネットワーク上で動作を開始するとき,そのホスト上のDHCPクライアントは,DHCPサーバの1つに対して設定情報を要求する。DHCPクライアントからの要求に対する応答として,1またはそれ以上のDHCPサーバは,そのDHCPクライアントのホストのためのIPアドレスを含み,そのDHCPクライアントのホストによって既定の期間(「リース時間」)だけ使用される設定情報を返す。そのような応答は,アドレスのリースの「オファー」の形式をとる。そのDHCPクライアントは,オファーの1つが受け入れられたことをそれらのサーバに通知する。その後,そのDHCPクライアントを実行中のホストは,そのアドレスを含んだ設定情報を使用する。その設定情報は特定のDHCPクライアントに結びつけられ,リースをオファーしたDHCPサーバはその結びつきを記録する。)」(第6欄)

イ 「 2.0 Structural Overview
FIG. 1 is a block diagram that illustrates an overview of a system for authorizing a physical connection and assigning logical network addresses.
In the example of FIG. 1 , system 100 includes a switch 102 that is communicatively coupled to a local network 106 . A host 122 connects to the local network 106 through switch 102 . The system 100 also includes a RADIUS server host 132 , a DHCP server host 112 and a gateway host 142 . The gateway host 142 is connected to Internet 150 , or to any other public network or internetwork.
The switch 102 includes physical ports 104 a, 104 b, 104 c, 104 d, collectively referenced as physical ports 104 . The switch 102 employs the IEEE 802.1x standard for physical-port-based access control. An authenticator 105 executes on a processor of the switch 102 to apply the IEEE 802.1x standard. Authenticator 105 stores authentication and authorization data in a persistent store 108 on the switch 102 , as described in more detail below. The authentication and authorization data contains information obtained from the RADIUS server host 132 . IEEE 802.1x does not require or suggest storage of the authentication and authorization data from a RADIUS server host 132 at the switch 102 , as described in more detail below.
In addition, in the example of FIG. 1 , a DHCP relay agent 103 also executes on the processor of switch 102 . DHCP relay agent 103 communicates using DHCP messages with the DHCP client 123 on host 122 and a DHCP server on the DHCP server host 112 . DHCP relay agent 103 uses the authentication and authorization data in the persistent store 108 on the switch, as described in more detail below. DHCP does not require or suggest using the authentication and authorization data from a RADIUS server host by a DHCP relay agent 103 .
The host 122 employs the IEEE 802.1x standard for physical-port-based access control and DHCP for network configuration including IP address assignment. The host is connected to physical port 104 b of switch 102 through connection 121 . The connection 121 may be by cable or by a wireless signal, such as an electromagnetic or acoustic signal. A supplicant 125 executes on a processor of the host 122 to apply the IEEE 802.1x standard. The supplicant obtains information from a user of the host, such as the user identification and password, and sends that information to the authenticator 105 through physical port 104 b using connection 121 . A DHCP client 123 executes on the processor of the host 122 to obtain an IP address, among other configuration information, from a DHCP server.
The RADIUS server host 132 includes a processor that executes a RADIUS server 135 . The RADIUS server provides authentication, authorization and accounting (AAA) services. Authentication services determine that a user is who the user claims to be, such as by verifying a password and user identification combination. Authorization services indicate that the authenticated user has certain privileges to perform operations on the network. For example, an authorization service determines that an authenticated user is allowed to establish a physical connection to the local network but is not allowed to access the Internet. Accounting services determine that the user's use of authorized operations is tracked, for example to support QoS agreements and to enforce usage limits. The RADIUS server maintains one or more data structures of user profile data 136 that includes the user identification, password, and privileges. The RADIUS server 135 receives a request from the authenticator 105 to authenticate the user of host 122 . The RADIUS server sends a response indicating whether authentication succeeds or fails. In some embodiments, when the authentication succeeds, the RADIUS server also sends authorization information.
According to one embodiment, a user class is associated with each user in the user profile data 136 . Multiple users of the local network who have substantially the same authorizations for LAN resources and accounts, as enforced by one or more services on the LAN based on the users' IP addresses, are placed in the same user class. In this embodiment, the user class is included in authorization information sent by the RADIUS server to the authenticator 105 .
The DHCP server host 112 includes a processor on which executes a process called the DHCP server 113 . The DHCP server 113 applies DHCP for exchanging messages with DHCP clients and DHCP relay agents in order to provide IP addresses and other configuration information to hosts that become connected to the local network 106 .
According to the illustrated embodiment, the DHCP server 113 assigns IP addresses from several pools of IP addresses, including a first pool 114 of IP addresses and a second pool 116 of IP addresses, that are stored on the DHCP server host 112 in one or more data structures. In addition, the DHCP server stores a data structure herein called a map 118 that associates each pool of IP addresses with a user class. DHCP does not require that the DHCP server 113 store and use a map 118 associating a user class with a pool of IP addresses. In addition, the DHCP server 113 obtains the user class, for a user of a host being configured, from the DHCP relay agent 103 . The user class is based on information among the authentication and authorization data in the persistent store 108 on the switch 102 . DHCP does not require or suggest that the DHCP server 113 obtain a user class from a DHCP relay agent.
(当審仮訳:
2.0 構成の概要
図1は,物理的接続と論理ネットワークアドレス付与を認可するためのシステムの概要を示すブロック図である。
図1の例において,システム100はローカルネットワーク106と通信可能に結合されたスイッチ102を含む。ホスト122はスイッチ102を介してローカルネットワーク106と接続する。システム100はRADIUSサーバホスト132,DHCPサーバホスト112,ゲートウェイホスト142も含む。ゲートウェイホスト142はインターネット150あるいは他の任意の公共ネットワークかインターネットワークに接続する。
スイッチ102はまとめて物理ポート104と称される物理ポート104a,104b,104c,104dを含む。スイッチ102は物理ポートベースのアクセス制御のためのIEEE802.1ｘ標準を採用する。認証部105はスイッチ102のプロセッサ上でIEEE802.1ｘ標準を適用するように働く。認証部105は以下に詳述するように,スイッチ102の永続的な貯蔵所108に認証認可データを蓄える。認証認可データはRADIUSサーバホスト132から得られた情報を含む。IEEE802.1ｘ標準は,以下により詳細に述べるように,スイッチ102におけるRADIUSサーバホスト132からの認証認可データの保存を要求もしくは示唆しない。
加えて,図1の例では,DHCP中継エージェント103もスイッチ102のプロセッサ上で働く。DHCP中継エージェント103は,DHCPメッセージを使ってホスト122上のDHCPクライアント123およびDHCPサーバホスト112上のDHCPサーバと通信する。DHCP中継エージェント103は,以下により詳細に述べるように,永続的な貯蔵所108の認証認可データ使用する。DHCPは,DHCP中継エージェント103によるRADIUSサーバからの認証認可データの使用を要求もしくは示唆しない。
ホスト122は,物理ポートベースのアクセス制御のためにIEEE802.1ｘ標準を採用し,IPアドレス付与を含むネットワーク設定のためにDHCPを採用する。ホストは接続121を介してスイッチ102の物理ポート104bに接続されている。接続121はケーブルもしくは電磁信号または音声信号のような無線信号によってであり得る。サプリカント125はホスト122のプロセッサ上でIEEE802.1ｘ標準を適用するように働く。サプリカントはホストのユーザからユーザIDやパスワードのような情報を得て,接続121を使って物理ポート104bを介して認証部105へその情報を送る。DHCPクライアント123は,DHCPサーバから他の設定情報とともにIPアドレスを取得するためにホスト122のプロセッサ上で働く。
RADIUSサーバホスト132はRADIUSサーバ135を実行するプロセッサを含む。RADIUSサーバは認証認可アカウンティング(AAA)サービスを提供する。認証サービスは,パスワードとユーザIDの組合せを確認することなどにより,ユーザがその主張のとおりのユーザであることを決定する。認可サービスは,認証されたユーザがネットワーク上で操作を実行する権利を有することを示す。例えば,認可サービスは,認証されたユーザがローカルネットワークへの物理的な接続は許可されているがインターネットへのアクセスは許可されていないことを決定する。アカウンティングサービスは,例えばQｏS契約をサポートし使用制限を実施するために,ユーザの認可された操作の使用が追跡されることを決定する。RADIUSサーバは,ユーザID,パスワード,権利を含むユーザプロファイルデータ136の1または複数のデータ構造を保持する。RADIUSサーバ135は,認証部105から,ホスト122のユーザを認証するよう要求を受ける。RADIUSサーバは認証が成功したか失敗したかを示す応答を送る。いくつかの実施例では,認証が成功したとき,RADIUSサーバは認可情報も送る。
1実施例では,ユーザプロファイルデータ136においてユーザクラスは各ユーザと関連付けられている。ユーザのIPアドレスに基づいてLAN上の1または複数サービスにより実施されるLAN資源と課金についての実質的に同じ認可を有するローカルネットワーク上の複数のユーザは,同じユーザクラスに配置される。この実施例において,ユーザクラスはRADIUSサーバから認証部105へ送られる認可情報に含まれる。
DHCPサーバホスト112はDHCPサーバ113と呼ばれるプロセスを実行するプロセッサを含む。DHCPサーバ113は,ローカルネットワーク106へ接続されたホストにIPアドレスや他の設定情報を提供するために,DHCPクライアントやDHCP中継エージェントとメッセージを交換するためのDHCPを適用する。
示された実施例では,DHCPサーバ113は,DHCPサーバホスト112上で1または複数のデータ構造として記憶されたIPアドレスの第1のプール114とIPアドレスの第2のプールを含むIPアドレスの複数のプールの中からIPアドレスを付与する。加えて,DHCPサーバはIPアドレスの各プールとユーザクラスを関連付けるマップ118とここで呼ばれるデータ構造記憶している。DHCPは,DHCPサーバ113がユーザクラスとIPアドレスのプールを関連付けるマップ118を記憶し使用することを要求していない。加えて,DHCPサーバ113は,設定されるホストのユーザのために,ユーザクラスをDHCP中継エージェント103から取得する。そのユーザクラスは,スイッチ102の永続的な貯蔵所108の認証認可データのなかの情報に基づいている。DHCPはDHCPサーバ113がDHCP中継エージェントからユーザクラスを取得することを要求あるいは示唆していない。)」(第6?8欄)

ウ 「 3.0 Functional Overview
FIG. 2 is a time line chart that illustrates a sequence of messages sent between some components of the system of FIG. 1 . In FIG. 2 , time increases from top to bottom. Blocks in the first column represent processes that execute on the host 122 . Blocks in the second column represent processes that execute on the switch 102 . Arrows indicate messages that are sent at a relative time given by the point of the arrow.
・・・(中略)・・・
If the user is authentic, and the authentic user is authorized to connect to the local network, then a response 232 is prepared that includes authentication data indicating that authentication succeeds and authorization data indicating any services the user is privileged to request. According to some embodiments, the authentication data includes credentials that identify the user and that assure a trusted RADIUS server is the source of the authentication and authorization. In the illustrated embodiment, the authorization data also indicates the user class associated in the user profile data 136 with an authentic user.
At time t 3 after t 2 , the response 232 , including the authentication and authorization data, is sent to the authenticator 105 on switch 102 .
・・・(中略)・・・
At time t 5 after t 4 , the DHCP client on the host 122 broadcasts a DHCP discovery message to request configuration information that includes an IP address for the host 122 . A conventional switch without a DHCP relay agent would receive and then also broadcast the same DHCP discovery message. Also, the first embodiments do not require a DHCP relay agent 103 be included on the switch 102 . However, according to the second set of embodiments, the switch includes the DHCP relay agent 103 .
A DHCP relay agent directs an IP data packet containing the DHCP discovery message to one or more DHCP servers using the IP address of each DHCP server host in the destination address of the data packet, and using the well-known port 67 in the destination logical port. In the illustrated embodiment, the DHCP relay agent 103 generates a UDP/IP data packet with the IP address of the DHCP server host 112 in the destination address and the well-known logical port 67 in the destination logical port.
Further, before sending the data packet to the DHCP server 113 , the DHCP relay agent 103 includes authentication and authorization information in the DHCP discovery message. To illustrate one way in which this is accomplished, consider FIG. 3 . FIG. 3 is a block diagram that illustrates a DHCP discovery message 330 in a UDP/IP data packet 300 according to an embodiment.
・・・(中略)・・・
The fields in the DHCP options portion include the DHCP message-type field 336 , among others. The DHCP message-type field 336 holds data that indicates the type of message, such as an initial discovery request (a "DHCPDISCOVER" message type) and a renewal request (a "DHCPREQUEST" type), and the response with an offer (an "DHCPOFFER" type), among others. Other fields of the DHCP options portion are indicated by the ellipsis 339 .
The DHCP options portion includes a DHCP relay agent options portion 340 . According to the second set of embodiments, DHCP relay agent options are added to carry authentication and authorization data. The options are specified according to the DHCP for specifying options in a DHCP message. In one embodiment, the DHCP relay agent option includes a credentials field 342 and a user class field 344 . The credentials field 342 includes data that indicates the actual user, and that the trusted RADIUS server is the source of the authentication and authorization data. The user class field 344 includes data indicating the user class for the user of the host 122 , as determined by the RADIUS server 135 . Other fields of the relay agent options portion are indicated by the ellipsis 349 .
At time t 6 after t 5 , the DHCP relay agent 103 sends a DHCP discovery message 252 in a UDP/IP data packet directed to the DHCP server 113 . The DHCP discovery message 252 includes authentication and authorization data 236 . For example, the DHCP discovery message includes data in the credentials field 342 and in the user class field 344 .
According to the illustrated embodiment, the DHCP server 113 selects a pool of IP addresses based on the authentication and authorization data 236 in the DHCP discovery message 252 . For example, the DHCP server 113 determines a particular user class from the data in the user class field 344 . The DHCP server 113 finds the particular user class in the map 118 associating user classes with corresponding pools, and determines that the corresponding pool is the second pool. The DHCP server 113 therefore selects the second pool 116 of IP addresses. The DHCP server 113 selects a particular IP address from the selected pool of IP addresses. For example, the DHCP server 113 selects one IP address from the second pool 116 of IP addresses.
(当審仮訳:
3.0 機能の概要
図2は,図1のシステムのいくつかの要素間で送られる一連のメッセージを表す時系列図である。図2において,時間は上から下にいくにつれて増加する。1番目の列の複数のブロックはホスト122で実行されるプロセスを表す。2番目の列の複数のブロックはスイッチ102で実行されるプロセスを表す。矢印は,矢印の先端で指定される相対的時間で送信されるメッセージを示す。
・・・(中略)・・・
もしユーザが真正であり,その真正なユーザがローカルネットワークへ接続することが認可されるなら,認証が成功したことを示す認証データとユーザが要求する権利を有するサービスを示す認可データとを含む応答232が用意される。いくつかの実施例では,認証データは,ユーザを認定しかつ信頼できるRADIUSサーバが認証認可のソースであることを保証する信任状を含む。示された実施例では,認可情報は,ユーザプロファイルデータ136の中で真正なユーザと関連付けられたユーザクラスも示す。
ｔ2の後の時間ｔ3で,認証認可データを含んだ応答232は,スイッチ102の認証部105に送られる。
・・・(中略)・・・
ｔ4の後の時間ｔ5で,ホスト122上のDHCPクライアントはそのホスト122のためのIPアドレスを含む設定情報を要求するDHCP発見メッセージをブロードキャストする。DHCP中継エージェントを持たない従来のスイッチならその同じDHCP発見メッセージを受信しその後またブロードキャストするであろう。また,最初の実施例では,DHCP中継エージェント103がスイッチ102に含まれる必要はない。しかしながら,第2の組の実施例では,スイッチはDHCP中継エージェント103を含む。
DHCP中継エージェントはデータパケットの宛先アドレスとして各DHCPサーバホストのIPアドレスを用い,宛先論理ポートとしてウェルノウンポート67を用いて,DHCP発見メッセージを含んだIPデータパケットを1または複数のDHCPサーバへ向かわせる。示された実施例では,DHCP中継エージェント103は,DHCPサーバーホスト112のIPアドレスを宛先アドレスとし,ウェルノウン論理ポート67を宛先論理ポートとしたUDP/IPデータパケットを生成する。
さらに,そのデータパケットをDHCPサーバ113に送信する前に,DHCP中継エージェント103は,そのDHCP発見メッセージの中に認証認可情報を入れる。これが実行される方法を例示するために図3を参照されたい。図3は,1実施例に従った,UDP/IPデータパケット300内のDHCP発見メッセージ330を示すブロック図である。
・・・(中略)・・・
DHCPオプション部のフィールドは特にDHCPメッセージタイプフィールド336を含む。DHCPメッセージタイプフィールド336は,特に,最初の発見要求("DHCPDISCOVER"メッセージタイプ),新された要求("DHCPREQUEST"タイプ),オファーを伴った応答("DHCPOFFER"タイプ)のようなメッセージのタイプを示すデータを持つ。DHCPオプション部の他のフィールドは省略339として示されている。
DHCPオプション部はDHCP中継エージェントオプション部340を含む。第2の組の実施例によれば,DHCP中継エージェントオプションは認証認可データを運ぶために付加される。そのオプションはDHCPがDHCPメッセージ内のオプションを特定するやり方に従って特定される。1実施例では,DHCP中継エージェントオプションは信任状フィールド342とユーザクラスフィールド344を含む。信任状フィールド343は現実のユーザを示し,かつ,信頼できるRADIUSサーバが認証認可データのソースであることを示すデータを含む。ユーザクラスフィールド344はRADIUSサーバ135で決定されたホスト122のユーザのユーザクラスを示すデータを含む。中継エージェントオプションの他のフィールドは省略349として示されている。
ｔ5の後の時間ｔ6で,DHCP中継エージェント103はDHCPサーバ113へ向けられたUDP/IPデータパケットでDHCP発見メッセージ252を送る。DHCP発見メッセージ252は認証認可データ236を含む。例えば,DHCP発見メッセージは信任状フィールド342とユーザクラスフィールド344のデータを含む。
示された実施例では,DHCPサーバ113はDHCP発見メッセージ252の中の認証認可データ236に基づいてIPアドレスのプールを選択する。例えば,DHCPサーバ113はユーザクラスフィールド344のデータから特定のユーザクラスを決定する。DHCPサーバ113はユーザクラスと対応するプールとを関連付けるマップ118の中の特定のユーザクラスを見つけ,対応するプールが第2のプールであると決定する。DHCPサーバ113はそれゆえIPアドレスの第2のプール116を選択する。DHCPサーバ113は選択されたIPアドレスのプールから特定のIPアドレスを選択する。例えば,DHCPサーバ113はIPアドレスの第2のプール116から1つのIPアドレスを選択する。)」(第8?11欄)

上記摘記事項及びこの分野における技術常識を勘案すると,上記引用例の特に図2の時系列図から,認証認可データの転送に関して以下の技術事項が読み取れる。

a スイッチ102は,ユーザクラスを含んだ認証認可データ232をRADIUSサーバホスト132から受信している。
b スイッチ102は,受信した認証認可データ232を,ホスト122から送信されたDHCP発見メッセージ242に付加した中継エージェントオプション340内のフィールドに挿入し,DHCPサーバホスト112へ送信している。

上記技術事項及びこの分野における技術常識を総合勘案すると,上記引用例には次の発明(以下,「引用発明」という。)が記載されていると認める。

「スイッチ102によって,RADIUSサーバホスト132から送信された認証認可データを受信するステップであって,前記認証認可データは,ユーザクラスを含む,受信するステップと,
スイッチ102によって,DHCP中継エージェントオプションをホスト122から送信されたDHCP発見メッセージに付加し,前記認証認可データを前記オプション内のフィールドに含ませ,前記DHCP発見メッセージと前記オプションとの両方を含むDHCP発見メッセージをDHCサーバホスト112に送信するステップと,
を含む,認証認可データ転送方法。」

(3)対比
補正後の発明と引用発明とを対比するに,

a 引用発明の「ホスト122」は「DHCP発見メッセージ」を(スイッチ102を経由して)DHCPサーバホスト112に送信するクライアント機能を有するから「DHCPクライアント」といえ,補正後の発明の「DHCPｖ6クライアント」とは「DHCPクライアント」の点で共通する。
b aと同様に,引用発明の「スイッチ102」はDHCP発見メッセージを中継する「DHCP中継装置」といえるから,補正後の発明の「IPｖ6向け動的ホスト構成プロトコル(DHCPｖ6)中継装置」とは,「DHCP中継装置」の点で共通する。
c a,bと同様に,引用発明の「DHCPサーバホスト112」と補正後の発明の「DHCPｖ6サーバ」とは「DHCPサーバ」の点で共通する。
d 引用例に「RADIUSサーバホスト132はRADIUSサーバ135を実行するプロセッサを含む。RADIUSサーバは認証認可アカウンティング(AAA)サービスを提供する。」(摘記事項イ)とあるように,引用発明の「RADIUSサーバホスト132」は,ホスト122の「認証認可アカウンティング(AAA)」を管理するサーバであるから,補正後の発明の「認証認可アカウンティング(AAA)サーバ」に相当する。
e 引用発明の「認証認可データ」は補正後の発明の「認証情報」に相当するが,その具体的な情報として,引用発明では「ユーザクラスを含む」のに対し,補正後の発明では「プレフィックス・プール名,アドレス・プール名,指定IPｖ6プレフィックス,または指定IPｖ6アドレスを含む」点で相違する。
f 引用発明の「中継エージェントオプション」は補正後の発明の「オプション」に含まれる。また,前記認証認可データを「前記オプション内のフィールドに含ませ」ることは,前記認証認可データを「前記オプションにカプセル化」することといえる。
g 引用発明のホスト122から送信された「DHCP発見メッセージ」と補正後の発明のDHCPｖ6クライアントからの「要請メッセージ」とは「DHCPメッセージ」である点で共通する。
h 引用発明のスイッチ102によって送受信される「DHCP発見メッセージ」は,スイッチ102によって中継,転送される「DHCP中継転送メッセージ」といえるから,補正後の発明の「DHCPｖ6中継転送メッセージ」とは「DHCP中継転送メッセージ」の点で共通する。

以上をまとめると,両者は以下の点で一致ないし相違している。

(一致点)
「動的ホスト構成プロトコル(DHCP)中継装置によって,認証認可アカウンティング(AAA)サーバにより配信された認証情報を受信するステップと,
DHCP中継装置によって, オプションをDHCP中継転送メッセージに挿入し,前記認証情報を前記オプションにカプセル化し,DHCPクライアントからのDHCPメッセージと前記オプションとの両方を含むDHCP中継転送メッセージをDHCPサーバに送信するステップと,
を含む,認証情報転送方法。」

(相違点1)
「動的ホスト構成プロトコル(DHCP)」が,
補正後の発明では「IPｖ6向け動的ホスト構成プロトコル(DHCPｖ6)」であるのに対し,
引用発明ではどのIPバーション向けであるのかは明らかでない点。

(相違点2)
一致点の,DHCPクライアントからの「DHCPメッセージ」が,
補正後の発明では「要請メッセージ」であるのに対し,
引用発明では「DHCP発見メッセージ」である点。

(相違点3)
一致点の「認証情報」が,
補正後の発明では「プレフィックス・プール名,アドレス・プール名,指定IPｖ6プレフィックス,または指定IPｖ6アドレスを含む」のに対し,
引用発明では「ユーザクラスを含む」点。

(4)判断
上記各相違点につき検討する。

(相違点1)及び(相違点2)について
「動的ホスト構成プロトコル(DHCP)」について引用例の摘記事項アに詳しく記載されているように,DHCPはホストがネットワークに接続した際にIPアドレスを含む各種の設定情報を取得することを可能とするプロトコルである。そして「DHCP」が「IPネットワーク」で用いられるプロトコルであること,及び,「IP(インターネットプロトコル)」として従来より普及していた「IPｖ4」に加え新たな規格である「IPｖ6(インターネットプロトコルバージョン6)」があることは,いずれも本件出願の優先日において技術常識である。そして,「IPｖ6」を用いる「IPｖ6ネットワーク」においても「DHCP」として「DHCP(DHCPｖ6)」が用いられることは,「Dynamic Host Configuration Protocol for IPv6 (DHCPv6),RFC 3315,2003年」(以下,「周知文献」という。)に記載されているように当業者にとって周知の事項である。
そうすると,引用発明の方法をIPｖ6ネットワークに適用して,使用する「動的ホスト構成プロトコル(DHCP)」を補正後の発明の「IPｖ6向け動的ホスト構成プロトコル(DHCPｖ6)」とすること(相違点1)は,当業者が必要に応じて適宜なし得たものである。
また,これに関連して,上記周知文献に「A client uses the Solicit message to discover DHCP servers(当審仮訳:クライアントはDHCPサーバを発見するために要請メッセージを送信する)」(32頁「17.1. Client Behavior」)と記載されているように,DHCPｖ6において,DHCPサーバを発見するためにクライアントが送信するメッセージを「要請メッセージ」と呼ぶことは周知であるところ,引用発明の「DHCP発見メッセージ」を補正後の発明の「要請メッセージ」と称すること(相違点2)も,上記(相違点1)の解決に伴い普通になし得ることにすぎない。

(相違点3)について
引用例に「示された実施例では,DHCPサーバ113はDHCP発見メッセージ252の中の認証認可データ236に基づいてIPアドレスのプールを選択する。例えば,DHCPサーバ113はユーザクラスフィールド344のデータから特定のユーザクラスを決定する。DHCPサーバ113はユーザクラスと対応するプールとを関連付けるマップ118の中の特定のユーザクラスを見つけ,対応するプールが第2のプールであると決定する。DHCPサーバ113はそれゆえIPアドレスの第2のプール116を選択する。DHCPサーバ113は選択されたIPアドレスのプールから特定のIPアドレスを選択する。例えば,DHCPサーバ113はIPアドレスの第2のプール116から1つのIPアドレスを選択する。」(摘記事項ウ)と記載されているように,引用発明の「ユーザクラス」は特定の「IPアドレスプール」とマップ118で関連付けられており,(DHCPサーバ113を実行する)DHCPサーバホスト112は,受信した「ユーザクラス」で特定される「IPアドレスプール」を選択している。
そうすると,引用発明において,「ユーザクラス」は「IPアドレスプール」を特定するための単なるインデックスとして用いられているに過ぎないことが分かり,そのような「IPアドレスプール」の特定の仕方に代えて,直接的に「IPアドレスプール」の名前,即ち「アドレス・プール名」で特定するようにすることは,当業者であれば適宜なし得ることである。
したがって,上記(相違点3)は格別な相違ということはできない。

そして,補正後の発明が奏する効果も引用発明及び周知の事項から容易に予測できる範囲内のものである。

(5)まとめ
以上のとおり,補正後の発明は,引用発明および周知の事項に基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許出願の際独立して特許を受けることができないものである。
したがって,本件補正は,特許法第17条の2第6項において準用する特許法第126条第7項の規定に違反するので,特許法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

第3 本願発明について
1 本願発明
本件補正は上記のとおり却下されたので,本願発明は,上記「第2 補正却下の決定 1 本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。

2 引用発明
引用発明は,上記「第2 補正却下の決定」の項中の「3 独立特許要件について」の項中の「(2)引用発明」の項で認定したとおりである。

3 対比・判断
本願発明は上記補正後の発明から当該本件補正に係る限定を省いたものである。
そうすると,本願発明の構成に当該本件補正に係る限定を付加した補正後の発明が,上記「第2 補正却下の決定」の項中の「3 独立特許要件について」の項で検討したとおり,引用発明及び周知の事項に基づいて容易に発明できたものであるから,本願発明も同様の理由により,容易に発明できたものである。

4 むすび
以上のとおり,本願発明は引用発明及び周知の事項に基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。
したがって,他の請求項に係る発明について審理するまでもなく,本願は拒絶すべきものである。
よって,結論のとおり審決する。
 
審理終結日 2016-06-27 
結審通知日 2016-06-28 
審決日 2016-07-11 
出願番号 特願2014-540302(P2014-540302)
審決分類 P 1 8・ 121- Z (H04L)
最終処分 不成立  
前審関与審査官 菊地 陽一、松崎 孝大  
特許庁審判長 大塚 良平
特許庁審判官 新川 圭二
中野 浩昌
発明の名称 認証情報を転送するための方法、中継装置、およびサーバ  
代理人 佐伯 義文  
代理人 木内 敬二  

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