• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06Q
審判 査定不服 4号2号請求項の限定的減縮 特許、登録しない。 G06Q
管理番号 1352561
審判番号 不服2017-19562  
総通号数 236 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-08-30 
種別 拒絶査定不服の審決 
審判請求日 2017-12-28 
確定日 2019-06-12 
事件の表示 特願2014-513661「電子財布を経た支払いのためのシステム」拒絶査定不服審判事件〔平成24年12月 6日国際公開、WO2012/166790、平成26年 8月14日国内公表、特表2014-519657〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、2012年(平成24年)5月30日(パリ条約による優先権主張外国庁受理2011年5月31日、米国、2011年6月13日、米国)を国際出願日とする出願であって、平成28年3月14日付けで拒絶の理由が通知され、これに対して、同年9月15日に意見書及び手続補正書が提出された後、平成29年2月23日付けで改めて拒絶の理由が通知され、これに対して、同年8月23日に意見書及び手続補正書が提出されたが、同年9月4日付けで拒絶の査定がなされ、同拒絶査定の謄本が請求人に送達された。
これに対して、同年12月28日に拒絶査定不服審判の請求がなされ、それと同時に手続補正がなされたものである。


第2 平成29年12月28日にされた手続補正についての補正の却下の決定

[補正の却下の決定の結論]
平成29年12月28日にされた手続補正(以下、「本件補正」という。)を却下する。

[理由]
1 本件補正について
本件補正は、補正前の請求項1の記載を、以下のように、補正後の請求項1の記載とする補正を含むものである。

(補正前の請求項1)
【請求項1】
コンピュータによって実行される方法であって:
電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること;
前記電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別すること;
前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること;および、
前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること、
を含む方法。

(補正後の請求項1)
【請求項1】
コンピュータによって実行される方法であって:
電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること;
前記電子バリュートークン取引コンピュータにより、前記支払取引に関係する第1の小売商を識別すること;
前記電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別すること;
前記電子バリュートークン取引コンピュータにより、前記電子財布内の第2の小売商に関係し前記第1の小売商によって受け付けられない、第1のバリュートークンを識別すること;
前記電子バリュートークン取引コンピュータにより、前記第1のバリュートークンを、前記第1の小売商に受け付けられ前記電子財布内に存在しない第2のバリュートークンと交換すること;および、
前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記第2のバリュートークンの少なくとも一部を充てること、
を含む方法。

2 本件補正の目的について
(1)本件補正は、請求項1について、以下の補正事項1ないし4を含む。

＜補正事項1＞
「コンピュータによって実行される方法」に含まれるステップ(手順)として、「前記電子バリュートークン取引コンピュータにより、前記支払取引に関係する第1の小売商を識別すること」を追加する補正事項。

＜補正事項2＞
電子バリュートークン取引コンピュータが識別する「バリュートークン」を、「第2の小売商に関係し前記第1の小売商によって受け付けられない、第1のバリュートークン」に限定する補正事項。

＜補正事項3＞
「コンピュータによって実行される方法」に含まれるステップ(手順)として、「前記電子バリュートークン取引コンピュータにより、前記第1のバリュートークンを、前記第1の小売商に受け付けられ前記電子財布内に存在しない第2のバリュートークンと交換すること」を追加する補正事項。

＜補正事項4＞
電子バリュートークン取引コンピュータが支払取引の支払いに充てる「バリュートークン」を、「前記第2のバリュートークン」に限定する補正事項。

(2)検討
ア 補正事項1ないし4は、いずれも請求項1についての補正事項であるから、特許法第17条の2第5項第1号の請求項の削除を目的とするものでなく、また、請求項1における発明特定事項の内容の実質的な変更を伴わないものではないから、同条同項第3号の誤記の訂正又は同条同項第4号の明りようでない記載の釈明を目的とするものでもない。

イ そこで、請求項1についての補正事項1ないし4が、同条同項2号に掲げる事項を目的とするものであるかを検討する。

ウ 第一に、補正事項1ないし3は、いずれも、請求項1に記載された事項について直列的に発明特定事項を追加するものであるから、形式的には、特許請求の範囲の減縮に該当するといえる。しかし、補正事項4は、補正前には、支払いに充てられるものとされていた「前記バリュートークン」、すなわち、「電子財布」が含む「バリュートークン」を、補正後には、「第2のバリュートークン」としており、この「第2のバリュートークン」は、「電子財布内に存在しない」ものである(補正事項3を参照)から、補正後に支払いに充てられるバリュートークンは、補正前のバリュートークンの下位概念となっていない。
よって、請求項1についての補正事項のうちの補正事項4は、特許請求の範囲の減縮に該当しないものである。

