• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
管理番号 1363902
審判番号 不服2019-2402  
総通号数 248 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-08-28 
種別 拒絶査定不服の審決 
審判請求日 2019-02-21 
確定日 2020-07-06 
事件の表示 特願2016-571410「情報認証のための方法およびシステム」拒絶査定不服審判事件〔平成28年 1月 7日国際公開、WO2016/003605、平成29年 7月27日国内公表、特表2017-520838〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯

本件審判請求に係る出願(以下,「本願」という。)は,2015年6月8日(パリ条約による優先権主張外国庁受理2014年7月3日(以下,「優先日」という。),中華人民共和国)を国際出願日とする出願であって,平成28年12月6日に特許法第184条の5第1項に規定される書面が提出され,平成29年1月31日付けで特許法第184条の4第1項の規定による国際出願日における明細書,請求の範囲,図面(図面の中の説明に限る。)及び要約の翻訳文が提出され,同年2月6日付けで審査請求がなされ,平成30年1月29日付けで拒絶理由通知(同年2月2日発送)がなされ,同年5月1日付けで意見書が提出されるとともに,同日付けで手続補正がなされたが,同年10月19日付けで拒絶査定(同年10月23日謄本送達)がなされた。
これに対して,「原査定を取り消す。本願の発明は特許すべきものとする、との審決を求める。」ことを請求の趣旨として,平成31年2月21日付けで審判請求がなされるとともに,同日付けで手続補正がなされ,そして,令和元年6月13日付けで審査官により特許法第164条第3項に定める報告(前置報告)がなされたものである。

第2 平成31年2月21日にされた手続補正についての補正の却下の決定

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

平成31年2月21日にされた手続補正(以下,「本件補正」という。)を却下する。

[理由]

1 本件補正について

ア 本件補正の内容は,平成30年5月1日にされた手続補正により補正された特許請求の範囲の請求項1ないし請求項24の記載

「 【請求項1】
多人数認証を容易にするためのコンピュータ実施方法であって、
認証サーバが、通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
前記認証サーバが、認証要求を認証補助ユーザに送信するステップと、
前記認証サーバが、前記認証補助ユーザから応答を受信するステップと、
前記認証サーバが、認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
前記認証サーバが、前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含む、方法。
【請求項2】
前記認証要求を送信する前に、前記動作要求を許可するために少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、請求項1に記載の方法。
【請求項3】
少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも1つの既定のルールを前記受信された動作要求に適用するステップを含む、請求項1に記載の方法。
【請求項4】
前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、請求項3に記載の方法。
【請求項5】
前記ルールが、支払金額に基づく、請求項3に記載の方法。
【請求項6】
前記少なくとも1人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、請求項1に記載の方法。
【請求項7】
前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Eメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、請求項1に記載の方法。
【請求項8】
前記動作要求を拒否するステップが、拒否の理由を前記プライマリユーザに送信するステップを含む、請求項1に記載の方法。
【請求項9】
命令を格納する非一時的な記憶媒体であって、
前記命令はプロセッサによって実行されると、前記プロセッサに多人数認証を容易にするための方法を実行させ、前記方法は、
通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
認証要求を認証補助ユーザに送信するステップと、
前記認証補助ユーザから応答を受信するステップと、
認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含む、非一時的な記憶媒体。
【請求項10】
前記方法が、
前記認証要求を送信する前に、前記動作要求を許可するために少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、請求項9に記載の非一時的な記憶媒体。
【請求項11】
少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも1つの既定のルールを前記受信された動作要求に適用するステップを含む、請求項9に記載の非一時的な記憶媒体。
【請求項12】
前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、請求項11に記載の非一時的な記憶媒体。
【請求項13】
前記ルールが、支払金額に基づく、請求項11に記載の非一時的な記憶媒体。
【請求項14】
前記方法が、前記少なくとも1人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、請求項9に記載の非一時的な記憶媒体。
【請求項15】
前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Eメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、請求項9に記載の非一時的な記憶媒体。
【請求項16】
前記動作要求を拒否するステップが、拒否の理由を前記プライマリユーザに送信するステップを含む、請求項9に記載の非一時的な記憶媒体。
【請求項17】
多人数認証を容易にするためのコンピュータシステムであって、
プロセッサと、
前記プロセッサと結合され、命令を格納するメモリであって、前記命令は前記プロセッサによって実行されると、前記プロセッサに方法を実行させ、前記方法は、
通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
認証要求を認証補助ユーザに送信するステップと、
前記認証補助ユーザから応答を受信するステップと、
認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含む、メモリと
を含む、コンピュータシステム。
【請求項18】
前記方法が、
前記認証要求を送信する前に、前記動作要求を許可するために少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、請求項17に記載のコンピュータシステム。
【請求項19】
少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも1つの既定のルールを前記受信された動作要求に適用するステップを含む、請求項17に記載のコンピュータシステム。
【請求項20】
前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、請求項19に記載のコンピュータシステム。
【請求項21】
前記ルールが、支払金額に基づく、請求項19に記載のコンピュータシステム。
【請求項22】
前記方法が、前記少なくとも1人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、請求項17に記載のコンピュータシステム。
【請求項23】
前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Eメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、請求項17に記載のコンピュータシステム。
【請求項24】
前記動作要求を拒否するステップが、拒否の理由を前記プライマリユーザに送信するステップを含む、請求項17に記載のコンピュータシステム。」
(以下,この特許請求の範囲に記載された請求項各項を「補正前の請求項」という。)

