【事件の表示】
　特願２００２−１５８５９５「証券情報配信システム」拒絶査定不服審判事件〔平成１６年　１月　８日出願公開、特開２００４−　　５０８６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は，平成１４年５月３１日の出願であって，平成１７年１月２６日付けで拒絶査定がなされ，これに対し，同年５月１９日に拒絶査定に対する審判請求がされるとともに，同年６月２０日付けで手続補正書が提出されたものである。そして，当審における審理の結果，平成２１年１月１６日付けで拒絶理由通知がなされ，これに対して，同年３月２３日付けで手続補正がなされた。
　
２．本願発明
　本件の請求項１に係る発明（以下「本願発明」という。）は，平成２１年３月２３日付けの手続補正により補正された特許請求の範囲の請求項１に記載された事項からみて，以下のとおりのものである。
　
「【請求項１】ユーザが所有する端末と証券情報を配信するサーバと金融機関に配置された金融機関用サーバとが通信網を介して相互に接続された証券情報配信システムにおいて，
　前記サーバは，予め定められた動作を行なう処理部と入力部と出力部とデータベース装置とを備え，
　前記データベース装置は，証券識別ＩＤ，公共事業等の名，証券の券面額，集めた資金を投下する公共事業等の内容，該公共事業等の企画者・遂行者の名，保証人の名，償還期限，利率，保証限度，配当，関係者のコメント等が対応付けられた各証券の証券情報が一又は複数記載された証券情報テーブルを複数有すると共に，ユーザＩＤ，ユーザ名，ユーザ属性，口座番号，ユーザの端末操作に関する履歴情報が相互に関連付けられたユーザに関する情報が記載されたユーザデータテーブルを格納してなり，
　前記処理部は，前記ユーザＩＤと共に前記証券情報テーブルに格納されている全証券の証券識別ＩＤを要求する全証券情報送信要求と，前記ユーザＩＤと共に証券識別ＩＤを含む特定証券に関する情報を要求する特定証券情報送信要求とを受信する要求受信手段と，
　前記端末からの全証券情報送信要求に応じて，前記証券情報テーブルに格納されている全ての証券識別ＩＤを含む全証券表示情報を前記ユーザＩＤで識別されたユーザ名と共に前記端末に送信する全証券情報送信手段と，
　前記端末からの特定証券情報送信要求に応じて，受信した前記証券識別ＩＤによって前記データベース装置を検索して前記特定証券に関する情報を抽出する検索抽出手段と，
　前記検索抽出手段で抽出した，前記公共事業等の名，証券の券面額，集めた資金を投下する公共事業等の内容，該公共事業等の企画者・遂行者の名，保証人の名，償還期限，利率，保証限度，配当，関係者のコメント等に関する情報を含む特定証券に関する情報である特定証券表示情報を前記端末に送信する特定証券情報送信手段と，
　前記端末からの特定証券情報の購入申込を申込に係る証券識別ＩＤと共に受信する申込受信手段と，
　前記申込受信手段で受信した証券識別ＩＤの購入申込の確認情報を前記端末に送信する確認情報送信手段と，
　前記端末からの確認情報に対する証券購入の確定情報を受信する確定情報受信手段と，
　前記確定情報受信手段で確定情報を受信したとき，前記端末に対して承諾情報を送信する承諾情報送信手段と，
　前記ユーザＩＤに基づいて前記ユーザデータテーブルの口座番号を検出する口座検出手段と，
　前記口座検出手段で検出した口座番号から前記購入した特定証券の購入金額を証券会社の口座に振り込む旨の指示を前記金融機関用サーバに送信する指示送信手段とを備え，
　前記端末は，予め定められた動作を行なう処理部と入力部と表示部とを備え，
　前記入力部は，ユーザの操作に応じて前記全証券表示情報の中から選択された特定証券を選択し，
　前記表示部は，受信した前記全証券表示情報と前記特定証券表示情報とを画面に表示し，
　前記処理部は，前記ユーザＩＤと共に前記全証券情報送信要求を送信すると共に，前記入力部で選択された証券識別ＩＤと共に特定証券情報送信要求を前記サーバに送信する送信部と，
　前記全証券表示情報と前記特定証券表示情報とを前記サーバから受信する受信部と，
　前記入力部で選択された特定証券の購入申込を前記サーバの申込受信
手段
　前記サーバの確認情報送信手段から送信された確認情報を受信する確認情報受信部と，
　前記確認情報受信部で受信した確認情報に対し前記入力部の操作に応じて確定情報を送信する確定情報送信部と，
　前記サーバの承諾情報送信手段から送信された承諾情報を受信する承諾情報受信部と，
　前記承諾情報受信部が前記承諾情報を受信すると，前記表示部に，前記購入申込に係る証券を購入した旨を表示し，前記サーバと前記端末との間における一連の処理を終了することを前記入力部で選択すると，前記サーバの端末との間における一連の処理を終了させる終了情報を前記サーバに送信する終了情報送信手段とを備え，
　前記承諾情報受信部が前記承諾情報を受信して，前記表示部に，前記購入申込に係る証券を購入した旨を表示したときに，前記サーバと前記端末との間における一連の処理を終了させないことを前記入力部で選択すると，前記送信部から前記ユーザＩＤと共に前記全証券情報送信要求を送信し，
　前記端末との間における一連の処理を終了した前記サーバの口座検出手段では，前記ユーザデータテーブルの口座番号を検出し，
　前記金融機関用サーバは，予め定められた動作を行なう処理部と預金データベースを備え，
　前記処理部は，前記サーバの指示送信部から送信された指示を受信すると，前記購入した特定証券の購入金額をユーザの口座番号の口座から証券会社の口座に振り込む旨の指示に基づいて預金データベースを更新する更新部を備えることを特徴とする証券情報配信システム。」
　なお，請求項１に記載された「前記入力部で選択された特定証券の購入申込を前記サーバの申込受信部に送信する申込送信部」における「前記サーバの申込受信
部
手段
　
３．引用例
（１）引用例１
　当審で通知した拒絶理由で引用した特開２００２−４９８７７号公報（平成１４年２月１５日出願公開）（以下，「引用例１」という。）には，図面と共に，以下の事項が記載されている。
（Ａ）【００１１】〜【００２１】段落の記載
 「【００１１】
【発明の実施の形態】次に本発明の実施の形態について図面を参照して詳細に説明する。
【００１２】図１を参照すると，本発明の有価証券売買システムの実施の形態は，ユーザ端末１０と，有価証券販売管理システム２０と，有価証券取引市場システム３０と，銀行口座管理システム４０と，これらを相互に接続するインターネット等のネットワーク１００とから構成されている。
【００１３】ユーザ端末１０は，パーソナルコンピュータ等のコンピュータである。ユーザ端末１０は，有価証券販売管理システム２０がネットワーク１００上に提供している有価証券情報にアクセスし，当該有価証券情報を画面に表示する機能を備えている。有価証券情報は，例えば，株式，債権，株式指数オプション等の有価証券に関する情報である。ユーザ端末１０は，さらに，注文者が売買を希望する有価証券の情報である売買注文情報や，注文者が売買を希望する有価証券の約定代金の決済を行う銀行口座を示す取引銀行口座指定情報をネットワーク１００を介して有価証券販売管理システム２０に送信する機能を有する。尚，図１に於いては，ユーザ端末を１台しか図示していないが，実際には複数台のユーザ端末がネットワーク１００に接続されている。
【００１４】ユーザ端末１０が備えている記録媒体Ｋ１は，ディスク，半導体メモリ，その他の記録媒体であり，コンピュータをユーザ端末１０として機能させるためのプログラムが記録されている。このプログラムは，コンピュータによって読み取られ，コンピュータの動作を制御することで，コンピュータに，図２のステップＡ１，Ａ３〜Ａ７，Ａ２１の処理を行わせる。
【００１５】有価証券販売管理システム２０は，有価証券販売者により管理され，ワークステーション・サーバ等のコンピュータによって構成される。有価証券販売管理システム２０は，注文者の操作によりユーザ端末１０が送出した売買注文情報と取引銀行口座指定情報とを受け取り，注文者，売買情報，取引銀行口座指定情報に誤りがないか確認し，誤りがなければ売買注文情報を有価証券取引市場システム３０に送信する機能とを備えている。さらに，有価証券販売管理システム２０は，有価証券取引市場システム３０から送信される取引結果を受け取り，それが約定内容を示している場合は，銀行口座管理システム４０に，約定代金決済情報を送信する機能を備えている。尚，図１に於いては，有価証券販売管理システム２０を１台しか図示していないが，実際には，複数台の有価証券販売管理システム２０がネットワーク１００に接続されている。
【００１６】有価証券販売管理システム２０が備えている記憶装置２１には，図３に示すようなユーザ情報が登録されている。ユーザ情報は，各注文者毎の注文者ＩＤと，パスワードと，約定代金決済処理に使用可能な銀行口座と，売買注文に対する制限と，保有している有価証券を示す情報とを含んでいる。図３の例は，注文者ＩＤ「ＩＤａ」の注文者は，パスワードが「Ｐａ」，約定代金決済処理に使用可能な銀行口座が「ＸＸＸＸ」，「ＹＹＹＹ」，「ＺＺＺＺ」の３つ，売買注文に対する制限が「なし」，保有している有価証券が「Ａ株 10000株」, 「Ｂ株 10000株」であることを示し，注文者ＩＤ「ＩＤｂ」の注文者は，パスワードが「Ｐｂ」，約定代金決済処理に使用可能な銀行口座が「ＪＪＪＪ」，売買注文に対する制限が「成り行き禁止」，保有している有価証券が「Ｃ株 1000株」であることを示している。
【００１７】また，有価証券販売管理システム２０が備えている記録媒体Ｋ２は，ディスク，半導体メモリ，その他の記録媒体であり，コンピュータを有価証券販売管理システム２０として機能させるためのプログラムが記録されている。このプログラムは，コンピュータによって読み取られ，コンピュータの動作を制御することで，コンピュータに，図２のステップＡ２，Ａ８〜Ａ１０，Ａ１４，Ａ１５，Ａ１９，Ａ２０の処理を行わせる。
【００１８】有価証券取引市場システム３０は，コンピュータによって実現されるものであり，複数の有価証券販売管理システム２０からの売買注文情報を受け取り，取引を仲介し，取引結果を有価証券販売管理システム２０に送信する機能を備えている。
【００１９】有価証券取引市場システム３０が備えている記録媒体Ｋ３は，ディスク，半導体メモリ，その他の記録媒体であり，コンピュータを有価証券取引市場システム３０として機能させるためのプログラムが記録されている。このプログラムは，コンピュータによって読み取られ，コンピュータの動作を制御することで，コンピュータに，図２のステップＡ１１〜Ａ１３の処理を行わせる。
【００２０】銀行口座管理システム４０は，銀行で管理され，ワークステーション・サーバ等のコンピュータによって構成される。銀行口座管理システム４０は，有価証券販売管理システム２０から約定代金決済情報を受け取り，約定代金決済情報が買い注文により発生したものである場合は注文者の指定口座から指定金額を有価証券販売管理システム２０の口座に振り替え，売り注文の場合は，有価証券販売管理システム２０の口座から注文者の指定口座に約定代金を振り替える機能を備えている。
【００２１】銀行口座管理システム４０が備えている記録媒体Ｋ４は，ディスク，半導体メモリ，その他の記録媒体であり，コンピュータを銀行口座管理システム４０として機能させるためのプログラムが記録されている。このプログラムは，コンピュータによって読み取られ，コンピュータの動作を制御することで，コンピュータに，図２のステップＡ１６〜Ａ１８の処理を行わせる。」
（Ｂ）【００２２】〜【００３８】段落の記載
 「【００２２】