エ 第二に、補正事項1と補正事項3は、方法発明である請求項1に係る発明に、それぞれ、「前記電子バリュートークン取引コンピュータにより、前記支払取引に関係する第1の小売商を識別すること」及び「前記電子バリュートークン取引コンピュータにより、前記第1のバリュートークンを、前記第1の小売商に受け付けられ前記電子財布内に存在しない第2のバリュートークンと交換すること」という、方法発明の発明特定事項として独立したステップを新たに追加するものであるから、いずれも発明特定事項を限定するものに該当するものでない。

オ 第三に、補正事項1ないし補正事項4は、補正前には存在していなかった「第1の小売商」と「第2の小売商」の区別と、この区別を前提とした「第2の小売商に関係し前記第1の小売商によって受け付けられない、第1のバリュートークン」と「第1の小売商に受け付けられ」るものである「第2のバリュートークン」の区別を導入し、その上で、「交換する」ステップを導入し、「支払い」に「充てる」ステップを「交換する」ステップを前提とするものへと変更するものである。
これは、要するに、補正前には支払時の両替を可能とするための発明特定事項を含んでいなかったところを、補正後の発明は、支払時の両替を可能とするという課題をこれらを可能とするためのステップによって解決するものとなっているのであるから、いわば補正によって課題と解決手段が追加されたのであるから、補正の前後の課題が同一であるとはいえないものである。
このように、請求項1についての補正事項1ないし4は、総合すると、補正の前後の課題が同一のものに該当しないものである

カ してみると、本件補正における請求項1についての補正は、同条同項第2号に掲げる事項(いわゆる限定的減縮)を目的とするものでない。

キ よって、本件補正のおける請求項1についての補正は、同条同項各号のいずれを目的とするものともしないものであるから、本件補正は、同条同項に規定する要件(いわゆる目的要件)に違反してなされたものである。

3 補正の却下の決定のまとめ

以上のとおりであるから、本件補正は、「2」において上述したとおり、特許法第17条の2第5項各号に掲げる事項を目的とするものではないから、同項の規定する要件(目的要件)に適合するものでない。

したがって、本件補正は、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって、補正の却下の決定の結論のとおり決定する。


第3 本願発明について

1 本願発明

平成29年12月28日にされた手続補正は、上記のとおり却下された。よって、本願の請求項に係る発明は、平成29年8月23日にされた手続補正により補正された特許請求の範囲の請求項1ないし12に記載された事項により特定されるものであるところ、そのうち請求項1に係る発明(以下「本願発明1」という。)は、次のとおりのものである。

【請求項1】
コンピュータによって実行される方法であって:
電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること;
前記電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別すること;
前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること;および、
前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること、
を含む方法。

2 原査定の拒絶の理由

原査定の拒絶の理由は、この出願の請求項1ないし12に係る発明は、本願の優先権主張の日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献1に記載された発明及び引用文献2ないし4に示された周知技術に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない、というものである。

引用文献1:特開2004-133693号公報
引用文献2:特開2003-50959号公報
引用文献3:特開2010-39780号公報
引用文献4:特開2009-223436号公報

3 引用文献

(1)引用文献1
原査定の拒絶の理由に引用された引用文献1には、図面とともに次の事項が記載されている。なお、下線は当審において付加したものである。

ア
「【0018】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
図1は本発明の実施にかかるプリペイド型電子マネー決済システムの構成を示す図である。図示するように、本発明の実施にかかるプリペイド型電子マネー決済システム(以下、「本システム」と称する)10は、プリペイド型電子マネー(以下、「電子マネー」と称する)(A?C)の発行体であるプリペイド業者が有する電子マネー発行サーバ(11a?11c)と、プリペイド事業者と提携して電子マネー発行サーバ(11a?11c)が発行した電子マネーを使用することができる店舗の店舗サーバ20と、ユーザが電子マネーを使用するためのユーザ端末12とはインターネット13に接続されており、相互に各種のデータを授受することができる。
【0019】
電子マネー発行サーバ(11a?11c)は、それぞれ異なる種類の電子マネーを発行を行なう。尚、A発行元サーバが発行するA電子マネーはAプリベイト事業者が提携する店舗でしか利用できない。つまり、電子マネーは発行体であるプリペイド事業者が提携する店舗だけで使用できる。
店舗サーバ20は、ユーザ端末12から購入申し込みがなされた商品を販売し、その商品代金の決済を行うものであり、WWW(Wｏｒld Wide Web)サーバ210、サービスサーバ220、データベースサーバ230を備えて構成されている。
【0020】
WWWサーバ210は、ユーザ端末12から送られてくる各種の情報を受信してサービスサーバ220に渡すと共に、HTML(HｙｐeｒTeｘｔ Maｒkｕｐ Langｕage)で記述されてなるWebページのデータを必要に応じてユーザ端末に宛てて送信する。
【0021】
サービスサーバ220は、ユーザ端末12から送られてくる情報に基づいてデータベースサーバ230に格納されている各種情報を参照して個人認証を行ない、その認証結果に応じて電子商取引の処理を進行させる上で必要となる各種の作業を管理するものであり、顧客管理部221、課金決済管理部223、注文管理部234、配信管理部225を備えて構成されている。
【0022】
顧客管理部221は、本システムを利用するユーザの個人認証に関する各種処理を管理するものであり、ユーザ登録部221a、ユーザ認証部221bに大別される。
【0023】
ユーザ登録部221aは、本システムを新規に利用するユーザについての個人種情報をユーザ情報データベース(以下、「ユーザ情報DB」と称す)231に登録する処理、並びにユーザが所有している電子マネー情報をユーザ別残高データベース(以下、「ユーザ別残高DB」と称す)232に登録する処理を行なう。
【0024】
ユーザ認証部221bは、ログインのために店舗サーバへのアクセスを行ってきたユーザ端末12を操作するユーザの個人認証をユーザ情報DB231に登録されている個人情報との照合処理の実行し、処理結果を注文管理部234に渡す。」

