【事件の表示】
　平成１０年特許願第２８６７５９号「予約決済システム」拒絶査定不服審判事件〔平成１２年　４月２１日出願公開、特開２０００−１１３０６３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯
　本願は、平成１０年１０月８日の出願であって、平成１２年５月２９日付の拒絶理由通知に対して同年８月７日付で補正書が提出されたが、平成１３年５月３０日付で拒絶査定がなされ、これに対し、 同年７月１２日に拒絶査定に対する審判請求がなされたものである。
　　
２．本願発明
　本願の請求項１に係る発明（以下、本願発明）は、平成１３年８月７日付けによって補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された次のとおりのものと認められる。
　「商品との交換価値を表わす所定の価値ポイントがあらかじめ付与された状態で発行され、互いに固有の識別情報により区別されるプリペイド発行体の各々について、そのプリペイド発行体の現在の価値ポイントを保持するとともに、ネットワーク経由で与えられる商品の購入指示にしたがってこの購入指示で指定されたプリペイド発行体の現在の価値ポイントの加減を行う決済機関サーバ、前記購入指示に応じて前記決済機関サーバから与えられる購買情報に該当する商品が予約対象に指定されていたとき、この商品に対する予約の受付登録とこの予約に関わる詳細情報を得るための連絡先情報の登録を行う販売管理サーバ、前記販売管理サーバで予約対象に指定されている商品の各々についてその商品の在庫および注文を管理する在庫管理サーバを備えた予約決済システムにおいて、
(1)前記販売管理サーバは、受付登録を行った予約によって指定された商品の注文情報を前記在庫管理サーバへ送信する手段、
(2)前記在庫管理サーバは、前記販売管理サーバから送信された商品の注文情報に応じて、その商品の受注が可能か否かを表わす受注確認情報を前記販売管理サーバへ送信する手段、
(3)前記販売管理サーバは、前記在庫管理サーバから送信された受注確認情報に該当する商品の予約について登録された前記連絡先情報にしたがって、この商品の予約が成立したか否かをこの商品の購入指示を与えた者に伝える手段
を備えたことを特徴とする予約決済システム。」
　　
３．引用例記載の発明
 （１）原査定の拒絶理由に引用された「Mac Fan internet September Vol.2, No.9 (1997-9-1) pp76-79」には、「BitCashオンライン決済システム」に関して、次の事項が図面と共に記載されている。
　　
