• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G06Q
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06Q
管理番号 1384714
総通号数
発行国 JP 
公報種別 特許審決公報 
発行日 2022-06-24 
種別 拒絶査定不服の審決 
審判請求日 2020-12-24 
確定日 2022-06-14 
事件の表示 特願2019− 21708「情報処理方法、情報処理装置、及び情報処理プログラム」拒絶査定不服審判事件〔令和 2年 8月27日出願公開、特開2020−129281、請求項の数(12)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、平成31年2月8日の出願であって、令和2年5月21日付けで拒絶理由通知がされ、同年7月22日に手続補正がされ、同年10月6日付けで拒絶査定(原査定)がされ、これに対し、同年12月24日に拒絶査定不服審判の請求がされ、令和4年2月3日付けで当審より拒絶理由が通知され、同年3月9日に手続補正がされたものである。

第2 本願発明
本願請求項1−12に係る発明(以下、それぞれ「本願発明1」−「本願発明12」という。)は、令和4年3月9日にされた手続補正により補正された特許請求の範囲の請求項1−12に記載された事項により特定される発明であり、本願発明1は以下のとおりの発明である。

「【請求項1】
情報処理装置が、
個人間送金サービスを提供する処理と、
第1ユーザが利用する第1情報処理端末から、前記個人間送金サービスにおいて第1ユーザへの所定の請求額の送金を依頼するための送金リクエストを受信する処理と、
前記送金リクエストを第2ユーザが利用する第2情報処理端末に送信する処理と、
前記第2ユーザのアカウントの残高が前記請求額より少ない場合に、前記第2ユーザのアカウントに対して、前記請求額と前記残高との差額を、前記情報処理装置を運営する事業者を債権者とする後払いサービスにより補填して、前記送金リクエストの前記請求額を前記第1ユーザのアカウントの残高に加算する決済を行う処理と、を実行する情報処理方法。」

なお、本願発明2−12の概要は以下のとおりである。
本願発明2−10は、本願発明1を減縮した発明である。
本願発明11、12は、それぞれ本願発明1に対応する装置及びプログラムの発明であり、本願発明1とカテゴリ表現が異なるだけの発明である。

第3 引用文献、引用発明等
1.引用文献1について
原査定の拒絶の理由に引用された引用文献1(特開2003−157363号公報)には、図面とともに次の事項が記載されている。

「【0005】【発明が解決しようとする課題】本発明の目的は、上記のような不都合を解決し、融資業務が制限されている決済専門金融機関であっても、預金残高不足の際の引き落とし不能を防止し、顧客の不都合を解消するための決済システムを提供することを目的とする。」

