【事件の表示】
　特願２０１４−５４０３０２「認証情報を転送するための方法、中継装置、およびサーバ」拒絶査定不服審判事件〔平成２５年　５月１６日国際公開、ＷＯ２０１３／０６７８８４、平成２６年１２月　８日国内公表、特表２０１４−５３３０５４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本件出願は，２０１２年１０月２２日（パリ条約による優先権主張外国庁受理２０１１年１１月８日，中華人民共和国）を国際出願日とする出願であって，平成２７年４月１０日付け拒絶理由通知に対して同年６月４日に意見書及び手続補正書が提出されたが同年７月３日付けで拒絶査定がなされ，これを不服として同年１１月２日に審判請求がなされるとともに手続補正書が提出されたものである。
　
第２　補正却下の決定
［補正却下の決定の結論］
　平成２７年１１月２日に提出された手続補正書による手続補正（以下，「本件補正」という。）を却下する。
　
［理由］
１　本願発明と補正後の発明
　本件補正は，平成２７年６月４日に提出された手続補正書の特許請求の範囲の請求項１に記載された
「　ＩＰｖ６向け動的ホスト構成プロトコル（ＤＨＣＰｖ６）中継装置によって，ＡＡＡサーバにより配信された認証情報を受信するステップであって，前記認証情報は，プレフィックス・プール名，アドレス・プール名，指定ＩＰｖ６プレフィックス，または指定ＩＰｖ６アドレスを含む，受信するステップと，
　ＤＨＣＰｖ６中継装置によって， オプションをＤＨＣＰｖ６中継転送メッセージに挿入し，前記認証情報を前記オプションにカプセル化し，前記オプションをＤＨＣＰｖ６サーバに送信するステップと，
　を含む，認証情報転送方法。」
　という発明（以下，「本願発明」という。）を，補正後の特許請求の範囲の請求項１に記載された
「ＩＰｖ６向け動的ホスト構成プロトコル（ＤＨＣＰｖ６）中継装置によって，認証認可アカウンティング（ＡＡＡ）サーバにより配信された認証情報を受信するステップであって，前記認証情報は，プレフィックス・プール名，アドレス・プール名，指定ＩＰｖ６プレフィックス，または指定ＩＰｖ６アドレスを含む，受信するステップと，
　ＤＨＣＰｖ６中継装置によって， オプションをＤＨＣＰｖ６中継転送メッセージに挿入し，前記認証情報を前記オプションにカプセル化し，ＤＨＣＰｖ６クライアントからの要請メッセージと前記オプションとの両方を含むＤＨＣＰｖ６中継転送メッセージをＤＨＣＰｖ６サーバに送信するステップと，
　を含む，認証情報転送方法。」
　という発明（以下，「補正後の発明」という。）に変更することを含むものである。
　
２　新規事項の有無，シフト補正の有無，補正の目的要件について
　本件補正は，願書に最初に添付した明細書，特許請求の範囲若しくは図面に記載した事項の範囲内において，補正前の特許請求の範囲の請求項１に記載された「中継転送メッセージ」についてが「ＤＨＣＰｖ６クライアントからの要請メッセージと前記オプションとの両方を含む」点を付加してこれを限定することにより特許請求の範囲を限定的に減縮するものであって，特許法第１７条の２第３項（新規事項）及び特許法第１７条の２第５項第２号（補正の目的）の規定に適合している。
　また，特許法第１７条の２第４項（シフト補正）に違反するものでもない。
　
３　独立特許要件について
　上記補正は特許請求の範囲の限定的減縮を目的とするものであるから，上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。 
　
（１）補正後の発明
　上記「１　本願発明と補正後の発明」の項で「補正後の発明」として認定したとおりである。
　
（２）引用発明
　原査定の拒絶の理由に引用された米国特許第７５０２９２９号明細書(以下，「引用例」という。)には，「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.
（当審仮訳：
　１．２　ＤＨＣＰ
　ダイナミックホストコンフィギュレーションプロトコル（ＤＨＣＰ）は，本件執筆時点でワールドワイドウェブ（www）上のietf.org/rfcというドメイン及びディレクトリでそれぞれ文書rfc2131.htmlとrfc2132.htmlとして入手可能なＲＦＣ２１３１とＲＦＣ２１３２に記載されたダイナミックホストコンフィギュレーションの公開標準プロトコルである。ＤＨＣＰサーバプロセスは，１またはそれ以上のローカルネットワーク上の複数のホストにとって便利な位置にあるＤＨＣＰサーバホスト上で動作する。１またはそれ以上のＤＨＣＰサーバホストとプロセスは，１またはそれ以上のローカルネットワークの現在のアーキテクチャを反映させるように，これらのネットワーク上のホストを設定するための情報を有したシステム管理者によってセットアップされる。ＤＨＣＰクライアントプロセスは，そのローカルネットワークの各ホスト上で動作する。
　ホストがローカルネットワーク上で動作を開始するとき，そのホスト上のＤＨＣＰクライアントは，ＤＨＣＰサーバの１つに対して設定情報を要求する。ＤＨＣＰクライアントからの要求に対する応答として，１またはそれ以上のＤＨＣＰサーバは，そのＤＨＣＰクライアントのホストのためのＩＰアドレスを含み，そのＤＨＣＰクライアントのホストによって既定の期間（「リース時間」）だけ使用される設定情報を返す。そのような応答は，アドレスのリースの「オファー」の形式をとる。そのＤＨＣＰクライアントは，オファーの１つが受け入れられたことをそれらのサーバに通知する。その後，そのＤＨＣＰクライアントを実行中のホストは，そのアドレスを含んだ設定情報を使用する。その設定情報は特定のＤＨＣＰクライアントに結びつけられ，リースをオファーしたＤＨＣＰサーバはその結びつきを記録する。）」（第６欄）
　
イ　「　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.
（当審仮訳：
　２．０　構成の概要
　図１は，物理的接続と論理ネットワークアドレス付与を認可するためのシステムの概要を示すブロック図である。
　図１の例において，システム１００はローカルネットワーク１０６と通信可能に結合されたスイッチ１０２を含む。ホスト１２２はスイッチ１０２を介してローカルネットワーク１０６と接続する。システム１００はＲＡＤＩＵＳサーバホスト１３２，ＤＨＣＰサーバホスト１１２，ゲートウェイホスト１４２も含む。ゲートウェイホスト１４２はインターネット１５０あるいは他の任意の公共ネットワークかインターネットワークに接続する。
　スイッチ１０２はまとめて物理ポート１０４と称される物理ポート１０４ａ，１０４ｂ，１０４ｃ，１０４ｄを含む。スイッチ１０２は物理ポートベースのアクセス制御のためのＩＥＥＥ８０２．１ｘ標準を採用する。認証部１０５はスイッチ１０２のプロセッサ上でＩＥＥＥ８０２．１ｘ標準を適用するように働く。認証部１０５は以下に詳述するように，スイッチ１０２の永続的な貯蔵所１０８に認証認可データを蓄える。認証認可データはＲＡＤＩＵＳサーバホスト１３２から得られた情報を含む。ＩＥＥＥ８０２．１ｘ標準は，以下により詳細に述べるように，スイッチ１０２におけるＲＡＤＩＵＳサーバホスト１３２からの認証認可データの保存を要求もしくは示唆しない。
　加えて，図１の例では，ＤＨＣＰ中継エージェント１０３もスイッチ１０２のプロセッサ上で働く。ＤＨＣＰ中継エージェント１０３は，ＤＨＣＰメッセージを使ってホスト１２２上のＤＨＣＰクライアント１２３およびＤＨＣＰサーバホスト１１２上のＤＨＣＰサーバと通信する。ＤＨＣＰ中継エージェント１０３は，以下により詳細に述べるように，永続的な貯蔵所１０８の認証認可データ使用する。ＤＨＣＰは，ＤＨＣＰ中継エージェント１０３によるＲＡＤＩＵＳサーバからの認証認可データの使用を要求もしくは示唆しない。
　ホスト１２２は，物理ポートベースのアクセス制御のためにＩＥＥＥ８０２．１ｘ標準を採用し，ＩＰアドレス付与を含むネットワーク設定のためにＤＨＣＰを採用する。ホストは接続１２１を介してスイッチ１０２の物理ポート１０４ｂに接続されている。接続１２１はケーブルもしくは電磁信号または音声信号のような無線信号によってであり得る。サプリカント１２５はホスト１２２のプロセッサ上でＩＥＥＥ８０２．１ｘ標準を適用するように働く。サプリカントはホストのユーザからユーザＩＤやパスワードのような情報を得て，接続１２１を使って物理ポート１０４ｂを介して認証部１０５へその情報を送る。ＤＨＣＰクライアント１２３は，ＤＨＣＰサーバから他の設定情報とともにＩＰアドレスを取得するためにホスト１２２のプロセッサ上で働く。
　ＲＡＤＩＵＳサーバホスト１３２はＲＡＤＩＵＳサーバ１３５を実行するプロセッサを含む。ＲＡＤＩＵＳサーバは認証認可アカウンティング（ＡＡＡ）サービスを提供する。認証サービスは，パスワードとユーザＩＤの組合せを確認することなどにより，ユーザがその主張のとおりのユーザであることを決定する。認可サービスは，認証されたユーザがネットワーク上で操作を実行する権利を有することを示す。例えば，認可サービスは，認証されたユーザがローカルネットワークへの物理的な接続は許可されているがインターネットへのアクセスは許可されていないことを決定する。アカウンティングサービスは，例えばＱｏＳ契約をサポートし使用制限を実施するために，ユーザの認可された操作の使用が追跡されることを決定する。ＲＡＤＩＵＳサーバは，ユーザＩＤ，パスワード，権利を含むユーザプロファイルデータ１３６の１または複数のデータ構造を保持する。ＲＡＤＩＵＳサーバ１３５は，認証部１０５から，ホスト１２２のユーザを認証するよう要求を受ける。ＲＡＤＩＵＳサーバは認証が成功したか失敗したかを示す応答を送る。いくつかの実施例では，認証が成功したとき，ＲＡＤＩＵＳサーバは認可情報も送る。
　１実施例では，ユーザプロファイルデータ１３６においてユーザクラスは各ユーザと関連付けられている。ユーザのＩＰアドレスに基づいてＬＡＮ上の１または複数サービスにより実施されるＬＡＮ資源と課金についての実質的に同じ認可を有するローカルネットワーク上の複数のユーザは，同じユーザクラスに配置される。この実施例において，ユーザクラスはＲＡＤＩＵＳサーバから認証部１０５へ送られる認可情報に含まれる。
　ＤＨＣＰサーバホスト１１２はＤＨＣＰサーバ１１３と呼ばれるプロセスを実行するプロセッサを含む。ＤＨＣＰサーバ１１３は，ローカルネットワーク１０６へ接続されたホストにＩＰアドレスや他の設定情報を提供するために，ＤＨＣＰクライアントやＤＨＣＰ中継エージェントとメッセージを交換するためのＤＨＣＰを適用する。
　示された実施例では，ＤＨＣＰサーバ１１３は，ＤＨＣＰサーバホスト１１２上で１または複数のデータ構造として記憶されたＩＰアドレスの第１のプール１１４とＩＰアドレスの第２のプールを含むＩＰアドレスの複数のプールの中からＩＰアドレスを付与する。加えて，ＤＨＣＰサーバはＩＰアドレスの各プールとユーザクラスを関連付けるマップ１１８とここで呼ばれるデータ構造記憶している。ＤＨＣＰは，ＤＨＣＰサーバ１１３がユーザクラスとＩＰアドレスのプールを関連付けるマップ１１８を記憶し使用することを要求していない。加えて，ＤＨＣＰサーバ１１３は，設定されるホストのユーザのために，ユーザクラスをＤＨＣＰ中継エージェント１０３から取得する。そのユーザクラスは，スイッチ１０２の永続的な貯蔵所１０８の認証認可データのなかの情報に基づいている。ＤＨＣＰはＤＨＣＰサーバ１１３がＤＨＣＰ中継エージェントからユーザクラスを取得することを要求あるいは示唆していない。）」（第６〜８欄）
　
ウ　「　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.
（当審仮訳：
　３．０　機能の概要
　図２は，図１のシステムのいくつかの要素間で送られる一連のメッセージを表す時系列図である。図２において，時間は上から下にいくにつれて増加する。１番目の列の複数のブロックはホスト１２２で実行されるプロセスを表す。２番目の列の複数のブロックはスイッチ１０２で実行されるプロセスを表す。矢印は，矢印の先端で指定される相対的時間で送信されるメッセージを示す。
　・・・（中略）・・・
　もしユーザが真正であり，その真正なユーザがローカルネットワークへ接続することが認可されるなら，認証が成功したことを示す認証データとユーザが要求する権利を有するサービスを示す認可データとを含む応答２３２が用意される。いくつかの実施例では，認証データは，ユーザを認定しかつ信頼できるＲＡＤＩＵＳサーバが認証認可のソースであることを保証する信任状を含む。示された実施例では，認可情報は，ユーザプロファイルデータ１３６の中で真正なユーザと関連付けられたユーザクラスも示す。
　ｔ２の後の時間ｔ３で，認証認可データを含んだ応答２３２は，スイッチ１０２の認証部１０５に送られる。
　・・・（中略）・・・
　ｔ４の後の時間ｔ５で，ホスト１２２上のＤＨＣＰクライアントはそのホスト１２２のためのＩＰアドレスを含む設定情報を要求するＤＨＣＰ発見メッセージをブロードキャストする。ＤＨＣＰ中継エージェントを持たない従来のスイッチならその同じＤＨＣＰ発見メッセージを受信しその後またブロードキャストするであろう。また，最初の実施例では，ＤＨＣＰ中継エージェント１０３がスイッチ１０２に含まれる必要はない。しかしながら，第２の組の実施例では，スイッチはＤＨＣＰ中継エージェント１０３を含む。
　ＤＨＣＰ中継エージェントはデータパケットの宛先アドレスとして各ＤＨＣＰサーバホストのＩＰアドレスを用い，宛先論理ポートとしてウェルノウンポート６７を用いて，ＤＨＣＰ発見メッセージを含んだＩＰデータパケットを１または複数のＤＨＣＰサーバへ向かわせる。示された実施例では，ＤＨＣＰ中継エージェント１０３は，ＤＨＣＰサーバーホスト１１２のＩＰアドレスを宛先アドレスとし，ウェルノウン論理ポート６７を宛先論理ポートとしたＵＤＰ／ＩＰデータパケットを生成する。
　さらに，そのデータパケットをＤＨＣＰサーバ１１３に送信する前に，ＤＨＣＰ中継エージェント１０３は，そのＤＨＣＰ発見メッセージの中に認証認可情報を入れる。これが実行される方法を例示するために図３を参照されたい。図３は，１実施例に従った，ＵＤＰ／ＩＰデータパケット３００内のＤＨＣＰ発見メッセージ３３０を示すブロック図である。
　・・・（中略）・・・
　ＤＨＣＰオプション部のフィールドは特にＤＨＣＰメッセージタイプフィールド３３６を含む。ＤＨＣＰメッセージタイプフィールド３３６は，特に，最初の発見要求（DHCPDISCOVERメッセージタイプ），新された要求（DHCPREQUESTタイプ），オファーを伴った応答（DHCPOFFERタイプ）のようなメッセージのタイプを示すデータを持つ。ＤＨＣＰオプション部の他のフィールドは省略３３９として示されている。
　ＤＨＣＰオプション部はＤＨＣＰ中継エージェントオプション部３４０を含む。第２の組の実施例によれば，ＤＨＣＰ中継エージェントオプションは認証認可データを運ぶために付加される。そのオプションはＤＨＣＰがＤＨＣＰメッセージ内のオプションを特定するやり方に従って特定される。１実施例では，ＤＨＣＰ中継エージェントオプションは信任状フィールド３４２とユーザクラスフィールド３４４を含む。信任状フィールド３４３は現実のユーザを示し，かつ，信頼できるＲＡＤＩＵＳサーバが認証認可データのソースであることを示すデータを含む。ユーザクラスフィールド３４４はＲＡＤＩＵＳサーバ１３５で決定されたホスト１２２のユーザのユーザクラスを示すデータを含む。中継エージェントオプションの他のフィールドは省略３４９として示されている。
　ｔ５の後の時間ｔ６で，ＤＨＣＰ中継エージェント１０３はＤＨＣＰサーバ１１３へ向けられたＵＤＰ／ＩＰデータパケットでＤＨＣＰ発見メッセージ２５２を送る。ＤＨＣＰ発見メッセージ２５２は認証認可データ２３６を含む。例えば，ＤＨＣＰ発見メッセージは信任状フィールド３４２とユーザクラスフィールド３４４のデータを含む。
　示された実施例では，ＤＨＣＰサーバ１１３はＤＨＣＰ発見メッセージ２５２の中の認証認可データ２３６に基づいてＩＰアドレスのプールを選択する。例えば，ＤＨＣＰサーバ１１３はユーザクラスフィールド３４４のデータから特定のユーザクラスを決定する。ＤＨＣＰサーバ１１３はユーザクラスと対応するプールとを関連付けるマップ１１８の中の特定のユーザクラスを見つけ，対応するプールが第２のプールであると決定する。ＤＨＣＰサーバ１１３はそれゆえＩＰアドレスの第２のプール１１６を選択する。ＤＨＣＰサーバ１１３は選択されたＩＰアドレスのプールから特定のＩＰアドレスを選択する。例えば，ＤＨＣＰサーバ１１３はＩＰアドレスの第２のプール１１６から１つのＩＰアドレスを選択する。）」（第８〜１１欄）
　
　上記摘記事項及びこの分野における技術常識を勘案すると，上記引用例の特に図２の時系列図から，認証認可データの転送に関して以下の技術事項が読み取れる。
　
ａ　スイッチ１０２は，ユーザクラスを含んだ認証認可データ２３２をＲＡＤＩＵＳサーバホスト１３２から受信している。
ｂ　スイッチ１０２は，受信した認証認可データ２３２を，ホスト１２２から送信されたＤＨＣＰ発見メッセージ２４２に付加した中継エージェントオプション３４０内のフィールドに挿入し，ＤＨＣＰサーバホスト１１２へ送信している。
　
　上記技術事項及びこの分野における技術常識を総合勘案すると，上記引用例には次の発明（以下，「引用発明」という。）が記載されていると認める。
　
「スイッチ１０２によって，ＲＡＤＩＵＳサーバホスト１３２から送信された認証認可データを受信するステップであって，前記認証認可データは，ユーザクラスを含む，受信するステップと，
　スイッチ１０２によって，ＤＨＣＰ中継エージェントオプションをホスト１２２から送信されたＤＨＣＰ発見メッセージに付加し，前記認証認可データを前記オプション内のフィールドに含ませ，前記ＤＨＣＰ発見メッセージと前記オプションとの両方を含むＤＨＣＰ発見メッセージをＤＨＣサーバホスト１１２に送信するステップと，
　を含む，認証認可データ転送方法。」
　
（３）対比
　補正後の発明と引用発明とを対比するに，
　
ａ　引用発明の「ホスト１２２」は「ＤＨＣＰ発見メッセージ」を（スイッチ１０２を経由して）ＤＨＣＰサーバホスト１１２に送信するクライアント機能を有するから「ＤＨＣＰクライアント」といえ，補正後の発明の「ＤＨＣＰｖ６クライアント」とは「ＤＨＣＰクライアント」の点で共通する。
ｂ　ａと同様に，引用発明の「スイッチ１０２」はＤＨＣＰ発見メッセージを中継する「ＤＨＣＰ中継装置」といえるから，補正後の発明の「ＩＰｖ６向け動的ホスト構成プロトコル（ＤＨＣＰｖ６）中継装置」とは，「ＤＨＣＰ中継装置」の点で共通する。
ｃ　ａ，ｂと同様に，引用発明の「ＤＨＣＰサーバホスト１１２」と補正後の発明の「ＤＨＣＰｖ６サーバ」とは「ＤＨＣＰサーバ」の点で共通する。
ｄ　引用例に「ＲＡＤＩＵＳサーバホスト１３２はＲＡＤＩＵＳサーバ１３５を実行するプロセッサを含む。ＲＡＤＩＵＳサーバは認証認可アカウンティング（ＡＡＡ）サービスを提供する。」（摘記事項イ）とあるように，引用発明の「ＲＡＤＩＵＳサーバホスト１３２」は，ホスト１２２の「認証認可アカウンティング（ＡＡＡ）」を管理するサーバであるから，補正後の発明の「認証認可アカウンティング（ＡＡＡ）サーバ」に相当する。
ｅ　引用発明の「認証認可データ」は補正後の発明の「認証情報」に相当するが，その具体的な情報として，引用発明では「ユーザクラスを含む」のに対し，補正後の発明では「プレフィックス・プール名，アドレス・プール名，指定ＩＰｖ６プレフィックス，または指定ＩＰｖ６アドレスを含む」点で相違する。
ｆ　引用発明の「中継エージェントオプション」は補正後の発明の「オプション」に含まれる。また，前記認証認可データを「前記オプション内のフィールドに含ませ」ることは，前記認証認可データを「前記オプションにカプセル化」することといえる。
ｇ　引用発明のホスト１２２から送信された「ＤＨＣＰ発見メッセージ」と補正後の発明のＤＨＣＰｖ６クライアントからの「要請メッセージ」とは「ＤＨＣＰメッセージ」である点で共通する。
ｈ　引用発明のスイッチ１０２によって送受信される「ＤＨＣＰ発見メッセージ」は，スイッチ１０２によって中継，転送される「ＤＨＣＰ中継転送メッセージ」といえるから，補正後の発明の「ＤＨＣＰｖ６中継転送メッセージ」とは「ＤＨＣＰ中継転送メッセージ」の点で共通する。
　
　以上をまとめると，両者は以下の点で一致ないし相違している。
　
（一致点）
「動的ホスト構成プロトコル（ＤＨＣＰ）中継装置によって，認証認可アカウンティング（ＡＡＡ）サーバにより配信された認証情報を受信するステップと，
　ＤＨＣＰ中継装置によって， オプションをＤＨＣＰ中継転送メッセージに挿入し，前記認証情報を前記オプションにカプセル化し，ＤＨＣＰクライアントからのＤＨＣＰメッセージと前記オプションとの両方を含むＤＨＣＰ中継転送メッセージをＤＨＣＰサーバに送信するステップと，
　を含む，認証情報転送方法。」
　
（相違点１）
　「動的ホスト構成プロトコル（ＤＨＣＰ）」が，
　補正後の発明では「ＩＰｖ６向け動的ホスト構成プロトコル（ＤＨＣＰｖ６）」であるのに対し，
　引用発明ではどのＩＰバーション向けであるのかは明らかでない点。
　
（相違点２）
　一致点の，ＤＨＣＰクライアントからの「ＤＨＣＰメッセージ」が，
　補正後の発明では「要請メッセージ」であるのに対し，
　引用発明では「ＤＨＣＰ発見メッセージ」である点。
　
（相違点３）
　一致点の「認証情報」が，
　補正後の発明では「プレフィックス・プール名，アドレス・プール名，指定ＩＰｖ６プレフィックス，または指定ＩＰｖ６アドレスを含む」のに対し，
　引用発明では「ユーザクラスを含む」点。
　
（４）判断
　上記各相違点につき検討する。
　
（相違点１）及び（相違点２）について
　「動的ホスト構成プロトコル（ＤＨＣＰ）」について引用例の摘記事項アに詳しく記載されているように，ＤＨＣＰはホストがネットワークに接続した際にＩＰアドレスを含む各種の設定情報を取得することを可能とするプロトコルである。そして「ＤＨＣＰ」が「ＩＰネットワーク」で用いられるプロトコルであること，及び，「ＩＰ（インターネットプロトコル）」として従来より普及していた「ＩＰｖ４」に加え新たな規格である「ＩＰｖ６（インターネットプロトコルバージョン６）」があることは，いずれも本件出願の優先日において技術常識である。そして，「ＩＰｖ６」を用いる「ＩＰｖ６ネットワーク」においても「ＤＨＣＰ」として「ＤＨＣＰ（ＤＨＣＰｖ６）」が用いられることは，「Dynamic Host Configuration Protocol for IPv6 (DHCPv6)，RFC 3315，２００３年」（以下，「周知文献」という。）に記載されているように当業者にとって周知の事項である。
　そうすると，引用発明の方法をＩＰｖ６ネットワークに適用して，使用する「動的ホスト構成プロトコル（ＤＨＣＰ）」を補正後の発明の「ＩＰｖ６向け動的ホスト構成プロトコル（ＤＨＣＰｖ６）」とすること（相違点１）は，当業者が必要に応じて適宜なし得たものである。
　また，これに関連して，上記周知文献に「A client uses the Solicit message to discover DHCP servers（当審仮訳：クライアントはＤＨＣＰサーバを発見するために要請メッセージを送信する）」（３２頁「17.1. Client Behavior」）と記載されているように，ＤＨＣＰｖ６において，ＤＨＣＰサーバを発見するためにクライアントが送信するメッセージを「要請メッセージ」と呼ぶことは周知であるところ，引用発明の「ＤＨＣＰ発見メッセージ」を補正後の発明の「要請メッセージ」と称すること（相違点２）も，上記（相違点１）の解決に伴い普通になし得ることにすぎない。
　
（相違点３）について
　引用例に「示された実施例では，ＤＨＣＰサーバ１１３はＤＨＣＰ発見メッセージ２５２の中の認証認可データ２３６に基づいてＩＰアドレスのプールを選択する。例えば，ＤＨＣＰサーバ１１３はユーザクラスフィールド３４４のデータから特定のユーザクラスを決定する。ＤＨＣＰサーバ１１３はユーザクラスと対応するプールとを関連付けるマップ１１８の中の特定のユーザクラスを見つけ，対応するプールが第２のプールであると決定する。ＤＨＣＰサーバ１１３はそれゆえＩＰアドレスの第２のプール１１６を選択する。ＤＨＣＰサーバ１１３は選択されたＩＰアドレスのプールから特定のＩＰアドレスを選択する。例えば，ＤＨＣＰサーバ１１３はＩＰアドレスの第２のプール１１６から１つのＩＰアドレスを選択する。」（摘記事項ウ）と記載されているように，引用発明の「ユーザクラス」は特定の「ＩＰアドレスプール」とマップ１１８で関連付けられており，（ＤＨＣＰサーバ１１３を実行する）ＤＨＣＰサーバホスト１１２は，受信した「ユーザクラス」で特定される「ＩＰアドレスプール」を選択している。
　そうすると，引用発明において，「ユーザクラス」は「ＩＰアドレスプール」を特定するための単なるインデックスとして用いられているに過ぎないことが分かり，そのような「ＩＰアドレスプール」の特定の仕方に代えて，直接的に「ＩＰアドレスプール」の名前，即ち「アドレス・プール名」で特定するようにすることは，当業者であれば適宜なし得ることである。
　したがって，上記（相違点３）は格別な相違ということはできない。
　
　そして，補正後の発明が奏する効果も引用発明及び周知の事項から容易に予測できる範囲内のものである。
　
（５）まとめ
　以上のとおり，補正後の発明は，引用発明および周知の事項に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　したがって，本件補正は，特許法第１７条の２第６項において準用する特許法第１２６条第７項の規定に違反するので，特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３　本願発明について
１　本願発明
　本件補正は上記のとおり却下されたので，本願発明は，上記「第２ 補正却下の決定 １　本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。
　
２　引用発明
　引用発明は，上記「第２ 補正却下の決定」の項中の「３　独立特許要件について」の項中の「（２）引用発明」の項で認定したとおりである。
　
３　対比・判断
　本願発明は上記補正後の発明から当該本件補正に係る限定を省いたものである。
　そうすると，本願発明の構成に当該本件補正に係る限定を付加した補正後の発明が，上記「第２　補正却下の決定」の項中の「３　独立特許要件について」の項で検討したとおり，引用発明及び周知の事項に基づいて容易に発明できたものであるから，本願発明も同様の理由により，容易に発明できたものである。
　
４　むすび
　以上のとおり，本願発明は引用発明及び周知の事項に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，他の請求項に係る発明について審理するまでもなく，本願は拒絶すべきものである。
　よって，結論のとおり審決する。