2021-008669

第２ 原査定の概要

原査定（令和３年３月１８日付け拒絶査定）の概要は次のとおりである。

この出願の請求項１ないし２０に係る発明は、その原出願日前に日本国内又は外国において、頒布された下記の引用文献１ないし８に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、その原出願日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

＜引用文献等一覧＞

１.特開２０１５－０９０５５６号公報

２.特開２０１３－１２０４１８号公報

３.米国特許出願公開第２０１７／０１０９７７６号明細書

４.特開２０１４－１７０３５８号公報

５.特開２００６－０１１７００号公報

６.話題のコード決済アプリの便利な活用法とセキュリティホール ＰａｙＰａｙ超入門，ラジオライフ，日本，２０１９年 ２月 ５日，第４０巻 第５号，第２２－２４頁

７.韓国公開特許第１０－２０１８－０１１９１４３号公報

８.特開２０１２－１５０７１２号公報

第３ 当審拒絶理由の概要

当審拒絶理由の概要は次のとおりである。

この出願の請求項１ないし８及び１０ないし２０に係る発明は、その原出願日前に日本国内又は外国において、頒布された下記の引用文献１、２、４、５及び８に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、その原出願日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

＜引用文献等一覧＞

１ 特開２０１５－０９０５５６号公報

２ 特開２０１３－１２０４１８号公報

４ 特開２０１４－１７０３５８号公報

５ 特開２００６－０１１７００号公報

８ 特開２０１２－１５０７１２号公報

第４ 本願発明

本願請求項１ないし１９に係る発明（以下、それぞれ「本願発明１」ないし「本願発明１９」という。）は、令和４年５月２７にされた手続補正により特許請求の範囲の請求項１ない１９に記載された事項により特定される発明であり、本願発明１は以下のとおりの発明である。

「【請求項１】

所定のコードを用いた決済サービスを提供する生成装置であって、

複数の利用者が複数の事業者により提供される複数の店舗で行った所定のコードによる決済手段に関する決済の履歴を取得する取得部と、

店舗、利用者又は地域の少なくとも一つに関する条件が指定された場合に、当該指定された条件である指定条件を満たす各利用者の決済に関する順位を示す順位情報を生成する生成部と

を有し、

前記生成部は、前記利用者による決済のうち、決済を行った店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する

ことを特徴とする生成装置。」

なお、本願発明２ないし１９の概要は以下のとおりである。

本願発明２ないし１７は、本願発明１を減縮した発明である。

本願発明１８及び１９は、それぞれ本願発明１に対応する「生成方法」及び「生成プログラム」の発明であり、本願発明１とカテゴリ表現が異なるだけの発明である。

第５ 引用文献、引用発明等

１ 引用文献１について

原査定及び当審の拒絶の理由引用された引用文献１（特開２０１５－０９０５５６号公報）には、次の事項が記載されている。（下線は、当審で付した。以下同じ。）

「【技術分野】

【０００１】

本発明は、情報処理システム、および情報処理方法に関する。」

「【０００８】

また、フォースクエアのサーバ装置は、ベニュー毎に、チェックイン回数が最も多い利用者を、そのベニューのメイヤー（市長）として認定する。フォースクエアのサーバ装置は、メイヤーに認定した利用者の情報を、上述の詳細情報に含めて送信することで、他の利用者に紹介する。

【０００９】

また、フォースクエアは、他の利用者のチェックイン状況を確認することができる。そして、チェックイン中の他の利用者に対して、メール等でコミュニケーションを図ることともできる。

【００１０】

このようなフォースクエアの場合、利用者は、ベニューに対するチェックイン回数を多くすることで、バッジまたはメイヤーの称号等の名誉的な利益を得ることができる。また、ベニューの店舗等は、バッジまたはメイヤーの称号等を目的とする利用者およびメール等のコミュニケーションによる紹介で訪れた利用者が店舗を利用することで、金銭的利益を得ることができる。」

「【課題を解決するための手段】

【００１５】

本発明は、上述の課題を解決するための手段として、少なくとも、予め付与された店舗識別情報および売り上げ額に対応するポイント情報を送信する第１送信部と、受信したポイント情報に対応する登録識別情報を返信する第２送信部と、返信された登録識別情報を、画像情報に変換して出力する出力制御部と、出力された画像情報を撮像するように撮像部を制御する撮像制御部と、撮像部から得られた撮像画像を解析して登録識別情報を復元する復元部と、復元された登録識別情報を、予め付与された利用者識別情報と共に送信する第３送信部と、受信した利用者識別情報に関連付けて、利用者識別情報と共に受信した登録識別情報に対応するポイント情報を記憶部に記憶する記憶制御部とを有する。」

「【００１９】

（第１の実施の形態）

図１は、第１の実施の形態のコミュニケーションシステムのシステム構成図である。この図１に示すように、コミュニケーションシステムは、コミュニケーションサーバ装置１、携帯端末装置２、およびキャッシュレジスタ装置３を、ネットワーク４を介して相互に接続して構成されている。なお、コミュニケーションサーバ装置１は、以降、サーバ装置１という。また、キャッシュレジスタ装置３は、以降、レジスタ装置３という。

【００２０】

続きを表示（全53行）

図２は、サーバ装置１のハードウェア構成図である。サーバ装置１としては、通常のパーソナルコンピュータ装置と同様のハードウェア構成とすることができる。すなわち、サーバ装置１は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ハードディスクドライブ（ＨＤＤ）１４、入出力インターフェイス（Ｉ／Ｆ）１５、および通信Ｉ／Ｆ１６を有する。ＣＰＵは、「Central Processing Unit」の略記である。ＲＯＭは、「Read Only Memory」の略記である。ＲＡＭは、「Random Access Memory」の略記である。ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ＨＤＤ１４、入出力Ｉ／Ｆ１５および通信Ｉ／Ｆ１６は、バスライン１７で互いに通信可能に接続されている。

【００２１】

ＣＰＵ１１は、ＲＯＭ１２、ＲＡＭ１３またはＨＤＤ１４等の記憶部に予め記憶されるサーバ用アプリケーションプログラム（以下、ＳＡＰという）に従い、ＲＡＭ１３等をワークメモリとして用いて動作し、サーバ装置１全体の動作を制御する。すなわち、第１の実施の形態のコミュニケーションシステムを実現するアプリケーションプログラムは、上述のＳＡＰ，携帯端末装置にインストールされる携帯用アプリケーションプログラム（ＫＡＰ）、およびレジスタ装置３にインストールされるレジスタ装置用アプリケーションプログラム（ＲＡＰ）で構成されている。サーバ装置１のＨＤＤ１４等には、ＳＡＰが記憶されている。

【００２２】

なお、図２に示す例は、ＨＤＤ１４にＳＡＰが記憶された例を示している。ＳＡＰは、ネットワーク４上の他のコンピュータ装置からダウンロードしてもよい。また、これに限らず、ＳＡＰは、インストール可能な形式または実行可能な形式のファイルでＣＤ、ＤＶＤ等のコンピュータ装置で読み取り可能な記録媒体に記録して提供してもよい。

【００２３】

図３は、サーバ装置１の機能ブロック図である。この図３に示す各機能は、ＳＡＰのみでソフトウェア的に実現してもよいし、ソフトウェアおよびハードウェアで実現してもよいし、ハードウェアのみで実現してもよい。図３に示すように、サーバ装置１は、通信制御部５１、ＩＤ生成部５２、およびデータベース管理部５３を有している。ＩＤ生成部５２は、レジスタ装置３から送信される、利用者が商品またはサービス等を購入した金額に対応するポイント情報を、サーバ装置１で登録するための登録識別番号（登録ＩＤ）を生成する。なお、ポイントとは、利用者が商品またはサービス等を購入した際に付与される、商品等を購入した店舗、商品等を購入した店舗と提携している提携店舗等で、物品の購入、または物品の交換等に使用可能な金銭的価値を有する点数である。

【００２４】

通信制御部５１は、第２送信部の一例であり、サーバ装置１と携帯端末装置２との間、およびサーバ装置１とレジスタ装置３との間の通信を制御する。通信制御部５１は、レジスタ装置３から送信されたポイント情報を受信し、ＩＤ生成部５２で生成された登録ＩＤを携帯端末装置２に送信する。データベース管理部５３は、記憶制御部の一例であり、例えば図２に示すＨＤＤ１４をデータベースとして、各店舗の店舗ＩＤ、各利用者の利用者ＩＤ、各利用者が利用した店舗毎の利用回数、各利用者により登録された店舗毎のポイント等を記憶し管理する。なお、この例の場合、ＨＤＤ１４が記憶部の一例となる。

・・・ 中 略 ・・・

【００４０】

図３に示すサーバ装置１の通信制御部５１は、レジスタ装置３から送信されたポイント情報、および店舗ＩＤを受信制御する。また、サーバ装置１のＩＤ生成部５２は、店舗から受信したポイント情報をデータベースに登録するための登録ＩＤを生成（発行）する。通信制御部５１は、生成された登録ＩＤを、ステップＳ２において、レジスタ装置３に送信する。また、データベース管理部５３は、発行した登録ＩＤ、店舗ＩＤ、およびポイント情報を関連付けてデータベースに記憶する。

【００４１】

