【事件の表示】
　特願２０１４−５１３６６１「電子財布を経た支払いのためのシステム」拒絶査定不服審判事件〔平成２４年１２月　６日国際公開、ＷＯ２０１２／１６６７９０、平成２６年　８月１４日国内公表、特表２０１４−５１９６５７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２０１２年（平成２４年）５月３０日（パリ条約による優先権主張外国庁受理２０１１年５月３１日、米国、２０１１年６月１３日、米国）を国際出願日とする出願であって、平成２８年３月１４日付けで拒絶の理由が通知され、これに対して、同年９月１５日に意見書及び手続補正書が提出された後、平成２９年２月２３日付けで改めて拒絶の理由が通知され、これに対して、同年８月２３日に意見書及び手続補正書が提出されたが、同年９月４日付けで拒絶の査定がなされ、同拒絶査定の謄本が請求人に送達された。
　これに対して、同年１２月２８日に拒絶査定不服審判の請求がなされ、それと同時に手続補正がなされたものである。
第２　平成２９年１２月２８日にされた手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　平成２９年１２月２８日にされた手続補正（以下、「本件補正」という。）を却下する。
［理由］
１　本件補正について
　本件補正は、補正前の請求項１の記載を、以下のように、補正後の請求項１の記載とする補正を含むものである。
（補正前の請求項１）
【請求項１】
　コンピュータによって実行される方法であって：
　電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること；
　前記電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別すること；
　前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること；および、
　前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること、
を含む方法。
（補正後の請求項１）
【請求項１】
　コンピュータによって実行される方法であって：
　電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること；
　
前記電子バリュートークン取引コンピュータにより、前記支払取引に関係する第１の小売商を識別すること；
　前記電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別すること；
　前記電子バリュートークン取引コンピュータにより、前記電子財布内の
第２の小売商に関係し前記第１の小売商によって受け付けられない、第１の
　
前記電子バリュートークン取引コンピュータにより、前記第１のバリュートークンを、前記第１の小売商に受け付けられ前記電子財布内に存在しない第２のバリュートークンと交換すること；
　前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記
第２の
を含む方法。
２　本件補正の目的について
（１）本件補正は、請求項１について、以下の補正事項１ないし４を含む。
＜補正事項１＞
　「コンピュータによって実行される方法」に含まれるステップ（手順）として、「
前記電子バリュートークン取引コンピュータにより、前記支払取引に関係する第１の小売商を識別すること
＜補正事項２＞
　電子バリュートークン取引コンピュータが識別する「バリュートークン」を、「
第２の小売商に関係し前記第１の小売商によって受け付けられない、第１の
＜補正事項３＞
「コンピュータによって実行される方法」に含まれるステップ（手順）として、「
前記電子バリュートークン取引コンピュータにより、前記第１のバリュートークンを、前記第１の小売商に受け付けられ前記電子財布内に存在しない第２のバリュートークンと交換すること
＜補正事項４＞
　電子バリュートークン取引コンピュータが支払取引の支払いに充てる「バリュートークン」を、「前記
第２の
（２）検討
ア　補正事項１ないし４は、いずれも請求項１についての補正事項であるから、特許法第１７条の２第５項第１号の請求項の削除を目的とするものでなく、また、請求項１における発明特定事項の内容の実質的な変更を伴わないものではないから、同条同項第３号の誤記の訂正又は同条同項第４号の明りようでない記載の釈明を目的とするものでもない。
イ　そこで、請求項１についての補正事項１ないし４が、同条同項２号に掲げる事項を目的とするものであるかを検討する。
ウ　第一に、補正事項１ないし３は、いずれも、請求項１に記載された事項について直列的に発明特定事項を追加するものであるから、形式的には、特許請求の範囲の減縮に該当するといえる。しかし、補正事項４は、補正前には、支払いに充てられるものとされていた「前記バリュートークン」、すなわち、「電子財布」が含む「バリュートークン」を、補正後には、「第２のバリュートークン」としており、この「第２のバリュートークン」は、「電子財布内に存在しない」ものである（補正事項３を参照）から、補正後に支払いに充てられるバリュートークンは、補正前のバリュートークンの下位概念となっていない。
　よって、請求項１についての補正事項のうちの補正事項４は、特許請求の範囲の減縮に該当しないものである。
エ　第二に、補正事項１と補正事項３は、方法発明である請求項１に係る発明に、それぞれ、「
前記電子バリュートークン取引コンピュータにより、前記支払取引に関係する第１の小売商を識別すること
前記電子バリュートークン取引コンピュータにより、前記第１のバリュートークンを、前記第１の小売商に受け付けられ前記電子財布内に存在しない第２のバリュートークンと交換すること
オ　第三に、補正事項１ないし補正事項４は、補正前には存在していなかった「第１の小売商」と「第２の小売商」の区別と、この区別を前提とした「第２の小売商に関係し前記第１の小売商によって受け付けられない、第１のバリュートークン」と「第１の小売商に受け付けられ」るものである「第２のバリュートークン」の区別を導入し、その上で、「交換する」ステップを導入し、「支払い」に「充てる」ステップを「交換する」ステップを前提とするものへと変更するものである。
　これは、要するに、補正前には支払時の両替を可能とするための発明特定事項を含んでいなかったところを、補正後の発明は、支払時の両替を可能とするという課題をこれらを可能とするためのステップによって解決するものとなっているのであるから、いわば補正によって課題と解決手段が追加されたのであるから、補正の前後の課題が同一であるとはいえないものである。
　このように、請求項１についての補正事項１ないし４は、総合すると、補正の前後の課題が同一のものに該当しないものである
カ　してみると、本件補正における請求項１についての補正は、同条同項第２号に掲げる事項（いわゆる限定的減縮）を目的とするものでない。
キ　よって、本件補正のおける請求項１についての補正は、同条同項各号のいずれを目的とするものともしないものであるから、本件補正は、同条同項に規定する要件（いわゆる目的要件）に違反してなされたものである。
３　補正の却下の決定のまとめ
　以上のとおりであるから、本件補正は、「２」において上述したとおり、特許法第１７条の２第５項各号に掲げる事項を目的とするものではないから、同項の規定する要件（目的要件）に適合するものでない。
　したがって、本件補正は、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、補正の却下の決定の結論のとおり決定する。
第３　本願発明について
１　本願発明
　平成２９年１２月２８日にされた手続補正は、上記のとおり却下された。よって、本願の請求項に係る発明は、平成２９年８月２３日にされた手続補正により補正された特許請求の範囲の請求項１ないし１２に記載された事項により特定されるものであるところ、そのうち請求項１に係る発明（以下「本願発明１」という。）は、次のとおりのものである。
【請求項１】
　コンピュータによって実行される方法であって：
　電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること；
　前記電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別すること；
　前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること；および、
　前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること、
を含む方法。
２　原査定の拒絶の理由
　原査定の拒絶の理由は、この出願の請求項１ないし１２に係る発明は、本願の優先権主張の日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献１に記載された発明及び引用文献２ないし４に示された周知技術に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない、というものである。
　引用文献１：特開２００４−１３３６９３号公報
　引用文献２：特開２００３−５０９５９号公報
　引用文献３：特開２０１０−３９７８０号公報
　引用文献４：特開２００９−２２３４３６号公報
３　引用文献
（１）引用文献１
　原査定の拒絶の理由に引用された引用文献１には、図面とともに次の事項が記載されている。なお、下線は当審において付加したものである。
ア
「【００１８】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
図１は本発明の実施にかかるプリペイド型電子マネー決済システムの構成を示す図である。図示するように、
本発明の実施にかかるプリペイド型電子マネー決済システム（以下、「本システム」と称する）１０は
電子マネー発行サーバ（１１ａ〜１１ｃ）と
電子マネー発行サーバ（１１ａ〜１１ｃ）が発行した電子マネーを使用することができる店舗の店舗サーバ２０と、ユーザが電子マネーを使用するためのユーザ端末１２とはインターネット１３に接続されており、相互に各種のデータを授受することができる
【００１９】
電子マネー発行サーバ（１１ａ〜１１ｃ）は、それぞれ異なる種類の電子マネーを発行を行なう。尚、Ａ発行元サーバが発行するＡ電子マネーはＡプリベイト事業者が提携する店舗でしか利用できない
店舗サーバ２０は
ＷＷＷ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ）サーバ２１０、サービスサーバ２２０、データベースサーバ２３０を備えて構成されている
【００２０】
ＷＷＷサーバ２１０は、ユーザ端末１２から送られてくる各種の情報を受信してサービスサーバ２２０に渡すと共に、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）で記述されてなるＷｅｂページのデータを必要に応じてユーザ端末に宛てて送信する。
【００２１】
サービスサーバ２２０は
個人認証を行ない、その認証結果に応じて電子商取引の処理を進行させる上で必要となる各種の作業を管理するものであり、顧客管理部２２１、課金決済管理部２２３、注文管理部２３４、配信管理部２２５を備えて構成されている
【００２２】
顧客管理部２２１は、本システムを利用するユーザの個人認証に関する各種処理を管理するものであり、ユーザ登録部２２１ａ、ユーザ認証部２２１ｂに大別される。
【００２３】
ユーザ登録部２２１ａは、本システムを新規に利用するユーザについての個人種情報をユーザ情報データベース（以下、「ユーザ情報ＤＢ」と称す）２３１に登録する処理、並びにユーザが所有している電子マネー情報をユーザ別残高データベース（以下、「ユーザ別残高ＤＢ」と称す）２３２に登録する処理を行なう。
【００２４】
ユーザ認証部２２１ｂは
ユーザ端末１２を操作するユーザの個人認証をユーザ情報ＤＢ２３１に登録されている個人情報との照合処理の実行し、処理結果を注文管理部２３４に渡す
イ
「【００２８】
本システム１０は以上のように構成されている。
なお、図１に示した本システム１０の構成のうち、
サービスサーバ２２のユーザ管理部２２１、課金決済部２２２、注文管理部２２３、及び配信管理部２２４は、標準的な構成を有するコンピュータ
で構成することもできる
【００２９】
次に、
データベースサーバ２３が備えている各データベースのデータ構造について図２〜図６を参照しながら説明する
【００３０】
図２はユーザ情報ＤＢ２３１のデータ構造を示す。
ユーザ情報ＤＢ２３１には、各ユーザに割り当てられているユーザ毎に固有の「ユーザＩＤ」、「パスワード」、
などの各データがユーザ毎に、登録されたユーザを整理するための番号である「ユーザ番号」に関連付けられて蓄積される
【００３１】
図３はユーザ別残高ＤＢ２３２のデータ構造を示す。ユーザ別残高ＤＢ２３２には、ユーザが使用できる各電子マネーを分類するために各電子マネーに付与された「電子マネー名」の単位毎に
ユーザが商品代金として支払うことできる「ポイント数（残高）」、及び支払に用いる順番を示す「優先順位」、
の各データが関連付けられて「ユーザ番号」毎に蓄積される
ウ
「【００３６】
以下、
本システムの店舗サーバ２０において実行される、ユーザによる商品購入申し込みから購入商品の代金決済に至る処理の流れを図８に示すフローチャートを参照しながら説明する
同図にフローチャートで示された
一連の処理は
ユーザ端末１２から送信されるサービス要求をＷＷＷサーバ２１が受信することにより開始される
なお、ここでは、登録されたユーザの一人であるユーザＹＹＹ（ユーザ番号０００３）を例にして説明する。また、このユーザ番号に基づいて店舗サーバ２０における各処理の各種データの授受が行われることを前提として説明する。
【００３７】
まず、Ｓ１０１では、ユーザからの要求の内容が商品購入サービスへの要求を示すものであったか否かの判定を行う。
Ｓ１０２では、Ｓ１０１の判定がＹｅｓならば、その要求の内容にログインを要求するユーザＩＤとパスワードが含まれているか否かの判定を行う。Ｓ１０２の判定がＹｅｓならば、Ｓ１０３でユーザ認証処理が実行される
【００３８】
Ｓ１０３では、ユーザ管理部２２１のユーザ認証部２２２ｂが、受信したユーザＩＤ及びパスワードに該当するユーザＩＤ及びパスワードがユーザ情報ＤＢ２３１に蓄積されているか否かのユーザ認証処理を行なう
【００３９】
Ｓ１０４では、Ｓ１０３のユーザ認証処理の結果が認証ＯＫであったときにはログインが許可され
Ｓ１０５でユーザ認証失敗Ｗｅｂページを要求元のユーザ端末１２に送信を行なう。
　　　　　　　　　　　　・・・（中略）・・・
【００４３】
Ｓ１０９では、Ｓ１０４
で処理が終了すると
注文管理部２２３が、図１０に例示するような表示画面（購入申込画面）が表示されるＷｅｂページを表現するＨＴＭＬ文書データを
作成する
作成されたデータは
ユーザ端末１２に送出される
【００４４】
Ｓ１１０では、サービスサーバ２２の注文管理部２２３において、ユーザ端末１２で受信されて当該画面が表示され、
ユーザがユーザ端末１２を操作して該画面に表示されている商品リストのうち購入したい商品に対応する購入申込記入欄をチェックして「ＯＫ」なるボタンを操作したときにユーザＩＤと購入したい商品として購入申込がなされた商品のデータ（商品番号）が、ユーザ端末１２から送られて
【００４５】
Ｓ１１１では、Ｓ１１０で
ユーザ端末１２から送られた購入申込がなされた商品のデータ（商品番号）を基にして該当する商品名とその販売額を商品情報ＤＢ２３４から取得して課金決済管理部２２２に渡す
課金決済管理部２２２では渡された商品名とその販売額の各データを内部メモリ（図示せず）に一時的に格納を行なう
【００４６】
Ｓ１１２では、課金決済管理部２２２がユーザ別残高ＤＢに蓄積されている各電子マネーにそれぞれ対応する電子マネー発行サーバ宛てに残高照合の要求を実行する。この残高照合処理の詳細な動作についての説明は後述する。
【００４７】
Ｓ１１３では、課金決済管理部２２２においてＳ１１２で取得した各電子マネー毎の残高の合算残高がＳ１１１で取得して内部メモリに格納されている商品の販売額以内にあるか否かの判別を行なう。この判別結果がＹｅｓならば、使用できる電子マネー残高合計額で商品の代金額を支払できる通知を注文管理部２２３に渡し、Ｓ１１５に進む。判別結果がＮｏならば、使用できる電子マネー残高合計額が商品の代金額に不足している通知を注文管理部２２３に渡し、Ｓ１１４に進む。
【００４８】
Ｓ１１４では、残高不足通知を受けた注文管理部２２３において、図１１に例示するような表示画面（残高不足通知画面）が表示されるＷｅｂページを表現するＨＴＭＬ文書データを、課金決済管理部２２が管理する内部メモリに格納されている商品の販売額とユーザ別残高ＤＢ２３２に蓄積されている各電子マネー残高の各データに基づいて作成する。作成されたデータをＷＷＷサーバ２１に渡して、商品購入申込元のユーザ端末１２に送る。
【００４９】
Ｓ１１５では、支払可能通知を受けた
注文管理部２２３において、図１２に例示するような表示画面（購入申込確認画面）が表示されるＷｅｂページを表現するＨＴＭＬ文書データを
作成する
作成されたデータを
商品購入申込元のユーザ端末１２に送る
【００５０】
Ｓ１１６では、注文管理部２２３において、ユーザ端末１２で受信されて画面（購入申込確認画面）が表示され、
ユーザがユーザ端末１２を操作して該画面に表示されている指示に従って支払形式、支払順の入力欄に入力した後、「ＯＫ」なるボタンを操作したときに入力した支払形式、支払順の各データが、ユーザ端末１２から送られてＷＷＷサーバ２１が受信
【００５１】
Ｓ１１７では、Ｓ１１６で
受信した支払形式、支払順の各データを受注管理部２２３は課金決済管理部２２２に渡す
課金決済管理部２２２において渡された支払形式、支払順の各データをユーザ別残高ＤＢ２３２の対応する項目に蓄積を行なった後、蓄積終了の通知を注文管理部２２３に戻す
注文管理部２２３は内部メモリに格納しておいた購入申込がなされた商品番号を配信管理部２２４に渡し、商品番号を渡された配信管理部２２４は、商品番号に該当するデジタルコンテンツデータを購入申込先のユーザ端末に配信（ダウンロード）を行なう
【００５２】
Ｓ１１８では、Ｓ１１７における購入申込の
商品（デジタルコンテンツ）の配信処理が完了すると配信した商品の課金処理を行なう
Ｓ１１９では、Ｓ１１８で課金処理における課金対象となった各電子マネーの発行体であるプリペイド事業者との間における決済処理が行われる。」
エ
「【００６０】
以上までの処理が残高照合処理である。
次に、図８にＳ１１８として示されている課金処理の詳細について説明する。
図１４は課金処理の処理内容を示すフローチャートである。
この処理は
デジタルコンテンツを購入申込元のユーザ端末１２への送信が完了した後に行なわれる処理で
電子マネーに対する課金処理を行うものである
【００６１】
まず、
Ｓ３０１では
注文管理部２２３から商品代金ポイント数Ｐの取得が行われる
【００６２】
Ｓ３０２では、ユーザ別残高ＤＢ２３２における順位フラグが「１」に設定されているか否かを判別する。順位フラグはユーザが支払優先順位を指定した際に設定されるもので、順位フラグが「１」であれば、Ｓ３０５の処理に進む。順位フラグが「０」ならばユーザが支払優先順位を指定していないと見なしてＳ３０３の処理に進む。
Ｓ３０３では、課金決済管理部２２２はユーザ別残高ＤＢ２３２の各電子マネーの残高が比較される。
【００６３】
Ｓ３０４では、Ｓ３０３の処理での結果に基づいて、残高が少ない順に支払順番号を対応する電子マネーに付与してユーザ別残高ＤＢ２３２に格納される。ここで図３に示すように、Ａ電子マネー、Ｂ電子マネー、Ｃ電子マネーの各残高は３５０、５０、１７０の各ポイントであるので、支払優先順位は「１」位：Ｂ電子マネー、「２」位：Ｃ電子マネー、「３」位」：Ａ電子マネーの順となる。
【００６４】
Ｓ３０５では、課金決済管理部２２２はユーザ別残高ＤＢからユーザ番号に該当する各電子マネーの発行ＩＤを読み出して、それら各発行ＩＤを電子マネー名に対応する課金ＤＢ２３３にそれぞれ格納される
【００６５】
Ｓ３０６では、ユーザ別残高ＤＢ２３２内の電子マネー残高情報が格納されている項目番号である変数Ｓに初期値「１」が代入される
Ｓ３０７では、
Ｓ番目の電子マネーの残高ポイント数Ｐｔが商品代金ポイント数ＰＳを超えているか否かを判別する
その判別の結果、ＹｅｓならばＳ番目の電子マネー残高だけで商品代金を充足することができると見なしてＳ３０８の処理に進み
【００６６】
Ｓ３０８では、Ｓ番目の電子マネーの全残高Ｐｔを課金ＤＢ２３３にＳ番目の電子マネー名に対応付けて格納させる
一方、Ｓ３０７の判別処理の結果がＮｏであったときには、Ｓ３０９〜Ｓ３１４の一連の処理において、課金決済管理部２２２ａにおける電子マネーの残高における商品代金の不足分を使用できる他の電子マネーの残高を加算して充足させる処理が行われる。」
　したがって、上記引用文献１には次の発明（以下、「引用発明」という。）が記載されていると認められる。
「電子マネー発行サーバ（１１ａ〜１１ｃ）と、電子マネー発行サーバが発行した電子マネーを使用することができる店舗の店舗サーバ２０と、ユーザが電子マネーを使用するためのユーザ端末１２とが接続された、プリペイド型電子マネー決済システム１０（【００１８】）、であって、
　前記電子マネー発行サーバ（１１ａ〜１１ｃ）は、それぞれ異なる種類の電子マネーの発行を行い、Ａ発行元サーバが発行するＡ電子マネーはＡプリベイト事業者が提携する店舗でしか利用できないものであり（【００１９】）、
　前記店舗サーバ２０は、ＷＷＷサーバ２１０、サービスサーバ２２０、データベースサーバ２３０を備えて構成されており（【００１９】）、
　前記サービスサーバ２２０は、顧客管理部、課金決済管理部、注文管理部、配信管理部を備えて構成されるものであって（【００２１】）、
　ユーザ管理部２２１（「顧客管理部２２１」の誤記と認められる）、課金決済部２２２（「課金決済管理部２２２」の誤記と認められる）、注文管理部２２３、及び配信管理部２２４は、標準的な構成を有するコンピュータで構成されており（【００２８】）、
　データベースサーバ２３が備えているユーザ情報ＤＢ２３１には、各ユーザに割り当てられているユーザ毎に固有の「ユーザＩＤ」、「パスワード」などの各データが、登録されたユーザを整理するための番号である「ユーザ番号」に関連付けられて蓄積されており（【００３０】）、
　データベースサーバ２３が備えているユーザ別残高ＤＢ２３２には、ユーザが使用できる各電子マネーを分類するために各電子マネーに付与された「電子マネー名」の単位毎に、ユーザが商品代金として支払うことできる「ポイント数（残高）」、及び支払に用いる順番を示す「優先順位」の各データが関連付けられて「ユーザ番号」毎に蓄積されている（【００２９】【００３１】）システムの店舗サーバ２０において実行される、ユーザによる商品購入申し込みから購入商品の代金決済に至る一連の処理（【００３６】）に係る方法において、
　ユーザ端末１２から送信されるサービス要求をＷＷＷサーバ２１が受信することにより開始され（【００３６】）、
　ユーザからの要求の内容が商品購入サービスへの要求を示すものである場合には、ユーザ管理部２２１のユーザ認証部２２２ｂが、受信したユーザＩＤ及びパスワードに該当するユーザＩＤ及びパスワードがユーザ情報ＤＢ２３１に蓄積されているか否かのユーザ認証処理を行ない（【００３７】【００３８】）、
　ユーザ認証処理の結果が認証ＯＫであったときにはログインが許可され（【００３９】）、
　注文管理部２２３が、表示画面（購入申込画面）が表示されるＷｅｂページを表現するＨＴＭＬ文書データを作成し、作成されたデータはユーザ端末１２に送出され（【００４３】）、
　ユーザがユーザ端末１２を操作して該画面に表示されている商品リストのうち購入したい商品に対応する購入申込記入欄をチェックして「ＯＫ」なるボタンを操作したときにユーザＩＤと購入したい商品として購入申込がなされた商品のデータ（商品番号）が、ユーザ端末１２から送られ（【００４４】）、
　ユーザ端末１２から送られた購入申込がなされた商品のデータ（商品番号）を基にして該当する商品名とその販売額を商品情報ＤＢ２３４から取得して課金決済管理部２２２に渡し、課金決済管理部２２２では渡された商品名とその販売額の各データを内部メモリに一時的に格納を行い（【００４５】）、
　注文管理部２２３において、表示画面（購入申込確認画面）が表示されるＷｅｂページを表現するＨＴＭＬ文書データを作成し、作成されたデータを、商品購入申込元のユーザ端末１２に送り（【００４９】）、
　ユーザがユーザ端末１２を操作して該画面に表示されている指示に従って支払形式、支払順の入力欄に入力した後、「ＯＫ」なるボタンを操作したときに入力した支払形式、支払順の各データが、ユーザ端末１２から送られてＷＷＷサーバ２１が受信すること（【００５０】）、
　受信した支払形式、支払順の各データを受注管理部２２３（「注文管理部２２３」の誤記と認められる）は課金決済管理部２２２に渡し、課金決済管理部２２２において渡された支払形式、支払順の各データをユーザ別残高ＤＢ２３２の対応する項目に蓄積を行なった後、蓄積終了の通知を注文管理部２２３に戻し、注文管理部２２３は内部メモリに格納しておいた購入申込がなされた商品番号を配信管理部２２４に渡し、配信管理部２２４は、商品番号に該当するデジタルコンテンツデータを購入申込先のユーザ端末に配信（ダウンロード）を行うこと（【００５１】）、
　商品（デジタルコンテンツ）の配信処理が完了すると配信した商品の課金処理を行うものであって（【００５２】）、
　注文管理部２２３から商品代金ポイント数Ｐの取得が行われ（【００６１】）、
　課金決済管理部２２２はユーザ別残高ＤＢからユーザ番号に該当する各電子マネーの発行ＩＤを読み出して、それら各発行ＩＤを電子マネー名に対応する課金ＤＢ２３３にそれぞれ格納し（【００６４】）、
　ユーザ別残高ＤＢ２３２内の電子マネー残高情報が格納されている項目番号である変数Ｓに初期値「１」が代入され、Ｓ番目の電子マネーの残高ポイント数Ｐｔが商品代金ポイント数ＰＳを超えているか否かを判別すること（【００６５】）、
　その判別の結果、ＹｅｓならばＳ番目の電子マネー残高だけで商品代金を充足することができると見なし、Ｓ番目の電子マネーの全残高Ｐｔを課金ＤＢ２３３にＳ番目の電子マネー名に対応付けて格納させること（【００６５】−【００６６】）、
　を含む方法。」
４　対比・判断
（１）本願発明１と引用発明との対比
　引用発明の、各電子マネーの「電子マネー名」単位毎に蓄積された「ポイント数（残高）」は、商品代金の支払いに用いることができる価値を示すものであって、本願発明１の「電子バリュートークン」に相当する。また、引用発明は、この電子バリュートークンを、店舗サーバが備えるデータベースサーバが備えるユーザ別残高ＤＢにおいて「電子マネー名」単位に蓄積しており、このユーザ別残高ＤＢ（の各電子マネー名が示す項目）は、電子バリュートークンを示すデータを電子的に維持（本願明細書【００１１】）するものであるから、このユーザ別残高ＤＢにおいてユーザ毎（ユーザ番号毎）に区別される情報は、本願発明１の「電子財布」に相当する。
　また、引用発明においては、「電子マネー発行サーバ（１１ａ〜１１ｃ）」が「それぞれ異なる種類の電子マネーを発行」することから、引用発明の「電子マネー発行サーバ」は本願発明１の「電子バリュートークン発行者認証システム」に相当する。
　そして、引用発明の「店舗サーバ」は、「電子マネー発行サーバ」とは異なるものであって、当該「店舗サーバ」において「ユーザによる商品購入申し込みから購入商品の代金決済に至る一連の処理」が実行され、また、前記「店舗サーバ」を構成する「サービスサーバ」は「標準的な構成を有するコンピュータで構成され」ていることから、引用発明の「店舗サーバ」は本願発明１の「電子バリュートークン発行者認証システム
とは異なる
　次に、本願発明１を以下に示すＡ〜Ｅに分節して検討する。
Ａ
　コンピュータによって実行される方法であって：
Ｂ
　電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること；
Ｃ
　前記電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別すること；
Ｄ
　前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること；および、
Ｅ
　前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること、
Ａ
　を含む方法。
＜本願発明１の各分節についての検討＞
Ａ
「コンピュータによって実行される方法であって：」
「を含む方法。」について
　引用発明は「店舗サーバ」によって実行される方法であって、当該「店舗サーバ」は上記のとおり「標準的な構成を有するコンピュータで構成され」ていることから、引用発明は、本願発明１の「コンピュータによって実行される方法」に相当する。
Ｂ
「電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること；」について
　上記Ｂについては、以下のＢ−１、Ｂ−２、Ｂ−３に分けて検討する。
Ｂ−１
「電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、」「要求を受信すること；」について
　引用発明における、商品の代金を充当できる電子マネーに対する課金処理は、商品の代金の支払取引のために電子財布（ユーザ別残高ＤＢにおいてユーザ毎（ユーザ番号毎）に区別される情報）の各電子マネーの残高ポイント数Ｐｔを課金ＤＢに格納させ残高ポイント数Ｐｔを減少させているから、本願発明１の「電子財布に対する支払取引」に相当する。
　そして、引用発明では、商品を購入して代金を支払おうとするユーザによる「購入申込確認画面（図１２）」が表示されたユーザ端末に対する操作、具体的には、「購入申込確認画面（図１２）」の支払形式の入力欄及びユーザが所有する複数の電子マネーの電子マネー名及び残高に対応して表示される支払順の入力欄への入力と「ＯＫ」ボタンの操作、によってこのユーザ端末から送信される「支払形式、支払順の各データ」を受けて当該商品の代金を充当できる電子マネーに対する課金処理がなされるところ、この「支払形式、支払順の各データ」は、代金を支払おうとするユーザからの「電子財布に対する支払取引」に対する要求を示すものであるから、本願発明１の「電子財布に対する支払取引を処理するための要求」に相当する。
　よって、引用発明は、本願発明１の「電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、」「要求を受信すること；」に相当する構成を備えている。
Ｂ−２
「前記電子財布は複数の電子財布とともにデータベースに記憶され」について
　引用発明においては、「ユーザ別残高ＤＢ２３２には・・・各電子マネーに付与された「電子マネー名」の単位毎に、・・・「ポイント数（残高）」・・・の各データが関連付けられて「ユーザ番号」毎に蓄積され」ている、すなわち、「ユーザ別残高ＤＢ」（本願発明１の「データベース」に相当）に「電子マネー」の「ポイント数（残高）」などが「「ユーザ番号」毎に蓄積され」ている。
　ここで、引用発明において、「ユーザ別残高ＤＢ」に「「ユーザ番号」毎に蓄積され」ているということは、あるユーザの「電子マネー」の「ポイント数（残高）」が、他のユーザの「電子マネー」の「ポイント数（残高）」とともに「ユーザ別残高ＤＢ」に記憶されているということであるから、引用発明は、本願発明１の「前記電子財布は複数の電子財布とともにデータベースに記憶され」に相当する構成を備えている。
Ｂ−３
「前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む」について
　引用発明においては、上記のとおり、「ユーザ別残高ＤＢ２３２には・・・各電子マネーに付与された「電子マネー名」の単位毎に、・・・「ポイント数（残高）」・・・の各データが・・・蓄積され」ていることから、引用発明のユーザ別残高ＤＢにおいてユーザ毎（ユーザ番号毎）に区別される情報（本願発明１の「電子財布」に相当）は、複数の「ポイント数（残高）」（本願発明１の「バリュートークン」に相当）を含んでいる、すなわち、引用発明は、本願発明１の、「前記電子財布は」「複数のバリュートークンを含む」、に相当する構成を備えている。
　また、引用発明は、「電子マネー発行サーバ（１１ａ〜１１ｃ）は、それぞれ異なる種類の電子マネーの発行を行い、
Ａ発行元サーバが発行するＡ電子マネーはＡプリベイト事業者が提携する店舗でしか利用できないもの
複数の発行者によって発行された
　よって、引用発明は、本願発明１の「前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む」に相当する構成を備えている。
Ｃ
「前記電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別すること；」について
　本願発明１は、「前記要求の認証情報」、つまり、電子財布に対する支払取引を処理するための要求の認証情報、を「識別」しており、支払取引の対象となる電子財布は、電子財布に対する支払取引を処理するための要求に含まれる認証情報を識別することによって特定される。
　これに対して、引用発明の、支払取引を処理するための要求は、「支払形式、支払順の各データ」であって、支払取引の対象となる電子財布における支払優先順位を指定可能であり、「購入申込確認画面（図１２）」における、支払形式の入力欄及びユーザが所有する複数の電子マネーの電子マネー名及び残高に対応して表示される支払順の入力欄に入力された内容を示すデータであって、支払取引の対象となる電子財布に対応する電子マネーの認証のために識別される情報（認証情報）を含んでいるか否か、明示されていない。
　よって、この点は、相違点である。
Ｄ
「前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること；」について
　引用発明では、「店舗サーバ」により「Ｓ番目の電子マネーの残高ポイント数Ｐｔが商品代金ポイント数ＰＳを超えているか否かを判別する」ことから、引用発明は、本願発明１の「前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること」に相当する構成を備えている。
Ｅ
「前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること；」について
　引用発明では、「店舗サーバ」により「Ｓ番目の電子マネーの全残高Ｐｔを課金ＤＢ２３３にＳ番目の電子マネー名に対応付けて格納させる」ことから、引用発明は、本願発明１の「前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること」に相当する構成を備えている。
（２）本願発明１と引用発明との一致点・相違点
　以上のことから、本願発明１と引用発明との一致点及び相違点は、次のとおりである。
＜一致点＞
「コンピュータによって実行される方法であって：
　電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること；
　前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること；および、
　前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること、
を含む方法。」
＜相違点＞
　本願発明１は、「電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別する」のに対し、引用発明では、「前記要求（電子財布に対する支払取引を処理するための要求）」に含まれる「支払順」により電子財布の支払優先順位が指定されるものの、「前記要求（電子財布に対する支払取引を処理するための要求）」の「認証情報」を「識別」していない点。
（３）相違点についての判断
　以下、上記相違点について検討する。
　引用発明の「支払形式、支払順の各データ」のうちの「支払順」は、「購入申込確認画面（図１２）」においてユーザが所有する複数の電子マネーの電子マネー名及び残高に対応して表示される支払順の入力欄に入力された支払優先順位を示すものであって、これによってユーザが所有する複数の電子マネーに対応する複数の電子財布の集合のうちから特定の電子財布が一意に特定される情報である。
　そして、
引用発明の電子バリュートークン取引コンピュータ（店舗サーバ）が受信した「支払形式、支払順の各データ」を用いた処理を行うため
「購入申込確認画面（図１２）」の表示と「支払形式、支払順の各データ」の受信がユーザによるパスワード認証から続く一連の認証セッション中のものであることを示す情報
　以上を踏まえれば、引用発明における電子財布に対する支払取引を処理する電子バリュートークン取引コンピュータ（店舗サーバ）において、「支払形式、支払順の各データ」が含む又は伴う、パスワード認証から続く一連の認証セッション中のものであることを示す情報と「支払順」を併せた情報を、支払取引の対象となる電子財布を特定するために「識別」される「認証情報」として相違点に係る構成とすることは、当業者が適宜なし得たことである。
　そして、本願発明１の奏する作用効果は、引用発明の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。
　したがって、本願発明１は、引用発明に基づいて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないものである。
５　まとめ
　以上のとおり、本願発明１は、特許法第２９条第２項の規定により特許を受けることができないものである。
第４　むすび
　以上のとおり、本願発明１は、特許法第２９条第２項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。
　よって、結論のとおり審決する。