イ
「【0028】
本システム10は以上のように構成されている。
なお、図1に示した本システム10の構成のうち、サービスサーバ22のユーザ管理部221、課金決済部222、注文管理部223、及び配信管理部224は、標準的な構成を有するコンピュータ、すなわち、制御プログラムを実行することで各構成要素を制御するCPUと、ROMやRAM及び磁気記録装置などからなり、CPUに各構成要素を制御させる制御プログラムを実行する際のワークエリアあるいは各種データの記憶領域として使用される記憶部と、ユーザによる操作に対応する各種のデータが取得される入力部と、ディスプレイなどに各種のデータを表示してユーザに通知する出力部と、ネットワークに接続するインタフェース機能を提供するI/F部とを備えるコンピュータで構成することもできる。
【0029】
次に、データベースサーバ23が備えている各データベースのデータ構造について図2?図6を参照しながら説明する。
【0030】
図2はユーザ情報DB231のデータ構造を示す。ユーザ情報DB231には、各ユーザに割り当てられているユーザ毎に固有の「ユーザID」、「パスワード」、及びそのユーザの「個人情報」である氏名、住所、電話番号などの各データがユーザ毎に、登録されたユーザを整理するための番号である「ユーザ番号」に関連付けられて蓄積される。
【0031】
図3はユーザ別残高DB232のデータ構造を示す。ユーザ別残高DB232には、ユーザが使用できる各電子マネーを分類するために各電子マネーに付与された「電子マネー名」の単位毎に、電子マネーを識別するためにプリペイド事業者が付与した「発行ID」、ユーザが商品代金として支払うことできる「ポイント数(残高)」、及び支払に用いる順番を示す「優先順位」、及び各電子マネーのポイント数(残高)を合算した「合算残高」、支払順位がユーザ指定か否かを示す「順位フラグ」の各データが関連付けられて「ユーザ番号」毎に蓄積される。ここでは、店舗サーバ20は提携しているプリペイド事業者が発行する電子マネーA?Cの3種類の電子マネーを取り扱っている。」

