2017-002546

特願２０１５－５１６４３５「支払方法及び装置」拒絶査定不服審判事件〔平成２６年　１月２３日国際公開、ＷＯ２０１４／０１２４０７、平成２７年１０月　１日国内公表、特表２０１５－５２８９３４〕について、次のとおり審決する。

【結　論】 本件審判の請求は、成り立たない。

【理　由】 １．手続の経緯 本願は、２０１３年６月１８日（パリ条約による優先権主張外国庁受理２０１２年７月１８日、中華人民共和国）を国際出願日とする出願であって、平成２８年１月２９日付けの拒絶理由通知に応答して、平成２８年５月９日付けで意見書、手続補正書が提出されたが、平成２８年１０月２７日付けで拒絶査定がなされた。これに対して、平成２９年２月２２日に拒絶査定不服審判が請求され、同日付けで手続補正書が提出されたものである。 ２．平成２９年２月２２日の手続補正について 平成２９年２月２２日の手続補正による請求項１－４及び６-８の補正については適法になされたものとする。 ３．本願発明 本願の請求項１－８のうち請求項５に係る発明は、平成２８年５月９日付け手続補正書の特許請求の範囲の請求項７に記載されたものであって、平成２９年２月２２日付け手続補正書の特許請求の範囲の請求項５に記載された次のとおりのものと認める。（以下、「本願発明」という。） 「　　【請求項５】 端末からの支払要求を受信した後、前記端末のユーザーに対応するアカウントの支払情報が含まれる、前記端末からの二次元コードを取得するように設定される取得モジュールと、 前記二次元コードに含まれる前記アカウントの支払情報を読み取るように設定される読取モジュールと、 前記支払要求に応じて前記支払情報を使用して前記アカウントに対して料金を差し引くように設定される支払モジュールと、を備える支払装置。」 ４．引用例 １）引用例１ 原査定の拒絶の理由に引用された、本願の原出願日前である平成１５年１０月１７日に頒布された特開２００３－２９６６２２号公報（以下、「引用例１」という。）には、図面とともに次の事項が記載されている。なお、下線は当審により付した。 （１）「【００７７】〔第６の実施形態〕本発明を好適に実施した第６の実施形態について説明する。本実施形態による情報管理システムの構成は第１の実施形態と同様である。なお、本実施形態においても店舗端末２００ａ及び携帯電話端末３００ａを用いて説明を行う。図１４に、本実施形態による情報管理システムにおいて、センサーバ１００の個人情報ＤＢ１０４に格納される個人情報のデータ構造を示す。図に示すように、本実施形態では、個人情報のパラメータに利用可能残高情報が含まれる。利用可能残高情報は、会員が事業者の店舗で利用可能な金額を示す情報であり、会員が商取引を行ったり、例えば携帯電話端末３００ａを用いて入金操作を行うごとに、最新の情報に更新される。 【００７８】図１５に、本実施形態による情報管理システムの動作シーケンスの一例を示す。まず、入会希望者の会員登録を行う（ステップＳ６０１～Ｓ６０４）。この処理は、第１の実施形態と同様の処理（ステップＳ１０１～Ｓ１０４）である。 【００７９】会員が事業者店舗において代金を支払う際に、事業者又は会員は、入力部２０２を用いて店舗端末２００ａに取引条件（金額や商品名など）を入力する（ステップＳ６０５）。会員は、操作部３０３を用いて２Ｄコード格納部３０５に格納されている二次元コード（会員コード用二次元コード）を読み出し、表示部３０４に表示させる（ステップＳ６０６）。事業者は、表示部３０４に表示された二次元コードを２Ｄコード読み取り部２０４を用いて店舗端末２００に読み取らせる（ステップＳ６０７）。二次元コードを読み取り終えると制御部２０１は、二次元コードを読み取って取得した情報（会員コード）及び取引条件情報を、通信部２０３を用いてセンタサーバ１００へ送信する（ステップＳ６０８）。 【００８０】センタサーバ１００が店舗端末２００ａから二次元コードの情報（会員コード）を取得すると、制御部１０１は２Ｄコード格納部１０３に格納されている事業者の使用済み二次元コードの中に、店舗端末２００から受信した会員コードによって示される二次元コードと一致するものがあるか否かを判断する（ステップＳ６０９）。 【００８１】２Ｄコード格納部１０３に格納されている二次元コードの中に一致するものがない場合は（ステップＳ６０９／Ｎｏ）、情報管理システムは処理を終了する。この時、店舗端末２００ａに対してエラーを通知するようにしてもよい。一方、一致するものがある場合（ステップＳ６０９／Ｙｅｓ）、制御部１０１は、この二次元コードと関連づけられている個人情報を個人情報ＤＢ１０４から読み出す。さらに、制御部１０１は、この個人情報に含まれる残高情報と店舗端末２００から取得した取引条件情報に含まれる取引金額とを比較して、支払い可能であるか否かを確認する（ステップＳ６１０）。 【００８２】残高不足のため支払い不可能である場合（ステップＳ６１０／Ｎ）、制御部１０１は店舗端末２００ａに残高不足であることを通知して、エラー終了する。支払いが可能である場合（ステップＳ６１０／Ｙ）、制御部１０１は、取引金額を差し引いて新たな残高情報を生成し、個人情報ＤＢ１０４に格納されている個人情報を更新する（ステップＳ６１１）。さらに、制御部１０１は利用情報を生成し、利用履歴情報ＤＢ１０５に蓄積する（ステップＳ６１２）。そして、取引が成立したことを店舗端末２００ａ及び携帯電話端末３００ａに通知する（ステップＳ６１３、Ｓ６１４）。以降、ステップＳ６１５以降の処理は、第１の実施形態におけるステップＳ１１２～Ｓ１１７の処理と同様であり、上記同様に、個人情報ＤＢ１０４及び利用履歴情報ＤＢ１０５に格納されている情報を用いて、会員からの要求（ステップＳ６１５）や事業者からの要求（ステップＳ６１７）に応じたｐｕｌｌ型（ステップＳ６１６、Ｓ６１８）、あるいは、携帯電話端末３００ａへｐｕｓｈ型（ステップＳ６１９）で情報を配信できる。 【００８３】本実施形態による情報管理システムは、個人情報のパラメータとして残高情報を含むため、二次元コードを利用した電子決済が可能となる。なお、電子決済は上記手法に限定されることはない。例えば、残高情報の代わりに口座番号情報のパラメータを設け、金融機関の口座から取引の代金を引き落とすようにしてもよい。」 （下線は、当審による。） これらの記載から、引用例１には、 「会員が代金を支払う際に、取引条件（金額や商品名など）を入力し、二次元コード（会員コード用二次元コード）を読み取り、二次元コードを読み取って取得した情報（会員コード）及び取引条件情報を店舗端末２００から取得すると、 ２Ｄコード格納部１０３に格納されている事業者の使用済み二次元コードの中に、店舗端末２００から受信した会員コードによって示される二次元コードと一致するものがあるか否かを判断し、一致するものがある場合、この二次元コードと関連づけられている個人情報を個人情報ＤＢ１０４から読み出し、この個人情報に含まれる残高情報と店舗端末２００から取得した取引条件情報に含まれる取引金額とを比較して、支払い可能であるか否かを確認し、支払いが可能である場合、取引金額を差し引いて新たな残高情報を生成し、個人情報ＤＢ１０４に格納されている個人情報を更新し、取引が成立したことを店舗端末２００ａ及び携帯電話端末３００ａに通知する センタサーバ１００。」 の発明（以下、「引用例１発明」という。）が記載されているものと認められる。 ５．対比 引用例１発明と本願発明を対比する。 引用例１発明の「会員が代金を支払う際に、取引条件（金額や商品名など）を入力し、二次元コード（会員コード用二次元コード）を読み取り、二次元コードを読み取って取得した情報（会員コード）及び取引条件情報を店舗端末２００から取得すると、」において、「店舗端末２００」は、ユーザーである「会員」が使用する端末であるから、引用例１発明の「店舗端末２００」、「会員」は、本願発明の「端末」、「ユーザー」に相当する。 引用例１発明の「取引条件（金額や商品名など）」は、本願明細書に「支払要求に含まれる支払うべき商品の金額」という記載があることを参酌すれば、本願発明の「支払要求」に相当する。 引用例１発明の「二次元コードを読み取って取得した情報（会員コード）」は、二次元コードそのものであるかどうかは不明であるものの、本願発明の「二次元コード」とは、「二次元コードに関する情報」で共通する。 引用例１発明の「二次元コードを読み取って取得した情報（会員コード）」は、「２Ｄコード格納部１０３に格納されている事業者の使用済み二次元コードの中に、店舗端末２００から受信した会員コードによって示される二次元コードと一致するものがあるか否かを判断し、一致するものがある場合、この二次元コードと関連づけられている個人情報を個人情報ＤＢ１０４から読み出し、この個人情報に含まれる残高情報と店舗端末２００から取得した取引条件情報に含まれる取引金額とを比較して、支払い可能であるか否かを確認し、支払いが可能である場合、取引金額を差し引いて新たな残高情報を生成する」ためのものであるから、この「会員コード」は、会員個人を識別し、会員個人の支払権限を特定する機能を有しており、支払のためのアカウントを含んでいると解される。そうすると、「会員コード」は、本願発明の「前記端末のユーザーに対応するアカウントの支払情報が含まれる」ものである。 引用例１発明は、「二次元コードを読み取って取得した情報（会員コード）及び取引条件情報を店舗端末２００から取得する」構成であるから、本願発明の、「端末からの支払要求」と、「前記端末のユーザーに対応するアカウントの支払情報が含まれる、前記端末からの二次元コードに関する情報を取得するように設定される取得モジュール」に相当する構成を有している。 引用例１発明は、「支払い可能であるか否かを確認し、支払いが可能である場合、取引金額を差し引いて新たな残高情報を生成し、個人情報ＤＢ１０４に格納されている二次元コードと関連づけられている個人情報を更新」する構成であることから、本願発明の「前記支払要求に応じて二次元コードと関連づけられている支払情報を使用して前記アカウントに対して料金を差し引くように設定される支払モジュール」に相当する構成を有している。 引用例１発明の「センターサーバ１００」は、二次元コードに関連する情報を用いた支払装置といえるから、引用例１発明の「支払装置」に相当する。 してみると、両発明の一致点、相違点は以下のとおりである。 ［一致点］ 「　端末からの支払要求と、前記端末のユーザーに対応するアカウントの支払情報が含まれる、前記端末からの二次元コードに関する情報を取得するように設定される取得モジュールと、 前記支払要求に応じて前記支払情報を使用して前記アカウントに対して料金を差し引くように設定される支払モジュールと、を備える支払装置。」 である点。 ［相違点］ （１）本願発明が「端末からの支払要求を受信した後、」「二次元コード」を取得しているのに対して、引用例１発明は、「二次元コードを読み取って取得した情報（会員コード）及び取引条件情報」を取得している点。 （２）本願発明の「支払モジュール」で使用される「アカウントの支払情報」は、「前記支払情報」、すなわち、支払装置の取得モジュールによって取得するように設定され、支払装置の読み取りモジュールで読み取られるように設定された前記端末からの二次元コードに含まれる情報であるのに対して、引用例１発明の「会員コード」は、二次元コードに関連する情報であって、二次元コードに含まれる情報ではあるが、センタサーバサーバ１００は、二次元コードを取得し、読み取るように設定されておらず、したがって、引用例１発明の「センターサーバ１００」は、本願発明の「取得モジュール」「読み取りモジュール」に相当する構成を有していない点。 ６．当審の判断 相違点について （１）２つのデータを送信するに当たって、順番に送るか、一度に送るかは当業者が任意に設定し得る取り決め事項であり、技術的に格別な効果を奏する事項ではないから、当該相違点は実質的な相違点とはいえない。 （２）本願発明の「取得モジュール」「読み取りモジュール」は、明細書を参酌すると、「取得モジュール」は、二次元コードを取得し、「読み取りモジュール」は、二次元コードの復号化を行うものである。このように、二次元コードを、サーバで取得し、サーバで復号化を行うことは、例えば、特開２００７－１０８９４７号公報（段落番号００７７）、特開２００６－２３５９８１号公報（段落番号００３７）に記載されているように周知事項であるから、引用例１発明に当該周知事項を適用し相違点（２）の構成とすることは、当業者が容易になし得ることである。 また、本願発明が奏する作用効果も、引用例１発明および周知事項から当業者が予測し得る範囲のものである。 ７．むすび したがって、本願発明は、引用例１記載の発明及び周知事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 当該請求項５が特許を受けることができないものであるから、その他の請求項については検討するまでもなく拒絶されるべきものである。 よって、結論のとおり審決する。