以下に説明するが、実施の形態のコミュニケーションシステムの場合、利用者が登録ＩＤを用いてポイントの登録操作を行った際に、店舗から発行されたポイントが、サーバ装置１のデータベースに本登録される。このため、サーバ装置１が、発行した登録ＩＤ、店舗ＩＤ、およびポイント情報を関連付けてデータベースに記憶する段階は、いわばポイントの仮登録段階であると言える。

・・・ 中 略 ・・・

【００４９】

図９に、サーバ装置１のデータベースに登録されたポイント情報等の登録例を示す。図９に示す例の場合、各利用者が利用した店舗、利用回数、および取得ポイント（積算ポイント）が、それぞれ関連付けられてデータベースに登録されている。この図９は、「ｒｙｓ１」の利用者ＩＤを有する利用者が、「ａｂ１」の店舗ＩＤの店舗に、過去５回来店し、合計で８００ポイント分の商品の購入、またはサービスの提供を受けたことを示している。また、図９は、「ｒｙｓ１」の利用者ＩＤを有する利用者が、「ａｄ２」の店舗ＩＤの店舗に過去１５回来店し、合計で２５００ポイント分の商品の購入、またはサービスの提供を受けたことを示している。さらに、この図９は、「ｒｙｓ３」の利用者ＩＤを有する利用者が、「ｄｄ４」の店舗ＩＤの店舗に過去７回来店し、合計で７０ポイント分の商品の購入、またはサービスの提供を受けたことを示している。

【００５０】

次に、実施の形態のコミュニケーションシステムにおいては、以下に説明するコミュニティサービスを提供している。まず、図１０は、利用者が、所望の店舗情報の表示を指定した際に、携帯端末装置２の表示部２６に表示される店舗情報の一例である。この場合、利用者は、所望の場所でＫＡＰを起動してコミュニケーションシステムにログインし、周囲の店舗の検索を指定操作する。この指定操作がなされると、図５に示す携帯端末装置２の情報取得部５８は、図４に示す位置検出部２７から携帯端末装置２の現在位置を取得し、サーバ装置１に転送する。

【００５１】

サーバ装置１は、携帯端末装置２の現在位置周辺の店舗をデータベースから検索し、各店舗の店舗名、住所、および電話番号の一覧画面を携帯端末装置に送信する。携帯端末装置２の表示制御部６０は、サーバ装置１から受信した、例えば図１０に示すような一覧画面を表示部２６に表示する。利用者は、一覧画面の中から、店舗情報の閲覧を希望する店舗を選択操作する。この選択操作により、情報取得部５８は、利用者に選択された店舗を示す情報をサーバ装置１に送信して、情報取得要求を行う。

【００５２】

後述するが、サーバ装置１のデータベースには、各利用者および各店舗の様々な情報が記憶されている。サーバ装置１は、取得要求に対応する情報をデータベースから読み出して、利用者の携帯端末装置２または店舗のレジスタ装置３に送信する。今説明中の例の場合、サーバ装置１は、利用者に選択された店舗の店舗情報をデータベースから読み出し、携帯端末装置２に送信する。携帯端末装置２の表示制御部６０は、サーバ装置１から受信した店舗情報を、表示部２６に表示する。

【００５３】

図１１に、携帯端末装置２の表示部２６に表示された店舗情報の表示例を示す。この図１１に示す例の場合、店舗情報として、その店舗に対する利用者の利用回数、その店舗の現在のメイヤーの名前、携帯端末装置２の所有者がメイヤーの称号を与えられるまでに要する店舗の利用回数、および、その店舗から各利用者への広告情報等が表示されている。

【００５４】

具体的に説明すると、このコミュニケーションシステムの場合、サーバ装置１のデータベース管理部５３は、利用者により選択された店舗に対して、最高利用回数を保持している利用者をデータベースから検索する。そして、最高利用回数を保持している利用者を、その店舗のメイヤーとして紹介するための情報を、上述の店舗情報に含めて携帯端末装置２に送信する。これにより、携帯端末装置２に表示された店舗情報の表示画面において、最高利用回数保持者名等が紹介される。

【００５５】

また、サーバ装置１のデータベース管理部５３は、利用者により選択された店舗に対して、最高利用回数を保持している利用者をデータベースから検索した際に、店舗情報の取得要求を行った利用者の、その店舗に対する利用回数をデータベースから検索する。そして、データベース管理部５３は、現在のメイヤーの利用回数と、店舗情報の取得要求を行った利用者の利用回数との差＋１の値を、利用者がメイヤーの称号を与えられるまでに要する店舗の利用回数として算出する。この利用者がメイヤーの称号を与えられるまでに要する店舗の利用回数を示す情報は、上述の店舗情報に含められて携帯端末装置２に送信され表示部２６に表示される。

【００５６】

なお、実施の形態のコミュニケーションシステムの場合、各店舗は、利用回数の代わりに、取得ポイント数を選択可能となっている。この場合、店舗情報として、その店舗に対する利用者の取得ポイント数、その店舗の現在のメイヤー（最高ポイント保持者）の名前、携帯端末装置２の所有者がメイヤーの称号を与えられるまでに要するポイント数、および、その店舗から各利用者への広告情報等が表示される。

【００５７】

次に、図１２は、サーバ装置１のデータベースに登録されている店舗情報の一例となる模式図である。この図１２に示す例の場合、各店舗に付された店舗ＩＤ、複数の店舗で構成されるグループ毎に付与されるグループＩＤ、およびポイントの付与期間が、店舗情報としてデータベースに登録されている。また、図１２に示す例の場合、ポイントの有効期限を示すモード番号、店舗情報の表示形態の表示モード番号、および利用者一人あたりの予算（またはポイント）が、店舗情報としてデータベースに登録されている。

【００５８】

店舗ＩＤは、各店舗がサーバ装置１に対して店舗登録を行った際に、サーバ装置１から付与される、例えばａｂ１、ａｃ１、ｄｄ４等のＩＤとなっている。グループＩＤは、店舗登録を行った際に、店舗側からサーバ装置１に対してグループ登録を希望した際に、対象となるグループに対してサーバ装置１から付与される、例えばｇ１、ｇ２等のＩＤとなっている。付与期間は、ポイントの付与を行う期間であり、店舗側が店舗情報の編集時等に指定する。

【００５９】

有効期限モードは、利用者に付与したポイントの有効期限を示す。データベースには、ポイントの有効期間を示すモード番号で登録されている。図１３は、ポイントの有効期間を示すモード番号表である。店舗側の担当者は、店舗情報の編集時等に、自店舗が発行するポイントの有効期限に対応するモード番号を、図１３に示すモード番号表を参照して指定する。例えば、自店舗が発行するポイントの有効期限が無しの場合は、「１」のモード番号を指定する。また、例えば２０１３年１月１日～２月１０日等のように、発行したポイントに有効期限を付加する場合、「２」のモード番号を指定する。

【００６０】

表示モードは、店舗の利用者の携帯端末装置２に表示される店舗情報の表示形態を示す。データベースには、店舗情報の表示形態が、表示モード番号で登録されている。図１４は、店舗情報の表示形態を示すモード番号表である。店舗側の担当者は、店舗情報の編集時等に、自店舗が希望する表示形態に対応する表示モード番号を、図１４に示すモード番号表を参照して指定する。例えば、自店舗の全ての利用者を取得ポイントが多い順に全員表示する場合、「１」の表示モード番号を指定する。また、自店舗の利用回数が多い５人の利用者と共に、本人を表示する場合、「２」の表示モード番号を指定する。また、自店舗の利用回数が多い全ての利用者を順に表示する場合、「３」の表示モード番号を指定する。また、自店舗の取得ポイントが多い５人の利用者と共に、本人を表示する場合、「４」の表示モード番号を指定する。

【００６１】

平均予算（ポイント）は、店舗側がレジスタ装置３で「平均予算＝総売り上げ÷利用者数」、または、「平均付与ポイント＝総発行ポイント数÷利用者数」の演算を行い、この演算結果をサーバ装置１に登録したものである。

【００６２】

このような第１の実施の形態のコミュニケーションシステムは、以下の効果を得ることができる。

【００６３】

取得ポイントに応じてメイヤー等の名誉的な利益を与えることで、各利用者は、ポイントの取得を目的として店舗に来店する。店舗では、実際に商品を購入、またはサービスの提供を受けた利用者に対してのみ、ポイントを付与する。このため、利用者は、必ず店舗で商品等を購入することとなり、確実に売り上げを上げることができる。従って、利用者は上述の名誉的な利益を得ることができ、店舗側は確実に売り上げを上げることができ、利用者および店舗の双方のシステム導入を促進可能なコミュニケーションシステムを提供することができる。

【００６４】

また、図１４を用いて説明したように、取得ポイント数の多い他の利用者と共に、本人の取得ポイント数を表示することで、本人である利用者は、自分が常連客ランキングのどの位置にいるのか認識することができる。なお、常連客ランキングの位置に応じて、ボーナス等の名目で利用者にポイントを付与してもよい。また、利用者は、所望の店舗に来店して商品を購入し、レシートに印刷された二次元コードを撮像して、サーバ装置１に送信するだけで一連の動作は完結する。また、実名やプロフィール写真は不要である。このため、簡単かつ安全なコミュニケーションシステムを提供できる。

【００６５】

また、店舗側は、サーバ装置１のデータベースに登録されている各利用者の利用回数等を参照することで、常連客を把握できる。また、利用者登録時に、各利用者のメールアドレスの入力を求め、取得することで、常連客に対して、店舗の広告情報をメール送信する等のアプローチを可能とすることができる。」