　（ａ）「小額決済に最適のデジタルキャッシュ―ＢｉｔＣａｓｈ　
　さて一方で、Ｓｍａｓｈとはまったく異なる考え方から生まれたのが「ＢｉｔＣａｓｈ」というオンライン決済システム。こちらは１００円とか３０円といった小額を扱うのに適しているもので、商品は主に画像データやオンラインソフトなどのデジタルコンテンツだ。（略）ＢｉｔＣａｓｈを利用するには、事前に「ＢｉｔＣａｓｈカード」を購入する。（略）カードは1枚１，０００円と２，０００円の２種類があり、それぞれ１，０００クレジット、２，０００クレジットに換算される。「クレジット」とはＢｉｔＣａｓｈシステムの中で言う「通貨単位」と考えればいいだろう。ＢｉｔＣａｓｈカードの裏面にはスクラッチ部分があり、その部分をコインなどで削ると４×４行のひらがなが現れる。これがＢｉｔＣａｓｈを使うためのパスワードとなる。カードを入手したらＢｉｔＣａｓｈでの支払いを用意しているホームページに移動。ビットキャッシュ（株）のホームページ（http://www.BitCash.co.jp/links.html）に加盟店一覧が用意されているので、そこからジャンプすればいいだろう。今回は凸版印刷（株）『ＢｏｏｋＰａｒｋ』でデジタルコンテンツを買ってみよう。希望の商品を選択したら、支払いで「ＢｉｔＣａｓｈ」を選択する。選択するとＢｉｔＣａｓｈカードに記載されているパスワード（４×４のひらがな）を入力するためのホームページが表示されるので、文字を入力して送信。（略）カード情報があっていれば、現在の残高が表示される。ここでコンテンツの購入を選択すれば、画像データのダウンロードやデジタルコンテンツが記載されているホームページへの入室が許されるというわけだ。（略）ここまで読んで「なんだプリペイドカードか」と思われるかもしれない。だが、それはちょっと違う。ＢｉｔＣａｓｈは図書券や商品券のように特定の商品や施設、組織に使用が限定されるのではなく、インターネットの世界の中では商品の代価として「クレジット」通貨単位が利用される。その意味で立派に「通貨」、「デジタルキャッシュ」と呼べるものなのだ。」（第７８頁　左欄第１行〜右欄第１２行）
　また、第７９頁には、「ＢｉｔＣａｓｈを利用した買い物の流れ」のフロー図において、イ．ユーザーからＢｉｔＣａｓｈに対し「８．残高を確認後、商品を「購入」／「キャンセル」を選択する」こと、ロ．ＢｉｔＣａｓｈにおいて「９．残高から今回の代金を差し引く」こと、および、ハ．ＢｉｔＣａｓｈからＳＨＯＰに対し「１０．売上が発生したことを通知」すること、が示されている。
　　
　なお、（ａ）の記載、および、第７９頁のフロー図のＢｉｔＣａｓｈやＳＨＯＰの機能からして、ＢｉｔＣａｓｈが決済サーバを、また、ＳＨＯＰが販売管理のためのサーバを、それぞれ有し、当該サーバで各処理を行っていることは自明である。
　また、第７９頁の図面において、ＢｉｔＣａｓｈからＳＨＯＰに対し「１０．売上が発生したことを通知」しているが、この場合、ＳＨＯＰでは、どの商品が購入されたのか登録をしていることも自明である。
　
　したがって、引用例１には、「商品との交換価値を表わす所定の価値ポイントがあらかじめ付与された状態で発行され、互いに固有の識別情報により区別されるプリペイド発行体の各々について、そのプリペイド発行体の現在の価値ポイントを保持するとともに、ネットワーク経由で与えられる商品の購入指示にしたがってこの購入指示で指定されたプリペイド発行体の現在の価値ポイントの加減を行う決済機関サーバ、前記購入指示に応じて前記決済機関サーバから与えられる購買情報に該当する商品が購入対象に指定されていたとき、この商品に対する購入の登録を行う販売管理サーバ、を備えた決済システム」に関する発明が記載されている。
　
　（２）同じく原査定の拒絶理由に引用された特開平１０−４０４６２号公報（以下、引用例２）には、「予約販売システム」に関して、次の事項が図面と共に記載されている。
　（ａ）「本発明は、街頭において、商品の予約販売契約を成立させる機能を持った予約販売システムに関する。」（公報段落番号０００１）
　（ｂ）「本発明は、上述の事情に基づいてなされたもので、その目的とするところは、（略）不特定の顧客に対して、商品の予約契約が実現できるように、また、必要なら、誰でもが、自由に、商品の在庫の確認などが行える、便利な予約端末機を備えた予約販売システムを提供することにある。 」（公報段落番号０００５）
　（ｃ）「本発明の実施の形態を、図面を参照して、詳細に説明する。図１を参照すると、まず、顧客が、駅コンコースやコンビニエンスストアなどに設置されている予約端末機１０より、モニター１１に表示された予約ガイダンス、メニューに従って、予約者の住所、氏名などの入力操作、商品名、商品コード、数量などの入力操作、および、商品受け渡し方法の指定の入力操作を、それぞれ、行うことで、中継センター２０とアクセスし、予約端末機１０での現金もしくはカードによる予約料および／もしくは商品代金の支払い完了によって、予約カードを発行し、予約契約を成立させる。（略）なお、このような所定の入力操作による情報に基づくところの、中継センター２０での判定は、個人情報のみに限られるものではなく、たとえば、生産中止の商品についての予約希望について、その在庫の有無、予約の可否を判定する場合にも適用できる。中継センター２０で予約可能（上述の利用者の確認など）であると判断されると、予約操作の継続プログラムが進行し、予約したい商品の情報入力が行えることになる。その後、予約端末機１０で、実際に所望の商品予約をした場合には、中継センター２０で、情報ファイル２２、商品リスト２３、店舗データベース２４などを基に、顧客の希望する商品が、必要個数、希望する店舗に在庫しているか否かを確認し、結果を予約端末機１０のモニター１１へ表示する。」（公報段落番号００１０〜００１４）
　（ｄ）「次に、本発明のシステムのフローを図３を参照して詳細に説明する。ここでは、第一のフローとして、予約時のステップが示されている。即ち、まず、予約者は予約端末機１０において、モニター１１のメニュー選択で、予約操作を選択し（ステップ１）、画面表示から、希望する商品の情報（ここでは、ＣＤからの読み出し）を選択し、キー入力などの入力操作で、商品コード、その購入個数などを、入力端末機１０に入力する（ステップ２）。次に、利用者の個人情報を同じく、入力操作で、入力端末機１０より入力する（ステップ３）。なお、ここでの個人情報とは、氏名、電話番号、住所などで、要すれば、自分用のパスワード・ナンバーなどの任意情報である。この情報は、中継センター２０に送られ、ここで、住民データーバンク２１を利用したセキュリティチェックが行われる（ステップ４）。（略）セキュリティチェックがＯＫであれば、中継センター２０では、商品データー２３、店舗データーバンク２４を基に、顧客が希望する店舗３０に在庫が存在しているか否かを確認し（ステップ５）、結果を入力端末機１０のモニター１１に表示する。ここで、顧客は、実際に店舗まで商品を受け取りに行くのか、または、自宅への郵送なのかを選択する（ステップ６）。（略）同じ要領で、商品代金の支払い方法も、次のパターンから顧客が自由に選択できることになっている。（略）最後に、予約端末機１０では、予約料（前納の場合には、商品代金を含めて）の支払い額が表示される。 」（公報段落番号００２２〜００２８）   
（ｅ）「店舗に予約端末機１０が装備されている場合など、当該店舗での在庫問い合わせをメニューに載せることもできる。この流れは、次のフローで実現できる。即ち、利用者は、メニューから「在庫問い合わせ」を選択し（ステップ９）、入力操作で、商品情報の入力のみを行う（ステップ１０）。なお、駅コンコースなどの街頭設置の予約端末機では、顧客の希望する店舗に対する在庫問い合わせもできる（ステップ１１）。そして、モニター１１には、当該商品の在庫情報や、その商品が在庫している店舗情報などを表示する（ステップ１２）。」（公報段落番号００３０）
　
　なお、上述（ａ）〜（ｅ）の記載、および、図１から、引用例２記載の予約販売システムはネットワークを介して商品の購入の予約を行っていることは自明である。
　したがって、引用例２には、「１．商品の予約および決済をネットワークを介して行うこと。
　２．ネットワークを介した商品の予約・決済システムにおいて、イ．商品の購入予約が行われた場合には、商品リストや店舗データベース等を基に、その商品の受注が可能か否かを確認すること、そして、ロ．この確認結果を購入希望者に知らせること。」が記載されている。
　　
 ４．対比