を,

「 【請求項1】
多人数認証を容易にするためのコンピュータ実施方法であって、
認証サーバが、通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
前記認証サーバが、認証要求を認証補助ユーザに送信するステップと、
前記認証サーバが、前記認証補助ユーザから応答を受信するステップと、
前記認証サーバが、認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
前記認証サーバが、前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含み、
前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む、方法。
【請求項2】
前記認証要求を送信する前に、前記動作要求を許可するために少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、請求項1に記載の方法。
【請求項3】
少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも1つの既定のルールを前記受信された動作要求に適用するステップを含む、請求項1に記載の方法。
【請求項4】
前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、請求項3に記載の方法。
【請求項5】
前記ルールが、支払金額に基づく、請求項3に記載の方法。
【請求項6】
前記少なくとも1人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、請求項1に記載の方法。
【請求項7】
前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Eメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、請求項1に記載の方法。
【請求項8】
命令を格納する非一時的な記憶媒体であって、
前記命令はプロセッサによって実行されると、前記プロセッサに多人数認証を容易にするための方法を実行させ、前記方法は、
通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
認証要求を認証補助ユーザに送信するステップと、
前記認証補助ユーザから応答を受信するステップと、
認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含み、
前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む、非一時的な記憶媒体。
【請求項9】
前記方法が、
前記認証要求を送信する前に、前記動作要求を許可するために少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、請求項8に記載の非一時的な記憶媒体。
【請求項10】
少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも1つの既定のルールを前記受信された動作要求に適用するステップを含む、請求項8に記載の非一時的な記憶媒体。
【請求項11】
前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、請求項10に記載の非一時的な記憶媒体。
【請求項12】
前記ルールが、支払金額に基づく、請求項10に記載の非一時的な記憶媒体。
【請求項13】
前記方法が、前記少なくとも1人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、請求項8に記載の非一時的な記憶媒体。
【請求項14】
前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Eメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、請求項8に記載の非一時的な記憶媒体。
【請求項15】
多人数認証を容易にするためのコンピュータシステムであって、
プロセッサと、
前記プロセッサと結合され、命令を格納するメモリであって、前記命令は前記プロセッサによって実行されると、前記プロセッサに方法を実行させ、前記方法は、
通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
認証要求を認証補助ユーザに送信するステップと、
前記認証補助ユーザから応答を受信するステップと、
認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含み、
前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む、メモリと
を含む、コンピュータシステム。
【請求項16】
前記方法が、
前記認証要求を送信する前に、前記動作要求を許可するために少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップ
をさらに含む、請求項15に記載のコンピュータシステム。
【請求項17】
少なくとも1人の認証補助ユーザからの認証が必要かどうかを判断するステップが、少なくとも1つの既定のルールを前記受信された動作要求に適用するステップを含む、請求項15に記載のコンピュータシステム。
【請求項18】
前記ルールが、前記動作要求と関連付けられた取引タイプに基づく、請求項17に記載のコンピュータシステム。
【請求項19】
前記ルールが、支払金額に基づく、請求項17に記載のコンピュータシステム。
【請求項20】
前記方法が、前記少なくとも1人の認証補助ユーザから受信された前記応答が、既定の閾値より大きい承認の尺度を示すかどうかを判断するステップをさらに含む、請求項15に記載のコンピュータシステム。
【請求項21】
前記認証要求を前記認証補助ユーザに送信するステップが、電話番号、Eメールまたはインスタントメッセージに基づくテキストメッセージを前記認証補助ユーザに送信するステップを含む、請求項15に記載のコンピュータシステム。」
(以下,この特許請求の範囲に記載された請求項各項を「補正後の請求項」という。)
(なお,下線は,補正箇所を示すものとして,請求人が付与したものである。)