２ 引用文献２について

原査定及び当審の拒絶の理由に引用された引用文献２（特開２０１３－１２０４１８号公報）には、次の事項が記載されている。

「【技術分野】

【０００１】

本発明は、ユーザからのクーポン送信等のリクエストに対して、利用シーンに応じてユーザをランク付けし、ランクに応じた情報を送信するための情報送信サーバ、情報送信プログラム及び情報送信方法に関するものである。」

「【００６０】

尚、ユーザデータベース１５におけるユーザのクーポンの利用実績の記録方法は、図８に示した例に限定されるものではなく、例えば、地区、業態、時間帯毎に集計した利用回数等に関するデータを記録しておき、上記のＳ４では、利用回数を個々の利用実績をカウントすることによって行うのではなく、対応する地区、業態、時間帯について集計された利用回数を読み取ることによって行ってもよい。

【００６１】

また、利用シーンの区分は、図８に示した地区、業態、時間帯に限定されるものではなく、例えば、曜日、利用人数などその他の区分を用いるものであってもよい。利用実績に関する情報についても、利用シーンの区分別の利用回数に限定されるものではなく、例えば、利用金額を用いることとしてもよいし、一定の期間を区切った利用回数や利用金額を対象にすることとしてもよい。

続きを表示（全12行）

【００６２】

利用シーンに対応した利用回数が演算されると、ユーザランク決定部１３は、図６にも示したように、利用シーン毎の利用回数をランク定義テーブル１６と対照させ（Ｓ５）、ユーザのランクを決定する（Ｓ６）。ランク定義テーブル１６には、例えば、図９～１１に示したように、利用シーン別の利用回数に応じたランクの決定方法が定義されている。

【００６３】

図９は、同じ利用シーンでの利用実績のみからランクを決定するパターンにおける、ランク定義テーブル１６の一例を示したものである。ユーザがリクエストしたクーポンの店舗と同じ地区や同じ業態の店舗をどの程度利用したことがあるか、同じ時間帯のクーポンをどの程度利用しているかによってユーザのランクが決定され、この例では各々のランクについて設定された全ての条件を満たす（「ゴールド」であれば、同地区での利用回数５回以上、かつ同業態での利用回数５回以上、かつ同時間帯での利用回数５回以上）場合に、そのランクに該当するものと決定される。

【００６４】

このように、クーポンを発行する店舗だけでなく、同地区や同業態の店舗での利用実績からユーザのランクを決定することによって、同地区において、同業態の店舗をよく利用しているユーザ（例えば、恵比寿でよくラーメン店を利用しているユーザ）に対しては、クーポンを発行する店舗への利用実績に関わりなく潜在的な優良顧客としてランク付けを高く設定し、優先的なサービスを提供することで新たな顧客の囲い込みを図ることが可能になる。

【００６５】

図１０は、同じ利用シーンにおける利用実績のみでなく、利用シーンの限定されないユーザに関する情報も用いてランクを決定するパターンにおける、ランク定義テーブル１６の一例を示したものである。このパターンでは、ユーザがリクエストしたクーポンの店舗と同じ地区、同じ業態、同じ時間帯といった利用シーン毎の利用回数のみでなく、クーポンのトータルの利用回数や、マイクロブログにおけるユーザのフォロワー数など、利用シーンの限定されないユーザに関する情報がランク付けの条件として定義されている。」

「【００６９】

以上のようにしてユーザのランクが決定されると、クーポン発行部１４では、クーポン情報１７からクーポンの生成に必要な値引率等の情報を読み出し、携帯端末２０にクーポン画面を出力させるためのファイルを生成する（Ｓ７）。このクーポン画面には、決定されたユーザのランクが反映された情報が含まれている。

【００７０】

例えば、ユーザのランクに応じて、画面に異なる色彩を用いることとしてもよいし、ランク毎に異なる値引率（例えば、ブロンズは１０％、ゴールドは３０％、プラチナは５０％）などのインセンティブを適用して、画面に表示させることとしてもよい。このようにして生成された、ユーザのランク付けが反映されたクーポン画面を出力するためのファイルが、レスポンスとして携帯端末２０に返信され（Ｓ８）、図７に示したように、携帯端末２０のディスプレイに表示される。」

３ 引用文献３について

原査定の拒絶の理由に引用された引用文献３（米国特許出願公開第２０１７／０１０９７７６号明細書）には、次の事項が記載されている。なお、引用文献３の記載事項は、当審の訳文で示す。

「発明が属する技術分野

[0001]この発明は、デバイス間の通信および認証に関する。より詳細には、本発明は、ベンダーが選択した顧客セグメントに腐敗しやすい製品の在庫に関する動的価格設定割引の提案の生成に関するものである。」

「[0049]いくつかの実施形態では、クライアントデバイス203は、追加の情報をサーバ201に伝送する。例えば、クライアントデバイス203は、ベンダーが受け入れることをいとわない割引の最大額を記述したデータをサーバ201に送信することができる。追加データは、割引または提案を見ることができるようにし、対象者を特定することができる。例えば、ベンダーは、他の特性を有する特定の年齢範囲、所得範囲内の顧客、または他の顧客が、適用可能な法律と矛盾しないように新しい顧客、既存の顧客、旅行者、顧客を誘引することに特に関心がある場合がある。

[0050]いくつかの実施形態では、システム200は、少なくとも1つのユーザによって償還可能な割引の提案を生成する。クライアントデバイス203は、割引の提案の潜在的な受信者である複数のユーザを識別するデータを有することができる。システム200は、複数のユーザプロファイルへのアクセスを有してもよく、ユーザプロファイルは、ベンダークライアントデバイス203によってローカルに格納することができる。ユーザプロファイルは、サーバ201によって遠隔的に格納された、クラウドベースのストレージプロトコル、または他の任意のサーバ側データ記憶プロトコルを使用してもよい。複数のユーザプロファイルは、ユーザがシステム200を利用するとき、作成することができ、例えば、ユーザは、ユーザがシステム200と対話することを可能にする、顧客クライアントデバイス202を取得するときに、ユーザがプロファイルデータを提供することができる。ユーザプロファイルは、ユーザがシステムを使用するベンダーから購入した場合に作成することができる。ユーザプロファイルは、外部供給源から生成されてもよい。例えば、ユーザがソーシャルネットワークアカウントを有している場合があり、プロファイルがそれに基づいて生成されてもよい。プロファイルは、ユーザ活動によって入力されてもよい。ユーザ活動は、システム200とのユーザ相互作用を含む。ユーザ活動はベンダーとのユーザ相互作用を含むことができる。ユーザ活動は、外部ソースとユーザ活動、検索履歴、ソーシャルネットワーク相互作用などを含むことができる。ユーザ活動は、当該ユーザの位置、および他のベンダーとの対話、顧客クライアントデバイス202とベンダーのデバイスから収集されたユーザプロファイルの強化のために定期的に使用することを含んでもよい。

[0051]ユーザプロファイルによって追跡される属性は、ユーザがどの製品を好むかを含むことができ、異なるオファーに興味を有するユーザの過去の関心によって決定される。例えば、ユーザに提供された過去の取引のために、ユーザのサービスに対する関心の度合いは、ユーザがその取引に基づいて行動したか否かから判定することができる。ユーザプロファイルは、ユーザがベンダーの新顧客又は既存の顧客であるか否かを示す情報を含んでいてもよい。ユーザプロファイルは、ユーザが住んでいる場所を決定する場合がある。いくつかの実施形態では、これは、ユーザが入力したデータと、ユーザの住所等に基づいている。他の実施形態では、顧客クライアントデバイス202は、クライアント位置に関するサーバ201への定期的な更新を送信すると、サーバ201では、夜の時間の大部分を費やしているのか、更新に基づいて調べることができる。同様に、サーバ201は、ユーザが平日の日中の時間の大部分を費す場所を調べることによって働いているか、または勉強しているのかを判断することができる。システム200は、企業を特定するのに合わせた位置と前記地図データとを使用することにより、例えば、ユーザが訪れた、システム200に参加している双方のビジネスおよび他の企業を含む種々のビジネス企業を見ることで使用者のおよその年齢を決定することができ、ユーザが訪れている事業の種類を決定することができる。システム200はまた、ユーザの年齢グループを決定するために、ソーシャルネットワーク情報を使用することができる。同様の習慣的なデータを使用して、システム200は、ユーザが旅行者であると決定してもよく、ユーザは、ユーザが現在の作業または非作業位置近傍に配置されている。ユーザ反応を割引額を予測するモデルは、ユーザプロファイルに含まれてもよい。

[0052]いくつかの実施形態では、サーバ201は、割引の提案を生成する。他の実施形態では、ベンダークライアントデバイス203は、割引の提案を生成する。サーバ201とベンダークライアントデバイス203は、割引の提案を生成するプロセスの一部を実行することができる。例えば、ベンダークライアントデバイス203は、提案のための金額及び期間を生成することができ、サーバ201は、以下に更に詳細に記載されているように、割引の提案を送信するユーザを選択することができる。

