• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06Q
審判 査定不服 2項進歩性 取り消して特許、登録 G06Q
管理番号 1376196
審判番号 不服2019-17379  
総通号数 261 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-09-24 
種別 拒絶査定不服の審決 
審判請求日 2019-12-23 
確定日 2021-08-03 
事件の表示 特願2015- 891「定期請求システム、定期請求方法、および定期請求プログラム」拒絶査定不服審判事件〔平成28年 7月11日出願公開、特開2016-126599、請求項の数(10)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 理 由
第1 手続の経緯
本願は、平成27年1月6日の出願であって、平成30年12月27日付けで拒絶理由通知がされ、平成31年3月7日に手続補正がされ、令和元年5月24日付けで最後の拒絶理由通知がされ、同年7月23日に手続補正がされ、同年9月9日付けで同年7月23日にされた手続補正が却下されるとともに拒絶査定(原査定)がされ、これに対し、同年12月23日に拒絶査定不服審判の請求がされると同時に手続補正がされ、令和3年4月8日付けで当審より拒絶理由通知がされ、同年5月17日に手続補正がされたものである。

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

「事業者が作成したフォーマットの顧客データをインポートすることにより、商品または役務を定期的に購入する顧客を特定可能な前記顧客データに含まれる情報を、顧客情報として取得する顧客情報取得部と、
請求に関する情報を含む請求情報を取得する請求情報取得部と、
前記取得された顧客情報と請求情報とを対応付けて記憶装置に格納する情報格納部と、
前記記憶装置から読み出した前記請求情報に基づいて、所定期間ごとに請求書を作成する請求書作成部と、
前記記憶装置から読み出した前記顧客情報によって特定される顧客に、前記作成された請求書を送付する請求書送付部と、
前記顧客によって入金された入金額に関する情報を含む入金情報を取得する入金情報取得部と、
前記請求情報に含まれる請求額および請求先名と、前記入金情報に含まれる入金額および入金者名とをそれぞれ照合することによって、決済が完了したか否かを判定する決済判定部と、
前記決済が完了したと判定された場合、当該決済に対応する請求情報および入金情報を更新することによって、当該決済に伴う入金消し込みを行う入金消込部とを備え、
前記請求情報取得部は、前記所定期間ごとに前記商品または役務の数量の入力を事業者に求め、当該商品または役務の単価に当該入力された数量を乗じた額を前記請求額として含む前記請求情報を取得し、
前記請求書作成部は、前記請求情報と前記入金消し込みに関する情報とに基づいて、仕訳伝票を作成し、
前記入金消込部は、前記商品または役務を提供する事業者によって手動消し込みが行われた結果に基づいて前記請求情報を更新することによって、前記決済が完了したか否かに関する次回判定を自動化する
ことを特徴とする、定期請求システム。」

なお、本願発明2-10の概要は以下のとおりである。
本願発明2-8は、本願発明1を減縮した発明である。
本願発明9、10は、それぞれ本願発明1に対応する方法の発明、本願発明1に対応するプログラムの発明であり、いずれも、本願発明1とカテゴリ表現が異なるだけの発明である。

第3 原査定の拒絶理由の概要
(1)請求項1-12に係る発明は、下記引用文献1-10に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定におり特許を受けることができない。
引用文献
1.特開2010-49348号公報
2.特開2006-309540号公報
3.特開2009-294796号公報
4.特開2004-206253号公報
5.特開2004-265073号公報
6.特開2003-196448号公報
7.特開2014-132484号公報
8.特開2003-337733号公報
9.特開2008-140411号公報
10.特開2012-230443号公報

(2)請求項9-10(平成31年3月7日の手続補正による補正後のもの)は、引用請求項の記載の誤記があり、特許法第36条第6項第2号の記載要件に違反する。

第4 当審拒絶理由の概要
請求項1-10(令和元年12月23日の手続補正による補正後のもの)は、「決済が完了したか否かを判定する」ために「照合」されるものの記載について、特許法第36条第6項第1号の記載要件に違反する。

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