に補正するものである。

イ そして,本件補正は,補正前の請求項1,9,17に,それぞれ補正前の請求項8,16,24に記載されている「前記動作要求を拒否するステップが、拒否の理由を前記プライマリユーザに送信するステップを含む」という事項を追加し,さらに,「拒否の理由」を「認証を拒否する前記認証補助ユーザによって返された拒否の理由」と限定するものであるから,特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。

2 独立特許要件

以上のように,本件補正後の請求項1に記載された発明(以下,「本件補正発明」という。)は,補正前の請求項1に対して,限定的減縮を行ったものと認められる。そこで,本件補正発明が特許出願の際独立して特許を受けることができるものであるか(特許法第17条の2第6項において準用する同法第126条第7項の規定に適合するか)以下に検討する。

(1)補正後の発明

本件補正発明は,前記「1 本件補正について」において,補正後の請求項1として引用した,次の記載のとおりのものである。

「多人数認証を容易にするためのコンピュータ実施方法であって、
認証サーバが、通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
前記認証サーバが、認証要求を認証補助ユーザに送信するステップと、
前記認証サーバが、前記認証補助ユーザから応答を受信するステップと、
前記認証サーバが、認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
前記認証サーバが、前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含み、
前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む、方法。」

(2)引用文献に記載されている技術的事項及び引用発明の認定

(2-1)引用文献1

本願の優先日前に頒布され(又は電気通信回線を通じて公衆に利用可能となり),原審の拒絶の査定の理由である上記平成30年1月29日付けの拒絶理由通知において引用された文献である,特開平10-240690号公報(平成10年9月11日出願公開。以下,「引用文献1」という。)には,図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

A 「【請求項10】サーバを用いて、クライアント端末から通知されたサービス提供要求に応じたサービスを提供するサービス提供方法であって、ユーザの識別情報あるいはレベル情報と、当該ユーザへのサービス提供の可否を定めるルールと、の対応関係を示す管理テーブルから、前記サービス提供要求を通知したクライアント端末のユーザの識別情報あるいはレベル情報に対応付けられたルールを検索するルール検索ステップと、前記ルール検索ステップで検出したルールが、サービス提供に承認を必要としない旨示している場合は、前記サービス提供要求に応じた処理を実行し、サービス提供に他のユーザの承認を必要とする旨示している場合は、当該他のユーザの承認を受けた後に、前記サービス提供要求に応じた処理を実行し、そして、サービス提供を認めない旨示している場合は、前記サービス提供要求に応じた処理を実行することなく、その旨を前記サービス提供要求を通知したクライアント端末に通知するサービス提供実行ステップと、を有することを特徴とするサービス提供方法。」

B 「【0080】次に、サーバ2の機能ブロック構成について説明する。
【0081】サーバ2は、図6に示すように、クライアント端末1から送信されたログイン要求にしたがいログイン処理を行うログイン処理部201と、ログインしているクライアント端末1のユーザに関する情報を記憶するログイン管理テーブル202と、クライアント端末1から送信されたログアウト要求にしたがいログアウト処理を行うログアウト処理部203と、クライアント端末1へのサービス提供を管理するサービス管理部204と、を有する。
(中略)
【0088】サービス管理部204は、上述したように、クライアント端末1へのサービス提供を管理するものであり、サービス管理処理部205と、サービス承認要求処理部206と、サービス提供処理部207と、を有する。」

