2025-700709

特許第７６１８０８２号発明「振込代行システム、振込代行方法および振込代行プログラム」の特許異議申立事件について、次のとおり決定する。

結 論 特許第７６１８０８２号の請求項１－１１に係る特許を維持する。

理 由 第１ 手続の経緯 特許第７６１８０８２号の請求項１～１１に係る特許（以下「本件特許」という。）についての出願は、令和６年３月８日に出願され、令和７年１月９日にその特許権の設定登録がされ、同年１月２０日に特許掲載公報が発行された。その後、その特許に対し、同年７月９日に特許異議申立人 金澤 毅（以下、「異議申立人」という。）は、特許異議の申立てを行った。 第２ 本件発明 本件特許の請求項１～１１に係る発明（以下、「本件発明１」～「本件発明１１」という。）は、それぞれ、特許請求の範囲の請求項１～１１に記載された事項により特定される次のとおりのものである 「【請求項１】 ソフトウェアプラットフォームを提供するＳａａＳ事業者のサーバから請求情報を取得する情報取得部と、 支払日または前記支払日に基づく日が到来すると、仕向銀行における支払者の口座から、前記仕向銀行における振込代行事業者もしくは前記振込代行事業者の委託先の口座に支払い金額の口座振替を行うように前記仕向銀行に依頼する口座振替依頼部と、 前記仕向銀行から前記口座振替が完了した旨の通知を受信すると、中継銀行に対して、前記中継銀行における前記振込代行事業者もしくは前記振込代行事業者の委託先の口座から被仕向銀行における受取者の口座に前記支払い金額の振込処理を行うように依頼する振込依頼部と、 を備える振込代行システム。 【請求項２】 前記口座振替の実行により、前記支払者の口座から前記支払い金額が即時に引き落とされる、請求項１に記載の振込代行システム。 【請求項３】 振込代行を依頼する旨の支払い指図および請求情報を受信すると、前記支払者の引落口座および前記請求情報を含む支払い指図情報を支払い指図データベースに登録する登録部を備える、請求項１に記載の振込代行システム。 【請求項４】 前記登録部は、前記仕向銀行から前記口座振替の完了通知を受信すると、前記支払い指図データベースの口振ステータスを未処理から処理済みに更新する、請求項３に記載の振込代行システム。 【請求項５】 前記登録部は、前記中継銀行から前記振込処理の完了通知を受信すると、前記支払い指図データベースの振込ステータスを未処理から処理済みに更新する、請求項３に記載の振込代行システム。 【請求項６】 前記支払者の要求に応じて、前記支払い指図データベースに登録された振込ステータスを取得する情報取得部と、 前記振込ステータスを前記支払者の端末に表示させる表示制御部を備える、請求項５に記載の振込代行システム。 【請求項７】 前記仕向銀行は、前記支払者により指定された銀行である、請求項１に記載の振込代行システム。 【請求項８】 前記仕向銀行の銀行システムは、前記口座振替を行った後、所定の振込タイミングで、前記振込代行事業者もしくは前記振込代行事業者の委託先の口座に振り替えられた前記支払い金額を前記中継銀行における前記振込代行事業者もしくは前記振込代行事業者の委託先の口座に振り込む振込処理を行う、請求項１に記載の振込代行システム。 【請求項９】 前記仕向銀行の銀行システムは、支払日が同じ複数の請求に係る支払い金額を一括で前記中継銀行の前記口座に振り込む、請求項８に記載の振込代行システム。 【請求項１０】 情報取得部が、ソフトウェアプラットフォームを提供するＳａａＳ事業者のサーバから請求情報を取得するステップと、 口座振替依頼部が、支払日または前記支払日に基づく日が到来すると、仕向銀行における支払者の口座から、前記仕向銀行における振込代行事業者もしくは前記振込代行事業者の委託先の口座に支払い金額の口座振替を行うように前記仕向銀行に依頼するステップと、 振込依頼部が、前記仕向銀行から前記口座振替が完了した旨の通知を受信すると、中継銀行に対して、前記中継銀行における前記振込代行事業者もしくは前記振込代行事業者の委託先の口座から被仕向銀行における受取者の口座に前記支払い金額の振込処理を行うように依頼するステップと、 を備える振込代行方法。 【請求項１１】 請求項１０に記載の振込代行方法をコンピュータに実行させる振込代行プログラム。」 第３ 特許異議申立書に記載した申立ての理由の概要 令和７年７月９日に異議申立人が提出した特許異議申立書（以下、「特許異議申立書」という。）に記載した申立ての理由の概要は次のとおりである。 １ 異議申立人の提出した証拠 異議申立人は、次の甲第１号証～甲第３号証（以下、それぞれ、「甲１」～「甲３」という。）を証拠として提出している。 甲第１号証（甲１）：特開２０１９－１０６０９５号公報 甲第２号証（甲２）：特開２０１２－２２４１７号公報 甲第３号証（甲３）：特許第６９２５８２８号公報 ２ 申立理由 異議申立人の主張する特許異議の申立理由の概要は以下のとおりである。 理由（進歩性） 本件発明１～１１は、甲１～甲３に記載された事項に基づいて当業者が容易に発明をすることができたものであるから、本件特許は、特許法２９条２項の規定に違反してされたものである。 第４ 異議申立人の提出した証拠の記載 １ 甲１ （１）甲１の記載 甲１には、以下の記載がある。（なお、下線は合議体にて付与した。以下同じ。） 「【０００７】 このように、従来の技術による決済手段では、購入者及び販売者の双方に対して必ずしも利便性が高いサービスを提供しているとはいえない状況にある。 【０００８】 そこで、本発明の様々な実施形態により、利便性を向上させた決済を実行する処理装置を提供する。」 「【００１９】 １．情報処理システムの概要 図１は、本発明の一実施形態に係る情報処理システムの構成の一例を示すブロック図である。図１に示すように、一実施形態に係る情報処理システム１は、インターネット等を含む通信網１０に接続され、各購入者により操作可能な複数の端末装置２０-１、２０-２、・・・、２０-Ｎ（以下「端末装置２０」と総称することがある。）と、通信１０に接続され、各販売者により運用される複数のサーバ装置３０-１、３０-２、・・・、３０-Ｎ（以下「サーバ装置３０」と総称することがある。）と、通信網１０に接続され、決済代行企業により運用される１又はそれ以上のサーバ装置（処理装置）４０と、通信網１０に接続され、各金融機関により運用されるサーバ装置５０-１、５０-２、・・・、５０-Ｎ（以下「サーバ装置５０」と総称することがある。）と、を主に含む。 端末装置２０、サーバ装置３０、サーバ装置４０及びサーバ装置５０は、通信網１０を介して、相互に通信することが可能なものである。」 「【００２９】 ２－１．決済代行企業により運用されるサーバ装置（処理装置）４０の構成 図２に示すように、サーバ装置４０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４１と、メインメモリ４２と、ユーザインターフェイス（Ｉ／Ｆ）４３と、通信インターフェイス（Ｉ／Ｆ）４４と、外部メモリ４５と、ディスクドライブ４６と、を含み得るものであり、これらの各構成要素がバス４７を介して互いに電気的に接続されている。 【００３０】 ＣＰＵ４１は、外部メモリ４５からオペレーティングシステム、及び、様々な機能を実現するためのプログラム等をメインメモリ４２にロードし、ロードしたプログラムに含まれる命令を実行する。メインメモリ４２は、ＣＰＵ４１が実行するプログラムを格納するために用いられ、例えばＤＲＡＭによって構成される。ＣＰＵ４１に代えて又はＣＰＵ４１とともに、ＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を用いることも可能である。 【００３１】 ＣＰＵ４１は、端末装置２０、サーバ装置３０及びサーバ装置５０のうちの少なくとも１つの装置から受信した情報に基づいて、様々な処理及び演算を実行する。」 「【００４４】 ３－１．決済代行企業により運用されるサーバ装置（処理装置）４０の機能 図４は、図１に示した情報処理システム１に用いられるサーバ装置４０が有する機能の一例を示すブロック図である。図４に示すように、サーバ装置４０は、主に、通信部１００と、制御部１１０と、記憶部１２０と、を含む。 【００４５】 通信部（送受信部）１００は、通信網１０に接続された装置、例えば、購入者により操作される端末装置２０、販売者により運用されるサーバ装置３０及び金融機関により運用されるサーバ装置５０等と制御部１１０との間で通信を行うための通信インターフェイスである。通信部１００は、図２に例示した要素のうち主に通信Ｉ／Ｆ４４及びＣＰＵ４１により実現され得るものである。 【００４６】 制御部１１０は、販売者と購入者との間における代金の決済を代行するための様々な機能（後述）を実行するものである。制御部１１０は、図２に例示した要素のうち主にＣＰＵ４１、メインメモリ４２及び外部メモリ４５により実現され得るものである。 【００４７】 記憶部１２０は、販売者と購入者との間における代金の決済を代行するための様々な機能（後述）を実行するのに必要な情報を記憶するものである。記憶部１２０は、図２に例示した要素のうち主にＣＰＵ４１、メインメモリ４２及び外部メモリ４５により実現され得るものである。 【００４８】 制御部１１０により実行される機能の具体例は、以下のとおりである。 （１）購入者管理部１１１ 購入者管理部１１１は、購入者の情報（購入者情報）を管理するための機能を備える。購入者管理部１１１は、主に購入者の初回利用時の登録や購入者情報の更新等を行うことができる。なお、購入者情報は、記憶部１２０において購入者情報１２１として記憶され得る。 【００４９】 （２）販売者管理部１１２ 販売者管理部１１２は、販売者の情報（販売者情報）を管理するための機能を備える。販売者管理部１１２は、販売者情報や販売者との契約条件等の登録及び更新等を行うことができる。なお、販売者情報は、記憶部１２０において販売者情報１２２として記憶され得る。 【００５０】 （３）金融機関管理部１１３ 金融機関管理部１１３は、購入者、販売者及び決済代行企業の各々が保有する金融機関の口座情報（金融機関口座情報）等を管理する機能を備える。なお、金融機関口座情報は、記憶部１２０において金融機関口座情報１２３として記憶され得る。金融機関管理部１１３は、主に、金融機関の口座の登録、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の利用に必要なクレデンシャル情報（第１許可情報及び第２許可情報）の登録、並びに、金融機関が定める期間及び頻度におけるクレデンシャル情報の更新等を行うことができる。なお、クレデンシャル情報は、記憶部１２０において金融機関情報１２６として記憶され得る。 【００５１】 （４）決済代金出金部１１４ 決済代金出金部１１４は、購入者が保有する口座から決済代行企業が保有する口座に対する送金を管理する機能を備える。決済代金出金部１１４は、主に、サーバ装置３０からの要求信号の受付、送金実施結果の確認及び通知、購入者が保有する口座から決済代行企業Ｃが保有する口座に（同行間又は同一支店間振込による）送金する旨を指示する指示信号（第１指示信号）の送信、並びに、送金実施結果の取引情報への記録等を行うことができる。なお、取引情報は、記憶部１２０において取引情報１２４として記憶され得る。 【００５２】 （５）決済代金入金部１１５ 決済代金入金部１１５は、決済代行企業から販売者に対する送金を管理する機能を備える。決済代金入金部１１５は、主に、決済代行企業が保有する口座から販売者が保有する口座に（同行間又は同一支店間振込による）送金する旨を指示する指示信号（第２指示信号）の送信、及び、送金実施結果の取引情報への記録等を行うことができる。なお、取引情報は、記憶部１２０において取引情報１２４として記憶され得る。また、決済代金入金部１１５は、決済代行企業から販売者への送金を、予め販売者と合意した頻度に従って実施することも可能である。 【００５３】 さらに、決済代金入金部１１５は、決済代行企業から販売者に送金を行う際に、販売者と同一の金融機関に決済代行企業が保有する口座において十分な残高がない場合には、後述するように、他の金融機関において決済代行企業が保有する口座から販売者が保有する口座に送金（他行間振替）を行うことができる。 【００５４】 （６）残高管理部１１６ 残高管理部１１６は、決済代行企業が保有する複数の金融機関の口座の残高を管理する機能を備える。残高管理部１１６は、主に、後述するように各金融機関の口座間の残高調整にかかる資金移動、及び、各金融機関の口座と定期的に残高情報の突合等を行う。 【００５５】 ３－２．金融機関により運用されるサーバ装置５０の機能 図５は、図１に示した情報処理システム１に用いられるサーバ装置５０が有する機能の一例を示すブロック図である。図５に示すように、サーバ装置５０は、主に、通信部２００と、制御部２１０と、記憶部２２０と、を含む。 【００５６】 通信部（送受信部）２００は、通信網１０に接続された装置、例えば、購入者により操作される端末装置２０、販売者により運用されるサーバ装置３０及び決済代行企業により運用されるサーバ装置４０等と制御部２１０との間で通信を行うための通信インターフェイスである。通信部２００は、図３に例示した要素のうち主に通信Ｉ／Ｆ５４及びＣＰＵ５１により実現され得るものである。 【００５７】 制御部２１０は、当該サーバ装置５０がサーバ装置５０Ａとして機能する場合における第１送金を実現するための様々な機能（後述）、及び／又は、当該サーバ装置５０がサーバ装置５０Ｂとして機能する場合における第２送金を実現するための様々な機能（後述）を実行するものである。制御部２１０は、図３に例示した要素のうち主にＣＰＵ５１、メインメモリ５２及び外部メモリ５５により実現され得るものである。 【００５８】 記憶部２２０は、第１送金及び／又は第２送金を実現するための様々な機能（後述）を実行するのに必要な情報を記憶するものである。制御部２１０は、図３に例示した要素のうち主にＣＰＵ５１、メインメモリ５２及び外部メモリ５５により実現され得るものである。 【００５９】 制御部２１０は、主に、管理部２１１と、第１送金部２１２と、第２送金部２１３と、を含む。 管理部２１１は、購入者、販売者及び決済代行企業の各々が保有する金融機関の口座情報（金融機関口座情報）等を管理する機能を備える。なお、金融機関口座情報は、記憶部１２０に記憶され得る。また、管理部２１１は、金融機関の口座の登録、ＡＰＩの利用に必要なクレデンシャル情報（第１許可情報及び第２許可情報）の登録等を行うことができる。なお、クレデンシャル情報もまた記憶部１２０に記憶され得る。 【００６０】 第１送金部２１２は、通信部２００が決済代行企業により運用されるサーバ装置４０から第１指示信号を受信することを契機として、当該金融機関において購入者が保有する口座から当該金融機関において決済代行企業が保有する口座に代金を送金する（第１送金を実行する）。 【００６１】 第２送金部２１３は、通信部２００が決済代行企業により運用されるサーバ装置４０から第２指示信号を受信することを契機として、当該金融機関（すなわちこのサーバ装置４０を運用する金融機関）において決済代行企業が保有する口座から当該金融機関又は他の金融機関において販売者が保有する口座に代金を送金する（第２送金を実行する）。 【００６２】 ４．情報処理システム１の動作 ４－１．基本的な動作 次に、上述した構成を有する情報処理システム１の動作について説明する。なお、一実施形態では、購入者は、決済代行企業により運用されるサーバ装置４０に対して決済代金の支払いに用いるための金融機関の口座を複数設定し、決済の都度、決済代金の支払いに実際に用いる金融機関の口座を選択できるようにしてもよい。また、一実施形態では、販売者は、サーバ装置４０に対して決済代金の被振込先となる金融機関の口座を複数設定し、これら複数の金融機関の口座のうち最も優先度の高い金融機関の口座を通常用いる口座としておき、最も優先度の高い金融機関の口座がその金融機関のシステム障害等に利用できないような場合には、次に優先度の高い金融機関の口座を被振込先の口座として利用することができる。 【００６３】 図６は、図１に示した情報処理システム１において決済代行企業により運用されるサーバ装置４０が金融機関により運用されるサーバ装置５０からＡＰＩの利用に関するアクセストークンを取得するために行われる動作の一例を示すフロー図である。図７は、図１に示した情報処理システム１の動作の一例を示すフロー図である。図８Ａ～図８Ｌは、図１に示した情報処理システム１における購入者の端末装置２０において表示される画面の遷移例を示す模式図である。 以下、図６及び図７に示された動作と図８Ａ～図８Ｌに示された画面遷移とを対応付けて、情報処理システム１の動作を説明する。 【００６４】 まず図８Ａを参照すると、購入者の端末装置２０の画面には、ＥＣショップのために用意された所定のアプリケーション又は通常のウェブブラウザを介して、販売者のサーバ装置３０から受信したＥＣショップのページが表示されている。購入者は、ＥＣショップで商品（ここでは、「ミネラルウォーター５００ｍｌ」及び「トイレットペーパー １２ロール」）を選択して、「確認」というボタン３００をタップする。これにより、端末装置２０の画面には、図８Ｂに示すように、決済方法を選択するためのページが表示される。 【００６５】 購入者は、決済方法として、本件出願により提案される新規な決済方法（以下「新決済方法」という。）を選択すべく、「新決済方法」というボタン３０１をタップする。これにより、図８Ｃに示すように、端末装置２０の画面には、新決済方法による代金の決済のために利用する金融機関（振込元金融機関）として既に登録された振込元金融機関が表示される（なお、振込元金融機関が１つも登録されていない場合には、図８Ｃに示したページを飛ばして、後述する図８Ｄに示すページが表示される。）。ここでは、一例として、登録済みの振込元金融機関として、「××銀行」が表示されている。さらに、端末装置２０の画面には、図８Ｃに示すように、振込元金融機関の追加を促す「振込元銀行の追加」というボタン３０２も表示される。 【００６６】 図８Ｃに示した画面において、購入者が登録済みの振込元金融機関を選択した場合には、後述する図８Ｈに示すページが表示される。 【００６７】 一方、購入者が新たな振込元金融機関を登録すべくボタン３０２をタップした場合には、図８Ｄに示すページが表示される。購入者は、このページに振込元金融機関の候補として表示された金融機関のうち、ここでは「△△銀行」を選択するものとする。これにより、図６に示したステップ（以下「ＳＴ」という。）４００に示すように、端末装置２０が販売者のサーバ装置３０に対して、振込元金融機関の登録又は追加を要求する旨の信号を送信する。この信号を受信したサーバ装置３０は、ＳＴ４０１において、決済代行企業のサーバ装置４０に対して、振込元金融機関の登録又は追加に対する連携を要求する旨の信号を送信する。」 「【００７４】 購入者が図８Ｈに例示されたページにおける「注文を確定する」というボタン３０４をタップすることにより注文内容を確定すると、端末装置２０は、図７に示すように、ＳＴ５００において、新決済方法を選択した（新決済方法を要求する）旨の信号を販売者のサーバ装置３０に送信する。 【００７５】 引き続き図７を参照すると、ＳＴ５０１において、新決済方法の要求を受けた販売者のサーバ装置３０は、決済代行企業のサーバ装置４０に対して決済代行要求を行う。具体的には、購入者と販売者との間における代金の決済に関して、販売者により運用されるサーバ装置３０は、この決済を代行する旨を要求する要求信号を、決済代行企業のサーバ装置４０に送信する。この要求信号は、購入者を識別する情報、購入者の金融機関口座（購入者により振込元金融機関として選択された金融機関において購入者が保有する口座）を識別する情報、当該決済を識別する情報（注文番号等）、決済代金を示す情報、販売者を識別する情報等を含むものとすることができる。 【００７６】 サーバ装置３０から要求信号を受信したサーバ装置４０は、ＳＴ５０２において、要求信号により特定される金融機関に開設されている購入者の口座から上記金融機関に開設されている決済代行企業の口座に対して、要求信号により特定される代金を送金する旨を指示する第１指示信号（送金指示）を、上記金融機関により運用されるサーバ装置５０Ａに送信することができる。一実施形態では、サーバ装置４０は、上記金融機関により提供されるＡＰＩを実行することにより、第１指示信号をサーバ装置５０Ａに送信することができる。サーバ装置４０によるこのＡＰＩの利用は、サーバ装置４０が上述したＳＴ４０９においてサーバ装置５０Ａから取得したクレデンシャル情報（アクセストークン／第１許可情報）を、第１指示信号又は別の信号を介してサーバ装置５０Ａに送信し、サーバ装置５０Ａがこのクレデンシャル情報を適切なものであることを確認することにより、可能となるようにしてもよい。ここで、サーバ装置４０は、同行間振込又は同一支店間振込を実現するために、第１指示信号又は別の信号を介して、送金先には決済代行企業が要求信号により特定される金融機関に保有する口座を指定することができる。 【００７７】 第１指示信号を受信したサーバ装置５０Ａは、２要素認証（複数経路認証）を実行すべく、ＳＴ５０３において、購入者の端末装置２０に対して例えばプッシュ通知（電子メール等による通知であってもよい）を行う。これにより、再度図８を参照すると、端末装置２０の画面には、図８Ｉに示すように、振込元金融機関として選択された金融機関のために用意された所定のアプリケーションからのプッシュ通知が表示される（なお、端末装置２０がプッシュ通知を受信することに代えて電子メール等を受信するようにしてもよい）。購入者がプッシュ通知をタップすると、図８Ｊに示すように、端末装置２０により上記所定のアプリケーションが起動される。購入者は、上記所定のアプリケーションを用いて振込金額（決済の代金）を確認して許可すると、端末装置２０の画面には、図８Ｋに示すように、上記所定のアプリケーションにより２要素認証（複数経路認証）が要求される。すなわち、ＥＣショップのために用意された所定のアプリケーションを用いた購入者による認証（図８Ｈに示した認証）に加えて、振込元金融機関として選択された金融機関のために用意された所定のアプリケーションを用いた購入者による認証（図８Ｋに示した認証）が実行され得る（なお、図８Ｋに例示された第２の認証を省くことも可能である）。図８Ｋに示した認証が正常に実行されると、端末装置２０は、図８Ｌに示すように、ＥＣショップのために用意された所定のアプリケーションに復帰して、注文が完了する。 【００７８】 以上のような２要素認証が完了した後、再度図７を参照すると、ＳＴ５０４において、第１指示信号を受信したサーバ装置５０Ａは、この第１指示信号に従って、購入者の口座から決済代行企業の口座に代金を送金する（第１送金を実行する）。なお、別の実施形態では、サーバ装置５０Ａは、第１指示信号を受信した後、２要素認証を実行することなく、第１送金を実行してもよい。 【００７９】 決済代行企業により運用されるサーバ装置４０は、ＡＰＩを利用して、第１指示信号（送金指示）に対する応答をサーバ装置５０Ａから受信して、第１指示信号（送金指示）の結果を確認し（ＳＴ５０５）、そのように確認した結果（決済結果）を販売者のサーバ装置３０に通知する（ＳＴ５０６）。 【００８０】 決済結果の通知を受けた販売者のサーバ装置３０は、決済結果を購入者に通知する（ＳＴ５０７）。通知の方法としては、購入者のサイトに表示すること及びメール送信等の方法を用いることが可能である。販売者は、通知された決済結果に基づいて、決済が成功した旨を認識した場合には、購入者に対して商品の発送又はサービスの提供を実行する（ＳＴ５０８）。 【００８１】 決済代行企業のサーバ装置４０は、予め販売者と合意した頻度で、このサーバ装置４０により選択された金融機関のサーバ装置５０Ｂに対して、この選択された金融機関により提供されるＡＰＩの実行、ファイル伝送、又は、全銀ＴＣＰ／ＩＰ手順等の方法により、この選択された金融機関に開設されている決済代行企業の口座から販売者により予め設定された金融機関に開設されている販売者の口座に対して代金を送金する旨を指示する第２指示信号を送信することができる（ＳＴ５０９）。なお、決済代行企業のサーバ装置４０が、第２送金を実行するサーバ装置５０Ｂにより提供されるＡＰＩの利用に関するクレデンシャル情報（アクセストークン／第２許可情報）を取得する方法は、例えば、第１送金を実行するサーバ装置５０Ａにより提供されるＡＰＩの利用に関するクレデンシャル情報（アクセストークン／第１許可情報）を取得する方法（図６を参照して説明した方法）と同様のものとすることができる。 【００８２】 一実施形態では、同行間振込又は同一支店間振込を実現するために、サーバ装置４０は、送金元には、販売者により予め定められた金融機関において決済代行企業が保有する口座を指定することができる（すなわち、サーバ装置５０Ｂとして、販売者により予め設定された金融機関と同一の金融機関により運用されるサーバ装置５０Ｂを選択することができる）。別の実施形態では、後に図１０Ａ～図１０Ｃを参照して説明するように、送金元となる金融機関の口座の残高（又は残高及び貸越極度額の合計）が送金に必要な額に満たない場合等には、サーバ装置４０は、一時的に他の金融機関の口座からの送金も行うことも可能である（すなわち、サーバ装置５０Ｂとして、販売者により予め設定された金融機関とは異なる金融機関により運用されるサーバ装置５０Ｂを選択することも可能である）。 【００８３】 また、さらに別の実施形態では、サーバ装置４０は、上述したように、販売者により予め設定された複数の金融機関の口座のうち、通常用いる被振込先として設定された（最も優先度の高い）金融機関の口座が（この金融機関のシステムの障害等により）利用できない場合には、次に優先度の高い金融機関の口座を新たな被振込先として用いることが可能である。 【００８４】 サーバ装置４０から第２指示信号を受信したサーバ装置５０Ｂ（すなわち、サーバ装置４０により選択された金融機関のサーバ装置５０Ｂ）は、ＳＴ５１０において、決済代行企業の口座から販売者の口座に代金を送金する（第２送金を実行する）。なお、上述したように、決済代行企業の口座が開設されている金融機関と販売者の口座が開設されている金融機関とは、同一である場合もあれば異なる場合もある。 【００８５】 ＳＴ５１１において、販売者のサーバ装置３０は、決済代行企業のサーバ装置４０により提供される機能を用いて、図９に例示するような購入者との間で実施された取引の明細に対する照会及び出力を実行することができる。」 「【００９２】 ４－３．サーバ装置４０における残高管理部１１６の動作 次に、決済代行企業が保有する複数の金融機関の口座の残高を調整する残高管理部１１６の具体的な動作の一例について、図１１Ａ及び図１１Ｂを参照して説明する。図１１Ａ及び図１１Ｂは、図１に示した情報処理システム１に用いられるサーバ装置４０における決済代金入金部１１５の動作を説明する模式図である。 【００９３】 残高管理部１１６により実行される残高調整処理は、第２送金の実行時に他行間振込を極力発生させないようにすべく、複数の金融機関において決済代行企業が保有する口座の残高を適切に管理する処理である。この残高調整処理は、定期的に実行されるものとすることができる。 【００９４】 サーバ装置４０の記憶部１２０には、残高情報１２５の一部として、図１１Ａに示すように、複数の金融機関において決済代行企業が保有する口座について送金可能額等が記憶されている。 【００９５】 残高管理部１１６は、残高情報１２５を用いて、下限値を下回る送金可能額を有する口座及び上限値を上回る送金可能額を有する口座を認識する。図１１Ａに示した例では、残高管理部１１６は、下限値を下回る送金可能額を有する口座として、金融機関Ｄ３及びＤ５の口座を認識し、上限値を上回る送金可能額を有する口座として、金融機関Ｄ２、Ｄ４及びＤｎの口座を認識する。 【００９６】 残高管理部１１６は、一実施形態では、出金用の口座として、振込回数が最小となるように、送金可能額が上限値を上回る額が最も多い口座を優先的に選択することができる。例えば、図１１Ａに示した例では、残高管理部１１６は、送金可能額が上限値を上回る額が最も多い金融機関Ｄ２の口座を、出金用の口座として優先的に選択し、送金可能額が下限値を下回る額がその次に最も多い金融機関Ｄ３を、入金用の口座として選択することができる。さらに、残高管理部１１６は、送金可能額が上限値を上回る額がその次に多い金融機関Ｄ４の口座を、出金用の口座として優先的に選択し、送金可能額が下回る額が最も多い金融機関Ｄ５を、入金用の口座として選択することができる。これにより、残高管理部１１６は、金融機関Ｄ２において決済代行企業が保有する口座から金融機関Ｄ３において決済代行企業が保有する口座に対して不足額（３，０００，０００円）を振り込み、金融機関Ｄ４において決済代行企業が保有する口座から金融機関Ｄ５において決済代行企業が保有する口座に対して不足額（２００，０００円）を振り込む。」 「【図１】 ［図：0001429043000001.jpg］ 」 「【図２】 ［図：0001429043000002.jpg］ 」 「【図４】 ［図：0001429043000003.jpg］ 」 「【図７】 ［図：0001429043000004.jpg］ 」 「【図９】 ［図：0001429043000005.jpg］ 」 「【図１０Ａ】 ［図：0001429043000006.jpg］ 」 「【図１１Ａ】 ［図：0001429043000007.jpg］ 」 （２）甲１に記載されているといえる事項 ア 段落【００１９】の記載事項を踏まえると、甲１には、「各購入者により操作可能な端末装置２０、各販売者により運用されるサーバ装置３０、決済代行企業により運用されるサーバ装置４０、各金融機関により運用されるサーバ装置５０Ａ，５０Ｂを含む情報処理システム１におけるサーバ装置４０」との事項が記載されているといえる。 イ 段落【００４４】、【００４８】、【００５１】～【００５２】の記載事項を踏まえると、甲１には、「サーバ装置４０は、通信部１００と、制御部１１０と、記憶部１２０を含み、制御部１１０により、決済代金出金部１１４、決済代金入金部１１５の機能が実行される」との事項が記載されているといえる。 ウ 段落【００５１】、【００７６】の記載事項を踏まえると、前記【００７６】において、サーバ装置３０から要求信号を受信するのはサーバ装置４０が備える決済代金出金部１１４であることは明らかであるから、甲１には、「決済代金出金部１１４は、サーバ装置３０からの要求信号の受付を行い、サーバ装置３０から要求信号を受信すると、要求信号により特定される金融機関に開設されている購入者の口座から上記金融機関に開設されている決済代行企業の口座に対して、要求信号により特定される代金を送金する旨を指示する第１指示信号（送金指示）を、上記金融機関により運用されるサーバ装置５０Ａに送信する」との事項が記載されているといえる。 エ 段落【００７５】の記載事項を踏まえると、甲１には、「要求信号は、決済代金を示す情報を含む」との事項が記載されているといえる。 オ 段落【００５２】、【００８１】の記載事項を踏まえると、前記【００８１】に記載されているＳＴ５０９の処理を実行する主体は、サーバ装置４０が備える決済代金入金部１１５であることは明らかであるから、甲１には、「決済代金入金部１１５は、予め販売者と合意した頻度で、このサーバ装置４０により選択された金融機関のサーバ装置５０Ｂに対して、この選択された金融機関に開設されている決済代行企業の口座から販売者により予め設定された金融機関に開設されている販売者の口座に対して代金を送金する旨を指示する第２指示信号を送信する」との事項が記載されているといえる。 カ 段落【００８２】の記載事項を踏まえると、甲１には、「サーバ装置４０は、サーバ装置５０Ｂとして、販売者により予め設定された金融機関と同一の金融機関により運用されるサーバ装置５０Ｂを選択することも、販売者により予め設定された金融機関とは異なる金融機関により運用されるサーバ装置５０Ｂを選択することもできる」との事項が記載されているといえる。 （３）甲１に記載されている発明 上記（１）及び（２）によれば、甲１には次の発明（以下、「甲１発明」という。）が記載されている。 （甲１発明） 「各購入者により操作可能な端末装置２０、各販売者により運用されるサーバ装置３０、決済代行企業により運用されるサーバ装置４０、各金融機関により運用されるサーバ装置５０Ａ，５０Ｂを含む情報処理システム１におけるサーバ装置４０であって（上記ア）、 サーバ装置４０は、通信部１００と、制御部１１０と、記憶部１２０を含み、制御部１１０により、決済代金出金部１１４、決済代金入金部１１５の機能が実行され（上記イ）、 決済代金出金部１１４は、サーバ装置３０から要求信号を受信すると、要求信号により特定される金融機関に開設されている購入者の口座から上記金融機関に開設されている決済代行企業の口座に対して、要求信号により特定される代金を送金する旨を指示する第１指示信号（送金指示）を、上記金融機関により運用されるサーバ装置５０Ａに送信し（上記ウ）、 要求信号は、決済代金を示す情報を含み（上記エ）、 決済代金入金部１１５は、予め販売者と合意した頻度で、このサーバ装置４０により選択された金融機関のサーバ装置５０Ｂに対して、この選択された金融機関に開設されている決済代行企業の口座から販売者により予め設定された金融機関に開設されている販売者の口座に対して代金を送金する旨を指示する第２指示信号を送信し（上記オ）、 サーバ装置４０は、サーバ装置５０Ｂとして、販売者により予め設定された金融機関と同一の金融機関により運用されるサーバ装置５０Ｂを選択することも、販売者により予め設定された金融機関とは異なる金融機関により運用されるサーバ装置５０Ｂを選択することもできる（上記カ）、 決済代行企業により運用されるサーバ装置４０」 ２ 甲２ 甲２には、以下の記載がある。 「【背景技術】 【０００２】 従来における紙葉による請求書を用いた請求書発行側と請求書受領側との決済の流れは、例えば以下のように行われている。 【０００３】 すなわち、従来、請求書発行側では、紙葉による請求書を作成し、切手代、封筒代、用紙代、印刷代のコストをかけて、かつ、担当者押印、上長押印、社印押印、請求書３つ折り、封入、ラベリングの手間をかけた後、郵便により相手方に郵送している。 【０００４】 また、請求書受領側（支払側）では、請求書の到着を待たねばならず、結局事前にＦＡＸをもらったり、メールで請求金額を知らせてもらったりと煩雑な作業を行っている。更に、請求書が届いた後においては、使用済み封筒のような廃棄物も出て廃棄作業も付加される。 【０００５】 更に、請求書発行側においては、請求書発行後、請求書受領側（支払側）からの金融機関への入金に伴って、請求金額と入金金額との照合、消込作業が不可欠になり、多数の請求書を発行する事業者の経理部においては極めて煩雑な作業が必要であることが現状である。 【０００６】 近年では、インターネットを利用した請求書発行側と請求書受領側との間の電子決済装置として、特許文献１に開示されているように、債権者端末から提供された取引データに基づいて請求書データを作成し、請求先である債務者端末での閲覧に供して、請求明細項目毎に支払の選択を受け付け、選択された請求明細項目に基づいて、固有のキー情報が付加された支払データが作成され、キー情報は支払データの基となった請求明細項目に対応する取引データに関係付けて記録し、債権者口座への振込処理が行なわれると、その振込処理を指示した支払データのキー情報が取得され、取得されたキー情報と、取引データに関係付けて記録されたキー情報との照合により、請求明細項目毎の消し込み処理を行ない、これにより、債務者側に専用のシステムを設けることを不要にしつつ、債権者が個々の取引に対応した請求項目毎の消し込み処理を行なえるように構成した電子決済装置が提案されている。 【０００７】 しかし、この特許文献１を含め、ＳａａＳ（サース、Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）型の電子請求書アプリケーション、電子請求書受領アプリケーションを利用し、サービス提供事業者の介在の基に請求書発行側と請求書受領側との間の請求書関連の請求業務、更には、決済消込業務を低料金で、かつ、簡略、迅速に実現し得るような電子請求処理サービスシステムが存在しないのが実情である。」 「【発明が解決しようとする課題】 【０００９】 本発明が解決しようとする問題点は、サービス提供事業者の介在の基に請求書発行側の請求業務を低料金で、かつ、簡略、迅速に実現し得るような電子請求処理サービスシステムが存在しない点である。」 「【実施例】 【００２０】 以下、本発明の実施例１に係る電子請求書サービスシステムについて図面を参照して詳細に説明する。 【００２１】 本実施例１に係る電子請求書サービスシステム１は、図１に示すように、ＳａａＳ（サース、Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）型のカレンダー機能をも有する電子請求書アプリケーションをインターネットのような通信網２を経て利用可能に保持するサービス提供事業者のコンピュータシステム１１と、前記通信網２を経て前記電子請求書アプリケーションのサービスを受けるとともに、他の事業者に対する有償の役務の提供を行う複数（例えばＮ個：Ｎは正の整数）のユーザー事業者であるユーザー企業のコンピュータ装置３１と、前記通信網２に接続されるとともに、前記ユーザー企業からの役務の提供によりユーザー企業に対する支払い義務を有する複数（例えばＮ個：Ｎは正の整数）の顧客事業者である顧客企業のコンピュータ装置５１と、を有している。 また、前記通信網２に接続される金融機関サーバー１０１は、サービス提供事業者、ユーザー企業、顧客企業との各個別契約に基づいたネットバンキング機能を有している。」 「【００４３】 前記サービス提供事業者のコンピュータシステム１１においては、ユーザー企業側から送信された請求データ、外部データを基に電子請求書アプリケーションの処理により請求書の体裁を具備する請求書データ（図７にプリントアウトした態様の請求書の一例を示す）及びその明細データが作成され、前記ＤＢ１６に記憶される。 【００４４】 次に、前記サービス提供事業者のコンピュータシステム１１においては、電子請求書アプリケーションの処理により顧客企業向けに、例えば「ユーザー企業から御社宛の請求書が発行されています」との内容からなる請求通知メールが作成され、サービス提供事業者のコンピュータシステム１１のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）付でメールサーバー１４から通信網２を経て顧客企業担当端末５３に送信される。 そして、顧客企業担当端末５３において、担当者が顧客企業担当端末５３を操作し前記ＵＲＬをクリックすると、前記コンピュータシステム１１のＷｅｂサーバー１３が提供する顧客企業専用ページへログインできる画面が表示され、顧客企業担当端末５３において、固有のＩＤ、パスワードでログインすることで、前記請求書データ及び明細データが通信網２を経て顧客企業担当端末５３に送信され、この顧客企業担当端末５３の画面に表示される。また、前記プリンタ５４によりプリントアウトして紙葉として請求書とすることもできる。 この場合、顧客企業に対しては、顧客企業担当端末５３にて前記請求書データの利用に伴い、その枚数に応じた従量課金制（顧客企業担当端末５３によって当該請求書データを閲覧若しくはダウンロードした時点で例えば１通７０円）の態様で課金される。」 「【図１】 ［図：0001429043000008.jpg］ 」 したがって、甲２には、以下の技術事項（以下、「甲２記載の技術事項」という。）が記載されているといえる。 （甲２記載の技術事項） 「ＳａａＳ（サース、Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）型の電子請求書アプリケーションを利用可能に保持するサービス提供事業者のコンピュータシステムから請求書を取得すること」 ３ 甲３ 甲３には、以下の記載がある。 「【０１３５】 この時、同一の債権者に対する複数の送金データがある場合は、当該送金データを合算し、複数の取引識別子（例えば、請求書番号）を列記する形式の送金データを生成することも出来る。また、債権債務管理装置１０ｂは、債務データに基づいて計算された消費税額を基に生成した仕訳データを、通信ネットワークを介して、電子申告システム３０へ送信する。」 第５ 当審の判断 １ 理由１（進歩性）について （１）本件発明１について ア 対比 本件発明１と甲１発明とを対比する。 （ア）「ソフトウェアプラットフォームを提供するＳａａＳ事業者のサーバから請求情報を取得する情報取得部」について 甲１発明の「要求信号」は決済代金を示す情報を含むものであり、決済代金を示す情報は、販売者から購入者に対する請求に関する情報といえるから、甲１発明の「要求信号」は、本件発明１の「請求情報」に相当する。 また、甲１発明のサーバ装置４０の「決済代金出金部１１４」は、サーバ装置３０から要求信号を受信するものであるところ、要求信号を受信することは、要求信号を取得することといえる。 そうすると、甲１発明の「決済代金出金部１１４」と本件発明１の「情報取得部」は、「サーバから請求情報を取得する情報取得部」である点で共通しており、一方、両者は以下の点で相違する。 請求情報の取得元であるサーバに関し、本件発明１は、サーバが「ソフトウェアプラットフォームを提供するＳａａＳ事業者のサーバ」であるのに対し、甲１発明はそのような特定がない点。 （イ）「支払日または前記支払日に基づく日が到来すると、仕向銀行における支払者の口座から、前記仕向銀行における振込代行事業者もしくは前記振込代行事業者の委託先の口座に支払い金額の口座振替を行うように前記仕向銀行に依頼する口座振替依頼部」について 甲１発明の「購入者」、「要求信号により特定される代金」は、本件発明１の「支払者」、「支払金額」に相当する。 また、甲１発明の「決済代行企業」は、購入者から販売者への代金の振込を代行しているといえるから、本件発明１の「振込代行事業者」に相当する。 さらに、本件発明１の「振込代行事業者もしくは前記振込代行事業者の委託先」は択一的な記載であって、甲１発明の「決済代行企業」は、上記のとおりその一方である振込代行事業者と一致している。 そして、甲１発明の「決済代金出金部１１４」は、「サーバ装置３０から要求信号を受信すると、要求信号により特定される金融機関に開設されている購入者の口座から上記金融機関に開設されている決済代行企業の口座に対して、要求信号により特定される代金を送金する旨を指示する第１指示信号（送金指示）を、上記金融機関により運用されるサーバ装置５０Ａに送信」するものであり、ここで、甲１発明の「要求信号により特定される金融機関に開設されている購入者の口座」は、代金を送金する場合の送金元となる金融機関（仕向銀行）における購入者の口座であることを踏まえると、本件発明１の「仕向銀行における支払者の口座」に相当する。 また、甲１発明の「上記金融機関に開設されている決済代行業者の金融機関口座」は、本件発明１の「仕向銀行における振込代行事業者の口座」に相当する。 さらに、甲１発明において、「上記金融機関により運営されるサーバ装置５０Ａに、代金を送金する旨を指示する第１指示信号（送金指示）を送信する」ことは、購入者の口座から販売者の口座へ代金の振替を行うように金融機関に依頼することといえる。 してみると、甲１発明の「決済代金出金部１１４」と本件発明１の「口座振替依頼部」は、「仕向銀行における支払者の口座から、前記仕向銀行における振込代行事業者もしくは前記振込代行事業者の委託先の口座に支払い金額の口座振替を行うように前記仕向銀行に依頼する口座振替依頼部」である点で共通しており、一方、両者は以下の点で相違する。 本件発明１の「口座振替依頼部」は、「支払日または前記支払日に基づく日が到来すると」、「仕向銀行における支払者の口座から、前記仕向銀行における振込代行事業者もしくは前記振込代行事業者の委託先の口座に支払い金額の口座振替を行うように前記仕向銀行に依頼する」ものであるのに対し、甲１発明には、「決済代金出金部１１４」が送金指示を送信するタイミングとして、「支払日または前記支払日に基づく日が到来すると」との事項が特定されていない点。 （ウ）「前記仕向銀行から前記口座振替が完了した旨の通知を受信すると、中継銀行に対して、前記中継銀行における前記振込代行事業者もしくは前記振込代行事業者の委託先の口座から被仕向銀行における受取者の口座に前記支払い金額の振込処理を行うように依頼する振込依頼部」について 甲１発明の「販売者」は、購入者から代金を受け取る者であるから、本件発明１の「受取者」に相当する。 次に、本件発明１の「中継銀行」は「中継銀行における前記振込代行事業者もしくは前記振込代行事業者の委託先の口座から被仕向銀行における受取者の口座に前記支払い金額の振込処理を行う」ものであり、また、本件特許明細書の段落【００３２】の「中継銀行は、仕向銀行または被仕向銀行と同一の銀行であってもよい。」との記載を参酌すると、被仕向銀行と同一の銀行であってもよい（当然異なるものであってもよい）ものである。 一方、甲１発明の「サーバ装置４０により選択された金融機関」も、甲１発明が「サーバ装置５０Ｂとして、販売者により予め設定された金融機関と同一の金融機関により運用されるサーバ装置５０Ｂを選択することも、販売者により予め設定された金融機関とは異なる金融機関により運用されるサーバ装置５０Ｂを選択することもできる」ものであることを踏まえると、販売者の口座が開設されている金融機関と同一の金融機関であってもよく、また、異なるものであってもよいものである。 そうすると、甲１発明の「サーバ装置４０により選択された金融機関」は、本件発明１の「中継銀行」に相当し、「サーバ装置４０により選択された金融機関に開設されている決済代行企業の口座」は、本件発明１の「前記中継銀行における前記振込代行事業者の口座」に相当する。 また、甲１発明の「販売者により予め設定された金融機関に開設されている販売者の口座」は、本件発明１の「被仕向銀行における受取者の口座」に相当する。 さらに、上記（イ）と同様に、本件発明１の「前記振込代行事業者もしくは前記振込代行事業者の委託先」は択一的な記載であって、甲１発明の「決済代行企業」はその一方である振込代行事業者と一致している。 してみると、甲１発明の「決済代金入金部１１５」が、「予め販売者と合意した頻度で、サーバ装置４０により選択された金融機関のサーバ装置５０Ｂに対して、サーバ装置４０により選択された金融機関に開設されている決済代行企業の口座から販売者により予め設定された金融機関に開設されている販売者の口座に対して代金を送金する旨を指示する」ことは、本件発明１の「振込依頼部」が行う処理のうち、「中継銀行に対して、前記中継銀行における前記振込代行事業者もしくは前記振込代行事業者の委託先の口座から被仕向銀行における受取者の口座に前記支払い金額の振込処理を行うように依頼する」ことで共通しており、一方、両者は以下の点で相違する。 本件発明１の「振込依頼部」は、「前記仕向銀行から前記口座振替が完了した旨の通知を受信すると」振込処理を行うように依頼するものであるのに対し、甲１発明の「決済代金入金部１１５」は、「予め販売者と合意した頻度で」代金を送金する旨を指示するものである点。 （エ）「振込代行システム」について 甲１発明の「決済代行企業により運用されるサーバ装置４０」は、購入者から販売者への振込を代行する機能を備えているものといえるから、「振込代行システム」と称し得るものである。 イ 一致点及び相違点 上記（１）で対比した事項を踏まえると、本件発明１と甲１発明は、 「サーバから請求情報を取得する情報取得部と、 仕向銀行における支払者の口座から、前記仕向銀行における振込代行事業者もしくは前記振込代行事業者の委託先の口座に支払い金額の口座振替を行うように前記仕向銀行に依頼する口座振替依頼部と、 中継銀行に対して、前記中継銀行における前記振込代行事業者もしくは前記振込代行事業者の委託先の口座から被仕向銀行における受取者の口座に前記支払い金額の振込処理を行うように依頼する振込依頼部と、 を備える振込代行システム。」 という点で一致し、以下の点で相違している。 （相違点１） 請求情報の取得元であるサーバに関し、本件発明１は、サーバが「ソフトウェアプラットフォームを提供するＳａａＳ事業者のサーバ」であるのに対し、甲１発明はそのような特定がない点。 （相違点２） 本件発明１の「口座振替依頼部」は、「支払日または前記支払日に基づく日が到来すると」、「仕向銀行における支払者の口座から、前記仕向銀行における振込代行事業者もしくは前記振込代行事業者の委託先の口座に支払い金額の口座振替を行うように前記仕向銀行に依頼する」ものであるのに対し、甲１発明には、「決済代金出金部１１４」が送金指示を送信するタイミングとして、「支払日または前記支払日に基づく日が到来すると」との事項が特定されていない点。 （相違点３） 本件発明１の「振込依頼部」は、「前記仕向銀行から前記口座振替が完了した旨の通知を受信すると」振込処理を行うように依頼するものであるのに対し、甲１発明の「決済代金入金部１１５」は、「予め販売者と合意した頻度で」代金を送金する旨を指示するものである点。 ウ 判断 事案を鑑みて相違点１について検討する。 甲１の「近年、電子商取引（ＥＣ）市場の拡大に伴い、ＥＣショップやオークションサービス等において複数の決済サービスが利用可能となっている。特開２００９-９３７４号公報（特許文献１）には、電子商取引における利用代金を決済するために、クレジットカード等が用いられることが開示されている。クレジットカードやデビットカードによる決済や電子マネー等による決済サービスは、即時に決済を完了させるものであるため、購入者にとって利便性の高いサービスといえる。」（段落【０００２】）、「しかしながら、クレジットカード等を保有していない購入者は、銀行振込や代金引換等の決済方法を選択した場合、その決済にかかる手数料をほぼ全額負担することとなる。また、銀行振込を行うためには、購入者が、銀行窓口や現金自動預け払い機を利用するか、又は、インターネットバンキングを利用する必要がある。いずれを利用する場合においても、クレジットカードによる決済等を利用する場合と比較すると、手間及び時間がかかり、利便性が落ちてしまう。」（段落【０００４】）、「各販売者により運用されるサーバ装置３０は、その販売者が運営又は加盟するＥＣショップサイトやオークションサイト等を介したサービスを、各端末装置２０にインストールされた所定のアプリケーション又はウェブブラウザ等により、通信網１０を介して各端末装置２０に対して提供するものである。」（段落【００２２】）等の記載を踏まえると、甲１発明は、ＥＣショップやオークション等における決済（いわゆるＢｔｏＣ取引の決済）を対象とするものと解される。 一方、甲２には、上記第４の２に示したとおりの技術事項（「ＳａａＳ（サース、Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）型の電子請求書アプリケーションを利用可能に保持するサービス提供事業者のコンピュータシステムから請求書を取得すること」）が記載されているものの、段落【００３２】の「前記ユーザー企業の営業担当は、自企業内の役務について顧客企業との商談を受け、営業担当端末３３を操作し、前記電子請求書アプリケーションに基づき、当該顧客企業向けの見積書（図６にプリントアウトした態様の見積書一例を示す）を作成する。」等の記載から、甲２は、企業間取引における決済（いわゆるＢｔｏＢ取引の決済）を対象とするものと解される。 上記のとおり、甲１と甲２は、対象とする取引の性質が大きく異なるものである。 そして、ＢｔｏＣ取引においては、クレジットカード、銀行振込、代金引換等の多様な決済手段が広く用いられているものの、継続的な取引が多く請求書に基づく管理が一般的なＢｔｏＢ取引とは異なり、請求書の発行や管理が必要な場面は限られている。 そのため、ＢｔｏＣ取引において導入と運用にコストを要するＳａａＳ型の電子請求書アプリケーションを利用することは一般的な商慣行とは認められない。 してみると、甲１発明に、甲２記載の技術事項を適用する動機付けは認められない。 また、甲３には、上記第４の３に示したとおりの記載があるのみで、上記相違点に係る構成は記載されていない。 そして、上記相違点１に係る構成が本件特許の出願時の技術常識に鑑みて、周知技術であった又は当業者であれば自明であるとの合理的な理由もない。 したがって、本件発明１は、甲１発明及び甲２～甲３に記載された技術事項に基づいて当業者が容易に発明をすることができたものであるとはいえない。 エ 異議申立人の主張について 異議申立人は、特許異議申立書において、以下のとおり主張している。 「甲１発明の解決すべき課題は「従来の技術による決済手段では、購入者及び販売者の双方に対して必ずしも利便性が高いサービスを提供しているとはいえない状況にある。そこで、本発明の様々な実施形態により、利便性を向上させた決済を実行する処理装置を提供する。」（甲第１号証【０００７】、【０００８】）ことであり、甲第２号証の解決すべき課題は「サービス提供事業者の介在の基に請求書発行側の請求業務を低料金で、かつ、簡略、迅速に実現し得るような電子請求処理サービスシステム」（甲第２号証【０００９】）を提供することであるところ、両者はいずれも決済時の利便性向上を図ろうとするものである点で共通する。 そうすると、甲１発明の「販売者のサーバ装置３０」から受信する「要求信号」を「ソフトウェアプラットフォームを提供するＳａａＳ事業者のサーバ」から取得する「請求情報」とすることは、甲第２号証に基づいて当業者が容易に想到し得たものである。」（異議申立書第２６頁第７～２０行） 上記主張について検討する。 甲１、甲２が決済時の利便性向上を図ろうとするものである点で共通するとしても、上記ウのとおり、甲１と甲２は、対象とする取引の性質が大きく異なるものであり、甲１発明に甲２記載の技術事項を適用する動機付けは認められない。 したがって、異議申立人の上記主張は採用できない。 オ 小括 上記ウ～エより、他の相違点について検討するまでもなく、本件発明１は、甲１発明及び甲２～甲３に記載された技術事項に基づいて当業者が容易に発明をすることができたものであるとはいえない。 （２）本件発明２～９について 本件発明２～９は、本件発明１の構成に限定を加えて減縮したものであり、これらの請求項に係る発明は、いずれも、上記（１）イに示した上記相違点１に係る構成を有しているから、上記「（１）本件発明１について」で示したのと同様の理由により、甲１発明、甲２～甲３に記載された技術事項に基づいて当業者が容易に発明をすることができたものであるとはいえない。 （３）本件発明１０について 本件発明１０は、本件発明１の「振込代行システム」に係る発明を、「振込代行方法」として表現したものであり、少なくとも上記「（１）本件発明１について」で言及した上記相違点１に係る処理を実行するためのステップ（ソフトウェアプラットフォームを提供するＳａａＳ事業者のサーバから請求情報を取得するステップ）が備わっているのであるから、上記「（１）本件発明１について」で検討したのと同様に、甲１発明、甲２～甲３に記載された技術事項に基づいて当業者が容易に発明をすることができたものであるとはいえない。 （４）本件発明１１について 本件発明１１は、本件発明１０の「振込代行方法」に係る発明を、「振込代行プログラム」として表現したものであり、上記「（３）本件発明１０について」で検討したのと同様に、甲１発明、甲２～甲３に記載された技術事項に基づいて当業者が容易に発明をすることができたものであるとはいえない。 第６ むすび 以上によれば、特許異議の申立ての理由（特許法２９条２項）及び異議申立人の提出した証拠によっては、本件特許の請求項１～１１に係る特許を取り消すことはできない。 また、他に本件特許の請求項１～１１に係る特許を取り消すべき理由を発見しない。 よって、結論のとおり決定する。