• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1315586
審判番号 不服2015-119  
総通号数 199 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-07-29 
種別 拒絶査定不服の審決 
審判請求日 2015-01-05 
確定日 2016-06-09 
事件の表示 特願2013-174576「ユーザ確認装置、方法及びプログラム」拒絶査定不服審判事件〔平成25年12月12日出願公開、特開2013-251000〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯

本件審判請求に係る出願(以下,「本願」という。)は,
2006年3月29日を国際出願日とする特願2007-543641号(以下,「原願」という。)の一部を,
平成22年9月22日に新たな特許出願とした特願2010-212465号の一部をさらに,
平成23年2月4日に新たな特許出願とした特願2011-022895号の一部をさらに,
平成23年9月22日に新たな特許出願とした特願2011-208141号の一部をさらに,
平成24年5月18日に新たな特許出願とした特願2012-113987号の一部をさらに,
平成25年8月26日に新たな特許出願としたものであって,その手続の経緯の概略は以下のとおりである。

平成25年 8月27日 :出願審査請求書の提出
平成26年 5月30日付け:拒絶理由の通知
平成26年 7月29日 :意見書,手続補正書の提出
平成26年 9月30日付け:拒絶査定(同年10月7日謄本送達)
平成27年 1月 5日 :審判請求書の提出
平成27年 8月27日付け:拒絶理由の通知(当審),
平成27年10月16日 :面接
平成27年10月30日 :意見書,手続補正書の提出
平成27年12月18日付け:最後の拒絶理由の通知(当審)
平成28年 2月12日 :意見書,手続補正書の提出

第2 平成28年2月12日付けの手続補正についての補正却下の決定

[補正却下の決定の結論]

平成28年2月12日付けの手続補正を却下する。

[理由]

1.補正の内容

平成28年2月12日付けの手続補正(以下,「本件補正」という。)の内容は,平成27年10月30日付けの手続補正により補正された特許請求の範囲の請求項1?6の記載

「【請求項1】
端末装置より受信したパケットから,該パケットに含まれるユーザの識別情報,該ユーザの認証に必要な認証情報および前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と,
ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を,前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と,
前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と,
前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を,前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と,
前記判定手段により前記符合しないと判定された場合,前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と,
を備え,
前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置。
【請求項2】
前記端末情報は,複数種類のパラメータを含む請求項1に記載のユーザ確認装置。
【請求項3】
前記パケットは,インターネット層のプロトコルとしてIPが適用され,アプリケーション層のプロトコルとしてHTTPが適用されて,前記端末装置から受信され,
前記複数種類のパラメータは,少なくとも,前記端末装置のアクセス元IPアドレスおよびHTTPヘッダから抽出されるユーザーエージェント情報を含む請求項2に記載のユーザ確認装置。
【請求項4】
単一の前記ユーザ識別情報と関連付けて前記記憶手段に記憶された端末情報が複数である場合には,前記再認証手段は,前記抽出手段により抽出された端末情報が前記記憶手段に記憶されている前記複数の端末情報のいずれとも符合しないと前記判定手段に判定された場合に,前記再認証処理を行う,請求項1に記載のユーザ確認装置。
【請求項5】
コンピュータを,
端末装置より受信したパケットから,該パケットに含まれるユーザの識別情報,該ユーザの認証に必要な認証情報および前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と,
ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を,前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と,
前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と,
前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を,前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と,
前記判定手段により前記符合しないと判定された場合,前記認証手段による認証の方法
および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と,
を備え,
前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置として機能させるプログラムを格納した記録媒体。
【請求項6】
コンピュータを,
端末装置より受信したパケットから,該パケットに含まれるユーザの識別情報,該ユーザの認証に必要な認証情報および前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と,
ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を,前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と,
前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と,
前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を,前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と,
前記判定手段により前記符合しないと判定された場合,前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と,
を備え,
前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置として機能させるためのプログラム。」(以下,この特許請求の範囲に記載された請求項各項を「補正前の請求項」という。)を,

「【請求項1】
端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケットから,該パケットに含まれるユーザの識別情報,該ユーザの認証に必要な認証情報,および該ヘッダ部に含まれ前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と,
ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を,前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と,
前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と,
前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を,前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と,
前記判定手段により前記符合しないと判定された場合,前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と,
を備え,
前記情報管理手段は,前記再認証手段により前記ユーザの再認証が成功した場合に,前記判定手段による判定対象となる端末情報として,前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ,
前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置。
【請求項2】
単一の前記ユーザ識別情報と関連付けて前記記憶手段に記憶された端末情報が複数である場合には,前記再認証手段は,前記抽出手段により抽出された端末情報が前記記憶手段に記憶されている前記複数の端末情報のいずれとも符合しないと前記判定手段に判定された場合に,前記再認証処理を行う,請求項1に記載のユーザ確認装置。
【請求項3】
コンピュータを,
端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケットから,該パケットに含まれるユーザの識別情報,該ユーザの認証に必要な認証情報,および該ヘッダ部に含まれ前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と,
ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を,前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と,
前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と,
前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を,前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と,
前記判定手段により前記符合しないと判定された場合,前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と,
を備え,
前記情報管理手段は,前記再認証手段により前記ユーザの再認証が成功した場合に,前記判定手段による判定対象となる端末情報として,前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ,
前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置として機能させるプログラムを格納した記録媒体。
【請求項4】
コンピュータを,
端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケットから,該パケットに含まれるユーザの識別情報,該ユーザの認証に必要な認証情報,および該ヘッダ部に含まれ前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と,
ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を,前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と,
前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と,
前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を,前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と,
前記判定手段により前記符合しないと判定された場合,前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と,
を備え,
前記情報管理手段は,前記再認証手段により前記ユーザの再認証が成功した場合に,前記判定手段による判定対象となる端末情報として,前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ,
前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置として機能させるためのプログラム。」(以下,この特許請求の範囲に記載された請求項各項を「補正後の請求項」という。なお,下線は,補正箇所を示すものとして,請求人が付与したものである。)に補正するものである。

2.新規事項追加禁止要件

(1)平成28年2月12日付け手続補正によっても,補正前の請求項1の「前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置。」は補正されず,補正後の請求項1は「前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置」を依然として含むものであり,あたかも,「判定手段により前記符合すると判定された場合」と,「再認証手段により前記ユーザの再認証に成功した場合」とで同じ処理が行われるように特定している。

しかしながら,本願の平成25年8月26日付け願書に最初に添付した明細書,特許請求の範囲又は図面(以下,「当初明細書等」という。)には,
「第5の発明では,判断手段によって正当なユーザでないと判断されたユーザが,判断手段によるユーザ確認と異なる確認方法によって正当なユーザであると判断されたことが通知された場合,当該ユーザの利用環境が特殊であるとみなして,所定の識別情報をユーザのユーザ識別情報と対応付けて記憶手段に各々記憶させる。そして,記憶手段に所定の識別情報が記憶されているユーザについては,複数組のアクセス元IPアドレス及びユーザエージェント情報の中に,受信したパケットから抽出されたアクセス元IPアドレスと対応していると判定したアクセス元IPアドレス及びユーザエージェント情報全体の組が複数存在しているか,又は,受信したパケットから抽出されたユーザエージェント情報全体と対応していると判定したアクセス元IPアドレス及びユーザエージェント情報全体の組が複数存在している場合に,任意の端末装置を操作しているユーザが正当なユーザであると判断している。」(段落【0027】),及び,

「上記のように,ステップ46で認証が「失敗」と判定されると取引停止フラグに1が設定されるので,同一ユーザに対してユーザ認証処理が再度実行された場合,ステップ40の判定が肯定されてステップ70へ移行することで,通常ルートでの認証(アクセス元IPアドレス及びユーザエージェント情報に基づく認証)は行われず,再認証要請メールが再度送信され(ステップ68),起動元の所定の処理モジュールへ認証失敗が再度通知される(ステップ72)。」(段落【0075】),及び,

「一方,ユーザ認証処理を行う処理モジュールは,再認証成功が通知されると,図7に示す使用履歴テーブル更新処理を行う。すなわち,上記の再認証通知には,再認証手続きによって正当なユーザであることが確認されたユーザのユーザIDが情報として付加されており,まずステップ80では,正当なユーザであることが確認されたユーザのユーザIDを抽出・取得する。次のステップ82では,ステップ80で取得したユーザIDに対応する使用履歴情報を使用履歴テーブルから抽出し,抽出した使用履歴情報をメモリ12Bに記憶させる。またステップ84では,抽出した使用履歴情報のうち,取引停止フラグを0に戻すと共に,特殊環境フラグに1を設定する。そして,次のステップ86で使用履歴情報を使用履歴テーブルへ書き戻し,使用履歴テーブル更新処理を終了する。上記のように取引停止フラグを0に戻すことで,同一ユーザに対してユーザ認証処理が再度実行された場合に,ステップ40の判定が否定されることで通常ルートでの認証が再開されることになる。なお,ステップ84は第5の発明の情報管理手段に対応している。」(段落【0077】),及び,

「また,先のステップ46で認証が「条件付き成功」と判定された場合はステップ64へ移行し,・・・(後略)・・・」(段落【0078】),及び,

「また,ステップ64の判定が肯定された場合,すなわち再認証成功が通知されて使用履歴テーブル更新処理(図7)を行っている場合にはステップ66へ移行し,・・・(中略)・・・ステップ66の処理を行うとステップ52へ移行し,起動元の所定の処理モジュールへ認証成功を通知した後に,ステップ54以降で認証要求パケットから抽出されたアクセス元IPアドレス及びユーザエージェント情報の使用履歴情報への上書き登録・使用履歴テーブルへの使用履歴情報の書き戻しを行ってユーザ認証処理を終了する。」(段落【0079】),

「・・・(前略)・・・再認証が成功すれば取引停止フラグが0に戻されるので,次回以降のアクセスでは通常ルートでの認証が行われることになる。」(段落【0081】)(当審注:下線は,参考のために当審で付与したものである。),