C 「【0124】次に、サーバ2の動作について説明する。
【0125】図10および図11はサーバ2の動作を説明するためのフロー図である。
【0126】まず、図10に示すフローにおいて、ログイン処理部201は、クライアント端末1からログイン要求が送信されたか否かを判断する(ステップ3001)。ログイン要求が送られてきた場合はステップ3002に移行し、送られてきていない場合はステップ3005に移行する。
(中略)
【0132】ステップ3005では、サービス管理処理部205は、クライアント端末1からサービス提供要求が送信されたか否かを判断する。サービス提供要求が送られてきた場合はステップ3006に移行し、送られてきていない場合は図11に示すフローのステップ3020に移行する。
(中略)
【0138】ステップ3009では、サービス承認要求処理部206は、ステップ3008において、サービス管理処理部205から送られてきた処理制御ルールを解析する。そして、解析結果に応じた処理を行う。
(中略)
【0143】さらに、解析した処理制御ルールが、当該処理制御ルールに対応付けられたサービスの提供を受けるために、あるユーザの承認が必要であることを意味する場合は、当該ユーザが使用するクライアント端末1の識別子をログイン管理テーブル202に記憶されたテーブルから検索し(ステップ3012)、その後、ステップ3013に移行する。
【0144】たとえば、ログイン管理テーブル202に記憶されたテーブルが図7に示すものであるとする。
【0145】ここで、ステップ3008でサービス管理処理部205から送られてきたクライアント端末1の識別子が「11」、サービス識別子が「C」、そして処理制御ルールが「レベル0の承認が△人必要」である場合、ユーザ権限レベル「0」に対応付けられたクライアント端末1の全てを、図7に示すテーブルから検出することになる。
(中略)
【0148】たとえば、ログイン管理テーブル202に記憶されたテーブルが図7に示すものである場合、ステップ3008でサービス管理処理部205から送られてきた処理制御ルールが「レベル0の承認が△人必要」であるときには、ユーザ権限レベル「0」に対応付けられたクライアント端末1が△数以上検出できたか否かを判断する。また、ステップ3008でサービス管理処理部205から送られてきた処理制御ルールが「”taro”の承認が必要」であるときには、ユーザ識別子「taro」に対応付けられたクライアント端末1が検出できたか否かを判断する。
(中略)
【0150】一方、必要数分のクライアント端末が検出できた場合は、当該検出したクライアント端末1に、ステップ3005でサービス提供要求を送信したユーザが、当該サービス提供要求で特定されるサービスを享受することについて、承認するか否かの判断を要求する(ステップ3015)。
【0151】その後、承認要求を行ったクライアント端末1から返答(承認情報)がくるのを待つ(ステップ3016)。
【0152】次に、サービス承認要求処理部206は、処理制御ルールに示されたユーザ、あるいは処理制御ルールに示された人数分のユーザから、承認許諾情報を得られたか否かを判断する(ステップ3017)。得られている場合はステップ3010に移行する。一方、得られていない場合は、その旨をステップ3005でサービス提供要求を送信したクライアント端末1に通知し(ステップ3018)、その後、ステップ3020に移行する。
【0153】ステップ3010での処理実行後、ステップ3011では、サービス提供処理部207は、ステップ3010において、サービス承認要求部206から送られてきたサービス識別子で特定されるサービスを実行し、同じくサービス承認要求部206から送られてきたクライアント端末1の識別子で特定されるクライアント端末1に提供する。その後、ステップ3020に移行する。」

イ 上記AないしCの記載内容(特に,下線部を参照)からすると,上記引用文献1には,次の発明(以下,「引用発明」という。)が記載されているものと認められる。

「サーバを用いて,クライアント端末から通知されたサービス提供要求に応じたサービスを提供するサービス提供方法であって,
サーバのログイン処理部は,クライアント端末からログイン要求が送信されたか否かを判断し,
ログイン要求が送られてきた場合,サーバのサービス管理処理部は,クライアント端末からサービス提供要求が送信されたか否かを判断し,
サービス提供要求が送られてきた場合,サーバのサービス承認要求処理部は,サービス管理処理部から送られてきた処理制御ルールを解析し,解析した処理制御ルールが,当該処理制御ルールに対応付けられたサービスの提供を受けるために,あるユーザの承認が必要であることを意味する場合は,当該ユーザが使用するクライアント端末の識別子をテーブルから検索し,そして処理制御ルールに対応付けられたクライアント端末をテーブルから検出(処理制御ルールに示された人数分以上を検出)し,当該検出したクライアント端末に,サービス提供要求を送信したユーザが,当該サービス提供要求で特定されるサービスを享受することについて,承認するか否かの判断を要求し,
サーバのサービス承認要求処理部は,処理制御ルールに示された人数分のユーザから,承認許諾情報を得られたか否かを判断し,
承認許諾情報を得られている場合は,サーバのサービス提供処理部は,サービスを実行し,クライアント端末に提供する
ことを含むサービス提供方法。」

(2-2)引用文献2