「【0016】【発明の実施の形態】図1を参照して本発明の決済システムの例を説明する。本例の決済システムは、金融機関10に設けられた口座サーバ12と貸金業者30に設けられたクレジットサーバ32とを有し、両者は通信手段によって接続されている。通信手段は、インターネット等の通信ネットワーク回線、電話回線、専用回線等を含むが、好ましくは、オンライン用の専用回線が使用される。金融機関10は、銀行、信用金庫、郵便局、協同組合等の預金業務を行なうものであればよい。しかしながら、本発明では、特に、融資業務を行なわない決済専門銀行が好適である。貸金業者30は、貸金又は融資業務の資格又は免許を有するものであればよく、例えば、クレジットカード発行会社、消費者金融、商工ローン等の各種の金融会社を含む。金融機関10の口座サーバ12は顧客20の口座14の入金、出金、自動振込み、自動引き落し等を管理する。クレジットサーバ32も同様に顧客20の貸金残高、入金、返済金の支払い条件等を管理する。
【0017】口座サーバ12は更に顧客20の携帯電話22の番号を記憶している。金融機関10は、携帯電話22を介して顧客20との間で直接的に且つリアルタイムにて、情報交換をする。例えば、顧客20の預金残高が不足した場合、それを顧客に通知するから、顧客20は預金残高の不足が発生していることをリアルタイムにて知ることができる。更に、金融機関10は、顧客20に対して貸金業者に融資を申し込むべきか否かを問い合わせる。したがって、顧客が知らない間に、貸金業者に対する借金が増加することが防止される。尚、以下に、携帯電話22を例として説明するが、携帯電話の代わりに固定電話が使用されてよい。
【0018】図2に示すように、口座サーバ12は、顧客の口座番号及び電話番号とそれに対応付けられた貸金業者のカード番号等を記憶する記憶部121と、顧客の口座からの引き落としの要求があったときに、預金残高と引き落とし金額とを照合する照合部122と、照合部による照合の結果、預金残高不足と判定されたときに、貸金業者に融資又はキャッシングを依頼するためのクレジット決済部123と、顧客及び貸金業者と交信するための送受信部124と、これらを制御する制御部125とを有する。送受信部124は、例えばCAFIS(Credit and Finance InformationSwitching System)等の貸金業者との間でオンライン通信をするためのオンライン端末機の機能を有する。
【0019】図3を参照して本発明の決済方法の第1の例を説明する。本例の決済方法は先ずステップS101にて、口座サーバ12は顧客の口座14からの引き落としの要求を受信する。口座からの引き落としがなされる場合の例として、上述のように、公共料金、住宅又は事業ローンの返済金、自動車等の月賦金等の自動振込みがある。尚、ここに、引き落しには、現金自動支払機(ATM)を利用した現金の引き出し等も含まれるものとす
る。
【0020】次にステップS102にて、顧客の預金残高と引き落し金額の照合がなされる。これは上述のように照合部122にてなされる。引き落し金額が顧客の預金残高を超えない場合には、決済可能と判定され、ステップS108に進み、顧客の口座からの引き落しがなされる。
【0021】引き落とし金額が顧客の預金残高を超える場合には、決済不能と判定され、ステップS103に進む。金融機関10は顧客20の携帯電話22に預金残高が不足し、決済不能である旨を通知する。更に、金融機関10は、顧客20に対して貸金業者に融資を依頼するべきか否かを問う。ステップS104にて顧客20は貸金業者に融資を依頼するか否かを決定する。貸金業者に融資を依頼しないと決定した場合にはステップS110にて、金融機関10は取引を中止する。ステップS104にて顧客20が貸金業者に融資を依頼すると決定した場合には、ステップS105に進む。ステップS105では、金融機関10は、顧客に代わって且つ顧客の名義にて貸金業者30に融資を依頼する。即ち、口座サーバ12より貸金業者30のクレジットサーバ32へ、融資依頼が送信される。ステップS106では、貸金業者は融資又はキャッシングを行う。即ち、貸金業者30から
顧客の口座14に送金がなされる。
【0022】融資又はキャッシングの条件は、貸金業者と顧客の間の契約によって予め決められている。例えば、クレジットカード発行会社の場合は、分割払い、リボルビング、等がある。消費者金融、商工ローン等の場合には、所定の利率による貸し出しとなる。顧客は、貸金業者に対する負債を負う。尚、本実施例では貸金業者30から顧客の口座14に送金がなされることとしているが、貸金業者30が金融機関10に設けられた口座サーバ12に対して図示しない口座を開設し、当該図示しない口座から顧客の口座14に対して振り込みの依頼を行うことにより、決済時間を短縮することができる。
【0023】ステップS107にて、口座サーバ12のクレジット決済部は顧客の口座に入金がなされたことを確認すると、決済可能の信号を生成する。ステップS108にて、顧客の口座からの引き落しがなされる。ステップS109にて、金融機関10は、顧客20に携帯電話22を介して、顧客の口座に入金があり、無事に、口座からの引き落しが完了した旨を報告する。
【0024】図4を参照して本発明の第1の例の変形例を説明する。本例では、金融機関10から顧客20に携帯電話22を介して預金残高の不足が通知されると、顧客20自身が適当な貸金業者30に融資を申し込む。図1及び図3を参照して説明した例では、金融機関10が貸金業者30に融資を申し込んだが、本例では顧客20自身が貸金業者30に融資を申し込む点が異なる。従がって、本例では、顧客が適当な貸金業者を選択することができる利点がある。
【0025】こうして、本例では、顧客20に予め預金残高の不足を通知するから、顧客20は預金残高不足をリアルタイムにて知ることができる。また、貸金業者に対する融資の申し込みも、顧客20の確認の後に行われるから、顧客が知らない間に、貸金業者に対する負債が増加することが防止される。」

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