[0053]いくつかの実施形態では、システム200は、複数のユーザの各ユーザについてありそうなユーザ挙動のモデルを構築する。モデルは、ユーザに関して収集された大量のデータに基づくことができ、データはユーザプロファイルを作成又は埋めるために使用される任意のデータであってもよい。いくつかの実施形態では、並列アルゴリズムして、各ユーザに対して迅速に行動モデルを構築するために使用される。このモデルは、過去のユーザの挙動に基づいて予測を生成することができる。モデルは、ユーザへの接続を有する、ソーシャルネットワーク上の友人などの他のユーザの以前の挙動に基づいて予測を提供することができる。モデルは、1日の時間、ベンダー、割引の提案、および、他の要因に基づいて、システム200が、ランダムに人に割引を提供するシステムよりも効率的にすることを可能にし、ユーザは、必要に応じて生成した割引の提案を受諾すると、以下でさらに詳細に説明する可能性を増大させるという予測に作用することができる。

[0054]いくつかの実施形態では、モデルはサーバ201によって構築される。他の実施形態では、ベンダークライアントデバイス203。モデルは、ベンダークライアントデバイス203とサーバ201との組により構築されてもよい。

[0055]複数のユーザの特定のユーザは、システム200によってランク付けすることができる。いくつかの実施形態では、ランク付けは、ベンダークライアントデバイス203によって実行される。いくつかの実施形態では、ランク付けは、サーバ201によって実行される。ランク付けは、全てのベンダーに対して包括的であり得る、またはランキングは、各ベンダーのベンダー・クラスに特有であってもよい。即ち、複数のユーザの一人のユーザは、映画館内のレストランを高くランク付けすることができ、又は別の1つのレストランを高くランク付けすることができる。いくつかの実施形態では、ユーザが、好みの購入に応じてランク付けされる。他の実施形態では、ユーザは、一貫性に応じてランク付けされる、換言すれば、ユーザが、提案された傷みやすい品目を予約したならば、ユーザは、提案を引き換える際に成功する可能性がどれだけあるかにしたがってランク付けされ、以下に更に詳細に記載されている。ユーザが正直さに従ってランク付けすることができる;例えば、最初のユーザは、以下でさらに詳細に説明するように、最初の割引の提案を要求する、そうしようと試みないように、２番目のユーザが２番目の割引の提案を要求することを示す２番目のユーザより低くランク付けされてよい。ベンダーシステム200は、いくつかの閾値未満の正直な評価を有するユーザに取引に提供しないことを決定することもでき、あるいは、ベンダーまたはシステム200は、ベンダーに非常に近い場合にのみ低い正直者格付けの顧客に取引を提案することを決定すると、システム200は、低い正直者格付けより望ましくないベンダーへの提供をユーザに提供することができる、またはシステム200が高い不公正なランキングと同様のユーザよりもより少ない量を有する割引を提供するのかを決定することができる。

[0056]複数のユーザの一人のユーザは、ユーザがシステム200のベンダーと購入をする頻度に従ってランク付けすることができる。ユーザは、ユーザがシステム200の割引を引き換える頻度に従ってランク付けすることができる。ユーザは、関連付けられたユーザのランクに応じてランク付けされてもよい;例えば、”friends”、または”connections”ランクの高いソーシャルメディア上でユーザの活動とは、ユーザの順位を増大させることができる。ユーザは、さらに追加の特色に基づいてランク付けすることができる。いくつかの実施形態では、システム200によって発生される各ユーザ毎のランク付けは、システム200は、ユーザが割引の提案を送信することを選択する効率を改善し、ランキングを使用することなくユーザを選択するシステムと比較した。

[0057]システム200は、割引の提案を受信する複数のユーザの少なくとも1人のユーザを選択することができる。いくつかの実施形態では、システム200は、少なくとも1人のユーザが割引券を償還することを試みるであろうという可能性に基づいて少なくとも1つのユーザを選択する。例えば、システム200が近くにいるユーザを選択することができる。システム200は、少なくとも1つのユーザに関連する、顧客クライアントデバイス202から、顧客クライアントデバイス202に結合されたナビゲーションデバイスによれば、顧客クライアントデバイス202の地理的位置を示す情報を受信し、ベンダーに地理的位置からの距離を計算し、前記距離が閾値量未満である場合に、システム200は、少なくとも1つのユーザを選択することができる。システム200は、少なくとも1つのユーザがしきい値時間内に到着することができる可能性がある場合の地理的位置を地図データと比較すること、および少なくとも1つのユーザを選択することができる。システム200は、顧客クライアントデバイス202から振れ検出データを用いて、少なくとも1人のユーザが車両又は歩行を乗車しているか否かを判定することができる。システム200は、複数のユーザの他のユーザは、ベンダーのしきい値期間または距離内にいくつあるかに基づく少なくとも1つのユーザを選択することができる。いくつかの実施形態では、ベンダーの時間または距離閾値内に複数のユーザがいる場合、システム200は、ユーザがベンダーに最近傍に基づいて少なくとも1つのユーザを選択し、最も近いベンダーから地理的に近い、または時間の最小量を意味することができる。他の実施形態では、ベンダーの要求のために必要なより市販されているしきい値の範囲内のユーザの数が多い場合、ユーザは、ランダムに、又は、上で計算したようにランキングに応じてそれらの中から選択される。」

４ 引用文献４について

原査定及び当審の拒絶の理由に引用された引用文献４（特開２０１４－１７０３５８号公報）には、次の事項が記載されている。

「【技術分野】

【０００１】

本発明はデータ処理技術に関し、特にユーザの購買実績に対して特典を提供する技術に関する。」

「【００１２】

情報処理システム１００では、複数のユーザのそれぞれが予め定められた地域内で商品やサービスを購入した実績に応じて、その地域における各ユーザの順位を決定する。そして順位に応じた特典をユーザに提供する特典配信サービスを実現する。特典配信サーバ１２は、特典配信サービスを提供する情報処理装置である。特典配信サーバ１２の詳細構成は後述する。

【００１３】

特典配信サービスが対象とする地域は、実世界における地図上の特定の領域であり、以下では「対象地域」と呼ぶ。対象地域は、市区町村等の単位で特定される領域であってもよく、町丁目の単位で特定される領域であってもよく、商店街等の単位で特定される領域であってもよい。また対象地域は、ユーザへ特典を提供する主体でもあり、ユーザの購買実績を集計する単位になり、また典型的には特典によるメリットをユーザが享受可能な地域である。「特典」は、ユーザが実施する経済活動、典型的には商品やサービスの購入において各種の利益や便宜をユーザに提供することを約束するものであり、種々の態様が考えられる。例えば各種のクーポンでもよく、具体的には金券、割引券、引換券、提供範囲を限定した広告、特別なサービスの提供を約束するサービス券等であってもよい。

続きを表示（全18行）

【００１４】

ユーザ端末１０ａ、ユーザ端末１０ｂ、ユーザ端末１０ｃ、・・・・は、特典配信サービスを利用する複数のユーザにより操作される情報機器である。実施の形態では、ユーザが常時持ち運ぶ携帯情報端末であり、例えば携帯電話機やスマートフォンである。ユーザ端末１０は、おサイフケータイ（登録商標）機能を有し、店舗端末と連携して電子マネーによる商品代金やサービス代金の電子決済を実行する。またユーザ端末１０は、ＧＰＳ（Global Positioning System）機能を有し、端末の現在位置（緯度および経度）を識別可能である。

【００１５】

ユーザは、ユーザ端末１０を介して特典配信サーバ１２にアクセスし、ユーザ登録を行う。その際にユーザ端末１０は、ユーザが特典を獲得した旨の通知（以下、「特典獲得通知」とも呼ぶ。）を、特典配信サーバ１２からユーザ端末１０へプッシュ通知させるために必要な自身の個体識別情報を特典配信サーバ１２に登録する。変形例として、メール通知させる場合には、ユーザ端末１０のメールアドレスを特典配信サーバ１２に登録してもよい。特典配信サーバ１２は、ユーザＩＤを採番し、ユーザＩＤとユーザ端末１０の個体識別情報を対応づけて記憶する。またユーザは、購買実績を特典配信サーバ１２に登録するためのクライアントアプリケーションを特典配信サーバ１２からダウンロードして、ユーザ端末１０にインストールする。

【００１６】

このクライアントアプリケーションは、ユーザ端末１０のおサイフケータイ機能が電子決済処理を実行したことを検出すると、電子決済にてユーザが支払った金額を示す情報を支払金額として取得する。例えば、おサイフケータイ機能のプログラムモジュールから取得する。それとともに、ユーザ端末１０の現在位置（すなわちユーザが商品またはサービスを購入した位置）を示す緯度および経度を購買位置としてＧＰＳ機能のプログラムモジュールから取得する。またクライアントアプリケーションは、ユーザ端末１０のおサイフケータイ機能が電子決済処理を実行したことを検出すると、ユーザが購買を実施した日時を示す購買日時として現在日時を取得する。クライアントアプリケーションは、ユーザＩＤ・購買日時・購買位置・支払金額を対応づけた購買実績情報を特典配信サーバ１２へ送信し、ユーザの購買実績を特典配信サーバ１２に登録する。

【００１７】

またユーザ端末１０にはウェブブラウザがインストールされている。ユーザ端末１０は、特典配信サーバ１２から通知された特典獲得通知とのリンクが張られたウェブページであり、ユーザが獲得した特典を提示するウェブページ（以下、「特典詳細ページ」とも呼ぶ。）を特典配信サーバ１２から取得する。そしてウェブブラウザの機能により特典詳細ページの内容をディスプレイに表示させる。

【００１８】