【実施の形態の動作】次に，本実施の形態の動作について詳細に説明する。尚，以降の説明では，ネットワーク１００はインターネットであるとする。
【００２３】図２を参照すると，注文者は，自分のユーザ端末１０を介して，有価証券販売管理システム２０がインターネット１００上に開設している有価証券販売ホームページにアクセスする（ステップＡ１）。その際，注文者は，自身の注文者ＩＤ，パスワードを有価証券販売管理システム２０へ送信する。
【００２４】有価証券販売管理システム２０は，ユーザ端末１０から注文者ＩＤ，パスワードが送られてくると，このパスワードと記憶装置２１に登録されている上記注文者ＩＤに対応するパスワードとを照合する。そして，両者が一致している場合は，種々の有価証券情報（証券コードや銘柄を含む）をユーザ端末１０に送信すると共に，上記注文者ＩＤと対応して記憶装置２１に登録されている，注文者が約定代金決済に使用することが可能な銀行口座をユーザ端末１０に送信する（ステップＡ２）。尚，パスワードが一致していない場合は，有価証券販売管理システム２０は，ユーザ端末１０に対してパスワードの再送を要求する。
【００２５】これにより，ユーザ端末１０は，先ず，図４に示すような有価証券情報画面を表示装置（図示せず）に表示する（ステップＡ３）。この有価証券情報画面には，有価証券販売管理システム２０から送られてきた証券コード，銘柄を含む有価証券情報が表示されると共に，注文条件情報の入力欄が表示される。注文条件情報は，取引する株数と，売りか買いかを示す売買種別と，成り行きか指し値かを示す注文種別と，指し値とを含む。
【００２６】注文者は，図４の有価証券情報を見て売買したい有価証券を決定し，注文条件情報入力欄の当該有価証券に対応する行に，キーボード等を用いて必要事項を入力する（ステップＡ４）。今，例えば，図４の有価証券情報画面を見て株式会社Ａの株式1000株を成り行きで買い，株式会社Ｄの株式1000株を指し値で売ることを決定したとすると，注文者は，図５に示すように注文条件情報入力欄の株式会社Ａと対応する第１行目に株数「1000」，売買種別「買い」，注文種別「成り行き」を入力すると共に，株式会社Ｄと対応する第４行目に株数「1000」，売買種別「売り」，注文種別「指し値」，指し値「α」を入力する。ユーザ端末１０は，このようにして入力された注文条件情報と，入力された注文条件情報と同一行の有価証券情報との対を，売買注文情報として一時的に保持する。この図５の例の場合は，証券コード「ＮＮＮＮ」，銘柄「株式会社Ａ」，株数「1000」，売買種別「買い」，注文種別「成り行き」からなる第１の売買注文情報と，証券コード「ＱＱＱＱ」，銘柄「株式会社Ｄ」，株数「1000」，売買種別「売り」，注文種別「指し値」，指し値「α」からなる第２の売買注文情報との２つを一時的に保持することになる。
【００２７】　・・・（略）・・・
【００２８】その後，ユーザが図６の「注文」ボタンをマウスでクリックすると，ユーザ端末１０は，保持している売買注文情報それぞれに保持している取引銀行口座指定情報を付加し，ネットワーク１００を介して有価証券販売管理システム２０へ送信する（ステップＡ７）。　・・・（略）・・・
【００２９】有価証券販売管理システム２０は，売買注文情報と取引銀行口座指定情報との組を受信すると（ステップＡ８），受信した各組に対して以下の処理を行う。内容が正しいか否かをチェックし（ステップＡ９），正しい場合には売買注文情報に，自システム２０のシステム識別子と，売買注文情報を特定するための売買注文識別子（例えば連番）とを付加して有価証券取引市場システム３０に発信し（ステップＡ１０），正しくない場合には，ユーザ端末１０にエラー通知を行う。尚，ステップＡ１０に於いては，ステップＡ８で受信した売買注文情報と取引銀行口座指定情報との組と，上記売買注文を行った注文者の注文者ＩＤと，ステップＡ１０で付加した売買注文識別子とを対応付けて登録しておく処理も行う。
【００３０】〜【００３２】　・・・（略）・・・
【００３３】有価証券販売管理システム２０は，有価証券取引市場システム３０から，取引結果と売買注文識別子との対を受信すると，取引が成立しているか否かを調べる（ステップＡ１４）。そして，成立していない場合は，その取引の注文者が使用しているユーザ端末１０に取引不成立を通知する。尚，その際，ステップＡ１０に於いて登録した情報の内の，上記売買注文識別子と対応して登録されている売買注文情報もユーザ端末１０に通知することにより，どの売買注文に対する取引が不成立になったのかを注文者が認識できるようにする。また，上記売買注文識別子に関連する情報を削除する。
【００３４】これに対して，取引が成立している場合は，有価証券販売管理システム２０は，取引銀行口座指定情報で指定された銀行口座で約定代金を決済するため，約定代金決済情報を作成し，銀行口座管理システム４０に送信する（ステップＡ１５）。ここで，約定代金決済情報は，例えば，次のようにして作成する。先ず，ステップＡ１４で受信した売買注文識別子をキーにしてステップＡ１０で登録した情報を検索し，上記売買注文識別子を含む情報を探し出す。次いで，この探し出した情報から取引銀行口座指定情報，注文者ＩＤを抽出し，その後，上記売買注文識別子に関する情報を削除する。次いで，ステップＡ１４で受信した取引結果から，約定代金決済すべき金額と，取引が売りか買いかを示す情報を抽出する。そして，取引が売りであった場合は，有価証券販売管理システム２０の銀行口座から上記取引銀行口座指定情報によって示される注文者が指定した銀行口座へ，上記抽出した金額を振り込ませるための約定代金決済情報を作成する。これに対して，取引が買いであった場合は，上記取引銀行口座指定情報によって示される注文者が指定した銀行口座から有価証券販売管理システム２０の銀行口座へ，上記抽出した金額を振り込ませるための約定代金決済情報を作成する。また，取引が成立している場合には，ユーザ情報（図３参照）中の注文者が所有している有価証券を示す情報を，取引結果に応じて更新する。
【００３５】銀行口座管理システム４０は，約定代金決済情報を受信すると（ステップ１６），約定代金決済情報中の銀行口座が事前に登録されていた内容と一致するかチェックし，正しい場合は指定口座と有価証券販売管理システム２０の口座間で振り替えを行い約定代金を決済する（ステップ１７）。決済結果は，銀行口座管理システム４０から有価証券販売管理システム２０へ送信される（ステップ１８）。
【００３６】有価証券販売管理システム２０は，銀行口座管理システム４０から決済結果を受信すると，それをユーザ端末１０に送る（ステップＡ１９，Ａ２０）。
【００３７】ユーザ端末１０は，有価証券販売管理システム２０からの決済結果を受信すると，それを表示する（ステップＡ２１）。
【００３８】有価証券販売管理システム２０は，売買注文情報および取引銀行口座指定情報のチェック結果，有価証券取引市場システム３０からの取引結果，銀行口座管理システム４０からの決済結果に関する情報について，注文者が有価証券販売システムのホームページ上で確認できるようにしてもよいし，電子メール等により注文者に通知されるようにしてもよい。」
　
（ａ）上記【００１２】〜【００１３】，【００１５】，【００２０】段落の記載より，引用例１記載の有価証券売買システムは，パーソナルコンピュータ等のコンピュータであるユーザ端末と，有価証券販売管理システムと，銀行口座管理システムと，これらを相互に接続するインターネット等のネットワークから構成されている債権等の有価証券を売買するためのシステムである。また，有価証券販売管理システムは，ワークステーション・サーバ等のコンピュータによって構成されており，上記【００２４】段落の記載より，種々の有価証券情報（証券コードや銘柄を含む）をユーザ端末に送信する機能を有している。さらに，銀行口座管理システムは，銀行で管理され，ワークステーション・サーバ等のコンピュータによって構成されるのであるから，金融機関に配置されていることが明らかである。よって，引用例１には，パーソナルコンピュータ等のコンピュータであるユーザ端末と種々の有価証券情報（証券コードや銘柄を含む）を送信するワークステーション・サーバ等のコンピュータによって構成された有価証券販売管理システムと金融機関に配置されたワークステーション・サーバ等のコンピュータによって構成された銀行口座管理システムとがネットワークを介して相互に接続された有価証券売買システムが開示されている。
（ｂ）上記【００１３】〜【００１７】，【００２０】〜【００２１】段落の記載より，引用例１記載の有価証券売買システムのユーザ端末，有価証券販売管理システム，銀行口座管理システムは，それぞれ記録媒体に記憶されたプログラムにより制御されたコンピュータを備えており，予め定められた動作を行う処理部が備えられていることは明らかである。また，当該ユーザ端末は，有価証券情報画面に，有価証券販売管理システムから送られてきた証券コードを含む有価証券情報が表示されると共に，注文条件情報の入力欄が表示され，注文者が売買したい有価証券を，所定の入力欄にキーボード等を用いて必要事項を入力することにより決定し，当該有価証券販売管理システムは，当該ユーザ端末が送出した売買注文情報を受け取り，注文者，売買情報に誤りがないか確認し，誤りがなければ売買注文情報を有価証券取引市場システムに送信する機能とを備えているのであるから，当該ユーザ端末と，当該有価証券販売管理システムは，それぞれ入力部と出力部とを備えており，当該ユーザ端末は，入力部と出力部に加えて表示部を備えていることが明らかである。さらに，当該有価証券販売管理システムは，ユーザ情報が登録された記憶装置を備えている。また，銀行口座管理システムは，約定代金決済情報により注文者の口座から指定金額を有価証券販売管理システムの口座に振り替える機能を持っているのであるから，口座の情報を記憶する記憶部を備えていることは明らかである。よって，引用例１の有価証券販売管理システムは，予め定められた動作を行う処理部と入力部と出力部と記憶装置とを備えていることが開示されており，有価証券売買システムのユーザ端末は，予め定められた動作を行う処理部と入力部と表示部とを備えていることが開示されており，銀行口座管理システムは，予め定められた動作を行う処理部と記憶部を備えていることが開示されている。
（ｃ）上記【００１６】段落の記載より，前記有価証券販売管理システムが備える記憶装置には，注文者ＩＤと，約定代金決済処理に使用可能な銀行口座とを示すユーザ情報が登録されており，第３図の記載より，当該注文者ＩＤと，当該銀行口座は相互に関連付けられていることが明らかであるから，引用例１の価証券販売管理システムが備える記憶装置は，注文者ＩＤ，銀行口座が相互に関連付けられたユーザ情報を格納していることが開示されている。
（ｄ）上記【００２４】段落の記載より，前記有価証券販売管理システムは，ユーザ端末から注文者ＩＤが送られてくると，注文者ＩＤを確認後に，種々の有価証券情報（証券コードや銘柄を含む）をユーザ端末に送信する処理を行っており，当該処理が前記有価証券販売管理システムの処理部によって実行されることは明らかである。よって，引用例１の有価証券販売管理システムの処理部は，注文者ＩＤを受信する受信手段と，端末からの注文者ＩＤに応じて，証券コードを含む有価証券情報を前記端末に送信する有価証券情報送信手段とを備えることが開示されている。また，引用例1のユーザ端末の処理部は，注文者ＩＤを有価証券販売管理システムに送信する送信部と，有価証券情報を有価証券販売管理システムから受信する受信部とを備えることが開示されている。
（ｅ）上記【００２８】〜【００２９】段落の記載より，引用例１のユーザ端末は，ユーザが「注文」ボタンをマウスでクリックすると，ユーザ端末は，保持している売買注文情報をネットワークを介して有価証券販売管理システムへ送信している。一方，有価証券販売管理システムは，ユーザ端末からの売買注文情報を受信すると，内容をチェックし，正しい場合には売買注文情報を有価証券取引市場システムに発信している。また，当該売買注文情報は，上記【００２６】段落の記載より，注文者が有価証券情報を見て売買したい有価証券を決定し，キーボード等を用いて入力した情報であって，証券コード「ＮＮＮＮ」を含んでいる。さらに，有価証券の売買を注文することは，有価証券の購入を申込む処理を含むことは明らかである。よって，引用例１の有価証券販売管理システムの処理部は，端末からの売買注文情報を申込に係る証券コードと共に受信する申込受信手段を備えることが開示されている。また，引用例1のユーザ端末の処理部は，入力部で選択された有価証券の購入申込を有価証券販売管理システムの申込受付手段に送信する申込送信部とを備えることが開示されている。
（ｆ）上記【００２４】段落の記載より，有価証券販売管理システムは，ユーザ端末から注文者ＩＤが送られてくると，確認後に，上記注文者ＩＤと対応して記憶装置に登録されている，注文者が約定代金決済に使用することが可能な銀行口座をユーザ端末に送信する処理を行っているので，引用例１の価証券販売管理システムの処理部は，注文者ＩＤに基づいてユーザ情報の決済処理に使用可能な銀行口座を検出する口座検出手段を備えることが開示されている。
（ｇ）上記【００３４】，【００３５】段落の記載より，有価証券販売管理システムは，指定された銀行口座で約定代金を決済するため，注文者が指定した銀行口座から有価証券販売管理システムの銀行口座へ，抽出した金額を振り込ませるための約定代金決済情報を作成し，銀行口座管理システムに送信しており，銀行口座管理システムは，約定代金決済情報を受信すると，チェック後に指定口座と有価証券販売管理システムの口座間で振り替えを行い約定代金を決済する処理を行っている。有価証券販売管理システムと銀行口座管理システムにおけるそれぞれの処理が，それぞれの処理部でなされること，銀行口座管理システムの処理部において，約定代金決済情報により注文者の口座から指定金額を有価証券販売管理システムの口座に振り替える処理を，口座の情報を記憶する記憶部を更新する更新機能により行うことは明らかである。また，有価証券の売買を注文する処理が，有価証券の購入を申込む処理を含むことは明らかである。よって，引用例１の有価証券販売管理システムの処理部は，口座検出手段で検出した決済処理に使用可能な銀行口座から購入した有価証券の購入金額を有価証券販売管理システムの銀行口座に振り込む旨の指示を金融機関に配置されたワークステーション・サーバ等のコンピュータによって構成された銀行口座管理システムに送信する指示送信手段を備えることが開示されている。また，引用例１の銀行口座管理システムの処理部は，有価証券販売管理システムの指示送信部から送信された指示を受信すると，購入した有価証券の購入金額を注文者が指定した銀行口座から有価証券販売管理システムの銀行口座に振り込む旨の指示に基づいて記憶部を更新する更新部を備えることが開示されている。
（ｈ）上記【００１３】〜【００１４】，【００２６】段落の記載より，引用例１記載の有価証券売買システムのユーザ端末は，有価証券情報画面に，有価証券販売管理システムから送られてきた証券コードを含む有価証券情報が表示されると共に，注文条件情報の入力欄が表示され，注文者が売買したい有価証券を，所定の入力欄にキーボード等を用いて必要事項を入力することにより決定している。また，有価証券の売買を注文する処理が，有価証券の購入を申込む処理を含むことは明らかである。よって，引用例１のユーザ端末の入力部は，注文者の操作に応じて購入する証券を選択し，表示部は，受信した証券情報を画面に表示することが開示されている。
（ｉ）上記【００３３】〜【００３７】段落の記載より，引用例１の有価証券販売管理システムは，取引が成立しているか否かを調べ，成立している場合，約定代金を決済するため，約定代金決済情報を作成し，銀行口座管理システムに送信し，銀行口座管理システムから決済結果を受信すると，それをユーザ端末に送り，ユーザ端末は，有価証券販売管理システムからの決済結果を受信するとそれを表示する処理をおこなっている。当該取引とは，有価証券の購入申込に係る証券を購入する取引であることは明らかである。よって，引用例1には，ユーザ端末の前記表示部に，購入申込に係る証券を購入した旨を表示する手段を備えることが開示されている。
　
　そうしてみると，引用例１には，以下の発明（以下，「引用例１記載の発明」という。）が開示されていると認められる。
 「パーソナルコンピュータ等のコンピュータであるユーザ端末と種々の有価証券情報（証券コードや銘柄を含む）を送信するワークステーション・サーバ等のコンピュータによって構成された有価証券販売管理システムと金融機関に配置されたワークステーション・サーバ等のコンピュータによって構成された銀行口座管理システムとがネットワークを介して相互に接続された有価証券売買システムにおいて，
