【事件の表示】
　特願２００１−１２２５７５「ネットワークに基づく商取引のための携帯電話を用いた支払い」拒絶査定不服審判事件〔平成１３年１２月２６日出願公開、特開２００１−３５７３３９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯  
　この出願は、平成１３年４月２０日（パリ条約による優先権主張　２０００年４月２６日　欧州特許庁）の出願であって、平成１６年１２月１７日付で拒絶査定がなされ、これに対し、平成１７年３月１１日付で拒絶査定に対する審判請求がなされるとともに手続補正がなされ、平成２０年４月２２日付の当審の審尋に対して同年７月１６日付で回答がなされたものである。 
　　
　　
２．本願発明について  
　平成１７年３月１１日付でなされた請求項３に係る手続補正は、特許請求の範囲の減縮を目的としてなされたものであり適法な補正である。
　したがって本願の請求項１６に係る発明（以下「本願発明」という。）は、平成１７年３月１１日付の手続補正で補正された明細書の特許請求の範囲の請求項１６に記載された事項により特定される、次のとおりのものである。 
　　 
「　　顧客システム（４０；７０）が特定の価格で提供されるディリバラブル（４１；７１）を注文できるようにする商人システム（４５；７５）であって、前記顧客システム（４０；７０）はネットワーク（４４；７４）を介して前記商人システム（４５；７５）に接続可能であり、
　前記商人システムは、
　前記顧客システムまたは顧客の携帯電話によって提供された顧客の携帯電話（４３；７３）の電話番号を、前記商人システムの電話番号メモリに事前に登録する手段と、
　前記顧客システム（４０；７０）から前記ディリバラブル（４１；７１）の注文を受信する手段と、
　前記携帯電話（４３；７３）の前記電話番号を前記電話番号メモリから取得する手段と、
　前記携帯電話（４３；７３）の前記取得した電話番号を用いて前記携帯電話（４３；７３）に前記ディリバラブル（４１；７１）に対する注文確認を送る手段と、
　前記携帯電話（４３；７３）からの前記ディリバラブル（４１；７１）の前記注文の確認に対する応答を受信する手段と、
　前記応答の受信に応答して、仕掛り取引の詳細を電気通信事業者システム（４８；７８）に送信する手段と、
　前記電気通信事業者システム（４８；７８）により発行された支払い確認を受け取る手段と、
　前記商人システムが前記ディリバラブル（４１；７１）を前記顧客に入手可能にする手段と
　を含む商人システム。　　」  
　　
　　
３．原査定の拒絶の理由について 
　　 
　原査定の拒絶理由の「理由Ｄ」の概要は、以下のとおりである。 　　 
「＜理由Ｄ＞
　この出願の請求項１から４３に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　
　　　記　（引用文献等については引用文献等一覧を参照）
　　
【請求項１から４３について】
・刊行物：引用文献２−４
・備考
（途中略）
　　
　引用文献等一覧
　　
　１．（略）
　２．特開平０８−３３９４０７号公報
　３．特開平１０−２８９２６７号公報
　４．水野博泰他，モバイルが開くインターネット新世紀，
　　日経コミュニケーション，日経ＢＰ社，
　　２０００年４月３日，第３１５号，第７０−８１頁
　（以下略）　　」 
　　 
　　 
４．当審の判断 
　　 
４−１．各引用例について 
　　 
（１）引用例１について 
　原査定の拒絶理由通知の「理由Ｄ」で引用文献３として引用した「特開平１０−２８９２６７号公報」（以下「引用例１」という。）には、図面とともに以下のことが記載されている。  
　　
（ア）「【要約】
【課題】  ネットワークにおいて、円滑な取引を可能とする。
【解決手段】  ユーザの端末１から、加盟店のホームページに対してアクセスが行われ、商品の注文が行われた場合、注文データが加盟店の端末１２に伝送され、蓄積される。加盟店の端末１２から、ショッピングプロクシサーバ１３に適宜アクセスし、伝票作成のための画像の供給を受ける。売上伝票が作成されると、ショッピングプロクシサーバ１３にこれが記憶され、ショッピングプロクシサーバ１３から、注文を確認するための確認メールがユーザの端末１に送信される。この確認メールには、注文情報を確認するためのURLが含まれている。ユーザの端末１からこのURLにアクセスすると、ショッピングプロクシサーバ１３からユーザの端末１に対して、その注文情報が伝送される。」
　　
（イ）「【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、情報管理装置および方法、並びに情報管理システムに関し、特に、ネットワークを介して、円滑に正確に所定のサービスを受けることができるようにした情報管理装置および方法、並びに情報管理システムに関する。
【０００２】
【従来の技術】最近、インターネットに代表されるネットワークが普及してきた。このインターネット上には、World Wide Web(WWW)と呼ばれる情報検索システムが構築されている。このWWWにおいて、各種の商品の購入を含むサービスの提供を受けることができる。
【０００３】例えば、所定の商品を購入する場合、ユーザは、所定のホームページにアクセスし、商品に関する情報の提供を受ける。そして、その商品を購入するとき、住所、氏名、電話番号、クレジットカードの番号などを入力する。また、注文が行われたとき、サーバ側からユーザ側に対して、受信したメール（注文内容）が返信され、ユーザに注文内容を確認させるようになされている。入力された情報は、そのホームページを開設している販売者の端末に伝送される。販売者は、この情報に基づいて、商品を注文者（ユーザ）に対して発送するとともに、料金を指定された番号のクレジットカードから引き落とすように、クレジットカード会社に対して請求を行う。クレジットカード会社は、さらに、注文者（ユーザ）に対して料金の請求を行う。
【０００４】
【発明が解決しようとする課題】しかしながら、従来のこのようなシステムにおいては、ユーザが、誤操作により商品を発注してしまったような場合に、これをキャンセルすることが困難となる課題があった。サーバ側からの返信のメールが第３者に盗まれた場合、その第３者に注文を確定されてしまうような事態が発生し、ネットワーク上の取引が混乱するおそれがある。その結果、注文者と販売者との間で混乱が生じ、円滑な取引の妨げとなる課題があった。
【０００５】本発明はこのような状況に鑑みてなされたものであり、円滑な取引を可能とするものである。」
　　
（ウ）「【００１２】
【発明の実施の形態】以下に本発明の実施の形態を説明するが、特許請求の範囲に記載の発明の各手段と以下の実施の形態との対応関係を明らかにするために、各手段の後の括弧内に、対応する実施の形態（但し一例）を付加して本発明の特徴を記述すると、次のようになる。但し勿論この記載は、各手段を記載したものに限定することを意味するものではない。
【００１３】請求項１に記載の情報管理装置は、ネットワークを介して注文者にアクセスするアクセス手段（例えば図７の通信部４７）と、注文者が、その注文を確認するためにアクセスすべきネットワーク上のアドレスを、ネットワークを介して伝送する伝送手段（例えば図１２のステップＳ７７の処理を行う図７のCPU４１）とを備えることを特徴とする。
【００１４】請求項３に記載の情報管理システムは、注文者からの注文情報を記憶する記憶手段（例えば図７のハードディスク４５）と、ネットワークを介して注文者にアクセスするアクセス手段（例えば図７の通信部４７）と、注文者が、その注文を確認するためにアクセスすべきネットワーク上のアドレスを指定する指定手段（例えば図１２のステップＳ７７の処理を行う図７のCPU４１）と、注文者よりネットワークを介してアドレスにアクセスがあったとき、記憶されている注文情報を注文者に伝送する伝送手段（例えば図１２のステップＳ８４の処理を行う図７のCPU４１）とを備えることを特徴とする。
【００１５】図１は、本発明の情報管理システムの概念を表している。同図に示すように、このシステムにおいては、インターネット上のWWWにおいて、産直店、専門店、名店などの商品（サービス）販売者がホームページを開設している。これらの販売者は、このシステムによる対価の支払のサービスの提供を受ける場合、Smash（サービスマーク）に加盟する。ルータとしてのSo-net（サービスマーク）は、Smashの加盟店からアクセスがあったとき、クレジットカードによる決裁に必要な情報を提供する。
【００１６】一方、一般のユーザ（注文者）は、Smash加盟店からWWW上において商品を購入する場合、予めSo-netの会員になる。ユーザが、インターネットを介して所定の加盟店のホームページにアクセスし、商品を発注したとき、各加盟店は、そのユーザに対して商品を発送するとともに、料金をクレジットカード会社の１つであるSFI(Sony Finance International)（商号）に請求する。SFIは、さらに、この料金を、ユーザ（注文者）が指定したカードのクレジットカード会社に請求する。そして、そのクレジットカード会社が、さらに一般ユーザに、その料金を請求する。
【００１７】図２は、ネットワーク上における注文のシーケンスの概略を表している。同図に示すように、一般ユーザは、ステップＳ１において、所定の加盟店のホームページにアクセスし、商品を選択し、商品を購入する場合には、そのホームページ上で用意されている入力フォームに必要な事項を記入する。
【００１８】このようにして、ユーザが商品を発注すると、そのホームページを開設している加盟店の端末に、E-mail（電子メール）により、その注文情報が、ステップＳ２において転送される。加盟店においては、その端末から、So-netのSmashのサーバに、ステップＳ３でアクセスする。このとき、Smashサーバは、加盟店の端末に対して、注文された情報を入力するための伝票画面を転送する。加盟店側の端末においては、その伝票画面に、一般ユーザからの注文情報を入力する。その注文情報とは、商品、配送先、合計金額などである。
【００１９】Smashサーバは、注文内容をユーザに確認させるための確認メールの発信の指令が加盟店の端末から入力されたとき、ユーザに対して、E-mailで確認メールを発信する。この確認メールには、ユーザが注文した内容を確認するための情報を提供するインターネット上のアドレスとしてのURL(Uniform Resource Locator)が含まれている。
【００２０】ユーザは、ステップＳ４において、Smashサーバから転送されてきたE-mailを読み取り、そこに指定されているURLにアクセスする。Smashサーバは、そのURLで規定される位置に、ユーザが発注した内容に関する情報を記憶している。そして、ユーザからそのURLに対するアクセスが行われたとき、Smashサーバは、その記憶されている情報を読み出し、ユーザに提供する。ユーザは、この情報から、自らが注文した内容を確認する。この確認が行われたとき、ステップＳ５で、加盟店は、商品を発送し、Smashサーバは、売上処理を実行する。
【００２１】以上がこのシステムの概略であるが、次に、このシステムのより詳細について、さらに説明する。
【００２２】一般ユーザは、このSmashを利用して、ネットワーク上で商品を購入する（サービスの提供を受ける）場合、So-netの会員として予め登録しておく必要がある。図３は、この登録の処理を表している。
【００２３】すなわち、最初に、一般ユーザは、その端末１を操作して、サインアップサーバ３にアクセスする。このシステムは、WWWシステムを利用するものであるため、このサインアップサーバは、WWWサーバ（アプリケーションソフトウエア）として、例えばNetscape社のNetscape Commerce Serverのようなソフトウエアが必要となる。また、会員端末１においても、WWWブラウザとして、例えばNetscape社のNetscape Navigator（商標）のようなアプリケーションソフトウエアが必要となる。Netscape Commerce ServerやNetscape Navigatorは、何れもSSL(SecureSock Layer)に対応しており、暗号化してデータを送信するため、その秘密性を確保することができる。
【００２４】端末１から、ユーザは、So-netに入会するための申し込みの入力を行う。この申し込み時において、ユーザは、自分自身のユーザＩＤ、パスワード、および、商品を購入した場合の決裁に用いるクレジットカードの番号と有効期限などを入力する。
【００２５】サインアップサーバ３は、ユーザから入会申し込みを受け付けたとき、そのカードのオーソリ処理を実行する。このため、サインアップサーバ３は、SFIサーバ５に対してアクセスし、申し込まれた番号のクレジットカードが適正なものであるか否かをチェックする。すなわち、期限が有効であるか否か、さらに比較的少ない所定の金額（例えば１００円）の引き落としが可能であるか否かをチェックする。
【００２６】SFIサーバ５は、サインアップサーバ３からカードチェックの要請があったとき、必要に応じて、NTTデータ通信株式会社（商標）のCAFIS(Credit And Finance Information System)６を利用して、クレジットカード会社７にアクセスし、そのカードが適正なものであるか否かのチェックを要求し、そのチェックした結果を受け取ると、これをサインアップサーバ３に出力する。
【００２７】サインアップサーバ３は、カードオーソリの結果が適正なものである場合、So-net４に会員としての登録を要求する。So-net４においては、サインアップサーバ３から要求のあったユーザをSo-net４の会員として登録し、その会員（ユーザ）に対して、固有のA-Key(Shopping Access Key)を生成する。そして、ユーザから入会申し込み時に指定されたユーザＩＤと生成したA-Keyを含む登録内容を、郵便で、そのユーザに送付する。
【００２８】ユーザは、このようにして、登録内容の郵送を受けたとき、サインアップサーバ３に再びアクセスし、A-Key、ユーザＩＤ、パスワード、カード有効期限などを入力する。サインアップサーバ３は、これらの入力をチェックし、それらが適正なものである場合、ユーザの端末１に対して、ショッピングの利用が可能になったことを通知する。
【００２９】図４は、図３の会員登録の処理において授受されるデータの内容を表している。同図に示すように、オンラインによる入会申し込み時においては、ユーザＩＤ、パスワード、クレジットカードの番号、クレジット番号の有効期限といった情報が、端末１からサインアップサーバ３に転送される。サインアップサーバ３からSFIサーバ５に対して、カードオーソリ処理を実行するとき、カード番号と有効期限が伝送される。また、So-net４からユーザに対して郵便で登録内容を通知するとき、ユーザＩＤ、A-Keyが通知される。さらに、ユーザが登録内容通知書を受け取った後、ショッピング利用開始の許可を受けるために行う入力時においては、ユーザＩＤ、パスワード、A-Key、および有効期限が伝送される。
【００３０】図４を参照して明かなように、何れの段階においても、ユーザＩＤ、パスワード、A-Key、カード番号、および有効期限の全てが同時に授受されることはない。従って、その何れかの段階において情報が盗まれたとしても、それが悪用されるおそれが少なくなる。
【００３１】次に、図５を参照して、Smashシステムにおいて、商品を注文する場合の流れについて説明する。
【００３２】このシステムにおいては、WWWサーバ１１により、各加盟店のホームページが提供されている。ユーザの端末１から、加盟店のホームページにアクセスがあり、注文が出された場合には、その注文データが、WWWサーバ１１から、その加盟店の端末１２に転送されるようになされている。この注文データは、端末１２の記憶装置に蓄積される。各加盟店が所定のタイミングにおいて蓄積された注文情報を読み出し、その注文伝票を作成するとき、ショッピングプロクシサーバ１３にアクセスするようになされている。このショッピングプロクシサーバ１３は、図３におけるサインアップサーバ３と同一のものとすることも可能である。
【００３３】ショッピングプロクシサーバ１３は、加盟店の端末１２からアクセスがあったとき、必要な伝票情報を提供するとともに、ユーザの端末１に対して確認メールを送信するようになされている。そして、ショッピングプロクシサーバ１３は、端末１から注文を確認する入力がなされたとき、So-net４の会員管理サーバ１４にアクセスし、オーソリ処理を行うとともに、そのオーソリの結果を端末１に出力し、さらに、そのオーソリの結果が適正なものである場合には、加盟店の端末１２に対して、売上承認の連絡を行うようになされている。ショッピングプロクシサーバ１３は、さらに、加盟店の端末１２から、売上確定入力がなされた場合には、So-net４の売上管理サーバ１５に対して、売上データを転送し、記録させるようになされている。
【００３４】なお、会員管理サーバ１４は、SFIサーバ５に接続されており、CAFIS６を介して、クレジットカード会社７にクレジットカードのチェックを要求することができるようになされている。
【００３５】図６は、ユーザの端末１の構成例を表している。CPU２１は、ROM２２に記憶されているプログラムに従って各種の処理を実行するようになされている。RAM２３は、CPU２１が各種の処理を実行する上において必要なプログラム、データなどを適宜記憶する。インタフェース２４には、ハードディスク（ＨＤ）２５、光磁気ディスク２６、通信部２７、入力部２８、ディスプレイ２９などが接続されている。
【００３６】ハードディスク２５は、比較的高速にアクセスが必要なデータ、プログラムなどを適宜記憶する。光磁気ディスク２６は、ハードディスク２５よりアクセスの速度が遅くても差し支えのないデータ、プログラムなどを適宜記憶する。通信部２７は、インターネット専用回線、公衆電話回線などとの間における通信を行う。入力部２８は、キーボード、マウスなどにより構成され、各種の指令を入力するときユーザにより操作される。ディスプレイ２９は、CRT、LCDなどにより構成され、所定の文字、画像などを表示するようになされている。
【００３７】図７は、ショッピングプロクシサーバ１３の構成例を表している。このショッピングプロクシサーバ１３は、CPU４１乃至ディスプレイ４９を有し、これらは、図６におけるCPU２１乃至ディスプレイ２９と実質的に同様の構成とされている。但し、ショッピングプロクシサーバ１３の方が、ユーザの端末１より、大容量で高速のものが用いられるようになされている。
【００３８】さらに、図示は省略するが、加盟店の端末１２も、ユーザの端末１と同様に構成されている。また、会員管理サーバ１４、売上管理サーバ１５は、ショッピングプロクシサーバ１３と同様に構成されている。
【００３９】次に、図８と図９のフローチャートを参照して、ユーザがインターネットのWWWシステムを介して商品を注文する場合の処理について説明する。図８は、ユーザの端末１の注文処理を示すフローチャートであり、図９は、加盟店のホームページを提供しているWWWサーバ１１がユーザからのアクセスに対応して行う処理を表している。
【００４０】ユーザは、商品を購入しようとするとき、端末１を操作して、ステップＳ１において、所定の加盟店のホームページにアクセスする。すなわち、ユーザは、端末１の入力部２８を操作して、所定の加盟店のインターネット上のアドレスを入力する。CPU２１は、このとき、通信部２７を制御し、入力されたアドレスのホームページに対するアクセスを実行させる。
【００４１】WWWサーバ１１は、ステップＳ２１において、ユーザ（会員）からのアクセスがあるまで待機し、アクセスがあったとき、ステップＳ２２に進み、ホームページの情報を、アクセスしてきたユーザに転送する。このホームページには、その加盟店が提供する商品情報と注文書が含まれている。図１０は、このようにして、WWWサーバ１１からユーザの端末１に対して転送される注文書の例を表している。ユーザの端末１においては、ステップＳ２において、通信部２７が、この商品情報と注文書を受信し、CPU２１は、これをディスプレイ２９に出力し、表示させる。
【００４２】次に、ステップＳ３に進み、ユーザは、いま提供を受けた商品の情報を見て、所定の商品を注文するか否かを判断する。商品を注文する場合には、ステップＳ４に進み、ユーザは、受信した注文書に、入力部２８を操作して、必要な情報を入力する。このとき、入力する情報には、商品を特定する商品番号、商品名、金額などの他、ユーザの住所、氏名、電話番号なども含まれている。さらに、この情報には、ユーザＩＤ(So-net ID)と、そのユーザのE-mailのアドレスも含まれている。
【００４３】注文書の入力が完了したとき、ユーザは、入力部２８を操作して、入力の確定を指令する。このとき、CPU２１は、ステップＳ５において、通信部２７を制御し、ステップＳ４で入力された注文書の内容を、WWWサーバ１１に転送させる。
【００４４】WWWサーバ１１においては、ステップＳ２３において、ユーザの端末１から、注文内容を受信したか否かを判定し、受信した場合にはステップＳ２４に進み、受信した注文内容を、その加盟店の端末１２に対して、E-mailで転送する。
【００４５】ユーザは、ステップＳ３において、注文をしないと判断した場合、ステップＳ４とステップＳ５の処理をスキップする。この場合、WWWサーバ１１においては、ステップＳ２４の処理がスキップされる。
【００４６】次に、図１１乃至図１４のフローチャートを参照して、以上のようにして発注した情報を確認する処理について説明する。図１１は、加盟店の端末１２の処理を表し、図１２と図１３は、ショッピングプロクシサーバ１３の処理を表し、図１４は、会員（ユーザ）の端末１の処理を表している。
【００４７】以下、加盟店の端末１２は、ユーザの端末１と実質的に同様の構成とされているため、図６を、加盟店の端末１２の構成をも表すものとして適宜引用する。
【００４８】最初に、ステップＳ４１において、加盟店の端末１２のCPU２１は、記憶されている注文内容を読み出す処理を実行する。すなわち、上述したようにして、WWWサーバ１１から注文情報が転送されてきたとき、加盟店の端末１２においては、通信部２７において、これを受信し、ハードディスク２５に記憶させている。入力部２８が操作され、その読み出しが指令されたとき、CPU２１は、ハードディスク２５に記憶されている注文情報を読み出し、ディスプレイ２９に出力し、表示させる。
【００４９】ステップＳ４２において、加盟店側における端末１２の操作者は、いまディスプレイ２９に表示されている注文情報が、So-net(Smash)による決裁を希望する注文であるか否かを判定する。勿論、この判定は、CPU２１により自動的に行うようにしてもよい。So-net以外の決裁が希望されている注文の場合、ステップＳ４３に進み、その希望に対応する処理が実行される。
【００５０】これに対して、So-netによる決裁が希望されている注文である場合には、ステップＳ４４に進み、操作者は、入力部２８を操作して、ショッピングプロクシサーバ１３に対するアクセスを指令する。このとき、CPU２１は、通信部２７を制御し、ショッピングプロクシサーバ１３にアクセスさせる。
【００５１】ショッピングプロクシサーバ１３においては、ステップＳ７１において、加盟店の端末１２からアクセスがあるまで待機し、アクセスがあったと判定された場合、ショッピングプロクシサーバ１３のCPU４１は、ステップＳ７２に進み、売上伝票を作成するのに必要な入力画面データをハードディスク４５から読み出し、通信部４７から加盟店の端末１２に転送させる。
【００５２】加盟店の端末１２側においては、ステップＳ４５において、この入力画面のデータを受信し、これをディスプレイ２９に表示させる。図１５は、このようにして、ショッピングプロクシサーバ１３から加盟店の端末１２に出力される入力画面の表示例を表している。この表示例においては、加盟店の名称が表示されるとともに、その下に、その加盟店のＩＤ(So-net ID)とパスワードの入力欄が表示されている。加盟店側の端末１２の操作者は、ステップＳ４６において、この入力欄に、加盟店コード(So-net ID)とパスワードを入力する。この入力は、端末１２の入力部２８を操作して行われる。入力された加盟店コードとパスワードは、端末１２の通信部２７から、インターネットを介して、ショッピングプロクシサーバ１３の通信部４７において受信される。
【００５３】ショッピングプロクシサーバ１３のCPU４１は、この情報が受信されたとき、ステップＳ７３において、この受信された加盟店コードとパスワードが適正なものであるか否かを判定する。この判定は、会員管理サーバ１４にアクセスし、加盟店コードとパスワードが登録されており、かつ、それらが対応するものであることをチェックすることで行われる。加盟店コードとパスワードの一方が登録されていなかったり、登録されていたとしても対応するものではない場合、ステップＳ７４に進み、ショッピングプロクシサーバ１３のCPU４１は、エラー処理を実行する。このとき、CPU４１は、例えば図１６に示すような、「会員登録されていません」のメッセージを加盟店の端末１２に伝送させる。端末１２においては、そのディスプレイ２９にこのメッセージが表示される。加盟店の端末１２の操作者は、この表示から、自らの入力が誤っていたことを知ることができる。
【００５４】入力が適切なものである場合、ショッピングプロクシサーバ１３のCPU４１は、例えば図１７に示すような売上伝票を選択させるための入力画面を、加盟店の端末１２に出力する。加盟店の端末１２側においては、ステップＳ４７において、この入力画面が受信され、ディスプレイ２９に表示される。加盟店の端末１２の操作者は、この入力画面において、所定の項目を入力する。この入力は、端末１２側からショッピングプロクシサーバ１３に伝送される。ショッピングプロクシサーバ１３は、このようにして、所定の項目を受信したとき、その項目に対応する売上伝票をハードディスク４５から読み出し、これを端末１２に送信させる。端末１２側においては、ステップＳ４７で、その注文伝票を受信し、ディスプレイ２９に表示させる。このようにして、例えば図１８に示すような注文伝票がショッピングプロクシサーバ１３から加盟店の端末１２に出力され、表示される。
【００５５】加盟店の端末１２側においては、ステップＳ４８において、操作者が、注文伝票上に必要な事項を入力する。図１８に示すように、この売上伝票には、その左下に、その加盟店からユーザ（注文者）に対するメッセージを入力することができるようになされている。これにより、顧客との対話性が向上する。さらに、この注文伝票の入力内容には、注文者（ユーザ）の端末１に対するE-mailのアドレスが含まれている。
【００５６】加盟店の端末１２側において、ステップＳ４９で、操作者が注文確認メール発信を指令すると、端末１２のCPU２１は、ステップＳ５０において、注文伝票の入力内容をショッピングプロクシサーバ１３に転送させる。ショッピングプロクシサーバ１３においては、ステップＳ７６で、加盟店の端末１２側から伝送されてきた注文伝票の入力内容が受信される。
【００５７】ショッピングプロクシサーバ１３のCPU４１は、このようにして、加盟店の端末１２から注文伝票の入力内容の伝送を受けたとき、ステップＳ７７において、そこに含まれるE-mailアドレスに確認メールを送信する処理を実行する。すなわち、ショッピングプロクシサーバ１３のCPU４１は、加盟店の端末１２から転送されてきた注文伝票の内容を、受付番号を付して、ハードディスク４５に記憶させるとともに、その注文伝票に入力されている注文者のE-mailアドレスに、例えば図１９に示すような確認メールを送信する。この確認メール中には、図１９に示すように、注文に対応する受付番号とこの受付番号に対応する注文情報を確認するためにユーザがアクセスすべきURLが含まれている。この例の場合、受付番号毎に（注文毎に）、URLが割り当てられる。このURLは、ハードディスク４５に記憶されている、この受付番号に対応する注文情報を読み出すためのアドレスとなっている。
【００５８】以上のようにして、ユーザは、所定の注文を行った後、数時間あるいは数日が経過した時点において、加盟店からの確認メールを受信することになる。そこで、ユーザの端末１においては、図１４のフローチャートに示すような処理を行って、この注文情報を確認する処理を行う。
【００５９】最初に、ステップＳ１１１において、ユーザは、So-net４にアクセスし、自分自身宛の確認メールを受信し、それを端末１のディスプレイ２９に表示させる。これにより、例えば図１９に示すような確認メールが、端末１のディスプレイ２９に表示されることになる。そして、上述したように、この確認メールには、受付番号とそれに対応するURLが含まれている。
【００６０】そこで、ステップＳ１１２に進み、ユーザは、確認メールに含まれているURLに対するアクセスを、入力部２８を操作して指令する。CPU２１は、この指令に対応して、指定されたURLに対するアクセス処理を実行する。
【００６１】ショッピングプロクシサーバ１３においては、ステップＳ７８において、ユーザの端末１から受付番号に対応するURLにアクセスがあったか否かを判定し、アクセスがない場合には、ステップＳ７９に進み、ステップＳ７７で確認メールを送信した後、２週間が経過したか否かを判定する。２週間がまだ経過していない場合にはステップＳ７８に戻り、再び受付番号に対応するURLにアクセスがあったか否かを判定する。
【００６２】ユーザの端末１からアクセスがないまま２週間が経過した場合、ステップＳ８０に進み、ショッピングプロクシサーバ１３のCPU４１は、ハードディスク４５に記憶している注文伝票を破棄させる。そして、ステップＳ８１において、その旨を、加盟店の端末１２と、必要に応じてユーザの端末１に通知する。
【００６３】これに対して、ステップＳ７８において、受付番号に対応するURLにアクセスがあったと判定された場合、ステップＳ８２に進み、ショッピングプロクシサーバ１３のCPU４１は、ユーザＩＤとパスワードの入力を要求する画面を、ユーザの端末１に伝送する。ユーザの端末１においては、ステップＳ１１３で、この画面を受信し、そのディスプレイ２９に表示させる。これにより、例えば図２０に示すような、ユーザＩＤとパスワードの入力を要求する画面が表示される。
【００６４】そして、ユーザは、ステップＳ１１３において、自分自身のユーザＩＤとパスワードを入力する。この入力は、ショッピングプロクシサーバ１３に伝送される。
【００６５】ショッピングプロクシサーバ１３においては、ステップＳ８３において、ユーザＩＤとパスワードがハードディスク２５に記憶されているURLに対応する適正なものであるか否かを判定する。適正なものでない場合には、いたずらであるか、真の注文者以外からの入力である可能性があるので、ステップＳ７８に戻り、再び同様の処理を繰り返し実行する。
【００６６】ステップＳ８３において、ユーザの端末１から伝送されてきたユーザＩＤとパスワードがURLに対応する適正なものであると判定された場合、ステップＳ８４に進み、ショッピングプロクシサーバ１３のCPU４１は、そのURLに記憶されている受付番号に対応する注文情報を、ハードディスク４５から読み出し、これをユーザの端末１に転送させる。
【００６７】ユーザの端末１においては、ステップＳ１１４において、このようにしてショッピングプロクシサーバ１３から転送されてきた注文内容を表す情報を受信し、ディスプレイ２９に表示させる。このようにして、例えば図２１に示すような注文情報がディスプレイ２９に表示される。
【００６８】図２１に示すように、この情報には、ユーザが注文を行った店舗の名称、商品名、商品の価格、その他の情報が、問い合わせ先とともに表示されている。
【００６９】ユーザは、このような情報を見て、最終的に注文を行うか否かを、ステップＳ１１５において判定する。そして、注文を行う場合には、図２１に示すＯＫボタンをステップＳ１１６で操作し、注文をキャンセルする場合には、図２１に示すＮＧボタンをステップＳ１１７で操作する。
【００７０】この入力は、ユーザの端末１から、ショッピングプロクシサーバ１３に転送される。ショッピングプロクシサーバ１３においては、ステップＳ８５で、ユーザの端末１よりＯＫの入力があったか否かを判定する。ＯＫの入力がない場合（ＮＧの入力があった場合）、ステップＳ８０に進み、ハードディスク４５に記憶されている注文伝票を破棄し、ステップＳ８１において、その旨を加盟店に通知する。
【００７１】これに対して、ステップＳ８５において、ユーザからＯＫの入力がなされたと判定された場合、ステップＳ８６に進み、ショッピングプロクシサーバ１３のCPU４１は、ステップＳ８６において、ユーザＩＤに対応するカード番号をハードディスク４５から検索し、さらに、会員管理サーバ１４にアクセスして、その番号のクレジットカードが有効であるか否かをチェックする。会員管理サーバ１４は、このチェックの要求に対応して、必要に応じて、SFIサーバ５にさらにアクセスし、SFIサーバ５からさらに、CAFIS６を介して、クレジットカード会社７にアクセスして、カードが適正なものであるか否かをチェックする。そして、チェックした結果をショッピングプロクシサーバ１３に通知する。
【００７２】ショッピングプロクシサーバ１３のCPU４１は、ステップＳ８７において、チェックの結果、その番号のカードが適正なものであるか否かを判定し、適正なものでない場合には、ステップＳ８８に進み、ユーザの端末１にカードオーソリ結果を通知する。ユーザの端末１においては、このオーソリ結果がステップＳ１１８で受信される。ユーザの端末１のCPU２１は、これをディスプレイ２９に表示させる。いまの場合、オーソリ結果が適正なものではないので、例えば「カードの有効期限が切れています」のようなメッセージが表示されることになる。
【００７３】その後、ショッピングプロクシサーバ１３においては、ステップＳ７８に戻り、新たな入力を待機する状態に戻る。
【００７４】ステップＳ８７において、カードが適正なものであると判定された場合、ステップＳ８９に進み、ショッピングプロクシサーバ１３のCPU４１は、ユーザの端末１に対して、カードオーソリ結果を通知する。ユーザの端末１においては、ステップＳ１１８で、このカードオーソリ結果が受信される。このようにして、例えば図２２に示すような画面が、ショッピングプロクシサーバ１３からユーザの端末１に送信され、そのディスプレイ２９に表示される。この表示においては、注文が正しく処理されたので、「ご注文有り難うございました」のメッセージが表示されている。
【００７５】ショッピングプロクシサーバ１３のCPU４１は、さらにステップＳ９０に進み、加盟店の端末１２に対して、売上承認のメッセージをE-mailで通知する。加盟店の端末１２においては、ステップＳ５１において、売上承認通知が受信されたか否かを判定し、受信された場合には、ステップＳ５２に進み、売上確定の入力を行う。この売上確定の入力は、ユーザの端末１から注文を確認するＯＫの入力がなされない限り、行うことができないようになされている。
【００７６】ショッピングプロクシサーバ１３においては、ステップＳ９１で、加盟店の端末１２から売上確定入力を受信し、さらにステップＳ９２において、その売上データを売上管理サーバ１５に転送する。売上管理サーバ１５は、このようにしてショッピングプロクシサーバ１３から転送されてきた売上を、取引の履歴として蓄積しておく。
【００７７】加盟店の端末１２においては、ステップＳ５１において、売上承認の通知が受信されていないと判定された場合、ステップＳ５３に進み、その他の通知が受信されているか否かを判定する。その他の通知が受信されていない場合には、ステップＳ５１に戻る。そして、ステップＳ５３において、その他の通知が受信されたと判定された場合、ステップＳ５４に進み、対応する処理を実行する。
【００７８】例えば、ショッピングプロクシサーバ１３が、ステップＳ８１で、注文伝票を破棄する通知を行ったような場合、加盟店の端末１２においては、このステップＳ５４で、その注文を破棄する処理が行われる。
【００７９】以上の処理においては、受付番号（注文）毎に異なるURLを割り振り、それをその注文を行ったユーザに確認メールで伝送するようにしたが、例えばこのURLを、同一の加盟店においては同一のURLとするようにすることも可能である。図２３乃至図２５のフローチャートは、この場合の処理例を表している。図２３は、ユーザの端末１の注文を確認する場合の処理を表しており、図２４は、WWWサーバ１１の処理を表している。
【００８０】ユーザの端末１においては、ステップＳ１３１で、ショッピングプロクシサーバ１３からの確認メールを受信すると、これをディスプレイ２９に出力し、表示させる。この確認メールには、ユーザが行った注文に対して割り振られた受付番号と、ユーザがその注文を行った加盟店の注文情報を記憶しているインターネット上の位置を表すURLが含まれている。例えば、ショッピングプロクシサーバ１３が作成した売上伝票を、そのハードディスク４５に記録するのではなく、加盟店のホームページを管理しているWWWサーバ１１に転送し、記憶させるようにしている場合には、URLは、WWWサーバ１１に記憶されているこの売上情報を読み出すためのアドレスとなる。
【００８１】ステップＳ１３２において、ユーザが確認メールのURLに対するアクセスを指令すると、端末１のCPU２１は、そのURLに対するアクセスを実行する。WWWサーバ１１においては、ステップＳ１５１において、ユーザの端末１からアクセスがあったか否かを判定し、アクセスがなければ、ステップＳ１５２に進み、確認メールがユーザの端末１に伝送された後（WWWサーバ１１に売上伝票が記憶された後）、２週間が経過したか否かが判定される。まだ２週間が経過していない場合には、ステップＳ１５１に戻り、再びユーザの端末１からアクセスがあったか否かが判定される。
【００８２】ステップＳ１５２において、２週間が経過したと判定された場合、ステップＳ１５３に進み、WWWサーバ１１は、記憶している注文伝票を破棄し、ステップＳ１５４において、その旨を加盟店の端末１２に通知する。
【００８３】ステップＳ１５１において、ユーザの端末１からアクセスがあったと判定された場合、ステップＳ１５６に進み、WWWサーバ１１は、ユーザの端末１に対して、ユーザＩＤとパスワードの入力を要求する。ユーザの端末１側においては、この要求に対応して、ステップＳ１３３において、ユーザがユーザＩＤとパスワードを入力する。
【００８４】WWWサーバ１１は、ステップＳ１５７において、ユーザの端末１から伝送されてきたユーザＩＤとパスワードが、登録されている注文情報に含まれるユーザＩＤとパスワードに対応するか否かを判定する。伝送されてきたユーザＩＤとパスワードが適正なものでないと判定された場合、ステップＳ１５８に進み、WWWサーバ１１は、エラー処理を実行する。例えば、ユーザの端末１に対して、「ユーザＩＤまたはパスワードが正しくありません」のようなメッセージを送出する。
【００８５】これに対して、ステップＳ１５７において、ユーザＩＤとパスワードが適正なものであると判定された場合、ステップＳ１５９に進み、WWWサーバ１１は、さらにユーザの端末１に対して受付番号の入力を要求する。
【００８６】ユーザの端末１においては、この要求に対応して、ステップＳ１３４において、ステップＳ１３１で受信した確認メールに含まれている受付番号を入力する。この受付番号は、WWWサーバ１１に伝送される。WWWサーバ１１においては、ステップＳ１６０において、この受付番号を受け取り、この受付番号に対応する注文情報が登録されているか否かを検索する。検索した結果、ステップＳ１６１において、受付番号が登録されているか否かを判定し、登録されていなければステップＳ１５８に戻り、エラー処理を実行する。
【００８７】受付番号が登録されている場合には、ステップＳ１６２に進み、その受付番号とユーザＩＤが対応するか否かを判定する。すなわち、ユーザの端末１から伝送されてきた受付番号が、WWWサーバ１１の注文情報の受付番号として登録されていたとしても、その受付番号の注文情報中に記憶されているユーザＩＤが、ユーザの端末１から伝送されてきたユーザＩＤと異なるものである場合には、やはりステップＳ１５８に進み、エラー処理を実行する。
【００８８】これに対して、ステップＳ１６２において、受付番号とユーザＩＤが対応するものであると判定された場合、ステップＳ１６３に進み、WWWサーバ１１は、登録されている受付番号に対応する注文情報を読み出し、これをユーザの端末１に転送する。ユーザの端末１においては、ステップＳ１３５において、この注文情報を受信し、ディスプレイ２９に表示させる。
【００８９】ユーザは、この情報を見て、ステップＳ１３６において、最終的に注文を行うか否かを判定し、注文を行う場合には、ステップＳ１３７において、ＯＫの入力を行い、注文をキャンセルする場合には、ステップＳ１３８に進み、ＮＧの入力を行う。
【００９０】WWWサーバ１１側においては、ステップＳ１６４において、ユーザの端末１からＯＫが入力されたか否かを判定し、ＯＫが入力されない場合（ＮＧが入力された場合）、ステップＳ１５３に進み、注文伝票を破棄し、ステップＳ１５４において、加盟店にその旨を通知する。
【００９１】これに対して、ステップＳ１６４において、ユーザの端末１からＯＫが入力されたと判定された場合、ステップＳ１６５に進み、WWWサーバ１１は、ショッピングプロクシサーバ１３に対して、ユーザＩＤに対応するカード番号の検索を要求するとともに、さらにショッピングプロクシサーバ１３が、会員管理サーバ１４にアクセスして、そのカード番号のチェックをしてくれるように要求する。ショッピングプロクシサーバ１３は、この要求に対応して、ユーザＩＤに対応するカード番号を検索して、そのカード番号のチェックを会員管理サーバ１４に要求する。そして、会員管理サーバ１４からのチェックの結果をWWWサーバ１１に通知する。
【００９２】WWWサーバ１１においては、ステップＳ１６６で、その番号のカードが適正なものであるか否かを判定し、適正なものでない場合には、ステップＳ１６７に進み、ユーザの端末１にカードオーソリ結果を通知し、ステップＳ１５１に戻る。
【００９３】ステップＳ１６６において、カードが適正なものであると判定された場合、ステップＳ１６８に進み、WWWサーバ１１は、ユーザの端末１にカードオーソリ結果を通知する。このステップＳ１６７またはステップＳ１６８におけるオーソリ結果の通知は、ユーザの端末１において、ステップＳ１３９で受信され、表示される。
【００９４】WWWサーバ１１は、さらにステップＳ１６９に進み、加盟店の端末１２に対して、売上承認を通知する。加盟店の端末１２から売上確定入力がなされた場合には、これがWWWサーバ１１に転送され、ステップＳ１７０で受信される。このとき、WWWサーバ１１は、ステップＳ１７１において、記憶している売上データをショッピングプロクシサーバ１３に転送し、これを売上管理サーバ１５にさらに転送することを要求する。ショッピングプロクシサーバ１３は、この要求に対応して、WWWサーバ１１から受信した売上データを、売上管理サーバ１５に転送し、記憶させる。
【００９５】以上においては、ユーザの端末１、加盟店の端末１２、WWWサーバ１１、ショッピングプロクシサーバ１３を、それぞれ１台ずつ図示するようにしたが、これらは、適宜複数台設けることができるのは勿論である。
【００９６】また、以上においては、ネットワークとして、インターネットのWWWシステムを利用した場合を例として説明したが、その他のネットワークやシステムを利用する場合にも、本発明は適用することが可能である。
【００９７】以上のように、確認メール自体には、注文情報を添付せず、ユーザがショッピングプロクシサーバ１３にアクセスして注文内容を確認するようにしたので、第３者が注文者に成り済まして、不正に商品を発注したりするようなことが防止される。」
　　
　上記摘記事項（ア）乃至（ウ）によれば、引用例１には、以下の発明（以下「引用例１発明」という。）が開示されている。 
　　 
「　　ユーザの端末が、ユーザが所定の商品を注文できるようにする、加盟店の端末と接続されるショッピングプロクシサーバであって、
　ユーザの端末はネットワークを介してショッピングプロクシサーバに接続可能であり、
　ショッピングプロクシサーバは、
　ユーザの端末から所定の商品の注文が行われると、
　ユーザの端末に対して、注文を確認するメールを送信し、ユーザに注文情報を確認させるようになっており、
　ユーザが確認した旨を送信すると、会員管理サーバを介してクレジットカードが適正なものであるか否かをチェックし、適正なものであると判断されると、加盟店の端末に売上承認のメッセージを通知する、
　ショッピングプロクシサーバ。　　」  
　　 
（２）引用例２について 
　原査定の拒絶理由通知の「理由Ｄ」で引用文献２として引用した「特開平８−３３９４０７号公報」（以下「引用例２」という。）には、図面とともに以下のことが記載されている。  
　　
（エ）「【特許請求の範囲】
【請求項１】  トランザクションを認可するための自動化された方法であって、前記トランザクションは顧客に関連付けられている顧客識別子に基づいており、
前記顧客識別子を含んでいる前記トランザクションを認可するための要求を受信するステップと、
前記要求に応答して、そして前記顧客識別子に基づいて、前記トランザクションを認可するかどうかを決定するステップと、
前記トランザクションが認可されるべきであることを前記の決定のステップが決定した場合、前記決定を前記顧客に対して通信するステップと、
前記顧客が前記トランザクションの認可に同意したことを確認している、前記顧客からの通信を受信するステップと、
前記顧客から受信された前記通信に応答して前記トランザクションを認可するステップとを含む方法。」
　　
（オ）「【０００８】
【課題を解決するための手段】
（途中略）
そこで、本発明の或る説明的な実施例にしたがって、トランザクションを承認するための自動化された方法が提供される。その中で、顧客は未解決の認可について通知され、その後、そのトランザクションは顧客が承認した場合だけ、それに応答して認可される。
（以下略）」
　　
（カ）「【００１３】
【発明の実施の形態】
（途中略）
これらの実施例において、クレジット・カードまたは預貯金引出しカードの発行者の顧客である場合もあり、そうでない場合もあるカード保持者がクレジット・カードまたは預貯金引出しカード（または、クレジット・カード番号）を使って与えられたクレジット・カードの口座に対して購入をチャージすること、あるいは与えられた預貯金引出しカードの口座からその購入の金額を引き落とすように小売り業者（製品またはサービスの提供者）に対して指示する。
（途中略）
【００１４】
（途中略）
詳しく言えば、クレジット・カードの保持者がトランザクションに関連付けられた支払い額をチャージするためにクレジット・カードを商店主に対して差し出した時、商店主はそのクレジット・カードをカード読取り器１０１の中でスライドさせて、たとえば、クレジット・カード番号をそのクレジット・カードの背面上の磁気ストライプから読み取る。
（以下略）」
　　
（キ）「【００１５】
（途中略）
その後、カード読取り器１０１はカード保持者に秘密のコード（たとえば、ＰＩＮ）を催促する前に、その預貯金引出しカードの裏面にある磁気ストライプから、たとえば、預貯金引出しカードの番号を読み取る。次に、カード読取り器１０１は図２に示されている検証要求メッセージを検証用データベース１０１へ送信する。
【００１６】図２に示されているメッセージはカード番号２０１、クレジット・カードの要求金額２０２、商店主のコード２０３、および検証要求２０４を含んでいる。
（以下略）」
　　
（ク）「【００１７】検証要求メッセージを受信すると、検証用データベース１０６はカード番号２０１を検索キーとして使ってそのカード番号に関連付けられているプロファイルを検索する目的のために、テーブル・ルックアップの操作を実行する。
（以下略）」
　　
（ケ）「【００１８】
（途中略）
プロファイルが１つまたはそれ以上の非呼出し当事者との通信を要求している可能性がある時、検証用データベース１０６は自動ダイヤリング・ユニット（ＡＤＵ）１１０−１〜１１０Ｎを使ってカード番号に関連付けられているプロファイルから検索された電話番号をダイヤルする。」
　　
（コ）「【００２６】図４のフィールド４０３に図５の中のエントリの１つを記入することによって、そのカード所有者に対する送信のための完全なメッセージが作成される。その後、検証用データベース１０６はプロファイルの中の通信アドレスを検索し、ＡＤＵ１１０−１〜ＡＤＵ１１０−Ｎから選択されたアイドル自動ダイヤリング・ユニットを経由して、図４に示されているメッセージをカード所有者に対して送る。後者は、ａ）検証用データベース１０６から受信された電話番号をダイヤルすることによって電話の呼出しを起動する、ｂ）カード所有者からのフィードバック信号を検出した時に他の通信デバイスに対してそれらの呼出しをブリッジするように配置される。ＡＤＵ  １１０−１〜１１０−Ｎはあらかじめ定められた期間の後にフィードバック信号が受信されなかった場合、その呼出しを終了するようにも設計されている。
【００２７】通信アドレスが「５００」または「７００」のプリフィックス番号（たとえば、図３の第３レコードの中に示されている）などの個人の電話番号であった場合、データベース１０６は図４に示されているメッセージを対話型音声応答システム（ＩＶＲＳ）１２５へ送信してから、アイドル状態にあるＡＤＵに対してカード所有者の通信アドレスを送る。ＡＤＵ  １１０−１からのダイヤルされた番号を受信した場合、たとえば、通信ネットワーク１０２は「５００」または「７００」プリフィックス電話番号をそのカード所有者に連絡できるプレイン・オールド電話サービス（ＰＯＴＳ）の電話番号に変換する。ＡＤＵ  １１０−１がカード所有者からのフィードバック信号を検出すると、それはその呼出しを「配線１４０」を経由して、たとえば、電話のセット１４５の場所にいるカード所有者に対して音声の形式で図４のメッセージを配送する対話型音声応答システム（ＩＶＲＳ）１２５に対してブリッジする。詳しく言えば、ＩＶＲＳ１２５は図４に示されているメッセージの１つのような、ＡＳＣＩＩ入力を使うように設計されているテキストから音声への合成プログラムの命令を実行して、そのＡＳＣＩＩ入力の「読み上げ」の音声表現を機械合成の音声にして生成する。またＩＶＲＳ１２５は特定のトランザクションを承認するか、否認するかの何らかの入力を与えるようにカードの所有者に催促するように配置される。たとえば、カードの所有者はトランザクションを承認するには電話のダイヤルパッド上で「１」を入力し、あるいはそのトランザクションを認めない場合はダイヤルパット上で「２」を入力するように催促することができる。ＩＶＲＳ  １２５の中にもう１つ含まれているものは呼出し者からのタッチトーン・コマンドに応答するための手段である。特に、ＩＶＲＳ  １２５はカードの所有者から受信されたデュアル・トーン多周波数（ＤＴＭＦ）信号を、検証用データベース１０６によって認識できるＡＳＣＩＩなどの機械で読めるフォーマットに変換する。代わりにＩＶＲＳ  １２５は図５の中のメッセージのようなディジタルに記録されたワードを出力するように配置されているワード認識ユニットを含んでいて、検証用データベース１０６に対して配送するためのＡＳＣＩＩ形式に変換される特定の情報をカード所有者に催促する。さらに、そのトランザクションを承認している個人が詐欺師ではなく、そのカードの所有者であることを保証するために、ＩＶＲＳ  １２５はそのカード所有者のあらかじめ録音されたディジタル化された音声メッセージのテンプレートを格納している話者認識ユニットを含んでいてもよく、それが非呼出し側から受信された任意の入力と比較されて、そのトランザクションを承認しようとしている個人が「真の」カード所有者であることを証明する。
【００２８】通信アドレスがポケットベルの電話番号であった場合、ＡＤＵ  １１０−１〜１１０−Ｎのうちの１つが、そのポケットベルの電話番号をダイヤルして、そのカード所有者のポケットベル・デバイス１３５に対して、図４のメッセージのうちの１つを配送する目的でそのポケットベルの電話番号に対する呼出しを起動する。
（以下略）」
　　
（サ）「【００２９】
（途中略）
承認／否認の応答が検証用データベース１０６によって要求された場合、ポケットベル１０６はミシシッピー州のジャクソンにあるＭｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｔｅｃｈｎｏｌｏｇｙ  Ｉｎｃ．から入手できるデバイスのような双方向のページング・デバイスであることが有利な場合がある。その場合、カードの所有者はあらかじめ定義されたコードをその双方向ポケットベルに入力することによって承認／否認のメッセージを送信する。
（以下略）」
　　
（３）引用例３について 
　原査定の拒絶理由通知の「理由Ｄ」で引用文献４として引用した「水野博泰　他２名，モバイルが開くインターネット新世紀，日経コミュニケーション  第３１５号，日経ＢＰ社，2000年04月03日，70頁〜81頁」（以下「引用例３」という。）には、以下のことが記載されている。  
　　 
（シ）「利用料はダイヤルＱ２方式で回収
　コンテンツ・プロハイダが集まるもう一つの要因は，移動通信事業者が果金インフラを提供することだ。具体的には，移動通信事業者がユーザーのコンテンツ利用料金を，通信料金とともに回収する「料金回収代行サービス」を提供する（ｐ７８の図１−２）。手数料はかかるが，料金回収の手間が不要で，料金を回収できないというリスクを背負わずに済む。電話の「ダイヤルＱ２」サービスに似ている。ユーザーにしてみれば，通話料金と同時にコンテンツ利用料金が引き落とされるので，わざわざクレジットカード番号を入力するなどの手間がかからないというメリットがある。」（第７７ページ左欄第１７行−第３３行）
　　
　　
４−２．対比 
　　  
　本願発明と、上記引用例１発明とを比較する。 
　　
　引用例１発明の、「ユーザ」と「ユーザの端末」とは、ユーザがユーザの端末からネットワークと加盟店サーバ及びショッピングプロクシサーバとを介して商品の注文ができるものであることから、本願発明の「顧客」と「顧客システム」とに相当する。
　引用例１発明の、「所定の商品」は、特定の価格で提供される商品であると考えることが自然であることから、本願発明の「特定の価格で提供されるディリバラブル」に相当する。
　引用例１発明の「ショッピングプロクシサーバ」は、ユーザの端末に対して注文を確認するメールを送信していることから、「ショッピングプロクシサーバ」は、「ユーザの連絡先」を「事前に登録」しており、当該「ユーザの連絡先」はユーザによって「提供」されたものである。
　してみると引用例１発明の「ショッピングプロクシサーバ」と、本願発明の「商人システム」とは、「顧客」によって「提供」された「連絡先」を「事前に登録する手段」を有する点で共通する。
　引用例１発明の「ショッピングプロクシサーバ」は、ユーザの端末から所定の商品の注文が、ネットワークを介して加盟店サーバになされ、加盟店端末による受注処理がなされると、当該所定の商品の注文の情報を加盟店端末から受信している。
　してみると、引用例１発明の「ショッピングプロクシサーバ」と、本願発明の「商人システム」とは、「ディリバラブルの注文の情報を受信する手段」を有する点で共通する。
　引用例１発明の「ショッピングプロクシサーバ」は、ユーザの端末に対して注文を確認するメールを送信し、ユーザに注文情報を確認させ、ユーザが注文情報を確認した旨を返信するとこれを受信し、引き続き処理を行うものである。
　してみると、引用例１発明の「ショッピングプロクシサーバ」と、本願発明の「商人システム」とは、「登録された顧客の連絡先を取得する手段」、「取得した顧客の連絡先にディリバラブルの注文確認を送る手段」、「顧客からのディリバラブルの注文の確認に対する応答を受信する手段」を有する点で共通する。
　引用例１発明の「ショッピングプロクシサーバ」は、ユーザが注文情報を確認した旨を返信してくると、会員管理サーバを介してクレジットカードが適正なものであるか否かをチェックし、適正なものであると、引き続き処理を行うものである。
　してみると、引用例１発明の「ショッピングプロクシサーバ」と、本願発明の「商人システム」とは、「応答の受信に応答して、他システムより発行された支払い確認を受け取る手段」を有する点で共通する。
　引用例１発明の「ショッピングプロクシサーバ」は、クレジットカードが適正なものであると判断されると、加盟店端末に売上承認のメッセージを通知するものであることから、本願発明の「商人システム」とは、「ディリバラブルを顧客に入手可能にする手段」を有する点で共通する。
　以上の点を総合すれば、引用例１発明の「ショッピングプロクシサーバ」は、本願発明の「商人システム」に相当する。
　そうすると両者は、 
　　 
「　　顧客システムが特定の価格で提供されるディリバラブルを注文できるようにする商人システムであって、
　顧客システムはネットワークを介して前記商人システムに接続可能であり、
　商人システムは、
　顧客によって提供された顧客の連絡先を事前に登録する手段と、
　ディリバラブルの注文の情報を受信する手段と、
　顧客の連絡先を取得する手段と、
　取得した顧客の連絡先にディリバラブルの注文確認を送る手段と、
　顧客からのディリバラブルの注文の確認に対する応答を受信する手段と、
　応答の受信に応答して、他システムより発行された支払い確認を受け取る手段と、
　商人システムがディリバラブルを顧客に入手可能にする手段と
　を含む商人システム。　　　」 
　　 
である点で一致し、以下の点で相違する。 
　　  
［相違点１］  
　本願発明は、「顧客の連絡先」が、「顧客の携帯電話」であり、
　「顧客によって提供された顧客の連絡先を事前に登録する手段」が、「顧客システムまたは顧客の携帯電話によって提供された顧客の携帯電話の電話番号を、商人システムの電話番号メモリに事前に登録する手段」であり、
　「顧客の連絡先を取得する手段」が、「携帯電話の電話番号を電話番号メモリから取得する手段」であり、
　「取得した顧客の連絡先にディリバラブルの注文確認を送る手段」が、「取得した携帯電話の電話番号を用いて携帯電話にディリバラブルに対する注文確認を送る手段」であり、
　「顧客からのディリバラブルの注文の確認に対する応答を受信する手段」が、「携帯電話からのディリバラブルの注文の確認に対する応答を受信する手段」であるのに対し、引用例１発明ではそのようになっていない点。
　　 
［相違点２］
　本願発明は、「商人システム」が「顧客システムからディリバラブルの注文を受信」するのに対し、引用例１発明ではそのようになっていない点。
　　
［相違点３］ 
　本願発明は「支払い」が、電気通信事業者システムが携帯電話に対して発行する電話代請求書により顧客に請求されて支払われるものであり、
　「応答の受信に応答して、他システムより発行された支払い確認を受け取る手段」が、「応答の受信に応答して、仕掛り取引の詳細を電気通信事業者システムに送信する手段と、電気通信事業者システムにより発行された支払い確認を受け取る手段」であるのに対し、引用例１発明ではそのようになっていない点。
　　 
４−３．判断  
　　 
［相違点１］について。 
　上記引用例２の摘記事項（エ）乃至（サ）によれば、引用例２には、「クレジットカードを利用して小売り業者から製品を購入した際の、支払いの承認／否認を確認するために、店頭でクレジットカードを読み取ると、予め登録された顧客個人の電話番号を自動ダイヤルし、顧客個人が電話のダイヤルパッドや双方向ポケットベルのメッセージ送信で応答することにより、個人が真のカードの所有者であることを証明すること。」（以下「引用例２記載事項」という。）が記載されている。
　ここで、
　顧客の所持する電話やポケベルは本願発明の「携帯電話」に相当するものと認められること。
　顧客の電話番号は何らかの形で、電話番号メモリに事前に登録され、電話番号メモリから取得されるものであると認められること。
　顧客からの支払いの承認は、購入した製品のクレジットによる支払いを承認するものであることから、製品の購入の確認、即ちディリバラブルの注文の確認でもあると認められること。
　顧客が電話番号を提供する際、顧客システムまたは携帯電話により提供されると考えることが自然であり、そのように構成することには何ら困難性がないこと。
　以上のとおりであることから、引用例１発明に引用例２記載事項を適用し、もって、「顧客によって提供された顧客の連絡先を事前に登録する手段」を、「顧客システムまたは顧客の携帯電話によって提供された顧客の携帯電話の電話番号を、商人システムの電話番号メモリに事前に登録する手段」とし、「顧客の連絡先を取得する手段」を、「携帯電話の電話番号を電話番号メモリから取得する手段」とし、「取得した顧客の連絡先にディリバラブルの注文確認を送る手段」を、「取得した携帯電話の電話番号を用いて携帯電話にディリバラブルに対する注文確認を送る手段」とし、「顧客からのディリバラブルの注文の確認に対する応答を受信する手段」を、「携帯電話からのディリバラブルの注文の確認に対する応答を受信する手段」とすることは、当業者が容易に想到することができたものである。
　　
［相違点２］について
　ディリバラブルの注文の情報を何れから取得するかは、当業者が必要に応じて適宜選択し得る設計的事項であり、顧客システムからディリバラブルの注文を受信して情報を取得するよう構成することには何ら困難性がない。
　したがって、「商人システム」が「顧客システムからディリバラブルの注文を受信」するよう構成することは、当業者が容易に想到することができたものである。
　　 
［相違点３］について。 
　上記引用例３の摘記事項（シ）によれば、「移動通信事業者がユーザーのコンテンツ利用料金を通信料金とともに回収する」こと（以下「引用例３記載事項」という。）が記載されており、これは、電気通信事業者システムが電話に対して発行する電話代請求書により顧客に請求されて支払われることに相当する。
　ここで、電気通信事業者システムが、取引が発生した場合、その都度支払いの確認をするよう構成することには何ら困難性がない。
　してみると、引用例１発明に引用例３記載事項を適用し、もって、「応答の受信に応答して、他システムより発行された支払い確認を受け取る手段」を、「応答の受信に応答して、仕掛り取引の詳細を電気通信事業者システムに送信する手段と、電気通信事業者システムにより発行された支払い確認を受け取る手段」とすることは、当業者が容易に想到することができたものである。
　　 
　　 
　以上判断したとおり、本願発明における上記［相違点１］乃至［相違点３］に係る発明特定事項は、いずれも当業者が容易に想到することができたものであり、上記各相違点を総合しても、想到することが困難な格別の事項は
見いだせない。
　また、本願発明の作用効果も、引用例１乃至引用例３から当業者が予測できる範囲のものである。  
　　
４−４．まとめ  
　　 
　したがって、本願発明は、上記引用例１発明、引用例２記載事項、引用例３記載事項に基づいて、当業者が容易に発明をすることができたものである。  
　  
　  
５．むすび  
　以上のとおり、本願発明は、引用例１乃至引用例３に基づいて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができない。 
　　 
　よって、結論のとおり審決する。