図２は、特典詳細ページを模式的に示す。同図の特典詳細ページ１１０は、対象地域における順位が２位以下のユーザ向けの表示内容を示している。同図の特典詳細ページ１１０は、獲得特典情報１１２と上位特典情報１１４と下位特典情報１１６を含む。獲得特典情報１１２は、ページを提供する対象のユーザ（以下、「ページ提供先ユーザ」とも呼ぶ。）が獲得した特典であり、当該ユーザの順位に予め対応づけられた特典の具体的な内容、言い換えれば特典の具体的な価値を示す情報である。

【００１９】

上位特典情報１１４は、ページ提供先ユーザよりも上位のユーザに対して、ページ提供先ユーザに提供した特典より相対的に価値の高い特典（以下、「上位特典」とも呼ぶ。）を提供した事実を示す情報である。ただし上位特典情報１１４は、上位特典の存在を抽象的に示唆する内容にとどまる。すなわち特典配信サーバ１２は、上位特典情報１１４として、上位特典の具体的な内容、言い換えれば、上位特典の具体的な価値の大きさを排除した情報を設定する。

【００２０】

その一方、下位特典情報１１６は、ページ提供先ユーザよりも下位のユーザに対して、ページ提供先ユーザに提供した特典より相対的に価値の低い特典（以下、「下位特典」とも呼ぶ。）を提供した事実を示す情報である。特典配信サーバ１２は、下位特典情報１１６として、下位特典の具体的な内容、言い換えれば、下位特典の具体的な価値の大きさを示す情報を設定する。」

「【００２５】

次に特典配信サーバ１２の構成を詳細に説明する。

図４は、特典配信サーバ１２の機能構成を示すブロック図である。特典配信サーバ１２は、通信処理部２０とデータ保持部２２と制御部２４を備える。制御部２４は、特典配信サービスのためのデータ処理を実行・制御する。データ保持部２２は、制御部２４により処理されるデータや、各種設定情報を記憶する記憶領域である。通信処理部２０は、通信網１４を介して、ユーザ端末１０から送信された通信データを受信して制御部２４に渡す。また制御部２４から出力された通信データを、通信網１４を介してユーザ端末１０へ送信する。特典配信サーバ１２はウェブサーバ機能も有するが、ウェブサーバ機能そのものは公知であるため説明を省略する。

【００２６】

本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図４の制御部２４の各機能ブロックは、プログラムモジュールとしてＤＶＤ等の記録媒体に格納され、特典配信サーバ１２のストレージへインストールされてもよい。そして、特典配信サーバ１２のメインメモリに読み込まれて、特典配信サーバ１２のＣＰＵが実行することで、各機能ブロックの機能が発揮されてもよい。また図４のデータ保持部２２の各機能ブロックは、メインメモリやストレージにより実現されてもよい。

【００２７】

データ保持部２２は、特典情報保持部３０とユーザ情報保持部３２と地図情報保持部３４を有する。特典情報保持部３０は、特典配信サーバ１２に予め登録された特典に関する情報を保持する。ユーザ情報保持部３２は、特典配信サーバ１２に登録済みのユーザに関する情報を保持する。地図情報保持部３４は、実世界の地図情報を保持する。この地図情報は、例えば、緯度・経度の組み合わせと、実世界の住所との対応関係を含む。」

「【００３０】

図５（ａ）および（ｂ）で示すように、順位が上になるほど、ユーザの経済活動における価値が高い特典（もしくは複数の特典の組み合わせ）が対応づけられる。言い換えれば、順位が下のユーザほど獲得できる特典の金銭的価値、すなわち、金銭に換算した場合の価値は低くなっていく。図５の例では、１位のユーザには合計１９００円分の金券＋アイスを提供する一方、２位のユーザには１４００円分の金券、３位のユーザには７００円分の金券を提供することとしている。

【００３１】

図６は、ユーザ情報保持部３２に格納されるデータの構成を示す。ユーザ情報保持部３２は、特典配信サービスにユーザ登録した複数のユーザそれぞれのユーザＩＤと、端末情報（例えばユーザ端末１０の個体識別情報）と、購買実績情報とを対応づけて保持する。購買実績情報は、購買活動を実施した日時を示す購買日時と、その購買活動にてユーザが金銭を支払った地図上の位置（住所）を示す購買位置と、支払金額とを対応づけた情報である。各ユーザの購買実績を集計する所定期間（例えば１０日間等）においてユーザが複数回購買活動を実施した場合、それぞれの購買活動の実績を示す複数個の購買実績のレコードが記録される。

続きを表示（全12行）

【００３２】

図４に戻り、制御部２４は、購買実績取得部４０と、特典付与部４２と、特典画面作成部４４と、特典通知部４６を有する。購買実績取得部４０は、ユーザ端末１０から送信されたユーザＩＤ・購買日時・購買位置・支払金額が対応づけられた購買実績情報を受信し、ユーザＩＤで特定されるユーザ情報保持部３２のレコードに購買実績情報を記録する。その際に、購買位置については、ユーザ端末１０から通知された緯度経度情報を、地図情報保持部３４の地図上にマッピングして地図上の住所を特定し、その住所を購買位置として記録してもよい。

【００３３】

なお、実施の形態では購買実績情報をユーザ端末１０から取得するが、他の方法により購買実績情報を取得してもよい。例えば、商品代金の電子決済においてユーザ端末１０と連携する店舗側端末が、ユーザ端末１０から取得したユーザＩＤと、購買日時（現在日時）と、購買位置（予め定められた端末の設置位置）と、支払金額（販売金額）とを対応づけたユーザの購買実績情報を特典配信サーバ１２へ送信してもよい。また、電子決済システムにおいてユーザによる電子決済の履歴を記録する他の装置、例えば金融機関の装置等が、ユーザの購買実績情報を特典配信サーバ１２へ送信してもよい。

【００３４】

さらにまた、購買位置の情報はユーザ端末１０のＧＰＳ機能が特定してユーザ端末１０が特典配信サーバ１２へ通知する一方、支払金額の情報は店舗側の端末等、他の装置が特典配信サーバ１２へ通知してもよい。特典配信サーバ１２は、これらの情報に共通するＩＤ（例えばユーザＩＤ＋購買日時）にて、これらの情報を紐づけ、購買実績情報として記録してもよい。すなわち購買実績取得部４０は、複数の装置が連携して実現される電子決済システムにおいて少なくとも１つの装置が記録したユーザの購買実績情報を通信網１４を介して取得し、記録する。

【００３５】

特典付与部４２は、予め定められた特典付与タイミングに至ったことを検出すると、ユーザ登録済みの複数のユーザに対する特典付与処理を実行する。例えば、先の特典付与処理を実行後、所定期間（例えば１０日）が経過したことを検出すると、対象地域における複数のユーザそれぞれの支払金額に応じて各ユーザに付与する特典を決定する。特典付与部４２の詳細な構成は後述する。」

「【００４２】

特典付与部４２は、購買実績抽出部５０と、順位決定部５２と、特典割当部５４と、活動範囲特定部５６を含む。購買実績抽出部５０は、ユーザ情報保持部３２に格納された各ユーザの購買実績情報を参照して、１つ以上の購買実績の中から、購買位置が対象地域に含まれる購買実績情報を集計対象として抽出する。言い換えれば、ユーザ毎に、１つ以上の購買実績の中から、ユーザの順位を決定する要素となり、ユーザの順位に影響を与える購買実績情報を特定する。

【００４３】

順位決定部５２は、対象地域における複数のユーザそれぞれの順位を決定する。順位決定部５２は、ユーザ情報保持部３２に格納された各ユーザの購買実績情報のうち購買実績抽出部５０により集計対象として抽出された購買実績情報の支払金額をユーザ単位で集計し、ユーザ間で支払金額を比較する。

続きを表示（全12行）

【００４４】

基本的に順位決定部５２は、支払金額が大きいユーザほど高い順位を付与するよう決定する。ただし順位決定部５２は、購買日時からの経過期間であり、具体的には、購買日時から順位決定日時までの期間が長くなるほど、ユーザ間で比較するための計算上のユーザの支払金額を大きく減算し、実際の支払金額よりも小さい値とする。また順位決定部５２は、ユーザに複数回の購買実績がある場合、各購買における支払金額を各購買日時からの経過時間に応じてそれぞれ漸減させ、残余の支払金額の合計を、計算上のユーザの支払金額として決定する。このようなユーザの支払金額を調整する例を図７および図８に示す。なお図７はユーザＡ、図８はユーザＢの支払金額に関するものとする。

【００４５】

図７に示すように、実施の形態の順位決定部５２は、ユーザＡの支払金額の大小によらず、購買日時から１４日間（２週間）が経過すると支払金額を０にするよう購買日時からの時間経過に伴ってユーザＡの支払金額を漸減させていく。したがって、ユーザの実際の支払金額が大きいほど、単位期間あたりの減算額は大きくなる。図７の例では、ユーザＡによる実際の支払金額は１万円であるものの、購買日時から１０日後の順位決定タイミングでは、ユーザＡの支払金額を２８５７円として取り扱うことを示している。

【００４６】

図８では、ユーザＢが、順位決定タイミングの１０日前（買物１）と５日前（買物２）の２回、購買活動を行った例を示している。買物１における支出金額は４千円であるが、順位決定タイミングでは１１４２円に減算する。また買物２における支出金額は３千円であるが、順位決定タイミングでは１９２８円に減算する。ここでユーザＡとユーザＢを比較する。実際の支払金額はユーザＡ（１万円）がユーザＢ（７千円）より大きいにもかかわらず、調整後の支払金額はユーザＡ（２８５７円）よりユーザＢ（３０７０円）が大きくなる。この場合、順位決定部５２は、ユーザＢに対してユーザＡより高い順位を付与し、その結果、ユーザＢの方がユーザＡより価値が高い特典を獲得することになる。