「融資業務が制限されている決済専門金融機関であっても、預金残高不足の際の引き落とし不能を防止し、顧客の不都合を解消するための決済システムであって、金融機関に設けられた口座サーバと貸金業者に設けられたクレジットサーバとを有し、両者は通信手段によって接続されている、決済システムにおける決済方法であって、
口座サーバは、自動振り込み等に伴う顧客の口座からの引き落としの要求を受信し、
顧客の預金残高と引き落し金額の照合がなされ、
引き落し金額が顧客の預金残高を超えない場合には、決済可能と判定され、顧客の口座からの引き落しがなされ、
引き落とし金額が顧客の預金残高を超える場合には、決済不能と判定され、
金融機関から顧客の携帯電話への、預金残高不足及び決済不能の旨の通知と貸金業者に融資を依頼するべきか否かの問いを受けた顧客が、貸金業者に融資を依頼すると決定した場合には、金融機関は、顧客に代わって且つ顧客の名義にて貸金業者に融資を依頼し、すなわち、口座サーバより貸金業者のクレジットサーバへ融資依頼が送信され、
貸金業者は融資又はキャッシングを行う、すなわち、貸金業者から顧客の口座に送金がなされて、顧客は、貸金業者に対する負債を負うこととなり、
口座サーバは、顧客の口座に入金がなされたことを確認すると決済可能の信号を生成し、顧客の口座からの引き落しがなされ、
金融機関は、顧客に携帯電話を介して顧客の口座に入金があって口座からの引き落しが完了した旨を報告する、方法。」

2.引用文献2について
原査定の拒絶の理由に引用された引用文献2(特開2013−254279号公報)には、図面とともに次の事項が記載されている。

「【0049】・・ところで、図5(F)に示す割り勘承認状況画面には、各利用者の残高確認の結果(上記判定結果)として、残高有を示す情報「OK」が表示されているが、例えば一部の利用者の残高確認の結果として、残高無を示す情報「NG」が表示される場合もありうる。この場合、利用者Aは、残高無の利用者に対して支払い金額に相当する電子マネーのバリューの登録を促し、電子マネーのバリューをマネーサーバSAへ登録させた後、再度、上記ステップS13以降の処理を行わせるようにしてもよい。この構成によれば、代表となる利用者Aは、他の利用者が残高不足になることを防止することができる。或いは、この場合、利用者Aは、残高無の利用者から支払い金額に相当する現金をもらうことで、割り勘承認状況画面で提示された承認状況を了承してもよい。」
「【0052】・・・この割り勘支払い処理では、上記会員IDで特定される利用者それぞれの電子マネーのバリューから当該利用者それぞれの支払い金額に相当するバリューが減算され、上記支払い総額が上記受信された施設IDで特定される店舗の電子マネーのバリューに加算される。例えば、利用者Aの電子マネーのバリューから当該利用者Aの支払い金額(4,500円)に相当するバリューが減算され、利用者Bの電子マネーのバリューから当該利用者Bの支払い金額(4,500円)に相当するバリューが減算され、利用者Cの電子マネーのバリューから当該利用者Cの支払い金額(4,500円)に相当するバリューが減算され、利用者Dの電子マネーのバリューから当該利用者Dの支払い金額(4,500円)に相当するバリューが減算される。そして、上記支払い総額(18,000円)が施設IDで特定される店舗の電子マネーのバリューに加算される。なお、上記支払い総額(18,000円)が施設IDで特定される店舗に対して支払う金額情報として電子マネーデータベース21に登録される場合もある。この場合、電子マネー会社から当該店舗への支払いは、上記支払い総額から手数料を引いた上で、施設の口座へ振込みされる。また、電子マネーのバリュー残高が支払い金額に満たない利用者がいる場合、支払い総額の不足が生じるが、この不足する金額は利用者Aの電子マネーのバリューから減算されるようにするとよい。・・・」