本願の優先日前に頒布され(又は電気通信回線を通じて公衆に利用可能となり),原審の拒絶の査定において引用された文献である,特開2007-087081号公報(平成19年4月5日出願公開。以下,「引用文献2」という。)には,図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

D 「【0001】
本発明は、顧客と金融機関との金融取引を行うためのシステムであり、特に顧客が自動取引装置で金融取引を行うための情報を入力すると、該情報をホスト装置に通知して、当該ホスト装置で金融取引の許可判定を行う金融取引システムに関するものである。」

E 「【0056】
前記した実施例では、承認判定部337において、各承認者による全会一致の承認を確認すると、第三者により承認を総合的に得ることができたと判定したが、これに限る必要はなく、各承認者による承認の多数決でもって、承認判定を総合的に行うようにしてもよい。」

(2-3)引用文献3

本願の優先日前に頒布され(又は電気通信回線を通じて公衆に利用可能となり),原審の拒絶の査定において引用された文献である,特開2012-168616号公報(平成24年9月6日出願公開。以下,「引用文献3」という。)には,図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

F 「【0001】
本発明は、機密情報等を含む等の理由により、外部に送信されてはならないメールが誤って外部に送信されることを防止するためのメール誤配信防止装置、メール誤配信防止方法及びメール誤配信防止プログラムに関する。」

G 「【0122】
[実施形態3]
また、実施形態1では誤配信防止の承認者を一名のみとしていたが、図13の承認者メールアドレスF1に示すように、複数の承認者のメールアドレスを指定することができる。
【0123】
複数の承認者を指定することで、誰か一人でも承認したら対象メールの配信を行う論理和条件方法や、指定された承認者全員が承認しないと対象メールの配信を行わない論理積条件方法、または、指定された承認者の半数以上が承認した場合に対象メールの配信を行う多数決方法などを適用することができる。」

(3)参考文献に記載されている技術的事項

(3-1)参考文献1

本願の優先日前に頒布された(又は電気通信回線を通じて公衆に利用可能となった)文献である,国際公開第2012/164400号(2012年12月6日公開。以下,「参考文献1」という。)には,図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

H 「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.
(訳:第1の態様によれば、本発明は、通信方法を提供し、この方法は:
要求元からサービス要求を受信することと、
グレーリストに従い、サービス要求について第三者認証を実行し、認証結果を取得することと、
認証結果に従い、サービス要求を処理することと
を含むことを特徴とする。
ここで、グレーリストが、要求元、認証者およびサービスという少なくとも3つの属性を含む。
ここで、グレーリストに従い、サービス要求について第三者認証を実行することが、サービス要求を、要求元から、このサービス要求を認証する認証者へ転送することを含む。
ここで、認証結果に従い、サービス要求を処理することが、認証結果が承認である場合、サービスを要求元に提供し、認証結果が拒否である場合、サービスを要求元に提供しないことを含む。
サービスが要求元に提供されない場合、拒否メッセージが要求元へ送信され、その中に拒否理由が記述されていることが好ましい。)」(3頁16行?4頁3行)
(なお,日本語訳として,参考文献の翻訳文である特表2014-516178号公報の【0008】?【0012】の記載を用いた。)

(3-2)参考文献2

本願の優先日前に頒布された(又は電気通信回線を通じて公衆に利用可能となった)文献である,特表2005-506609号公報(平成17年3月3日出願公開。以下,「参考文献2」という。)には,図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

J 「【0063】
[企業管理者の確立]
下記の節は、輸送品視認システム10を用いて管理者が確立される過程を説明する。好ましい実施形態では、管理者は認定されたユーザだけしか予約すること及びユーザの口座に対して支払い請求を要求することができないことを保証するために、ユーザの口座及び情報を管理する。
(中略)
【0070】
ステップ320では、下位管理者の権限に対するユーザの要求が許可又は拒否される。好ましい実施形態では、下位管理者に対する要求を許可及び/又は拒否したことがイーメールを通してユーザに送られる。別の方法では、輸送品視認システム10内のユーザのプロフィールが更新されて、要求を許可又は拒否したことが反映され、ユーザは自分のプロフィールを確認して要求の状態を判断しなければならない。当業者は、要求の状態を提供する他の方法はこの技術分野では周知であり、本発明と共に使用できることは容易に認識されよう。好ましい実施形態では、管理に対する要求を許可及び拒否する権限を持つ人は、許可及び/又は拒否する理由を説明することができる。この付加的な情報は、イーメール又はユーザのプロフィールのいずれかにより要求を始めたユーザが利用することができる。例えば、管理権限に対するユーザの要求が拒否される場合、ユーザは自分のプロフィールの中のリンクをクリックして、要求が拒否された理由に関する付加的な情報を得ることができる。」