「

」(図3)と記載されており,

「判定手段」で認証に失敗すると,通常ルート(図3)での認証処理は,一旦,認証失敗を通知し,
その後,「再認証手段により前記ユーザの再認証に成功した場合」には,取引停止を解除し,特殊環境である旨を識別する情報を記録して,同一ユーザに対してユーザ認証処理が再度実行された場合に,特殊環境であっても認証可能となる点が記載されているものの,
「再認証手段」で成功した場合には,次回の通常ルート(図3)での「認証手段」及び「判定手段」の2回目の処理が必要な構成しか開示されておらず,ユーザの再認証に成功した場合に直ちにユーザが正当なユーザであると判定する態様を含むと読み取ることはできないから,当初明細書等には,再認証手段に成功した場合に判定手段で成功した場合と同様の処理をする構成は記載されていないといえる。

よって,「前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置」が,当初明細書等中には記載されておらず,また,当初明細書等の記載から自明な事項でもない。
以上のことから,本件補正は,当初明細書等の全ての記載を総合することにより導かれる技術的事項との関係において,新たな技術的事項を導入するものであるから,当初明細書等に記載した事項の範囲内においてしたものとは認められない。

(2)なお,平成28年2月12日付け意見書の(3-1-1)における請求人の主張についても,念のため以下に検討する。

ア.『処理に成功した場合と同様に正当なユーザとして判定されることは本願出願時の当業者の技術常識であり,また,この技術常識を踏まえて,例えば,本願の段落0076における「再認証手続で正当なユーザであることが確認された場合,ユーザ認証処理を行う処理モジュールへ再認証成功が通知される」等の記載をみれば,「ユーザの再認証に成功した場合に直ちにユーザが正当なユーザであると判定する態様」についても十分読み取れる』である旨を主張している。

ここで,当初明細書の段落【0075】の「上記のように,ステップ46で認証が「失敗」と判定されると取引停止フラグに1が設定されるので,同一ユーザに対してユーザ認証処理が再度実行された場合・・・(中略)・・・通常ルートでの認証(アクセス元IPアドレス及びユーザエージェント情報に基づく認証)は行われず,再認証要請メールが再度送信され(ステップ68),起動元の所定の処理モジュールへ認証失敗が再度通知される(ステップ72)。」との記載,
段落【0077】の「一方,ユーザ認証処理を行う処理モジュールは,再認証成功が通知されると・・・(中略)・・・上記のように取引停止フラグを0に戻すことで,同一ユーザに対してユーザ認証処理が再度実行された場合に,ステップ40の判定が否定されることで通常ルートでの認証が再開されることになる。」との記載,
段落【0081】の「再認証が成功すれば取引停止フラグが0に戻されるので,次回以降のアクセスでは通常ルートでの認証が行われることになる。」との記載からすると,
当初明細書等における「再認証」(以下,「再認証1」という。)とは,認証が失敗すると,疑わしいユーザを,通常ルートでの認証を拒否する取引停止状態(いわゆるアカウントや口座ロック)にした上で,一旦認証失敗を通知し,最初の認証端末と同一とは限らないメール取得端末で実行される別のルートでの再認証により,取引停止状態を解除する効果も奏する技術の範疇に属するものである。

一方,請求人が技術常識と主張する「再認証」(以下,「再認証2」という。)とは,認証が失敗すると,直ちに別の認証を行う場合を含むものであり,再認証1及び再認証2は,再認証関連技術において異なる技術の範疇に属するものである。

また,請求人の主張の根拠である,当初明細書の段落【0076】に記載の処理において,再認証手続で正当なユーザであることが確認された場合に通知されるのは,「認証成功」ではなく「再認証成功」であり,上記段落【0077】の記載からすると,再認証の通知は,取引停止状態を解除して,通常ルートでの認証を可能にするものであると解される。

イ.また,請求人は,上記意見書において『本願明細書において「「再認証手段」で成功した場合には,次回の通常ルート(図3)での「認証手段」及び「判定手段」の2回目の処理が必要な構成」しか直接的に開示がなかったとしても,この構成は,本願発明の技術的思想の一部である再認証処理を実現するにあたって本願明細書において開示された一実施形態であって,この処理の態様に限定されるものではありません。また,このような2回目の処理を実行せずにユーザの再認証に成功した場合に直ちにユーザが正当なユーザであると判定する態様を積極的に除外する記載もありません』と主張するが,「再認証1」を「再認証2」で置換する際に,「再認証2」を積極的に除外する阻害要因が無く,当業者が容易になし得ることであったとしても,そのことをもって,「再認証2」が当初明細書等に記載した事項の範囲内と同然であるとまでは言うことはできない。

ウ.請求人は,上記意見書において『実施形態では「再認証手段」による再認証処理に到達したユーザであれば,ユーザIDとパスワードによる2回目の認証処理は成功する前提となり,また,ユーザエージェント情報を用いた判定も成功することになることから,実質的には,再認証処理に成功すれば正当なユーザとして判定されることになります。』と主張する。
しかるに,補正後の請求項1の「端末情報」は「端末装置の使用に応じて変化する」情報と定義され,当初明細書の【発明が解決しようとする課題】の段落【0007】において「アクセスの都度IPアドレスが相違する。」と記載されていることからすると,補正後の請求項1に係る発明は,その前提において,1回目の認証時の端末情報と,2回目の認証時の端末情報が同一であることを何ら保証していない。
そして,本願図面の図3を参照すると,IPアドレス及びユーザエージェント情報による照合処理(ステップ44)の結果が「認証NG」であれば,再認証の結果である「特殊環境フラグ」を参照せずに,すなわち,再認証の結果に影響されることなく,ステップ72で「認証NG」が出力されている。

また,端末情報が短期間では変更されないと仮定しても,段落【0065】,【0078】,【0079】,図3の記載からすると,使用履歴テーブルの格納されたIPアドレス及びユーザエージェント情報の更新タイミング(ステップ56,60)は,IPアドレス及びユーザエージェント情報による照合処理(ステップ44)が終了した後であるから,再認証処理に成功した後の,2回目の認証における,使用履歴テーブルとパケットから抽出したIPアドレス及びユーザエージェント情報の照合処理(補正後の請求項1の判定手段に相当)の時点では,使用履歴テーブルは更新されておらず,再認証の結果は,使用履歴テーブルのIPアドレス及びユーザエージェント情報に影響しえない。
そうすると,「実質的には,再認証処理に成功すれば正当なユーザとして判定される」構成が,当初明細書等に記載した事項の範囲内と同然であるとまでは言うことはできない。

エ.してみると,請求人の主張は,当初明細書等に明示的に記載されている「再認証1」を,別の認証方式である「再認証2」で置換するものであって,該主張をもってしても,「ユーザの再認証に成功した場合に直ちにユーザが正当なユーザであると判定する態様」が,当初明細書等に明示されていないものの記載されているのと同然である事項とまでは言うことはできない。

(3)新規事項追加禁止要件のむすび

してみれば,補正後の請求項1が含む「前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置」は,当初明細書等に記載した事項の範囲内においてしたものでなく,また当初明細書等の記載からみて自明な事項でもない。
また,補正後の請求項1の発明カテゴリを変更した補正後の請求項3,4についても同様のことがいえる。
以上のことから,本件補正は,当初明細書等の全ての記載を総合することにより導かれる技術的事項との関係において,新たな技術的事項を導入するものであるから,当初明細書等に記載した事項の範囲内においてしたものとは認められず,本件補正は,特許法第17条の2第3項の規定に違反するものである。

3.目的要件

以上のように,本件補正は,特許法第17条の2第3項の規定に違反するものの,仮に本件補正が,当初明細書等に記載した事項の範囲内で補正されたものとして,本件補正が,特許法第17条の2第4項の規定を満たすものであるか否か,すなわち,本件補正が,特許法第17条の2第4項に規定する請求項の削除,特許請求の範囲の減縮(特許法第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る),誤記の訂正,或いは,明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る)の何れかを目的としたものであるかについて,以下に検討する。

(1)補正前の請求項と,補正後の請求項の対応関係

補正前の請求項と,補正後の請求項とを比較すると,意見書で請求人が説明するとおり,補正後の請求項1,2,3,4はそれぞれ,補正前の請求項1,4,5,6に対応する。

(2)補正事項

ア.補正後の請求項1,3,4に係る補正は,下記の補正事項1,2よりなるものである。
＜補正事項1＞
補正前の請求項1,5,6の「端末装置より受信したパケットから,該パケットに含まれるユーザの識別情報,該ユーザの認証に必要な認証情報および前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段」との記載を,
補正後の請求項1,3,4の「端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケットから,該パケットに含まれるユーザの識別情報,該ユーザの認証に必要な認証情報,および該ヘッダ部に含まれ前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段」に変更する補正。
＜補正事項2＞
補正前の請求項1,5,6の「情報管理手段」を,
補正後の請求項1,3,4の「前記情報管理手段は,前記再認証手段により前記ユーザの再認証が成功した場合に,前記判定手段による判定対象となる端末情報として,前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ」るように変更する補正。

イ.補正前の請求項2,3に係る補正は,下記の補正事項3よりなるものである。
＜補正事項3＞
補正前の請求項2,3を削除する補正。

(3)補正事項についての判断

上記補正事項1?3について,以下のとおり検討する。

＜補正事項1について＞
上記補正事項1は,「抽出手段」について,パケットが,アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有し,端末情報がヘッダ部に含まれるように限定して下位概念化する補正である。
そして,これによって当該発明の産業上の利用分野及び解決しようとする課題が格別変更されるものではない。
したがって,当該補正事項の目的は,請求項に記載した発明特定事項を限定するものであって,その補正前後の当該請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるもの(以下,単に「限定的減縮」という。)に該当する。