【００４７】

このように順位決定部５２は、購買日時からの経過時間が長くなるほど、ユーザ間で比較するための計算上のユーザの支払金額を小さくするよう調整する。これにより、あるユーザが１回多額の支払を行っても、そのユーザが何回もの順位決定処理に亘り常に上位になってしまうことを抑制し、特定のユーザが特典を長期間独占することを防止できる。また、支払金額の多寡によらず、購買日時から固定期間の経過により支払金額を一定値（実施の形態では０）にするよう調整することで、相対的に少ない回数しか購買活動をしていないユーザより、相対的に多くの回数、購買活動をしたユーザを、順位決定において有利に取り扱う。これにより、特典提供の対象地域（例えば特定の町丁目や商店街等）に、多くの回数、来訪して購買活動をすることへのインセンティブをユーザに与え、対象地域へのユーザの来訪頻度を高めることができる。その結果、対象地域に存在する複数の店舗へのユーザの来店を促進し、また、対象地域の活性化も支援できる。」

「【００５２】

以上の構成による情報処理システム１００の動作を以下説明する。

ユーザは、クーポン提供の対象地域において金銭を支出する経済活動（典型的には商品やサービスの購入）を実施し、ユーザ端末１０を使用して商品代金やサービス代金を電子決済する。ユーザ端末１０は、購買実績情報を特典配信サーバ１２へ送信する。特典配信サーバ１２の購買実績取得部４０は、複数のユーザそれぞれの購買実績情報を取得して、ユーザ情報保持部３２に蓄積していく。特典配信サーバ１２の順位決定部５２は、対象地域における各ユーザの購買実績情報にもとづいて、対象地域における各ユーザの順位を決定する。特典割当部５４は、特典情報保持部３０に設定された順位とクーポンとの対応関係にしたがって、相対的に順位が高いユーザに、相対的に金銭的な価値が高いクーポンを割り当てる。」

そうすると、引用文献４には、次の発明（以下、「引用発明」という。）が記載されている。

「クライアントアプリケーションが、ユーザ端末１０のおサイフケータイ機能が電子決済処理を実行したことを検出すると、ユーザＩＤ・購買日時・購買位置・支払金額を対応づけた購買実績情報を特典配信サーバ１２へ送信するものにおいて、

特典配信サーバ１２は、データ保持部２２と制御部２４を備え、

データ保持部２２は、ユーザ情報保持部３２を有し、

制御部２４は、購買実績取得部４０と特典付与部４２を有し、

購買実績取得部４０は、ユーザ端末１０から送信されたユーザＩＤ・購買日時・購買位置・支払金額が対応づけられた購買実績情報を受信し、ユーザＩＤで特定されるユーザ情報保持部３２のレコードに購買実績情報を記録し、

特典付与部４２は、購買実績抽出部５０と順位決定部５２を含み、

購買実績抽出部５０は、ユーザ情報保持部３２に格納された各ユーザの購買実績情報を参照し、１つ以上の購買実績の中から、購買位置が対象地域に含まれる購買実績情報を集計対象として抽出し、

順位決定部５２は、対象地域におけるユーザの支払金額が大きいユーザほど、高い順位を付与するようにそれぞれの順位を決定し、

相対的に順位が高いユーザに、相対的に金銭的な価値が高いクーポンを割り当てる、

特典配信サーバ１２。」

５ 引用文献５について

原査定及び当審の拒絶の理由に引用された引用文献５（特開２００６－０１１７００号公報）には、次の事項が記載されている。

「【技術分野】

【０００１】

本発明は、利用量に応じた特典付与システムに関し、特に、商取引の対象となる会員を登録し、各会員に対して、商取引の利用金額などの量に応じて、ポイントの付与などの特典を与えるシステムに関する。」

「【背景技術】

【０００２】

物品の購入や、役務の利用を促進させるための手段として、予め会員を募り、各会員の利用金額に応じて、ポイントの付与などの特典を与えるサービスが普及している。たとえば、大手百貨店や商店街などでは、募集した会員に、それぞれ会員カードを発行しておき、各会員が、会員カードを提示して物品の購入などを行った場合には、購入金額に応じたサービスポイントを付与するようにし、貯まったサービスポイントと引き換えに、景品を与えるようなサービスを行っている。また、信販会社では、会員にクレジットカードを発行し、このクレジットカードの利用金額に応じて、所定のサービスポイントを付与し、景品などと引き換えるサービスを行うことにより、クレジットカードの利用を促進させている。更に、大手家電量販店などでは、購入金額に応じたサービスポイントを付与し、貯まったサービスポイントを、自社店舗での新たな物品の購入に充てることができるようにして、利用金額の一定割合を会員に還元するサービスも行われている。もちろん、このようなサービスの提供は、実在の店舗だけでなく、インターネット上の仮想店舗でも同様に行われている。

【０００３】

続きを表示（全11行）

このように、会員の利用金額に応じて、サービスポイントを付与する処理を行うシステムに関する工夫として、たとえば、下記の特許文献１には、複数種類のポイントシステムを１枚の統一した会員カードで管理できるようにする技術が開示されている。また、下記の特許文献２には、会員にカードを所持させることなしに、サービスポイントの付与管理を行うための技術が開示されている。

【特許文献１】特開２００１-２９０９９５号公報

【特許文献２】特開２００２-１６３５２８号公報

【発明の開示】

【発明が解決しようとする課題】

【０００４】

上述した一般的な特典付与システムは、現在、極めて広い分野に普及してきており、会員に対する利用促進効果も鈍化する傾向にある。たとえば、商品の購入額１００円につき１ポイントを付与し、貯まったポイントを、１ポイント＝１円相当で新たな物品の購入に充てることができるサービスや、１ポイント＝１円相当の価値をもった景品と引き換えることができるサービスは、いずれも、利用金額の１％を会員に還元する、という運用形態になるが、このような運用形態はもはや陳腐化してきており、会員の利用意欲を惹起する効果的な手段にはなっていない。」

「【００２１】

たとえば、大手百貨店や商店街などが事業を展開する場合、顧客となる個々の会員ごとの購入履歴に関する情報が、取引サーバ３００内に蓄積される。具体的には、取引サーバ３００内には、購入履歴に関する情報として、個々の会員が、いつ、どの商品を、いくらで購入したか、といった情報が格納されることになる。一方、特典付与システム１００は、この購入履歴に関する情報に基づいて、特典付与のための処理を行う機能を有し、たとえば、個々の会員について、いつ、何ポイントが付与され、何ポイントが還元のために使用され、残存するポイントは何ポイントか、といった情報を管理することができる。

【００２２】

同様に、クレジットカードを発行する信販会社が事業を展開する場合、個々の会員ごとの利用履歴に関する情報が、取引サーバ３００内に蓄積され、大手家電量販店などが事業を展開する場合、個々の会員ごとの購入履歴に関する情報が、取引サーバ３００内に蓄積される。また、インターネット上で仮想店舗を運営する会社が事業を展開する場合は、取引サーバ３００自身が、仮想店舗の運営に必要な処理作業を行うことになる。

続きを表示（全30行）

【００２３】

いずれにせよ、この取引サーバ３００自身は、従来から利用されている公知の装置であり、顧客となる個々の会員に対する商取引に必要な処理を実行する機能を有している。本発明に係る特典付与システム１００は、この取引サーバ３００によって処理される商取引に、更に特典付与の機能を付加するためのものである。

【００２４】

一方、携帯電話１０およびパソコン２０は、会員端末として利用される装置であり、個々の会員は、この会員端末から、取引サーバ３００にアクセスしたり、特典付与システム１００にアクセスしたりすることができる。取引サーバ３００が、インターネット上での仮想店舗を提供するサーバの場合、各会員は、会員端末から取引サーバ３００へとアクセスし、物品の購入などの手続を行うことになる。また、後述するように、特典付与システム１００は、各会員に情報提示を行う機能を有しているが、この情報提示は、会員端末に対して行われる。会員は、携帯電話１０やパソコン２０の画面上で、提示された情報を閲覧することができる。

【００２５】

また、カードリーダ３０は、店舗端末として利用される装置である。たとえば、顧客としての会員が、実在の店舗において、クレジットカードを利用して代金決済を行う場合、当該クレジットカードの情報や決済情報がカードリーダ３０によって読み取られ、取引サーバ３００へと送られることになる。なお、パソコン２０などを店舗端末として設置しておけば、会員端末と同様に、特典付与システム１００から提供された情報を表示することができる。店舗を来訪した会員は、この店舗端末の画面上で、提供された情報を閲覧することが可能である。

【００２６】