以上の記載によれば、引用文献2には、支払者の口座残高が不足する場合に、入金を促すこと、及び、割り勘金額の支払いができない者に対し、他の者が立て替えることが記載されている。

3.引用文献3について
原査定の拒絶の理由に引用された引用文献3(特開2013−41424号公報)には、図面とともに次の事項が記載されている。

「【0021】管理サーバ100は、アグリゲーション技術を使用した試行に関連して取得された資産情報および債務情報に基づいて、利用者14が所定の返済期間内、例えば10日間程度の間に返済可能な金銭の額すなわち支払い余力を演算する(S218)。管理サーバ100は、演算された支払い余力と不足額とを比較することで利用者14に不足額に相当する金銭を短期的に貸し付けるか否かを判定する(S220)。管理サーバ100は、貸し付けの可否をX銀行サーバ2に専用線32を介して通知する(S222)。貸し付け可と判定された場合、X銀行サーバ2は、引き出しを許可する旨をコンビニATM8に専用線32を介して通知する(S224)と共に、Z事業者の銀行口座から利用者14の銀行口座へ不足額分の振替処理を実行する(S226)。コンビニATM8は引き出し許可の通知を受けると引き出し希望額に相当する現金を払い出す(S228)。利用者14が払い出された現金を受け取ると、コンビニATM8は引き出しセッションを終了する(S230)。すなわち、不足額の通知、アグリゲーション、支払い余力の演算、貸し付け可否の判定はいずれも引き出しセッションが継続している間に行われる。
なお、X銀行サーバ2は、Z事業者の銀行口座から利用者14の銀行口座へ不足額分の振替処理を実行する代わりに、貸し付け可とされたという情報を保持してもよい。」

以上の記載によれば、引用文献3には、資産情報や債務情報に基づいた支払い余力内であれば銀行口座の不足額を自動的に貸し付ける技術が記載されている。

4.引用文献4について
原査定の拒絶の理由に引用された引用文献4(特開2018−32200号公報)には、図面とともに次の事項が記載されている。

「【0156】ステップS313で、端末20AのSNS処理部210は、ユーザから、サーバ10の決済サービスを利用した、トークルームに含まれる他のユーザへの、料金の少なくとも一部の支払い要求操作を受け付ける。
【0157】ステップS314で、端末20AのSNS処理部210は、サーバ10へ、支払い要求を送信する。
【0158】例えば、図13A、図13Bの「割り勘依頼」ボタン561を押下すると、図14の画面が表示される。
【0159】図14は、支払い要求操作を受け付ける際の端末20Aの表示画面の一例である。
【0160】図14Aでは、支払った額や、購入したサービス等の情報が表示される。図14Bでは、トークルームに含まれる他のユーザの一人あたりの支払額が表示されている。なお、図14Bの例では、端末20AのユーザがIABを用いた処理で支払いを済ませているため、割り勘する相手が1人であっても、支払額を2で除算した額が割り勘額として算出される。
【0161】図14Cでは、支払い要求をトークルーム宛てに送信する際に、一緒に送信するメッセージやスタンプを選択できる。また、「割り勘のレシートを一緒に送る」ボタン571を選択すると、相手からもレシートを参照できるようになる。
【0162】ステップS315で、端末20AのSNS処理部210は、端末20Bから、支払い結果を受信し、表示する。
【0163】図14Dでは、端末20Bのユーザへの支払い要求572と、端末20Bのユーザからの支払いが完了した旨の通知573のメッセージとスタンプが表示されている。
【0164】図14Eでは、支払いが完了した旨の通知573をクリックした場合の、通知573の表示例を示す。
【0165】図14Fでは、割り勘のレシートの表示例を示す。」