＜補正事項2について＞
上記補正事項2は,「抽出手段によって抽出された端末情報を,前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段」について,「前記認証手段により前記ユーザの認証に成功した場合に」記憶させる事項を追加して下位概念化する補正である。
そして,これによって当該発明の産業上の利用分野及び解決しようとする課題が格別変更されるものではない。
したがって,当該補正事項の目的は,限定的減縮に該当する。

＜補正事項3について＞
上記補正事項3の目的は,請求項の削除に該当する。

(4)したがって,上記補正事項1?3は限定的減縮又は請求項の削除を目的とするものであり,本件補正の目的は,特許法第17条の2第4項各号に掲げる目的に該当すると言えることから,特許法第17条の2第4項の規定を満たすものである。

4.独立特許要件

以上のように,本件補正の補正事項1,2は,限定的減縮を目的とするものであり,補正後の請求項1に記載された発明が,特許法第17条の2第5項において準用する同法第126条第5項の規定に適合するか否か,すなわち,補正後の請求項1に記載されている事項による特定される発明が,特許出願の際独立して特許を受けることができるものであるか否かについて以下に検討する。

4-1.特許法第36条第6項第1号について

補正後の請求項1は,「前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置」に関するものである。

しかしながら,平成26年7月29日付け手続補正,平成27年10月30日付け手続補正,平成28年2月12日付け手続補正は,いずれも特許請求の範囲のみを補正するものであり,本願の明細書及び図面は,当初明細書等と同一であるところ,上記「2.新規事項追加禁止要件」で検討したように発明の詳細な説明では,請求項1に記載された「ユーザ確認装置」に対応する事項が,記載も示唆もされていない。
よって,補正後の請求項1に係る発明は,発明の詳細な説明に記載したものでなく,特許法第36条第6項第1号に規定する要件を満たしていない。

4-2.特許法第36条第6項第2号について

補正後の請求項1に記載の「端末情報」なる用語は,一般的に端末が有している情報にとどまらず,端末に関連するあらゆる情報を意味していると解され,その具体的内容を特定しておらず,用語の示す範囲(外延)が明りょうでない。
また,データをパケット中のいずれの領域に配置するかに格別の制限はなく,データをいずれの領域に配置するかは,当業者が適宜選択可能な設計的事項であり,該限定では,「端末情報」の種類等の具体的内容は何ら特定されていない。

そして,本願明細書等を参照しても「端末情報」なる用語は定義されておらず,「端末装置の使用に応じて変化する情報」なる表現が,どの様な「使用」により,どのように「変化」する情報までを含むのか範囲が特定できない。
例えば,本願明細書において「端末装置の使用に応じて変化する情報」として例示されるIPアドレスは,本願明細書の段落【0007】に「アクセスの都度IPアドレスが相違する」と記載されるように,高頻度で変化する情報である。
一方,本願明細書で「端末装置の使用に応じて変化する情報」として例示される「ユーザエージェント情報」は,本願明細書の段落【0011】に
「また,ユーザエージェント情報は,OSやブラウザに新たなパッチが当てられたり,バージョンアップや入れ替えが行われれば内容が変更されるが,OSやブラウザに新たなパッチを当てられたり,OSやブラウザのバージョンアップや入れ替えが行われて内容が変更される頻度は非常に低いので,個々の端末装置から送信されるユーザエージェント情報はおよそ一定とみなすことができる。」と記載されるように,ほぼ変化しない情報である。
してみれば,「端末装置の使用に応じて変化する情報」とは,アクセス毎に変化する短期情報から,ほぼ変化しない情報の長期情報までを網羅する,実質的には,少しでも変化する可能性のある,端末に関連する任意の情報一般を意味するものである。
してみると,本願明細書等を参照しても「端末情報」の内容の範囲は実質的に定義されておらず,したがって,補正後の請求項1に係る発明は,特許を受けようとする発明の範囲が不明確であり,特許法第36条第6項第2号に規定する要件を満たしていない。

なお,請求人は,平成28年2月12日付け意見書において,
「「端末情報」は1種類のみが特定される場合を含むことには誤りがありません」(4頁2行),
「まず,本願発明1における「端末情報」は,端末装置の使用に応じて変化する情報であるため,ユーザ確認装置に端末装置がアクセスする度に変化する可能性のある情報です。そのため,ユーザの認証(認証手段)に成功した場合に行われる判定手段による判定は,符合するか否かが状況により変化します。」(4頁12?15行),
「この開示は,ユーザエージェント情報などの曖昧な情報を用いて,IDとパスワードとを用いた認証(認証手段)に加えて,別の方法での判定をさらに行うという発明の技術的思想の一部を具現化するための一例として開示されているものであって」(4頁26?28行)と主張しており,
端末情報は,1種類のみであって,アクセスする度に変化する可能性のある情報,すなわち,IPアドレスである場合の効果を主張しているにも関わらず,他方では,変更される頻度は非常に低くおよそ一定とみなすことができるユーザエージェント情報である場合をも含むと主張しており,全体として補正後の請求項1に記載の「端末情報」がどのような概念の情報と主張しているのか判然としない。

4-3.特許法第29条第2項について

(1)本件補正発明

本件補正発明は,上記平成28年2月12付け手続補正により補正された特許請求の範囲,明細書及び図面の記載からみて,その特許請求の範囲の請求項1に記載された以下のとおりのものと認める。

「端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケットから,該パケットに含まれるユーザの識別情報,該ユーザの認証に必要な認証情報,および該ヘッダ部に含まれ前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と,
ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を,前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と,
前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と,
前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を,前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と,
前記判定手段により前記符合しないと判定された場合,前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と,
を備え,
前記情報管理手段は,前記再認証手段により前記ユーザの再認証が成功した場合に,前記判定手段による判定対象となる端末情報として,前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ,
前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置」

(2)引用文献

原願の出願前に頒布され,上記平成27年12月18日付けの当審の拒絶理由通知(以下,「当審拒絶理由」という。)において引用された,特開2005-44277号公報(平成17年2月17日出願公開,以下,「引用文献1」という。)には,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

A.「【0016】
本発明の実施の形態について図面を参照しながら説明する。本発明の実施の形態に係る不正通信検出装置1は,図1に示すように,企業外ネットワーク(例えばインターネット;the Internet)2と,企業内ネットワーク3との間に接続されるもので,企業外ネットワーク2上の端末から,企業内ネットワーク3に接続されたコンピュータ等にアクセスするための通信経路上に設けられている。また企業外ネットワーク2には,外部利用者側端末21を含む複数の情報処理装置が接続され,企業内ネットワーク3には,サーバ装置31を含む情報処理装置が複数接続されている。
【0017】
また,不正通信検出装置1は,制御部11と,記憶部12と,通信部13とを含んで構成されている。ここで制御部11は,記憶部12に格納されているプログラムに従って動作しており,企業内ネットワーク3上の情報処理装置宛ての情報を,企業外ネットワーク2から受信して,企業内ネットワーク3へ送出し,また,企業内ネットワーク3上の情報処理装置から企業外ネットワーク2上の情報処理装置宛の情報を受信し,企業外ネットワーク2へ送出する処理(仲介処理)を行っている。」

B.「【0021】
外部利用者端末21は,一般的なパーソナルコンピュータで構わない。また,サーバ装置31は,例えばウエブサーバであり,HTTP(Hyper Text Transfer Protocol)に基づく要求情報を受信すると,当該要求情報によって示された要求に従って,ファイル等を当該要求元に提供している。また,サーバ装置31は,ウエブサーバと協働するアプリケーションを動作させ,ウエブサーバが受信した要求情報に基づき,当該アプリケーションに動作を行わせて,その結果を提供するようにしても構わない。そしてここでは,サーバ装置31がHTTPにおけるいわゆるベーシック認証によってユーザを認証するものとする。
【0022】
このようにサーバ装置31がウエブサーバとして動作している場合は,外部利用者端末21は,ウエブブラウザを動作させて,サーバ装置31に対してHTTPの要求情報(HTTPリクエスト)を送信し,当該要求に応じた処理の結果等を受信することになる。またベーシック認証に関する情報として,ユーザを特定する情報(ユーザの認証に関する情報)を,HTTPリクエストに含める。具体的には,そのリクエスト・ヘッダのオーソライゼーション(Authorization)フィールドに当該ユーザを特定する情報が含められる。」

C.「【0026】
制御部11は,記憶部12に対し,例えば図3(a)に示すように,企業外ネットワーク2側から受け入れた一連のHTTPの要求情報(リクエスト・メッセージ)と,その受信日時の情報(制御部11が図示しないカレンダー計時部から取得する)とを記録する。ここでHTTPリクエストは,リクエスト・ラインとリクエスト・ヘッダとを含み,このリクエスト・ヘッダには,既に述べたように,Authorizationフィールドが含まれ,ここにユーザを識別するための情報が記録されている。なお,HTTPの仕様は,例えばRFC2616(Request for Comments 2616),「Hypertext Transfer Protocol -- HTTP/1.1 」に詳細が記載されている。」