ウ
「【0036】
以下、本システムの店舗サーバ20において実行される、ユーザによる商品購入申し込みから購入商品の代金決済に至る処理の流れを図8に示すフローチャートを参照しながら説明する。
同図にフローチャートで示された一連の処理は、ユーザがWWWブラウザ(図示せず)を操作することによってユーザ端末12から送信されるサービス要求をWWWサーバ21が受信することにより開始される。
なお、ここでは、登録されたユーザの一人であるユーザYYY(ユーザ番号0003)を例にして説明する。また、このユーザ番号に基づいて店舗サーバ20における各処理の各種データの授受が行われることを前提として説明する。
【0037】
まず、S101では、ユーザからの要求の内容が商品購入サービスへの要求を示すものであったか否かの判定を行う。
S102では、S101の判定がYeｓならば、その要求の内容にログインを要求するユーザIDとパスワードが含まれているか否かの判定を行う。S102の判定がYeｓならば、S103でユーザ認証処理が実行される。
【0038】
S103では、ユーザ管理部221のユーザ認証部222bが、受信したユーザID及びパスワードに該当するユーザID及びパスワードがユーザ情報DB231に蓄積されているか否かのユーザ認証処理を行なう。
【0039】
S104では、S103のユーザ認証処理の結果が認証OKであったときにはログインが許可され、ユーザ認証部222bはログイン許可通知を注文管理部223に渡す。ユーザ認証結果がNｏならば、S105に進む。
S105でユーザ認証失敗Webページを要求元のユーザ端末12に送信を行なう。
・・・(中略)・・・
【0043】
S109では、S104、又はS108で処理が終了すると、ログインが許可されたとして、ユーザ管理部221からログイン許可の通知を受け取ったサービスサーバ22の注文管理部223が、図10に例示するような表示画面(購入申込画面)が表示されるWebページを表現するHTML文書データを商品情報DB234に格納されている種々の商品情報に基づいて作成する。作成されたデータはWWWサーバ21に送られて要求元のユーザ端末12に送出される。
【0044】
S110では、サービスサーバ22の注文管理部223において、ユーザ端末12で受信されて当該画面が表示され、ユーザがユーザ端末12を操作して該画面に表示されている商品リストのうち購入したい商品に対応する購入申込記入欄をチェックして「OK」なるボタンを操作したときにユーザIDと購入したい商品として購入申込がなされた商品のデータ(商品番号)が、ユーザ端末12から送られてWWWサーバ21が受信したか否かの判別を行なう。その判別結果がYeｓならば、S111に進む。判別結果がNｏならば、ユーザにより指定された商品のデータがユーザ端末12から送られるまで待つ。
【0045】
S111では、S110でユーザ端末12から送られた購入申込がなされた商品のデータ(商品番号)を基にして該当する商品名とその販売額を商品情報DB234から取得して課金決済管理部222に渡す。課金決済管理部222では渡された商品名とその販売額の各データを内部メモリ(図示せず)に一時的に格納を行なう。商品名と販売額の各データの格納が完了すると処理がS112に進む。
【0046】
S112では、課金決済管理部222がユーザ別残高DBに蓄積されている各電子マネーにそれぞれ対応する電子マネー発行サーバ宛てに残高照合の要求を実行する。この残高照合処理の詳細な動作についての説明は後述する。
【0047】
S113では、課金決済管理部222においてS112で取得した各電子マネー毎の残高の合算残高がS111で取得して内部メモリに格納されている商品の販売額以内にあるか否かの判別を行なう。この判別結果がYeｓならば、使用できる電子マネー残高合計額で商品の代金額を支払できる通知を注文管理部223に渡し、S115に進む。判別結果がNｏならば、使用できる電子マネー残高合計額が商品の代金額に不足している通知を注文管理部223に渡し、S114に進む。
【0048】
S114では、残高不足通知を受けた注文管理部223において、図11に例示するような表示画面(残高不足通知画面)が表示されるWebページを表現するHTML文書データを、課金決済管理部22が管理する内部メモリに格納されている商品の販売額とユーザ別残高DB232に蓄積されている各電子マネー残高の各データに基づいて作成する。作成されたデータをWWWサーバ21に渡して、商品購入申込元のユーザ端末12に送る。
【0049】
S115では、支払可能通知を受けた注文管理部223において、図12に例示するような表示画面(購入申込確認画面)が表示されるWebページを表現するHTML文書データを、課金決済管理部22が管理するユーザ別残高DB232から取得し、取得した各データに基づいて作成する。作成されたデータをWWWサーバ21に渡して、商品購入申込元のユーザ端末12に送る。
【0050】
S116では、注文管理部223において、ユーザ端末12で受信されて画面(購入申込確認画面)が表示され、ユーザがユーザ端末12を操作して該画面に表示されている指示に従って支払形式、支払順の入力欄に入力した後、「OK」なるボタンを操作したときに入力した支払形式、支払順の各データが、ユーザ端末12から送られてWWWサーバ21が受信したか否かの判別を行なう。その判別結果がYeｓならば、S111に進む。判別結果がNｏならば、ユーザにより指定された商品のデータがユーザ端末12から送られるまで待つ。
【0051】
S117では、S116で受信した支払形式、支払順の各データを受注管理部223は課金決済管理部222に渡す。課金決済管理部222において渡された支払形式、支払順の各データをユーザ別残高DB232の対応する項目に蓄積を行なった後、蓄積終了の通知を注文管理部223に戻す。そして、注文管理部223は内部メモリに格納しておいた購入申込がなされた商品番号を配信管理部224に渡し、商品番号を渡された配信管理部224は、商品番号に該当するデジタルコンテンツデータを購入申込先のユーザ端末に配信(ダウンロード)を行なう。
【0052】
S118では、S117における購入申込の商品(デジタルコンテンツ)の配信処理が完了すると配信した商品の課金処理を行なう。この課金処理の動作についての説明は後述する。この課金処理が完了するとS119の処理に進む。
S119では、S118で課金処理における課金対象となった各電子マネーの発行体であるプリペイド事業者との間における決済処理が行われる。」

