【事件の表示】
　特願２００２−１７８１４「現金受付配送システム及びその制御用プログラム」拒絶査定不服審判事件〔平成１５年７月３１日出願公開，特開２００３−２１６８１３〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１．手続の経緯
　本願は，平成１４年１月２８日の出願であって，平成１９年９月２８日付けの拒絶理由通知に対して，同年１１月２９日付けで意見書が提出されるとともに同日付けで手続補正がなされたが，平成２０年１月１１日付けで拒絶査定がなされ，この拒絶の査定を不服として，同年２月２１日に拒絶査定に対する審判請求がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下「本願発明」という。）は，平成１９年１１月２９日付けの手続補正により補正された明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された次の事項により特定されるものである。
　「現金要求の受付を行い，受付データの管理を行う現金要求受付システムを含む現金受付配送システムにおいて，
　前記現金要求受付システムは，
　予め顧客毎に定められた配送可能日数の情報を格納する配送日数情報データベースと，
　顧客からの現金要求を受け付ける場合，顧客の特定後，前記配送日数情報データベースを参照し，現在日時と配送要求日時との日数が，該顧客に対応する配送可能日数以上ある場合に配送可能として前記現金要求を受け付け，要求内容を金種・日付・配送先を含む電子化データの受付情報として出力する受付処理部と，
　を備えたことを特徴とする現金受付配送システム。」
　
３．引用例
　これに対して，原査定の拒絶の理由に引用された特開２０００−２７６５４４号公報（以下「引用例１」という。）には，以下ａ．−ｉ．の記載がある。
ａ．「【０００２】
【従来の技術】従来，銀行が顧客（企業等）から現金の支給依頼を受け付ける場合，電話，ファクシミリ等により人的対応をしていた。また，例えば給与の給付に使用される現金の支給依頼である場合には，金種毎の必要数等が指定されるため，銀行では，各顧客から受け付けた現金の支給依頼について，支払日別に，金種別に集計等していた。また，支給日前日には，集計結果に基づいて，銀行員が現金を仕分けして，袋詰めを行っていた。また，顧客からの支給金額分の資金の確保（例えば，顧客の口座から銀行の口座への支給金額分の資金の振り込み等）は，各営業店がそれぞれ行っていた。」
ｂ．「【０００３】
【発明が解決しようとする課題】しかし，上記のようなシステムでは，現金の支給依頼の受付・確認，現金の仕分け・袋詰め等の処理は人手によるものであるため，作業効率が悪く，ミスも多い。また，支給した分の資金については，各営業店がそれぞれ資金確保を行わなければならず煩雑であった。
【０００４】本発明は，上述した事情に鑑みてなされたもので，現金の支給依頼の受付処理及び受付に伴う種々の処理を効率良く行う銀行センタ等に関する。」
ｃ．「【０００５】
【課題を解決するための手段】上記目的を達成するため，本発明の第１の観点に係る銀行センタは，依頼元から現金の支給の依頼を受けて，現金を銀行の営業店で受け渡す銀行システムにおいて，前記依頼元からの依頼を受け付ける銀行センタであって，依頼元からのファクシミリによる現金の支給要求を受信し，該支給要求の内容を示す確認書データを依頼元に返送するとともに，該支払要求に対応する所定の依頼データを生成して記憶する確認手段と，前記確認書データの送信先から承認要求を受信し，承認符号を生成して返送するとともに，該承認符号を前記確認手段により記憶された依頼データに含める承認手段と，前記承認手段により承認符号を付与した依頼元のうち，資金の支払い方法として，指定口座からの支払いを指定している依頼元について，該依頼元の口座から銀行の所定口座へ資金を移動するための移動データを生成し，資金移動要求とともに外部に送信する手段と，前記確認手段により生成され記憶された依頼データに基づいて，銀行の営業店毎に現金の支給金額を集計し，該集計結果を，現金を袋詰めする装置に送信する手段と，銀行の所定口座への入金明細を示す入金データを外部から取得し，当日が現金の支給日と設定されている依頼データと，前記入金データと，を突き合わせて，各依頼元からの資金の入金が完了しているか否かをチェックし，該チェック結果に基づいて，各依頼元主について，資金の確保状況と，該依頼元の前記承認符号と，を示すリストを生成する手段と，前記生成されたリストを銀行の各営業店のファクシミリに送信する手段と，を備える。」
ｄ．「【００１３】前記銀行センタは，前記依頼データ記憶手段に記憶された依頼データに基づいて銀行の営業店毎に現金の支給金額を集計する集計手段と，前記集計手段による集計結果を，現金を袋詰めする袋詰装置に送信する手段と，を備えてもよい。また，受け付けた依頼について，その支給金額を，現金を受け渡す銀行の営業店毎に集計して現金を袋詰めする装置に送信することにより，銀行の営業店毎の現金の袋詰めを自動化することができる。なお，前記集計手段による集計処理は金種毎の集計処理を含んでもよく，前記送信手段により前記袋詰装置に送信されるデータは，各依頼元への支給金額のデータを含んでもよい。」
ｅ．「【００２２】依頼データＤＢ３２は，例えば図３に示すような，「企業ＩＤ」，「支給日」，「依頼日時」，「承認日時」，「承認番号」，「支給金額」等のデータを含む依頼データを記憶する。（途中省略）また，依頼データは，当該企業が所属する「営業店コード」等のデータをさらに含んでもよい。
【００２３】現金支給要求受付部３３は，企業のファクシミリ１から，現金の支給依頼に関する所定データ（支給依頼データ）を受信する。現金支給要求受付部３３は，受信した支給依頼データに基づいて依頼データ（図３参照）を生成して依頼データＤＢ３２に記憶する。」
ｆ．「【００２６】依頼データ集計部３７は，日毎に，例えば銀行業務の終了後等の所定のタイミングで，依頼データＤＢ３２に新たに記憶された依頼データを読み出し，各企業への支給金額を店別にまとめた集計データ等を現金袋詰め装置４に転送する。また，依頼データ集計部３７は，上記集計データを送信する際，現金が袋詰めされた各現金袋に貼付されるラベルに記載されるデータ（企業名，企業ＩＤ，承認番号等）を顧客ＤＢ３１又は依頼データＤＢ３２から読み出して併せて送信するようにしてもよい。」
ｇ．「【００３２】まず，受付サーバ３が企業Ａから現金支給の依頼を受け付ける受付処理について図５を参照して説明する。依頼元の企業Ａのファクシミリ１は，依頼人によるプッシュボタン入力操作に応じて，現金支給を依頼するための支給依頼データを電話回線を介して受付サーバ３に送信する（Ｓ１１）。これに応じて，受付サーバ３の現金支給要求受付部３３は，受信した支給依頼データ等に基づいて，依頼データを生成し，依頼データＤＢ３２に記憶するとともに（Ｓ１２），依頼内容を示す確認書データ（ＦＡＸデータ）を，依頼元の企業Ａのファクシミリ１に送信する（Ｓ１３）。
【００３３】依頼元の企業Ａのファクシミリ１は，確認書データを受信して印刷する。依頼人は，印刷された確認書を見て，依頼内容を確認した後，受付サーバ３から依頼の承認を受けるためにファクシミリ１を操作する。この操作とは，例えば，依頼人がファクシミリ１の電話機能により受付サーバ３に電話をかけ，応答サービス等によるガイダンスに従って，承認要求に対応する番号等をプッシュボタン入力すること等である。この操作に応じて，企業Ａのファクシミリ１は，プッシュボタン入力された承認要求を受付サーバ３に送信する（Ｓ１４）。
【００３４】これに応じて，受付サーバ３の現金支給要求受付部３３は，企業Ａからの依頼に対する承認番号を生成し，その承認番号を，依頼データＤＢ３２に記憶されている企業Ａの依頼データに設定するとともに（Ｓ１５），企業Ａのファクシミリ１にＦＡＸデータとして送信する（Ｓ１６）。」
ｈ．「【００３７】次に，上記受付処理にて受け付けた依頼について，当日分の依頼データの集計結果を現金袋詰め装置４に転送する集計データ転送処理について図７を参照して説明する。受付サーバ３の依頼データ集計部３７は，例えば銀行業務の終了後等の所定のタイミングで，依頼データＤＢ３２に当日記憶された依頼データを読み出し，例えば各企業への支給金額を店別に集めた袋詰めデータを生成する（ステップＳ３１）。次に，受付サーバ３の依頼データ集計部３７は，生成した袋詰めデータ等を現金袋詰め装置４に送信する（Ｓ３２）。このようにして，受付サーバ３が，店毎に，そして顧客毎に現金を袋詰めするためのデータ等を現金袋詰め装置４に供給することにより，顧客毎の現金の袋詰めを正確にかつ自動的に行うことができる。」
ｉ．「【００３８】次に，企業Ａへの現金の支給日当日に，受付サーバ３が企業Ａからの資金確保の状況等を営業店Ｂに通知する通知処理を図８を参照して説明する。受付サーバ３の支給リスト送信部３９は，企業Ａの現金の支給日に，例えば業務開始時等の所定のタイミングで，企業から銀行の所定口座への入金（振込）の明細を示す入金明細データを勘定系ホスト５から取得する（Ｓ４１）。
【００３９】次に，支給リスト送信部３９は，当日が現金の支給日と設定されている依頼データ（企業Ａの依頼データを含む）を依頼データＤＢ３２から読み出し，入金明細データと突き合わせて，企業Ａを含む各企業から銀行への入金がそれぞれ完了しているかをチェックし，そのチェック結果を示す支給リストを生成する（Ｓ４２）。なお，上述のように，振り込みによる資金確保が必要でないと設定されている企業については，支給リストにその旨を設定する。支給リスト送信部３９は，生成した支給リストを営業店Ｂに送信する（Ｓ４３）。
【００４０】営業店Ｂのファクシミリ１は，受付サーバ３からの支給リストを受信して印刷する。ここでは，この支給リストには，企業Ａから銀行への入金が完了している旨が記載されていることとする。また，現金袋詰め装置４により袋詰めされた現金は営業店毎に運送される（Ｓ４４）。営業店Ｂでは，ファクシミリ１により印刷された支給リストと，現金袋に貼付されているラベルの記載内容と，を照らし合わせて，当日支給される現金が揃っていること等を確認する。そして，企業Ａの依頼人等が現金を受け取りに営業店Ｂに来店した場合には，その企業Ａの依頼人等による承認番号の提示を受け（Ｓ４５），企業Ａの現金袋のラベルに記載されている企業Ａの承認番号と，一致することを確認した後，現金を渡す（Ｓ４６）。」
　
　上記ａ．の「従来，例えば給与の給付に使用される現金の支給依頼である場合には，金種毎の必要数等が指定されるため，銀行では，各顧客から受け付けた現金の支給依頼について，支払日別に，金種別に集計等していた」旨の記載及び上記ｄ．の「依頼データに基づく集計処理が金種毎の集計処理を含んでもよい」旨の記載から，上記ｅ．の「依頼データ」が「企業ＩＤ」，「支給日」，「依頼日時」，「承認日時」，「承認番号」，「支給金額」，「営業店コード」に加えて「金種毎の必要枚数」を含んでもよいことは明らかである。
　
　したがって，上記ａ．−ｉ．の記載及び図面の記載から，引用例１には，
　「現金の支給依頼の受付処理及び受付処理に伴う種々の処理を行う銀行センタを含む，顧客企業から現金の支給依頼を受けて現金を銀行の営業店で顧客企業に受け渡す銀行システムにおいて，
　前記銀行センタは，
　顧客企業のファクシミリ１から現金の支給依頼に関するデータを受信し，受信した現金の支給依頼に関するデータに基づいて，企業ＩＤ，支給日，依頼日時，承認日時，承認番号，支給金額，営業店コード，金種毎の必要枚数を含む依頼データを生成して依頼データＤＢ３２に記憶する現金支給要求受付部３３を備えた
　銀行システム。」
の発明（以下「引用発明」という。）が記載されていると認められる。
　
　同じく引用された特開平１１−３１１８２号公報（以下「引用例２」という。）には，
　「【０００３】従来の製品引当装置は，販売店からの注文に対して倉庫内に実在する在庫品から順に引当てるよう構成されている。
【０００４】従来の製品引当装置の場合，販売店からの製品の注文数に対して倉庫内にある在庫品の数が無ければ，納入不可能を販売店の情報端末へ回答している。」，
　「【０００８】本発明は（途中省略）注文を受けた製品を倉庫で効率よく引当てることのできる製品引当装置，製品引当方法および記録媒体を提供することを目的としている。」，
　「【００３２】この場合，入荷予定引当処理部３４は，注文の問い合わせ要求に対して，図２に示すように，まず，注文管理ファイル３７を検索して注文製品に対する注文情報（製品名，数量，希望納期，客先情報，配送先情報など）を取得する（Ｓ２０１）。続いて，入荷予定引当処理部３４は，取得した配送先情報を基に配送日数ファイル３９を検索して配送先への配送日数情報を取得する（Ｓ２０２）。
【００３３】そして，入荷予定引当処理部３４は，取得した各情報のうち，現在日付＋出荷所要日数＋配送日数≦希望納期という第１の条件式を満たすか否かを判定し，この第１の条件式を満たさなかった場合は（Ｓ２０３のＮ），引当て不可を回答する（Ｓ２０４）。」
と記載されている。
　
　上記の記載及び図面の記載から，引用例２には，
　販売店からの製品の注文に対して，配送先情報を基に配送日数ファイルから配送先への配送日数情報を取得し，現在日付＋出荷所要日数＋配送日数≦希望納期の条件を満たさなかった場合は，引当て不可を販売店の情報端末に回答すること
が記載されていると認められる。
　
　原査定に周知例として引用された特開２００１−１６０１０４号公報（以下「引用例３」という。）には，
　「【００４９】・ＩＳＢＮコード
（途中省略）
図６の（ｃ）は，書店マスタ例を示す。この書店マスタ６は，顧客がパソコン１を操作して書店コードが不明なときに，都道府県コード，市町村コードなどを送信して検索依頼し，書籍取次システム３が当該書名マスタ４を検索し，顧客の目的とする書店（書店コード）を検索するためのものであって，図示の下記の項目を予め登録したものである。
【００５０】・書店コード
・書店
・都道府県コード
・市町村コード
・仕切率
・出荷リードタイム日数
ここで，仕切率は，定価に対する当該書店に対する仕切率である。出荷リードタイム日数は，配送センタからの距離に基づいて決められるものであり，書店に書籍を配送するときに当該配送によって遅れる日数である（従って，顧客のお届け日（配送予定日）は受注が確定した日に当該出荷リードタイム日数を加算した日となる）。」，
　「【００５４】（２） 書店マスタ６を検索して見つけた書店（書店コード）を，受注確定デ―タベース７の該当する“お客様名，予約Ｎｏ．”のエントリの矢印の書店の欄に設定および出荷リードタイム日数をもとに配送予定日を決定して配送予定日の欄に設定する。」，
　「【００５５】
【発明の効果】以上説明したように，本発明によれば，顧客がパソコン通信などを介して書籍のオーダエントリを書籍取次システム３に行い，書籍を書店に配送して当該書店から代金と引換えに引き取る構成を採用しているため，顧客はパソコン通信などによって書籍を書籍取次システム３に予約し，最寄りの書店から特別な送料などの付加料金なしに確実に目的とする書籍を入手することができる。（途中省略）本発明の対象とする販売システムは，書籍のみに限定するものではなく，書籍以外にも，ビデオ，ＣＤ，パソコンソフト等の名称などから一意に特定できる商品の販売システムであれば本発明の範囲に含まれるものである。」
と記載されている。
　
　上記の記載及び図面の記載から，引用例３には，
　配送センタからの販売店の距離に基づいて決められ，販売店に商品を配送するときに該配送によって遅れる日数である出荷リードタイム日数を，販売店毎に販売店マスタファイルに登録しておき，該販売店マスタファイルから販売店毎の出荷リードタイム日数を知ること
が記載されていると認められる。
　
４．対比・判断
　本願発明と引用発明とを対比すると，
　引用発明の「銀行センタ」，「銀行システム」は，それらの機能からみて，本願発明の「現金要求受付システム」，「現金受付配送システム」に各々対応し，
　引用発明の「現金の支給依頼に関するデータ」は，本願発明の「要求内容」に相当し，
　引用発明の「支給日」，「営業店コード」，「金種毎の必要枚数」は，本願発明の「日付」，「配送先」，「金種」に各々相当し，
　引用発明の「依頼データ」は，本願発明の「電子化データの受付情報」に相当し，
　引用発明の「現金支給要求受付部」は，本願発明の「受付処理部」に対応している。
　
　したがって，両者は，
　「現金要求の受付を行い，受付データの管理を行う現金要求受付システムを含む現金受付配送システムにおいて，
　前記現金要求受付システムは，
　顧客からの現金要求を受け付け，要求内容を金種・日付・配送先を含む電子化データの受付情報として出力する受付処理部，
　を備えたことを特徴とする現金受付配送システム。」
である点で一致し，次の点で相違している。
　
［相違点］
　本願発明は，現金要求受付システムが，予め顧客毎に定められた配送可能日数の情報を格納する配送日数情報データベースを備え，受付処理部が，顧客からの現金要求を受け付ける場合，顧客の特定後，前記配送日数情報データベースを参照し，現在日時と配送要求日時との日数が，該顧客に対応する配送可能日数以上ある場合に配送可能として前記現金要求を受け付けるのに対して，引用発明は，そうではない点。
　
　上記［相違点］について検討する。
　引用例２に，販売店からの製品の注文に対して，配送先情報を基に配送日数ファイルから配送先への配送日数情報を取得し，現在日付＋出荷所要日数＋配送日数≦希望納期の条件を満たさなかった場合は，引当て不可を販売店の情報端末に回答することが記載されており，出荷所要日数と配送日数とで配送可能日数に相当するといえるから，引用発明において，受付処理部が，顧客からの現金要求を受け付ける場合，顧客の特定後，現在日時と配送要求日時との日数が，該顧客に対応する配送可能日数以上ある場合に配送可能として前記現金要求を受け付けるようにすることは，当業者が格別に思考することなく推考し得たことである。
　その際に，引用例３に，配送センタからの販売店の距離に基づいて決められる出荷リードタイム日数を販売店毎に販売店マスタファイルに登録しておき，該販売店マスタファイルから販売店毎の出荷リードタイム日数を知ることが記載されているから，さらに，現金要求受付システムに，予め顧客毎に定められた配送可能日数の情報を格納する配送日数情報データベースを設け，受付処理部が，配送日数情報データベースを参照して顧客に対応する配送可能日数を知るようにし，本願発明のようにすることは，当業者が容易に想到し得たことである。
　
　そして，本願発明の作用効果も，引用発明，引用例２，３に記載された事項の作用効果から，当業者が容易に予測し得たことである。
　
　なお，審判請求人は，請求の理由において，「本願発明では，顧客毎に配送可能日数を設定する点に特徴を有し，これにより一般的な顧客と優良な顧客との配送サービスの差別化を図ることができる。」（平成２０年３月１２日付け手続補正書２頁４１−４２行）と主張しているが，本願明細書の発明の詳細な説明には，「更に，配送可能日とは，受付日から最短で何日後に配送可能かを示す情報であり，これは，配送先の場所や配送ルート等の要因によって決定されている。」（段落【００１７】）と記載されており，上記の主張に格別の意義は認められない。
　
　したがって，本願発明は，引用発明，引用例２，３に記載された事項に基いて，当業者が容易に発明をすることができたものと認められる。
　
５．むすび
　以上のとおり，本願発明は，引用発明，引用例２，３に記載された事項に基いて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　よって，結論のとおり決定する。