【事件の表示】
　特願２００２−２５２２２４「自動承認判定方法」拒絶査定不服審判事件〔平成１６年　３月２５日出願公開、特開２００４−　９４４１６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯について 
　本願の手続の経緯の概要は、以下のとおりである。  
平成１４年８月３０日　　　出願 
平成１６年１１月３０日付　拒絶理由通知
平成１７年１月２７日付　　意見書・手続補正書
平成１７年４月１１日付　　拒絶査定 
平成１７年５月１９日付　　　審判請求 
平成２０年６月３日付　　　拒絶理由通知 
平成２０年８月８日付　　　意見書・手続補正書 
　　 
　　 
２．本願発明について 
　本願の特許請求の範囲の請求項１に係る発明（以下「本願発明」という。）は、平成２０年８月８日付の手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。  
　　 
　「　　コンピュータにより実行される自動承認判定処理方法であって、
　前記コンピュータが、操作者のランク情報が当該操作者の識別情報に対応して登録された操作者テーブルから、特定の取引のデータを入力した前記操作者の識別情報に対応するランク情報を特定する特定ステップと、
　前記コンピュータが、取引の種別及び当該取引のデータを入力した操作者のランク情報に対応して確率値が登録された確率テーブルから、前記特定の取引の種別及び前記特定の取引のデータを入力した操作者のランク情報に対応する確率値を取得する取得ステップと、
　前記コンピュータが、前記確率テーブルに登録された確率値が取り得る値の範囲内で発生した乱数の値と取得された前記確率値とを比較するステップと、
　前記確率値が上限値である場合には前記乱数の値が前記確率値以下である場合に、前記確率値が下限値である場合には前記乱数の値が前記確率値を超える場合に、前記コンピュータが、前記特定の取引の自動承認を行うと判定するステップと、
　を含む自動承認判定処理方法。　」  
　　 
　　 
３．引用例について 
　　 
（１）引用例１  
　平成２０年６月３日付の当審の拒絶の理由に引用された特開２０００−２５１１２７号公報（以下「引用例１」という。）には、図面とともに、下記（ア）乃至（キ）の事項が記載されている。 
　（ア）「【０００１】【発明の属する技術分野】この発明は、たとえば操作者のランクに応じて操作許可の承認を必要として紙幣、硬貨等の現金を処理する現金処理装置と操作許可承認方法に関する。」  
　（イ）「【００３２】本発明においては、テラーズマシン１ａ，１ｂのＨＤＤ１４８にオペレータがグループ別に登録されると共に、オペレータの承認にあたって付与されるランクに応じたポイントが与えられる。
【００３３】図４は、ＨＤＤ１４８に登録されるオペレータ（操作者）登録状況一覧の構成例を示すものである。オペレータ（操作者）登録状況一覧において、オペレータは、グループＡ、グループＣ、グループＤ，…に別けられて登録される。さらに、オペレータはランクに応じてポイントが与えられる。例えばグループＡにおいては、リーダが７ポイント、サブリーダが５ポイント、メンバＡが３ポイント、メンバＢが３ポイント、メンバＣが３ポイント、アシスタントＡが１ポイント、アシスタントＢが１ポイント、アシスタントＣが１ポイントとなっている。また、各グループを統括するグループ統括長が１０ポイントとなっている。
【００３４】なお、各オペレータが持つ自分のオペレータカードＣには、リーダ、メンバ、アシスタント等の情報が磁気情報として記録されている。」
 　（ウ）「【００３５】次に、このような構成において、オペレータ（操作者）による操作を図５のフローチャートを参照して説明する。
