【事件の表示】
　特願２０１６−５７１４１０「情報認証のための方法およびシステム」拒絶査定不服審判事件〔平成２８年　１月　７日国際公開、ＷＯ２０１６／００３６０５、平成２９年　７月２７日国内公表、特表２０１７−５２０８３８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本件審判請求に係る出願（以下，「本願」という。）は，２０１５年６月８日（パリ条約による優先権主張外国庁受理２０１４年７月３日（以下，「優先日」という。），中華人民共和国）を国際出願日とする出願であって，平成２８年１２月６日に特許法第１８４条の５第１項に規定される書面が提出され，平成２９年１月３１日付けで特許法第１８４条の４第１項の規定による国際出願日における明細書，請求の範囲，図面（図面の中の説明に限る。）及び要約の翻訳文が提出され，同年２月６日付けで審査請求がなされ，平成３０年１月２９日付けで拒絶理由通知（同年２月２日発送）がなされ，同年５月１日付けで意見書が提出されるとともに，同日付けで手続補正がなされたが，同年１０月１９日付けで拒絶査定（同年１０月２３日謄本送達）がなされた。
　これに対して，「原査定を取り消す。本願の発明は特許すべきものとする、との審決を求める。」ことを請求の趣旨として，平成３１年２月２１日付けで審判請求がなされるとともに，同日付けで手続補正がなされ，そして，令和元年６月１３日付けで審査官により特許法第１６４条第３項に定める報告（前置報告）がなされたものである。
第２　平成３１年２月２１日にされた手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　平成３１年２月２１日にされた手続補正（以下，「本件補正」という。）を却下する。
［理由］
１　本件補正について
ア　本件補正の内容は，平成３０年５月１日にされた手続補正により補正された特許請求の範囲の請求項１ないし請求項２４の記載
「　【請求項１】
　多人数認証を容易にするためのコンピュータ実施方法であって、
　認証サーバが、通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
　前記認証サーバが、認証要求を認証補助ユーザに送信するステップと、
　前記認証サーバが、前記認証補助ユーザから応答を受信するステップと、
　前記認証サーバが、認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
　前記認証サーバが、前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含む、方法。
　　【請求項２】
　前記認証要求を送信する前に、前記動作要求を許可するために少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、請求項１に記載の方法。
　　【請求項３】
　少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも１つの既定のルールを前記受信された動作要求に適用するステップを含む、請求項１に記載の方法。
　　【請求項４】
　前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、請求項３に記載の方法。
　　【請求項５】
　前記ルールが、支払金額に基づく、請求項３に記載の方法。
　　【請求項６】
　前記少なくとも１人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、請求項１に記載の方法。
　　【請求項７】
　前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Ｅメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、請求項１に記載の方法。
　　【請求項８】
　前記動作要求を拒否するステップが、拒否の理由を前記プライマリユーザに送信するステップを含む、請求項１に記載の方法。
　　【請求項９】
　命令を格納する非一時的な記憶媒体であって、
　前記命令はプロセッサによって実行されると、前記プロセッサに多人数認証を容易にするための方法を実行させ、前記方法は、
　通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
　認証要求を認証補助ユーザに送信するステップと、
　前記認証補助ユーザから応答を受信するステップと、
　認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
　前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含む、非一時的な記憶媒体。
　　【請求項１０】
　前記方法が、
　前記認証要求を送信する前に、前記動作要求を許可するために少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、請求項９に記載の非一時的な記憶媒体。
　　【請求項１１】
　少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも１つの既定のルールを前記受信された動作要求に適用するステップを含む、請求項９に記載の非一時的な記憶媒体。
　　【請求項１２】
　前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、請求項１１に記載の非一時的な記憶媒体。
　　【請求項１３】
　前記ルールが、支払金額に基づく、請求項１１に記載の非一時的な記憶媒体。
　　【請求項１４】
　前記方法が、前記少なくとも１人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、請求項９に記載の非一時的な記憶媒体。
　　【請求項１５】
　前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Ｅメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、請求項９に記載の非一時的な記憶媒体。
　　【請求項１６】
　前記動作要求を拒否するステップが、拒否の理由を前記プライマリユーザに送信するステップを含む、請求項９に記載の非一時的な記憶媒体。
　　【請求項１７】
　多人数認証を容易にするためのコンピュータシステムであって、
　プロセッサと、
　前記プロセッサと結合され、命令を格納するメモリであって、前記命令は前記プロセッサによって実行されると、前記プロセッサに方法を実行させ、前記方法は、
　　通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
　　認証要求を認証補助ユーザに送信するステップと、
　　前記認証補助ユーザから応答を受信するステップと、
　　認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
　　前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
　を含む、メモリと
を含む、コンピュータシステム。
　　【請求項１８】
　前記方法が、
　前記認証要求を送信する前に、前記動作要求を許可するために少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、請求項１７に記載のコンピュータシステム。
　　【請求項１９】
　少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも１つの既定のルールを前記受信された動作要求に適用するステップを含む、請求項１７に記載のコンピュータシステム。
　　【請求項２０】
　前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、請求項１９に記載のコンピュータシステム。
　　【請求項２１】
　前記ルールが、支払金額に基づく、請求項１９に記載のコンピュータシステム。
　　【請求項２２】
　前記方法が、前記少なくとも１人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、請求項１７に記載のコンピュータシステム。
　　【請求項２３】
　前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Ｅメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、請求項１７に記載のコンピュータシステム。
　　【請求項２４】
　前記動作要求を拒否するステップが、拒否の理由を前記プライマリユーザに送信するステップを含む、請求項１７に記載のコンピュータシステム。」
（以下，この特許請求の範囲に記載された請求項各項を「補正前の請求項」という。）
を，
「　【請求項１】
　多人数認証を容易にするためのコンピュータ実施方法であって、
　認証サーバが、通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
　前記認証サーバが、認証要求を認証補助ユーザに送信するステップと、
　前記認証サーバが、前記認証補助ユーザから応答を受信するステップと、
　前記認証サーバが、認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
　前記認証サーバが、前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含
み、
　
前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む
　　【請求項２】
　前記認証要求を送信する前に、前記動作要求を許可するために少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、請求項１に記載の方法。
　　【請求項３】
　少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも１つの既定のルールを前記受信された動作要求に適用するステップを含む、請求項１に記載の方法。
　　【請求項４】
　前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、請求項３に記載の方法。
　　【請求項５】
　前記ルールが、支払金額に基づく、請求項３に記載の方法。
　　【請求項６】
　前記少なくとも１人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、請求項１に記載の方法。
　　【請求項７】
　前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Ｅメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、請求項１に記載の方法。
　　【請求項８】
　命令を格納する非一時的な記憶媒体であって、
　前記命令はプロセッサによって実行されると、前記プロセッサに多人数認証を容易にするための方法を実行させ、前記方法は、
　通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
　認証要求を認証補助ユーザに送信するステップと、
　前記認証補助ユーザから応答を受信するステップと、
　認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
　前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含
み、
　
前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む
　　【請求項９】
　前記方法が、
　前記認証要求を送信する前に、前記動作要求を許可するために少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、
請求項８
　　【請求項１０】
　少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも１つの既定のルールを前記受信された動作要求に適用するステップを含む、
請求項８
　　【請求項１１】
　前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、
請求項１０
　　【請求項１２】
　前記ルールが、支払金額に基づく、
請求項１０
　　【請求項１３】
　前記方法が、前記少なくとも１人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、
請求項８
　　【請求項１４】
　前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Ｅメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、
請求項８
　　【請求項１５】
　多人数認証を容易にするためのコンピュータシステムであって、
　プロセッサと、
　前記プロセッサと結合され、命令を格納するメモリであって、前記命令は前記プロセッサによって実行されると、前記プロセッサに方法を実行させ、前記方法は、
　　通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
　　認証要求を認証補助ユーザに送信するステップと、
　　前記認証補助ユーザから応答を受信するステップと、
　　認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
　　前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
　を含
み、
　
前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む
を含む、コンピュータシステム。
　　【請求項１６】
　前記方法が、
　前記認証要求を送信する前に、前記動作要求を許可するために少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、
請求項１５
　　【請求項１７】
　少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも１つの既定のルールを前記受信された動作要求に適用するステップを含む、
請求項１５
　　【請求項１８】
　前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、
請求項１７
　　【請求項１９】
　前記ルールが、支払金額に基づく、
請求項１７
　　【請求項２０】
　前記方法が、前記少なくとも１人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、
請求項１５
　　【請求項２１】
　前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Ｅメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、
請求項１５
（以下，この特許請求の範囲に記載された請求項各項を「補正後の請求項」という。）
（なお，下線は，補正箇所を示すものとして，請求人が付与したものである。）
に補正するものである。
イ　そして，本件補正は，補正前の請求項１，９，１７に，それぞれ補正前の請求項８，１６，２４に記載されている「前記動作要求を拒否するステップが、拒否の理由を前記プライマリユーザに送信するステップを含む」という事項を追加し，さらに，「拒否の理由」を「認証を拒否する前記認証補助ユーザによって返された拒否の理由」と限定するものであるから，特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものに該当する。
２　独立特許要件
　以上のように，本件補正後の請求項１に記載された発明（以下，「本件補正発明」という。）は，補正前の請求項１に対して，限定的減縮を行ったものと認められる。そこで，本件補正発明が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか）以下に検討する。
（１）補正後の発明
　本件補正発明は，前記「１　本件補正について」において，補正後の請求項１として引用した，次の記載のとおりのものである。
「多人数認証を容易にするためのコンピュータ実施方法であって、
　認証サーバが、通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
　前記認証サーバが、認証要求を認証補助ユーザに送信するステップと、
　前記認証サーバが、前記認証補助ユーザから応答を受信するステップと、
　前記認証サーバが、認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
　前記認証サーバが、前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含み、
　前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む、方法。」
（２）引用文献に記載されている技術的事項及び引用発明の認定
（２−１）引用文献１
　本願の優先日前に頒布され（又は電気通信回線を通じて公衆に利用可能となり），原審の拒絶の査定の理由である上記平成３０年１月２９日付けの拒絶理由通知において引用された文献である，特開平１０−２４０６９０号公報（平成１０年９月１１日出願公開。以下，「引用文献１」という。）には，図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
Ａ　「【請求項１０】
サーバを用いて、クライアント端末から通知されたサービス提供要求に応じたサービスを提供するサービス提供方法
Ｂ　「【００８０】次に、サーバ２の機能ブロック構成について説明する。
【００８１】
サーバ２は
クライアント端末１から送信されたログイン要求にしたがいログイン処理を行うログイン処理部２０１
サービス管理部２０４と、を有する
（中略）
【００８８】
サービス管理部２０４は
サービス管理処理部２０５と、サービス承認要求処理部２０６と、サービス提供処理部２０７と、を有する
Ｃ　「【０１２４】次に、サーバ２の動作について説明する。
【０１２５】図１０および図１１はサーバ２の動作を説明するためのフロー図である。
【０１２６】まず、図１０に示すフローにおいて、
ログイン処理部２０１は、クライアント端末１からログイン要求が送信されたか否かを判断する
ログイン要求が送られてきた場合は
（中略）
【０１３２】ステップ３００５では、
サービス管理処理部２０５は、クライアント端末１からサービス提供要求が送信されたか否かを判断する
サービス提供要求が送られてきた場合
（中略）
【０１３８】ステップ３００９では、
サービス承認要求処理部２０６は、
サービス管理処理部２０５から送られてきた処理制御ルールを解析する
（中略）
【０１４３】さらに、
解析した処理制御ルールが、当該処理制御ルールに対応付けられたサービスの提供を受けるために、あるユーザの承認が必要であることを意味する場合は、当該ユーザが使用するクライアント端末１の識別子をログイン管理テーブル２０２に記憶されたテーブルから検索し
【０１４４】たとえば、ログイン管理テーブル２０２に記憶されたテーブルが図７に示すものであるとする。
【０１４５】ここで、ステップ３００８でサービス管理処理部２０５から送られてきたクライアント端末１の識別子が「１1」、サービス識別子が「Ｃ」、
そして処理制御ルール
に対応付けられたクライアント端末１の全てを
テーブルから検出する
（中略）
【０１４８】たとえば、ログイン管理テーブル２０２に記憶されたテーブルが図７に示すものである場合、ステップ３００８でサービス管理処理部２０５から送られてきた
処理制御ルールが「レベル０の承認が△人必要」であるときには、ユーザ権限レベル「０」に対応付けられたクライアント端末１が△数以上検出できたか否かを判断する
（中略）
【０１５０】一方、必要数分のクライアント端末が検出できた場合は、
当該検出したクライアント端末１に、ステップ３００５でサービス提供要求を送信したユーザが、当該サービス提供要求で特定されるサービスを享受することについて、承認するか否かの判断を要求する
【０１５１】その後、承認要求を行ったクライアント端末１から返答（承認情報）がくるのを待つ（ステップ３０１６）。
【０１５２】次に、
サービス承認要求処理部２０６は、
処理制御ルールに示された人数分のユーザから、承認許諾情報を得られたか否かを判断する
得られている場合はステップ３０１０に移行する
【０１５３】
ステップ３０１０での処理実行後、ステップ３０１１では、サービス提供処理部２０７は、
サービスを実行し、
クライアント端末１に提供する
イ　上記ＡないしＣの記載内容（特に，下線部を参照）からすると，上記引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認められる。
「サーバを用いて，クライアント端末から通知されたサービス提供要求に応じたサービスを提供するサービス提供方法であって，
　サーバのログイン処理部は，クライアント端末からログイン要求が送信されたか否かを判断し，
　ログイン要求が送られてきた場合，サーバのサービス管理処理部は，クライアント端末からサービス提供要求が送信されたか否かを判断し，
　サービス提供要求が送られてきた場合，サーバのサービス承認要求処理部は，サービス管理処理部から送られてきた処理制御ルールを解析し，解析した処理制御ルールが，当該処理制御ルールに対応付けられたサービスの提供を受けるために，あるユーザの承認が必要であることを意味する場合は，当該ユーザが使用するクライアント端末の識別子をテーブルから検索し，そして処理制御ルールに対応付けられたクライアント端末をテーブルから検出（処理制御ルールに示された人数分以上を検出）し，当該検出したクライアント端末に，サービス提供要求を送信したユーザが，当該サービス提供要求で特定されるサービスを享受することについて，承認するか否かの判断を要求し，
　サーバのサービス承認要求処理部は，処理制御ルールに示された人数分のユーザから，承認許諾情報を得られたか否かを判断し，
　承認許諾情報を得られている場合は，サーバのサービス提供処理部は，サービスを実行し，クライアント端末に提供する
ことを含むサービス提供方法。」
（２−２）引用文献２
　本願の優先日前に頒布され（又は電気通信回線を通じて公衆に利用可能となり），原審の拒絶の査定において引用された文献である，特開２００７−０８７０８１号公報（平成１９年４月５日出願公開。以下，「引用文献２」という。）には，図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
Ｄ　「【０００１】
　本発明は、顧客と金融機関との金融取引を行うためのシステムであり、特に
顧客が自動取引装置で金融取引を行うための情報を入力すると、該情報をホスト装置に通知して、当該ホスト装置で金融取引の許可判定を行う金融取引システム
Ｅ　「【００５６】
　前記した実施例では、
承認判定部３３７において、各承認者による全会一致の承認を確認すると、第三者により承認を総合的に得ることができたと判定したが、これに限る必要はなく、各承認者による承認の多数決でもって、承認判定を総合的に行うようにしてもよい
（２−３）引用文献３
　本願の優先日前に頒布され（又は電気通信回線を通じて公衆に利用可能となり），原審の拒絶の査定において引用された文献である，特開２０１２−１６８６１６号公報（平成２４年９月６日出願公開。以下，「引用文献３」という。）には，図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
Ｆ　「【０００１】
　本発明は、
機密情報等を含む等の理由により、外部に送信されてはならないメールが誤って外部に送信されることを防止するためのメール誤配信防止装置、メール誤配信防止方法及びメール誤配信防止プログラム
Ｇ　「【０１２２】
　［実施形態３］
　また、
実施形態１では誤配信防止の承認者を一名のみとしていたが、図１３の承認者メールアドレスＦ１に示すように、複数の承認者のメールアドレスを指定することができる
【０１２３】
　
複数の承認者を指定することで、誰か一人でも承認したら対象メールの配信を行う論理和条件方法や、指定された承認者全員が承認しないと対象メールの配信を行わない論理積条件方法、または、指定された承認者の半数以上が承認した場合に対象メールの配信を行う多数決方法などを適用することができる
（３）参考文献に記載されている技術的事項
（３−１）参考文献１
　本願の優先日前に頒布された（又は電気通信回線を通じて公衆に利用可能となった）文献である，国際公開第２０１２／１６４４００号（２０１２年１２月６日公開。以下，「参考文献１」という。）には，図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
Ｈ　「According to a first aspect, the present invention provides a communication method, characterized in that, 
the method comprises:
　
receiving a service request from a requesting party;
　
performing a third-party authentication on the service request according to a gray list and obtaining an authentication result; and
　
processing the service request according to the authentication result.
　Wherein, the gray list includes at least the following three attributes: requesting party, authenticating party and service.
　Wherein, performing the third-party authentication on the service request according to a gray list comprises: forwarding the service request from the requesting party to the authenticating party which authenticates the service request.
　Wherein, processing the service request according to the authentication result comprises: providing the service to the requesting party when the authentication result is Accept; and not providing the service to the requesting party when the authentication result is Reject.
　
Preferably, when the service is not provided to the requesting party, a reject message is sent to the requesting party, in which a reject reason is described.
（訳：第１の態様によれば、本発明は、通信方法を提供し、
この方法は：
　
要求元からサービス要求を受信することと、
　
グレーリストに従い、サービス要求について第三者認証を実行し、認証結果を取得することと、
　
認証結果に従い、サービス要求を処理することと
を含む
　ここで、グレーリストが、要求元、認証者およびサービスという少なくとも３つの属性を含む。
　ここで、グレーリストに従い、サービス要求について第三者認証を実行することが、サービス要求を、要求元から、このサービス要求を認証する認証者へ転送することを含む。
　ここで、認証結果に従い、サービス要求を処理することが、認証結果が承認である場合、サービスを要求元に提供し、認証結果が拒否である場合、サービスを要求元に提供しないことを含む。
　
サービスが要求元に提供されない場合、拒否メッセージが要求元へ送信され、その中に拒否理由が記述されていることが好ましい
（なお，日本語訳として，参考文献の翻訳文である特表２０１４−５１６１７８号公報の【０００８】〜【００１２】の記載を用いた。）
（３−２）参考文献２
　本願の優先日前に頒布された（又は電気通信回線を通じて公衆に利用可能となった）文献である，特表２００５−５０６６０９号公報（平成１７年３月３日出願公開。以下，「参考文献２」という。）には，図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
Ｊ　「【００６３】
［企業管理者の確立］
下記の節は、輸送品視認システム１０を用いて管理者が確立される過程を説明する。好ましい実施形態では、管理者は認定されたユーザだけしか予約すること及びユーザの口座に対して支払い請求を要求することができないことを保証するために、ユーザの口座及び情報を管理する。
（中略）
【００７０】
ステップ３２０では、
下位管理者の権限に対するユーザの要求が許可又は拒否される。好ましい実施形態では、下位管理者に対する要求を許可及び／又は拒否したことがイーメールを通してユーザに送られる。
好ましい実施形態では、管理に対する要求を許可及び拒否する権限を持つ人は、許可及び／又は拒否する理由を説明することができる。この付加的な情報は、イーメール又はユーザのプロフィールのいずれかにより要求を始めたユーザが利用することができる。
（３−３）参考文献３
　本願の優先日前に頒布された（又は電気通信回線を通じて公衆に利用可能となった）文献である，『小林竜巳，“チャット会議ログからの議事録自動作成−領域分析と試作検討−”，第３６回  言語・音声理解と対話処理研究会資料，社団法人人工知能学会，2002年11月07日，p.7-12』（以下，「参考文献３」という。）には，図表とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
Ｋ　「議題とその議題の採択可否（議決）が抽出される．
多数決結果のまとめや賛成反対の理由などの決議理由が抽出されることもある
（４）本件補正発明と引用発明との対比
ア　本件補正発明と引用発明とを対比する。
（ア）引用発明は，クライアント・サーバシステムにおいて，「サーバを用いて，クライアント端末から通知されたサービス提供要求に応じたサービスを提供するサービス提供方法」であるところ，サービス提供要求が送られてきた場合，処理制御ルールに基づいて，多人数のユーザによる承認の必要性を確認し，当該多人数のユーザによる承認結果に応じてサービスを提供するものであるから，多人数承認を容易にするためのコンピュータ実装方法であると言える。
　してみれば，本件補正発明と引用発明は，“多人数認証を容易にするためのコンピュータ実施方法”である点で一致する。
（イ）引用発明の「サーバ」は，「クライアント端末からサービス提供要求が送信されたか否かを判断」するものであるから，本件補正発明の「認証サーバ」に相当する。また，引用発明の「クライアント端末」は，サービス提供要求を送信してくるものであるから，本件補正発明の「プライマリユーザ」に相当する。そして，引用発明の「サービス提供要求」は，本件補正発明の「動作要求」に相当する。
（ウ）引用発明のサーバは，「クライアント端末からサービス提供要求が送信されたか否かを判断」するものであることから，クライアント端末からサービス提供要求を受信することは自明であり，当該要求を受信する際に，何らかの通信機器（本件補正発明の「通信モジュール」に相当）を介して受信するものであることも，当業者にとって自明のことである。
　してみると，上記（イ）の検討内容も踏まえると，本件補正発明と引用発明は，“認証サーバが、通信モジュールを介して、プライマリユーザから動作要求を受信するステップ”を含む点で一致する。
（エ）引用発明の（サービス提供についての承認を行う）「ユーザ」は，本件補正発明の「認証補助ユーザ」に相当する。そして，引用発明の「サービス提供要求で特定されるサービスを享受することについて，承認するか否かの判断を要求」することは，本件補正発明の「認証要求」に相当する。また，引用発明のサーバが，サービス提供についての承認を行うユーザに承認するか否かの判断を要求することは，当該ユーザに対して判断要求を送信することに他ならない。
　してみると，本件補正発明と引用発明は，“認証サーバが，認証要求を認証補助ユーザに送信するステップ”を含む点で一致する。
（オ）引用発明の「承認許諾情報」は，本件補正発明の「応答」に相当する。そして，引用発明のサーバは，「処理制御ルールに示された人数分のユーザから，承認許諾情報を得られたか否かを判断」するものであるから，サービス提供についての承認を行うユーザから，承認許諾情報を受信するものであることは自明である。
　してみると，本件補正発明と引用発明は，“認証サーバが，認証補助ユーザから応答を受信するステップ”を含む点で一致する。
（カ）本件補正発明の「認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率」とは，“認証応答を示す割合”といえるものである。
　そして，引用発明は，「処理制御ルールに示された人数分以上を検出」し，「当該検出したクライアント端末に，サービス提供要求を送信したユーザが，当該サービス提供要求で特定されるサービスを享受することについて，承認するか否かの判断を要求」するものであるところ，引用発明の「処理制御ルールに示された人数分のユーザから，承認許諾情報を得られたか否かを判断」するということは，サーバが，承認許諾を示す割合を計算し，処理制御ルールに示された閾値より大きいかどうかに基づいて，サービス提供要求を承認するか否かを判断していることに他ならない。
　してみると，本件補正発明と引用発明は，後記する点で相違するものの，“認証サーバが，承認応答を示す割合を計算するステップ”及び“認証サーバが，承認応答を示す割合が規定の閾値より大きいかどうかに基づいて，動作要求を許可するかまたは拒否するステップ”を含む点で共通するといえる。
イ　以上（ア）ないし（カ）から，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
（一致点）
　多人数認証を容易にするためのコンピュータ実施方法であって，
　認証サーバが，通信モジュールを介して，プライマリユーザから動作要求を受信するステップと，
　前記認証サーバが，認証要求を認証補助ユーザに送信するステップと，
　前記認証サーバが，前記認証補助ユーザから応答を受信するステップと，
　前記認証サーバが，承認応答を示す割合を計算するステップと，
　前記認証サーバが，前記承認応答を示す割合が既定の閾値より大きいかどうかに基づいて，前記動作要求を許可するかまたは拒否するステップと
を含む，方法。
（相違点１）
　「承認応答を示す割合」について，本件補正発明が「認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率」であるのに対し，引用発明は「承認許諾情報を得られた」人数である点。
（相違点２）
　本件補正発明は，「前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む」ものであるのに対し，引用発明は，承認を拒否する場合の動作について特に明記されていない点。
（５）相違点についての当審の判断
　上記相違点１及び相違点２について検討する。
（５−１）相違点１について
　オンラインシステムにおける取引等を許可する判定に際して，複数の関係者の承認を得ることは，慣用的に行われているものであるところ，
　上記引用文献２の上記Ｄに，
「承認判定部３３７において、各承認者による全会一致の承認を確認すると、第三者により承認を総合的に得ることができたと判定したが、これに限る必要はなく、各承認者による承認の多数決でもって、承認判定を総合的に行うようにしてもよい」と記載され，
　上記引用文献３の上記Ｇの段落【０１２３】に，
「複数の承認者を指定することで、誰か一人でも承認したら対象メールの配信を行う論理和条件方法や、指定された承認者全員が承認しないと対象メールの配信を行わない論理積条件方法、または、指定された承認者の半数以上が承認した場合に対象メールの配信を行う多数決方法などを適用することができる」と記載されるように，
　オンラインシステムにおける取引等を許可する判定に際して，複数の関係者の承認結果を基に承認許諾の基準をどのように設定するかについては，設計者が必要に応じて適宜選択し得る設計的事項に過ぎない。
　してみると，オンラインシステムにおけるサービス提供を許可する判定を行う引用発明において，承認許諾を得られた人数を基に承認するか否かの判断を行うことに替えて，承認許諾の判断を行うユーザ総数に対する承認ユーザの割合を基に承認するか否かの判断を行うよう構成すること，すなわち上記相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点１は格別なものではない。
（５−２）相違点２について
　上記参考文献１の上記Ｈに，
「この方法は：
　要求元からサービス要求を受信することと、
　グレーリストに従い、サービス要求について第三者認証を実行し、認証結果を取得することと、
　認証結果に従い、サービス要求を処理することと
を含む」，
「サービスが要求元に提供されない場合、拒否メッセージが要求元へ送信され、その中に拒否理由が記述されていることが好ましい」
と記載されるように，要求元からのサービス要求について第三者認証を実行し，サービスが要求元に提供されない場合，拒否理由を含む拒否メッセージを当該要求元へ送信する技術については，本願の優先日前において周知の技術であった。
　また，上記参考文献２の上記Ｊに，
「下位管理者の権限に対するユーザの要求が許可又は拒否される。好ましい実施形態では、下位管理者に対する要求を許可及び／又は拒否したことがイーメールを通してユーザに送られる。…（中略）…好ましい実施形態では、管理に対する要求を許可及び拒否する権限を持つ人は、許可及び／又は拒否する理由を説明することができる。この付加的な情報は、イーメール又はユーザのプロフィールのいずれかにより要求を始めたユーザが利用することができる。」
と記載されるように，要求を出したユーザに許可又は拒否をメール等で通知する際に，許可又は拒否の理由を付加することも，本願の優先日前において慣用的に行われている周知の技術であった。
　さらに，上記参考文献３の上記Ｋに，
「多数決結果のまとめや賛成反対の理由などの決議理由が抽出されることもある」
と記載されるように，賛成反対を述べる時に理由を付すことについても，本願の優先日前において日常的に行われている取り決めに過ぎなかった。
　してみると，オンラインシステムにおけるサービス提供を許可する判定を行う引用発明において，サービス提供要求を承認するか否かの判断を行ったユーザが承認を拒否した理由を，サービス提供要求を行ったクライアント端末に送信するように構成すること，すなわち上記相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点２は格別なものではない。　
（５−３）小括
　上記で検討したごとく，相違点１及び相違点２は，いずれも格別のものではなく，そして，これらの相違点を総合的に勘案しても，本件補正発明の奏する作用効果は，上記引用発明，引用文献２及び引用文献３に記載の技術，参考文献１ないし参考文献３に記載の技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本件補正発明は，上記引用発明，引用文献２及び引用文献３に記載の技術，参考文献１ないし参考文献３に記載の技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。　
３　むすび
　以上のように，本件補正は，上記「２　独立特許要件」で指摘したとおり，補正後の請求項１に記載された発明は，特許出願の際独立して特許を受けることができるものではないから，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって，補正却下の決定の結論のとおり決定する。
第３　本願発明について 
１　本願発明の認定
　平成３１年２月２１日にされた手続補正は，上記のとおり却下されたので，本願の請求項に係る発明は，平成３０年５月１日にされた手続補正により補正された特許請求の範囲の請求項１ないし２４に記載された事項により特定されるものであるところ，その請求項１に係る発明（以下，「本願発明」という。）は，以下のとおりのものである。
「多人数認証を容易にするためのコンピュータ実施方法であって、
　認証サーバが、通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
　前記認証サーバが、認証要求を認証補助ユーザに送信するステップと、
　前記認証サーバが、前記認証補助ユーザから応答を受信するステップと、
　前記認証サーバが、認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
　前記認証サーバが、前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含む、方法。」
２　原査定の拒絶の理由
　原査定の拒絶の理由は，この出願の請求項１〜２４に係る発明は，本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献Ａ〜Ｅに記載された事項に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない，というものである。
　引用文献Ａ：特開平１０−２４０６９０号公報
　引用文献Ｂ：米国特許出願公開第２０１３／０１１０６７０号明細書
　引用文献Ｃ：特開２００７−０８７０８１号公報
　引用文献Ｄ：特開２０１２−１６８６１６号公報
　引用文献Ｅ：特開２０１４−０４１６１４号公報
３　引用文献に記載されている技術的事項及び引用発明の認定
　原査定の拒絶の理由に引用された，引用文献Ａ，Ｃ，Ｄおよびその記載事項は，前記「第２　平成３１年２月２１日付けの手続補正についての補正却下の決定」の「２　独立特許要件」の「（２）引用文献に記載されている技術的事項及び引用発明の認定」に記載したとおりである。
４　対比・判断 
　本願発明は，前記「第２　平成３１年２月２１日付けの手続補正についての補正却下の決定」の「２　独立特許要件」で検討した本件補正発明から「前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む」という特定の限定（「第２　平成３１年２月２１日付けの手続補正についての補正却下の決定」の「２　独立特許要件」の（相違点２）に相当）を削除したものである。
　そうすると，本願発明の発明特定事項を全て含む本件補正発明が，上記「第２　平成３１年２月２１日付けの手続補正についての補正却下の決定」の「２　独立特許要件」に記載したとおり，引用発明，引用文献２及び引用文献３に記載の技術，参考文献１ないし参考文献３に記載の技術に基づいて当業者が容易に発明をすることができたものであるから，上記特定の限定を省いた本願発明も同様の理由により，引用発明（原査定の引用文献Ａに記載された発明），引用文献２（原査定の引用文献Ｃ）及び引用文献３（原査定の引用文献Ｄ）に記載の技術に基づいて，当業者が容易に発明をすることができたものである。
第４　むすび
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。
　よって，結論のとおり審決する。