【事件の表示】
　特願２００５−１６５３２２「コンピュータ間通信ネットワークを用いてバイヤの取引及び決済を管理する方法，並びにバイヤの消費動向に沿った情報をバイヤに通知する方法」拒絶査定不服審判事件〔平成１７年１１月１０日出願公開，特開２００５−３１７０３９〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯
　本願は，２００１年４月２５日（優先権主張２０００年４月２６日，２０００年７月６日，日本国）を国際出願日とする特願２００１−５７９１７４号の一部を，平成１４年１１月２５日に新たな特許出願とした特願２００２−３４０６８５号の一部を，さらに平成１７年６月６日に新たな特許出願としたものであって，出願後の手続の経緯の概要は，次のとおりである。
　
　平成１７年６月８日付け　　手続補正
　同年８月１６日付け　　　　拒絶理由通知
　同年１０月１４日付け　　　手続補正（以下「第２回補正」という。）
　同年１１月１１日付け　　　拒絶理由通知
　平成１８年１月１２日付け　手続補正（以下「第３回補正」という。）
　同年３月２９日付け　　　　第３回補正について補正却下の決定
　同日付け　　　　　　　　　拒絶査定
　同年５月８日　　　　　　　拒絶査定に対する審判請求
　同年６月５日付け　　　　　手続補正（以下「本件補正」という。）
　
第２　平成１８年６月５日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１８年６月５日付けの手続補正を却下する。
　
［理由］
１　本件補正の基準明細書等
　請求人は，原審における補正却下の決定に対して不服である旨の主張をしていないので，本件補正の適否を判断する基準となる明細書，特許請求の範囲及び図面は，拒絶査定時の明細書，特許請求の範囲及び図面，すなわち，第２回補正により補正された明細書，特許請求の範囲及び図面である。
　
２　本件補正の内容
　本件補正により，特許請求の範囲の請求項１は，
「請求書を発行するサプライヤが用いるサプライヤシステムと，
　請求書を受けるバイヤが用いるバイヤシステムと，
　サプライヤ及びバイヤの銀行口座を管理し，前記バイヤの銀行口座から前記サプライヤの銀行口座への入出金処理を行う銀行システムと，
　前記サプライヤシステム，前記バイヤシステム及び前記銀行システムと通信ネットワークを介して通信可能に接続されたサーバと
を用いて取引及び決済を管理する方法において，
　前記サーバが，どの請求書であるかを特定するための固有の識別コードが前記サプライヤシステムによって記述された電子請求書を，前記サプライヤシステムから受信するステップと，
　前記サーバが，前記受信した電子請求書及びその状態をデータベースに登録するステップと，
　前記サーバが，前記登録されている電子請求書の状態を前記サプライヤシステム及び前記バイヤシステムの少なくとも一方に通知するステップと，
　前記サーバが，前記データベースに登録された前記電子請求書の内容を示したＧＵＩ画面を，前記バイヤシステムに送信して表示させるステップと，
　前記サーバが，前記バイヤの承認の入力を受けた場合に，前記登録された電子請求書に基づいて，前記登録された電子請求書の支払いのための取立て依頼電文を自動的に作成して前記銀行システムに送信するステップと，
　前記銀行システムが，前記取立て依頼電文を受けて，前記銀行システムの取立システムを用いて，前記バイヤの銀行口座から前記サプライヤの銀行口座に前記電子請求書に記述されている請求金額を移動する取立て処理を行い，取立てが完了すると，リアルタイム又は所定のタイミングで，取立ての完了通知を前記サーバに送信するステップと，
　前記サーバが，前記取立ての完了通知を受信すると，前記取立ての完了通知から，前記取立て依頼電文の基になった前記電子請求書の固有の識別コードを有する電子請求書を前記データベースから特定し，前記特定された，前記データベースに登録されている前記電子請求書の状態を支払い済みに更新し，その電子請求書についての支払い済みを，前記サプライヤシステム及び前記バイヤシステムの少なくとも一方に送信するステップと
を有する方法。」
と補正された。
　
　上記補正によって，本件補正前の「前記バイヤの承認により」が「前記バイヤの承認の入力を受けた場合に」と補正されているところ，この補正は，特許法第１７条の２第４項第４号の明りょうでない記載の釈明を目的とするものである。
　また，上記補正は，本件補正前の請求項１に記載した発明を特定するために必要な事項である「取立ての完了通知を・・・送信するステップ」について「前記銀行システムの取立システムを用いて」及び「リアルタイム又は所定のタイミングで」との限定を付加し，同じく「支払い済みを・・・送信するステップ」について「前記取立ての完了通知から，前記取立て依頼電文の基になった前記電子請求書の固有の識別コードを有する電子請求書を前記データベースから特定し，前記特定された」との限定を付加するものであって，特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで，本件補正後の前記請求項１に記載された発明（以下「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるかについて以下に検討する。
　
３　本件補正の適否（独立特許要件）
３−１　引用例
　原審の拒絶の理由に引用された，本願の出願日前に頒布された刊行物である，田代裕三「電子請求書掲示／支払いサービス（上）米国の現状と実現方式」日経デジタルマネーシステム，日経ＢＰ社，１９９９年１０月１５日，５２号，１３〜１５頁（以下「引用例１」という。），田代裕三「電子請求書掲示／支払いサービス（中）米国の先進企業」日経デジタルマネーシステム，日経ＢＰ社，１９９９年１１月１日，５３号，１４〜１５頁（以下「引用例２」という。），田代裕三「電子請求書掲示／支払いサービス（下）日本での今後の展開」日経デジタルマネーシステム，日経ＢＰ社，１９９９年１１月１５日，５４号，１４〜１５頁（以下「引用例３」という。），特開平９−７３４９６号公報（以下「引用例４」という。）には，それぞれ，図面とともに次の事項が記載されている。
　
３−１−１　引用例１の記載事項
　(ア)「米国ではオンラインで請求・支払いを行う「ＥＢＰＰ」サービスが数年前に登場し，インターネット金融サービスの「キラー・アプリケーション」として期待されている。ＥＢＰＰはElectronic Bill Presentment and Paymentの略であり，日本では電子請求書掲示／支払いサービスと呼ばれる。米国ではソフトウエアベンダーやポータルサイト，金融機関はもちろん，ベンチャ企業も同市場に参入し始めており，市場開拓期から成長期へ離陸する直前の段階にある。」（１３頁左欄１〜１１行）
　(イ)「これに対してＥＢＰＰは，インターネットなどを利用して請求明細書を利用者に掲示するとともに，その請求書に対する支払い指示をオンラインで電子的に処理できるようにしたサービスである。請求書掲示→内容確認→小切手記入→支払いという一連のサイクルをすべてシームレスにインターネット上で実現するワンストップ・サービスといえる。」（１３頁中欄１６〜２４行）
　(ウ)「ＥＢＰＰ
　インターネットなどを利用して電子的に請求明細書を利用者に提示するとともに，その支払いまで連結して処理するサービス。ＥＢＤＰ（Electronic Bill Delivery and Payment）や，請求書掲示の部分だけを指してＥＢＰ（Electronic Bill Presentment），ＥＢＰＲ（Electronic Bill Presentment）と呼ばれることもある。」（１３頁右欄１〜１１行）
　(エ)「ＥＢＰＰを利用した請求料金の支払いは以下のような手順になる。
１．請求企業は電子の請求書を作成してウェブサイトに掲示し，ウェブ・ブラウザなどから閲覧可能にする。
２．請求企業は必要に応じて，利用者に電子メールなどで当該サイトに請求書が到着した旨を通知する。
３．利用者は請求内容を確認した上で，支払い方法，支払い日付などを指定し，支払い処理を行う。
　支払い方法は口座引き落としとクレジットカードが一般的で，事前に支払い方法を登録しておけば，電子請求書に表示された支払いボタンをクリックするだけでよい。」（１４頁左欄１０〜２４行）
　(オ)「ＥＢＰＰサービスの電子課金・決済には以下の４者が関係する。
【請求企業】
　請求明細書を発行する企業（電力，水道，クレジットカードなど）。銀行や証券会社が取引明細・利用明細を発行する場合は，こうした金融機関も請求企業に準じるカテゴリーに包含することがある。
【コンソリデータ】
　複数の請求企業の請求書を１ヵ所にまとめ，請求掲示／支払いを支援するサービス提供業者。ベンダー，金融機関，ポータルサイトなどがこの業務を担うケースが多い。
【金融機関】
　利用者の口座から請求企業への支払いを行う電子決済サービスを提供する。また，オンラインで取引明細書を提供する請求企業でもあり，金融機関自らがコンソリデータの役割を果たすこともある。
【利用者】
　ＰＦＭソフト，ウェブ・ブラウザなどを通じて各種請求書にアクセスし，電子請求書を閲覧するとともに電子的に支払い指示を行う。」（１４頁左欄末行〜中欄２３行）
　(カ)「上記４者の組み合わせによりＥＢＰＰの様々なビジネスモデルが提供されており，官民双方から推奨モデルが提示されている。」（１４頁中欄２５〜２７行）
 (キ)「Direct Modelは，請求企業が自社もしくはアウトソーシング・センターで独自にウェブ・サイトを立てて，請求明細の掲示から支払い処理までを一括して行う。同モデルでサービスを受けるためには，利用者は請求企業のサイトに直接アクセスする必要がある。