　前記有価証券販売管理システムは，予め定められた動作を行なう処理部と入力部と出力部と記憶装置とを備え，
　上記記憶装置は，注文者ＩＤ，決済処理に使用可能な銀行口座が相互に関連付けられたユーザ情報を格納してなり，
　上記処理部は，前記注文者ＩＤを受信する受信手段と，
　前記端末からの注文者ＩＤに応じて，証券コードを含む有価証券情報を前記端末に送信する有価証券情報送信手段と，
　前記端末からの売買注文情報を申込に係る証券コードと共に受信する申込受信手段と，
　前記注文者ＩＤに基づいて前記ユーザ情報の決済処理に使用可能な銀行口座を検出する口座検出手段と，
　前記口座検出手段で検出した決済処理に使用可能な銀行口座から前記購入した有価証券の購入金額を有価証券販売管理システムの銀行口座に振り込む旨の指示を前記金融機関に配置されたワークステーション・サーバ等のコンピュータによって構成された銀行口座管理システムに送信する指示送信手段とを備え，
　前記ユーザ端末は，予め定められた動作を行なう処理部と入力部と表示部とを備え，
　前記入力部は，注文者の操作に応じて購入する有価証券を選択し，
　前記表示部は，受信した有価証券情報を画面に表示し，
　前記処理部は，前記注文者ＩＤを前記有価証券販売管理システムに送信する送信部と，
　前記有価証券情報を前記有価証券販売管理システムから受信する受信部と，
　前記入力部で選択された有価証券の購入申込を有価証券販売管理システムの申込受信手段に送信する申込送信部と，
　前記表示部に，前記購入申込に係る有価証券を購入した旨を表示する手段を備え，
  前記銀行口座管理システムは，予め定められた動作を行う処理部と記憶部を備え，
  前記処理部は，前記有価証券販売管理システムの指示送信部から送信された指示を受信すると，前記購入した有価証券の購入金額を注文者が指定した銀行口座から有価証券販売管理システムの銀行口座に振り込む旨の指示に基づいて記憶部を更新する更新部を備える
　ことを特徴とする有価証券売買システム。」
　
（２）引用例２
　同じく，当審で通知した拒絶理由で引用した特開２００１−３３８１３０号公報（平成１３年１２月７日出願公開）（以下，「引用例２」という。）には，図面と共に，以下の事項が記載されている。
（Ｃ）【０００１】〜【００１３】段落の記載
 「【０００１】
【発明の属する技術分野】本発明は，公共施設等，たとえば公営住宅，公民館，公的福祉ないし介護施設，公立図書館，公営体育館，道路，橋，空港，地下鉄等の建設，管理に適用するためのシステムに関する。
【０００２】
【従来の技術】一般に，この種の公共施設等を，国，都道府県，市区町村，あるいはそれに準ずる公社，公団，営団等の各種公共団体が建設，管理する場合，その公共施設等の企画，建設，維持をはじめ，管理，運営に至るまで公共団体自体が行うのが通常であった。
【０００３】ところが，公共施設の建設，管理等には，莫大な資金等を必要とする場合も多く，また事業の効率的実施等の要請もあり，民間の資金，経営能力，技術的能力等を有効に活用する方が有利である，という考え方が提案されるようになって来た。
【０００４】そこで，従来は国，地方公共団体等が行って来た公共施設等の企画，建設，維持，管理，運営等を民間に委ねる方式として，いわゆるＰＦＩ（Private Finance Initiative：民間資金等活用）事業を推進するため，ＰＦＩ法が制定され，施行されている。
【０００５】ＰＦＩ法に基づく事業の実施プロセスは図６に示す通りであるが，ここでは詳細な説明は省略するが，「基本方針の決定」，「事業の選定」，「事業者の選定」，「契約」，「事業の実施」のプロセスを経て事業が完了するように策定されている。
【０００６】
【発明が解決しようとする課題】ところで，ＰＦＩ法が制定，施行されても，その実施事業が実際に活用されなければ，実効は挙げられないので，民間事業者が合目的的にいわゆるＳＰＣ法によるＳＰＣ（Special Purpose Company ：特定目的会社）を設立し，ＰＦＩの活用を推進することが考えられている。
【０００７】いわゆるＳＰＣ法によるＳＰＣ（特定目的会社）は，一つの事業，業務についての目的で設立され，特定（目的）資産の流動化に係わる業務の運営を行うためのものである。
【０００８】そして，特定（目的）資産とは，指名金銭債権（貸付け債権，リースクレジット債権，売掛債権）・不動産（土地，建物）・これらを信託する信託の受益権を指す。
【０００９】また，特定（目的）資産の流動化とは，資産対応証券（優先出資証券・特定社債権・特定約束手形）の発行によって得られた金銭で，特定資産を取得し，資産の管理・処分によって得られた金銭で資産対応証券の元本や利回り配当等の支払いをするものである。
【００１０】しかし，単にＰＦＩ法とＳＰＣ法によるＳＰＣとを組み合わせると言っても，単にそれだけでは有効に機能せず，実効は挙がらない。
【００１１】そこで，本発明者らが検討したところ，従来のように公共施設等の所有権を施設建設会社等の民間業者等が有している方式では十分な実効を図れないことが判明した。
【００１２】したがって，本発明の１つの目的は，ＰＦＩ事業に対してＳＰＣ法によるＳＰＣの有効利用を図ることのできる公共施設等の建設・管理システムを提供することにある。
【００１３】また，本発明の他の１つの目的は，機関投資家等の保護を図ることのできる公共施設等の建設・管理システムを提供することにある。」
　
（Ｄ）【００４３】〜【００５４】段落の記載
 「【００４３】（実施の形態３）図３は本発明のさらに他の実施の形態によるシステムを示す図である。