「【0012】
以下、図面を参照して本発明の実施形態について説明する。図1は資産管理システムの構成例を示す。このシステムは、資産管理サービス会社(以下、単にサービス会社という)1と、商品又はサービス(商品等という)の提供者である複数の債権者2と、商品等の提供に対して支払義務を負う債務者3と、金融機関4の各情報処理ステーションが、インターネットなどのネットワークを介して接続して構成される。債権者2や債務者3及び金融機関4の各情報処理ステーションは、例えば入出力手段、記憶手段及び情報処理手段を含むクラインアント端末を有する。以下、サービス会社1、債権者2、債務者3、金融機関4と言うときには、主としてこれらの処理手段を有する情報処理ステーションを指す。
【0013】
債権者2は、債務者3に対して種々の商品等を提供する複数の会社であり、その内にはレンタル又はリース契約に基づいて商品等を提供する会社や保険会社、保守サービス会社等が含まれる。債務者3はサービス会社1の顧客であり、例えば製造会社や事務会社、更には市町村等の公的企業も含まれ、複数の債権者2に対して定期的に(例えば毎月)代金の支払が発生する。
【0014】
サービス会社1は債務者3の資産を管理し、債権者2に対する支払データの作成及びその確認業務、更には債務者に対する支払請求書の作成等の特徴的な処理業務を行う。なお、図示の例では、1つの債務者3が示されているが、複数の債務者3がネットワークに接続され、サービス会社1はこれら複数の債務者に対するサービス業務の提供を行うことができる。この場合、債務者3ごとにそれらを識別する債務者IDが付与される。
【0015】
また、金融機関4には債権者2の口座が開設されており、債権者2からの支払要求に従
って、債務者3はその口座に請求代金を振り込む。なお、図示では1つの金融機関4が示されているが、実際に債権者は複数の金融機関を利用することがあり、複数の金融機関4がネットワークに接続される。
【0016】
サービス会社1は、このシステムの中核を成すものであり、債務者の資産を管理するための情報処理を行う管理サーバ10と、資産管理のために種々の情報を記憶する管理データベース(以下単にDB)12、及びネットワークと接続される送受信部14と、表示器15と、入力器16を有する。・・・」

「【0017】
管理DB12には資産、支払管理のための幾つかのDBを有する。即ち、管理DB12は、債務者の資産を管理する資産管理DB121と、商品等の提供に関して、債務者と債権者との間に締結される契約に関する情報を管理する契約管理DB122と、債務者が債権者に対して発生する代金の支払を管理する支払データ管理DB123と、債権者に請求内容の確認を行うために請求・支払明細を管理する請求・支払明細管理DB124等の複数のDBを有する。各管理DBの構成については図2?図4を参照して後述する。」

「【0018】
サービス会社1の管理サーバ10は、プロセッサで関連するアプリケーションプログラムを実行することで、資産管理部101、契約管理部102、支払データ作成部103、支払確認処理部104、資産更新部105、入金消込み処理部106(当審注:請求・支払明細作成部106の誤記と認められる。)、請求書発行部107(当審注:請求・支払明細確認処理部107の誤記と認められる。)、請求書作成発行部108、入金消込み処理部109の各機能を実現する。」