　Thick Consolidation Modelは，請求企業からの請求明細情報をコンソリデータと呼ぶデータセンターにすべて転送する。利用者はコンソリデータのサイトにアクセスすればすべての情報を閲覧して支払いまでできる。
　Thin Consolidation Modelは，請求企業からの請求明細情報から，利用者番号，請求額，支払い期日などの主要情報のみを抽出してコンソリデータに転送しておく。コンソリデータのサイトにアクセスした利用者が詳細情報を閲覧したい場合には，請求企業のサイトにアクセスし直して閲覧することができる。支払い処理はコンソリデータ側で行う。」（１４頁中欄３４行〜１５頁左欄１０行）
　(ク)「民間３社が提案したThickとThinの２つのモデルはともにService Provider Consolidation Modelに包含されている。つまり，コンソリデータが徐々にThickとThinに対応するようになってきたため，あえて分ける必要がなくなったと考えられる。」（１５頁中欄１〜６行）
　(ケ)図２の「Service Provider Consolodation Model」には，請求企業から送付された請求データがコンソリデータの「請求データ」のファイルに記録されることが記載されている。
　
３−１−２　引用例２の記載事項
　(コ) 「コンソリデータ
　複数の請求企業の請求書を１ヵ所にまとめ，請求書掲示／支払いを支援するサービス提供者。請求企業から送られてくる請求書をデータセンターで統合して利用者の手元に電子的に届けるだけでなく，利用者からの支払い指示に従い請求企業の銀行口座への資金移動を仲介する業務も行う。」（１４頁右欄１３〜２２行）
　
３−１−３　引用例３の記載事項
　(サ)「こうした日本での利用者と請求企業の潜在的ニーズ，および米国でのＥＢＰＰサービスの進展状況を踏まえて，日本ではインターネット明細情報サービス推進協議会がＥＢＰＰサービスのインフラ整備に向けて活動を始めている。
　同協議会は，米国のＮＡＣＨＡ（Nationnal Automated Clearing House Association）におけるService Provider Consolidation Modelをベースとして，当面はプレゼントメント・サービス向けのデータセンター・ビジネスの実現性を調査・検証する。さらに将来は，請求支払い機能を視野に入れたＥＢＰＰサービス事業の見通しを検討し，事業化に結び付けていく（図）。」（１５頁左欄２１〜３５行）
　(シ)１５頁の図には，一般消費者からの支払い指示を受けて，インターネット明細情報サービスセンターから振込データが金融決済ネットワークを介して金融機関に送られ，金融機関からインターネット明細情報サービスセンターに明細・通知データが送られ，請求企業に入金明細が送られることが記載されている。
　
３−１−４　引用例４の記載事項
　(ス)「入金により，売主５２は売掛金を消し込む必要がある。支払指図データに含まれる処理項目は，全銀プロトコルに従った振込依頼人名，送金額，送金先金融機関名，支店名，受取人名，受取人口座番号等の送金処理に必要な最小限度の情報に限定されている。このため，売主５２は，入金情報から，支払が行われた請求書の番号等を知ることができず，入金と売掛金の対応関係を手作業等で判別する必要があり，売掛金消込作業の負担が大きかった。」（段落【０００５】）
　(セ)「また，請求書番号，請求金額，請求額と支払額との差異の説明等の売掛金消込処理を簡易化するために必要な関連情報を入力し，全銀システム９０経由で被仕向金融機関に送信することも考えられる。しかし，この方法では，全銀システム９０の大規模な変更が必要になり，従来の送金システムとの互換性が維持できなくなる等の問題がある。」（段落【０００７】）
　
３−１−５　引用例１発明 
(1) 上記３−１−１の記載事項を検討するに，引用例１の電子請求書掲示／支払いサービスを実施する方法は，次の(a)〜(f)を含むことが記載されているということができる。
　(a)　電子請求書掲示／支払いサービスの電子課金・決済は，電子請求書を発行する請求企業のシステム，コンソリデータ，利用者の口座から請求企業への支払いを行う電子決済サービスを提供する金融機関のシステム及び利用者のパソコンを用いて実施されること。
　(b)　コンソリデータは，請求企業のシステム及び利用者のパソコンとインターネットなどで接続されていること。
　(c)　コンソリデータは，請求企業のシステムからの電子請求書を受け取り，請求データのファイルに記録すること。 
　(d)　コンソリデータは，利用者のアクセスに応じて，請求データファイルに記録されている電子請求書を利用者のパソコンに表示して閲覧させ，電子的に支払いを指示させること。
　(e)　コンソリデータは，利用者が支払いを指示した電子請求書に基づいて支払い依頼を作成して金融機関のシステムに送ること。
　(f)　金融機関のシステムは，支払い依頼を受けて，電子決済サービスを行うこと。
(2) してみると，引用例１には，
「請求書を発行する請求企業が用いる請求企業のシステムと，
　請求書を受ける利用者が用いる利用者のパソコンと，
　利用者の銀行口座を管理し，前記利用者の銀行口座から前記請求企業への支払い処理を行う金融機関のシステムと， 
　前記請求企業のシステム及び前記利用者のパソコンとインターネットなどを介して通信可能に接続されたコンソリデータと
を用いて電子請求書掲示／支払いサービスの電子課金・決済を実施する方法において，
　前記コンソリデータが，電子請求書を，前記請求企業のシステムから受信するステップと，
　前記コンソリデータが，前記受信した電子請求書を請求データファイルに記録するステップと，
　前記コンソリデータが，前記請求データファイルに記録された前記電子請求書の内容を示し且つ前記利用者に前記電子請求書について支払い指示をさせるための画面を，前記利用者のパソコンに送信して表示させるステップと，
　前記コンソリデータが，前記利用者のパソコンに表示された前記画面上の前記電子請求書について前記利用者が支払い指示したことに応答して，前記利用者に支払い指示された前記記録された電子請求書に基づいて，支払い依頼を作成して前記金融機関のシステムに送るステップと，
　前記金融機関のシステムが，前記支払い依頼を受けて，前記電子請求書の支払いのための処理を行うステップとを有する方法。」
の発明（以下「引用例１発明」という。）が記載されていると認められる。
　
３−２　対比
(1) そこで，本願発明（以下「前者」という。）と引用例１発明（以下「後者」という。）とを対比すると，後者の「請求企業」，「請求企業のシステム」，「利用者」，「利用者のパソコン」，「金融機関のシステム」，「コンソリデータ」が前者の「サプライヤ」，「サプライヤシステム」，「バイヤ」，「バイヤシステム」，「銀行システム」，「サーバ」にそれぞれ相当し，後者の「電子請求書掲示／支払いサービスの電子課金・決済を実施する方法」は，前者の「取引及び決済を管理する方法」に相当する。
　また，後者の「支払い処理」，「インターネットなど」，「請求データファイルに記録」，「電子請求書の内容を示し且つ利用者に電子請求書について支払い指示をさせるための画面」，「利用者が支払い指示したことに応答して」，「支払い依頼を受けて，電子請求書の支払いのための処理を行う」は，前者の「入出金処理」，「通信ネットワーク」，「データベースに登録」「電子請求書の内容を示した画面」，「バイヤの承認の入力を受けた場合に」，「依頼を受けて，バイヤの銀行口座からサプライヤに電子請求書に記述されている請求金額を移動する処理を行い」にそれぞれ相当する。
(2) そうすると，両者は，
「請求書を発行するサプライヤが用いるサプライヤシステムと，
　請求書を受けるバイヤが用いるバイヤシステムと，
　バイヤの銀行口座を管理し，前記バイヤの銀行口座から前記サプライヤへの入出金処理を行う銀行システムと，
　前記サプライヤシステム，前記バイヤシステムと通信ネットワークを介して通信可能に接続されたサーバと
を用いて取引及び決済を管理する方法において，
　前記サーバが，電子請求書を，前記サプライヤシステムから受信するステップと，
　前記サーバが，前記受信した電子請求書をデータベースに登録するステップと，
　前記サーバが，前記データベースに登録された前記電子請求書の内容を示した画面を，前記バイヤシステムに送信して表示させるステップと，
　前記サーバが，前記バイヤの承認の入力を受けた場合に，前記登録された電子請求書に基づいて，前記登録された電子請求書の支払いのための依頼を作成して前記銀行システムに送るステップと，
　前記銀行システムが，前記依頼を受けて，前記バイヤの銀行口座から前記サプライヤに前記電子請求書に記述されている請求金額を移動する処理を行うステップと，
を有する方法。」
である点で一致し，下記の点で相違する。
　
〔相違点１〕前者の銀行システムは，「サプライヤの銀行口座」も管理し，バイヤの銀行口座から「サプライヤの銀行口座」への入出金処理を行い，サーバと「通信ネットワークを介して通信可能に接続され」ているのに対し，後者の銀行システムは，サプライヤの銀行口座について特定されておらず，サーバとの接続についても特定されていない点。
〔相違点２〕前者のデータベースには，電子請求書の「状態」も登録されるのに対し，後者のデータベースはそうでない点。 
〔相違点３〕前者は，「前記サーバが，前記登録されている電子請求書の状態を前記サプライヤシステム及び前記バイヤシステムの少なくとも一方に通知するステップ」を有するのに対し，後者はそうでない点。
〔相違点４〕前者のバイヤシステムに表示する画面は，「ＧＵＩ画面」であるのに対し，後者の画面は，ＧＵＩ画面と特定されていない点。
〔相違点５〕前者の依頼は，「電文」であり，「自動的に」作成されて銀行システムに「送信」されるのに対し，後者の依頼は，そのように特定されていない点。
〔相違点６〕前者の依頼は，「取立」依頼であるのに対し，後者の依頼は，支払い依頼である点。
〔相違点７〕前者の銀行システムは，依頼を受けて，「前記銀行システムの取立システムを用いて」，サプライヤの「銀行口座に」請求金額を移動する「取立」処理を行い，「取立てが完了すると，リアルタイム又は所定のタイミングで，取立ての完了通知を前記サーバに送信する」のに対し，後者はそうでない点。
〔相違点８〕前者の電子請求書は，「どの請求書であるかを特定するための固有の識別コードが前記サプライヤシステムによって記述された」ものであるのに対し，後者の電子請求書はそうでない点。
〔相違点９〕前者は，「前記サーバが，前記取立ての完了通知を受信すると，前記取立ての完了通知から，前記取立て依頼電文の基になった前記電子請求書の固有の識別コードを有する電子請求書を前記データベースから特定し，前記特定された，前記データベースに登録されている前記電子請求書の状態を支払い済みに更新し，その電子請求書についての支払い済みを，前記サプライヤシステム及び前記バイヤシステムの少なくとも一方に送信するステップ」を有するのに対し，後者はそうでない点。
　
３−３　判断
(1) 相違点１について
　コンソリデータと金融決済ネットワークを通信可能に接続し，振込データを金融決済ネットワークを介して請求企業の金融機関に送ることが，引用例２，３に開示されており，また，銀行システムが支払い側の銀行口座と受け取り側の銀行口座の両方を管理し，支払い側の銀行口座から受け取り側の銀行口座への入出金処理を行うことは周知の事項であるから，後者の銀行システムを通信ネットワークを介してサーバと通信可能に接続し，後者の銀行システムがサプライヤの銀行口座も管理し，バイヤの銀行口座からサプライヤの銀行口座への入出金処理を行うようにすることは，当業者が容易に想到し得ることである。
(2) 相違点２について
　コンピュータシステムを用いて一連の事務処理を管理する場合，処理の進捗状況を管理することは周知の事項であるから，後者において，電子請求書について未払いであるか，払い済みであるか等の処理の進捗状況を管理することは，当業者が容易に想到し得ることである。
　そして，処理の進捗状況を管理する手法として，事務処理に係る書類にその進捗状況の情報，すなわち，状態を付加することも，国際公開第９９／０５６２８号パンフレット（特表２００１−５１１５６７号公報参照）に記載されるように周知の事項であるから，後者において，電子請求書の状態もデータベースに登録することは，当業者が容易になし得ることである。
(3) 相違点３について
　コンピュータシステムを用いて一連の事務処理を管理する場合，処理の進捗状況を管理し，関係者に通知することは周知の事項であるから，後者において，サーバが登録されている電子請求書の状態をサプライヤシステム及びバイヤシステムの少なくとも一方に通知するように構成することは，当業者が容易に想到し得ることである。
　また，引用例１には，コンソリデータが利用者に請求書の到着を通知する旨の記載はないが，摘記事項(エ)に「請求企業は必要に応じて，利用者に電子メールなどで当該サイトに請求書が到着した旨を通知する。」と記載されており，後者においても，コンソリデータから利用者に請求書の到着を通知し，利用者にコンソリデータのサイトにアクセスさせる構成を採用することは，当業者が容易に想到し得ることである。
　そして，請求書の到着を通知することは，請求書が新規の請求書で，未払い状態であることを通知することと実質的に同じことであるから，引用例１の記載からみても，後者において，サーバが登録されている電子請求書の状態をバイヤシステムに通知するように構成することは，当業者が容易に想到し得ることである。
　したがって，後者において，相違点３に係るステップを付加することは，当業者が容易に想到し得ることである。
(4) 相違点４について
　引用例１には，摘記事項(エ)に，利用者は，ウェブ・ブラウザを通じて電子請求書を閲覧し，電子請求書に表示された支払いボタンをクリックする態様が記載されており，このウェブ・ブラウザを通して表示される画面はＧＵＩ画面であるから，後者の画面をＧＵＩ画面とすることは，当業者が容易に想到し得ることである。
(5) 相違点５について
　サーバと銀行システムを通信ネットワークを介して通信可能に接続すれば，依頼は，電子的な依頼，すなわち，依頼電文となり，銀行システムに送信される構成となることは，直ちに導出される事項である。
　サーバと銀行システムを通信ネットワークを介して通信可能に接続することは，上記(1)で述べたとおり，当業者にとって容易であるから，後者において，依頼を依頼電文とし，依頼電文を銀行システムに送信する構成とすることもまた容易である。
　そして，引用例１に記載されたコンソリデータ方式では，利用者は，電子請求書に表示された支払いボタンをクリックするだけでよいようにするのであるから，後者において，依頼を自動的に作成する構成とすることは，当業者が容易に想到し得ることである。
(6) 相違点６，７について
　(i)　支払い側の銀行口座及び受け取り側の銀行口座を管理する銀行システムにおいて，支払い処理と取立て処理は，手続をどちらの口座から開始するかの違いがあるが，いずれも，支払い側の銀行口座から受け取り側の銀行口座へ資金を移動する処理として周知の処理である。
　そして，前者における取立て処理は，バイヤの承認の入力を条件しており，バイヤが支払うことを承認して開始されるものであるから，銀行システムにおける資金移動処理を支払い処理とするか，取立処理とするかは，人為的に取り決めることができる事項である。
　したがって，後者において，支払い側の銀行口座から受け取り側の銀行口座へ資金を移動する処理として取立て処理を採用し，支払い依頼を，取立て依頼とすることは，当業者が容易になし得ることである。
　そして，銀行システムの取立システムは，銀行口座間の資金移動手段として周知のものであるから，銀行システムの取立システムを用いて取立て処理を行うことも，当業者が容易になし得ることである。
　(ii)　引用例３の摘記事項(シ)に，金融機関において資金移動処理が完了すれば，その旨の通知をコンソリデータに送ることが記載されているから，後者において，銀行システムにおける処理が完了した際に，その旨を銀行システムからサーバに送信することは，当業者が容易になし得ることである。
　そして，資金移動処理が完了した旨の通知をどのタイミングで行うかは，当業者が適宜設定する事項であるから，後者において，リアルタイム又は所定のタイミングで，完了通知をサーバに送信することも，当業者が容易になし得ることである。
　(iii)　したがって，後者において，相違点６，７に係る構成を得ることは，当業者が容易に想到し得ることである。
(7) 相違点８について
　(i) 支払い指図データとともに請求書番号を全銀システム経由で被仕向金融機関に送信すれば，売掛金の消し込み処理が簡易になることは，引用例４に記載されるように周知の事項である。
　もっとも，引用例４は，平成７年の出願に係るものであり，その当時の全銀システムでは，請求書番号等をそのまま送信するには問題がある旨記載されているが，渡辺保史「ＮＴＴデータ「ＡＮＳＥＲ−ＳＰＣ」次世代ネット・バンキングのインフラに有望　市販財務会計・家計簿ソフトとの連係が実現」日経デジタルマネーシステム別冊，日経ＢＰ社，平成１０年１２月３１日発行，５８〜６５頁（特に，５９頁右欄２５行〜６０頁左欄４行）には，平成８年１２月以降は，全銀システムで２０桁の付加情報を決済情報と同時に送受信できるようになり，振込処理の際に同時に送信された請求書番号を用いて売掛金の消し込みを自動的に処理することができるようになったことが記載されているから，支払い指図データとともに請求書番号を全銀システム経由で被仕向金融機関に送信することにより，売掛金の消し込み処理を簡易にすることは，本願出願前に周知の事項であったと認定できる。
　そして，売掛金の消し込み処理は，請求書を発行し，支払いを受ける全ての取り引きにおいてなされる処理であるから，後者の取引及び決済を管理する方法においても，上記の支払い指図データとともに請求書番号を全銀システム経由で被仕向金融機関に送信することにより，売掛金の消し込み処理を簡易にする周知の事項を適用し，請求書の消し込み処理を簡易にすることは，当業者が容易に想到し得ることである。
　(ii) 後者の取引及び決済を管理する方法に，上記周知の事項を適用すれば，サプライヤが請求書番号を付した電子請求書をサーバに送信する構成となることは明らかである。
　しかも，請求書番号は，どの請求書であるかを特定するための固有の識別コードの機能を有するものである。
　(iii) したがって，後者において，相違点８に係る構成を得ることは，当業者が容易に想到し得ることである。
(8) 相違点９について
　(i) 上記相違点２について述べたとおり，後者において，電子請求書について未払いであるか，払い済みであるか等の処理の進捗状況を管理することは，当業者が容易に想到し得ることであるから，銀行システムからサーバに完了通知が送信されると，該完了通知に対応する電子請求書を支払い済みとして管理することは，当業者が容易になし得ることである。
　その際，電子請求書の固有の識別コードを利用して，前記完了通知に対応する電子請求書をデータベースから特定することは，上記相違点８で述べたとおり，当業者が容易になし得ることであるから，後者において，「前記サーバが，前記取立ての完了通知を受信すると，前記取立ての完了通知から，前記取立て依頼電文の基になった前記電子請求書の固有の識別コードを有する電子請求書を前記データベースから特定し，前記特定された，前記データベースに登録されている前記電子請求書の状態を支払い済みに更新」することは，当業者が容易に想到し得ることである。
　(ii) 上記相違点３について述べたとおり，コンピュータシステムを用いて一連の事務処理を管理する場合，処理の進捗状況を管理し，関係者に通知することは周知の事項であるから，後者において，登録されている電子請求書の状態が支払い済みとなった際に，サーバがその旨をサプライヤシステム及びバイヤシステムの少なくとも一方に通知するように構成することは，当業者が容易に想到し得ることである。
　なお，引用例３の１５頁の図には，金融機関から請求企業へ入金明細を送ることが記載されているが，資金移動処理の完了を金融機関から請求企業へ直接通知するか，コンソリデータを介して通知するかは，人為的取り決めというべき事項であるから，引用例３の１５頁の図の記載は，上記判断を左右するものではない。
　(iii) したがって，後者において，相違点９に係るステップを付加することは，当業者が容易に想到し得ることである。
(9) 作用効果について
　本願補正発明の作用効果についてみても，引用例１発明，引用例２〜４に記載された事項及び周知事項から当業者が予測し得る程度のものであり，格別のものとはいえない。
　
　なお，審判請求人は，審判請求書において，引用例１〜３のバイヤによる入力操作を不要とする技術と，引用例４のバイヤが手で情報を入力させることを前提とする技術を組み合わせることは不可能である旨主張するが，引用例４で開示される周知事項は，支払い指図データとともに請求書番号を全銀システム経由で被仕向金融機関に送信することにより，売掛金の消し込み処理を簡易にするということであり，ここでは，請求書番号が消し込み処理を行うところに戻ることが必須なのであって，バイヤ側からの支払い依頼をバイヤが手で入力することが必須なのではないから，引用例１〜３のバイヤによる入力操作を不要とする技術と，引用例４で開示される周知事項を組み合わせることに格別の阻害要因は認められない。
　
５　むすび
　したがって，本件補正は，特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので，特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３　本願発明について
１　本願発明
　上記のとおり，平成１８年６月５日付けの手続補正は却下され，また，平成１８年１月１２日付けの手続補正を却下した原審の決定は維持すべきものであるので，本願の請求項１，２に係る発明は，平成１７年１０月１４日付け手続補正により補正された特許請求の範囲の請求項１，２に記載された事項により特定されるとおりのものであり，請求項１の記載は次のとおりである（以下，請求項１に係る発明を「本願発明」という。）。
「請求書を発行するサプライヤが用いるサプライヤシステムと，
　請求書を受けるバイヤが用いるバイヤシステムと，
　サプライヤ及びバイヤの銀行口座を管理し，前記バイヤの銀行口座から前記サプライヤの銀行口座への入出金処理を行う銀行システムと，
　前記サプライヤシステム，前記バイヤシステム及び前記銀行システムと通信ネットワークを介して通信可能に接続されたサーバと
を用いて取引及び決済を管理する方法において，
　前記サーバが，どの請求書であるかを特定するための固有の識別コードが前記サプライヤシステムによって記述された電子請求書を，前記サプライヤシステムから受信するステップと，
　前記サーバが，前記受信した電子請求書及びその状態をデータベースに登録するステップと，
　前記サーバが，前記登録されている電子請求書の状態を前記サプライヤシステム及び前記バイヤシステムの少なくとも一方に通知するステップと，
　前記サーバが，前記データベースに登録された前記電子請求書の内容を示したＧＵＩ画面を，前記バイヤシステムに送信して表示させるステップと，
　前記サーバが，前記バイヤの承認により，前記登録された電子請求書に基づいて，前記登録された電子請求書の支払いのための取立て依頼電文を自動的に作成して前記銀行システムに送信するステップと，
　前記銀行システムが，前記取立て依頼電文を受けて，前記バイヤの銀行口座から前記サプライヤの銀行口座に前記電子請求書に記述されている請求金額を移動する取立て処理を行い，取立てが完了すると，取立ての完了通知を前記サーバに送信するステップと，
　前記サーバが，前記取立ての完了通知を受信すると，前記データベースに登録されている前記電子請求書の状態を支払い済みに更新し，その電子請求書についての支払い済みを，前記サプライヤシステム及び前記バイヤシステムの少なくとも一方に送信するステップと
を有する方法。」
　
２　引用例
　原査定の拒絶の理由に引用された引用例，および，その記載事項は，前記第２の３の３−１に記載したとおりである。
　
３　対比・判断
　本願発明は，前記第２の３で検討した本願補正発明から「取立ての完了通知を・・・送信するステップ」の限定事項である「前記銀行システムの取立システムを用いて」及び「リアルタイム又は所定のタイミングで」との構成を省き，同じく「支払い済みを・・・送信するステップ」の限定事項である「前記取立ての完了通知から，前記取立て依頼電文の基になった前記電子請求書の固有の識別コードを有する電子請求書を前記データベースから特定し，前記特定された」との構成を省いたものである。
　なお，本願発明では，本願補正発明の「前記バイヤの承認の入力を受けた場合に」が「前記バイヤの承認により」であり，その記載に不明りょうさは残るが，この点は，進歩性の判断に影響しない。
　そうすると，本願発明の構成要件を全て含み，さらに他の構成要件を付加したものに相当する本願補正発明が，前記第２の３の３−２及び３−３に記載したとおり，引用例１発明，引用例２〜４に記載された事項及び周知事項に基づいて，当業者が容易に発明をすることができたものであるから，本願発明も，同様の理由により，引用例１発明，引用例２〜４に記載された事項及び周知事項に基づいて，当業者が容易に発明をすることができたものである。
　
４　むすび
　したがって，本願発明は，引用例１，引用例２〜４に記載された事項に記載された発明及び上記周知事項に基づいて，当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　よって，結論のとおり審決する。