エ
「【0060】
以上までの処理が残高照合処理である。
次に、図8にS118として示されている課金処理の詳細について説明する。
図14は課金処理の処理内容を示すフローチャートである。
この処理は、S117の処理で購入申込されたデジタルコンテンツを購入申込元のユーザ端末12への送信が完了した後に行なわれる処理で、ユーザ宛に納品した商品商品の代金を充当できる電子マネーに対する課金処理を行うものである。
【0061】
まず、S301では、課金決済管理部222は商品代金ポイント数の獲得を注文管理部223に要求し、注文管理部223から商品代金ポイント数Pの取得が行われる。
【0062】
S302では、ユーザ別残高DB232における順位フラグが「1」に設定されているか否かを判別する。順位フラグはユーザが支払優先順位を指定した際に設定されるもので、順位フラグが「1」であれば、S305の処理に進む。順位フラグが「0」ならばユーザが支払優先順位を指定していないと見なしてS303の処理に進む。
S303では、課金決済管理部222はユーザ別残高DB232の各電子マネーの残高が比較される。
【0063】
S304では、S303の処理での結果に基づいて、残高が少ない順に支払順番号を対応する電子マネーに付与してユーザ別残高DB232に格納される。ここで図3に示すように、A電子マネー、B電子マネー、C電子マネーの各残高は350、50、170の各ポイントであるので、支払優先順位は「1」位:B電子マネー、「2」位:C電子マネー、「3」位」:A電子マネーの順となる。
【0064】
S305では、課金決済管理部222はユーザ別残高DBからユーザ番号に該当する各電子マネーの発行IDを読み出して、それら各発行IDを電子マネー名に対応する課金DB233にそれぞれ格納される。
【0065】
S306では、ユーザ別残高DB232内の電子マネー残高情報が格納されている項目番号である変数Sに初期値「1」が代入される。
S307では、変数Sの番号であるS番目の電子マネーの残高ポイント数Pｔが商品代金ポイント数PSを超えているか否かを判別する。その判別の結果、YeｓならばS番目の電子マネー残高だけで商品代金を充足することができると見なしてS308の処理に進み、NｏならばS番目の電子マネー残高だけでは商品代金を充足できないものとしてS309の処理に進む。
【0066】
S308では、S番目の電子マネーの全残高Pｔを課金DB233にS番目の電子マネー名に対応付けて格納させる。
一方、S307の判別処理の結果がNｏであったときには、S309?S314の一連の処理において、課金決済管理部222aにおける電子マネーの残高における商品代金の不足分を使用できる他の電子マネーの残高を加算して充足させる処理が行われる。」

したがって、上記引用文献1には次の発明(以下、「引用発明」という。)が記載されていると認められる。

「電子マネー発行サーバ(11a?11c)と、電子マネー発行サーバが発行した電子マネーを使用することができる店舗の店舗サーバ20と、ユーザが電子マネーを使用するためのユーザ端末12とが接続された、プリペイド型電子マネー決済システム10(【0018】)、であって、
前記電子マネー発行サーバ(11a?11c)は、それぞれ異なる種類の電子マネーの発行を行い、A発行元サーバが発行するA電子マネーはAプリベイト事業者が提携する店舗でしか利用できないものであり(【0019】)、
前記店舗サーバ20は、WWWサーバ210、サービスサーバ220、データベースサーバ230を備えて構成されており(【0019】)、
前記サービスサーバ220は、顧客管理部、課金決済管理部、注文管理部、配信管理部を備えて構成されるものであって(【0021】)、

ユーザ管理部221(「顧客管理部221」の誤記と認められる)、課金決済部222(「課金決済管理部222」の誤記と認められる)、注文管理部223、及び配信管理部224は、標準的な構成を有するコンピュータで構成されており(【0028】)、
データベースサーバ23が備えているユーザ情報DB231には、各ユーザに割り当てられているユーザ毎に固有の「ユーザID」、「パスワード」などの各データが、登録されたユーザを整理するための番号である「ユーザ番号」に関連付けられて蓄積されており(【0030】)、
データベースサーバ23が備えているユーザ別残高DB232には、ユーザが使用できる各電子マネーを分類するために各電子マネーに付与された「電子マネー名」の単位毎に、ユーザが商品代金として支払うことできる「ポイント数(残高)」、及び支払に用いる順番を示す「優先順位」の各データが関連付けられて「ユーザ番号」毎に蓄積されている(【0029】【0031】)システムの店舗サーバ20において実行される、ユーザによる商品購入申し込みから購入商品の代金決済に至る一連の処理(【0036】)に係る方法において、
ユーザ端末12から送信されるサービス要求をWWWサーバ21が受信することにより開始され(【0036】)、
ユーザからの要求の内容が商品購入サービスへの要求を示すものである場合には、ユーザ管理部221のユーザ認証部222bが、受信したユーザID及びパスワードに該当するユーザID及びパスワードがユーザ情報DB231に蓄積されているか否かのユーザ認証処理を行ない(【0037】【0038】)、
ユーザ認証処理の結果が認証OKであったときにはログインが許可され(【0039】)、
注文管理部223が、表示画面(購入申込画面)が表示されるWebページを表現するHTML文書データを作成し、作成されたデータはユーザ端末12に送出され(【0043】)、
ユーザがユーザ端末12を操作して該画面に表示されている商品リストのうち購入したい商品に対応する購入申込記入欄をチェックして「OK」なるボタンを操作したときにユーザIDと購入したい商品として購入申込がなされた商品のデータ(商品番号)が、ユーザ端末12から送られ(【0044】)、