「【0019】
資産管理部101は、債務者3の資産情報を資産管理DB121に登録して管理するための処理を行う。具体的には、入力器16から入力される、債務者3が新たに取得した資産の情報を資産管理DB121に登録し、不要となった情報をそのDBから削除する処理を行う。
【0020】
契約管理部102は、債務者3が債権者2と交わしている契約情報を契約管理DB122に管理するための処理を行う。債務者3は通常、複数の債権者と契約を交わしているので、債権者毎に識別して管理する。具体的には、入力器16から入力される、債務者3が新たに交わした契約情報を契約管理D B 1 2 2 に登録する処理、不要となった情報を契約管理DB122から削除する処理、更に、契約内容が変更になった場合(例えば、契約期間の延長や短縮、契約金額の変更、支払時期の変更、契約の中途解約等)に、変更部分について契約管理DB122を変更する等の更新処理を行う。
【0021】
支払データ作成部103は、債務者3に定期的(例えば毎月)に発生する、支払データを作成する。この処理は、本来債務者が毎月行っている支払に関する業務を代行し、かつ作成された毎月の支払データを債権者2 に照会して、債権者と債務者との間で、毎月の請求に対する支払のミス(不一致)を防止することを期待している。この処理は、債務者3の資産管理DB121と契約管理DB122を参照して、契約上当月に支払が発生する資産に関する支払項目を抽出して、債務者の部署毎の資産に対応して支払データを集めて纏める処理である。支払データ作成部103によって作成される支払データは、支払データ管理DB123に保管される。なお、支払データ管理DB123の記憶形式については後述する。
【0022】
支払確認処理部104は、支払データ作成部103で作成された毎月の支払データを債務者3に送信してその支払内容を確認させるための処理である。例えば、1つの債務者3が複数の債権者2に対して支払う場合、この処理部104は該当する債権者ごとに支払内容を分けて整理して債務者3へ送信し、債務者3の確認した結果を受信する。
【0023】
債務者3からの受信した内容には、債務者が契約を確認して当月に支払を確認した結果、及び債務者の資産の変更状況を示す情報が含まれている。資産の変更とは、例えば資産の1つであるパソコンの設置部署を変更したり、費用負担先を変更したり、管理責任者を変更したり、或いはそのリース契約を解除する場合が該当する。なお、債務者3側の処理については後述する。
【0024】
資産更新部105は、支払確認処理の結果、債務者3の資産の変更があった場合、その変更を資産管理DB121の登録情報に反映して、資産情報を更新する処理である。なお、この資産更新部105は資産管理部101の1の処理としてそれに統合してもよい。
【0025】
請求・支払明細作成部106は、支払確認処理部104において債務者3で確認された支払データを、債権者毎に請求・支払明細として纏めて作成する。これは、その請求・支払明細を債権者3毎にネットワークを介して送信して、債権者に当月の請求・支払内容と金融機関の指定口座への振込金額とを照合して確認させるための処理である。作成された請求・支払明細は、控えとして、請求・支払明細管理DB(図5)に保管される。
【0026】
請求・支払明細確認処理部107は、請求・支払明細作成部106で作成された請求・支払明細を、債権者3毎にネットワークを介して送信して、当月の請求・支払内容を確認させるための処理である。債権者2により確認された結果は、当該請求・支払明細の形式で、ネットワークを介して受信される。
【0027】
なお、債務者3が正しく確認された結果は、請求・支払明細管理DBに保管された当該明細の支払確認事項欄にチェックマーク「レ」を付すようにする。また、債権者よりコメントが付いた場合には同じく備考欄に記入される。債権者の確認結果によっては請求内容を訂正することもある。
【0028】
請求書作成発行部108は、サービス会社1が債権者2に代わって債務者3に対して、請求書を発行することを代行するために、請求書を作成して印刷発行する処理である。当該債権者から当該債務者への請求が正しい場合に、請求書作成発行部108は、請求・支払明細管理DBを参照して、当該債権者から債務者3へ請求する当月分の請求書を作成して印刷発行する。
【0029】
印刷発行された請求書は、図6に示されるように、当月分の請求内容、及び当該債権者の代行発行である旨が表示されている。この請求書は債務者の出納部署等支払部門へ送付される。なお、1つの債務者に対して債権者が多数存在する中には、請求書の代行発行をこのサービス会社1に依託しない場合もある。その場合には、従来通り、当該債権者が作成した請求書が債務者へ送付されることになる。勿論、その内容は、上記請求・支払明細確認処理部107によって確認された結果と一致している。
【0030】
入金消込み処理部109は、債権者より請求された支払金額を債務者が債権者の指定の口座に振り込んだ場合、その振込金額を含む振込情報を債権者2より取得して、請求・支払明細管理DB123に保管された、当該債権者に対する支払内容と照合して消し込む処理である。複数の債権者から請求された、当月の全ての項目が消し込まれれば、当該債務者の当月の支払は正しく処理されたことになる。消込みが正しく行われた場合には、請求・支払明細管理DBに保管された当該明細の入金消込確認欄532に、例えばチェックマーク「レ」が記録される。」