続いて、特典付与システム１００の構成および機能について説明する。図示のとおり、特典付与システム１００は、会員情報登録部１１０、情報提示部１２０、順位決定部１３０、合計算出部１４０、特典付与処理部１５０の各要素によって構成されており、商取引の対象となる会員を登録し、各会員に対して、商取引の利用量に応じた特典を付与する機能を有する。もっとも、これらの各構成要素は、実際には、サーバ用コンピュータなどに専用のプログラムを組み込むことにより具現化されるものであり、特典付与システム１００は、実際には、専用のプログラムを組み込んだコンピュータによって実現されるシステムである。また、ここでは説明の便宜上、特典付与システム１００と取引サーバ３００とを別な構成要素として取り扱っているが、特典付与システム１００と取引サーバ３００とは、同一のサーバ用コンピュータを利用して構築することが可能である。実際には、取引サーバ３００として機能している既存のサーバ用コンピュータに、特典付与システム１００として機能する専用のプログラムを追加することにより本発明を実施するのが最も実用的な形態である。もちろん、この場合、特典付与システム１００と取引サーバ３００とは、ネットワークを介することなく、直接、情報のやりとりを行うことができる。

【００２７】

本発明の基本概念は、各会員の特定期間内の利用合計量を求め、この利用合計量の多い順に各会員に順位を定め、この順位に応じて各会員に所定の特典を付与する処理を行うようにする点にある。以下、図示の各構成要素１１０～１５０の機能を説明する。なお、以下の実施形態では、説明の便宜上、「利用合計量」として「利用合計額」を用いた例を示すことにするが、「利用合計量」としては必ずしも金額を用いる必要はなく、たとえば、「利用合計回数」、「利用合計頻度」、「商品の購入個数」などを用いてもかまわない。

【００２８】

まず、会員情報登録部１１０は、各会員の個人情報を登録するための構成要素であり、たとえば、図２に示すような情報が登録される。すなわち、図２に示す例では、個々の会員について、会員ＩＤ、氏名、住所、電子メールアドレスといったデータが、個人情報として登録されている。この他、個々の会員の性別、年齢、電話番号、認証用パスワードなどのデータを個人情報として登録することができる。なお、このような個人情報は、通常、取引サーバ３００内にも登録されている情報であるので、実用上、会員情報登録部１１０は、取引サーバ３００内の同等の機能要素を流用して構成することが可能である。

【００２９】

合計算出部１４０は、各会員について、特定期間内の利用合計額を算出する処理を行う。図示の実施形態の場合、前述したように、取引サーバ３００内には、各会員ごとに、利用年月日や利用金額に関する情報が格納されている。そこで、合計算出部１４０は、この情報に基づく集計を行うことにより、各会員についての特定期間内の利用合計額を算出する演算を実行することができる。集計対象となる特定期間は、キャンペーンの実施期間として任意の期間を設定しておけばよい。たとえば、１ヶ月単位でそれぞれキャンペーンを実施することにすれば、１月のキャンペーン期間は１月１日～１月３１日となり、この期間が集計対象となる特定期間に設定される。２月１日は、２月のキャンペーン期間に繰り入れられる。

【００３０】

図３は、１月のキャンペーン期間である１月１日～１月３１日を特定期間に設定した場合に、１月２３日午後８時３０分の現在時点における合計算出部１４０の算出結果の一例を示す図である。まだ、キャンペーン期間の途中であるため、期間内の最終的な利用合計額を算出することはできないが、とりあえず現時点までの各会員の利用合計額が算出されている。合計算出部１４０は、このように、必要に応じて、現時点までの利用合計額を算出する機能を有しており、１月３１日深夜２４時の時点における算出結果が、１月のキャンペーン期間における最終的な利用合計額になる。

【００３１】

順位決定部１３０は、合計算出部１４０が算出した利用合計額に基づいて、各会員の現時点での順位を決定する処理を行う。図３に示すように、合計算出部１４０によって、各会員の現時点での利用合計額が算出されているので、合計算出部１４０は、利用合計額の多い順に各会員をソートする処理を行うことにより、順位を決定することができる。こうして決定された順位は、情報提示部１２０によって、各会員に対して提示される。具体的な提示態様については後述する。

【００３２】

特典付与処理部１５０は、特定期間終了時点において、順位決定部１３０で決定された順位に基づいて、各会員に所定の特典を付与するための処理を行う。前述の例の場合、１月３１日深夜２４時が、１月のキャンペーン期間の終了時点となるので、この時点での最終的な順位に基づいて、各会員に所定の特典を付与する処理が行われる。順位に基づいて、どのような特典を付与するかは、予め設定しておく。実用上は、会員数がかなり多くなるので、連続した一群の順位により１つのグループが構成されるように複数のグループを定義しておき、各グループごとに、それぞれ異なる特典を設定しておくのが好ましい。

【００３３】

図４は、このようなグループごとの特典設定例を示す図である。この例では、各グループごとに、翌月のポイント率（店舗での利用金額に対して与えられるサービスポイントの割合）が定義されている。すなわち、１位～１０位までが所属するグループＧ１には、翌月のポイント率を５％とする特典が与えられ、１１位～５０位までが所属するグループＧ２には、翌月のポイント率を３％とする特典が与えられ、５１位～１００位までが所属するグループＧ３には、翌月のポイント率を２％とする特典が与えられ、１０１位～５００位までが所属するグループＧ４には、翌月のポイント率を１％とする特典が与えられ、５０１位以降が所属するグループＧ５には、翌月のポイント率を０．５％（通常のポイント率）とする特典が与えられることになる。また、順位１位の会員には、更に、ボーナスポイントとして１０００ポイントの特典が与えられる。

【００３４】

特典付与処理部１５０は、このような設定に基づいて、各会員ごとに所定の特典を付与するために必要な処理を行う。具体的には、順位１位の会員については、ボーナスポイント１０００ポイントを付加する処理を行う。また、グループＧ１～Ｇ５に所属する各会員については、翌月からそれぞれ設定されたポイント率で、利用金額に対するポイントを付与する処理を行う。図示の例の場合、２月のキャンペーン期間内の各会員の利用については、指示されたとおりのポイント率で、ポイントの付与処理を行うことになる。特典付与処理部１５０は、このように、各会員ごとのサービスポイントの付与履歴を管理するとともに、会員がサービスポイントを利用して何らかの特典を得た場合には、利用したポイント分を減じる管理も行うことになる。

【００３５】

続いて、情報提示部１２０による情報提示の具体的な態様を説明する。図５は、情報提示部１２０による具体的な情報提示態様の一例を示す図である。この例は、上述したような１月のキャンペーン期間が設定されている場合において、その途中の時点、すなわち、１月２３日午後８時３０分の時点における情報提示を行った例である。図示のとおり、この例では、各会員の利用合計額をその順位に従って並べて示した一覧表の形式で情報提示が行われている。具体的には、各会員ＩＤに対応させて、今回のキャンペーン期間中における現在の順位、現在の利用合計額、現在の状態で与えられる特典（翌月のポイント率）およびボーナスポイントが示されている。また、右端には会員欄が設けられており、ここに、この一覧表上における自己の位置を示す情報（図示の例では、「あなたの順位」なる文言）が表示されている。この例では、一覧表上における自己の位置をより明確に示すために、自己の順位に対応する行のみを太字のイタリック体表示にしてある（実際には、特別色による表示を行うのが好ましい）。」

６ 引用文献６について

原査定の拒絶の理由に引用された引用文献６（話題のコード決済アプリの便利な活用法とセキュリティホール ＰａｙＰａｙ超入門，ラジオライフ，日本，２０１９年２月５日，第４０巻 第５号，第２２－２４頁）には、次の事項が記載されている。

「レジ周りにＰａｙＰａｙアイコンのポップなどが設置されていれば、ＰａｙＰａｙ対応店舗である目印。店員に「ＰａｙＰａｙで支払います！」と伝え、ＰａｙＰａｙを起動しましょう。

ＰａｙＰａｙでの支払い方法は店舗により、２パターンあります。１つ目が、自身のバーコードを表示して、それを店側に読み込んでもらう提示型。２つ目は逆に、店側のＱＲコードをＰａｙＰａｙで読み込み、支払金額を送金する方法です。」（第２４頁左欄１行ないし右欄２行）

７ 引用文献７について

原査定の拒絶の理由に引用された引用文献７（韓国公開特許第１０－２０１８－０１１９１４３号公報）には、次の事項が記載されている。なお、引用文献７の記載事項は、当審の訳文で示す。

「技術分野

[0001]本発明は使用者の課金内訳情報を収集する方法に関することで、より詳しくはモバイルデバイス上で使用者の課金内訳情報を収集する方法に関する。」

「[0038]図３を参照すると、本発明の一実施例による方法は、所定のアプリマーケットに使用者のアカウント情報を利用してログインする段階（Ｓ１０１）、前記アプリマーケットの前記使用者の課金内訳ページに近付く段階（Ｓ１０２）、前記課金内訳ページを構成するコードを分析して前記課金内訳ページ内に含まれた課金内訳情報を抽出する段階（Ｓ１０３）、前記課金内訳情報を利用して前記使用者の所定の期間の間の課金額を合算した実績課金額を算出する段階（Ｓ１０４）、前記実績課金額を基に前記使用者の等級を決める段階（Ｓ１０５）を含む。本発明の一実施例によるモバイルデバイス上で使用者の課金内訳情報を収集する方法を順に説明する。」

「[0042]Ｓ１０４段階で、前記所定の期間は現在時点から最近の一定期間を含まないこともある。具体的に、図１８を参照すると、前記所定の期間は現在時点から第１時点までの期間を除いて、前記第１時点から過去の第２時点までの期間で構成されることができる。すなわち、第２時点から第１時点までの期間が実績算出期間になって、第１時点から現在時点までの期間は実績除外期間になりうる。例えば、実績算出期間は３ヶ月の期間で、実績除外期間は１週間（７日）の期間に設定されうるが、これに制限されるものではない。前記実績算出期間を現在時点から第１時点までの期間を除くことで、後述する等級上昇などを目的に短期間（７日）に過度な金額を課金する行為を防止することができる効果を有する。」