ユーザ端末12から送られた購入申込がなされた商品のデータ(商品番号)を基にして該当する商品名とその販売額を商品情報DB234から取得して課金決済管理部222に渡し、課金決済管理部222では渡された商品名とその販売額の各データを内部メモリに一時的に格納を行い(【0045】)、
注文管理部223において、表示画面(購入申込確認画面)が表示されるWebページを表現するHTML文書データを作成し、作成されたデータを、商品購入申込元のユーザ端末12に送り(【0049】)、
ユーザがユーザ端末12を操作して該画面に表示されている指示に従って支払形式、支払順の入力欄に入力した後、「OK」なるボタンを操作したときに入力した支払形式、支払順の各データが、ユーザ端末12から送られてWWWサーバ21が受信すること(【0050】)、

受信した支払形式、支払順の各データを受注管理部223(「注文管理部223」の誤記と認められる)は課金決済管理部222に渡し、課金決済管理部222において渡された支払形式、支払順の各データをユーザ別残高DB232の対応する項目に蓄積を行なった後、蓄積終了の通知を注文管理部223に戻し、注文管理部223は内部メモリに格納しておいた購入申込がなされた商品番号を配信管理部224に渡し、配信管理部224は、商品番号に該当するデジタルコンテンツデータを購入申込先のユーザ端末に配信(ダウンロード)を行うこと(【0051】)、

商品(デジタルコンテンツ)の配信処理が完了すると配信した商品の課金処理を行うものであって(【0052】)、
注文管理部223から商品代金ポイント数Pの取得が行われ(【0061】)、
課金決済管理部222はユーザ別残高DBからユーザ番号に該当する各電子マネーの発行IDを読み出して、それら各発行IDを電子マネー名に対応する課金DB233にそれぞれ格納し(【0064】)、
ユーザ別残高DB232内の電子マネー残高情報が格納されている項目番号である変数Sに初期値「1」が代入され、S番目の電子マネーの残高ポイント数Pｔが商品代金ポイント数PSを超えているか否かを判別すること(【0065】)、

その判別の結果、YeｓならばS番目の電子マネー残高だけで商品代金を充足することができると見なし、S番目の電子マネーの全残高Pｔを課金DB233にS番目の電子マネー名に対応付けて格納させること(【0065】-【0066】)、
を含む方法。」

4 対比・判断

(1)本願発明1と引用発明との対比

引用発明の、各電子マネーの「電子マネー名」単位毎に蓄積された「ポイント数(残高)」は、商品代金の支払いに用いることができる価値を示すものであって、本願発明1の「電子バリュートークン」に相当する。また、引用発明は、この電子バリュートークンを、店舗サーバが備えるデータベースサーバが備えるユーザ別残高DBにおいて「電子マネー名」単位に蓄積しており、このユーザ別残高DB(の各電子マネー名が示す項目)は、電子バリュートークンを示すデータを電子的に維持(本願明細書【0011】)するものであるから、このユーザ別残高DBにおいてユーザ毎(ユーザ番号毎)に区別される情報は、本願発明1の「電子財布」に相当する。
また、引用発明においては、「電子マネー発行サーバ(11a?11c)」が「それぞれ異なる種類の電子マネーを発行」することから、引用発明の「電子マネー発行サーバ」は本願発明1の「電子バリュートークン発行者認証システム」に相当する。
そして、引用発明の「店舗サーバ」は、「電子マネー発行サーバ」とは異なるものであって、当該「店舗サーバ」において「ユーザによる商品購入申し込みから購入商品の代金決済に至る一連の処理」が実行され、また、前記「店舗サーバ」を構成する「サービスサーバ」は「標準的な構成を有するコンピュータで構成され」ていることから、引用発明の「店舗サーバ」は本願発明1の「電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータ」に相当する。

次に、本願発明1を以下に示すA?Eに分節して検討する。

A
コンピュータによって実行される方法であって:

B
電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること;

C
前記電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別すること;

D
前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること;および、

E
前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること、

A
を含む方法。

＜本願発明1の各分節についての検討＞

A
「コンピュータによって実行される方法であって:」
「を含む方法。」について

引用発明は「店舗サーバ」によって実行される方法であって、当該「店舗サーバ」は上記のとおり「標準的な構成を有するコンピュータで構成され」ていることから、引用発明は、本願発明1の「コンピュータによって実行される方法」に相当する。

B
「電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること;」について

上記Bについては、以下のB-1、B-2、B-3に分けて検討する。

B-1
「電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、」「要求を受信すること;」について