(3-3)参考文献3

本願の優先日前に頒布された(又は電気通信回線を通じて公衆に利用可能となった)文献である,『小林竜巳,“チャット会議ログからの議事録自動作成-領域分析と試作検討-”,第36回 言語・音声理解と対話処理研究会資料,社団法人人工知能学会,2002年11月07日,p.7-12』(以下,「参考文献3」という。)には,図表とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

K 「議題とその議題の採択可否(議決)が抽出される.
多数決結果のまとめや賛成反対の理由などの決議理由が抽出されることもある.」(10頁表3.7「討議内容の会議タイプ別議事録作成ノウハウの分析結果」の「会議タイプ:議決」の「議事録作成ノウハウ(討議内容)欄」)

(4)本件補正発明と引用発明との対比

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

(ア)引用発明は,クライアント・サーバシステムにおいて,「サーバを用いて,クライアント端末から通知されたサービス提供要求に応じたサービスを提供するサービス提供方法」であるところ,サービス提供要求が送られてきた場合,処理制御ルールに基づいて,多人数のユーザによる承認の必要性を確認し,当該多人数のユーザによる承認結果に応じてサービスを提供するものであるから,多人数承認を容易にするためのコンピュータ実装方法であると言える。
してみれば,本件補正発明と引用発明は,“多人数認証を容易にするためのコンピュータ実施方法”である点で一致する。

(イ)引用発明の「サーバ」は,「クライアント端末からサービス提供要求が送信されたか否かを判断」するものであるから,本件補正発明の「認証サーバ」に相当する。また,引用発明の「クライアント端末」は,サービス提供要求を送信してくるものであるから,本件補正発明の「プライマリユーザ」に相当する。そして,引用発明の「サービス提供要求」は,本件補正発明の「動作要求」に相当する。

(ウ)引用発明のサーバは,「クライアント端末からサービス提供要求が送信されたか否かを判断」するものであることから,クライアント端末からサービス提供要求を受信することは自明であり,当該要求を受信する際に,何らかの通信機器(本件補正発明の「通信モジュール」に相当)を介して受信するものであることも,当業者にとって自明のことである。
してみると,上記(イ)の検討内容も踏まえると,本件補正発明と引用発明は,“認証サーバが、通信モジュールを介して、プライマリユーザから動作要求を受信するステップ”を含む点で一致する。

(エ)引用発明の(サービス提供についての承認を行う)「ユーザ」は,本件補正発明の「認証補助ユーザ」に相当する。そして,引用発明の「サービス提供要求で特定されるサービスを享受することについて,承認するか否かの判断を要求」することは,本件補正発明の「認証要求」に相当する。また,引用発明のサーバが,サービス提供についての承認を行うユーザに承認するか否かの判断を要求することは,当該ユーザに対して判断要求を送信することに他ならない。
してみると,本件補正発明と引用発明は,“認証サーバが,認証要求を認証補助ユーザに送信するステップ”を含む点で一致する。

(オ)引用発明の「承認許諾情報」は,本件補正発明の「応答」に相当する。そして,引用発明のサーバは,「処理制御ルールに示された人数分のユーザから,承認許諾情報を得られたか否かを判断」するものであるから,サービス提供についての承認を行うユーザから,承認許諾情報を受信するものであることは自明である。
してみると,本件補正発明と引用発明は,“認証サーバが,認証補助ユーザから応答を受信するステップ”を含む点で一致する。

(カ)本件補正発明の「認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率」とは,“認証応答を示す割合”といえるものである。
そして,引用発明は,「処理制御ルールに示された人数分以上を検出」し,「当該検出したクライアント端末に,サービス提供要求を送信したユーザが,当該サービス提供要求で特定されるサービスを享受することについて,承認するか否かの判断を要求」するものであるところ,引用発明の「処理制御ルールに示された人数分のユーザから,承認許諾情報を得られたか否かを判断」するということは,サーバが,承認許諾を示す割合を計算し,処理制御ルールに示された閾値より大きいかどうかに基づいて,サービス提供要求を承認するか否かを判断していることに他ならない。
してみると,本件補正発明と引用発明は,後記する点で相違するものの,“認証サーバが,承認応答を示す割合を計算するステップ”及び“認証サーバが,承認応答を示す割合が規定の閾値より大きいかどうかに基づいて,動作要求を許可するかまたは拒否するステップ”を含む点で共通するといえる。

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