【００３６】まず、現金処理装置のオペレータ（操作者）は、テラーズマシン１ａ（１ｂ）のオペレータカードリード部３０に自分のオペレータカードＣを挿入し、液晶表示部１４５に表示されるメニュー画面より操作をキーボード１４４で選択する（ＳＴ１）。
【００３７】テラーズマシン１ａ（１ｂ）のＭＰＵ１４０は、オペレータカードリード部３０のリード部３１で読み取った磁気情報と上記選択された操作とから承認が必要か否かを判断する（ＳＴ２）ここで、本発明における承認が必要か否かの判断について説明する。」
　（エ）「【００３８】図６は、ＨＤＤ１４８に予め記憶されている承認操作必要判断テーブルの構成例を示すものである。承認操作必要判断テーブルは、承認操作番号、操作内容、承認操作必要な対象オペレータとから構成されている。
【００３９】例えば、選択された操作内容が支払い操作（１取引が１０００万円以上）の場合、承認操作が必要な対象オペレータは図４で説明した操作者登録状況一覧に示すアシスタント以下のランクの操作者であり、この場合の承認条件は後述する承認操作番号（２）である。
【００４０】また、例えば、選択された操作内容が現金装填の場合、承認操作が必要な対象オペレータはメンバ以下のランクの操作者であり、この場合の承認条件は後述する承認操作番号（４）である。
【００４１】また、例えば、選択された操作内容がオペレータ登録／削除の場合、承認操作が必要な対象オペレータは全オペレータであり、この場合の承認条件は後述する承認操作番号（６）である。
【００４２】このようにＭＰＵ１４０は、操作者（オペレータ）がオペレータカードリード部３０に挿入したオペレータカードＣの磁気情報からどのランクの操作者かを確認した後、ＨＤＤ１４８に予め記憶されている承認操作必要判断テーブルを参照して承認が必要か否かを判断する。
【００４３】ステップＳＴ２で承認が必要であった場合、ＭＰＵ１４０は、当該操作に応じて承認条件テーブルを参照して承認の条件を検索／決定する（ＳＴ３）。」 
　（オ）「【００４４】図７は、ＨＤＤ１４８に予め記憶されている上述した承認条件テーブルの構成例である。承認条件テーブルは、選択された操作に応じて承認条件を決定するもので、承認操作番号に対応して承認条件が設定されている。
【００４５】図７において、承認操作番号（１）の場合は承認条件として同グループ全員の承認が必要であり、承認操作番号（２）の場合は承認条件として同グループサブリーダ以上の承認が必要であり、承認操作番号（３）の場合は承認条件として全グループのグループリーダ以上の承認が必要であり、承認操作番号（４）の場合は承認条件として同グループ１０ポイント以上の承認が必要であり、承認操作番号（５）の場合は承認条件として他グループ１０ポイント以上の承認が必要であり、承認操作番号（６）の場合は承認条件としてグループ統括長と全グループリーダの承認が必要である。
【００４６】例えば、選択された操作内容が支払い操作（１取引が１０００万円以上）の場合、承認操作が必要な対象オペレータはアシスタント以下のランクの操作者で承認条件は承認操作番号（２）であり、仮に操作者（オペレータ）がアシスタント以下であれば承認操作番号（２）により同グループサブリーダ以上の承認が必要となる。
【００４７】また、例えば、選択された操作内容が現金装填の場合、承認操作が必要な対象オペレータはメンバ以下のランクの操作者で承認条件は承認操作番号（４）であり、仮に操作者（オペレータ）がメンバ以下であれば承認操作番号（４）により同グループ１０ポイント以上の承認が必要となる。
【００４８】また、例えば、選択された操作内容がオペレータ登録／削除の場合、承認操作が必要な対象オペレータは全オペレータで承認条件は承認操作番号（６）であり、この場合は承認操作番号（６）によりグループ統括長と全グループリーダの承認が必要となる。」
　（カ）「【００４９】ステップＳＴ３で承認の条件が決定された際、ＭＰＵ１４０は、この承認条件を液晶表示部１４５に表示する（ＳＴ４）。
【００５０】図８は、液晶表示部１４５における承認条件の表示例である。例えば、承認条件が承認操作番号（４）であった場合、操作者と同じグループのオペレータによるオペレータカードＣの磁気情報の読み取りが１０ポイント以上になる承認が必要であり、図８の液晶表示部１４５の表示例に示すように、「承認条件表示」、「［条件］：同グループの方から１０ポイント以上の承認が必要」、そして「［承認状況］：ただいまの承認ポイント数  ０ポイント  承認まで後、１０ポイント必要です」と表示される。
【００５１】ここで、承認者となるオペレータによる承認操作が行われる。具体的には、液晶表示部１４５に表示された承認条件に応じた承認者が、自分のオペレータカードＣを図２に示すオペレータカードリード部３０のリード部３１まで挿入して磁気情報を読み取らせる（ＳＴ５）。
【００５２】ＭＰＵ１４０は、リード部３１で読み取った磁気情報から承認条件を満たしたか否かを確認する（ＳＴ６）。
【００５３】例えば、承認条件が承認操作番号（２）であった場合、操作者と同じグループのサブリーダ以上の承認者のオペレータカードＣの磁気情報の読み取りがなければ承認条件が満たされない。また、承認条件が承認操作番号（４）であった場合、操作者と同じグループのオペレータによるオペレータカードＣの磁気情報の読み取りが１０ポイント以上とならなければ承認条件が満たされない。また、承認条件が承認操作番号（６）であった場合、グループ統括長と全グループリーダのオペレータカードＣの磁気情報の読み取りがなければ承認条件が満たされない。
【００５４】ＭＰＵ１４０は承認条件を満たした場合に選択された操作を制御し、オペレータ（操作者）による操作が実行される（ＳＴ７）。
【００５５】なお、ＭＰＵ１４０は、ステップＳＴ２で承認が必要ないと判断した場合、選択された操作を制御し、オペレータ（操作者）による操作が実行される（ＳＴ７）。」
　（キ）「【００５６】以上説明したように上記発明の実施の形態によれば、予めオペレータをグループ別けして各オペレータのランクに応じた承認ポイントを与えて登録することにより、操作に承認が必要な場合に、「グループ全員の承認が必要」、「他のグループの承認が必要」、「承認ポイント数をある数値以上にする必要がある」等の多彩な承認方法を可能とすることができる。」  
　　 
　引用例１の記載を検討すると、まず、上記摘記事項（ア）乃至（キ）によれば、引用例１は、「現金処理装置により実行される操作許可承認方法」である。  
　また、上記摘記事項（イ）乃至（ウ）によれば、引用例１の操作許可承認方法は、「現金処理装置が、操作するオペレータのランクを読み取るステップ」を有している。  
　また、上記摘記事項（イ）乃至（キ）及び図４乃至図７によれば、引用例１の操作許可承認方法は、「現金処理装置が、オペレータにより選択された操作の内容、及び当該操作をしたオペレータのランクに対応した承認条件を判断するステップ」とを有している。
　　 
　してみれば、引用例１には、  
　「現金処理装置により実行される操作許可承認方法であって、
現金処理装置が、操作するオペレータのランクを読み取るステップと、
現金処理装置が、オペレータにより選択された操作の内容、及び当該操作をしたオペレータのランクに対応した承認条件を判断するステップと、
を含む操作許可承認方法。」
の発明（以下「引用例１発明」という。）が開示されている。 
　　 
（２）引用例２  
　同じく、当審の拒絶の理由に引用された特開２００２−０４１７７３号公報（以下「引用例２」という。）には、下記（ク）乃至（シ）の事項が記載されている。 
　（ク）「【０００１】
【発明の属する技術分野】本発明は、決裁業務を自動化する方法、自動決裁装置及び自動決裁プログラムを記録した記録媒体に関する。
【０００２】
【従来の技術】会社や工場では、日常的に発生する種々の決裁業務が多数存在する。例えば、残業、休日出勤の申請、備品の購入の許可、仕事の発注の許可等種々の決裁業務がある。管理者は、それぞれの申請内容を検討して承認するか否かを決める必要がある。
【０００３】
【発明が解決しようとする課題】しかしながら、管理者が１件ずつ申請内容を調べて承認するか否かを判断するのでは、申請件数が多いときには、決裁業務に時間が取られ、他の業務ができなくなるという問題点があった。
【０００４】最近では、ＬＡＮ等を利用して書類を電子メールで送信し、決裁結果を申請者に通知することが行われているが、決済業務そのものの効率化を図ることは実現されていなかった。
【０００５】本発明の課題は、決裁業務を効率化することである。」
　（ケ）「【００１２】この自動決裁システムは、パーソナルコンピュータ等からなる複数の端末装置１１，１２，１３・・・と決裁を行う管理者が利用する端末装置１４とがネットワーク１５を介して接続されている。管理者の端末装置１４には、本発明に係る自動決裁プログラムが格納されている。」
　（コ）「【００１４】次に、図２は、管理者自身が決裁を行う場合と自動決裁プログラムにより自動的に決裁が行われる場合の説明図である。図２（Ａ）に示す管理者自身が決裁を行う場合には、申請者からの申請内容が端末装置１４の画面に表示されるので、管理者が申請内容を検討し、申請を承認、あるいは却下する。このときの申請データ及び判定結果は学習データとして承認学習データ記憶部３１に格納される。また、申請データと決裁結果が集計されてインデックス記憶部３３に格納される。
【００１５】図２（Ｂ）に示すように、自動決裁プログラムが決裁を行う場合には、申請内容と関連するデータを承認学習データ記憶部３１から検索し、過去の申請データから自動決裁が可能か否かを判断する。自動決裁が可能か否かの判断は、学習データの中に申請内容を判定するための基準となる条件を示すデータが存在するか否かを調べることにより行う。基準となるデータが存在する場合には、そのデータに従って申請を承認または却下し、決裁結果を申請データとともに承認学習データ記憶部３１に格納する。さらに、申請データと決裁結果を管理者に通知する。また、承認／却下の記録をインデックス記憶部３３に格納する。」
　（サ）「【００１６】次に、自動決裁プログラムの処理の内容を図３のフローチャートを参照して説明する。申請があると、承認学習データ記憶部３１に記録されている過去に承認／決裁された学習データの中に申請内容と関連する学習データが存在するか否かを判別する（図３，Ｓ１１）。
【００１７】承認学習データ記憶部３１に関連する学習データが存在しない場合には（Ｓ１１，なし）、ステップＳ１２に進み、管理者自身が申請内容の承認、却下を判定するための承認決裁画面を表示させ、同時に申請内容を示す申請データを申請データ記憶部３２に格納する。次に、承認／決裁結果を学習データとして記録することが管理者により指示されたか否かを判別する（Ｓ１４）。これは例外的な決裁のデータを学習データとして記憶しないようにするためである。
【００１８】承認／決裁結果を記録することが管理者により指示されている場合には（Ｓ１３，する）、承認／決裁結果と申請データを対応付けて承認学習データ格納部３２に格納する（Ｓ１４）。その後、申請内容とその申請内容に対する決裁／却下の記録のインデックスをインデックス記憶部３３に記録する（Ｓ１５）。
【００１９】他方、ステップＳ１１で承認学習データ記憶部３１に申請内容と関連する学習データが存在すると判別された場合には（Ｓ１１，あり）、ステップＳ１６に進み過去の申請内容と今回の申請内容を比較する。過去の申請内容から今回の申請を判定できる場合には、その学習データに基づいて申請を承認するか、却下するかを自動的に判定する（Ｓ１７）。申請を承認する場合には（Ｓ１７，承認）、申請内容を示す申請データを申請データ記憶部３２に格納し、承認したことを示すデータを申請データと対応づけて承認学習データ記憶部３１に格納する。
【００２０】また、申請を却下する場合には（Ｓ１７，却下）、申請データを申請データ記憶部３２に格納し、却下したことを示すデータを申請データと対応付けて承認学習データ記憶部３１に格納する。その後、上述したステップＳ１５に進み申請データと決裁／却下のインデックスを記録する。」
　（シ）「【００２１】図４は、承認学習データ記憶部３１に記録される学習データの一例を示す図である。図４は、承認学習データ記憶部３１に従業員単位で申請データを記録した場合の学習データを示しており、従業員毎に申請種別、予算科目、申請数量、決裁結果が記録される。
【００２２】例えば、ケース１として、従業員番号「１１１１１１」の従業員から「１時間３０分」の時間外労働の申請があった場合には、該当する従業員の過去の学習データを承認学習データ記憶部３１から検索する。そして、申請データと検索により得られた該当する従業員の申請種別が「時間外」の学習データを比較する。この場合、承認学習データ記憶部３１には同じ従業員に対して過去に「２時間」の時間外労働の申請が承認されたことが記録されており、今回の申請時間「１時間３０分」は過去に承認した時間より短いので、自動決裁プログラムにより今回の時間外労働の申請が自動的に承認される。そして、申請データと承認結果が承認学習データ記憶部３１に記録される。さらに、自動承認した申請内容が管理者に通知される。
【００２３】また、ケース２として従業員番号「１１１１１１」の従業員から「３時間３０分」の時間外労働の申請があった場合には、該当する従業員の申請種別が「時間外」である過去の学習データが承認学習データ記憶部３１から検索され、申請データと検索された学習データが比較される。この場合、承認データ学習記憶部３１には、同じ従業員に対して過去に「２時間」の時間外労働の申請が承認され、「４時間」の申請が却下されたことが記憶されている。従って、今回の申請時間は、過去に承認された時間外労働の値（この例では、２時間）より大きく、却下された時間外労働の値（この例では、４時間）より小さいので、自動決裁プログラムでは自動的に決裁できないので管理者に判断を委ねる。
【００２４】また、ケース３として従業員番号「１１１１１１」の従業員から「６時間」の時間外労働の申請があった場合には、同様に該当する従業員の過去の時間労働に関する学習データが承認学習データ記憶部３１から検索され、検索された学習データと申請データとの比較が行われる。この場合、同じ従業員に対して過去に４時間の時間外労働の申請が却下されているので、自動決裁プログラムにより６時間の時間外労働の申請は自動的に却下される。この決裁結果と申請データは承認学習データ記憶部３１に格納される。」
　　 
（３）引用例３  
　同じく、当審の拒絶の理由に引用された特開平０１−０９８０６０号公報（以下「引用例３」という。）には、下記（ス）乃至（タ）の事項が記載されている。 
　（ス）「《発明の構成と効果》
　この発明は上記の目的を達成するために、認証処理限度金額以下の小額取引については、予め設定された抽出率に基づきランダムに抽出された取引についてのみホストと交信して実際に認証処理を行なう一方、抽出漏れの取引についてはホストと交信せず模擬的に認証処理を行なうようにしたカード認証用端末装置であって、
　伝送回線を介して受信されたデータ中から前記抽出率に関する情報を検出する手段と、
　前記検出された情報に基づいて、前記抽出率を自動的に更新する手段と、
　を備え、伝送回線を介して外部からのみ抽出率の設定を可能としたことを特徴とするものである。」（第２頁右上欄第１行−第１４行）
　（セ）「また、カード会社から見た各店舗の取引信用の評価度合により、抽出率に関する情報を各店舗毎に異ならせ、これにより実認証処理の割合を制御できるため、ホストコンピュータへのカード認証問合せ量を制御して、効率的なホストの運用を図ることもできる。
　更には、各店舗毎に設定した実認証処理の割合と、その店舗で発生したカード処理ミス、カード犯罪事故件数等により、継続的な各店舗の信用度検証も可能となり、カード犯罪の減少を図ることができる。」（第２頁左下欄第１１行−同頁右下欄第１行）
　（ソ）「これに対して、入力された金額情報が（ステップ５０４）、認証処理限度金額以下と判定された場合（ステップ５０５）、予め設定された抽出率に基づきランダムに抽出された取引についてのみがホストと交信する実認証処理とされ、他方抽出漏れの取引についてはホストと交信しない模擬認証処理とされる。
　すなわち、認証処理限度金額以下と判定された場合（ステップ５０５肯定）、公知の乱数発生処理が行なわれる（ステップ５０６）。
　次いで、この乱数発生処理で得られた乱数の値は、第４図に示される上限バッファ、下限バッファにそれぞれ記憶された基準データ上限、基準データ下限と頂度ウィンドコンパレータの要領で比較される（ステップ５０７，５０８）。
　その結果、得られた乱数の値が上下限データの範囲から外れる場合に限り（ステップ５０７否定，５０８否定）、すなわち予め設定された抽出率に基づきランダムに抽出された取引についてのみが、ホストと交信する実認証処理とされる（ステップ５１８〜５２１）。
　他方、以上のウィンドコンパレータ処理（ステップ５０７，５０８）において、上下限以内におさまると判定された場合には（ステップ５０７肯定、５０８肯定）、第４図に示される模擬認証処理フラグＦをセットした後（ステップ５０９）、以下に述べる模擬認証処理が行なわれる。」（第３頁左下欄第９行−同頁右下欄第１５行）
　（タ）「また、本実施例装置によれば、カード会社から見た各店舗の取引信用の評価度合により、判断基準データを各店舗毎に変えて実認証処理の割合を制御できるため、ホストコンピュータへのカード認証間合せ遣を制御でき、効率的なホストの運用を図ることができる。」（第４頁右下欄第２０行−第５頁左上欄第５行）
　　
４．対比  
　本願発明と引用例１発明とを対比すると、引用例１発明の「現金処理装置」、「オペレータ」は、本願発明の「コンピュータ」、「操作者」に、それぞれ相当する。
　また、引用例１発明の「操作許可承認方法」と、本願発明の「自動承認判定処理方法」とは、いずれも、承認をどのようにするかを判定する処理を行うものであることから、「承認判定処理方法」である点で一致する。  
　また、引用例１発明の「操作するオペレータのランクを読み取るステップ」は、引用例１のオペレータのランクに関する図６の記載、及びオペレータのランクの情報に係る前記摘記事項（イ）、（ウ）の記載を参照すれば、「ランク」とは、オペレータの「アシスタント以下、メンバー以下、全オペレータ」の各ランクの情報であり、当該各ランクの情報が、登録されたオペレータカードの磁気情報からテラーズマシンである現金処理装置が読み取り、その後の承認操作の判断に用いるものであることから、本願発明の「操作者のランク情報を特定する特定ステップ」に相当する。
　また、引用例１発明の「オペレータにより選択された操作の内容」は、本願発明の「特定の取引の種別」に相当することは明らかであることから、引用例１発明の「オペレータにより選択された操作の内容、及び当該操作をしたオペレータのランクに対応した承認条件を判断するステップ」は、「特定の取引の種別及び当該特定の取引の操作をした操作者のランク情報に対応した承認条件を判定するステップ」である点で本願発明と共通する。
　  
　してみれば、本願発明と引用例１発明とは、  
　「コンピュータにより実行される承認判定処理方法であって、
前記コンピュータが、操作者のランク情報を特定する特定ステップと、
前記コンピュータが、特定の取引の種別及び前記特定の取引の操作をした操作者のランク情報に対応した承認条件を判定するステップと、
を含む承認判定処理方法。」 
である点で一致し、以下の点で相違する。  
　　 
　［相違点１］  
　本願発明では、コンピュータが判定する承認が「自動承認」であり、コンピュータが、「取引の種別及び当該取引のデータを入力した操作者のランク情報」に対応して「確率値が登録された確率テーブル」から、「特定の取引の種別及び特定の取引のデータを入力した操作者のランク情報」に対応する「確率値」を取得し、コンピュータが、「確率テーブルに登録された確率値が取り得る値の範囲内で発生した乱数の値と取得された確率値とを比較し、確率値が上限値である場合には乱数の値が確率値以下である場合に、確率値が下限値である場合には乱数の値が確率値を超える場合」に、コンピュータが、特定の取引の「自動承認」を行うと判定するものであるのに対し、引用例１発明は、そうではない点。
　　
　［相違点２］ 
　本願発明では、コンピュータが、「操作者のランク情報が当該操作者の識別情報に対応して登録された操作者テーブル」から、「特定の取引のデータを入力した操作者の識別情報に対応するランク情報」を特定するものであるのに対し、引用例１発明は、そうではない点。
　　
　　
５．当審の判断  
　　 
（１）［相違点１］について  
　引用例２には、上記（ク）乃至（シ）の各摘記事項によれば、「申請件数が多いときには管理者の決裁業務に時間がかかる」という課題に対して、「パーソナルコンピュータ等からなる複数の端末装置と、決裁を行う管理者の端末装置」とにより、「過去の申請データから自動決裁が可能か否かを判断する」ことにより、「決裁業務を効率化」することが記載されており、その具体例として、上記（コ）乃至（シ）の各摘記事項、及び図４の記載を参照すれば、「従業員」から「時間外労働の申請」があった場合には、当該「従業員の従業員番号」と「時間外労働の申請種別」に対応した、「申請数量が２時間の申請が承認され、申請数量が４時間の申請が却下された」という過去の決裁／却下の記録を指標として、「申請数量が１時間３０分の申請は自動的に承認され、３時間３０分の申請は管理者に判断を委ねる」ことが記載されている。
　ここで、引用例２の「パーソナルコンピュータ等からなる複数の端末装置と、決裁を行う管理者の端末装置」は、引用例１発明の「現金処理装置」即ち本願発明の「コンピュータ」に対応し、以下同様に、「従業員」は、「オペレータ」即ち「操作者」に対応し、「時間外労働の申請」が、「選択された操作の内容」即ち「特定の取引の種別」に対応する。
　そして、引用例２の「申請数量が２時間の申請が承認され、申請数量が４時間の申請が却下された」という過去の決裁／却下の記録は、特定の従業員の特定の申請種別に対する信頼性に関する指標にあたるものであることから、引用例２には、特定の従業員の特定の申請種別に対する信頼性に関する指標を用いて自動承認の判定処理を行うことが記載されている。
　してみると、引用例１発明において、「オペレータにより選択された操作の内容、及び当該操作をしたオペレータのランク」という信頼性を用いた承認条件を決定するステップにおいて、引用例２記載事項を適用することにより、特定の従業員、即ちオペレータの、特定の申請種別、即ち操作の内容に対する信頼性に関する指標を用いて自動承認の判定処理を行うよう構成することは、当業者が困難性なく為し得たものであると認められる。
　したがって「特定の取引の種別及び特定の取引の操作をした操作者のランク情報」に関する指標を用いて「自動承認」の判定処理を行うよう構成することは、当業者であれば格別な困難性なく想起し得たものである。
　　
　ここで、負担軽減を目的とした自動承認の判定処理を行う際、引用例２では信頼性に関する指標として過去の決裁／却下の記録を用い、これと申請数量との比較により自動承認の判定処理を行うこととしているが、負担軽減を目的とした自動承認の判定処理を行う手段として、確率を用いて自動承認することが広く知られている。
　例えば引用例３には、上記（ス）乃至（タ）の各摘記事項によれば、カードの認証処理を行うものではあるが、入力された金額情報が認証処理限度金額以下の場合、予め設定された抽出率に基づきランダムに抽出された取引についてのみがホストと交信する実認証処理とされ、抽出漏れの取引についてはホストと交信しない模擬認証処理とすることにより、ホストの運用を効率的にすること、ランダムに抽出する手段として乱数発生処理で得られた乱数の値と基準データ上限、基準データ下限とウインドコンパレータの要領で比較すること、カード会社からみた各店舗の取引信用の評価度合により判断基準データを各店舗毎に変えて実認証処理の割合を制御すること、が記載されている。
　してみると、引用例１発明において、信頼性に関する指標を用いて自動承認の判定処理を行うよう構成する際、信頼性に関する指標として基準データ上限、基準データ下限を採用し、これと乱数発生処理で得られた乱数の値とにより自動承認の判定処理を行うようにすることもまた、当業者であれば格別な困難性なく想起し得たものである。
　　
　ここで、引用例１には、図６の記載及び図７の記載とを参照すれば、「承認操作必要判断テーブル」と、「承認が必要であった場合の承認の条件を決定するための承認条件テーブル」とが記載されているところ、これらのテーブルは、「操作内容」と「オペレータのランク」とにより１つの「承認操作番号」が決まり、当該「承認操作番号」から１つの「承認条件」が決まるものであることから、「オペレータにより選択された操作の内容」と「操作をしたオペレータのランク」とから「承認条件」を判断する「テーブル」に相当することは明らかである。
　
　以上のとおりであることから、［相違点１］に係る、「コンピュータが判定する承認が自動承認であり、コンピュータが、取引の種別及び当該取引のデータを入力した操作者のランク情報に対応して確率値が登録された確率テーブルから、特定の取引の種別及び特定の取引のデータを入力した操作者のランク情報に対応する確率値を取得し、コンピュータが、確率テーブルに登録された確率値が取り得る値の範囲内で発生した乱数の値と取得された確率値とを比較し、確率値が上限値である場合には乱数の値が確率値以下である場合に、確率値が下限値である場合には乱数の値が確率値を超える場合に、コンピュータが、特定の取引の自動承認を行うと判定する」との事項は、引用例１乃至引用例３に記載された事項から、当業者が容易に想到することができたものである。
　　 
（２）［相違点２］について 
　各操作者に関する所定の情報を、操作者のＩＤと所定の情報とを格納したテーブルにより取得することは周知の事項である。
　してみると、「特定の取引のデータを入力した操作者の識別情報に対応するランク情報」を特定する際、「操作者のランク情報が当該操作者の識別情報に対応して登録された操作者テーブル」を用いて特定するよう構成することは、上記した周知の事項を用いることにより、当業者が容易に想到することができたものである。
　　
（３）まとめ　  
　以上のとおり、本願発明における上記相違点１乃至相違点２に係る構成は、引用例１発明、引用例２乃至引用例３の各記載事項及び周知の事項に基づいて、当業者が容易に想到することができたものである。 
　そして、本願発明の作用効果も、引用例１乃至引用例３及び周知技術から当業者が予測できる範囲のものである。  
　　
　　
６．むすび  
　以上のとおり、本願の請求項１に係る発明は、引用例１に記載された発明、引用例２乃至引用例３の各記載事項及び周知の事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　
　　
　よって、結論のとおり審決する。