【００４４】図３のシステムはたとえば高速道路の建設・管理のための例があり，このシステムにおけるスキームの流れのステップは図１および図２の例とは異なる。
【００４５】すなわち，図３のシステムでは，ＳＰＣ４はたとえば資産対応証券の如き証券を発行して投資家６から代金を回収し，ＰＦＩ事業主体に事業資金を提供する。
【００４６】一方，施設完成後の所有権移転時に，たとえば東京都等の地方公共団体である公共団体等３には，国９からたとえば５０％の補助金が支給される。また，残額のうち，２５％は国９からＰＦＩ事業主体２に対して無利子で融資され，他の２５％は公共団体等３の負担分で，たとえば簡易保険金等の公的資金または民間資金を３０年割賦返済する。
【００４７】図３のシステムにより，莫大な資金を必要とする高速道路建設がＰＦＩ事業とＳＰＣ方式で実行可能となる。
【００４８】（実施の形態３）図４は本発明のさらに他の実施の形態によるシステムを示す図である。
【００４９】本システムは，たとえば公営住宅の建設，管理をＰＦＩ事業で行う例であり，ＳＰＣが建設時のＳＰＣすなわち第１のＳＰＣ４ａと，建設後のＳＰＣすなわち第２のＳＰＣ４ｂとの２つ設立されているものである。したがって，図４のシステムにおけるスキームの流れのステップは図１および２のものや図３のものとも異なる。
【００５０】すなわち，第１のＳＰＣ４ａは施設建設時に指名金銭債権を特定資産として設立され，第２のＳＰＣ４ｂは施設建設後に指名金銭債権を特定資産として設立され，それぞれ日本開発銀行や金融機関等の投資家６ａ，あるいは日本開発銀行や乞うて来資金（郵便貯金，簡易保険金等）により債権購入される。
【００５１】図４のシステムの場合，建設時に第１のＳＰＣ４ａで投資家６ａから債権購入が行われるが，施設建設後の所有権移転に対応して公共団体等３からＰＦＩ事業主体２に建築工事費の５０％が支払われ，さらにＰＦＩ事業主体２から第１のＳＰＣ４ａに建築工事費の５０％が支払われる。
【００５２】一方，建設後の指名金銭債権を特定資産として設立された第２のＳＰＣ４ｂは第２の投資家６ｂからの債権購入により建築工事費の残りの５０％をステップの如く第１のＳＰＣ４ａに送金する。
【００５３】そして，第１のＳＰＣ４ａから施設建設会社５に建築工事費が支払われるが，施設建設会社５への工事発注はＰＦＩ事業主体２から行われている。
【００５４】また，第１のＳＰＣ４ａおよび第２のＳＰＣ４ｂからそれぞれの投資家６ａ，６ｂへの元利償還も行われる。」
　
（３）引用例３
　同じく，当審で通知した拒絶理由で引用した特開２０００−１４８８７５号公報（平成１２年５月３０日出願公開）（以下，「引用例３」という。）には，図面と共に，以下の事項が記載されている。
（Ｅ）【０００１】〜【００２３】段落の記載
 「【０００１】
【産業上の利用分野】本発明は，個人または複数の投資家と，担保不足を保証する第三者の投資保証機関と，企業評価・調査・金融業務実行機関とをシステムの構成因子とし，前記企業評価・調査・金融業務実行機関は，融資元本と利息を保証し，借り手側の担保力の不足を第三者の投資による保証債券で補い，借り手側の融資を受けやすくし，金融システムの活性化を促すものである。
【０００２】また，借り手側の企業評価やベンチャーの内容，社会ニーズ等を調査し，融資債券，保証債券の発行体が，このシステムを実行するものであり，企業の資金調達が間接金融の落ち込みに引きづられて，深刻になっても，直接金融のメリットを導入して経済環境を活性化しょうとするシステムである。
【０００３】また，借り手側に債務不履行（デフォルト）が発生した時には，担保処分と保証債券の活用で得た利息収入で貸し手側に対する債務を弁済するもので，保証債券元本は保証されて年利９％にも達するようになっている。
【０００４】さらに，借り手側の企業経営の成功，企業の発展に伴って，保証債券には転換社債，ワラント債，その他特別配当などのプレミアムを付加することを目的とするようになっている。
【０００５】
【従来の技術】従来，金融機関を経由する預貯金から貸付に至る，いわゆる間接金融システムでは，近年，預貯金は超低利息であり，公定歩合も極低率でありながら貸付金利は従前通り高利息となっている。このような預かり利息と貸付利息の格差や，金融機関の貸付条件の種々の設定はもはや市場経済と整合性を欠いたものとなっている。
【０００６】現行の銀行法や，貸金法などの規制は相当厳しいが，グローバリゼーション（国際市場の一体化）によって，ディリバティブ（金融波及商品）や，スワップオプションなどを使った賭博性や不透明性による投資の弊害も，取り沙汰されており，今後は金融の証券化（セキュリタリゼーション）は大きく進められていくものと思われる。
【０００７】一般企業が金融機関から融資を受ける場合，先ず担保の評価が第一条件，即ち担保を基準にした貸付スキームである。
【０００８】こうした従来の金融システムは，預貯金の利息率の取り決めや，担保評価の自裁，連帯保証人の設定等，一方的に間接金融の弊害にさらされている。
【０００９】
【発明が解決しようとする問題点】本発明は，銀行の貸し渋りや貸付回収によって，運転資金の調達が難しくなって，健全経営の企業まで行き詰まっているから，早急に十分な手当をしないと，日本産業全体が雪崩現象を起こして崩壊してしまう。借り手側がいつも悩む担保力の不足は第三者の投資による保証債券で補い，貸し手側の融資（債券）によって生まれた資金は有効適切に活用されて元金が保証され，十分な利息収入が得られるように，直接金融のメリットを導入しようというものである。
【００１０】また，銀行の預貯金の利息が史上最低の超低利息が続いており，資金の調達や資産運用の点からも，老後の生活安定のためにも深刻な事態となって，新しい社会不安が予想されるようになってきた。超低公定歩合，超低預貯金金利と，一般の貸付金利の甚だしい利息格差が，金融機関を経由しているために預貯金者に正当に還元されていない。銀行の貸付原資は預貯金であり，本源的には預貯金の対価であるものを収奪しているものとみてもよく，預貯金の対価を守るために直接金融のメリットを導入しようというものである。
【００１１】金融機関の貸付条件の種々の設定は，もはや市場経済と整合性を欠いたものとなっており，徒に金融システムの安定策や金融機関の保護策に時間を費やしても貸し渋りや，貸付回収に改善がみられないし，また，預貯金者の超低利問題が一顧もされないようでは，内需拡大も景気回復もない。借り手側が融資を受ける際に，融資条件の担保能力等が満たされない場合に，第三者の投資する保証債券の保証をもって，借り手側が必要な資金を調達しやすくする必要がある。
【００１２】また，銀行の貸し渋り等にともなって，健全な経営企業まで運営資金の手当ができないから経営が行き詰まっているのが多く，これに充分な手当をしないと，日本の産業全体が雪崩現象を起こして崩壊に向かってしまう。そのために融資の調査は，確実性を主眼とするものばかりではなく，企業の将来性，ベンチャービジネスの中身，ベンチャービジネスの社会的ニーズを中心として調査することが重要である。
【００１３】なお，借り手側の返済の遅れ（モラトリアム）や，債務返済不履行（デフォルト）が発生した時には，保証債券が本来受け取るべき利息と，第一段階で据置きになっている保証債券の資金を，第二段階で融資資金として再活用する利息と，借り手側の担保の処分をもって，容易に弁済できる見通しを持ったシステムとする必要がある。
【００１４】貸し手側の融資に対して，安定した十分な利息が得られることは，国外投資などで国際金融市場の狂乱にさらされる事もなく，国内預貯金の国外流出が阻止されて，国内金融市場の安定化にもつながるものであり，大手企業による第三者の保証債券の投資が得られるようになれば，産業の活性化にも大いに役立つものである。
【００１５】また，借り手側が不正，非合法でないやむを得ない事情で債務返済不履行（デフォルト）になったときには担保の処分で終わり，以降の債務追求はしないもので，事業の失敗が，即人生の破局という不幸な悲劇は避けたいものである。
【００１６】
【課題を解決するための手段】本発明は，従来の問題点を解決するために，個人または複数の貸し手側の口座に設けられる融資債券１と，借り手側の担保能力不足を保証をする第三者の投資保証機関の口座に設けられる保証債券２と，借り手側発行の債務証券４と，企業の将来性，ベンチャービジネスの中身，ベンチャービジネスの社会的ニーズを中心として調査する企業評価・調査・金融業務実行機関の口座３を本システムの構成因子とし，積極的なキャピタルゲインを図るとともに，借り手側が合法的ながら止むなく債務不履行になったときは，提出された担保以上の債務責任を追求しないこととし，債務保証をすることを特徴とする新金融活性化システムである。
【００１７】融資の対価として発行する融資債券１の元金と利息は，債券発行体である金融業務実行機関が保証し，借り手側の債務不履行が発生した時は，第三者の保証債券２の資金活用で得た利息をもって弁済するものである。もちろん貸し手側の融資債券１及び保証債券２の利息，及びシステム実行機関の諸費用は借り手が融資を受けた利息として負担するものである。
【００１８】第三者の投資による保証債券２の元金は，債券発行体である金融業務実行機関が保証するが，保証債券２の活用で得た利息収入は，借り手側の債務不履行（デフォルト）が発生した時に，貸し手側への債務を弁済に充当するが，このシステムの実行によって得た収入を利息として保証債券２に配分する。だから変動利息であり，借り手側の債務不履行のないときは年利９％にもなるものである。
【００１９】借り手側の企業経営の成功，企業の発展に伴って，保証債券２には転換社債，ワラント債，その他特別配当などのプレミアムをが付加されることにもなっているが，借り手側が合法的な理由で止むなく債務不履行になった時には，提出した担保以上の債務の責任が追求されないものである。
【００２０】
【作 用】本発明による新金融活性化システムの手順を詳細に説明すると，融資債券１は下記条件とシステムの仕組みを明示して貸し手側の登録を受け付けて資金を募集する。
　　例　　１口金額　；仮　　　　１，０００万円
　　　　　年　　利　；固　　定　３％
　　　　　期　　間　；期間明示
　　　　　募集口数　；仮　　　　１，０００口
　　　　　保　　証　；金融業務実行機関
【００２１】借り手側の債務証券４は，下記の条件とシステムの仕組みを明示して借り手側の登録を受付ける。
　　例　　１口金額　；仮　　　　１０００万円
　　　　　年　　利　；固　　定　８％
　　　　　期　　間　；期間明示
　　　　　募集口数　；仮　　　　１０００口
　　　　　条　　件　；担保不足は第三者保証
【００２２】第三者の投資による保証債券２は，融資債券１に対して債務証券４の担保不足を保証するもので，下記の条件とシステムの仕組みを明示して資金を募集する。
　　例　（担保不足５０％として試算）
　　　　　１口金額　；　仮　　　　１０００万円
　　　　　金　　利　；　システム収入の配分−変動金利
　　　　　期　　間　；　期間明示
　　　　　募集口数　；　仮　　　　１０００口，
　　　　　保　　証　；　金融業務実行機関
【００２３】本システムの金融業務実行機関は口座３を持ち，融資債券１，保証債券２，債務証券４の募集業務と，融資債券１，保証債券２の発行，債務証券４に対する融資契約業務の実行の責任基本体である。」
　
（４）引用例４
　同じく，当審で通知した拒絶理由で引用した特開２００１−２７３４００号公報（平成１３年１０月５日出願公開）（以下，「引用例４」という。）には，図面と共に，以下の事項が記載されている。
（Ｆ）【００４３】段落の記載
 「【００４３】この処理が終了した後，このシステムは，顧客の端末に，図７に示すような受付確認を受付番号７２を表示させる。ついで，顧客が，この確認画面で，「申告／申込一覧」７１を選択することで，図８に示すように，当該顧客が需要申告した銘柄の一覧が表示する。この一覧中，特定の銘柄についての需要申告内容を閲覧したい場合には，受付番号８１をクリックすることで，図９に示す詳細表示画面を表示させることができる。」
　