以上の記載によれば、引用文献4には、所定のサービスに対する支払いを割り勘処理するにあたり、まず代表者が払い、他のユーザへ支払い要求を行うことが記載されている。

5.引用文献5について
原査定の拒絶の理由に引用された引用文献(特開2016−151785号公報)には、図面とともに次の事項が記載されている。

「【0111】また、第2の実施形態に係る決済管理システム1では、割り勘対象の複数のユーザのうちの1以上のユーザが、割り勘金額の支払いを拒否した場合や承認期間を徒過した場合等は、不足分の割り勘金額を取引者ユーザが支払うようにすることができる。」

以上の記載によれば、引用文献5には、割り勘金額の支払いができない者に対し、他の者が立て替えることが記載されている。

6.引用文献6について
原査定の拒絶の理由に引用された引用文献6(齋藤順,どうなるインターネット専業銀行,BUSINESS STANDARD 第1巻 第4号,ソフトバンクパブリッシング株式会社,2001年11月1日,第1巻,p.102−109、摘記省略)には、インターネット銀行において個人間送金サービスが提供されていることが記載されている。

第4 対比・判断
1.本願発明1について
(1)対比
本願発明1と引用発明とを対比すると、次のことがいえる。

引用発明における「顧客」、「携帯電話」は、本願発明1における「第2ユーザ」、「第2ユーザが利用する第2情報端末」に相当する。
引用発明の「自動振り込み等」は、第2ユーザ以外の者への送金処理であり、本願発明1の「送金リクエスト」と引用発明の「自動振り込み等に伴う顧客の口座からの引き落としの要求」は、いずれも、第1ユーザ(第2ユーザ以外の者)への所定の請求額の送金を依頼するための送金リクエストである点で共通するものといえる。

引用発明の、顧客の預金残高と引き落し金額の照合により引き落とし金額が顧客の預金残高を超える場合は、本願発明1の「前記第2ユーザのアカウントの残高が前記請求額より少ない場合」に相当し、引用発明の、融資又はキャッシングによる顧客の口座への送金は、本願発明1の「前記請求額と前記残高との差額」を「補填」する処理に対応し、引用発明の、顧客の口座からの引き落しは、本願発明1の「前記送金リクエストの前記請求額を前記第1ユーザのアカウントの残高に加算する決済」に対応する。

したがって、本願発明1と引用発明との間には、次の一致点、相違点があるといえる。

(一致点)
「情報処理装置が、
第1ユーザが利用する第1情報処理端末から、第1ユーザへの所定の請求額の送金を依頼するための送金リクエストを受信する処理と、
前記第2ユーザのアカウントの残高が前記請求額より少ない場合に、前記第2ユーザのアカウントに対して、前記請求額と前記残高との差額を、補填して、前記送金リクエストの前記請求額を前記第1ユーザのアカウントの残高に加算する決済を行う処理と、を実行する情報処理方法。」

(相違点)
(相違点1)本願発明1は、「個人間送金サービスを提供する処理」を実行するものであって、受信される「送金リクエスト」が「前記個人間送金サービス」において「第1ユーザが利用する第1情報処理端末」からのものであるのに対し、引用発明は、自動振り込み等を実行するものであって個人間送金サービスを提供する処理を実行するものでなく、送金リクエストが自動振り込み等に伴うものであって個人間送金サービスにおいて第1ユーザが利用する第1情報処理端末からのものでない点。
(相違点2)本願発明1は、「前記送金リクエストを第2ユーザが利用する第2情報処理端末に送信する処理」を実行するのに対し、引用発明は、この送金リクエストを第2ユーザが利用する第2情報処理端末である顧客の携帯端末に送信しない点。
(相違点3)本願発明1は、第2ユーザのアカウントに対する「前記請求額と前記残高との差額」の「補填」を「前記情報処理装置を運営する事業者を債権者とする後払いサービス」によって行うのに対し、引用発明では、顧客が貸金業者に対する負債を負う、つまり、貸金業者を債権者とする融資又はキャッシングによって行う点。