D.「【0040】
[外部ノードからの通信条件を用いた不正通信基準ルール]
さらに,制御部11において利用される不正通信基準ルールは,外部ノード(ここでは外部利用者端末21)からの通信条件を用いて定められてもよい。このような条件としては,例えば外部利用者端末21に割り当てられる可能性のあるIPアドレスや,外部利用者端末21からの通信が行われるべき時間帯,通信を行っている時間等がある。
【0041】
このような不正通信基準ルールを用いる場合,例えばIPアドレスに関する条件を用いて定めた不正通信基準ルールであれば,ユーザを識別する情報(上記Authorizationフィールドに設定される情報)ごとに,予め利用される可能性のあるIPアドレスを列挙して,記憶部12に格納しておき,企業外ネットワーク2側から受け入れたリクエストについて,そのソースIPアドレス情報(当該リクエストを生成した端末のIPアドレス)が,そのAuthorizationフィールドに設定される情報に関連づけて登録されているIPアドレス群に含まれているか否かを調べ,含まれていなければ,当該リクエストは,不正な通信であると判断する。具体的には,企業内にあるサーバ装置31に対して,企業外ネットワーク2を介してアクセスする正当な権限を有するユーザは,予め,例えば自己が契約しているインターネットサービスプロバイダ(ISP)が当該ユーザの利用する外部利用者端末21に対して割り当てる可能性のあるIPアドレスの範囲を記憶部12に設定しておく。このようにすると,当該ユーザが外部利用者端末21をネットワークに接続するために,当該ユーザの契約するISPにグローバルIPアドレスの提供を要求したときに,当該設定した範囲のIPアドレスのいずれかが割り当てられ(例えばDHCP等によって割当がなされる),当該割り当てられたIPアドレスからのリクエストとして,制御部11に受け入れられるので,正当な通信として扱われる。
【0042】
一方,悪意のユーザが他のISPを利用するなどして通信を行おうとすると,たとえサーバ装置31側でのユーザ認証を通過できたとしても,制御部11が当該IPアドレスが登録されていないものであることを検出するので,不正な通信として扱われることになる。」

E.「【0045】
またこれらの設定は,各ユーザが明示的に行うのではなく,制御部11が過去の通信履歴に基づいて抽出することとしてもよい。例えば,制御部11は,ユーザを識別する情報ごとに,当該ユーザが利用したIPアドレス(群)を抽出し,記憶部12に履歴情報として記録しておく。そして企業外ネットワーク2側から受け入れたリクエストについて,そのソースIPアドレス情報が,そのAuthorizationフィールドに設定される情報に関連づけて履歴情報として記録されているIPアドレス群に含まれているか否かを調べ,含まれていなければ,当該リクエストは,不正な通信であると判断する。
【0046】
同様に,アクセスの時間帯についても,ユーザを識別する情報ごとに,過去のアクセス時間帯の集計を履歴情報として記憶部12に格納しておき,そして企業外ネットワーク2側から受け入れたリクエストについて,そのリクエストを受信した時間帯が,そのAuthorizationフィールドに設定される情報に関連づけて履歴情報として記録されている時間帯に一致しているか否かを調べ,一致していなければ,当該リクエストは,不正な通信であると判断する。
【0047】
また,上記のIPアドレスは一例であって,それに代えて,当該IPアドレスの一部(ネットワークアドレス部分)のみを用いてもよいし,デバイスごとに固有なMACアドレス等(イーサネット(登録商標)のアドレスなど)を用いてもよい。」

F.「【0053】
具体的には制御部11は,HTTPリクエストのAuthorizationフィールドに含まれるべき情報(ユーザを特定する情報)について,それぞれ所定の連絡先の情報を関連づけて記憶部12に保持しておき,不正な通信として検出されたHTTPリクエスト(群)について,そのAuthorizationフィールドに含まれる情報を抽出し,当該情報に関連づけて保持されている連絡先の情報を取り出して,当該連絡先に対して不正な通信があった旨を報知する。
【0054】
この連絡先及び報知の態様としては,例えば電子メールアドレスを連絡先とし,電子メールにて不正な通信があった旨を報知してもよい。この場合,制御部11は,電子メールクライアントとして動作し,企業外ネットワーク2又は企業内ネットワーク3に接続されている電子メールサーバ(SMTPサーバ)に対して当該連絡先に対する電子メールを送信させる。」

G.「【0059】
[ユーザからのフィードバック]
さらにこの対処処理部44の処理としては,ユーザや管理者等予め設定された通知先に対して不正な通信があったことを報知した後,当該連絡先から情報を受け入れたか否かに基づいて,またはその受け入れた情報の内容に基づいて上記仲介処理を停止するか否かを判断してもよい。具体的には,制御部11は,ウエブサーバとしての動作を行い,不正な通信が検出されたときに,固有のファイル名を発行して,当該発行したファイル名で,通信継続の可否を問い合わせるためのウエブページを生成して保持しておく。そして,予め設定された通知先に対して不正の通信があった旨の報知を行うとともに,当該報知に,上記生成したウエブページのURLを含める。
【0060】
そして,図示しないタイマを用いて報知からの経過時間を監視し,一定の時間内に,通知先から,上記URLへのアクセスがない場合に(ウエブサーバのログによってアクセスの有無を検出できる),仲介処理を停止する処理を行って,保護対象ノードであるサーバ装置31への企業外ネットワーク2からの通信(の一部)を遮断する。
【0061】
なお,通知先からの応答は,このようなフィードバックの態様に限られるものではなく,例えばユーザに不正通信装置1が備える電話回線接続部(不図示)の電話番号を発呼させることとし,一定の時間が経過するまでに当該電話番号に着信がなかったときに仲介処理を停止する処理を行うこととしてもよい。
【0062】
さらに,通信継続の可否を問い合わせるためのフィードバックだけでなく,一旦通信が遮断されてしまったときに,当該通信の再開指示を受け入れるためのURLや電話番号を報知に含めてもよい。この場合,制御部11は,当該再開指示を受け入れるURLへのアクセスがあったり,当該電話番号への着信があったときに,当該アクセスや電話番号の発呼を行ったユーザ(電話の場合,電話回線網側のサービスである発呼者番号通知を利用できる)を,記憶部12の接続遮断対象ユーザから削除する。
【0063】
本実施の形態に係る不正通信検出装置1は,上記構成を備えており,次に述べるような動作を行う。すなわち,企業内ネットワーク3上の端末(不図示)から,サーバ装置31へのHTTPリクエストについては,この不正通信検出装置1は,何ら関与しない。
【0064】
一方,企業外ネットワーク2上の端末,例えば外部利用者側端末21から企業内ネットワーク3へ入来する要求情報等については,HTTPのベーシック認証のようなユーザ認証を行った上で,当該ユーザ認証情報を各要求情報に関連づけさせ(HTTPの場合は,クライアントソフトウエアの仕様として一般に,ベーシック認証後はHTTPリクエストにユーザを識別する情報が含められるのでこれを用いればよい),ユーザ認証情報によって特定されるユーザごとに,受け入れた要求情報を記録する。」

H.「【0068】
また,正当なユーザが利用する外部利用者端末21に割り当てられるIPアドレスが知られている場合や,ユーザのアクセス時間帯が予めわかっている場合は,事前にされた設定や,過去の履歴に基づいて,外部利用者端末21のネットワークアドレス(IPアドレス等)があらかじめ登録されているものや,履歴として記録されているアドレスと異なる場合に不正な通信が行われたと判断する。また,アクセスの時間帯があらかじめ登録されている時間帯や,過去にアクセスした時間帯として履歴に記録されていない場合に,不正な通信が行われたと判断してもよい。さらに,長時間に亘りアクセスが行われている場合に,不正な通信が行われたと判断してもよい。さらに,これらの条件を組み合わせて不正な通信が行われたか否かを判断しても構わない。
【0069】
そして,不正通信検出装置1は,不正な通信が行われたと判断した場合に,当該不正な通信と判断された要求情報(群)に含まれるユーザ認証情報を抽出し,当該ユーザ認証情報に関連づけて予め設定されている連絡先に対して,不正な通信があったことを報知する。そして,一定の時間,当該連絡先から通信継続の可否に係る情報が受け入れられるか否かを監視し,受け入れられない場合は,当該ユーザ認証情報を含む要求情報の受け入れを停止する。
【0070】
これにより,上記ベーシック認証などのユーザ認証を通過した悪意のユーザ(なりすましを行うユーザ)による不正な通信を効果的に検出して,これを阻止できる。」

I.「【0074】
また不正通信検出処理部43が情報記録部42によって記録された情報のうち,ユーザ認証を行った後の情報のみを対象として不正通信検出処理を行うようにしてもよい。上述のように情報記録部42が,ユーザ認証が行われた後の情報のみを記録したり,ここで述べたように不正通信検出処理部43が,ユーザ認証が行われた後の情報のみを対象として不正通信検出処理を行うようにすることで,ユーザを認証した後の情報に基づき,予め定められた所定の不正通信基準ルールに合致するか否かが判断されることになる。
【0075】
さらに,不正通信検出装置1は,ユーザ認証の結果に基づく処理を行うサーバ装置(上述の例でのサーバ装置31)と一体の構成となっていてもよい。・・・(後略)・・・」

ここで,上記引用文献1に記載されている事項を検討する。

(ア)上記Aの段落【0017】の「不正通信検出装置1は,制御部11と,記憶部12と,通信部13とを含んで構成されている。」との記載,
上記Iの段落【0075】の「さらに,不正通信検出装置1は,ユーザ認証の結果に基づく処理を行うサーバ装置(上述の例でのサーバ装置31)と一体の構成となっていてもよい。」との記載,
上記Bの段落【0021】の「また,サーバ装置31は,ウエブサーバと協働するアプリケーションを動作させ,ウエブサーバが受信した要求情報に基づき,当該アプリケーションに動作を行わせて,その結果を提供するようにしても構わない。そしてここでは,サーバ装置31がHTTPにおけるいわゆるベーシック認証によってユーザを認証するものとする。」,段落【0022】の「外部利用者端末21は,ウエブブラウザを動作させて,サーバ装置31に対してHTTPの要求情報(HTTPリクエスト)を送信し,当該要求に応じた処理の結果等を受信することになる。またベーシック認証に関する情報として,ユーザを特定する情報(ユーザの認証に関する情報)を,HTTPリクエストに含める。具体的には,そのリクエスト・ヘッダのオーソライゼーション(Authorization)フィールドに当該ユーザを特定する情報が含められる。」との記載,
上記Cの段落【0026】の「ここでHTTPリクエストは,リクエスト・ラインとリクエスト・ヘッダとを含み,このリクエスト・ヘッダには,既に述べたように,Authorizationフィールドが含まれ,ここにユーザを識別するための情報が記録されている。」との記載,
上記Dの段落【0042】の「悪意のユーザが他のISPを利用するなどして通信を行おうとすると,たとえサーバ装置31側でのユーザ認証を通過できたとしても」との記載,
上記Gの段落【0064】の「外部利用者側端末21から企業内ネットワーク3へ入来する要求情報等については,HTTPのベーシック認証のようなユーザ認証を行った上で,」との記載からすると,
引用文献1には,“制御部は,端末から,ベーシック認証に関する情報であるユーザを特定する情報を含むヘッダを含むHTTPリクエストが受信されると,最初に,ベーシック認証によって,ユーザ認証する不正通信検出装置”が記載されていると認められる。