(一致点)

多人数認証を容易にするためのコンピュータ実施方法であって,
認証サーバが,通信モジュールを介して,プライマリユーザから動作要求を受信するステップと,
前記認証サーバが,認証要求を認証補助ユーザに送信するステップと,
前記認証サーバが,前記認証補助ユーザから応答を受信するステップと,
前記認証サーバが,承認応答を示す割合を計算するステップと,
前記認証サーバが,前記承認応答を示す割合が既定の閾値より大きいかどうかに基づいて,前記動作要求を許可するかまたは拒否するステップと
を含む,方法。

(相違点1)

「承認応答を示す割合」について,本件補正発明が「認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率」であるのに対し,引用発明は「承認許諾情報を得られた」人数である点。

(相違点2)

本件補正発明は,「前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む」ものであるのに対し,引用発明は,承認を拒否する場合の動作について特に明記されていない点。

(5)相違点についての当審の判断

上記相違点1及び相違点2について検討する。

(5-1)相違点1について

オンラインシステムにおける取引等を許可する判定に際して,複数の関係者の承認を得ることは,慣用的に行われているものであるところ,
上記引用文献2の上記Dに,
「承認判定部337において、各承認者による全会一致の承認を確認すると、第三者により承認を総合的に得ることができたと判定したが、これに限る必要はなく、各承認者による承認の多数決でもって、承認判定を総合的に行うようにしてもよい」と記載され,
上記引用文献3の上記Gの段落【0123】に,
「複数の承認者を指定することで、誰か一人でも承認したら対象メールの配信を行う論理和条件方法や、指定された承認者全員が承認しないと対象メールの配信を行わない論理積条件方法、または、指定された承認者の半数以上が承認した場合に対象メールの配信を行う多数決方法などを適用することができる」と記載されるように,
オンラインシステムにおける取引等を許可する判定に際して,複数の関係者の承認結果を基に承認許諾の基準をどのように設定するかについては,設計者が必要に応じて適宜選択し得る設計的事項に過ぎない。

してみると,オンラインシステムにおけるサービス提供を許可する判定を行う引用発明において,承認許諾を得られた人数を基に承認するか否かの判断を行うことに替えて,承認許諾の判断を行うユーザ総数に対する承認ユーザの割合を基に承認するか否かの判断を行うよう構成すること,すなわち上記相違点1に係る構成とすることは,当業者が容易に想到し得たことである。

よって,相違点1は格別なものではない。

(5-2)相違点2について

上記参考文献1の上記Hに,
「この方法は:
要求元からサービス要求を受信することと、
グレーリストに従い、サービス要求について第三者認証を実行し、認証結果を取得することと、
認証結果に従い、サービス要求を処理することと
を含む」,
「サービスが要求元に提供されない場合、拒否メッセージが要求元へ送信され、その中に拒否理由が記述されていることが好ましい」
と記載されるように,要求元からのサービス要求について第三者認証を実行し,サービスが要求元に提供されない場合,拒否理由を含む拒否メッセージを当該要求元へ送信する技術については,本願の優先日前において周知の技術であった。
また,上記参考文献2の上記Jに,
「下位管理者の権限に対するユーザの要求が許可又は拒否される。好ましい実施形態では、下位管理者に対する要求を許可及び/又は拒否したことがイーメールを通してユーザに送られる。…(中略)…好ましい実施形態では、管理に対する要求を許可及び拒否する権限を持つ人は、許可及び/又は拒否する理由を説明することができる。この付加的な情報は、イーメール又はユーザのプロフィールのいずれかにより要求を始めたユーザが利用することができる。」
と記載されるように,要求を出したユーザに許可又は拒否をメール等で通知する際に,許可又は拒否の理由を付加することも,本願の優先日前において慣用的に行われている周知の技術であった。
さらに,上記参考文献3の上記Kに,
「多数決結果のまとめや賛成反対の理由などの決議理由が抽出されることもある」
と記載されるように,賛成反対を述べる時に理由を付すことについても,本願の優先日前において日常的に行われている取り決めに過ぎなかった。

してみると,オンラインシステムにおけるサービス提供を許可する判定を行う引用発明において,サービス提供要求を承認するか否かの判断を行ったユーザが承認を拒否した理由を,サービス提供要求を行ったクライアント端末に送信するように構成すること,すなわち上記相違点2に係る構成とすることは,当業者が容易に想到し得たことである。