　そこで、本願発明と引用例１記載の発明を対比すると、引用例１の「決済システム」と本願発明の「予約決済システム」は「決済システム」という概念で一致する。また、引用例１と本願発明の販売管理サーバは、「（購入指示に応じて）決済機関サーバから与えられる購買情報に該当する商品が本システムの対象に指定されていたとき、この商品に対する登録を行う」という点で一致する。
　　
　したがって、本願発明と引用例１記載の発明とは、
 「商品との交換価値を表わす所定の価値ポイントがあらかじめ付与された状態で発行され、互いに固有の識別情報により区別されるプリペイド発行体の各々について、そのプリペイド発行体の現在の価値ポイントを保持するとともに、ネットワーク経由で与えられる商品の購入指示にしたがってこの購入指示で指定されたプリペイド発行体の現在の価値ポイントの加減を行う決済機関サーバ、前記購入指示に応じて前記決済機関サーバから与えられる購買情報に該当する商品が本システムの対象に指定されていたとき、この商品に対する登録を行う販売管理サーバ、を備えた決済システム」の点で一致し、以下の点で相違する。
　　
　（相違点１）
　本願発明は予約決済システムであるが、引用例１記載の発明は決済システムである点。　また、その結果、本願発明の販売管理サーバは「決済機関サーバから与えられる購買情報に該当する商品が予約対象に指定されていたとき、この商品に対する予約の受付登録」を行っているが、引用例１の販売管理サーバは「決済機関サーバから与えられる購買情報に該当する商品が購入対象に指定されていたとき、この商品に対する購入の登録」を行っている。　
　（相違点２）
　本願発明は、「販売管理サーバで予約対象に指定されている商品の各々についてその商品の在庫および注文を管理する在庫管理サーバ」を備えており、そして、在庫管理サーバと販売管理サーバとの間を連絡する「(1)販売管理サーバは、受付登録を行った予約によって指定された商品の注文情報を前記在庫管理サーバへ送信する手段、(2)在庫管理サーバは、前記販売管理サーバから送信された商品の注文情報に応じて、その商品の受注が可能か否かを表わす受注確認情報を前記販売管理サーバへ送信する手段」を設けているが、引用例１には在庫管理サーバはなく、また、その結果、販売管理サーバとの間を連絡する構成も何ら記載されていない。
　
　（相違点３）
　本願発明の販売管理サーバは、「（決済機関サーバから与えられる購買情報に該当する商品が予約対象に指定されていたとき、）予約に関わる詳細情報を得るための連絡先情報の登録を行い」、そして、「在庫管理サーバから送信された受注確認情報に該当する商品の予約について登録された連絡先情報にしたがって、この商品の予約が成立したか否かをこの商品の購入指示を与えた者に伝える手段」を有しているが、引用例１にはこれらの構成は記載されていない点。
　　
５．当審の判断
　上記相違点について検討する。
（相違点１）について
　引用例２には商品の予約および決済をネットワークを介して行うことが記載されてあり、そして、引用例１に記載のような決済システムを商品の予約および決済を行うシステムに応用する点に格別な技術的な困難性があるものとは認められない。
　したがって、引用例１に記載のような決済システムを商品の予約および決済を行うシステムに応用することは、当業者が適宜実施しうることと認められる。　
　また、この際、引用例１の販売管理サーバが「決済機関サーバから与えられる購買情報に該当する商品が予約対象に指定されていたとき、この商品に対する予約の受付登録」を行うようにすることも当然のことであり、この点も当業者が適宜実施しうることと認められる。　
　　
（相違点２）について
　引用例２には、ネットワークを介した商品の予約・決済システムにおいて、商品の購入予約が行われた場合には、商品リストや店舗データベース等を基に、その商品の受注が可能か否かを確認すること、が記載されてある。また、店舗等において、商品の在庫や注文を管理するために在庫管理サーバを用いることは周知のこと（例えば、特開平１０−２０７９５６号公報参照）である。
　したがって、引用例１に記載のような決済システムを商品の予約および決済を行うシステムに応用する際、上述の引用例２に記載の手段および周知の手段を採用し、商品の在庫や注文を管理するために在庫管理サーバを設け、そして、販売管理サーバから予約された商品情報を在庫管理サーバに送信し、在庫管理サーバでその商品の受注が可能か否かを確認し、その結果を販売管理サーバに送信するように構成することは、当業者が容易に考え得ることと認められる。
　　　
（相違点３）について
　引用例２には、ネットワークを介した商品の予約・決済システムにおいて、商品の購入予約が行われた場合には、その商品の受注が可能か否かを確認し、その後、その確認結果を購入希望者に知らせることが、記載されてある。また、一般に、商品の予約受付けを行う際、在庫状況を確認してから回答する場合には、予約受付時に予約者の連絡先を聞いておき、在庫状況を確認した後にその連絡先にコンタクトすることは、常套手段である。
  　したがって、引用例１に記載のような決済システムを商品の予約および決済を行うシステムに応用する際、引用例２に記載の手段および常套手段を採用し、予約受付時に販売管理サーバに購入希望者の連絡先情報の登録を行い、（在庫状況の確認後、）販売管理サーバから登録された連絡先情報にしたがって、商品の予約が成立したか否かを購入希望者に伝えるように構成することは、当業者が適宜実施し得ることと認められる。
　　
　なお、請求人は審判請求の理由において、本願発明は販売管理サーバのみにＣＧＩプログラムを持たせる点を主張しているが、ＢｉｔＣａｓｈカードを利用した決済システムでは、商品提供者や加盟店は自分のサーバ（本願発明の販売管理サーバに相当）にＣＧＩプログラムを組み込むだけで、本システムを利用できることは周知である（例えば、日経マルチメデイア（１９９７−７） pp.20-21参照）。
　また、本願請求項１に係る発明の効果についてみても、上記引用例１、２記載の発明、および、周知技術から当然に予測される程度のものにすぎず、格別顕著なものではない。
　　　
 ６．むすび
   したがって、本願発明は、引用例１、２記載の発明、及び、周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　
　よって、結論のとおり審決する。