(イ)上記Dの段落【0040】の「さらに,制御部11において利用される不正通信基準ルールは,外部ノード(ここでは外部利用者端末21)からの通信条件を用いて定められてもよい。このような条件としては,例えば外部利用者端末21に割り当てられる可能性のあるIPアドレス・・・(中略)・・・等がある。」,段落【0041】の「このような不正通信基準ルールを用いる場合,例えばIPアドレスに関する条件を用いて定めた不正通信基準ルールであれば,ユーザを識別する情報(上記Authorizationフィールドに設定される情報)ごとに,予め利用される可能性のあるIPアドレスを列挙して,記憶部12に格納しておき」,「当該ユーザが外部利用者端末21をネットワークに接続するために,当該ユーザの契約するISPにグローバルIPアドレスの提供を要求したときに,当該設定した範囲のIPアドレスのいずれかが割り当てられ(例えばDHCP等によって割当がなされる)」との記載,
上記Eの段落【0046】の「アクセスの時間帯についても,ユーザを識別する情報ごとに,過去のアクセス時間帯の集計を履歴情報として記憶部12に格納しておき」,段落【0047】の「また,上記のIPアドレスは一例であって,それに代えて,当該IPアドレスの一部(ネットワークアドレス部分)のみを用いてもよいし,デバイスごとに固有なMACアドレス等(イーサネット(登録商標)のアドレスなど)を用いてもよい。」との記載からすると,
引用文献1には,前記不正通信検出装置が,“制御部は,不正通信基準ルールとして,時間帯やMACアドレスを含む,DHCP等によって割当がなされるIPアドレス等を記憶部に格納”しておくことが記載されていると認められる。

(ウ)上記Eの段落【0045】の「またこれらの設定は,各ユーザが明示的に行うのではなく,制御部11が過去の通信履歴に基づいて抽出することとしてもよい。例えば,制御部11は,ユーザを識別する情報ごとに,当該ユーザが利用したIPアドレス(群)を抽出し,記憶部12に履歴情報として記録しておく。そして企業外ネットワーク2側から受け入れたリクエストについて,そのソースIPアドレス情報が,そのAuthorizationフィールドに設定される情報に関連づけて履歴情報として記録されているIPアドレス群に含まれているか否かを調べ,含まれていなければ,当該リクエストは,不正な通信であると判断する。」との記載,
上記Gの【0064】の「HTTPのベーシック認証のようなユーザ認証を行った上で・・・(中略)・・・ユーザ認証情報によって特定されるユーザごとに,受け入れた要求情報を記録する。」との記載,及び,
上記Bの段落【0022】の「ユーザを特定する情報(ユーザの認証に関する情報)」との記載,及び,上記(イ)で検討した事項からすると,
引用文献1には,前記不正通信検出装置が,“これらの設定はユーザが設定しなくても,ユーザを特定する情報ごとに,後でリクエストのソースIPアドレス等と照合するためのIPアドレス等を抽出して記憶部に履歴情報として記録”しておくことが記載されていると認められる。

(エ)上記Dの段落【0041】の「企業外ネットワーク2側から受け入れたリクエストについて,そのソースIPアドレス情報(当該リクエストを生成した端末のIPアドレス)が,そのAuthorizationフィールドに設定される情報に関連づけて登録されているIPアドレス群に含まれているか否かを調べ,含まれていなければ,当該リクエストは,不正な通信であると判断する。」との記載,
上記Hの段落【0068】の「過去の履歴に基づいて,外部利用者端末21のネットワークアドレス(IPアドレス等)があらかじめ登録されているものや,履歴として記録されているアドレスと異なる場合に不正な通信が行われたと判断する。」との記載,
段落【0070】の「これにより,上記ベーシック認証などのユーザ認証を通過した悪意のユーザ(なりすましを行うユーザ)による不正な通信を効果的に検出して,これを阻止できる。」との記載,
上記Iの段落【0074】の「また不正通信検出処理部43が情報記録部42によって記録された情報のうち,ユーザ認証を行った後の情報のみを対象として不正通信検出処理を行うようにしてもよい。」との記載,及び,
上記(ウ)で検討した事項からすると,
引用文献1には,前記不正通信検出装置が,“制御部は,ユーザ認証が成功した後に,リクエストのソースIPアドレス等が,履歴として記録されているIPアドレス等の情報と異なる場合,不正と判断”することが記載されていると認められる。

(オ)上記Fの段落【0053】の「不正な通信として検出されたHTTPリクエスト(群)について,そのAuthorizationフィールドに含まれる情報を抽出し,当該情報に関連づけて保持されている連絡先の情報を取り出して,当該連絡先に対して不正な通信があった旨を報知する。」,
段落【0054】の「この連絡先及び報知の態様としては,例えば電子メールアドレスを連絡先とし,電子メールにて不正な通信があった旨を報知してもよい。」との記載,
上記Gの段落【0059】の「制御部11は・・・(中略)・・・不正な通信が検出されたときに・・・(中略)・・・通信継続の可否を問い合わせるためのウエブページを生成して保持しておく。そして,予め設定された通知先に対して不正の通信があった旨の報知を行うとともに,当該報知に,上記生成したウエブページのURLを含める。」との記載,
上記Hの段落【0069】の「そして,不正通信検出装置1は,不正な通信が行われたと判断した場合に,当該不正な通信と判断された要求情報(群)に含まれるユーザ認証情報を抽出し,当該ユーザ認証情報に関連づけて予め設定されている連絡先に対して,不正な通信があったことを報知する。」との記載,
上記Bの段落【0022】の「ユーザを特定する情報(ユーザの認証に関する情報)」との記載からすると,
引用文献1には,前記不正通信検出装置が,“制御部は,不正と判断された場合には,ユーザを特定する情報に関連付けて予め設定されている連絡先のメールアドレスに,「通信継続の可否を問い合わせるためのウェブページ」のURLを含むメールを送信”することが記載されていると認められる。

(カ)上記Gの段落【0059】の「ユーザや管理者等予め設定された通知先に対して不正な通信があったことを報知した後,当該連絡先から情報を受け入れたか否かに基づいて,またはその受け入れた情報の内容に基づいて上記仲介処理を停止するか否かを判断してもよい。」との記載,
上記Hの段落【0069】の「不正通信検出装置1は・・・(中略)・・・一定の時間,当該連絡先から通信継続の可否に係る情報が受け入れられるか否かを監視し,受け入れられない場合は,当該ユーザ認証情報を含む要求情報の受け入れを停止する。」との記載,及び,
上記(ア)?(オ)で検討した事項からすると,
引用文献1には,前記不正通信検出装置が,“連絡先から受け取る「通信継続の可否に係る情報」に基づき,通信の可否を決定し,
リクエストのソースIPアドレス等が,履歴として記録されているIPアドレス等の情報と一致する場合,又は,「通信継続の可否を問い合わせるためのウェブページ」からの「通信継続の可否に係る情報」により通信可能と決定した場合,処理は停止されない”ことが記載されていると認められる。

(キ)以上,(ア)?(カ)で検討した事項を踏まえると,引用文献1には,次の発明(以下,「引用発明」という。)が記載されているものと認める。

「制御部は,
端末から,ベーシック認証に関する情報であるユーザを特定する情報を含むヘッダを含むHTTPリクエストが受信されると,最初に,ベーシック認証によって,ユーザ認証し,
不正通信基準ルールとして,時間帯やMACアドレスを含む,DHCP等によって割当がなされるIPアドレス等を記憶部に格納しておき,
これらの設定はユーザが設定しなくても,ユーザを特定する情報ごとに,後でリクエストのソースIPアドレス等と照合するためのIPアドレス等を抽出して記憶部に履歴情報として記録しておき,
ユーザ認証が成功した後に,リクエストのソースIPアドレス等が,履歴として記録されているIPアドレス等の情報と異なる場合,不正と判断し,
不正と判断された場合には,ユーザを特定する情報に関連付けて予め設定されている連絡先のメールアドレスに,「通信継続の可否を問い合わせるためのウェブページ」のURLを含むメールを送信し,
連絡先から受け取る「通信継続の可否に係る情報」に基づき,通信の可否を決定し,
リクエストのソースIPアドレス等が,履歴として記録されているIPアドレス等の情報と一致する場合,又は,「通信継続の可否を問い合わせるためのウェブページ」からの「通信継続の可否に係る情報」により通信可能と決定した場合,処理は停止されない
不正通信検出装置。」

(3)参考文献