「【0032】
次に、各管理DBの構成例について説明する。図2は資産管理DB121の構成例である。サービス会社1の顧客である債務者の資産状況を管理するものであり、債務者毎に資産管理DB121を有する。図示のように、資産管理DBは、その内容として、債務者の物件名、メーカー名、物件台数、資産Nｏ、物件の固有ID、負担先、等々の各情報を登録する。なお、資産管理DB121の登録内容は、資産更新部105の処理によって更新される。
【0033】
図3は契約管理DB122の構成例である。契約管理DB122は、資産区分、契約先の債権会社、取引番号、契約名称、請求コード、契約開始年月日、契約終了日、支払金額、支払方法、契約金額、等々の各情報を登録して管理する。
【0034】
図4は支払データ管理DB123の構成例である。支払データ管理DB123は、支払データ作成部103によって作成される支払データを保管する。この支払データには、契約管理DB122から得た情報と資産管理DB121から得た情報と基本にした、債務者による支払確認のための項目、及び資産の変更状況を調査するための項目が含まれる。即ち、請求情報欄41と、支払確認欄42と、物件情報欄43と、変更欄44から成る。支払確認欄42と変更欄44は、債務者3の該当する部署の責任者が記入することが許可されている。
【0035】
請求情報欄41には、契約管理DB122から得られた情報である、資産区分、項番、契約先の会社名、取引番号、契約者名称、請求先コード、契約開始年月日、契約対象の物件名称、物件台数、契約金額、当月の請求額、負担先の情報が含まれる。
【0036】
支払確認欄42は、対象部署の責任者が請求情報を確認して、本件請求案件について支払確認部署が出納部署に対して支払伝票を発行した場合に、チェックマークを記入する支払伝票発行確認欄421、当月の支払確定額422、及び出納部署の責任者が支払伝票の金額を確認したときにチェックマークを記入する出納部署確認欄423から構成される。
【0037】
物件情報欄43は、資産管理DB121から得られた情報である、債務者の物件項番、設置部署、物件番号、使用者、メーカー名、設置場所、物件型名等の物件情報が含まれる。各部署の責任者は、この物件情報を参照して、それらに変更があるか否かを確認する。
【0038】
変更欄44は、関係部署の責任者が物件情報を確認した結果、変更がある場合に、その変更情報を記入する欄である。変更情報としては例えば、物件の部署間の移動、物件の使用者や責任者の変更、負担先変更等がある。
【0039】
図5は請求・支払明細管理DB124の構成例である。請求・支払明細管理DB124は、請求・支払明細作成部106で作成された明細を保管する。この明細は、債権者の会社毎に分けられ、請求情報51として、資産区分、項番、会社名、取引番号、契約者名称、当月の請求額、及び支払確認事項52として債務者が支払手続きに関して確認された事項(図4の421?423に対応)を有する。
【0040】
更に、債権会社欄53として、入金確認531、入金消込確認532及び備考533の各欄を有する。債権者2によって入金が確認されると、入金確認欄531にチェックマーク「レ」が記録され、またサービス会社1によって入金消し込みが行われると、入金消込確認欄532に「レ」が記録される。」

【0025】、【0039】、【0040】の記載によれば、請求・支払明細作成部では、債務者で確認された支払データを債権者毎に請求・支払明細として纏めて作成し、作成された請求・支払明細を請求・支払明細管理DBに保管するところ、保管される明細は、請求情報として当月の請求額等を有するものであり、また、この請求・支払明細管理DBは、債権会社欄として、入金確認欄と入金消込確認欄を有するものである。

【0030】、【0039】、【0040】の記載によれば、入金消込み処理部では、債権者より請求された支払金額を債務者が債権者の指定の口座に振り込んだ場合、その振込金額を含む振込情報を債権者より取得し、債権者によって入金が確認されると、請求・支払明細管理DBの債権会社欄の入金確認欄にチェックマークが記録され、その上で、請求・支払明細管理DBに保管された当該債権者に対する支払内容と照合して消し込む処理が行われると、請求・支払明細管理DBの債権会社欄の入金消込確認欄にチェックマークが記録されて、消し込む処理を行う。

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