（５）引用例５
　同じく，当審で通知した拒絶理由で引用した特開２００２−１１７２４２号公報（平成１４年４月１９日出願公開）（以下，「引用例５」という。）には，図面と共に，以下の事項が記載されている。
（Ｇ）【０２０５】〜【０２１１】段落の記載
 「【０２０５】端末１２１でユーザがスクラッチ番号を入力して（１６０８），この情報を決済サーバ１６１に送信すると（１６０９），決済サーバ１６１では，スクラッチ番号をチェックし，当該スクラッチ番号に対応する残高をチェックする（１６１０）。
【０２０６】さらに，本当に購入するか否かを問う購入確認画面を表示するためのｈｔｔｐパケットを端末１２１に送信する（１６１１）。
【０２０７】端末１２１でユーザが購入を確認すると（１６１２），購入確認メッセージが決済サーバ１６１に送信される（１６１３）。
【０２０８】決済サーバ１６１では，残高の減算更新処理を行い（１６１４），決済が成功した旨を販売サーバ１４１に送信する（１６１５）。
【０２０９】販売サーバ１４１では，決済結果を記録して（１６１６），決済結果を受領した旨の確認通知を決済サーバ１６１に送る（１６１７）。
【０２１０】これを受信した決済サーバ１６１は，決済完了確認画面を表示するためのｈｔｔｐパケット（決済完了通知）を端末１２１に送信する（１６１８）。
【０２１１】すると端末１２１では，決済が完了した旨の画面が表示される（１６１９）。」
　
 ４．対比
（ａ）引用例１記載の発明の「パーソナルコンピュータ等のコンピュータであるユーザ端末」，「有価証券情報」，「有価証券」，「ワークステーション・サーバ等のコンピュータによって構成された銀行口座管理システム」，「ネットワーク」，「注文者ＩＤ」，「決算処理に使用可能な銀行口座」，「証券コード」，「注文者」，「売買注文」，「有価証券販売管理システムの銀行口座」，「注文者が指定した銀行口座」は，それぞれ，請求項１に係る発明の「ユーザが所有する端末」，「証券情報」，「証券」，「金融機関用サーバ」，「通信網」，「ユーザＩＤ」，「口座番号」，「証券識別ＩＤ」，「ユーザ」，「購入申込」，「証券会社の口座」，「ユーザの口座番号の口座」に相当する。
（ｂ）引用例１に係る発明の「種々の有価証券情報（証券コードや銘柄を含む）を送信するワークステーション・サーバ等のコンピュータによって構成される有価証券販売管理システム」は，請求項１に係る発明の「証券情報を配信するサーバ」に相当すると認められる。
（ｃ）引用例１に記載された登録されたユーザ情報に対する処理から見て，引用例１記載の発明の「記憶装置」はユーザ情報を格納したデータベース装置と認められるから，引用例１記載の発明の「有価証券販売管理システム」が備える「記憶装置」と，請求項１に係る発明の「サーバ」が備える「データベース装置」は，格納される情報が一部相違するものの，「ユーザＩＤ，口座番号が相互に関連付けられたユーザに関する情報を格納して」なるデータベース装置である点で共通すると認められる。
（ｄ）引用例１記載の発明の「注文者ＩＤ，決済処理に使用可能な銀行口座が相互に関連付けられたユーザ情報」と，請求項１に係る発明の「ユーザＩＤ，ユーザ名，ユーザ属性，口座番号，ユーザの端末操作に関する履歴情報が相互に関連付けられたユーザに関する情報」は，情報の内容が一部相違するものの，いずれもユーザに関連する情報である点で共通すると認められる。
（ｅ）引用例１記載の発明の「前記注文者ＩＤを受信する受信手段」と，請求項１に係る発明の「前記ユーザＩＤと共に前記証券情報テーブルに格納されている全証券の証券識別ＩＤを要求する全証券情報送信要求と，前記ユーザＩＤと共に証券識別ＩＤを含む特定証券に関する情報を要求する特定証券情報送信要求とを受信する要求受信手段」は，証券の情報を端末に表示するために必要となる所定の情報の内容が相違するものの，当該表示を要求する所定の情報を受信している点で共通すると認められる。
（ｆ）引用例１記載の発明の「前記端末からの注文者ＩＤに応じて，証券コードを含む有価証券情報を前記端末に送信する有価証券情報送信手段」と，請求項１に係る発明の「前記端末からの全証券情報送信要求に応じて，前記証券情報テーブルに格納されている全ての証券識別ＩＤを含む全証券表示情報を前記ユーザＩＤで識別されたユーザ名と共に前記端末に送信する全証券情報送信手段」と「前記公共事業等の名，証券の券面額，集めた資金を投下する公共事業等の内容，該公共事業等の企画者・遂行者の名，保証人の名，償還期限，利率，保証限度，配当，関係者のコメント等に関する情報を含む特定証券に関する情報である特定証券表示情報を前記端末に送信する特定証券情報送信手段」は，送信する証券の情報の内容が相違するものの，「端末へ証券の情報を送信する証券情報送信手段」である点で共通すると認められる。
（ｇ）引用例１記載の発明の「前記端末からの売買注文情報を申込に係る証券コードと共に受信する申込受信手段」と，請求項１に係る発明の「前記端末からの特定証券情報の購入申込を申込に係る証券識別ＩＤと共に受信する申込受信手段」とは，申込する証券の情報の内容が相違するものの，「端末から証券の購入申込に関する情報を受信する申込受信手段」である点で共通すると認められる。
（ｈ）引用例１記載の発明の「前記注文者ＩＤに基づいて前記ユーザ情報の決済処理に使用可能な銀行口座を検出する口座検出手段」と，請求項１に係る発明の「前記ユーザＩＤに基づいて前記ユーザデータテーブルの口座番号を検出する口座検出手段」とは，ユーザに関する情報の形式が相違するものの，「ユーザＩＤに基づいて，ユーザに関する情報の口座番号を検出する口座検出手段」である点で共通すると認められる。
（ｉ）引用例１記載の発明の「銀行口座管理システム」が備える「記憶部」と，請求項１に係る発明の「金融機関用サーバ」が備える「預金データベース」は，以下の相違点があるものの，いずれも「記憶部」である点で共通すると認められる。
（ｊ）そして，引用例１記載の発明の「有価証券売買システム」と，請求項１に係る発明の「証券情報配信システム」は，以下の相違点で相違するものの，「販売証券情報配信システム」で共通すると認められる。
　
　そうしてみると，請求項１に係る発明と引用例１記載の発明は，
「ユーザが所有する端末と証券情報を配信するサーバと金融機関に配置された金融機関用サーバとが通信網を介して相互に接続された証券情報配信システムにおいて，
　前記サーバは，予め定められた動作を行なう処理部と入力部と出力部とデータベース装置とを備え，
　上記データベース装置は，ユーザＩＤ，口座番号が相互に関連付けられたユーザに関する情報を格納してなり，
　上記処理部は，ユーザＩＤを受信する要求受信手段と，
　前記端末からのユーザＩＤに応じて，証券識別ＩＤを含む証券情報を前記端末に送信する証券情報送信手段と，
　前記端末からの証券購入情報を申込に係る証券識別ＩＤと共に受信する申込受信手段と，
　前記ユーザＩＤに基づいて前記ユーザに関する情報の口座番号を検出する口座検出手段と，
　前記口座検出手段で検出した口座番号から前記購入した証券の購入金額を証券会社の口座に振り込む旨の指示を前記金融機関用サーバに送信する指示送信手段とを備え，
　前記端末は，予め定められた動作を行なう処理部と入力部と表示部とを備え，
　前記入力部は，ユーザの操作に応じて購入する証券を選択し，
　前記表示部は，受信した前記証券情報を画面に表示し，
　前記処理部は，前記ユーザＩＤを前記サーバに送信する送信部と，
　前記証券情報を前記サーバから受信する受信部と，
  前記入力部で選択された証券の購入申込を前記サーバの申込受信手段に送信する申込送信部と，
　前記表示部に，前記購入申込に係る証券を購入した旨を表示する手段とを備え，
　前記金融機関用サーバは，予め定められた動作を行なう処理部と記憶部を備え，
　前記処理部は，前記サーバの指示送信部から送信された指示を受信すると，前記購入した証券の購入金額をユーザの口座番号の口座から証券会社の口座に振り込む旨の指示に基づいて預金データベースを更新する更新部を備える
　ことを特徴とする販売証券情報配信システム」
 である点で一致し，以下の点で相違するものと認められる。
　