引用発明における、商品の代金を充当できる電子マネーに対する課金処理は、商品の代金の支払取引のために電子財布(ユーザ別残高DBにおいてユーザ毎(ユーザ番号毎)に区別される情報)の各電子マネーの残高ポイント数Pｔを課金DBに格納させ残高ポイント数Pｔを減少させているから、本願発明1の「電子財布に対する支払取引」に相当する。
そして、引用発明では、商品を購入して代金を支払おうとするユーザによる「購入申込確認画面(図12)」が表示されたユーザ端末に対する操作、具体的には、「購入申込確認画面(図12)」の支払形式の入力欄及びユーザが所有する複数の電子マネーの電子マネー名及び残高に対応して表示される支払順の入力欄への入力と「OK」ボタンの操作、によってこのユーザ端末から送信される「支払形式、支払順の各データ」を受けて当該商品の代金を充当できる電子マネーに対する課金処理がなされるところ、この「支払形式、支払順の各データ」は、代金を支払おうとするユーザからの「電子財布に対する支払取引」に対する要求を示すものであるから、本願発明1の「電子財布に対する支払取引を処理するための要求」に相当する。

よって、引用発明は、本願発明1の「電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、」「要求を受信すること;」に相当する構成を備えている。

B-2
「前記電子財布は複数の電子財布とともにデータベースに記憶され」について

引用発明においては、「ユーザ別残高DB232には・・・各電子マネーに付与された「電子マネー名」の単位毎に、・・・「ポイント数(残高)」・・・の各データが関連付けられて「ユーザ番号」毎に蓄積され」ている、すなわち、「ユーザ別残高DB」(本願発明1の「データベース」に相当)に「電子マネー」の「ポイント数(残高)」などが「「ユーザ番号」毎に蓄積され」ている。
ここで、引用発明において、「ユーザ別残高DB」に「「ユーザ番号」毎に蓄積され」ているということは、あるユーザの「電子マネー」の「ポイント数(残高)」が、他のユーザの「電子マネー」の「ポイント数(残高)」とともに「ユーザ別残高DB」に記憶されているということであるから、引用発明は、本願発明1の「前記電子財布は複数の電子財布とともにデータベースに記憶され」に相当する構成を備えている。

B-3
「前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む」について

引用発明においては、上記のとおり、「ユーザ別残高DB232には・・・各電子マネーに付与された「電子マネー名」の単位毎に、・・・「ポイント数(残高)」・・・の各データが・・・蓄積され」ていることから、引用発明のユーザ別残高DBにおいてユーザ毎(ユーザ番号毎)に区別される情報(本願発明1の「電子財布」に相当)は、複数の「ポイント数(残高)」(本願発明1の「バリュートークン」に相当)を含んでいる、すなわち、引用発明は、本願発明1の、「前記電子財布は」「複数のバリュートークンを含む」、に相当する構成を備えている。
また、引用発明は、「電子マネー発行サーバ(11a?11c)は、それぞれ異なる種類の電子マネーの発行を行い、A発行元サーバが発行するA電子マネーはAプリベイト事業者が提携する店舗でしか利用できないもの」であることから、引用発明の「各電子マネー」は各々の「プリペイド事業者」によって「発行」されるもの、すなわち、引用発明の「各電子マネー」の「ポイント数(残高)」は、本願発明1の「複数の発行者によって発行された複数のバリュートークン」に相当すると認められる。
よって、引用発明は、本願発明1の「前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む」に相当する構成を備えている。

C
「前記電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別すること;」について

本願発明1は、「前記要求の認証情報」、つまり、電子財布に対する支払取引を処理するための要求の認証情報、を「識別」しており、支払取引の対象となる電子財布は、電子財布に対する支払取引を処理するための要求に含まれる認証情報を識別することによって特定される。
これに対して、引用発明の、支払取引を処理するための要求は、「支払形式、支払順の各データ」であって、支払取引の対象となる電子財布における支払優先順位を指定可能であり、「購入申込確認画面(図12)」における、支払形式の入力欄及びユーザが所有する複数の電子マネーの電子マネー名及び残高に対応して表示される支払順の入力欄に入力された内容を示すデータであって、支払取引の対象となる電子財布に対応する電子マネーの認証のために識別される情報(認証情報)を含んでいるか否か、明示されていない。
よって、この点は、相違点である。

D
「前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること;」について

引用発明では、「店舗サーバ」により「S番目の電子マネーの残高ポイント数Pｔが商品代金ポイント数PSを超えているか否かを判別する」ことから、引用発明は、本願発明1の「前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること」に相当する構成を備えている。

E
「前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること;」について

引用発明では、「店舗サーバ」により「S番目の電子マネーの全残高Pｔを課金DB233にS番目の電子マネー名に対応付けて格納させる」ことから、引用発明は、本願発明1の「前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること」に相当する構成を備えている。

(2)本願発明1と引用発明との一致点・相違点
以上のことから、本願発明1と引用発明との一致点及び相違点は、次のとおりである。

