【事件の表示】
　特願２０１３−１７４５７６「ユーザ確認装置、方法及びプログラム」拒絶査定不服審判事件〔平成２５年１２月１２日出願公開、特開２０１３−２５１０００〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本件審判請求に係る出願（以下，「本願」という。）は，
２００６年３月２９日を国際出願日とする特願２００７−５４３６４１号（以下，「原願」という。）の一部を，
平成２２年９月２２日に新たな特許出願とした特願２０１０−２１２４６５号の一部をさらに，
平成２３年２月４日に新たな特許出願とした特願２０１１−０２２８９５号の一部をさらに，
平成２３年９月２２日に新たな特許出願とした特願２０１１−２０８１４１号の一部をさらに，
平成２４年５月１８日に新たな特許出願とした特願２０１２−１１３９８７号の一部をさらに，
平成２５年８月２６日に新たな特許出願としたものであって，その手続の経緯の概略は以下のとおりである。
平成２５年　８月２７日　　：出願審査請求書の提出
平成２６年　５月３０日付け：拒絶理由の通知
平成２６年　７月２９日　　：意見書，手続補正書の提出
平成２６年　９月３０日付け：拒絶査定（同年１０月７日謄本送達）
平成２７年　１月　５日　　：審判請求書の提出
平成２７年　８月２７日付け：拒絶理由の通知（当審），
平成２７年１０月１６日　　：面接
平成２７年１０月３０日　　：意見書，手続補正書の提出
平成２７年１２月１８日付け：最後の拒絶理由の通知（当審）
平成２８年　２月１２日　　：意見書，手続補正書の提出
第２　平成２８年２月１２日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２８年２月１２日付けの手続補正を却下する。
［理由］
１．補正の内容
　平成２８年２月１２日付けの手続補正（以下，「本件補正」という。）の内容は，平成２７年１０月３０日付けの手続補正により補正された特許請求の範囲の請求項１〜６の記載
「【請求項１】
　端末装置より受信したパケットから，該パケットに含まれるユーザの識別情報，該ユーザの認証に必要な認証情報および前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と，
　ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を，前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と，
　前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と，
　前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を，前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と，
　前記判定手段により前記符合しないと判定された場合，前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と，
　を備え，
　前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置。
　　【請求項２】
　前記端末情報は，複数種類のパラメータを含む請求項１に記載のユーザ確認装置。
　　【請求項３】
　前記パケットは，インターネット層のプロトコルとしてＩＰが適用され，アプリケーション層のプロトコルとしてＨＴＴＰが適用されて，前記端末装置から受信され，
　前記複数種類のパラメータは，少なくとも，前記端末装置のアクセス元ＩＰアドレスおよびＨＴＴＰヘッダから抽出されるユーザーエージェント情報を含む請求項２に記載のユーザ確認装置。
　　【請求項４】
　単一の前記ユーザ識別情報と関連付けて前記記憶手段に記憶された端末情報が複数である場合には，前記再認証手段は，前記抽出手段により抽出された端末情報が前記記憶手段に記憶されている前記複数の端末情報のいずれとも符合しないと前記判定手段に判定された場合に，前記再認証処理を行う，請求項１に記載のユーザ確認装置。
　　【請求項５】
　コンピュータを，
　端末装置より受信したパケットから，該パケットに含まれるユーザの識別情報，該ユーザの認証に必要な認証情報および前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と，
　ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を，前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と，
　前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と，
　前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を，前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と，
　前記判定手段により前記符合しないと判定された場合，前記認証手段による認証の方法
および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と，
　を備え，
　前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置として機能させるプログラムを格納した記録媒体。
　　【請求項６】
　コンピュータを，
　端末装置より受信したパケットから，該パケットに含まれるユーザの識別情報，該ユーザの認証に必要な認証情報および前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と，
　ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を，前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と，
　前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と，
　前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を，前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と，
　前記判定手段により前記符合しないと判定された場合，前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と，
　を備え，
　前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置として機能させるためのプログラム。」（以下，この特許請求の範囲に記載された請求項各項を「補正前の請求項」という。）を，
「【請求項１】
　端末装置より受信した
アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有する
，
該ヘッダ部に含まれ
　ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を，前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と，
　前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と，
　前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を，前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と，
　前記判定手段により前記符合しないと判定された場合，前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と，
　を備え，
　
前記情報管理手段は，前記再認証手段により前記ユーザの再認証が成功した場合に，前記判定手段による判定対象となる端末情報として，前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ，
　前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置。
　　【請求項２】
　単一の前記ユーザ識別情報と関連付けて前記記憶手段に記憶された端末情報が複数である場合には，前記再認証手段は，前記抽出手段により抽出された端末情報が前記記憶手段に記憶されている前記複数の端末情報のいずれとも符合しないと前記判定手段に判定された場合に，前記再認証処理を行う，請求項１に記載のユーザ確認装置。
　　【請求項３】
　コンピュータを，
　端末装置より受信した
アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有する
，
該ヘッダ部に含まれ
　ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を，前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と，
　前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と，
　前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を，前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と，
　前記判定手段により前記符合しないと判定された場合，前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と，
　を備え，
　
前記情報管理手段は，前記再認証手段により前記ユーザの再認証が成功した場合に，前記判定手段による判定対象となる端末情報として，前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ，
　前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置として機能させるプログラムを格納した記録媒体。
　　【請求項４】
　コンピュータを，
　端末装置より受信した
アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有する
，
該ヘッダ部に含まれ
　ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を，前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と，
　前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と，
　前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を，前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と，
　前記判定手段により前記符合しないと判定された場合，前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と，
　を備え，
　
前記情報管理手段は，前記再認証手段により前記ユーザの再認証が成功した場合に，前記判定手段による判定対象となる端末情報として，前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ，
　前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置として機能させるためのプログラム。」（以下，この特許請求の範囲に記載された請求項各項を「補正後の請求項」という。なお，下線は，補正箇所を示すものとして，請求人が付与したものである。）に補正するものである。
２．新規事項追加禁止要件
（１）平成２８年２月１２日付け手続補正によっても，補正前の請求項１の「前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置。」は補正されず，補正後の請求項１は「前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置」を依然として含むものであり，あたかも，「判定手段により前記符合すると判定された場合」と，「再認証手段により前記ユーザの再認証に成功した場合」とで同じ処理が行われるように特定している。
　しかしながら，本願の平成２５年８月２６日付け願書に最初に添付した明細書，特許請求の範囲又は図面（以下，「当初明細書等」という。）には，
「
第５の発明
判断手段によって正当なユーザでないと判断されたユーザが，判断手段によるユーザ確認と異なる確認方法によって正当なユーザであると判断されたことが通知された場合
ユーザの利用環境が特殊であるとみなし
所定の識別情報をユーザのユーザ識別情報と対応付けて記憶手段に各々記憶させる
記憶手段に所定の識別情報が記憶されているユーザについては
抽出されたアクセス元ＩＰアドレス
抽出されたユーザエージェント情報
　「上記のように，
ステップ４６で認証が「失敗」と判定されると
再認証要請メールが再度送信され
起動元の所定の処理モジュールへ認証失敗が再度通知される
　「
一方，ユーザ認証処理を行う処理モジュールは，再認証成功が通知されると，図７に示す使用履歴テーブル更新処理を行う。
取引停止フラグを０に戻す
特殊環境フラグに１を設定する
同一ユーザに対してユーザ認証処理が再度実行された場合
第５の発明
　「また，先のステップ４６で認証が「条件付き成功」と判定された場合はステップ６４へ移行し，・・・（後略）・・・」（段落【００７８】），及び，
　「また，ステップ６４の判定が肯定された場合，すなわち
再認証成功が通知されて使用履歴テーブル更新処理（図７）を行っている場合にはステップ６６へ移行し
ステップ６６の処理を行うとステップ５２へ移行し，起動元の所定の処理モジュールへ認証成功を通知
アクセス元ＩＰアドレス及びユーザエージェント情報の使用履歴情報への上書き登録・使用履歴テーブルへの使用履歴情報の書き戻しを行って
「・・・（前略）・・・
再認証が成功すれば
次回以降のアクセスでは通常ルートでの認証が行われる
「
」（図３）と記載されており，
　「判定手段」で認証に失敗すると，通常ルート（図３）での認証処理は，一旦，認証失敗を通知し，
　その後，「再認証手段により前記ユーザの再認証に成功した場合」には，取引停止を解除し，特殊環境である旨を識別する情報を記録して，同一ユーザに対してユーザ認証処理が再度実行された場合に，特殊環境であっても認証可能となる点が記載されているものの，
　「再認証手段」で成功した場合には，次回の通常ルート（図３）での「認証手段」及び「判定手段」の２回目の処理が必要な構成しか開示されておらず，ユーザの再認証に成功した場合に直ちにユーザが正当なユーザであると判定する態様を含むと読み取ることはできないから，当初明細書等には，再認証手段に成功した場合に判定手段で成功した場合と同様の処理をする構成は記載されていないといえる。
　よって，「前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置」が，当初明細書等中には記載されておらず，また，当初明細書等の記載から自明な事項でもない。
　以上のことから，本件補正は，当初明細書等の全ての記載を総合することにより導かれる技術的事項との関係において，新たな技術的事項を導入するものであるから，当初明細書等に記載した事項の範囲内においてしたものとは認められない。
（２）なお，平成２８年２月１２日付け意見書の（３−１−１）における請求人の主張についても，念のため以下に検討する。
ア．『処理に成功した場合と同様に正当なユーザとして判定されることは本願出願時の当業者の技術常識であり，また，この技術常識を踏まえて，例えば，本願の段落００７６における「再認証手続で正当なユーザであることが確認された場合，ユーザ認証処理を行う処理モジュールへ再認証成功が通知される」等の記載をみれば，「ユーザの再認証に成功した場合に直ちにユーザが正当なユーザであると判定する態様」についても十分読み取れる』である旨を主張している。
　ここで，当初明細書の段落【００７５】の「上記のように，ステップ４６で認証が「失敗」と判定されると取引停止フラグに１が設定されるので，同一ユーザに対してユーザ認証処理が再度実行された場合・・・（中略）・・・通常ルートでの認証（アクセス元ＩＰアドレス及びユーザエージェント情報に基づく認証）は行われず，再認証要請メールが再度送信され（ステップ６８），起動元の所定の処理モジュールへ認証失敗が再度通知される（ステップ７２）。」との記載，
　段落【００７７】の「一方，ユーザ認証処理を行う処理モジュールは，再認証成功が通知されると・・・（中略）・・・上記のように取引停止フラグを０に戻すことで，同一ユーザに対してユーザ認証処理が再度実行された場合に，ステップ４０の判定が否定されることで通常ルートでの認証が再開されることになる。」との記載，
　段落【００８１】の「再認証が成功すれば取引停止フラグが０に戻されるので，次回以降のアクセスでは通常ルートでの認証が行われることになる。」との記載からすると，
　当初明細書等における「再認証」（以下，「再認証１」という。）とは，認証が失敗すると，疑わしいユーザを，通常ルートでの認証を拒否する取引停止状態（いわゆるアカウントや口座ロック）にした上で，一旦認証失敗を通知し，最初の認証端末と同一とは限らないメール取得端末で実行される別のルートでの再認証により，取引停止状態を解除する効果も奏する技術の範疇に属するものである。
　一方，請求人が技術常識と主張する「再認証」（以下，「再認証２」という。）とは，認証が失敗すると，直ちに別の認証を行う場合を含むものであり，再認証１及び再認証２は，再認証関連技術において異なる技術の範疇に属するものである。
　また，請求人の主張の根拠である，当初明細書の段落【００７６】に記載の処理において，再認証手続で正当なユーザであることが確認された場合に通知されるのは，「認証成功」ではなく「再認証成功」であり，上記段落【００７７】の記載からすると，再認証の通知は，取引停止状態を解除して，通常ルートでの認証を可能にするものであると解される。
イ．また，請求人は，上記意見書において『本願明細書において「「再認証手段」で成功した場合には，次回の通常ルート（図３）での「認証手段」及び「判定手段」の２回目の処理が必要な構成」しか直接的に開示がなかったとしても，この構成は，本願発明の技術的思想の一部である再認証処理を実現するにあたって本願明細書において開示された一実施形態であって，この処理の態様に限定されるものではありません。また，このような２回目の処理を実行せずにユーザの再認証に成功した場合に直ちにユーザが正当なユーザであると判定する態様を積極的に除外する記載もありません』と主張するが，「再認証１」を「再認証２」で置換する際に，「再認証２」を積極的に除外する阻害要因が無く，当業者が容易になし得ることであったとしても，そのことをもって，「再認証２」が当初明細書等に記載した事項の範囲内と同然であるとまでは言うことはできない。
ウ．請求人は，上記意見書において『実施形態では「再認証手段」による再認証処理に到達したユーザであれば，ユーザＩＤとパスワードによる２回目の認証処理は成功する前提となり，また，ユーザエージェント情報を用いた判定も成功することになることから，実質的には，再認証処理に成功すれば正当なユーザとして判定されることになります。』と主張する。
　しかるに，補正後の請求項１の「端末情報」は「端末装置の使用に応じて変化する」情報と定義され，当初明細書の【発明が解決しようとする課題】の段落【０００７】において「アクセスの都度ＩＰアドレスが相違する。」と記載されていることからすると，補正後の請求項１に係る発明は，その前提において，１回目の認証時の端末情報と，２回目の認証時の端末情報が同一であることを何ら保証していない。
　そして，本願図面の図３を参照すると，ＩＰアドレス及びユーザエージェント情報による照合処理（ステップ４４）の結果が「認証ＮＧ」であれば，再認証の結果である「特殊環境フラグ」を参照せずに，すなわち，再認証の結果に影響されることなく，ステップ７２で「認証ＮＧ」が出力されている。
　また，端末情報が短期間では変更されないと仮定しても，段落【００６５】，【００７８】，【００７９】，図３の記載からすると，使用履歴テーブルの格納されたＩＰアドレス及びユーザエージェント情報の更新タイミング（ステップ５６，６０）は，ＩＰアドレス及びユーザエージェント情報による照合処理（ステップ４４）が終了した後であるから，再認証処理に成功した後の，２回目の認証における，使用履歴テーブルとパケットから抽出したＩＰアドレス及びユーザエージェント情報の照合処理（補正後の請求項１の判定手段に相当）の時点では，使用履歴テーブルは更新されておらず，再認証の結果は，使用履歴テーブルのＩＰアドレス及びユーザエージェント情報に影響しえない。
　そうすると，「実質的には，再認証処理に成功すれば正当なユーザとして判定される」構成が，当初明細書等に記載した事項の範囲内と同然であるとまでは言うことはできない。
エ．してみると，請求人の主張は，当初明細書等に明示的に記載されている「再認証１」を，別の認証方式である「再認証２」で置換するものであって，該主張をもってしても，「ユーザの再認証に成功した場合に直ちにユーザが正当なユーザであると判定する態様」が，当初明細書等に明示されていないものの記載されているのと同然である事項とまでは言うことはできない。
（３）新規事項追加禁止要件のむすび
　してみれば，補正後の請求項１が含む「前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置」は，当初明細書等に記載した事項の範囲内においてしたものでなく，また当初明細書等の記載からみて自明な事項でもない。
　また，補正後の請求項１の発明カテゴリを変更した補正後の請求項３，４についても同様のことがいえる。
　以上のことから，本件補正は，当初明細書等の全ての記載を総合することにより導かれる技術的事項との関係において，新たな技術的事項を導入するものであるから，当初明細書等に記載した事項の範囲内においてしたものとは認められず，本件補正は，特許法第１７条の２第３項の規定に違反するものである。
３．目的要件
　以上のように，本件補正は，特許法第１７条の２第３項の規定に違反するものの，仮に本件補正が，当初明細書等に記載した事項の範囲内で補正されたものとして，本件補正が，特許法第１７条の２第４項の規定を満たすものであるか否か，すなわち，本件補正が，特許法第１７条の２第４項に規定する請求項の削除，特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る），誤記の訂正，或いは，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る）の何れかを目的としたものであるかについて，以下に検討する。
（１）補正前の請求項と，補正後の請求項の対応関係
補正前の請求項と，補正後の請求項とを比較すると，意見書で請求人が説明するとおり，補正後の請求項１，２，３，４はそれぞれ，補正前の請求項１，４，５，６に対応する。
（２）補正事項
ア．補正後の請求項１，３，４に係る補正は，下記の補正事項１，２よりなるものである。
＜補正事項１＞
　補正前の請求項１，５，６の「端末装置より受信したパケットから，該パケットに含まれるユーザの識別情報，該ユーザの認証に必要な認証情報および前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段」との記載を，
　補正後の請求項１，３，４の「端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケットから，該パケットに含まれるユーザの識別情報，該ユーザの認証に必要な認証情報，および該ヘッダ部に含まれ前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段」に変更する補正。
＜補正事項２＞
　補正前の請求項１，５，６の「情報管理手段」を，
　補正後の請求項１，３，４の「前記情報管理手段は，前記再認証手段により前記ユーザの再認証が成功した場合に，前記判定手段による判定対象となる端末情報として，前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ」るように変更する補正。
イ．補正前の請求項２，３に係る補正は，下記の補正事項３よりなるものである。
＜補正事項３＞
　補正前の請求項２，３を削除する補正。
（３）補正事項についての判断
　上記補正事項１〜３について，以下のとおり検討する。
＜補正事項１について＞
　上記補正事項１は，「抽出手段」について，パケットが，アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有し，端末情報がヘッダ部に含まれるように限定して下位概念化する補正である。
　そして，これによって当該発明の産業上の利用分野及び解決しようとする課題が格別変更されるものではない。
　したがって，当該補正事項の目的は，請求項に記載した発明特定事項を限定するものであって，その補正前後の当該請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるもの（以下，単に「限定的減縮」という。）に該当する。
＜補正事項２について＞
　上記補正事項２は，「抽出手段によって抽出された端末情報を，前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段」について，「前記認証手段により前記ユーザの認証に成功した場合に」記憶させる事項を追加して下位概念化する補正である。
　そして，これによって当該発明の産業上の利用分野及び解決しようとする課題が格別変更されるものではない。
　したがって，当該補正事項の目的は，限定的減縮に該当する。
＜補正事項３について＞
　上記補正事項３の目的は，請求項の削除に該当する。
（４）したがって，上記補正事項１〜３は限定的減縮又は請求項の削除を目的とするものであり，本件補正の目的は，特許法第１７条の２第４項各号に掲げる目的に該当すると言えることから，特許法第１７条の２第４項の規定を満たすものである。
４．独立特許要件
　以上のように，本件補正の補正事項１，２は，限定的減縮を目的とするものであり，補正後の請求項１に記載された発明が，特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか否か，すなわち，補正後の請求項１に記載されている事項による特定される発明が，特許出願の際独立して特許を受けることができるものであるか否かについて以下に検討する。
４−１．特許法第３６条第６項第１号について
　補正後の請求項１は，「前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置」に関するものである。
　しかしながら，平成２６年７月２９日付け手続補正，平成２７年１０月３０日付け手続補正，平成２８年２月１２日付け手続補正は，いずれも特許請求の範囲のみを補正するものであり，本願の明細書及び図面は，当初明細書等と同一であるところ，上記「２．新規事項追加禁止要件」で検討したように発明の詳細な説明では，請求項１に記載された「ユーザ確認装置」に対応する事項が，記載も示唆もされていない。
　よって，補正後の請求項１に係る発明は，発明の詳細な説明に記載したものでなく，特許法第３６条第６項第１号に規定する要件を満たしていない。
４−２．特許法第３６条第６項第２号について
　補正後の請求項１に記載の「端末情報」なる用語は，一般的に端末が有している情報にとどまらず，端末に関連するあらゆる情報を意味していると解され，その具体的内容を特定しておらず，用語の示す範囲（外延）が明りょうでない。
　また，データをパケット中のいずれの領域に配置するかに格別の制限はなく，データをいずれの領域に配置するかは，当業者が適宜選択可能な設計的事項であり，該限定では，「端末情報」の種類等の具体的内容は何ら特定されていない。
　そして，本願明細書等を参照しても「端末情報」なる用語は定義されておらず，「端末装置の使用に応じて変化する情報」なる表現が，どの様な「使用」により，どのように「変化」する情報までを含むのか範囲が特定できない。
　例えば，本願明細書において「端末装置の使用に応じて変化する情報」として例示されるＩＰアドレスは，本願明細書の段落【０００７】に「アクセスの都度ＩＰアドレスが相違する」と記載されるように，高頻度で変化する情報である。
　一方，本願明細書で「端末装置の使用に応じて変化する情報」として例示される「ユーザエージェント情報」は，本願明細書の段落【００１１】に
「また，ユーザエージェント情報は，ＯＳやブラウザに新たなパッチが当てられたり，バージョンアップや入れ替えが行われれば内容が変更されるが，ＯＳやブラウザに新たなパッチを当てられたり，ＯＳやブラウザのバージョンアップや入れ替えが行われて内容が変更される頻度は非常に低いので，個々の端末装置から送信されるユーザエージェント情報はおよそ一定とみなすことができる。」と記載されるように，ほぼ変化しない情報である。
　してみれば，「端末装置の使用に応じて変化する情報」とは，アクセス毎に変化する短期情報から，ほぼ変化しない情報の長期情報までを網羅する，実質的には，少しでも変化する可能性のある，端末に関連する任意の情報一般を意味するものである。
　してみると，本願明細書等を参照しても「端末情報」の内容の範囲は実質的に定義されておらず，したがって，補正後の請求項１に係る発明は，特許を受けようとする発明の範囲が不明確であり，特許法第３６条第６項第２号に規定する要件を満たしていない。
　なお，請求人は，平成２８年２月１２日付け意見書において，
　「「端末情報」は１種類のみが特定される場合を含むことには誤りがありません」（４頁２行），
　「まず，本願発明１における「端末情報」は，端末装置の使用に応じて変化する情報であるため，ユーザ確認装置に端末装置がアクセスする度に変化する可能性のある情報です。そのため，ユーザの認証（認証手段）に成功した場合に行われる判定手段による判定は，符合するか否かが状況により変化します。」（４頁１２〜１５行），
　「この開示は，ユーザエージェント情報などの曖昧な情報を用いて，ＩＤとパスワードとを用いた認証（認証手段）に加えて，別の方法での判定をさらに行うという発明の技術的思想の一部を具現化するための一例として開示されているものであって」（４頁２６〜２８行）と主張しており，
　端末情報は，１種類のみであって，アクセスする度に変化する可能性のある情報，すなわち，ＩＰアドレスである場合の効果を主張しているにも関わらず，他方では，変更される頻度は非常に低くおよそ一定とみなすことができるユーザエージェント情報である場合をも含むと主張しており，全体として補正後の請求項１に記載の「端末情報」がどのような概念の情報と主張しているのか判然としない。
４−３．特許法第２９条第２項について
（１）本件補正発明
　本件補正発明は，上記平成２８年２月１２付け手続補正により補正された特許請求の範囲，明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
「端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケットから，該パケットに含まれるユーザの識別情報，該ユーザの認証に必要な認証情報，および該ヘッダ部に含まれ前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と，
　ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を，前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と，
　前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と，
　前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を，前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と，
　前記判定手段により前記符合しないと判定された場合，前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と，
　を備え，
　前記情報管理手段は，前記再認証手段により前記ユーザの再認証が成功した場合に，前記判定手段による判定対象となる端末情報として，前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ，
　前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置」
（２）引用文献
　原願の出願前に頒布され，上記平成２７年１２月１８日付けの当審の拒絶理由通知（以下，「当審拒絶理由」という。）において引用された，特開２００５−４４２７７号公報（平成１７年２月１７日出願公開，以下，「引用文献１」という。）には，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ａ．「【００１６】
　本発明の実施の形態について図面を参照しながら説明する。本発明の実施の形態に係る不正通信検出装置１は，図１に示すように，企業外ネットワーク（例えばインターネット；the Internet）２と，企業内ネットワーク３との間に接続されるもので，企業外ネットワーク２上の端末から，企業内ネットワーク３に接続されたコンピュータ等にアクセスするための通信経路上に設けられている。また企業外ネットワーク２には，外部利用者側端末２１を含む複数の情報処理装置が接続され，企業内ネットワーク３には，サーバ装置３１を含む情報処理装置が複数接続されている。
【００１７】
　また，
不正通信検出装置１は，制御部１１と，記憶部１２と，通信部１３とを含んで構成されている。
Ｂ．「【００２１】
　外部利用者端末２１は，一般的なパーソナルコンピュータで構わない。また，サーバ装置３１は，例えばウエブサーバであり，ＨＴＴＰ（Hyper Text Transfer Protocol）に基づく要求情報を受信すると，当該要求情報によって示された要求に従って，ファイル等を当該要求元に提供している。
また，サーバ装置３１は，ウエブサーバと協働するアプリケーションを動作させ，ウエブサーバが受信した要求情報に基づき，当該アプリケーションに動作を行わせて，その結果を提供するようにしても構わない。そしてここでは，サーバ装置３１がＨＴＴＰにおけるいわゆるベーシック認証によってユーザを認証するものとする。
【００２２】
　このようにサーバ装置３１がウエブサーバとして動作している場合は，
外部利用者端末２１は，ウエブブラウザを動作させて，サーバ装置３１に対してＨＴＴＰの要求情報（ＨＴＴＰリクエスト）を送信し，当該要求に応じた処理の結果等を受信することになる。またベーシック認証に関する情報として，ユーザを特定する情報（ユーザの認証に関する情報）を，ＨＴＴＰリクエストに含める。具体的には，そのリクエスト・ヘッダのオーソライゼーション（Authorization）フィールドに当該ユーザを特定する情報が含められる。
Ｃ．「【００２６】
　制御部１１は，記憶部１２に対し，例えば図３（ａ）に示すように，企業外ネットワーク２側から受け入れた一連のＨＴＴＰの要求情報（リクエスト・メッセージ）と，その受信日時の情報（制御部１１が図示しないカレンダー計時部から取得する）とを記録する。
ここでＨＴＴＰリクエストは，リクエスト・ラインとリクエスト・ヘッダとを含み，このリクエスト・ヘッダには，既に述べたように，Authorizationフィールドが含まれ，ここにユーザを識別するための情報が記録されている。
Ｄ．「【００４０】
［外部ノードからの通信条件を用いた不正通信基準ルール］
　
さらに，制御部１１において利用される不正通信基準ルールは，外部ノード（ここでは外部利用者端末２１）からの通信条件を用いて定められてもよい。このような条件としては，例えば外部利用者端末２１に割り当てられる可能性のあるＩＰアドレス
等がある。
【００４１】
　
このような不正通信基準ルールを用いる場合，例えばＩＰアドレスに関する条件を用いて定めた不正通信基準ルールであれば，ユーザを識別する情報（上記Authorizationフィールドに設定される情報）ごとに，予め利用される可能性のあるＩＰアドレスを列挙して，記憶部１２に格納しておき
企業外ネットワーク２側から受け入れたリクエストについて，そのソースＩＰアドレス情報（当該リクエストを生成した端末のＩＰアドレス）が，そのAuthorizationフィールドに設定される情報に関連づけて登録されているＩＰアドレス群に含まれているか否かを調べ，含まれていなければ，当該リクエストは，不正な通信であると判断する。
当該ユーザが外部利用者端末２１をネットワークに接続するために，当該ユーザの契約するＩＳＰにグローバルＩＰアドレスの提供を要求したときに，当該設定した範囲のＩＰアドレスのいずれかが割り当てられ（例えばＤＨＣＰ等によって割当がなされる）
【００４２】
　一方，
悪意のユーザが他のＩＳＰを利用するなどして通信を行おうとすると，たとえサーバ装置３１側でのユーザ認証を通過できたとしても
Ｅ．「【００４５】
　
またこれらの設定は，各ユーザが明示的に行うのではなく，制御部１１が過去の通信履歴に基づいて抽出することとしてもよい。例えば，制御部１１は，ユーザを識別する情報ごとに，当該ユーザが利用したＩＰアドレス（群）を抽出し，記憶部１２に履歴情報として記録しておく。そして企業外ネットワーク２側から受け入れたリクエストについて，そのソースＩＰアドレス情報が，そのAuthorizationフィールドに設定される情報に関連づけて履歴情報として記録されているＩＰアドレス群に含まれているか否かを調べ，含まれていなければ，当該リクエストは，不正な通信であると判断する。
【００４６】
　同様に，
アクセスの時間帯についても，ユーザを識別する情報ごとに，過去のアクセス時間帯の集計を履歴情報として記憶部１２に格納しておき
【００４７】
　
また，上記のＩＰアドレスは一例であって，それに代えて，当該ＩＰアドレスの一部（ネットワークアドレス部分）のみを用いてもよいし，デバイスごとに固有なＭＡＣアドレス等（イーサネット（登録商標）のアドレスなど）を用いてもよい。
Ｆ．「【００５３】
　具体的には制御部１１は，ＨＴＴＰリクエストのAuthorizationフィールドに含まれるべき情報（ユーザを特定する情報）について，それぞれ所定の連絡先の情報を関連づけて記憶部１２に保持しておき，
不正な通信として検出されたＨＴＴＰリクエスト（群）について，そのAuthorizationフィールドに含まれる情報を抽出し，当該情報に関連づけて保持されている連絡先の情報を取り出して，当該連絡先に対して不正な通信があった旨を報知する。
【００５４】
　
この連絡先及び報知の態様としては，例えば電子メールアドレスを連絡先とし，電子メールにて不正な通信があった旨を報知してもよい。
Ｇ．「【００５９】
［ユーザからのフィードバック］
　さらにこの対処処理部４４の処理としては，
ユーザや管理者等予め設定された通知先に対して不正な通信があったことを報知した後，当該連絡先から情報を受け入れたか否かに基づいて，またはその受け入れた情報の内容に基づいて上記仲介処理を停止するか否かを判断してもよい。
制御部１１は，
不正な通信が検出されたときに
通信継続の可否を問い合わせるためのウエブページを生成して保持しておく。そして，予め設定された通知先に対して不正の通信があった旨の報知を行うとともに，当該報知に，上記生成したウエブページのＵＲＬを含める。
【００６０】
　そして，図示しないタイマを用いて報知からの経過時間を監視し，一定の時間内に，通知先から，上記ＵＲＬへのアクセスがない場合に（ウエブサーバのログによってアクセスの有無を検出できる），仲介処理を停止する処理を行って，保護対象ノードであるサーバ装置３１への企業外ネットワーク２からの通信（の一部）を遮断する。
【００６１】
　なお，通知先からの応答は，このようなフィードバックの態様に限られるものではなく，例えばユーザに不正通信装置１が備える電話回線接続部（不図示）の電話番号を発呼させることとし，一定の時間が経過するまでに当該電話番号に着信がなかったときに仲介処理を停止する処理を行うこととしてもよい。
【００６２】
　さらに，通信継続の可否を問い合わせるためのフィードバックだけでなく，一旦通信が遮断されてしまったときに，当該通信の再開指示を受け入れるためのＵＲＬや電話番号を報知に含めてもよい。この場合，制御部１１は，当該再開指示を受け入れるＵＲＬへのアクセスがあったり，当該電話番号への着信があったときに，当該アクセスや電話番号の発呼を行ったユーザ（電話の場合，電話回線網側のサービスである発呼者番号通知を利用できる）を，記憶部１２の接続遮断対象ユーザから削除する。
【００６３】
　本実施の形態に係る不正通信検出装置１は，上記構成を備えており，次に述べるような動作を行う。すなわち，企業内ネットワーク３上の端末（不図示）から，サーバ装置３１へのＨＴＴＰリクエストについては，この不正通信検出装置１は，何ら関与しない。
【００６４】
　一方，企業外ネットワーク２上の端末，例えば
外部利用者側端末２１から企業内ネットワーク３へ入来する要求情報等については，ＨＴＴＰのベーシック認証のようなユーザ認証を行った上で
ユーザ認証情報によって特定されるユーザごとに，受け入れた要求情報を記録する。
Ｈ．「【００６８】
　また，正当なユーザが利用する外部利用者端末２１に割り当てられるＩＰアドレスが知られている場合や，ユーザのアクセス時間帯が予めわかっている場合は，事前にされた設定や，
過去の履歴に基づいて，外部利用者端末２１のネットワークアドレス（ＩＰアドレス等）があらかじめ登録されているものや，履歴として記録されているアドレスと異なる場合に不正な通信が行われたと判断する。
【００６９】
　
そして，不正通信検出装置１は，不正な通信が行われたと判断した場合に，当該不正な通信と判断された要求情報（群）に含まれるユーザ認証情報を抽出し，当該ユーザ認証情報に関連づけて予め設定されている連絡先に対して，不正な通信があったことを報知する。
一定の時間，当該連絡先から通信継続の可否に係る情報が受け入れられるか否かを監視し，受け入れられない場合は，当該ユーザ認証情報を含む要求情報の受け入れを停止する。
【００７０】
　
これにより，上記ベーシック認証などのユーザ認証を通過した悪意のユーザ（なりすましを行うユーザ）による不正な通信を効果的に検出して，これを阻止できる。
Ｉ．「【００７４】
　
また不正通信検出処理部４３が情報記録部４２によって記録された情報のうち，ユーザ認証を行った後の情報のみを対象として不正通信検出処理を行うようにしてもよい。
【００７５】
　
さらに，不正通信検出装置１は，ユーザ認証の結果に基づく処理を行うサーバ装置（上述の例でのサーバ装置３１）と一体の構成となっていてもよい。
　ここで，上記引用文献１に記載されている事項を検討する。
（ア）上記Ａの段落【００１７】の「不正通信検出装置１は，制御部１１と，記憶部１２と，通信部１３とを含んで構成されている。」との記載，
　上記Ｉの段落【００７５】の「さらに，不正通信検出装置１は，ユーザ認証の結果に基づく処理を行うサーバ装置（上述の例でのサーバ装置３１）と一体の構成となっていてもよい。」との記載，
　上記Ｂの段落【００２１】の「また，サーバ装置３１は，ウエブサーバと協働するアプリケーションを動作させ，ウエブサーバが受信した要求情報に基づき，当該アプリケーションに動作を行わせて，その結果を提供するようにしても構わない。そしてここでは，サーバ装置３１がＨＴＴＰにおけるいわゆるベーシック認証によってユーザを認証するものとする。」，段落【００２２】の「外部利用者端末２１は，ウエブブラウザを動作させて，サーバ装置３１に対してＨＴＴＰの要求情報（ＨＴＴＰリクエスト）を送信し，当該要求に応じた処理の結果等を受信することになる。またベーシック認証に関する情報として，ユーザを特定する情報（ユーザの認証に関する情報）を，ＨＴＴＰリクエストに含める。具体的には，そのリクエスト・ヘッダのオーソライゼーション（Authorization）フィールドに当該ユーザを特定する情報が含められる。」との記載，
　上記Ｃの段落【００２６】の「ここでＨＴＴＰリクエストは，リクエスト・ラインとリクエスト・ヘッダとを含み，このリクエスト・ヘッダには，既に述べたように，Authorizationフィールドが含まれ，ここにユーザを識別するための情報が記録されている。」との記載，
　上記Ｄの段落【００４２】の「悪意のユーザが他のＩＳＰを利用するなどして通信を行おうとすると，たとえサーバ装置３１側でのユーザ認証を通過できたとしても」との記載，
　上記Ｇの段落【００６４】の「外部利用者側端末２１から企業内ネットワーク３へ入来する要求情報等については，ＨＴＴＰのベーシック認証のようなユーザ認証を行った上で，」との記載からすると，
　引用文献１には，“制御部は，端末から，ベーシック認証に関する情報であるユーザを特定する情報を含むヘッダを含むＨＴＴＰリクエストが受信されると，最初に，ベーシック認証によって，ユーザ認証する不正通信検出装置”が記載されていると認められる。
（イ）上記Ｄの段落【００４０】の「さらに，制御部１１において利用される不正通信基準ルールは，外部ノード（ここでは外部利用者端末２１）からの通信条件を用いて定められてもよい。このような条件としては，例えば外部利用者端末２１に割り当てられる可能性のあるＩＰアドレス・・・（中略）・・・等がある。」，段落【００４１】の「このような不正通信基準ルールを用いる場合，例えばＩＰアドレスに関する条件を用いて定めた不正通信基準ルールであれば，ユーザを識別する情報（上記Authorizationフィールドに設定される情報）ごとに，予め利用される可能性のあるＩＰアドレスを列挙して，記憶部１２に格納しておき」，「当該ユーザが外部利用者端末２１をネットワークに接続するために，当該ユーザの契約するＩＳＰにグローバルＩＰアドレスの提供を要求したときに，当該設定した範囲のＩＰアドレスのいずれかが割り当てられ（例えばＤＨＣＰ等によって割当がなされる）」との記載，
　上記Ｅの段落【００４６】の「アクセスの時間帯についても，ユーザを識別する情報ごとに，過去のアクセス時間帯の集計を履歴情報として記憶部１２に格納しておき」，段落【００４７】の「また，上記のＩＰアドレスは一例であって，それに代えて，当該ＩＰアドレスの一部（ネットワークアドレス部分）のみを用いてもよいし，デバイスごとに固有なＭＡＣアドレス等（イーサネット（登録商標）のアドレスなど）を用いてもよい。」との記載からすると，
　引用文献１には，前記不正通信検出装置が，“制御部は，不正通信基準ルールとして，時間帯やＭＡＣアドレスを含む，ＤＨＣＰ等によって割当がなされるＩＰアドレス等を記憶部に格納”しておくことが記載されていると認められる。
（ウ）上記Ｅの段落【００４５】の「またこれらの設定は，各ユーザが明示的に行うのではなく，制御部１１が過去の通信履歴に基づいて抽出することとしてもよい。例えば，制御部１１は，ユーザを識別する情報ごとに，当該ユーザが利用したＩＰアドレス（群）を抽出し，記憶部１２に履歴情報として記録しておく。そして企業外ネットワーク２側から受け入れたリクエストについて，そのソースＩＰアドレス情報が，そのAuthorizationフィールドに設定される情報に関連づけて履歴情報として記録されているＩＰアドレス群に含まれているか否かを調べ，含まれていなければ，当該リクエストは，不正な通信であると判断する。」との記載，
　上記Ｇの【００６４】の「ＨＴＴＰのベーシック認証のようなユーザ認証を行った上で・・・（中略）・・・ユーザ認証情報によって特定されるユーザごとに，受け入れた要求情報を記録する。」との記載，及び，
　上記Ｂの段落【００２２】の「ユーザを特定する情報（ユーザの認証に関する情報）」との記載，及び，上記（イ）で検討した事項からすると，
　引用文献１には，前記不正通信検出装置が，“これらの設定はユーザが設定しなくても，ユーザを特定する情報ごとに，後でリクエストのソースＩＰアドレス等と照合するためのＩＰアドレス等を抽出して記憶部に履歴情報として記録”しておくことが記載されていると認められる。
（エ）上記Ｄの段落【００４１】の「企業外ネットワーク２側から受け入れたリクエストについて，そのソースＩＰアドレス情報（当該リクエストを生成した端末のＩＰアドレス）が，そのAuthorizationフィールドに設定される情報に関連づけて登録されているＩＰアドレス群に含まれているか否かを調べ，含まれていなければ，当該リクエストは，不正な通信であると判断する。」との記載，
　上記Ｈの段落【００６８】の「過去の履歴に基づいて，外部利用者端末２１のネットワークアドレス（ＩＰアドレス等）があらかじめ登録されているものや，履歴として記録されているアドレスと異なる場合に不正な通信が行われたと判断する。」との記載，
　段落【００７０】の「これにより，上記ベーシック認証などのユーザ認証を通過した悪意のユーザ（なりすましを行うユーザ）による不正な通信を効果的に検出して，これを阻止できる。」との記載，
　上記Ｉの段落【００７４】の「また不正通信検出処理部４３が情報記録部４２によって記録された情報のうち，ユーザ認証を行った後の情報のみを対象として不正通信検出処理を行うようにしてもよい。」との記載，及び，
　上記（ウ）で検討した事項からすると，
　引用文献１には，前記不正通信検出装置が，“制御部は，ユーザ認証が成功した後に，リクエストのソースＩＰアドレス等が，履歴として記録されているＩＰアドレス等の情報と異なる場合，不正と判断”することが記載されていると認められる。
（オ）上記Ｆの段落【００５３】の「不正な通信として検出されたＨＴＴＰリクエスト（群）について，そのAuthorizationフィールドに含まれる情報を抽出し，当該情報に関連づけて保持されている連絡先の情報を取り出して，当該連絡先に対して不正な通信があった旨を報知する。」，
　段落【００５４】の「この連絡先及び報知の態様としては，例えば電子メールアドレスを連絡先とし，電子メールにて不正な通信があった旨を報知してもよい。」との記載，
　上記Ｇの段落【００５９】の「制御部１１は・・・（中略）・・・不正な通信が検出されたときに・・・（中略）・・・通信継続の可否を問い合わせるためのウエブページを生成して保持しておく。そして，予め設定された通知先に対して不正の通信があった旨の報知を行うとともに，当該報知に，上記生成したウエブページのＵＲＬを含める。」との記載，
　上記Ｈの段落【００６９】の「そして，不正通信検出装置１は，不正な通信が行われたと判断した場合に，当該不正な通信と判断された要求情報（群）に含まれるユーザ認証情報を抽出し，当該ユーザ認証情報に関連づけて予め設定されている連絡先に対して，不正な通信があったことを報知する。」との記載，
　上記Ｂの段落【００２２】の「ユーザを特定する情報（ユーザの認証に関する情報）」との記載からすると，
　引用文献１には，前記不正通信検出装置が，“制御部は，不正と判断された場合には，ユーザを特定する情報に関連付けて予め設定されている連絡先のメールアドレスに，「通信継続の可否を問い合わせるためのウェブページ」のＵＲＬを含むメールを送信”することが記載されていると認められる。
（カ）上記Ｇの段落【００５９】の「ユーザや管理者等予め設定された通知先に対して不正な通信があったことを報知した後，当該連絡先から情報を受け入れたか否かに基づいて，またはその受け入れた情報の内容に基づいて上記仲介処理を停止するか否かを判断してもよい。」との記載，
　上記Ｈの段落【００６９】の「不正通信検出装置１は・・・（中略）・・・一定の時間，当該連絡先から通信継続の可否に係る情報が受け入れられるか否かを監視し，受け入れられない場合は，当該ユーザ認証情報を含む要求情報の受け入れを停止する。」との記載，及び，
　上記（ア）〜（オ）で検討した事項からすると，
　引用文献１には，前記不正通信検出装置が，“連絡先から受け取る「通信継続の可否に係る情報」に基づき，通信の可否を決定し，
　リクエストのソースＩＰアドレス等が，履歴として記録されているＩＰアドレス等の情報と一致する場合，又は，「通信継続の可否を問い合わせるためのウェブページ」からの「通信継続の可否に係る情報」により通信可能と決定した場合，処理は停止されない”ことが記載されていると認められる。
（キ）以上，（ア）〜（カ）で検討した事項を踏まえると，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
「制御部は，
　端末から，ベーシック認証に関する情報であるユーザを特定する情報を含むヘッダを含むＨＴＴＰリクエストが受信されると，最初に，ベーシック認証によって，ユーザ認証し，
　不正通信基準ルールとして，時間帯やＭＡＣアドレスを含む，ＤＨＣＰ等によって割当がなされるＩＰアドレス等を記憶部に格納しておき，
　これらの設定はユーザが設定しなくても，ユーザを特定する情報ごとに，後でリクエストのソースＩＰアドレス等と照合するためのＩＰアドレス等を抽出して記憶部に履歴情報として記録しておき，
　ユーザ認証が成功した後に，リクエストのソースＩＰアドレス等が，履歴として記録されているＩＰアドレス等の情報と異なる場合，不正と判断し，
　不正と判断された場合には，ユーザを特定する情報に関連付けて予め設定されている連絡先のメールアドレスに，「通信継続の可否を問い合わせるためのウェブページ」のＵＲＬを含むメールを送信し，
　連絡先から受け取る「通信継続の可否に係る情報」に基づき，通信の可否を決定し，
　リクエストのソースＩＰアドレス等が，履歴として記録されているＩＰアドレス等の情報と一致する場合，又は，「通信継続の可否を問い合わせるためのウェブページ」からの「通信継続の可否に係る情報」により通信可能と決定した場合，処理は停止されない
　不正通信検出装置。」
（３）参考文献
ア．当審拒絶理由で引用され，原願出願前に頒布された，特開２００４−１５８０２５号公報（平成１６年６月３日出願公開，以下，「参考文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｊ．「【００５１】
　
クライアント１０からサーバ１４にアクセスする場合
クライアント１０は，サーバ１４に対してユーザＩＤおよびパスワードを送信する。サーバ１４は，受信したユーザＩＤおよびパスワードと，ＨＤＤ１４ｄに格納されているユーザＩＤおよびパスワードと比較することにより，ユーザを認証するか否かを判定する
イ．当審拒絶理由で引用され，原願出願前に頒布された，特開２００４−２９５６３２号公報（平成１６年１０月２１日出願公開，以下，「参考文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｋ．「【００６３】
ステップＳ２５に続いてステップＳ２６に進み，セキュリティモジュールインタフェース手段１２が，認証手段１３に認証情報を出力すると，認証手段１３は，文書管理・認証サーバ２０に対して認証情報を送信することにより，ユーザの認証を要求する。
【００６４】
ステップＳ２６に続いてステップＳ２７に進み，認証手段１３は，文書管理・認証サーバ２０からの応答に基づいてユーザの認証が成功したか否かを判断する。ユーザの認証が成功した場合は，認証手段１３は，その旨を制御部１４に出力する。この場合は，ユーザは，文書管理・認証サーバ２０に対するアクセスが許可されたことになり，当該ユーザが有するアクセス権限の範囲で，文書管理ＤＢ２１の文書情報に対してアクセスが可能となる。
【００６５】
一方，
ユーザの認証が失敗した場合
再認証を行う旨が選択されるとステップＳ２３に進み，次の優先順位のセキュリティモジュール１１（ＢａｒＣｏｄｅ．ｄｌｌ）によって認証処理が行われる
ウ．当審拒絶理由で引用され，原願出願前に頒布された，特開２００５−３４６５９２号公報（平成１７年１２月５日出願公開，以下，「参考文献３」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｌ．「【請求項１】
　携帯電話機の携帯ブラウザを介して携帯サイトにアクセスする際の，前記携帯サイト側でのユーザーの認証に関する方法であって，
　前記ユーザー側では，前記携帯サイトのＵＲＬにアクセスしてログイン用のＩＤ及びパスワードを入力する初期アクセスと，前記携帯サイトからメール送信された認証用ＵＲＬにアクセスする認証用アクセスとを行い，
　前記携帯サイト側では，予め前記ユーザーの前記携帯電話機の携帯メールアドレスを管理者によってサーバーに登録するサーバ登録を行った後に，前記ユーザー側からの前記初期アクセスがあると，前記ＩＤ及び前記パスワードに基づいて前記ユーザーに対する一回目の認証を行うとともに，少なくとも
認証フラグ及び認証キーからなる文字列を組み込んだ前記認証用ＵＲＬを登録且つ前記ユーザーの前記携帯メールアドレスに送信する処理を行い，その後，前記ユーザー側からの前記認証用アクセスがあると，前記認証用ＵＲＬの前記文字列に基づいて前記ユーザーに対する二回目の認証を行う
　ことを特徴とする携帯サイト認証方法。
【請求項２】
　請求項１に記載の携帯サイト認証方法において，
　前記携帯サイト側では，前記認証フラグ及び前記認証キーを生成する際に，前記携帯ブラウザの情報及び／又は前記携帯電話機の機種の情報を生成してその登録をするとともに，前記二回目の認証の際に前記各情報を用いる
　ことを特徴とする携帯サイト認証方法。」
Ｍ．「【００２６】
　ステップＳ２７の処理では，
アクセスを行ったユーザーに対して認証用ＵＲＬを送信する処理が行われる。その送信は，ユーザーの携帯メールアドレスを宛先として行われる（認証用ＵＲＬは不正利用者の携帯電話機にメール送信されることはない）
・・・（中略）・・・
【００２９】
　ステップＳ３３の処理では，ステップＳ２７の処理で
メール送信した携帯ブラウザからのアクセスか否かを端末・ブラウザ情報登録エリア３０に登録された端末・ブラウザ情報に基づいて確認する処理が行われる。
・・・（中略）・・・
【００３２】
　以上，本発明によれば，ユーザーは，常に同じログイン用のＩＤ及びパスワードを用いるだけでよく，これにより忘れという問題点が解消される。また，
携帯サイト５側で二回の認証を行っていることから，常に同じログイン用のＩＤ及びパスワードを用いたとしても，携帯サイト５の安全性が低下することはない。
（４）対比
　本件補正発明と引用発明とを対比する。
ア．引用発明の「不正通信検出装置」は，ユーザを認証するサーバであるから，本件補正発明の「ユーザ確認装置」に対応するといえる。
イ．引用発明の「端末から，ベーシック認証に関する情報であるユーザを特定する情報を含むヘッダを含むＨＴＴＰリクエストが受信され」，「不正通信基準ルールとして，時間帯やＭＡＣアドレスを含む，ＤＨＣＰ等によって割当がなされるＩＰアドレス等を記憶部に格納しておき」，「これらの設定はユーザが設定しなくても，ユーザを識別する情報ごとに，後でリクエストのソースＩＰアドレス等と照合するためのＩＰアドレス等を抽出して記憶部に履歴情報として記録」しておく「制御部」と，
　本件補正発明の「端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケットから，該パケットに含まれるユーザの識別情報，該ユーザの認証に必要な認証情報，および該ヘッダ部に含まれ前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段」の両者を対比する。
　引用発明の「端末」は，認証されるユーザの端末であるから，本件補正発明の「端末装置」に相当する。
　引用発明の「ＤＨＣＰ等によって割当がなされるＩＰアドレス等」は，端末に係る情報であり，「ＤＨＣＰ等によって割当がなされるＩＰアドレス」が変化しうることは技術常識であるから，本件補正発明の「端末装置の使用に応じて変化する端末情報」に相当する。
　引用発明の「ユーザを特定する情報」は，本件補正発明の「ユーザの識別情報」及び「認証情報」と，「ユーザの認証に関する情報」である点で共通する。
　引用発明の「端末から，ベーシック認証に関する情報であるユーザを特定する情報を含むヘッダを含むＨＴＴＰリクエストが受信され」，「ＨＴＴＰリクエスト」と，本件補正発明の「アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケット」とは，いずれもヘッダを含むデータであり，本件補正発明の「ヘッダ部」とは，本願明細書の段落【００３６】の「アプリケーション層のプロトコルとしてＨＴＴＰが適用されて端末装置より受信したパケットから，当該パケットのＨＴＴＰヘッダに設定されているユーザエージェント情報全体を抽出する」との記載からすると，ＨＴＴＰヘッダを含むものであるから，端末より受信する「アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するデータ」である点で共通する。
　したがって，上記両者は，後記する点で相違するものの，
　“端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するデータから，該データに含まれるユーザの認証に関する情報，および，前記端末装置の使用に応じて変化する端末情報を抽出する抽出処理を行う手段”である点で共通しているといえる。
ウ．引用発明の「不正通信基準ルールとして，時間帯やＭＡＣアドレスを含む，ＤＨＣＰ等によって割当がなされるＩＰアドレス等を記憶部に格納しておき」，「これらの設定はユーザが設定しなくても，ユーザを識別する情報ごとに，後でリクエストのソースＩＰアドレス等と照合するためのＩＰアドレス等を抽出して記憶部に履歴情報として記憶部に記録」しておく「制御部」と，
　本件補正発明の「ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を，前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段」とは，
　上記イ．で検討した事項からすると，引用発明の「記憶部」は，ユーザの認証に関する情報と端末情報を記憶するものであり，本件補正発明の「記憶手段」に相当するから，
　後記する点で相違するものの，
　“ユーザの操作する前記端末装置より受信したデータから前記抽出処理によって抽出された端末情報と照合される端末情報を，前記ユーザのユーザの認証に関する情報と関連付けて記憶手段に記憶させる情報管理処理を行う手段”である点で共通しているといえる。
エ．引用発明の「端末から，ベーシック認証に関する情報であるユーザを特定する情報を含むヘッダを含むＨＴＴＰリクエストが受信されると，最初に，ベーシック認証によって，ユーザ認証」する「制御部」と，
　本件補正発明の「前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段」とは，
　上記イ．で検討したように引用発明の「ユーザを特定する情報（ユーザの認証に関する情報）」，「ユーザを識別する情報」は，本件補正発明の「ユーザの識別情報」及び「認証情報」と，「ユーザの認証に関する情報」である点で一致するから，
　後記する点で相違するものの，
　“前記抽出処理により抽出されたユーザの認証に関する情報に基づいて前記ユーザの認証処理を行う手段”である点で共通しているといえる。
オ．引用発明の「ユーザ認証が成功した後に，リクエストのソースＩＰアドレス等が，履歴として記録されているＩＰアドレス等の情報と異なる場合，不正と判断」する「制御部」と，
　本件補正発明の「前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を，前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段」とは，
　上記イ．〜エ．で検討した事項からすると，
　引用発明の「ＩＰアドレス等」は，本件補正発明の「端末情報」に相当し，
　引用発明の「異なる場合，不正と判断」することは，受信した端末情報と記録されている端末情報との比較による判定処理であって，本件補正発明の「符合するか否かを判定」することに相当するから，
　後記する点で相違するものの，
　“前記認証処理により前記ユーザの認証に成功した場合に前記抽出処理により抽出された端末情報を，前記ユーザのユーザの認証に関する情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定処理を行う手段”である点で共通しているといえる。
カ．引用発明の「不正と判断された場合には，ユーザを特定する情報に関連付けて予め設定されている連絡先のメールアドレスに，「通信継続の可否を問い合わせるためのウェブページ」のＵＲＬを含むメールを送信し，連絡先から受け取る「通信継続の可否に係る情報」に基づき，通信の可否を決定」する「制御部」と，
　本件補正発明の「前記判定手段により前記符合しないと判定された場合，前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段」の両者を対比する。
　引用発明の「不正と判断された場合」は，上記オ．で検討した事項からすると，受信した端末情報と記録されている端末情報が不一致の場合であるから，本件補正発明の「符合しないと判定された場合」に相当する。
　引用発明の「通信継続の可否に係る情報」は，ユーザ認証情報に関連付けて予め設定されている正当なユーザのメールアドレスに連絡して，正当なユーザからのリクエストであることを確認するための情報である。
　もし，ユーザ認証に成功しても，不正ユーザは，正当なユーザのメールアドレスからメールを受信できないのであるから，端末から「通信継続の可否に係る情報」を受信できた場合，正当なユーザの存在を確認できる。
　したがって，引用発明の「通信継続の可否を問い合わせるためのウェブページ」は，これにより正当なユーザであるか否かを確認する効果を奏するものと解することができるから，本件補正発明の「再認証手段」と，”ユーザの確認処理を行う手段”である点で一致する。
　したがって，上記両者は，後記する点で相違するものの，
　“前記判定処理により前記符合しないと判定された場合，前記認証処理による認証の方法および前記判定処理による判定の方法とは異なる方法により前記ユーザの確認処理を行う手段”である点で共通しているといえる。
キ．上記ウ．で検討したとおり，引用発明の「制御部」と本件補正発明の「情報管理手段」とは，“ユーザの操作する前記端末装置より受信したデータから前記抽出処理によって抽出された端末情報と照合される端末情報を，前記ユーザのユーザの認証に関する情報と関連付けて記憶手段に記憶させる情報管理処理を行う手段”である点で共通しているといえる。
　そして，引用発明の「制御部」は，「ユーザを特定する情報ごとに，後でリクエストのソースＩＰアドレス等と照合するためのＩＰアドレス等を抽出して記憶部に履歴情報として記録」するところ，
　「リクエストのソースＩＰアドレス等が，履歴として記録されているＩＰアドレス等の情報と異なる場合」であっても，『「通信継続の可否を問い合わせるためのウェブページ」からの「通信継続の可否に係る情報」により通信可能と決定した場合，処理は停止されない』ものであって，
　換言すれば，ＩＰアドレスと履歴情報による判定処理が失敗した場合であっても，「通信継続の可否を問い合わせるためのウェブページ」による再認証処理が成功した場合には，通信が阻止されずに発生するので，記憶部に，その通信の履歴情報が記録されることは明らかである。
　したがって，引用発明の「制御部」と本件補正発明の「情報管理手段」とは，後記する点で相違するものの，
　“前記情報管理処理を行う手段は，前記確認処理を行う手段により前記ユーザの確認が成功した場合に，前記判定処理を行う手段による判定対象となる端末情報として，前記抽出手段によって抽出された端末情報を前記ユーザのユーザの認証に関する情報と関連付けて前記記憶手段に記憶させ”るものである点で共通しているといえる。
ク．引用発明の「リクエストのソースＩＰアドレス等が，履歴として記録されているＩＰアドレス等の情報と一致する場合，又は，「通信継続の可否を問い合わせるためのウェブページ」からの「通信継続の可否に係る情報」により通信可能と決定した場合，処理は停止されない」ことと，
　本件補正発明の「前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定する」こととは，
　上記ア．〜キ．で検討した事項からすると，
“前記判定処理を行う手段により前記符合すると判定された場合，または，前記確認処理を行う手段により前記ユーザの確認に成功した場合に，該ユーザが正当なユーザであると判定する処理を実行する”ものである点で共通しているといえる。
　以上から，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
（一致点） 
「端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するデータから，該データに含まれるユーザの認証に関する情報，および，前記端末装置の使用に応じて変化する端末情報を抽出する抽出処理を行う手段と，
　ユーザの操作する前記端末装置より受信したデータから前記抽出処理によって抽出された端末情報と照合される端末情報を，前記ユーザのユーザの認証に関する情報と関連付けて記憶手段に記憶させる情報管理処理を行う手段と，
　前記抽出処理により抽出されたユーザの認証に関する情報に基づいて前記ユーザの認証処理を行う手段と，
　前記認証処理により前記ユーザの認証に成功した場合に前記抽出処理により抽出された端末情報を，前記ユーザのユーザの認証に関する情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定処理を行う手段と，
　前記判定処理により前記符合しないと判定された場合，前記認証処理による認証の方法および前記判定処理による判定の方法とは異なる方法により前記ユーザの確認処理を行う手段と
　を備え，
　前記情報管理処理を行う手段は，前記確認処理を行う手段により前記ユーザの確認が成功した場合に，前記判定処理を行う手段による判定対象となる端末情報として，前記抽出手段によって抽出された端末情報を前記ユーザのユーザの認証に関する情報と関連付けて前記記憶手段に記憶させ，
　前記判定処理を行う手段により前記符合すると判定された場合，または，前記確認処理を行う手段により前記ユーザの確認に成功した場合に，該ユーザが正当なユーザであると判定する処理を実行するユーザ確認装置。」
（相違点１）
　抽出処理に関して，
　本件補正発明では，パケットを受信するのに対して，
　引用発明では，パケット形式のリクエストを受信しない点。
（相違点２）
　抽出処理により抽出される端末情報に関して，
　本件補正発明では，「端末情報」がヘッダ部に含まれているのに対して，
　引用発明では，端末情報とヘッダ部の関係は特定されていない点。
（相違点３）
　ユーザの認証に関する情報と認証処理に関して，
　本件補正発明では，ユーザの認証に関する情報が，「ユーザの識別情報」及び「ユーザの認証に必要な認証情報」であって，認証情報が情報管理処理に記憶されているか否かを判定するのに対して，
　引用発明では，ユーザを特定する情報を含むヘッダを含むＨＴＴＰリクエストに基づいて，ベーシック認証しているものの，「ユーザの識別情報」及び「ユーザの認証に必要な認証情報」による認証方式が明示されていない点。
（相違点４）
　「抽出処理」，「記憶管理処理」，「認証処理」，「判定処理」，「再認証処理」の実現に関して，
　本件補正発明では，それぞれ別々の手段で実現されるのに対して，
　引用発明では，それらの各処理が「制御部」により実現される点。
（相違点５）
　判定処理により符合しないと判定された場合に関して，
　本件補正発明では，「認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う」のに対して，
　引用発明では，「通信継続の可否を問い合わせるためのウェブページ」による確認処理を実行するものの，前記確認処理がユーザ認証としての機能をも備えるのか明示されていない点。
（５）当審の判断
　上記相違点１〜５について検討する。
ア．相違点１について
　情報処理の技術分野において，インターネット上で通信されるデータのリクエストをパケット形式で構成することは，引用文献等を示すまでもなく，従来から当業者が必要に応じて採用する常とう手段であり，
　引用発明においても，リクエストをパケットで構成すること，すなわち，上記相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
イ．相違点２について
　情報処理の技術分野において，インターネット上で通信されるパケットのヘッダがＩＰアドレスを含むことは，技術常識であり，
　引用発明においても，ＩＰアドレス（端末情報）がヘッダ部に含まれるようにすること，すなわち，上記相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
ウ．相違点３について
　受信したユーザ識別情報及びパスワードが，記憶手段に記憶されているか否かを判定するユーザ認証方法は，例えば，参考文献１（上記Ｊ参照）に記載されているように，原願の出願前には，情報処理の技術分野において適宜に採用される周知技術であった。
　してみると，引用発明に上記周知技術を適用して，「認証処理」（ベーシック認証）において，ヘッダ部から抽出したユーザ識別情報及びパスワード（認証情報）が，情報管理手段に記憶されているか否かを判定するように構成すること，すなわち，上記相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
エ．相違点４について
　一連の情報処理を実現する際に，そのための所定の纏まりをもった機能実現手段の組合わせによって実現することは，情報処理の技術分野における常とう手段であるから，引用発明における抽出処理，情報管理処理，第１判定処理，第２判定処理及び第３判定処理の各処理の機能実現手段として「認証手段」，「記憶管理手段」，「判定手段」，「再認証手段」とを備えること，すなわち，上記相違点４に係る構成とすることは，当業者が容易に想到し得たことである。
オ．相違点５について
　参考文献３（上記Ｌ，Ｍ参照）には，認証方法の一態様として，サーバが，予め登録されたユーザのメールアドレスにＵＲＬ付きメールを送信して表示させ，その後，端末から応答アクセスを確認することで（二回目の認証と呼称）認証に対する信頼性を高める認証方法が記載されている。
　引用発明と，参考文献３記載の発明は，いずれも認証技術の分野に属し，いずれも，サーバが，予め登録されたユーザのメールアドレスへメールし，ユーザからの応答により後続処理の可否を制御する機能を備える発明であるから，
　引用発明のＩＰアドレス等による認証に失敗した後のメール処理に，参考文献３記載の発明を適用して，正規ユーザの登録メールアドレスにメールしてフィードバックがあるか否かを判定する確認処理を，ユーザ認証と呼称して用いること，すなわち，上記相違点５に係る構成とすることは，当業者が容易に想到し得たことである。
（６）請求人の主張について
　なお，平成２８年２月１２日付け意見書の請求人の主張について以下のとおり，検討する。
ア．請求人は，上記意見書の（３−４−１）において，『これらの記載によれば，引用発明１は，企業外ネットワーク２側から受け入れたリクエストにおける情報と比較される情報は，記憶部１２に格納されているものの，何らかの手法で過去のアクセス履歴を集計して得られたものであると思料いたします。そのため，引用発明１は，可能性の高いと考えられる範囲を事前に特定しておき，判定基準としています。すなわち，判定が成功となる範囲を事前にある程度の幅をもって決めておくという程度に過ぎません。』（７頁５〜１０行），
　『一方，引用発明１では，再帰的な処理をしていないため，通信継続の可否を問い合わせるためのウェブページが電子メールによって送信された場合，ユーザが通信継続を認めたとしても，再び同じ環境でアクセスをすれば，同じ電子メールが再度送信されることとなります。したがって，引用発明１では，管理者等が設定を変更しない限り，新しい環境からのアクセスについて，同じ電子メールが送信され続けることになります。』（７頁１６〜２０行）と主張する。
　しかるに，上記「（４）対比」のキ．で検討したように，引用発明においても，ＩＰアドレスと履歴情報による判定処理が失敗した場合であっても，「通信継続の可否を問い合わせるためのウェブページ」による確認処理が成功した場合には，通信が阻止されずに発生するので，記憶部に，その通信の履歴情報が記録されることは明らかである。
　また，引用文献１の上記Ｅの段落【００４５】の「またこれらの設定は，各ユーザが明示的に行うのではなく」，「制御部１１は，ユーザを識別する情報ごとに，当該ユーザが利用したＩＰアドレス（群）を抽出し，記憶部１２に履歴情報として記録しておく。」，「受け入れたリクエストについて，そのソースＩＰアドレス情報が，そのAuthorizationフィールドに設定される情報に関連づけて履歴情報として記録されているＩＰアドレス群に含まれているか否かを調べ」との記載からすると，
　引用発明は，自動的に記録されたＩＰアドレスの履歴情報を，直接調べて判定しており，ユーザが通信継続を認めた場合には，そのアクセスによるＩＰアドレスが履歴情報として記録され，次回の判定処理には反映されるといえる。
　したがって，「引用発明１では，管理者等が設定を変更しない限り，新しい環境からのアクセスについて，同じ電子メールが送信され続けることになります。」との主張は，失当である。
イ．また，請求人は，上記意見書の（３−４−１）において，『仮に認証処理の一態様であったとしても，これは電子メールが特定の宛先に送信されることによって「端末」を認証するものであって，「ユーザ」を認証するものではありません。このように引用発明１は，端末を認証する前提であるため，ユーザが保持していれば間接的に正当ユーザと認証したものと仮定することになりますが，不正ユーザがその端末を持っていればその不正ユーザも正当ユーザとして認証されることになります。』（７頁２５〜３０行）と主張する。
　しかるに，上記「（５）当審の判断」の「オ．相違点５について」の（イ）で検討したように，サーバからユーザの登録端末のメールアドレスへのメールとその応答による確認処理は，ユーザに対する認証と呼称することができるものであり（参考文献３（上記Ｌ，Ｍ）参照），このような，ユーザが，携帯電話やＩＣカードのような本人証明するためのハードウェアを保有しているか確認することによるユーザ認証方式は，認証技術の分野における常とう手段である。
ウ．ここで，上記相違点５に関して，仮に，引用発明の「通信継続の可否を問い合わせるためのウェブページ」による処理が，ユーザに対する認証と呼称されうる機能を含まないとした場合についても，一応検討する。
　所定の認証方法が失敗した際に，別の認証方法を実行して再認証する点は，例えば参考文献２（特に上記Ｋ参照）に記載されているように，原願の出願前には，認証技術分野において普通に採用される周知技術であった。
　引用発明の「ＩＰアドレス」による認証に，上記周知技術を適用して，ＩＰアドレス等による認証に失敗した際に，代替手段として別の認証方法，すなわち，再認証処理を実行するように構成することは，当業者が容易に想到し得たことである。
　なお，請求人は，上記意見書の（３−４−１）において，『引用発明１において引用文献３（上記参考文献２に相当）の構成を適用すると，引用発明１において最初のユーザの認証（ＩＤ・パスワードによる認証）が失敗した場合に別の認証方法によるユーザの認証が行われるという処理を追加することが，当業者によって想到される程度であると思料いたします。』と主張するが，最初の認証に失敗した場合には，他の認証方法を提供するが，第２の認証に失敗した場合は，他の認証方法を提供しないようにするような格別の事情もなく，引用発明に上記周知技術を適用する際に，引用発明の「ユーザを特定する情報」による認証に上記周知技術を適用するか，「ＩＰアドレス」による認証に上記周知技術を適用するか，両方の認証に上記周知技術を適用するかは，当業者が適宜選択可能な設計的事項にすぎない。
（７）小括
　上記で検討したごとく，上記各相違点に係る構成は当業者が容易に想到し得たものであり，そして，これらの相違点を総合的に勘案しても，本件補正発明の奏する作用効果は，上記引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本件補正発明は，上記引用発明及び当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。
４−４．独立特許要件のむすび
　したがって，補正後の請求項１の記載は，特許法第３６条第６項第１号，又は，特許法第３６条第６項第２号の規定を満たしておらず，しかも，本件補正発明は特許法第２９条第２項の規定により特許を受けることができないものであるから，補正後の請求項１に記載の発明は，独立して特許することができないものである。
５．補正却下のむすび
　以上のように，本件補正は，上記「２．新規事項追加禁止要件」で指摘したとおり，特許法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　また，仮に本件補正が，当初明細書等に記載した事項の範囲内で補正されたものであったとしても，上記「４．独立特許要件」で指摘したとおり，限定的減縮を目的とした補正後の請求項１が特許出願の際独立して特許を受けることができるものではないから，特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって，上記補正却下の決定の結論のとおり決定する。
第３　本願発明について
１．本願発明の認定
　平成２８年２月１２日付けの手続補正は上記のとおり却下されたので，補正後の請求項１に対応する補正前の請求項に係る発明（以下，「本願発明」という。）は，平成２７年１０月３０日付けの手続補正により補正された特許請求の範囲の請求項１に記載された事項により特定される，以下のとおりのものである。
「端末装置より受信したパケットから，該パケットに含まれるユーザの識別情報，該ユーザの認証に必要な認証情報および前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と，
　ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を，前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と，
　前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と，
　前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を，前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と，
　前記判定手段により前記符合しないと判定された場合，前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と，
　を備え，
　前記判定手段により前記符合すると判定された場合，または，前記再認証手段により前記ユーザの再認証に成功した場合に，該ユーザが正当なユーザであると判定するユーザ確認装置。」
２．引用文献
　引用発明は，前記「第２　平成２８年２月１２日付けの手続補正についての補正却下の決定」の「４．独立特許要件」の「４−３．　特許法第２９条第２項について」の「（２）引用文献」に記載したとおりである。
３．対比・判断
　本願発明は，前記「第２　平成２８年２月１２日付けの手続補正についての補正却下の決定」の「４．独立特許要件」の「４−３．　特許法第２９条第２項について」で検討した本件補正発明の
　「アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケット」から，「アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有」する点を削除し，
　「該ヘッダ部に含まれ前記端末装置の使用に応じて変化する端末情報」から，「該ヘッダ部に含まれ」る点を削除し，
　「前記再認証手段により前記ユーザの再認証が成功した場合に，前記判定手段による判定対象となる端末情報として，前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ」る「情報管理手段」から，「前記再認証手段により前記ユーザの再認証が成功した場合に，前記判定手段による判定対象となる端末情報として，前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ」る点を削除したものである。
　そうすると，本願発明の発明特定事項を全て含む本件補正発明が，前記「第２　平成２８年２月１２日付けの手続補正についての補正却下の決定」の「４．独立特許要件」の「４−３．　特許法第２９条第２項について」の「（２）引用文献」乃至「（５）当審の判断」に記載したとおり，引用発明及び当該技術分野の周知技術に基づいて当業者が容易に発明をすることができたものであるから，上記特定の限定を省いた本願発明も同様の理由により，引用発明及び当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものである。
４．特許法第１７条の２第３項，特許法第３６条第６項第１号及び第２号について
　本願発明の発明特定事項を全て含む本件補正発明は，前記「第２　平成２８年２月１２日付けの手続補正についての補正却下の決定」の「２．新規事項追加禁止要件」及び「４．独立特許要件」の「４−１．特許法第３６条第６項第１号について」，「４−２．　特許法第３６条第６項第２号について」に記載したとおり，当初明細書等に記載した事項の範囲内においてしたものではない事項を含み，発明の詳細な説明に記載したものでなく，特許を受けようとする発明の範囲が不明確である。
　そして，本件補正発明から上記特定の限定を削除しても，「２．新規事項追加禁止要件」，「４−１．特許法第３６条第６項第１号について」，「４−２．　特許法第３６条第６項第２号について」で指摘した記載は削除されておらず，本願発明は本件補正発明と同様の理由により，特許法第１７条の２第３項，特許法第３６条第６項第１号，又は，特許法第３６条第６項第２号に規定する要件を満たしていない。
５．むすび
　以上のとおり，本願の請求項１に係る発明は，特許法第１７条の２第３項，特許法第３６条第６項第１号，又は，特許法第３６条第６項第２号に規定する要件を満たしていない，又は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。
　よって，結論のとおり審決する。