（相違点１）
　請求項１に係る発明では，「データベース装置」が，「証券識別ＩＤ，公共事業等の名，証券の券面額，集めた資金を投下する公共事業等の内容，該公共事業等の企画者・遂行者の名，保証人の名，償還期限，利率，保証限度，配当，関係者のコメント等が対応付けられた各証券の証券情報が一又は複数記載された証券情報テーブルを複数有すると共に，ユーザＩＤ，ユーザ名，ユーザ属性，口座番号，ユーザの端末操作に関する履歴情報が相互に関連付けられたユーザに関する情報が記載されたユーザデータテーブル」を格納し，「サーバ」の「口座検出手段」が，ユーザにＩＤ基づいて「ユーザデータテーブル」の口座番号を検出しているのに対して，引用例１記載の発明では，「ユーザＩＤ，口座番号が相互に関連付けられたユーザに関する情報」を格納しているものの，「データベース装置」に格納する「証券情報」と「ユーザに関する情報」の内容が相違し，「データベース装置」に「証券情報」を格納しているかどうか明確ではなく，また，各情報が記載されたテーブルの形式で格納されているかどうか明確でなく，「有価証券販売管理システム」の「口座検出手段」が，注文者ＩＤに基づいて「ユーザ情報」の決済処理に使用可能な銀行口座を検出している点。
　
（相違点２）
　請求項１に係る発明では，「サーバ」が「全証券情報送信要求」と「特定証券情報送信要求」に応じて「全証券情報」と「特定証券情報」を端末に送信するのに対して，引用例１記載の発明は，「有価証券販売管理システム」が「注文者ＩＤ」に応じて「有価証券情報」を送信する点で相違している。
　そして，この相違により，請求項１に係る発明では，「サーバ」の「処理部」の「要求受信手段」は，「前記証券情報テーブルに格納されている全証券の証券識別ＩＤを要求する全証券情報送信要求と，前記ユーザＩＤと共に証券識別ＩＤを含む特定証券に関する情報を要求する特定証券情報送信要求」とを受信し，当該「処理部」の「証券情報送信手段」は，「前記端末からの全証券情報送信要求に応じて，前記証券情報テーブルに格納されている全ての証券識別ＩＤを含む全証券表示情報を前記ユーザＩＤで識別されたユーザ名と共に前記端末に送信する全証券情報送信手段と，前記端末からの特定証券情報送信要求に応じて，受信した前記証券識別ＩＤによって前記データベース装置を検索して前記特定証券に関する情報を抽出する検索抽出手段と，前記検索抽出手段で抽出した，前記公共事業等の名，証券の券面額，集めた資金を投下する公共事業等の内容，該公共事業等の企画者・遂行者の名，保証人の名，償還期限，利率，保証限度，配当，関係者のコメント等に関する情報を含む特定証券に関する情報である特定証券表示情報を前記端末に送信する特定証券情報送信手段」とで構成され，「端末」の「処理部」は，「前記ユーザＩＤと共に前記全証券情報送信要求を送信すると共に，前記入力部で選択された証券識別ＩＤと共に特定証券情報送信要求を前記サーバに送信する送信部」を備えているのに対して，引用例１記載の発明では，「有価証券販売管理システム」の「処理部」は，「注文者ＩＤを受信する受信手段」と，「前記端末からの注文者ＩＤに応じて，証券コードを含む有価証券情報を前記端末に送信する有価証券情報送信手段」とを備え，「ユーザ端末」の「処理部」は，「注文者ＩＤを前記有価証券販売管理システムに送信する送信部」と「前記有価証券情報を前記有価証券販売管理システムから受信する受信部」を備えている点。
　
（相違点３）
　請求項１に係る発明では，「全証券情報」から選択された「特定証券」に関する情報を要求して端末に表示するのに対して，引用例１記載の発明は，「特定証券」に関する情報の処理を行わない点で相違している。
　そして，この相違により，請求項１に係る発明では，「サーバ」の「処理部」の「要求受信手段」が，「前記ユーザＩＤと共に前記証券情報テーブルに格納されている全証券の証券識別ＩＤを要求する全証券情報送信要求と，前記ユーザＩＤと共に証券識別ＩＤを含む特定証券に関する情報を要求する特定証券情報送信要求」とを受信し，当該「処理部」の「証券情報送信手段」が，「前記端末からの全証券情報送信要求に応じて，前記証券情報テーブルに格納されている全ての証券識別ＩＤを含む全証券表示情報を前記ユーザＩＤで識別されたユーザ名と共に前記端末に送信する全証券情報送信手段」と，「前記端末からの特定証券情報送信要求に応じて，受信した前記証券識別ＩＤによって前記データベース装置を検索して前記特定証券に関する情報を抽出する検索抽出手段」と，「前記検索抽出手段で抽出した，前記公共事業等の名，証券の券面額，集めた資金を投下する公共事業等の内容，該公共事業等の企画者・遂行者の名，保証人の名，償還期限，利率，保証限度，配当，関係者のコメント等に関する情報を含む特定証券に関する情報である特定証券表示情報を前記端末に送信する特定証券情報送信手段」とで構成されていると共に，当該「処理部」の「申込受信手段」は，「特定証券情報」の購入申込を受信し，当該「処理部」の「指示送信手段」は，「特定証券」の購入金額を振り込む旨の指示を行い，「端末」の「入力部」は，ユーザの操作に応じて「前記全証券表示情報の中から選択された特定証券」を選択し，当該「端末」の「表示部」は，受信した「前記全証券表示情報と前記特定証券表示情報」とを画面に表示し，当該「端末」の「処理部」の「送信部」は，「前記ユーザＩＤと共に前記全証券情報送信要求」と，「前記入力部で選択された証券識別ＩＤと共に特定証券情報送信要求」を前記サーバに送信し，当該「処理部」の「受信部」は，「前記全証券表示情報と前記特定証券表示情報」とを前記サーバから受信し，当該「処理部」の「申込送信部」は，「特定証券」の購入申込を送信すると共に，「金融機関用サーバ」の「処理部」は，「特定証券」の購入金額を振り込む旨の指示を行っているのに対して，引用例１記載の発明では，「有価証券販売管理システム」の「受信手段」が，「前記注文者ＩＤを受信する」し，当該「処理部」の「証券情報送信手段」が，「証券コードを含む有価証券情報を前記端末に送信」し，当該「処理部」の「申込受信手段」は，「売買注文情報」の購入申込を受信し，当該「処理部」の「指示送信手段」は，「購入した有価証券」の購入金額を振り込む旨の指示を行い，「ユーザ端末」の「入力部」は，ユーザの操作に応じて「購入する有価証券」を選択し，当該「ユーザ端末」の「表示部」は，受信した「有価証券情報」を画面に表示し，当該「ユーザ端末」の「処理部」の「送信部」は，「前記注文者ＩＤ」を前記サーバに送信し，当該「処理部」の「受信部」は，「有価証券情報」を前記サーバから受信し，当該「処理部」の「申込送信部」は，「有価証券」の購入申込を送信すると共に，「銀行口座管理システム」の「処理部」は，「有価証券」の購入金額を振り込む旨の指示を行っている点。
　
（相違点４）
　請求項１に係る発明では，「サーバ」の「処理部」が，「前記申込受信手段で受信した証券識別ＩＤの購入申込の確認情報を前記端末に送信する確認情報送信手段と，前記端末からの確認情報に対する証券購入の確定情報を受信する確定情報受信手段と，前記確定情報受信手段で確定情報を受信したとき，前記端末に対して承諾情報を送信する承諾情報送信手段」を備えており，「端末」の「処理部」が，「前記サーバの確認情報送信手段から送信された確認情報を受信する確認情報受信部と，　前記確認情報受信部で受信した確認情報に対し前記入力部の操作に応じて確定情報を送信する確定情報送信部と，前記サーバの承諾情報送信手段から送信された承諾情報を受信する承諾情報受信部と，前記承諾情報受信部が前記承諾情報を受信すると，前記表示部に，前記購入申込に係る証券を購入した旨を表示し，前記サーバと前記端末との間における一連の処理を終了することを前記入力部で選択すると，前記サーバの端末との間における一連の処理を終了させる終了情報を前記サーバに送信する終了情報送信手段」とを備えているのに対し，引用例１記載の発明では，「有価証券販売管理システム」の「処理部」が，そのような手段を備えていない点。
　
（相違点５）
　請求項１に係る発明では，「端末」が，「前記承諾情報受信部が前記承諾情報を受信して，前記表示部に，前記購入申込に係る証券を購入した旨を表示したときに，前記サーバと前記端末との間における一連の処理を終了させないことを前記入力部で選択すると，前記送信部から前記ユーザＩＤと共に前記全証券情報送信要求を送信」するのに対し，引用例１記載の発明では，「ユーザ端末」が，そのような処理をしていない点。
　                   
（相違点６）
　請求項１に係る発明では，「サーバ」の「口座検出手段」が，「前記端末との間における一連の処理を終了した」後に検出を行うのに対し，引用例１記載の発明では，「有価証券販売管理システム」の「口座検出手段」が，そのようなタイミングで検出していない点。
　
（相違点７）
　請求項１に係る発明では，「金融機関用サーバ」が，「預金データベース」とを備えているのに対し，引用例１記載の発明では，「銀行口座管理システム」が「記憶部」を備えているものの，該「記憶部」が，預金データベースであるかが明確ではない点。
　
５．請求人の主張
　請求人は，平成２１年３月２３日付けの意見書において以下の通り主張している。
［相違点１に関して］
「審判官は，拒絶理由通知書の中で，（相違点１）として，（略）
　しかしながら，そもそも，審判官は，本願発明が対象とする証券を導き出すために，互いに独立した引用例２の発明と引用例３の発明とを組み合わせ，この引用例２，３を組み合わせた発明を，引用例１に組み合わせているものである。これは，本願発明を実現するに当たって，先ず引用例２の発明と引用例３の発明を組み合わせる創作活動と，更に引用例２，３を組み合わせて創作した発明を引用例１に組み合わせる創作活動を必要とするものであって，引用例２の発明と引用例３の発明を組み合わせた発明を引用例１の発明に組み合わせる動機付けも見出すことはできず，もはや，本願発明を，当業者が引用例１−３に基づいて容易に発明できるものではない。
　そして，引用例１−３を組み合わせても，上述したような本願発明の証券の券情報配信システムのような，民間資金活用のために発行される証券についての，証券購入に提供された資金が如何なる公共事業等に投下されるのか，その事業の企画者・遂行者が誰か，元本の償還は誰によってどの程度保証されるのか，券面額はいくらか等の証券を購入するために必要な情報を端末を使用して容易に得ることができ，また，所望の証券の購入も容易に行なうことができる，という作用効果を実現することはできない。（略）
　上述したように，本願発明では，取引の対象となる証券が新規な証券であり，更に，この証券を用いて，後の公共事業等において資金を円滑に調達できるようにする必要があるため，履歴情報として蓄積されたユーザの操作に関する情報を，企画者・遂行者が「保証人，償還期限，利率，保証限度，配当」等を決定するに当たっての参考情報にできるようにするものである。
　このような本願発明の特有の証券及び履歴情報に関する考え方は，何れの引用例，更には拒絶理由通知で指摘された特開２００２−１３２８２５号公報，特開２００２−１３２８００号公報，特開２００１−３３１３３７号公報にも示唆されていない。
　すなわち，本願発明での履歴情報の考え方は，本願発明の取引の対象とする証券が，公共事業等の企画者・遂行者が資金を容易に調達できるようにするためのもので新規な内容の証券であり，このため，「保証人，償還期限，利率，保証限度，配当」を決定するためユーザの操作に関する履歴情報を企画者・遂行者が参考情報として用いることができるように蓄積していくものである。このような本願発明の履歴情報は，現在一般的な債権や株式とはその仕組みを異にする本願発明が対象とする新規な証券であるからこそ有意義な情報となるのであって，現在一般に取引されている周知の債権や株式の取引を行う際には，特段の事情がない限り本願発明のような目的で使用される履歴情報までも必要とはならない。
　なお，特開２００２−１３２８２５号公報，特開２００２−１３２８００号公報，特開２００１−３３１３３７号公報の何れも，本願発明のように証券との関係で特定される履歴情報に関しては何ら記載されていない。
　したがって，引用例１−５，更に，特開２００２−１３２８２５号公報，特開２００２−１３２８００号公報，特開２００１−３３１３３７号公報からは，本願発明の履歴情報を導き出すことはできない。」
　
［補正前の請求項２−４に係る発明について」
「審判官は，請求項２に係る発明についての指摘において，（略）請求項３，４に係る発明についての指摘において，（略）
　しかしながら，引用例５の（０２０５）〜（０２１１）段落の記載と対比すると，当該段落は，所定の購入確認手順を決済サーバ１６１と端末１２１との間で行うことが記載されており，販売サーバ１４１と端末１２１との間のやりとりを規定したものではない。そして，引用例５とは，本願発明の承諾情報の出る順番が異なる。すなわち，本願発明では，端末が承諾情報を受信し，表示部に，購入申込に係る証券を購入した旨が表示し，終了情報をサーバに送信し，サーバと端末との間における一連の処理が終了してから，金融機関用サーバの預金データベースの更新を行うようにしているが，引用文献３では，本願発明の承諾情報に対応する決済完了通知は，決済サーバで決済が行われた後に端末に送信する。すなわち，引用例５は，決済サーバ１６１が端末１２１と購入確認を行うようにすることで，決済の後決済通知をユーザの端末１２１に送信することを実現している。
　一般に証券をユーザが購入する場合，信用買い等の取引実情があり，証券を購入した後，証券会社に代金を支払う場合がある。本願発明では，端末が承諾情報を受信し，ユーザに証券を購入したことを知らせてから（図１４（ｂ）参照），金融機関用サーバの預金データベースの更新を行うようにし，仮に，ユーザの口座が残高不足の場合であっても，証券の購入ができるようにし，後にユーザが証券会社に対して代金を支払うことを許容するようになっている。
　一方，引用例５は，金融商品でない一般的な商品のカタログ販売を想定しており，少なくとも証券取引を想定したものとはなっていない。一般的な商取引では，証券取引の場合のような信用買い等は行われておらず，従って，銀行口座での決済が完了した後でなければ，決済完了をユーザに知らせないようになっている。
　このように，本願発明のユーザが所有する端末と証券情報を配信するサーバとの所定の購入確認手順，すなわち承諾情報を受信してから金融機関用サーバの預金データベースの更新を行うようにする手順は，証券取引実情に鑑みたものであって，引用文献３からはこの考え方を導き出すことはできず，更に，周知慣用の技術手段と言い得るものではない。
　また，電子商取引を決済サーバで実現する場合には，引用例５のように，銀行口座での決済が完了した後に，決済完了をユーザに知らせるのが一般的であり，このような手順がコンピュータで決済処理を実現する際の技術的な自然の流れである。商品を売った際，面前にいない買い手より対価を確実に徴収できるようにするためである。これに対して，本願発明では，証券の分野の取引実情を考慮して，あえて，引用例５のような決済処理手順に従わず，端末が承諾情報を受信し，ユーザに証券を購入したことを知らせてから，金融機関用サーバの預金データベースの更新を行うようにしている。
　この点，引用例１には，段落００３４−００３６に買い注文が成立した場合の決済処理が記載されている。引用例１では，証券取引の場合であるにもかかわらず，取引銀行口座指定情報によって示される注文者が指定した銀行口座から有価証券販売管理システム２０の銀行口座へ振り込み処理を行い，銀行口座管理システム４０から有価証券販売管理システム２０を介して，決済結果をユーザ端末１０に送るようになっている（図２のＡ２０，２１）。すなわち，引用例５と同様，銀行口座での決済が完了した後に，決済完了をユーザに知らせるようにしている。
　以上のように，本願発明は，証券の分野の取引実情を考慮して，あえて，引用例５のような決済処理手順に従わず，端末が承諾情報を受信し，ユーザに証券を購入したことを知らせてから，金融機関用サーバの預金データベースの更新を行うようにしており，この点に創作的価値がある。すなわち，本願発明は，決済処理に関し，人間が行っている業務のシステム化であるかもしれないが，上述のように，あえて，引用例５や引用例１のような決済処理手順に従わず，端末が承諾情報を受信し，ユーザに証券を購入したことを知らせてから，金融機関用サーバの預金データベースの更新を行うようにし，一般的な電子商取引における決済手順と異なるようにしている。引用例１では，証券取引の場合であるにもかかわらず，引例５と同じような手順になっている。したがって，審判官の言うように，引用例５のような周知技術を引用例１に適用しても，本願発明の，ユーザに証券を購入したことを知らせてから，金融機関用サーバの預金データベースの更新を行う考え方は導き出すことはできず，したがって，引用例５のような周知技術を引用例１記載の発明に適用しても本願発明の構成を容易に発明することはできない。
　すなわち，引用例５や引用例１からは，本願発明の「前記承諾情報受信部が前記承諾情報を受信すると，前記表示部に，前記購入申込に係る証券を購入した旨が表示し，前記サーバと前記端末との間における一連の処理を終了することを前記入力部で選択すると，前記サーバの端末との間における一連の処理を終了させる終了情報を前記サーバに送信する終了情報送信手段とを備え，前記承諾情報受信部が前記承諾情報を受信して，前記表示部に，前記購入申込に係る証券を購入した旨を表示したときに，前記サーバと前記端末との間における一連の処理を終了させないことを前記入力部で選択すると，前記送信部から前記ユーザＩＤと共に前記全証券情報送信要求を送信し，前記端末との間における一連の処理を終了した前記サーバの口座検出手段では，前記ユーザデータテーブルの口座番号を検出し，」という構成を実現することはできない。」
　
６．当審の判断
　上記相違点について以下に検討する。
（相違点１についての検討）
　引用例１には明記されていないものの，引用例１摘記事項（Ｂ）の【００２５】段落の記載より，サーバから端末へ証券コード（「証券識別ＩＤ」に相当する。），銘柄を含む有価証券情報が送られてくるのであるから，サーバのいずれかに証券識別ＩＤと証券に関する情報が対応付けられた各証券の証券情報が格納されていることが示唆されており，ユーザ端末に送信する証券情報がサーバに備えられたデータベースに格納されていることは技術的に自明な事項である。また，各情報をデータテーブルの形式で格納することは，データベース装置の構成として周知事項である。
　また，前記引用例２の摘記事項（Ｃ）の【０００９】段落には，「ＰＦＩ事業に対して，資金対応証券（優先出資証券・特定社債権・特定約束手形）の発行により得られた金銭で，特定資産を取得し，資産の管理・処分によって得られた金銭で資産対応証券の元本や利回り配当等の支払いをする」こと（以下「引用例２記載事項Ａ」という。）が記載されている。
　資産の管理によって得られた金銭で利回り配当の支払いをするためには，ＰＦＩ事業者が，証券を所有する者に，当該事業者の事業活動の結果得た利益を分配し，かつ，利息を定期的に支払うというルールが決められており，証券は，ＰＦＩ事業者が調達した資金と引き換えに交付する民間資金調達用のものであると考えることが自然である。
　前記引用例３の摘記事項（Ｅ）の【００２０】，【００２２】段落には，融資債券に条件として保証する機関名を明示して資金を募集すること，債務不履行時に第三者の投資による保証債券で債務証券の担保不足を補うことが記載されていること（以下「引用例３記載事項Ａ」という。）が記載されている。
　融資債券により資金を募集するものであるから，当該債権は，事業者が調達した資金と引き換えに交付する民間資金調達用のものであると考えることが自然である。
　引用例１記載の発明は，有価証券売買システムであって，有価証券販売者とユーザとの間で証券の内容をユーザに示しつつ，有価証券の売買をネットワークで行うシステムであり，ユーザに提示する証券の内容や種類は，技術的に格別な変更を伴うことなく，取り扱う証券により証券の売買を企画する者が適宜し得ることであり，しかも，引用例２記載事項Ａや引用例３記載事項Ａに記載された証券が公知であることから，引用例１記載の有価証券売買システムにおいて売買に必要な証券を取り扱うために，「証券識別ＩＤ，公共事業等の名，証券の券面額，集めた資金を投下する公共事業等の内容，該公共事業等の企画者・遂行者の名，保証人の名，償還期限，利率，保証限度，配当，関係者のコメント等が対応付けられた各証券の証券情報」を，適宜取捨選択してデータベース装置に格納すること，当該証券情報を一又は複数用意することに何ら技術的困難性は見いだせない。
　さらに，有価証券の売買に際して，有用なユーザ情報を証券を販売する側のシステムが保持しておくことは，引用例１記載の発明においてもユーザＩＤ，口座番号を記憶しているように，当業者にとって通常行われていることであり，技術的に格別な変更を伴うものではない。また，インターネットを利用した商取引システムにおいて，操作履歴，購入履歴を蓄積することは，特開２００２−１３２８２５号公報の【００２１】段落の「ユーザデータ蓄積部７には，インターネットショッピングを利用したユーザ（顧客）の個人情報，操作履歴，購入履歴等に関する情報が予め記憶蓄積されている。」という記載（以下，「周知例１記載事項Ａ」という。）や，特開２００２−１３２８００号公報の【０００１】〜【０００２】段落の「コンテンツプロバイダとコンテンツ利用者を仲介する情報仲介者を設け，情報仲介者において利用者の段階的操作履歴と利用者属性情報をもとに利用者動向を分析する利用者動向分析システム・・略・・インターネットを用いた電子商取引いわゆるＥ−Ｃｏｍｍｅｒｃｅにおいては，顧客属性情報及び購買履歴情報から，どのような属性を持つ顧客がどのような商品に興味を示すかを分析し，効果的なダイレクトマーケティングを実現することが可能となっている。・・略・・」という記載（以下，「周知例２記載事項Ａ」という。）や，特開２００１−３３１３３７号公報の【０００６】段落の「コンテンツの操作履歴を保持し，・・略・・前記操作履歴を前記サーバに送信し，前記サーバは，前記操作履歴に基づいて前記更新されたコンテンツをカスタマイズする」という記載（以下，「周知例３記載事項Ａ」という。）にあるように，本願出願前に周知の事項であり，ユーザ名やユーザ属性を蓄積することも周知の事項である。引用例１記載の発明において，ユーザーに関するどのような情報を保持しておくかは，システムが取り扱う証券の内容や，対象とする顧客，販売者側の営業戦略等により，証券の売買を企画する者が，既に知られている情報から適宜選択し得ることであって，引用例１記載の有価証券売買システムにおける有価証券販売管理システムに格納するユーザに関する情報として，ユーザＩＤ，口座番号に加えて，本願出願前に周知であるユーザ名，ユーザ属性，ユーザの端末操作に関する履歴情報を格納することに何ら技術的困難性は見いだせない。
　よって，引用例１記載の発明において，データベース装置に「証券識別ＩＤ，公共事業等の名，証券の券面額，集めた資金を投下する公共事業等の内容，該公共事業等の企画者・遂行者の名，保証人の名，償還期限，利率，保証限度，配当，関係者のコメント等が対応付けられた各証券の証券情報が一又は複数記載された証券情報テーブルを複数」格納すると共に，ユーザに関する情報に「ユーザＩＤ，ユーザ名，ユーザ属性，口座番号，ユーザの端末操作に関する履歴情報が相互に関連付けられたユーザデータテーブル」を格納すること，口座検出手段が，「ユーザデータテーブル」に基づいて口座番号を検出するよう構成することは，当業者にとって容易である。
　なお，請求人の引用例１−３の組み合わせの動機付けに関する主張を検討したが，履歴情報を蓄積することについては，上述した周知の顧客分析を単に証券に適用したに過ぎず，何ら技術的に格別な変更を伴うものではなく，その他の主張についても，上述したとおりであるので，引用例１記載の発明は，有価証券売買システムであって，有価証券販売管理システムがユーザに提示する証券の内容や当該ユーザに関する情報は，証券の売買を企画する者が適宜取捨選択すべきことにすぎず，当業者が容易に組み合わせ得るものである。よって，当該主張を採用することはできない。
　したがって，上記相違点１に係る請求項１に係る発明の構成は，引用例１記載の発明及び引用例２，３に記載された事項，周知事項に基づいて，当業者が容易に想到し得たものと認められる。
　
（相違点２，３についての検討）
　相違点２及び３は，相互に関係しているので，まとめて検討する。
　まず，引用例１記載の発明において，注文者がユーザ端末を介して，サーバにアクセスするのは，有価証券情報の売買注文を行うに際して，種々の有価証券情報（証券コードや銘柄を含む）を取得するために行っているものであり，注文者が注文者ＩＤとパスワードをサーバへ送信するのは，当該アクセスのためのログイン手続として行っている。つまり，有価証券情報を受信するために注文者ＩＤ等を送信してログイン手続を行っているのであり，ユーザ端末から注文者ＩＤ等をサーバに送信し，サーバが当該注文者ＩＤ等の照合処理を行い，照合結果が一致した場合に，有価証券情報を当該ユーザ端末に送信するといった一連の処理において，ログイン手続として注文者ＩＤ等をサーバに送信することは，同時に送信可能な全ての有価証券情報の送信要求をユーザ端末からサーバに送信していることが示唆されている。引用例１記載の発明は，一度の処理で必要な有価証券情報を表示させ，購入する有価証券を選択する形態を採用しているが，前記引用例４の摘記事項（Ｆ）の【００４３】段落，図８−９に，システムが，顧客の端末に，当該顧客が需要申告した銘柄の一覧を表示し，この一覧中，特定の銘柄についての需要申告内容を閲覧したい場合には，受付番号をクリックすることで，詳細表示画面を表示させること（以下「引用例４記載事項Ａ」という。）が記載されているように，コンピュータ端末上で商品や銘柄等を選択する際に，まずは，一覧表示させるための指示を送受信することにより，端末画面上に一覧表示させ，次いで端末画面上に表示された商品や銘柄等一覧のなかから所望のものの詳細情報を表示させるよう指示を送受信する形態も周知な技術手段であり，このような周知技術を引用例１記載の発明に適用することに格別の困難性は認められないので，いずれの形態を採用するかは当業者が商取引の利便性により適宜選択し得る設計的な事項である。
　そうしてみると，引用例１記載の発明において，サーバが「全証券情報送信要求」と「特定証券情報送信要求」に応じて，それぞれ「全証券情報」と「特定証券情報」を端末に送信することと，「全証券情報」から選択された「特定証券」に関する情報を要求して端末に表示するよう構成すること，さらに，証券の購入申込の処理を「特定証券」に対して行うことは，当業者にとって容易に考えられる事項である。
　すなわち，引用例１記載の発明において，サーバの「処理部」の「要求受信手段」を，「前記証券情報テーブルに格納されている全証券の証券識別ＩＤを要求する全証券情報送信要求と，前記ユーザＩＤと共に証券識別ＩＤを含む特定証券に関する情報を要求する特定証券情報送信要求」とを受信するようにし，当該「処理部」の「証券情報送信手段」を，「前記端末からの全証券情報送信要求に応じて，前記証券情報テーブルに格納されている全ての証券識別ＩＤを含む全証券表示情報を前記ユーザＩＤで識別されたユーザ名と共に前記端末に送信する全証券情報送信手段」と，「前記端末からの特定証券情報送信要求に応じて，受信した前記証券識別ＩＤによって前記データベース装置を検索して前記特定証券に関する情報を抽出する検索抽出手段」と，「前記検索抽出手段で抽出した，前記公共事業等の名，証券の券面額，集めた資金を投下する公共事業等の内容，該公共事業等の企画者・遂行者の名，保証人の名，償還期限，利率，保証限度，配当，関係者のコメント等に関する情報を含む特定証券に関する情報である特定証券表示情報を前記端末に送信する特定証券情報送信手段」とで構成し，当該「処理部」の「申込受信手段」を「特定証券情報」の購入申込を受信し，当該「処理部」の「指示送信手段」を，「特定証券」の購入金額を振り込む旨の指示を行うよう構成すると共に，
　端末の「入力部」を，ユーザの操作に応じて「前記全証券表示情報の中から選択された特定証券」を選択させ，「表示部」を，受信した「前記全証券表示情報と前記特定証券表示情報」とを画面に表示させることと，端末の「処理部」に，「前記ユーザＩＤと共に前記全証券情報送信要求を送信すると共に，前記入力部で選択された証券識別ＩＤと共に特定証券情報送信要求を前記サーバに送信する送信部」を備えさせ，当該「処理部」の「送信部」を，「前記ユーザＩＤと共に前記全証券情報送信要求」と，「前記入力部で選択された証券識別ＩＤと共に特定証券情報送信要求」を前記サーバに送信させ，当該「処理部」の「受信部」を，「前記全証券表示情報と前記特定証券表示情報」を前記サーバから受信させ，当該「処理部」の「申込送信部」は，「特定証券」の購入申込を送信させるよう構成すると共に，
　金融機関用サーバの「処理部」を，「特定証券」の購入金額を振り込む旨の指示を行うよう構成することは，いずれも周知技術の付加に伴う単なる設計変更に過ぎず，当業者が容易に想到できたことである。
　したがって，上記相違点２及び３に係る請求項１に係る発明の構成は，引用例１記載の発明及び引用例４等に記載される周知技術に基づいて，当業者が容易に想到し得たものと認められる。
　
（相違点４についての検討）
　インターネットを利用した商取引システムにおいて，購入側からの購入申込に対して，購入側と販売側との間で，購入の確認のための情報，購入の確定のための情報，取引終了の情報を送受信することは，例えば，確認のための情報では，引用文献５の【０２０６】〜【０２０７】段落に「本当に購入するか否かを問う購入確認画面を表示するためのｈｔｔｐパケットを端末１２１に送信する・・略・・端末１２１でユーザが購入を確認すると（１６１２），購入確認メッセージが決済サーバ１６１に送信される」こと（以下「引用例５記載事項Ａ」という。）と記載されていること等から，インターネットを利用した商取引において広く実施され，当業者に周知のことであり，購入の確認や確定の手続きをどのように構築するかは，販売する商品や役務の特性により，販売を企画する者が適宜決定し得ることである。
　そうしてみると，引用例１記載の発明において，サーバの「処理部」を，「前記申込受信手段で受信した証券識別ＩＤの購入申込の確認情報を前記端末に送信する確認情報送信手段と，前記端末からの確認情報に対する証券購入の確定情報を受信する確定情報受信手段と，前記確定情報受信手段で確定情報を受信したとき，前記端末に対して承諾情報を送信する承諾情報送信手段」を備えさせ，端末の「処理部」を，「前記サーバの確認情報送信手段から送信された確認情報を受信する確認情報受信部と，前記確認情報受信部で受信した確認情報に対し前記入力部の操作に応じて確定情報を送信する確定情報送信部と，前記サーバの承諾情報送信手段から送信された承諾情報を受信する承諾情報受信部と，前記承諾情報受信部が前記承諾情報を受信すると，前記表示部に，前記購入申込に係る証券を購入した旨を表示し，前記サーバと前記端末との間における一連の処理を終了することを前記入力部で選択すると，前記サーバの端末との間における一連の処理を終了させる終了情報を前記サーバに送信する終了情報送信手段」を備えさせることは，周知技術の付加に伴う単なる設計変更に過ぎず，当業者が容易に想到できたことである。
　したがって，上記相違点４に係る請求項１に係る発明の構成は，引用例１記載の発明及び引用例５等に記載される周知事項に基づいて，当業者が容易に想到し得たものと認められる。
　
（相違点５についての検討）
　インターネットを利用した商取引システムにおいて，商取引後に，取引を終了させるか，引き続き取引するために最初の手続きに戻るかを操作者が選択させることは，例えば，特開平２００１−３３１７３３号公報の【００２１】段落および第１〜２図に「購入者は，・・略・・ショッピングを続けるか，終了するかを選択し，「ショッピングを続ける」ボタンをクリックした場合は，Ｓ１１（第２図「カタログシティーのサイト上で，購入する商品を選択する」に戻り，購入を終了する場合は，「精算」ボタンをクリックする」こと（以下，「周知例４記載事項Ａ」という。）が記載されているように，インターネットを利用した商取引において広く実施され，当業者に周知のことであるので，引用例１記載の発明に当該周知事項を付加し，端末を，「前記承諾情報受信部が前記承諾情報を受信して，前記表示部に，前記購入申込に係る証券を購入した旨を表示したときに，前記サーバと前記端末との間における一連の処理を終了させないことを前記入力部で選択すると，前記送信部から前記ユーザＩＤと共に前記全証券情報送信要求を送信」するよう構成することは，当業者が容易に想到できたことである。
　したがって，上記相違点５に係る請求項１に係る発明の構成は，引用例１記載の発明及び周知事項に基づいて，当業者が容易に想到し得たものと認められる。
　
（相違点６についての検討）
　商品等を販売する際，商品等の受渡しよりも決済を後に行う掛け売り取引や，証券の販売において信用取引が幅広く知られており，当該掛け売りや信用取引のような人間が従来行っていた商行為をコンピュータシステムにより自動的に処理することは当業者の通常の創作能力の範囲内のことであって，さらに，引用例１記載の発明の「口座検出手段」は，上述したとおり，既にコンピュータシステム上で自動的に処理されているのであるから，当該処理を従来行われていた商慣行に合わせることに，格別な技術力を要するとは認められない。すなわち，引用例１記載の発明の口座検出手段を，「前記端末との間における一連の処理を終了した」後に検出を行うよう構成することは当業者にとって容易である。
　なお，請求人の承諾情報の出る順番に関する主張を検討したが，上述したとおり，引用例１記載の発明の「口座検出手段」の処理を従来行われていた商慣行に合わせることに技術的に格別な点は見いだせず，人間が行っている業務のシステム化にすぎないので，当業者が容易に設計変更し得るものである。さらに，電子商取引を決済サーバで実現する場合についての主張も検討したが，従来行われていた掛け売りや信用取引においても，対価を徴収できる見込みにより，取引を行うか否かのリスク管理は行われており，電子商取引を決済サーバで実現する場合に特有の管理は何ら見いだせないので，従来の商慣行をシステム化したにすぎない。よって，当該主張を採用することはできない。
　したがって，上記相違点６に係る請求項１に係る発明の構成は，引用例１記載の発明及び周知事項に基づいて，当業者が容易に想到し得たものと認められる。
　
（相違点７についての検討）
　引用例１記載の発明の銀行口座管理システムは，上記３．（１）（ｇ）で述べたとおり，抽出した金額を振り込ませるための約定代金決済情報を有価証券販売管理システム受信すると，チェック後に指定口座と有価証券販売管理システムの口座間で振り替えを行い約定代金を決済する処理を行っているのであるから，銀行口座管理システムの処理部において，約定代金決済情報により注文者の口座から指定金額を有価証券販売管理システムの口座に振り替える処理を，口座の情報を記憶する記憶部を更新する更新機能により行っていると認められる。また，金融機関が口座を預金情報を含むデータベースで管理することは，当業者にとって周知事項である。引用例１記載の発明の金融機関用サーバは，金融機関が関与するサーバであるので，当該金融機関用サーバに「預金データベース」を備えさせ，当該金融機関用サーバの「処理部」の処理を当該「預金データベース」に対して行うことは当業者が容易に想到し得ることである。
　したがって，上記相違点７に係る請求項１に係る発明の構成は，引用例１記載の発明及び周知事項に基づいて，当業者が容易に想到し得たものと認められる。
　
　以上判断したとおり，本願発明における上記相違点１−７に係る構成は当業者が容易に想到し得たものであり，また，各相違点を総合しても本願発明は当業者が想到することが困難なものとはいえない。
　そして，本願発明の作用効果も，引用例１に記載された発明及び引用例２−５に記載された技術，並びに周知の事項から当業者が予測できる範囲のものである。
　したがって，本願発明は，引用例１に記載された発明及び引用例２−５に記載された技術，並びに周知の事項に基づいて，当業者が容易に発明をすることができたものである。
　
７．むすび
　以上のとおり，本願発明は，引用例１に記載された発明及び引用例２−５に記載された技術，並びに周知の事項に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。