＜一致点＞
「コンピュータによって実行される方法であって:
電子バリュートークン発行者認証システムとは異なる電子バリュートークン取引コンピュータにより、電子財布に対する支払取引を処理するための要求を受信することであって、前記電子財布は複数の電子財布とともにデータベースに記憶され、前記電子財布は複数の発行者によって発行された複数のバリュートークンを含む、要求を受信すること;
前記電子バリュートークン取引コンピュータにより、前記電子財布内のバリュートークンを識別すること;および、
前記電子バリュートークン取引コンピュータにより、前記要求の少なくとも一部の支払いに、前記バリュートークンの少なくとも一部を充てること、
を含む方法。」

＜相違点＞
本願発明1は、「電子バリュートークン取引コンピュータにより、前記要求の認証情報を識別する」のに対し、引用発明では、「前記要求(電子財布に対する支払取引を処理するための要求)」に含まれる「支払順」により電子財布の支払優先順位が指定されるものの、「前記要求(電子財布に対する支払取引を処理するための要求)」の「認証情報」を「識別」していない点。

(3)相違点についての判断
以下、上記相違点について検討する。

引用発明の「支払形式、支払順の各データ」のうちの「支払順」は、「購入申込確認画面(図12)」においてユーザが所有する複数の電子マネーの電子マネー名及び残高に対応して表示される支払順の入力欄に入力された支払優先順位を示すものであって、これによってユーザが所有する複数の電子マネーに対応する複数の電子財布の集合のうちから特定の電子財布が一意に特定される情報である。
そして、引用発明の電子バリュートークン取引コンピュータ(店舗サーバ)が受信した「支払形式、支払順の各データ」を用いた処理を行うためには、受信したデータが、「購入申込確認画面(図12)」が表示されたユーザ端末(パスワード認証がなされたユーザによって用いられ、このユーザが所有するものとして登録された複数の電子マネーの電子マネー名及び残高が示された「購入申込確認画面(図12)」が表示されたユーザ端末)から受信されたものであることを示す情報、いうなれば、「購入申込確認画面(図12)」の表示と「支払形式、支払順の各データ」の受信がユーザによるパスワード認証から続く一連の認証セッション中のものであることを示す情報、を含む又は伴うことが必要であって、電子バリュートークン取引コンピュータ(店舗サーバ)が、「支払順」に基づいて支払取引の対象となる電子財布を特定するにあたって、この情報を用いて支払順によって支払優先順位が決定されるべき「購入申込確認画面(図12)」に表示された複数の電子マネーに対応する複数の電子財布の集合を特定していることは、引用文献1に明示されていなくとも当然のことである。(なお、この情報は、店舗サーバにおいてパスワードと対応されているのであれば、このユーザ端末のIPアドレスやMACアドレスのような、WWWサーバへの通信に伴うもので構わないものである。)つまり、引用発明の「支払形式、支払順の各データ」は、「支払形式」や「支払順」のみならず、ユーザによるパスワード認証から続く一連の認証セッション中のものであることを示す情報をも含むか又は伴っているのであり、この情報と「支払順」とが相俟って、認証されたユーザが所有する複数の電子マネーに対応する複数の電子財布の集合から支払優先順位に応じた電子財布(及び各々の電子財布に対応する「発行ID」)を支払取引の対象として特定しているものである。
以上を踏まえれば、引用発明における電子財布に対する支払取引を処理する電子バリュートークン取引コンピュータ(店舗サーバ)において、「支払形式、支払順の各データ」が含む又は伴う、パスワード認証から続く一連の認証セッション中のものであることを示す情報と「支払順」を併せた情報を、支払取引の対象となる電子財布を特定するために「識別」される「認証情報」として相違点に係る構成とすることは、当業者が適宜なし得たことである。
そして、本願発明1の奏する作用効果は、引用発明の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。

したがって、本願発明1は、引用発明に基づいて、当業者が容易に発明をすることができたものであり、特許法第29条第2項の規定により特許を受けることができないものである。

5 まとめ
以上のとおり、本願発明1は、特許法第29条第2項の規定により特許を受けることができないものである。


第4 むすび
以上のとおり、本願発明1は、特許法第29条第2項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。

よって、結論のとおり審決する。
 
別掲
 
審理終結日 2019-01-15 
結審通知日 2019-01-16 
審決日 2019-01-30 
出願番号 特願2014-513661(P2014-513661)
審決分類 P 1 8・ 572- Z (G06Q)
P 1 8・ 121- Z (G06Q)
最終処分 不成立  
前審関与審査官 阿部 潤  
特許庁審判長 渡邊 聡
特許庁審判官 田中 秀樹
相崎 裕恒
発明の名称 電子財布を経た支払いのためのシステム  
代理人 特許業務法人浅村特許事務所  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