よって,相違点2は格別なものではない。

(5-3)小括

上記で検討したごとく,相違点1及び相違点2は,いずれも格別のものではなく,そして,これらの相違点を総合的に勘案しても,本件補正発明の奏する作用効果は,上記引用発明,引用文献2及び引用文献3に記載の技術,参考文献1ないし参考文献3に記載の技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。

したがって,本件補正発明は,上記引用発明,引用文献2及び引用文献3に記載の技術,参考文献1ないし参考文献3に記載の技術に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により,特許出願の際独立して特許を受けることができない。

3 むすび

以上のように,本件補正は,上記「2 独立特許要件」で指摘したとおり,補正後の請求項1に記載された発明は,特許出願の際独立して特許を受けることができるものではないから,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

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

第3 本願発明について

1 本願発明の認定

平成31年2月21日にされた手続補正は,上記のとおり却下されたので,本願の請求項に係る発明は,平成30年5月1日にされた手続補正により補正された特許請求の範囲の請求項1ないし24に記載された事項により特定されるものであるところ,その請求項1に係る発明(以下,「本願発明」という。)は,以下のとおりのものである。

「多人数認証を容易にするためのコンピュータ実施方法であって、
認証サーバが、通信モジュールを介して、プライマリユーザから動作要求を受信するステップと、
前記認証サーバが、認証要求を認証補助ユーザに送信するステップと、
前記認証サーバが、前記認証補助ユーザから応答を受信するステップと、
前記認証サーバが、認証補助ユーザの総数に対する承認応答を示す認証補助ユーザの数の比率を計算するステップと、
前記認証サーバが、前記比率が既定の閾値より大きいかどうかに基づいて、前記動作要求を許可するかまたは拒否するステップと
を含む、方法。」

2 原査定の拒絶の理由

原査定の拒絶の理由は,この出願の請求項1?24に係る発明は,本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献A?Eに記載された事項に基づいて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない,というものである。

引用文献A:特開平10-240690号公報
引用文献B:米国特許出願公開第2013/0110670号明細書
引用文献C:特開2007-087081号公報
引用文献D:特開2012-168616号公報
引用文献E:特開2014-041614号公報

3 引用文献に記載されている技術的事項及び引用発明の認定

原査定の拒絶の理由に引用された,引用文献A,C,Dおよびその記載事項は,前記「第2 平成31年2月21日付けの手続補正についての補正却下の決定」の「2 独立特許要件」の「(2)引用文献に記載されている技術的事項及び引用発明の認定」に記載したとおりである。

4 対比・判断

本願発明は,前記「第2 平成31年2月21日付けの手続補正についての補正却下の決定」の「2 独立特許要件」で検討した本件補正発明から「前記動作要求を拒否するステップが、認証を拒否する前記認証補助ユーザによって返された拒否の理由を前記プライマリユーザに送信するステップを含む」という特定の限定(「第2 平成31年2月21日付けの手続補正についての補正却下の決定」の「2 独立特許要件」の(相違点2)に相当)を削除したものである。

そうすると,本願発明の発明特定事項を全て含む本件補正発明が,上記「第2 平成31年2月21日付けの手続補正についての補正却下の決定」の「2 独立特許要件」に記載したとおり,引用発明,引用文献2及び引用文献3に記載の技術,参考文献1ないし参考文献3に記載の技術に基づいて当業者が容易に発明をすることができたものであるから,上記特定の限定を省いた本願発明も同様の理由により,引用発明(原査定の引用文献Aに記載された発明),引用文献2(原査定の引用文献C)及び引用文献3(原査定の引用文献D)に記載の技術に基づいて,当業者が容易に発明をすることができたものである。

第4 むすび

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

よって,結論のとおり審決する。

 
別掲
 
審理終結日 2020-02-05 
結審通知日 2020-02-06 
審決日 2020-02-25 
出願番号 特願2016-571410(P2016-571410)
審決分類 P 1 8・ 575- Z (G06F)
P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 岸野 徹  
特許庁審判長 石井 茂和
特許庁審判官 松平 英
田中 秀人
発明の名称 情報認証のための方法およびシステム  
代理人 大貫 敏史  
代理人 江口 昭彦  
代理人 稲葉 良幸  
代理人 内藤 和彦  
  • この表をプリントする

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