(2)相違点についての判断
事案に鑑み、相違点1及び相違点3について検討する。
引用発明は、金融機関に設けられた口座サーバ12と貸金業者に設けられたクレジットサーバとを有する決済システムを前提としていることから、貸金業者を債権者とする融資又はキャッシングは必須の要素であって、これを「前記情報処理装置を運営する事業者を債権者とする後払いサービス」を用いたものに変更することはできない。
また、相違点3に係る本願発明1の「前記請求額」とは、「個人間送金サービス」において「第1ユーザが利用する第1情報処理端末」から受信される「送金リクエスト」(相違点1)に係る「所定の請求額」であるところ、原査定の理由において引用された引用文献2−6(上記「第3」の「2」ないし「6」)は、個人間送金サービスを開示する引用文献6を含め、いずれも、「個人間送金サービス」における送金リクエストに係る請求額について「前記情報処理装置を運営する事業者を債権者とする後払いサービス」を用いて補填することを示すものではない。また、この点が本願出願時に公知技術又は周知技術であったことを示す証拠は見あたらない。
よって、相違点2について判断するまでもなく、本願発明1は、引用発明及び引用文献2−6に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。

2.本願発明2−10について
本願発明2も、上記1の相違点1及び相違点3に係る、本願発明1の「個人間送金サービス」における送金リクエストに係る請求額について「前記情報処理装置を運営する事業者を債権者とする後払いサービス」を用いて補填するという事項を有するものであるから、本願発明1と同じ理由により、当業者であっても、引用発明及び引用文献2−6に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。

3.本願発明11、12について
本願発明11、12は、それぞれ本願発明1に対応する装置及びプログラムの発明であり、本願発明1と同様に、「個人間送金サービス」における送金リクエストに係る請求額について「前記情報処理装置を運営する事業者を債権者とする後払いサービス」を用いて補填するという事項を有するものであるから、本願発明1と同様の理由により、当業者であっても、引用発明及び引用文献2−6に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。

第5 原査定の概要及び原査定についての判断
原査定は、請求項1−12について上記引用文献1−6に基づいて、当業者が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができないというものである。
しかしながら、令和2年7月22日にされた手続補正による補正後の請求項1−12は、「個人間送金サービス」における送金リクエストに係る請求額について「前記情報処理装置を運営する事業者を債権者とする後払いサービス」を用いて補填することを発明特定事項として含むものとなっており、上記「第4」の1(2)において検討したとおり、本願発明1−12は、引用発明及び引用文献2−6に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。したがって、原査定を維持することはできない。

第6 当審より通知した拒絶理由について
当審より、請求項1−12の記載は、「決済する」という処理の範囲及び「補填」される対象が不明確であることから、特許法第36条第6項第2号の記載要件を満たさない旨の拒絶理由を通知した。
これに対して、令和4年3月9日にされた手続補正によって「決済」が「前記送金リクエストの前記請求額を前記第1ユーザのアカウントの残高に加算する」処理である旨及び「補填」される対象が「前記請求額と前記残高との差額」である旨を特定する補正がなされた結果、この拒絶の理由は解消した。

第7 むすび
以上のとおり、本願発明1−12は、引用発明及び引用文献2−6に記載された技術的事項に基づいて当業者が容易に発明をすることができたものではない。
また、本願の請求項1−12の記載は、明確である。
したがって、原査定の理由及び当審より通知した拒絶理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2022-05-31 
出願番号 P2019-021708
審決分類 P 1 8・ 121- WY (G06Q)
P 1 8・ 537- WY (G06Q)
最終処分 01   成立
特許庁審判長 渡邊 聡
特許庁審判官 相崎 裕恒
溝本 安展
発明の名称 情報処理方法、情報処理装置、及び情報処理プログラム  
代理人 伊東 忠重  
代理人 伊東 忠彦  

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