(引用発明)
複数の債務者に対してサービス業務を提供する資産管理サービス会社(以下、サービス会社という。)と、商品又はサービスの提供者である複数の債権者と、サービス会社の顧客であって、複数の債権者からの商品又はサービスの提供に対する定期的な代金の支払が発生する債務者と、金融機関との各情報処理ステーションがインターネットなどのネットワークを介して接続されて構成されたシステムにおける、サービス会社における債務者の資産を管理するための情報処理を行う管理サーバであって(【0012】-【0016】)、
債務者の資産情報を資産管理DBに登録して管理するための処理を行う資産管理部(【0019】)、
債務者が債権者と交わしている契約情報を契約管理DBに管理するための処理を行う契約管理部(【0020】)、
債務者に定期的(例えば毎月)に発生する支払いデータを作成する支払データ作成部(【0021】)、
支払いデータ作成部で作成された毎月の支払いデータを債務者に送信してその支払い内容を確認させるための処理である支払確認処理を行う支払確認処理部(【0022】)、
支払確認処理の結果、債務者の資産に変更があった場合にその変更を資産管理DBに反映して資産情報を更新する処理である資産更新処理を行う資産更新部(【0024】)、
債務者で確認された支払データを債権者毎に、請求情報として当月の請求額等を有する請求・支払明細として纏めて作成し、作成された請求・支払明細を、債権会社欄として入金確認欄と入金消込確認欄を有する請求・支払明細管理DBに、保管する請求・支払明細作成部(【0025】、【0039】、【0040】)、
請求・支払明細作成部で作成された請求・支払明細を、債権者毎にネットワークを介して送信して当月の請求・支払内容を確認させるための処理である請求・支払明細確認処理を行う請求・支払明細確認処理部(【0026】)、
請求・支払明細管理DBを参照して、債権者から債務者へ請求する当月分の請求書を作成して印刷発行して、サービス会社が債権者に代わって債務者に対して請求書を発行することを代行する処理を行い、この請求書は債務者の支払部門へ送付されるものである、請求書作成発行部(【0028】)、
債権者より請求された支払金額を債務者が債権者の指定の口座に振り込んだ場合、その振込金額を含む振込情報を債権者より取得し、債権者によって入金が確認されると、請求・支払明細管理DBの債権会社欄の入金確認欄にチェックマークが記録され、その上で、請求・支払明細管理DBに保管された当該債権者に対する支払内容と照合して消し込む処理が行われると、請求・支払明細管理DBの債権会社欄の入金消込確認欄にチェックマークが記録されて、消し込む処理を行う入金消込み処理部、(【0030】、【0039】、【0040】)
の各機能を実現する、
管理サーバ。

2 引用文献2-10 略

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

引用発明の「商品又はサービス」は、本願発明1の「商品または役務」に相当する。
引用発明の「債務者」は、商品または役務の提供に対して定期的に発生する支払いに係る請求書の送付先となる被請求者である点で、本願発明1の「顧客」と共通している。

引用発明の「支払データ作成部」は、上記支払いのデータを作成するものであり、その支払いの請求に関する情報を含む被請求者に対する請求情報を取得するといえるから、本願発明1の「請求に関する情報を含む請求情報を取得する請求情報取得部」に相当する。
引用発明の「請求・支払明細管理DB」は、被請求者に対する請求情報として当月の請求額等が格納される記憶装置であるといえ、その点で、本願発明1の「記憶装置」と共通している。そして、引用発明の「請求・支払明細作成部」は、作成された明細における被請求者に対する請求情報を記憶装置に格納する点で、本願発明1の「情報格納部」と共通している。
引用発明の「請求書作成発行部」は、当月分の請求書を印刷発行するものであるから、所定期間毎に請求書を作成する点で、本願発明1の「請求書作成部」と共通している。また、引用発明は、印刷発行された請求書を債務者の支払部門へ送付するから、そのために本願発明1の「請求書送付部」に相当する構成を有するものといえる。