「[0046]図５を参照すると、本発明のまた他の実施例による方法は前記使用者の等級が所定の等級なら、前記使用者に所定の提携クーポンを提供する段階（Ｓ１０７）をさらに含む。」

上記記載から引用文献７には、以下の事項（以下、「引用文献７記載事項」という。）が記載されている。

「使用者の所定の期間の間の課金額を合算した実績課金額を算出し、前記実績課金額を基に前記使用者の等級を決める方法において、等級上昇などを目的に短期間に過度な金額を課金する行為を防止するために、現在時点から第１時点までの期間を除いて、前記第１時点から過去の第２時点までの期間で構成された期間を、所定の期間とすること。」

８ 引用文献８について

原査定及び当審の拒絶の理由に引用された引用文献８（特開２０１２－１５０７１２号公報）には、次の事項が記載されている。

「【技術分野】

【０００１】

本発明は、所定の地域において生産された生鮮食品を購入した顧客に対しボーナスポイントを付与するシステムに関する。」

「【０１３９】

本実施形態のポイントラリーシステム１００は、購入金額に対して一律にポイントを還元するのではなく、指定された産地の生鮮食品の購入金額に対してポイントを還元することで、顧客に対し地産地消の取り組みへの経済的インセンティブを与え、地産地消の促進が期待できる。

また、指定された産地の生鮮食品の購入割合に基づいてランキングを特定することにより、顧客間の競争意識を刺激し、地産地消の促進がより期待できる。さらに、最低購入金額を設定することにより、例えば指定された産地の生鮮食品を１つ購入して購入割合が１００％となる顧客をランキングの対象外とする。そして、最低購入金額以上を購入した顧客をランキングの対象とすることで、ボーナスポイントを公平に付与することができる。」

第６ 対比・判断

１ 本願発明１について

（１）対比

本願発明１と引用発明とを対比すると、次のことがいえる。

ア 引用発明の「ユーザＩＤ・購買日時・購買位置・支払金額を対応づけた購買実績情報」は、「ユーザＩＤ」を含むことから、複数のユーザの購買実績を対象としており、また「購買位置」を含むことから、複数の事業者により提供される複数の店舗での購買実績を対象としているといえる。

そうすると、引用発明の「ユーザＩＤ・購買日時・購買位置・支払金額を対応づけた購買実績情報」と、本願発明１の「複数の利用者が複数の事業者により提供される複数の店舗で行った所定のコードによる決済手段に関する決済の履歴」とは、「複数の利用者が複数の事業者により提供される複数の店舗で行った決済の履歴」である点で共通する。

そして、引用発明は、この「購買実績情報」を「購買実績取得部４０」で受信しているから、引用発明「購買実績取得部４０」と本願発明１の「取得部」とは、「複数の利用者が複数の事業者により提供される複数の店舗で行った決済の履歴を取得する取得部」である点で共通する。

イ 引用発明の「順位決定部５２」は、「対象地域におけるユーザの支払金額が大きいユーザほど、高い順位を付与するようにそれぞれの順位を決定し」ているから、対象地域を指定しているといえる。

そうすると、引用発明の「順位決定部５２」は、本願発明１の「店舗、利用者又は地域の少なくとも一つに関する条件が指定された場合に、当該指定された条件である指定条件を満たす各利用者の決済に関する順位を示す順位情報を生成する生成部」に相当する。

ウ そして、引用発明の「特典配信サーバ１２」は「順位を決定」していることから、引用発明の「特典配信サーバ１２」と、本願発明１の「所定のコードを用いた決済サービスを提供する生成装置」とは、「生成装置」である点で共通する。

エ そうすると、本願発明１と引用発明との一致点及び相違点は、次のとおりとなる。

［一致点］

「生成装置であって、

複数の利用者が複数の事業者により提供される複数の店舗で行った決済の履歴を取得する取得部と、

店舗、利用者又は地域の少なくとも一つに関する条件が指定された場合に、当該指定された条件である指定条件を満たす各利用者の決済に関する順位を示す順位情報を生成する生成部と

を有し、

前記生成部は、前記利用者による決済のうち、決済を行った店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する

ことを特徴とする生成装置。」

［相違点１］

本願発明１は、「所定のコードを用いた決済サービスを提供する生成装置」であるのに対して、引用発明は、「おサイフケータイ機能」の「電子決済処理」を対象とした、「特典配信サーバ」であって、決済サービスを提供する生成装置とはいえるものの、対象とする「決済サービス」が、「所定のコードを用いた決済サービス」であるとはいえない点。

［相違点２］

本願発明１は、「複数の利用者が複数の事業者により提供される複数の店舗で行った所定のコードによる決済手段に関する決済の履歴を取得する取得部」を有しているのに対して、引用発明は「所定のコードを用いた決済サービス」を対象としていないために、引用発明の「購買実績取得部４０」は、「複数の利用者が複数の事業者により提供される複数の店舗で行った所定のコードによる決済手段に関する決済の履歴を取得する」とはいえない点。

［相違点３］

本願発明１の「前記生成部」は、「前記利用者による決済のうち、決済を行った店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」のに対して、引用発明の「順位決定部５２」は、対応する特定事項を備えていない点。

（２）相違点についての判断

事案に鑑み、上記相違点３について先に検討すると、相違点３に係る本願発明１の「前記生成部」が、「前記利用者による決済のうち、決済を行った店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」点は、上記引用文献１ないし３及び５ないし８には記載されておらず、原出願日前において周知技術であるともいえない。

なお、令和２年１２月２２日付けの拒絶理由通知書では、本願発明１の上記相違点３に係る構成に対応する補正前の請求項９に係る発明について、引用文献７に記載されている旨記載している。しかしながら、引用文献７には、上記引用文献７記載事項に示すように、「使用者の所定の期間の間の課金額を合算した実績課金額を算出し、前記実績課金額を基に前記使用者の等級を決める方法において、等級上昇などを目的に短期間に過度な金額を課金する行為を防止するために、現在時点から第１時点までの期間を除いて、前記第１時点から過去の第２時点までの期間で構成された期間を、所定の期間とすること」が記載されており、引用文献７に記載された「所定の期間」は、「現時点から第１時点までの期間を除いて、前記第１時点から過去の第２時点までの期間で構成された期間」であって、上記相違点３に係る「前回行われた決済から経過した時間が所定の閾値を超える」期間とは、異なる期間であり、上記相違点３の構成が引用文献７に記載されているとはいえない。

したがって、他の相違点について判断するまでもなく、本願発明１は、当業者であっても、引用発明及び引用文献１ないし３及び５ないし８に記載された技術的事項に基づいて容易に発明をすることができたものであるとはいえない。

２ 本願発明２及び１７について

本願発明２ないし１７も、上記相違点３に係る「前記生成部は、前記利用者による決済のうち、前記指定店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」点を備えているから、本願発明１と同じ理由により、当業者であっても、引用発明及び引用文献１ないし３及び５ないし８に記載された技術的事項に基づいて容易に発明をすることができたものであるとはいえない。

３ 本願発明１８及び１９について

本願発明１８及び１９は、それぞれ本願発明１に対応する「生成方法」及び「生成プログラム」の発明であり、上記相違点３に係る本願発明１の「前記生成部は、前記利用者による決済のうち、前記指定店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」ことに対応する、「前記生成工程は、前記利用者による決済のうち、決済を行った店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」こと、及び「前記生成手順は、前記利用者による決済のうち、決済を行った店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」ことを備えているから、本願発明１と同様の理由により、引用発明及び引用文献１ないし３及び５ないし８に記載された技術的事項に基づいて容易に発明をすることができたものであるとはいえない。

第７ 原査定についての判断

令和４年５月２７日にされた手続補正により、補正後の請求項１ないし１７は、「前記生成部は、前記利用者による決済のうち、前記指定店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」という技術的事項を備え、補正後の請求項１８は、「前記生成工程は、前記利用者による決済のうち、決済を行った店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」という技術的事項を備え、補正後の請求項１９は、「前記生成手順は、前記利用者による決済のうち、決済を行った店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」という技術的事項を備えるものとなった。

当該事項は、原査定における引用文献１ないし８に記載されておらず、原出願日における周知技術でもないので、本願発明１ないし１９は、当業者であっても、原査定における引用文献１ないし８に基づいて容易に発明をすることができたものではない。

したがって、原査定を維持することはできない。

第８ 当審拒絶理由についての判断

令和４年５月２７日にされた手続補正により、補正後の請求項１ないし１７は、「前記生成部は、前記利用者による決済のうち、前記指定店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」という技術的事項を備え、補正後の請求項１８は、「前記生成工程は、前記利用者による決済のうち、決済を行った店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」という技術的事項を備え、補正後の請求項１９は、「前記生成手順は、前記利用者による決済のうち、決済を行った店舗の属性に関する情報に応じて設定された時間であって、前回行われた決済から経過した時間が所定の閾値を超える決済に基づいて、前記順位情報を生成する」という技術的事項を備えるものとなった結果、当審拒絶理由は解消した。

第９ むすび

以上のとおり、原査定の理由及び当審拒絶理由によって、本願を拒絶することはできない。

他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。