ア.当審拒絶理由で引用され,原願出願前に頒布された,特開2004-158025号公報(平成16年6月3日出願公開,以下,「参考文献1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

J.「【0051】
クライアント10からサーバ14にアクセスする場合には,クライアント10の入力装置10iが操作され,サーバ14にアクセスする要求がなされる。この結果,図5に示すステップS1において,クライアント10は,サーバ14に対してユーザIDおよびパスワードを送信する。サーバ14は,受信したユーザIDおよびパスワードと,HDD14dに格納されているユーザIDおよびパスワードと比較することにより,ユーザを認証するか否かを判定する。」

イ.当審拒絶理由で引用され,原願出願前に頒布された,特開2004-295632号公報(平成16年10月21日出願公開,以下,「参考文献2」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

K.「【0063】
ステップS25に続いてステップS26に進み,セキュリティモジュールインタフェース手段12が,認証手段13に認証情報を出力すると,認証手段13は,文書管理・認証サーバ20に対して認証情報を送信することにより,ユーザの認証を要求する。
【0064】
ステップS26に続いてステップS27に進み,認証手段13は,文書管理・認証サーバ20からの応答に基づいてユーザの認証が成功したか否かを判断する。ユーザの認証が成功した場合は,認証手段13は,その旨を制御部14に出力する。この場合は,ユーザは,文書管理・認証サーバ20に対するアクセスが許可されたことになり,当該ユーザが有するアクセス権限の範囲で,文書管理DB21の文書情報に対してアクセスが可能となる。
【0065】
一方,ユーザの認証が失敗した場合は,ステップS27に続いてステップS28に進み,認証手段13は,再認証を行うか否かを問い合わせるダイアログを表示する。ユーザによって,再認証を行う旨が選択されるとステップS23に進み,次の優先順位のセキュリティモジュール11(BaｒCｏde.dll)によって認証処理が行われる(S24?S26)。」

ウ.当審拒絶理由で引用され,原願出願前に頒布された,特開2005-346592号公報(平成17年12月5日出願公開,以下,「参考文献3」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

L.「【請求項1】
携帯電話機の携帯ブラウザを介して携帯サイトにアクセスする際の,前記携帯サイト側でのユーザーの認証に関する方法であって,
前記ユーザー側では,前記携帯サイトのURLにアクセスしてログイン用のID及びパスワードを入力する初期アクセスと,前記携帯サイトからメール送信された認証用URLにアクセスする認証用アクセスとを行い,
前記携帯サイト側では,予め前記ユーザーの前記携帯電話機の携帯メールアドレスを管理者によってサーバーに登録するサーバ登録を行った後に,前記ユーザー側からの前記初期アクセスがあると,前記ID及び前記パスワードに基づいて前記ユーザーに対する一回目の認証を行うとともに,少なくとも認証フラグ及び認証キーからなる文字列を組み込んだ前記認証用URLを登録且つ前記ユーザーの前記携帯メールアドレスに送信する処理を行い,その後,前記ユーザー側からの前記認証用アクセスがあると,前記認証用URLの前記文字列に基づいて前記ユーザーに対する二回目の認証を行う
ことを特徴とする携帯サイト認証方法。
【請求項2】
請求項1に記載の携帯サイト認証方法において,
前記携帯サイト側では,前記認証フラグ及び前記認証キーを生成する際に,前記携帯ブラウザの情報及び/又は前記携帯電話機の機種の情報を生成してその登録をするとともに,前記二回目の認証の際に前記各情報を用いる
ことを特徴とする携帯サイト認証方法。」

M.「【0026】
ステップS27の処理では,アクセスを行ったユーザーに対して認証用URLを送信する処理が行われる。その送信は,ユーザーの携帯メールアドレスを宛先として行われる(認証用URLは不正利用者の携帯電話機にメール送信されることはない)。
・・・(中略)・・・
【0029】
ステップS33の処理では,ステップS27の処理でメール送信した携帯ブラウザからのアクセスか否かを端末・ブラウザ情報登録エリア30に登録された端末・ブラウザ情報に基づいて確認する処理が行われる。その確認の結果,メール送信した携帯ブラウザからのアクセスであれば,次の処理へ移行する(メール送信した携帯ブラウザからのアクセスでなければ(例えば認証用URLを盗み見てユーザーとは別の携帯電話機4によりアクセスした場合が該当),そこで処理を中断するか又はステップS21の処理へ戻る)。
・・・(中略)・・・
【0032】
以上,本発明によれば,ユーザーは,常に同じログイン用のID及びパスワードを用いるだけでよく,これにより忘れという問題点が解消される。また,携帯サイト5側で二回の認証を行っていることから,常に同じログイン用のID及びパスワードを用いたとしても,携帯サイト5の安全性が低下することはない。さらに,ユーザーは,認証フラグ及び認証キーからなる文字列を組み込んだ認証用URLのメール受信をほんの短い時間だけ待つことと,その認証用URLへのアクセスとを行うことだけでよく,煩わしさが伴うことはない。さらにまた,携帯サイト5側では,携帯ブラウザからのアクセスか否かなどの各種確認を行っていることから,認証に対する信頼性が高まる。さらにまた,有効期限を設定していることから,余分な外部からのアクセス時間が減って,携帯サイト5の安全性が高まる。」

(4)対比

本件補正発明と引用発明とを対比する。

ア.引用発明の「不正通信検出装置」は,ユーザを認証するサーバであるから,本件補正発明の「ユーザ確認装置」に対応するといえる。

イ.引用発明の「端末から,ベーシック認証に関する情報であるユーザを特定する情報を含むヘッダを含むHTTPリクエストが受信され」,「不正通信基準ルールとして,時間帯やMACアドレスを含む,DHCP等によって割当がなされるIPアドレス等を記憶部に格納しておき」,「これらの設定はユーザが設定しなくても,ユーザを識別する情報ごとに,後でリクエストのソースIPアドレス等と照合するためのIPアドレス等を抽出して記憶部に履歴情報として記録」しておく「制御部」と,
本件補正発明の「端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケットから,該パケットに含まれるユーザの識別情報,該ユーザの認証に必要な認証情報,および該ヘッダ部に含まれ前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段」の両者を対比する。
引用発明の「端末」は,認証されるユーザの端末であるから,本件補正発明の「端末装置」に相当する。
引用発明の「DHCP等によって割当がなされるIPアドレス等」は,端末に係る情報であり,「DHCP等によって割当がなされるIPアドレス」が変化しうることは技術常識であるから,本件補正発明の「端末装置の使用に応じて変化する端末情報」に相当する。
引用発明の「ユーザを特定する情報」は,本件補正発明の「ユーザの識別情報」及び「認証情報」と,「ユーザの認証に関する情報」である点で共通する。
引用発明の「端末から,ベーシック認証に関する情報であるユーザを特定する情報を含むヘッダを含むHTTPリクエストが受信され」,「HTTPリクエスト」と,本件補正発明の「アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケット」とは,いずれもヘッダを含むデータであり,本件補正発明の「ヘッダ部」とは,本願明細書の段落【0036】の「アプリケーション層のプロトコルとしてHTTPが適用されて端末装置より受信したパケットから,当該パケットのHTTPヘッダに設定されているユーザエージェント情報全体を抽出する」との記載からすると,HTTPヘッダを含むものであるから,端末より受信する「アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するデータ」である点で共通する。
したがって,上記両者は,後記する点で相違するものの,
“端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するデータから,該データに含まれるユーザの認証に関する情報,および,前記端末装置の使用に応じて変化する端末情報を抽出する抽出処理を行う手段”である点で共通しているといえる。

ウ.引用発明の「不正通信基準ルールとして,時間帯やMACアドレスを含む,DHCP等によって割当がなされるIPアドレス等を記憶部に格納しておき」,「これらの設定はユーザが設定しなくても,ユーザを識別する情報ごとに,後でリクエストのソースIPアドレス等と照合するためのIPアドレス等を抽出して記憶部に履歴情報として記憶部に記録」しておく「制御部」と,
本件補正発明の「ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を,前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段」とは,
上記イ.で検討した事項からすると,引用発明の「記憶部」は,ユーザの認証に関する情報と端末情報を記憶するものであり,本件補正発明の「記憶手段」に相当するから,
後記する点で相違するものの,
“ユーザの操作する前記端末装置より受信したデータから前記抽出処理によって抽出された端末情報と照合される端末情報を,前記ユーザのユーザの認証に関する情報と関連付けて記憶手段に記憶させる情報管理処理を行う手段”である点で共通しているといえる。

エ.引用発明の「端末から,ベーシック認証に関する情報であるユーザを特定する情報を含むヘッダを含むHTTPリクエストが受信されると,最初に,ベーシック認証によって,ユーザ認証」する「制御部」と,
本件補正発明の「前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段」とは,
上記イ.で検討したように引用発明の「ユーザを特定する情報(ユーザの認証に関する情報)」,「ユーザを識別する情報」は,本件補正発明の「ユーザの識別情報」及び「認証情報」と,「ユーザの認証に関する情報」である点で一致するから,
後記する点で相違するものの,
“前記抽出処理により抽出されたユーザの認証に関する情報に基づいて前記ユーザの認証処理を行う手段”である点で共通しているといえる。

オ.引用発明の「ユーザ認証が成功した後に,リクエストのソースIPアドレス等が,履歴として記録されているIPアドレス等の情報と異なる場合,不正と判断」する「制御部」と,
本件補正発明の「前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を,前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段」とは,
上記イ.?エ.で検討した事項からすると,
引用発明の「IPアドレス等」は,本件補正発明の「端末情報」に相当し,
引用発明の「異なる場合,不正と判断」することは,受信した端末情報と記録されている端末情報との比較による判定処理であって,本件補正発明の「符合するか否かを判定」することに相当するから,
後記する点で相違するものの,
“前記認証処理により前記ユーザの認証に成功した場合に前記抽出処理により抽出された端末情報を,前記ユーザのユーザの認証に関する情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定処理を行う手段”である点で共通しているといえる。

カ.引用発明の「不正と判断された場合には,ユーザを特定する情報に関連付けて予め設定されている連絡先のメールアドレスに,「通信継続の可否を問い合わせるためのウェブページ」のURLを含むメールを送信し,連絡先から受け取る「通信継続の可否に係る情報」に基づき,通信の可否を決定」する「制御部」と,
本件補正発明の「前記判定手段により前記符合しないと判定された場合,前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段」の両者を対比する。
引用発明の「不正と判断された場合」は,上記オ.で検討した事項からすると,受信した端末情報と記録されている端末情報が不一致の場合であるから,本件補正発明の「符合しないと判定された場合」に相当する。
引用発明の「通信継続の可否に係る情報」は,ユーザ認証情報に関連付けて予め設定されている正当なユーザのメールアドレスに連絡して,正当なユーザからのリクエストであることを確認するための情報である。
もし,ユーザ認証に成功しても,不正ユーザは,正当なユーザのメールアドレスからメールを受信できないのであるから,端末から「通信継続の可否に係る情報」を受信できた場合,正当なユーザの存在を確認できる。
したがって,引用発明の「通信継続の可否を問い合わせるためのウェブページ」は,これにより正当なユーザであるか否かを確認する効果を奏するものと解することができるから,本件補正発明の「再認証手段」と,”ユーザの確認処理を行う手段”である点で一致する。
したがって,上記両者は,後記する点で相違するものの,
“前記判定処理により前記符合しないと判定された場合,前記認証処理による認証の方法および前記判定処理による判定の方法とは異なる方法により前記ユーザの確認処理を行う手段”である点で共通しているといえる。

キ.上記ウ.で検討したとおり,引用発明の「制御部」と本件補正発明の「情報管理手段」とは,“ユーザの操作する前記端末装置より受信したデータから前記抽出処理によって抽出された端末情報と照合される端末情報を,前記ユーザのユーザの認証に関する情報と関連付けて記憶手段に記憶させる情報管理処理を行う手段”である点で共通しているといえる。
そして,引用発明の「制御部」は,「ユーザを特定する情報ごとに,後でリクエストのソースIPアドレス等と照合するためのIPアドレス等を抽出して記憶部に履歴情報として記録」するところ,
「リクエストのソースIPアドレス等が,履歴として記録されているIPアドレス等の情報と異なる場合」であっても,『「通信継続の可否を問い合わせるためのウェブページ」からの「通信継続の可否に係る情報」により通信可能と決定した場合,処理は停止されない』ものであって,
換言すれば,IPアドレスと履歴情報による判定処理が失敗した場合であっても,「通信継続の可否を問い合わせるためのウェブページ」による再認証処理が成功した場合には,通信が阻止されずに発生するので,記憶部に,その通信の履歴情報が記録されることは明らかである。
したがって,引用発明の「制御部」と本件補正発明の「情報管理手段」とは,後記する点で相違するものの,
“前記情報管理処理を行う手段は,前記確認処理を行う手段により前記ユーザの確認が成功した場合に,前記判定処理を行う手段による判定対象となる端末情報として,前記抽出手段によって抽出された端末情報を前記ユーザのユーザの認証に関する情報と関連付けて前記記憶手段に記憶させ”るものである点で共通しているといえる。

ク.引用発明の「リクエストのソースIPアドレス等が,履歴として記録されているIPアドレス等の情報と一致する場合,又は,「通信継続の可否を問い合わせるためのウェブページ」からの「通信継続の可否に係る情報」により通信可能と決定した場合,処理は停止されない」ことと,
本件補正発明の「前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定する」こととは,
上記ア.?キ.で検討した事項からすると,
“前記判定処理を行う手段により前記符合すると判定された場合,または,前記確認処理を行う手段により前記ユーザの確認に成功した場合に,該ユーザが正当なユーザであると判定する処理を実行する”ものである点で共通しているといえる。

以上から,本件補正発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

(一致点)
「端末装置より受信したアプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するデータから,該データに含まれるユーザの認証に関する情報,および,前記端末装置の使用に応じて変化する端末情報を抽出する抽出処理を行う手段と,
ユーザの操作する前記端末装置より受信したデータから前記抽出処理によって抽出された端末情報と照合される端末情報を,前記ユーザのユーザの認証に関する情報と関連付けて記憶手段に記憶させる情報管理処理を行う手段と,
前記抽出処理により抽出されたユーザの認証に関する情報に基づいて前記ユーザの認証処理を行う手段と,
前記認証処理により前記ユーザの認証に成功した場合に前記抽出処理により抽出された端末情報を,前記ユーザのユーザの認証に関する情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定処理を行う手段と,
前記判定処理により前記符合しないと判定された場合,前記認証処理による認証の方法および前記判定処理による判定の方法とは異なる方法により前記ユーザの確認処理を行う手段と
を備え,
前記情報管理処理を行う手段は,前記確認処理を行う手段により前記ユーザの確認が成功した場合に,前記判定処理を行う手段による判定対象となる端末情報として,前記抽出手段によって抽出された端末情報を前記ユーザのユーザの認証に関する情報と関連付けて前記記憶手段に記憶させ,
前記判定処理を行う手段により前記符合すると判定された場合,または,前記確認処理を行う手段により前記ユーザの確認に成功した場合に,該ユーザが正当なユーザであると判定する処理を実行するユーザ確認装置。」

(相違点1)
抽出処理に関して,
本件補正発明では,パケットを受信するのに対して,
引用発明では,パケット形式のリクエストを受信しない点。

(相違点2)
抽出処理により抽出される端末情報に関して,
本件補正発明では,「端末情報」がヘッダ部に含まれているのに対して,
引用発明では,端末情報とヘッダ部の関係は特定されていない点。

(相違点3)
ユーザの認証に関する情報と認証処理に関して,
本件補正発明では,ユーザの認証に関する情報が,「ユーザの識別情報」及び「ユーザの認証に必要な認証情報」であって,認証情報が情報管理処理に記憶されているか否かを判定するのに対して,
引用発明では,ユーザを特定する情報を含むヘッダを含むHTTPリクエストに基づいて,ベーシック認証しているものの,「ユーザの識別情報」及び「ユーザの認証に必要な認証情報」による認証方式が明示されていない点。

(相違点4)
「抽出処理」,「記憶管理処理」,「認証処理」,「判定処理」,「再認証処理」の実現に関して,
本件補正発明では,それぞれ別々の手段で実現されるのに対して,
引用発明では,それらの各処理が「制御部」により実現される点。

(相違点5)
判定処理により符合しないと判定された場合に関して,
本件補正発明では,「認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う」のに対して,
引用発明では,「通信継続の可否を問い合わせるためのウェブページ」による確認処理を実行するものの,前記確認処理がユーザ認証としての機能をも備えるのか明示されていない点。

(5)当審の判断

上記相違点1?5について検討する。

ア.相違点1について
情報処理の技術分野において,インターネット上で通信されるデータのリクエストをパケット形式で構成することは,引用文献等を示すまでもなく,従来から当業者が必要に応じて採用する常とう手段であり,
引用発明においても,リクエストをパケットで構成すること,すなわち,上記相違点1に係る構成とすることは,当業者が容易に想到し得たことである。

イ.相違点2について
情報処理の技術分野において,インターネット上で通信されるパケットのヘッダがIPアドレスを含むことは,技術常識であり,
引用発明においても,IPアドレス(端末情報)がヘッダ部に含まれるようにすること,すなわち,上記相違点2に係る構成とすることは,当業者が容易に想到し得たことである。

ウ.相違点3について
受信したユーザ識別情報及びパスワードが,記憶手段に記憶されているか否かを判定するユーザ認証方法は,例えば,参考文献1(上記J参照)に記載されているように,原願の出願前には,情報処理の技術分野において適宜に採用される周知技術であった。
してみると,引用発明に上記周知技術を適用して,「認証処理」(ベーシック認証)において,ヘッダ部から抽出したユーザ識別情報及びパスワード(認証情報)が,情報管理手段に記憶されているか否かを判定するように構成すること,すなわち,上記相違点3に係る構成とすることは,当業者が容易に想到し得たことである。

エ.相違点4について
一連の情報処理を実現する際に,そのための所定の纏まりをもった機能実現手段の組合わせによって実現することは,情報処理の技術分野における常とう手段であるから,引用発明における抽出処理,情報管理処理,第1判定処理,第2判定処理及び第3判定処理の各処理の機能実現手段として「認証手段」,「記憶管理手段」,「判定手段」,「再認証手段」とを備えること,すなわち,上記相違点4に係る構成とすることは,当業者が容易に想到し得たことである。

オ.相違点5について
参考文献3(上記L,M参照)には,認証方法の一態様として,サーバが,予め登録されたユーザのメールアドレスにURL付きメールを送信して表示させ,その後,端末から応答アクセスを確認することで(二回目の認証と呼称)認証に対する信頼性を高める認証方法が記載されている。
引用発明と,参考文献3記載の発明は,いずれも認証技術の分野に属し,いずれも,サーバが,予め登録されたユーザのメールアドレスへメールし,ユーザからの応答により後続処理の可否を制御する機能を備える発明であるから,
引用発明のIPアドレス等による認証に失敗した後のメール処理に,参考文献3記載の発明を適用して,正規ユーザの登録メールアドレスにメールしてフィードバックがあるか否かを判定する確認処理を,ユーザ認証と呼称して用いること,すなわち,上記相違点5に係る構成とすることは,当業者が容易に想到し得たことである。

(6)請求人の主張について

なお,平成28年2月12日付け意見書の請求人の主張について以下のとおり,検討する。

ア.請求人は,上記意見書の(3-4-1)において,『これらの記載によれば,引用発明1は,企業外ネットワーク2側から受け入れたリクエストにおける情報と比較される情報は,記憶部12に格納されているものの,何らかの手法で過去のアクセス履歴を集計して得られたものであると思料いたします。そのため,引用発明1は,可能性の高いと考えられる範囲を事前に特定しておき,判定基準としています。すなわち,判定が成功となる範囲を事前にある程度の幅をもって決めておくという程度に過ぎません。』(7頁5?10行),
『一方,引用発明1では,再帰的な処理をしていないため,通信継続の可否を問い合わせるためのウェブページが電子メールによって送信された場合,ユーザが通信継続を認めたとしても,再び同じ環境でアクセスをすれば,同じ電子メールが再度送信されることとなります。したがって,引用発明1では,管理者等が設定を変更しない限り,新しい環境からのアクセスについて,同じ電子メールが送信され続けることになります。』(7頁16?20行)と主張する。

しかるに,上記「(4)対比」のキ.で検討したように,引用発明においても,IPアドレスと履歴情報による判定処理が失敗した場合であっても,「通信継続の可否を問い合わせるためのウェブページ」による確認処理が成功した場合には,通信が阻止されずに発生するので,記憶部に,その通信の履歴情報が記録されることは明らかである。

また,引用文献1の上記Eの段落【0045】の「またこれらの設定は,各ユーザが明示的に行うのではなく」,「制御部11は,ユーザを識別する情報ごとに,当該ユーザが利用したIPアドレス(群)を抽出し,記憶部12に履歴情報として記録しておく。」,「受け入れたリクエストについて,そのソースIPアドレス情報が,そのAuthorizationフィールドに設定される情報に関連づけて履歴情報として記録されているIPアドレス群に含まれているか否かを調べ」との記載からすると,
引用発明は,自動的に記録されたIPアドレスの履歴情報を,直接調べて判定しており,ユーザが通信継続を認めた場合には,そのアクセスによるIPアドレスが履歴情報として記録され,次回の判定処理には反映されるといえる。
したがって,「引用発明1では,管理者等が設定を変更しない限り,新しい環境からのアクセスについて,同じ電子メールが送信され続けることになります。」との主張は,失当である。

イ.また,請求人は,上記意見書の(3-4-1)において,『仮に認証処理の一態様であったとしても,これは電子メールが特定の宛先に送信されることによって「端末」を認証するものであって,「ユーザ」を認証するものではありません。このように引用発明1は,端末を認証する前提であるため,ユーザが保持していれば間接的に正当ユーザと認証したものと仮定することになりますが,不正ユーザがその端末を持っていればその不正ユーザも正当ユーザとして認証されることになります。』(7頁25?30行)と主張する。
しかるに,上記「(5)当審の判断」の「オ.相違点5について」の(イ)で検討したように,サーバからユーザの登録端末のメールアドレスへのメールとその応答による確認処理は,ユーザに対する認証と呼称することができるものであり(参考文献3(上記L,M)参照),このような,ユーザが,携帯電話やICカードのような本人証明するためのハードウェアを保有しているか確認することによるユーザ認証方式は,認証技術の分野における常とう手段である。

ウ.ここで,上記相違点5に関して,仮に,引用発明の「通信継続の可否を問い合わせるためのウェブページ」による処理が,ユーザに対する認証と呼称されうる機能を含まないとした場合についても,一応検討する。
所定の認証方法が失敗した際に,別の認証方法を実行して再認証する点は,例えば参考文献2(特に上記K参照)に記載されているように,原願の出願前には,認証技術分野において普通に採用される周知技術であった。
引用発明の「IPアドレス」による認証に,上記周知技術を適用して,IPアドレス等による認証に失敗した際に,代替手段として別の認証方法,すなわち,再認証処理を実行するように構成することは,当業者が容易に想到し得たことである。
なお,請求人は,上記意見書の(3-4-1)において,『引用発明1において引用文献3(上記参考文献2に相当)の構成を適用すると,引用発明1において最初のユーザの認証(ID・パスワードによる認証)が失敗した場合に別の認証方法によるユーザの認証が行われるという処理を追加することが,当業者によって想到される程度であると思料いたします。』と主張するが,最初の認証に失敗した場合には,他の認証方法を提供するが,第2の認証に失敗した場合は,他の認証方法を提供しないようにするような格別の事情もなく,引用発明に上記周知技術を適用する際に,引用発明の「ユーザを特定する情報」による認証に上記周知技術を適用するか,「IPアドレス」による認証に上記周知技術を適用するか,両方の認証に上記周知技術を適用するかは,当業者が適宜選択可能な設計的事項にすぎない。

(7)小括

上記で検討したごとく,上記各相違点に係る構成は当業者が容易に想到し得たものであり,そして,これらの相違点を総合的に勘案しても,本件補正発明の奏する作用効果は,上記引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。
したがって,本件補正発明は,上記引用発明及び当該技術分野の周知技術に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により,特許出願の際独立して特許を受けることができない。

4-4.独立特許要件のむすび

したがって,補正後の請求項1の記載は,特許法第36条第6項第1号,又は,特許法第36条第6項第2号の規定を満たしておらず,しかも,本件補正発明は特許法第29条第2項の規定により特許を受けることができないものであるから,補正後の請求項1に記載の発明は,独立して特許することができないものである。

5.補正却下のむすび

以上のように,本件補正は,上記「2.新規事項追加禁止要件」で指摘したとおり,特許法第17条の2第3項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
また,仮に本件補正が,当初明細書等に記載した事項の範囲内で補正されたものであったとしても,上記「4.独立特許要件」で指摘したとおり,限定的減縮を目的とした補正後の請求項1が特許出願の際独立して特許を受けることができるものではないから,特許法第17条の2第5項において準用する同法第126条第5項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって,上記補正却下の決定の結論のとおり決定する。

第3 本願発明について

1.本願発明の認定

平成28年2月12日付けの手続補正は上記のとおり却下されたので,補正後の請求項1に対応する補正前の請求項に係る発明(以下,「本願発明」という。)は,平成27年10月30日付けの手続補正により補正された特許請求の範囲の請求項1に記載された事項により特定される,以下のとおりのものである。

「端末装置より受信したパケットから,該パケットに含まれるユーザの識別情報,該ユーザの認証に必要な認証情報および前記端末装置の使用に応じて変化する端末情報を抽出する抽出手段と,
ユーザの操作する前記端末装置より受信したパケットから前記抽出手段によって抽出された端末情報を,前記ユーザの識別情報と関連付けて記憶手段に記憶させる情報管理手段と,
前記抽出手段により抽出された識別情報および認証情報に基づいて前記ユーザの認証を行う認証手段と,
前記認証手段により前記ユーザの認証に成功した場合に前記抽出手段により抽出された端末情報を,前記ユーザの識別情報と関連付けて前記記憶手段に記憶されている端末情報と符合するか否かを判定する判定手段と,
前記判定手段により前記符合しないと判定された場合,前記認証手段による認証の方法および前記判定手段による判定の方法とは異なる方法により前記ユーザの再認証を行う再認証手段と,
を備え,
前記判定手段により前記符合すると判定された場合,または,前記再認証手段により前記ユーザの再認証に成功した場合に,該ユーザが正当なユーザであると判定するユーザ確認装置。」

2.引用文献

引用発明は,前記「第2 平成28年2月12日付けの手続補正についての補正却下の決定」の「4.独立特許要件」の「4-3. 特許法第29条第2項について」の「(2)引用文献」に記載したとおりである。

3.対比・判断

本願発明は,前記「第2 平成28年2月12日付けの手続補正についての補正却下の決定」の「4.独立特許要件」の「4-3. 特許法第29条第2項について」で検討した本件補正発明の
「アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有するパケット」から,「アプリケーションデータ部と当該アプリケーションデータ部以外のヘッダ部とを有」する点を削除し,
「該ヘッダ部に含まれ前記端末装置の使用に応じて変化する端末情報」から,「該ヘッダ部に含まれ」る点を削除し,
「前記再認証手段により前記ユーザの再認証が成功した場合に,前記判定手段による判定対象となる端末情報として,前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ」る「情報管理手段」から,「前記再認証手段により前記ユーザの再認証が成功した場合に,前記判定手段による判定対象となる端末情報として,前記抽出手段によって抽出された端末情報を前記ユーザの識別情報と関連付けて前記記憶手段に記憶させ」る点を削除したものである。

そうすると,本願発明の発明特定事項を全て含む本件補正発明が,前記「第2 平成28年2月12日付けの手続補正についての補正却下の決定」の「4.独立特許要件」の「4-3. 特許法第29条第2項について」の「(2)引用文献」乃至「(5)当審の判断」に記載したとおり,引用発明及び当該技術分野の周知技術に基づいて当業者が容易に発明をすることができたものであるから,上記特定の限定を省いた本願発明も同様の理由により,引用発明及び当該技術分野の周知技術に基づいて,当業者が容易に発明をすることができたものである。

4.特許法第17条の2第3項,特許法第36条第6項第1号及び第2号について

本願発明の発明特定事項を全て含む本件補正発明は,前記「第2 平成28年2月12日付けの手続補正についての補正却下の決定」の「2.新規事項追加禁止要件」及び「4.独立特許要件」の「4-1.特許法第36条第6項第1号について」,「4-2. 特許法第36条第6項第2号について」に記載したとおり,当初明細書等に記載した事項の範囲内においてしたものではない事項を含み,発明の詳細な説明に記載したものでなく,特許を受けようとする発明の範囲が不明確である。
そして,本件補正発明から上記特定の限定を削除しても,「2.新規事項追加禁止要件」,「4-1.特許法第36条第6項第1号について」,「4-2. 特許法第36条第6項第2号について」で指摘した記載は削除されておらず,本願発明は本件補正発明と同様の理由により,特許法第17条の2第3項,特許法第36条第6項第1号,又は,特許法第36条第6項第2号に規定する要件を満たしていない。

5.むすび

以上のとおり,本願の請求項1に係る発明は,特許法第17条の2第3項,特許法第36条第6項第1号,又は,特許法第36条第6項第2号に規定する要件を満たしていない,又は,特許法第29条第2項の規定により特許を受けることができないものであるから,その余の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2016-04-01 
結審通知日 2016-04-05 
審決日 2016-04-22 
出願番号 特願2013-174576(P2013-174576)
審決分類 P 1 8・ 121- WZ (G06F)
P 1 8・ 537- WZ (G06F)
P 1 8・ 561- WZ (G06F)
P 1 8・ 575- WZ (G06F)
最終処分 不成立  
前審関与審査官 和田 財太  
特許庁審判長 辻本 泰隆
特許庁審判官 高木 進
戸島 弘詩
発明の名称 ユーザ確認装置、方法及びプログラム  
代理人 特許業務法人高橋・林アンドパートナーズ  

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