引用発明における、債権者からの、債務者が請求された支払金額を債権者の指定の口座に振り込んだ際の振込金額を含む振込情報は、上記支払いのために被請求者によって入金された入金額に関する情報を含む入金情報であり、本願発明1の「入金情報」に相当する。
そして引用発明の「入金消込処理部」は、この入金情報を取得する点で、本願発明1の「入金情報取得部」と共通する。
さらに、引用発明の「入金消込処理部」は、債権者による入金確認を受信して請求・支払明細管理DBの入金確認欄にチェックマークを記録し、さらに当該債権者に対する支払内容と照合して入金消込確認欄にチェックマークを記録して消込処理を行うものであり、請求情報に含まれる請求額および請求先名と入金情報に含まれる入金額および入金者名とをそれぞれ照合して請求情報および入金情報を更新することによって入金消し込みを行うものともいえるから、この点で、本願発明1の「入金消込部」とも共通するといえる。

引用発明の管理サーバは、下記の相違点では相違するものの、所定期間毎に請求書を作成して送付する請求書作成部及び請求書送付部を備えるシステムであるから、本願発明1の「定期請求システム」と相当するといえる。

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

(一致点)
請求に関する情報を含む請求情報を取得する請求情報取得部と、
被請求者に対する請求情報を記憶装置に格納する情報格納部と、
前記記憶装置から読み出した前記請求情報に基づいて、所定期間ごとに請求書を作成する請求書作成部と、
被請求者に前記作成された請求書を送付する請求書送付部と、
前記顧客によって入金された入金額に関する情報を含む入金情報を取得する入金情報取得部と、
前記請求情報に含まれる請求額および請求先名と、前記入金情報に含まれる入金額および入金者名とをそれぞれ照合し、請求情報および入金情報を更新することによって、入金消し込みを行う入金消込部とを備える、
定期請求システム。

(相違点)
(相違点1)
本願発明1は、請求書の送付先である被請求者が、請求情報と対応付けて記憶装置に格納される「顧客情報」によって特定される「顧客」であるのに対し、引用発明における被請求者は、サービス会社が資産を管理する債務者である点。

(相違点2)
本願発明1は、「事業者が作成したフォーマットの顧客データをインポートすることにより、商品または役務を定期的に購入する顧客を特定可能な前記顧客データに含まれる情報を、顧客情報として取得する顧客情報取得部」を備えるのに対し、引用発明は、これを備えない点。

(相違点3)
本願発明1は、「決済が完了したか否かを判定する決済判定部」を備え、入金消し込みを「前記決済が完了したと判定された場合」に行うのに対し、引用発明は、債権者から取得した振込情報を入金情報として用いており、決済が完了したか否かを判定していない点。

(相違点4)
本願発明1の「請求情報取得部」は、「前記所定期間ごとに前記商品または役務の数量の入力を事業者に求め、当該商品または役務の単価に当該入力された数量を乗じた額を前記請求額として含む前記請求情報を取得」するのに対し、引用発明ではそうではない点。

(相違点5)
本願発明1の「請求書作成部」は、「前記請求情報と前記入金消し込みに関する情報とに基づいて、仕訳伝票を作成」するのに対し、引用発明ではそうではない点。

(相違点6)
本願発明1の「入金消込部」は、「前記商品または役務を提供する事業者によって手動消し込みが行われた結果に基づいて前記請求情報を更新することによって、前記決済が完了したか否かに関する次回判定を自動化する」のに対し、引用発明では、そうではない点。

(2)相違点についての判断
ア 相違点1、2について
相違点1、2は関連しているので、まとめて検討する。
引用発明の「サービス会社」は、「債務者の資産を管理」するサービスを行う事業者であり、請求書の作成発行のようなサービスを提供する相手方となる債権者は、サービス会社がサービスを提供する債務者に対する債権者である。
このことを踏まえれば、引用発明であるサービス会社の管理サーバにおける「債務者」は、債権者ではなくサービス会社のサービスの相手方と位置づけされているのであるから、債権者である事業者の「顧客」と位置づけられたり、管理サーバが「債権者」である事業者から「顧客」に関する「顧客情報」を「事業者が作成したフォーマットの顧客データ」を「インポート」して取得することもあり得ない。
よって、引用発明において被請求者を顧客とすることや事業者が作成したフォーマットの顧客データのインポートによって顧客情報を取得するものに変更することが動機付けられることはない。

イ 相違点3、5、6について
相違点3、5、6は関連しているので、まとめて検討する。
引用発明は、請求された支払金額を債務者が債権者の指定の口座に振り込んだ場合の振込金額を含む振込情報を請求書の送付先として振込を行う債務者からでなく振込がなされた「債権者」より「取得」しているから(【0030】)、引用発明の「入金消し込み」は、債務者からの振込を確認して行われる債権者の資産項目振替のための会計処理を代行するものでなく、引用発明は、債権者が行う決済のための請求と入金の照合の処理や決済を踏まえた仕訳のような会計処理を代行するものではない。いうなれば、債権者の業務のうち、決済そのものや決済に伴う会計処理は、請求書の印刷や送付のような業務と異なり、債務者の資産を管理するサービスを行うサービス会社における代行になじまないという整理が示されている。
よって、引用発明において、請求と入金との照合に基づく決済の判定(次回決済に関する判定を含む)や決済を踏まえた仕訳をサービス会社の管理サーバが行うように変更することが、動機付けられることはない。

ウ したがって、相違点1、2、3、5、6は、当業者が引用発明に基づいて容易に想到し得たものとはいえない。
よって、上記相違点4について判断するまでもなく、本願発明1は、当業者であっても引用発明に基づいて容易に発明をすることができたものではない。

2 本願発明2-8について
本願発明2-8も、1で検討した相違点1、2、3、5、6に係る本願発明1の構成と同一の構成を備えるものであるから、本願発明1と同じ理由により、当業者であっても、引用発明に基づいて容易に発明をすることができたものではない。

3 本願発明9、10について
本本願発明9、10は、それぞれ本願発明1に対応する方法の発明、本願発明1に対応するプログラムの発明であり、1で検討した相違点1、2、3、5、6に係る本願発明1の構成に対応する構成を備えるものであるから、本願発明1と同様の理由により、当業者であっても、引用発明に基づいて容易に発明をすることができたものではない。

第7 原査定についての判断
1 特許法第29条第2項について
原査定の理由1は、請求項1-10について、上記引用文献1を主引用文献として、特許法第29条第2項の規定により特許を受けることができないというものである。しかしながら、第6に上記したとおり、本願発明1-10は、上記引用文献1に記載された発明に基づいて、当業者が容易に発明をすることができたものではない。
なお、原査定の理由で副引用文献ないし周知例として示された引用文献2-10も、第6で検討した相違点1、2、3、5、6に係る本願発明1-10の構成に対応する内容を開示するものでない。

2 特許法第36条第6項第2号について
誤記を含む請求項が令和元年12月23日の手続補正により削除されている。

3 よって、原査定を維持することはできない。

第8 当審拒絶理由について
当審拒絶理由(特許法第36条第6項第1号の記載要件違反)は、令和3年5月17日の手続補正における補正により解消した。

第9 むすび
以上のとおり、本願発明1-10は、当業者が引用発明に基づいて容易に発明をすることができたものではなく、上記のとおり、原査定の理由及び当審拒絶理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2021-07-15 
出願番号 特願2015-891(P2015-891)
審決分類 P 1 8・ 537- WY (G06Q)
P 1 8・ 121- WY (G06Q)
最終処分 成立  
前審関与審査官 渡邉 加寿磨  
特許庁審判長 高瀬 勤
特許庁審判官 中野 浩昌
相崎 裕恒
発明の名称 定期請求システム、定期請求方法、および定期請求プログラム  
代理人 特許業務法人白坂  

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