(57)【特許請求の範囲】
【請求項１】
所定のプラットフォームを介して取引対象の注文を受け付ける店舗に関する営業状態に係る現在情報を取得する取得部と、
前記現在情報と、前記店舗に関して予め定められた営業形態に係る登録情報とを照らし合わせ、営業状態と営業形態について比較し、前記現在情報と前記登録情報とが不一致な状態であるか否かを判定する判定部と、
前記判定部で前記現在情報と前記登録情報とが不一致な状態であると判定された場合、前記不一致な状態の是正を前記店舗に対してリクエストするためのリクエスト手段を前記所定のプラットフォームを介して前記店舗を利用する利用者に提供する提供部と、
を備える提供装置。
【請求項２】
前記提供部は、前記リクエスト手段によりリクエストされた内容を前記店舗に提供する請求項１に記載の提供装置。
【請求項３】
前記現在情報は、前記店舗の現在の営業状態を含み、
前記登録情報は、前記店舗の予め定められた営業時間を含み、
前記判定部は、前記営業時間内に前記店舗の現在の営業状態が営業中でない場合、前記現在情報と前記登録情報とが不一致な状態であると判定する、
請求項１または請求項２に記載の提供装置。
【請求項４】
前記現在情報は、前記店舗の現在の所在地を含み、
前記登録情報は、前記店舗の予め定められた所在地を含み、
前記判定部は、前記店舗の現在の所在地と前記予め定められた所在地とが異なる場合、前記現在情報と前記登録情報とが不一致な状態であると判定する、
請求項１から請求項３のいずれか一項に記載の提供装置。
【請求項５】
前記現在情報は、前記取引対象に関する現在の取引対象情報を含み、
前記登録情報は、前記取引対象に関する予め定められた取引対象情報を含み、
前記判定部は、前記現在の取引対象情報と前記予め定められた取引対象情報とが異なる場合、前記現在情報と前記登録情報とが不一致な状態であると判定する、
請求項１から請求項４のいずれか一項に記載の提供装置。
【請求項６】
前記現在情報は、前記取引対象が前記利用者に提供可能となった通知情報を含み、
前記登録情報は、前記取引対象を提供するための作業が完了するまでの設定時間の情報を含み、
前記判定部は、前記取得部から前記現在情報を取得し、所定のデータベースから前記取引対象を提供するための作業が完了するまでの設定時間を取得し、前記設定時間に基づいて決定される商品が受領可能となる予定の時間内に、前記通知情報が前記所定のプラットフォームを介して前記利用者に提供されなかった場合、前記現在情報と前記登録情報とが不一致な状態であると判定する、
請求項１から請求項５のいずれか一項に記載の提供装置。
【請求項７】
前記取得部は、前記利用者の取引回数を示す履歴情報を取得し、
前記提供部は、前記利用者の前記取引回数に応じて、前記リクエストの内容を前記店舗に提供する態様を変更する、
請求項１から請求項６のいずれか一項に記載の提供装置。
【請求項８】
前記提供部は、前記リクエスト手段の一つとして、前記利用者が商品の受け取り予定時刻を所定時間だけ遅らせて欲しい旨のリクエストを行うための手段を提供する請求項１から請求項７のいずれか一項に記載の提供装置。
【請求項９】
コンピュータが実行する提供方法であって、
所定のプラットフォームを介して取引対象の注文を受け付ける店舗に関する営業状態に係る現在情報を取得する取得工程と、
前記現在情報と、前記店舗に関して予め定められた営業形態に係る登録情報とを照らし合わせ、営業状態と営業形態について比較し、前記現在情報と前記登録情報とが不一致な状態であるか否かを判定する判定工程と、
前記判定工程で前記現在情報と前記登録情報とが不一致な状態であると判定された場合、前記不一致な状態の是正を前記店舗に対してリクエストするためのリクエスト手段を前記所定のプラットフォームを介して前記店舗を利用する利用者に提供する提供工程と、
を含むことを特徴とする提供方法。
【請求項１０】
所定のプラットフォームを介して取引対象の注文を受け付ける店舗に関する営業状態に係る現在情報を取得する取得手順と、
前記現在情報と、前記店舗に関して予め定められた営業形態に係る登録情報とを照らし合わせ、営業状態と営業形態について比較し、前記現在情報と前記登録情報とが不一致な状態であるか否かを判定する判定手順と、
前記判定手順で前記現在情報と前記登録情報とが不一致な状態であると判定された場合、前記不一致な状態の是正を前記店舗に対してリクエストするためのリクエスト手段を前記所定のプラットフォームを介して前記店舗を利用する利用者に提供する提供手順と、
をコンピュータに実行させることを特徴とする提供プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、提供装置、提供方法および提供プログラムに関する。
【背景技術】
【０００２】
従来、来店前の利用者による店舗への事前注文に関するサービスを提供する技術が知られている。このような技術の一例として、ユーザがネットワークを介してデリバリーサービスやテイクアウトサービスに対して注文を行うウェブサイトにアクセスし、店舗に対して注文を行う技術が提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第６３２５７５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記の従来技術では、事前注文サービスを行う店舗に関して予め登録された情報と、店舗の現在の状況を示す現在情報とに不一致が生じている場合、その旨を店舗に対して適切に報知することができるとは限らない。
【０００５】
例えば、上記の従来技術では、ユーザが利用可能な店舗をウェブサイト上でサジェストするに過ぎず、本来は利用可能な店舗が営業時間になっても営業していない場合等、登録情報と現在の状況とに不一致が生じている場合に、不一致が生じている旨を店舗に対して適切に報知することができるとは限らない。
【０００６】
本発明は、上記に鑑みてなされたものであって、事前注文サービスを行う店舗に関する登録情報と、店舗に関する現在情報とに不一致が生じている場合に、不一致の是正をリクエストすることができる提供装置、提供方法および提供プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するために、本発明にかかる提供装置は、所定のプラットフォームを介して取引対象の注文を受け付ける店舗に関する現在情報を取得する取得部と、前記現在情報と、前記店舗に関して予め定められた登録情報とを照らし合わせ、前記現在情報と前記登録情報とが不一致な状態であるか否かを判定する判定部と、前記判定部で前記現在情報と前記登録情報とが不一致な状態であると判定された場合、前記不一致な状態の是正を前記店舗に対してリクエストするためのリクエスト手段を前記所定のプラットフォームを介して利用者に提供する提供部と、を備える。
【発明の効果】
【０００８】
本発明にかかる提供装置、提供方法および提供プログラムは、事前注文サービスを行う店舗に関する登録情報と、店舗に関する現在情報とに不一致が生じている場合に、不一致の是正をリクエストすることができるという効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施形態に係る提供処理の一例を示す図である。
【図２】図２は、実施形態に係る利用者端末の画面の一例を示す図である。
【図３】図３は、実施形態に係る決済サーバの構成例を示す図である。
【図４】図４は、実施形態に係る口座データベースの一例を示す図である。
【図５】図５は、実施形態に係る事業者情報データベースの一例を示す図である。
【図６】図６は、実施形態に係る利用者情報データベースの一例を示す図である。
【図７】図７は、実施形態に係る提供処理の手順の一例を示すフローチャートである。
【図８】図８は、決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。
【発明を実施するための形態】
【００１０】
以下に本願に係る提供装置、提供方法及び提供プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る提供装置、提供方法及び提供プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。
【００１１】
〔１．実施形態〕
図１を用いて、本実施形態の提供装置等により実現される提供処理について説明する。図１は、実施形態に係る提供処理の一例を示す図である。なお、図１では、本実施形態に係る提供装置の一例である決済サーバ１０によって、実施形態に係る提供処理などが実現されるものとする。
【００１２】
図１に示すように、実施形態に係る提供処理システム１は、決済サーバ１０と、利用者端末１００と、事業者端末２００とを含む。決済サーバ１０、利用者端末１００及び事業者端末２００は、ネットワークＮ（例えば、図３参照）を介して有線または無線により相互に通信可能に接続される。ネットワークＮは、例えば、インターネットなどのＷＡＮ（Wide  Area  Network）である。なお、図１に示した提供処理システム１には、複数台の決済サーバ１０、複数台の利用者端末１００及び複数台の事業者端末２００が含まれていてもよい。
【００１３】
図１に示す決済サーバ１０は、実施形態に係る提供処理を実行する情報処理装置であり、サーバ装置やクラウドシステム等により実現される。例えば、決済サーバ１０は、利用者端末１００を用いる電子決済に関する電子決済サービスを提供する。例えば、決済サーバ１０は、取引対象の提供者（事業者）や取引対象が提供される利用者の口座を管理しており、利用者からの決済要求に従って、口座間において電子マネーの移行等を行うことで、各種決済を実現する。なお、電子マネーとは、例えば、各種企業が独自に用いるポイントや通貨等であってもよく、日本円やドル等の国家により提供される貨幣を電子的に取引可能としたものであってもよい。
【００１４】
また、決済サーバ１０は、飲食店向けの事前注文サービスを提供する。例えば、決済サーバ１０は、利用者端末１００を用いる電子決済用のアプリケーション（以下、単に「決済アプリ」と記載する場合がある）内で起動するアプリケーション（ミニアプリ）において事前注文サービスを提供する。以下、事前注文サービスを提供するアプリケーションを単に「事前注文アプリ」と記載する場合がある。
【００１５】
例えば、決済サーバ１０は、電子決済サービスを管理する（言い換えると、電子決済サービスに関する処理を制御する）決済管理部と、事前注文サービスを管理する（言い換えると、事前注文サービスに関する処理を制御する）注文管理部とを有する。そして、決済管理部及び注文管理部は、それぞれ共通キー（例えば、事前注文サービスを介した利用者からの注文を識別するための注文番号）を用いて利用者からの注文の内容（例えば、取引対象や、決済金額）を特定し、それぞれのサービスに関する処理を実行する。
【００１６】
図１に示す利用者端末１００は、利用者によって利用される情報処理装置である。利用者端末１００は、例えば、スマートフォンや、タブレット型端末、ノート型ＰＣ（Personal  Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal  Digital  Assistant）等により実現される。また、利用者端末１００は、決済サーバ１０によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１に示す例では、利用者端末１００がスマートフォンである場合を示す。
【００１７】
図１に示す事業者端末２００は、利用者に取引対象を提供する事業者によって利用される情報処理装置である。事業者端末２００は、例えば、スマートフォンや、タブレット型端末、ノート型ＰＣ、デスクトップＰＣ、携帯電話機、ＰＤＡ等により実現される。また、事業者端末２００は、決済サーバ１０によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１に示す例では、事業者端末２００がスマートフォンである場合を示す。
【００１８】
なお、利用者端末１００及び事業者端末２００は、所定の情報処理を実現する制御情報を決済サーバ１０から受け取った場合には、制御情報に従って情報処理を実現する。ここで、制御情報は、例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）等のスクリプト言語やＣＳＳ（Cascading  Style  Sheets）等のスタイルシート言語、Ｊａｖａ（登録商標）等のプログラミング言語、ＨＴＭＬ（HyperText  Markup  Language）等のマークアップ言語等により記述される。なお、決済サーバ１０から配信される所定のアプリケーションそのものを制御情報とみなしてもよい。
【００１９】
〔１−１．利用者端末１００を用いた決済について〕
ここで、決済サーバ１０が実行する提供処理に先立ち、利用者端末１００を用いた決済（電子決済）の一例について説明する。なお、以下の説明では、店舗Ａに配置された２次元コード（ＱＲコード（登録商標））であって、店舗Ａを識別する店舗識別情報を示す２次元コードを用いて、利用者Ｕ１が利用者端末１００を用いた決済を行う例について説明するが、実施形態は、これに限定されるものではない。以下に説明する決済の一例は、任意の利用者が任意の利用者端末１００を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報は、ＱＲコード（登録商標）のみならず、バーコードや所定のマーク、番号等であってもよい。
【００２０】
例えば、利用者Ｕ１が店舗Ａにて各種の商品やサービスといった決済対象（取引対象）の利用や購入に伴う決済を行う場合、利用者Ｕ１は、利用者端末１００に予めインストールされた決済アプリを起動する。そして、利用者Ｕ１は、決済アプリを介して、店舗Ａに設置された店舗識別情報を撮影する。このような場合、利用者端末１００は、決済対象の価格を入力するための画面を表示し、利用者Ｕ１或いは店舗Ａの店員から決済金額の入力を受け付ける。そして、利用者端末１００は、利用者Ｕ１を識別する利用者識別情報と、店舗識別情報（若しくは、店舗識別情報が示す情報、すなわち、店舗Ａを示す情報（例えば、店舗ＩＤ））と、決済金額とを示す決済情報を決済サーバ１０へと送信する。
【００２１】
このような場合、決済サーバ１０は、利用者識別情報が示す利用者Ｕ１の口座から、店舗識別情報が示す店舗Ａの口座へと、決済金額が示す額の電子マネーを移行させる。そして、決済サーバ１０は、決済が完了した旨の通知を利用者端末１００へと送信する。このような場合、利用者端末１００は、決済が完了した旨の画面や所定の音声を出力することで、電子マネーによる決済が行われた旨を通知する。
【００２２】
なお、利用者端末１００を用いた決済は、上述した処理に限定されるものではない。例えば、利用者端末１００を用いた決済は、店舗Ａに設置された店舗端末を用いたものであってもよい。例えば、利用者端末１００は、利用者Ｕ１を識別するための利用者識別情報を画面上に表示させる。このような場合、店舗Ａに設置された店舗端末は、利用者端末１００に表示された利用者識別情報を読み取り、利用者識別情報（若しくは、利用者識別情報が示す情報、すなわち、利用者Ｕ１を示す情報（例えば、利用者ＩＤ））と、決済金額と、店舗Ａを識別する情報とを示す決済情報を決済サーバ１０へと送信する。このような場合、決済サーバ１０は、利用者識別情報が示す利用者Ｕ１の口座から、店舗Ａの口座へと、決済金額が示す額の電子マネーを移行させ、店舗Ａの店舗端末或いは利用者端末１００に対し、決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知してもよい。
【００２３】
また、利用者端末１００を用いた決済は、利用者Ｕ１が予め電子マネーをチャージした口座から店舗Ａの口座へと電子マネーを移行させる処理のみならず、例えば、利用者Ｕ１が予め登録したクレジットカードを用いた決済であってもよい。このような場合、例えば、利用者端末１００は、店舗Ａの口座に対して決済金額の電子マネーを移行させるとともに、利用者Ｕ１のクレジットカードの運用会社に対し、決済金額を請求してもよい。
【００２４】
〔１−２．利用者端末１００を用いた事前注文について〕
さらに、決済サーバ１０が実行する提供処理に先立ち、決済サーバ１０が提供する事前注文サービスを用いた事前注文処理を行う際に利用者端末１００に表示される画面の一例について、図２を用いて説明する。図２は、実施形態に係る利用者端末の画面の一例を示す図である。
【００２５】
なお、以下の説明では、利用者端末１００が、利用者Ｕ１からの操作に応じて予めインストールされた事前注文アプリを起動し、事前注文サービスの加盟店である店舗Ａへの注文内容を決済サーバ１０へ送信済みであるものとする。例えば、利用者端末１００は、店舗Ａが事前注文サービスを介して提供する商品（飲食物）を注文するための注文画面を表示する。そして、利用者端末１００は、注文画面において利用者Ｕ１が行った注文操作を行った商品を示す注文内容を決済サーバ１０に送信する。
【００２６】
図２に示すように、注文内容を決済サーバ１０に送信した後、利用者端末１００は、注文内容が送信されたことを示す画面Ｃ１を表示する。例えば、利用者端末１００は、注文内容に対応する金額（店舗Ａへの決済金額）を示す情報を含む画面Ｃ１を表示する。所定時間が経過した場合や、利用者Ｕ１による所定の操作が行われた場合、利用者端末１００は、画面Ｃ１を、画面Ｃ２に遷移させる。
【００２７】
利用者端末１００は、注文した商品が受け取り可能となる時間を示す情報を含む画面Ｃ２を表示する。例えば、利用者端末１００は、事前注文サービスを介して注文を受け付けてから商品を提供するまでの期間として店舗Ａが設定した期間に基づく時間を画面Ｃ２に表示する。ここで、決済サーバ１０は、注文内容を店舗Ａに設置された店舗端末に送信する。そして、店舗Ａが注文を受注する場合、店舗端末は、店舗Ａの店員からの操作に応じて、注文を受注する旨を示す通知を決済サーバ１０に送信する。この場合、利用者端末１００は、注文が店舗Ａに受注されたことを示す情報を決済サーバ１０から受け付け、画面Ｃ２を、画面Ｃ３に遷移させる。
【００２８】
利用者端末１００は、注文が店舗Ａに受注され、店舗Ａが商品を提供するための作業を行っていることを示す情報を含む画面Ｃ３を表示する。ここで、店舗Ａにおいて作業が完了し、利用者Ｕ１に商品を提供可能となった場合、店舗端末は、店舗Ａの店員からの操作に応じて、商品が提供可能である旨の通知を決済サーバ１０に送信する。そして、利用者端末１００は、商品が提供可能であることを示す情報と、商品を受領するための認証情報（例えば、決済サーバ１０により採番される受け取り番号）を決済サーバ１０から受け付け、画面Ｃ３を、画面Ｃ４に遷移させる。
【００２９】
利用者端末１００は、決済サーバ１０から受け付けた情報を含む画面Ｃ４を表示する。これにより、利用者Ｕ１は、店舗Ａに来店し、店舗Ａの店員に受け取り番号を提示することで商品を受領することが可能となる。そして、利用者Ｕ１が店舗Ａから商品を受領した場合、利用者端末１００は、利用者Ｕ１からの操作に応じて、商品を受領した旨の通知を決済サーバ１０に送信する。
【００３０】
〔１−３．実施形態の概要について〕
ここで、従来、上述したような来店前の利用者による店舗への事前注文に関するサービスを提供する技術が知られている。しかしながら、上記の従来技術では、事前注文サービスを行う店舗に関する登録情報と、店舗に関する現在情報とに不一致が生じている場合、その旨を店舗に対して適切に報知することができるとは限らない。例えば、本来は利用可能な店舗が営業時間になっても営業していないといった、登録情報と現在情報とに不一致が生じている場合、不一致が生じている旨を店舗に対して適切に報知することができるとは限らない。
【００３１】
そこで、決済サーバ１０は、実施形態に係る提供処理を実行する。以下、図１を用いて、決済サーバ１０が実行する情報処理について説明する。なお、以下の説明では、利用者端末１００が利用者Ｕ１により利用され、事業者端末２００が店舗Ａを管理する事業者Ｍ１により利用される例を示す。また、以下の説明では、利用者端末１００を利用者Ｕ１と同一視し、事業者端末２００を事業者Ｍ１及び店舗Ａと同一視する場合がある。すなわち、以下では、利用者Ｕ１を利用者端末１００、事業者Ｍ１及び店舗Ａを事業者端末２００と読み替えることもできる。
【００３２】
また、以下の説明では、決済サーバ１０が提供する電子決済サービスを利用して利用者からの決済を受け付ける店舗Ａ（すなわち、電子決済サービスの加盟店）が、事前注文サービスの加盟店であり、事前注文サービスを介して利用者に商品（飲食物）を提供するものとする。例えば、事業者Ｍ１は、電子決済サービスを利用して利用者に提供する取引対象の商品（例えば、テイクアウト品）に関する取引対象情報を決済サーバ１０に登録し、事前注文サービスを介して利用者からの注文を受け付け、その後来店する利用者に商品を提供する。
【００３３】
また、以下の説明において、決済サーバ１０は、商品名や、価格、説明テキスト、商品画像、商品に付与可能なオプション（商品のサイズや、トッピングなど）、商品を販売する期間などを含む取引対象情報の登録を事前注文サービスの加盟店の事業者等から受け付け、店舗の情報（例えば、店舗ＩＤや、店舗名、所在地、営業時間、など）に紐付けて管理するものとする。
【００３４】
まず、決済サーバ１０は、利用者Ｕ１から事前注文サービスを利用しようとした旨の情報を取得する（ステップＳ１）。すなわち、決済サーバ１０は、利用者Ｕ１が予めインストールされた事前注文アプリを起動し、店舗Ａに対して注文を行う画面を表示させた旨の情報を取得する。このとき、例えば、店舗Ａが本来は開店している営業時間内であるにも関わらず、開店していない状態であると、利用者Ｕ１が所望の注文を行うことができないことになる。
【００３５】
そこで、決済サーバ１０は、ステップＳ１の情報を取得すると、店舗Ａに関する現在情報を取得する（ステップＳ２）。例えば、決済サーバ１０は、店舗Ａの現在の営業状態を取得する。現在の営業状態は、店舗Ａが開店している状態であるか、閉店している状態であるかの別を示す情報である。現在の営業状態は、適宜、事業者Ｍ１から事業者端末２００を介して入力される。例えば、事業者Ｍ１は、事業者端末２００に表示される営業開始のボタンをプッシュし、営業状態を“営業中”とする。また、事業者Ｍ１は、事業者端末２００に表示される営業終了のボタンをプッシュし、営業状態を“営業終了”とする。また、決済サーバ１０は、店舗Ａの現在の所在地を取得する。現在の所在地は、事業者Ｍ１が管理する店舗Ａの現在の位置情報（例えば、住所）である。また、現在の所在地は、例えば店舗Ａが移動型販売店である場合、曜日や時間帯に応じて営業場所が変更される。決済サーバ１０は、例えばＧＰＳ（Global  Positioning  System）センサ等により測位された店舗Ａの現在位置を取得する。なお、決済サーバ１０は、事業者Ｍ１から事業者端末２００を介して入力された店舗Ａの現在位置を取得してもよい。また、決済サーバ１０は、店舗Ａの取引対象に関する現在の取引対象情報を取得する。取引対象情報は、例えば、商品のメニュー、価格、画像等の情報を含む。取引対象情報は、適宜、事業者Ｍ１から事業者端末２００を介して入力される。
【００３６】
続いて、決済サーバ１０は、取得した現在情報と、店舗Ａに関して予め定められた登録情報とを照らし合わせて、現在情報と登録情報とが不一致な状態であるか否かを判定する（ステップＳ３）。登録情報は、所定のプラットフォームを介して決済サーバ１０が取得してもよいし、決済サーバ１０に予め記憶されていてもよい。例えば、決済サーバ１０は、店舗Ａの現在の営業状態と、店舗Ａの予め定められた営業時間とを照らし合わせ、営業時間内に店舗Ａの現在の営業状態が営業中でない場合、すなわち、店舗Ａが開店しているはずにも関わらず開店していない状態の場合、現在情報と登録情報とが不一致な状態であると判定する。営業時間は、ランチタイム（例えば、１１時〜１４時）や、ディナータイム（例えば、１７時〜２１時）、その他（例えば、９時〜１１時、１４時〜１７時）などといった時間帯を別として登録された情報であってもよい。また、決済サーバ１０は、店舗Ａの現在の所在地と、店舗Ａの予め定められた所在地とが異なる場合、現在情報と登録情報とが不一致な状態であると判定する。予め定められた所在地は、事業者Ｍ１が管理する店舗Ａの営業場所として登録された位置情報（例えば、住所）である。また、予め定められた所在地は、例えば、店舗Ａが移動型販売店である場合、曜日や時間帯に応じて、予め店舗Ａの営業場所として登録された位置情報（例えば、住所）であってもよい。また、決済サーバ１０は、現在の取引対象情報と予め定められた取引対象情報とが異なる場合、現在情報と登録情報とが不一致な状態であると判定する。予め定められた取引対象情報は、例えば、事前注文サービスにおいて取引対象となる商品のメニュー、価格、画像等が登録された情報であればよい。
【００３７】
続いて、決済サーバ１０は、店舗Ａの現在情報と登録情報とが不一致な状態であると判定された場合、不一致な状態の是正を店舗Ａに対してリクエストするためのリクエスト手段を利用者Ｕ１に提供する（ステップＳ４）。リクエスト手段は、利用者端末１００に表示される。リクエスト手段は、例えば、店舗Ａの現在情報と登録情報との不一致の内容を表示すると共に、当該不一致の内容を店舗Ａに対して通知するボタンである。また、リクエスト手段は、例えば、利用者Ｕ１が不一致の内容を表示すると共に、不一致の内容をテキストで入力可能な入力欄を含むものであってもよい。それにより、利用者Ｕ１がリクエスト手段を介して、不一致を是正するためのリクエストを入力する（ステップＳ５）。
【００３８】
続いて、決済サーバ１０は、利用者Ｕ１により入力されたリクエストを受け付ける（ステップＳ６）。決済サーバ１０は、受け付けたリクエストの内容を店舗Ａに提供する（ステップＳ７）。すなわち、決済サーバ１０は、店舗Ａの現在情報と登録情報とに不一致が生じており、利用者Ｕ１が不一致の是正をリクエストしたこと、および、リクエストの具体的な内容、すなわち現在情報と登録情報との不一致の内容を事業者端末２００に通知する。
【００３９】
例えば、利用者Ｕ１が店舗Ａに対する注文を行うための画面を表示させ、店舗Ａが開店している時間帯にも関わらず、店舗Ａが開店していなかった場合、上述したように、決済サーバ１０において不一致が判定される（上記ステップＳ１からステップＳ３）。このとき、決済サーバ１０は、リクエスト手段として、例えば“開店し忘れていませんか？”というメッセージを含む通知ボタンを利用者端末１００に表示する（上記ステップＳ４）。同様に、例えば、店舗Ａの登録された所在地が本来の営業場所とは異なる間違った所在地で登録されており、現在の所在地と登録された所在地とが異なっていた場合には、決済サーバ１０は、リクエスト手段として、例えば“所在地が異なっていませんか？”というメッセージを含む通知ボタンを利用者端末１００に表示する。また、取引対象となる現在の商品のメニュー、価格、画像等が、登録された取引対象となる現在の商品のメニュー、価格、画像等と異なっていた場合には、決済サーバ１０は、リクエスト手段として、例えば“利用できる商品が異なっていませんか？”というメッセージを含む通知ボタンを利用者端末１００に表示する。利用者Ｕ１が、上記通知ボタンを押すことにより、例えば、上述した“開店し忘れていませんか？”、“所在地が異なっていませんか？”、“利用できる商品が異なっていませんか？”といったメッセージが店舗Ａに対して報知されることになる。なお、上述したように、リクエスト手段は、通知ボタンのみではなく、利用者Ｕ１が自由にメッセージを入力できるものであってもよい。
【００４０】
また、上述した例では、利用者Ｕ１が店舗Ａに対する注文を行うための画面を表示させたタイミングで、決済サーバ１０が現在情報と登録情報との不一致を判定するものとしたが、判定のタイミングは、これに限られない。例えば、利用者Ｕ１が店舗Ａで商品を受け取ったタイミングで、決済サーバ１０が現在情報と登録情報との不一致を判定してもよい。
【００４１】
具体的には、例えば、店舗Ａの登録された所在地が、実際の営業場所ではなく本社住所となっている場合を想定する。このとき、利用者Ｕ１が店舗Ａで商品を受け取り、受け取り完了ボタンを押したことで、決済サーバ１０が、利用者Ｕ１が商品を受領した旨の通知を受領したとする。決済サーバ１０は、利用者Ｕ１が商品を受領した旨の通知を受領したタイミングで、店舗Ａの現在の所在地と、登録された所在地とを照らし合わせ、所在地が不一致な状態であると判定し、利用者Ｕ１にリクエスト手段を提供する。この場合、決済サーバ１０は、店舗Ａの現在の所在地と、登録された所在地との距離が所定距離以上である場合に、所在地の現在情報と登録情報とが不一致な状態であると判定してもよい。
【００４２】
また、例えば、利用者Ｕ１が店舗Ａで商品を受け取り、実際に受け取った商品と、注文を行うときに表示されていた商品の画像とが類似していなかった場合を想定する。このとき、例えば、利用者Ｕ１が店舗Ａで受け取った商品を自ら撮影し、撮影した画像を決済サーバ１０に送信したとする。決済サーバ１０は、利用者Ｕ１から商品の画像を受け取ったタイミングで、利用者Ｕ１が撮影した商品の画像と、予め登録された商品の画像とを照らし合わせ、周知の画像解析処理により、２つの画像が類似するものであるか否かを判定する。決済サーバ１０は、利用者Ｕ１が受け取った商品の画像と、予め登録された商品の画像とが類似していないと判定した場合に、取引対象の現在情報と登録情報とが不一致な状態であると判定し、利用者Ｕ１にリクエスト手段を提供する。
【００４３】
また、決済サーバ１０は、利用者Ｕ１からリクエスト手段によりリクエストされた回数が一定数以上となった場合に、店舗Ａにリクエストの内容を報知してもよい。
【００４４】
以上のように、実施形態に係る決済サーバ１０は、所定のプラットフォームを介して取引対象の注文を受け付ける店舗Ａに関する現在情報と、店舗Ａに関する登録情報とを取得する。決済サーバ１０は、現在情報と登録情報とを照らし合わせ、現在情報と登録情報とが不一致な状態であるか否かを判定する。決済サーバ１０は、現在情報と登録情報とが不一致な状態であると判定された場合、不一致な状態の是正を店舗Ａに対してリクエストするためのリクエスト手段を所定のプラットフォームを介して利用者Ｕ１に提供する。これにより、店舗Ａに関する現在情報と登録情報とに生じている不一致の是正を、利用者Ｕ１がリクエストすることができる。したがって、事前注文サービスを行う店舗Ａに関する登録情報と、店舗に関する現在情報とに不一致が生じている場合に、不一致の是正を店舗Ａに対して適切にリクエストすることが可能となる。
【００４５】
また、実施形態に係る決済サーバ１０は、リクエスト手段によりリクエストされた内容を店舗Ａに提供する。これにより、事業者Ｍ１は、事業者端末２００に表示されたリクエストの内容を確認し、店舗Ａに関する現在情報と登録情報との不一致の内容を把握して、是正を図ることが可能となる。
【００４６】
〔２．決済サーバの構成〕
次に、図３を用いて、決済サーバ１０の構成について説明する。図３は、実施形態に係る決済サーバの構成例を示す図である。図３に示すように、決済サーバ１０は、通信部２０と、記憶部３０と、制御部４０とを有する。
【００４７】
（通信部２０について）
通信部２０は、例えば、ＮＩＣ（Network  Interface  Card）等によって実現される。そして、通信部２０は、ネットワークＮと有線または無線で接続され、利用者端末１００や、事業者端末２００等との間で情報の送受信を行う。
【００４８】
（記憶部３０について）
記憶部３０は、例えば、ＲＡＭ（Random  Access  Memory）、フラッシュメモリ（Flash  Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図３に示すように、記憶部３０は、口座データベース３１と、事業者情報データベース３２と、利用者情報データベース３３とを有する。
【００４９】
（口座データベース３１について）
口座データベース３１は、利用者や事業者、事前注文サービスの管理者の口座に関する各種の情報を記憶する。ここで、図４を用いて、口座データベース３１が記憶する情報の一例を説明する。図４は、実施形態に係る口座データベースの一例を示す図である。図４の例において、口座データベース３１は、「口座ＩＤ」、「所有者情報」、「口座残高」といった項目を有する。
【００５０】
「口座ＩＤ」は、口座を識別するための識別情報を示す。「所有者情報」は、口座を所有（保有）する所有者（利用者や事業者、事前注文サービスの管理者）に関する情報を示し、例えば、所有者を識別するための識別情報（識別子）が格納される。「口座残高」は、利用者や事業者、事前注文サービスの管理者が所有する口座の残高を示す。
【００５１】
すなわち、図４では、口座ＩＤ「ＡＩＤ＃１」によって識別される口座の所有者の情報が「利用者＃１」であり、口座残高が「７８００」である例を示す。
【００５２】
（事業者情報データベース３２について）
事業者情報データベース３２は、事業者に関する各種の予め定められた登録情報を記憶する。ここで、図５を用いて、事業者情報データベース３２が記憶する登録情報の一例を説明する。図５は、実施形態に係る事業者情報データベースの一例を示す図である。図５の例において、事業者情報データベース３２は、「事業者ＩＤ」、「店舗ＩＤ」、「口座ＩＤ」、「所在地」、「営業時間」、「設定時間」、「履歴情報」、「取引対象情報」といった項目を有する。
【００５３】
「事業者ＩＤ」は、事業者を識別するための識別情報を示す。「店舗ＩＤ」は、事業者が管理する店舗を識別するための識別情報を示す。「口座ＩＤ」は、事業者が所有する口座を識別するための識別情報を示す。「所在地」は、事業者が管理する店舗の位置情報（例えば、住所）を示す。「所在地」は、店舗が移動型販売店であるとき、例えば曜日や時間帯に応じて予め設定された店舗の営業場所の位置情報を示す。「営業時間」は、事業者が店舗を営業する予め定められた時間である。「営業時間」は、ランチタイムや、ディナータイム、その他などといった時間帯を別に登録されてもよい。「設定時間」は、店舗が事前注文サービスを介して注文を受け付けてから取引対象を提供するための作業が完了するまでの時間であって、店舗により設定された時間を示す。なお、設定時間は、取引対象ごとに設定されていてもよい。「履歴情報」は、事前注文サービスを利用して取引対象を提供した履歴を示す。
【００５４】
「取引対象情報」は、事業者が提供する取引対象に関する情報を示し、例えば、「取引対象ＩＤ」、「価格」、「画像」といった項目を有する。「取引対象ＩＤ」は、取引対象を識別するための識別情報を示す。すなわち、「取引対象ＩＤ」は、事前注文サービスの対象となる商品のメニューの別を示す。「価格」は、取引対象の価格を示す。「画像」は、取引対象の画像を示す。
【００５５】
すなわち、図５では、事業者ＩＤ「ＭＩＤ＃１」によって識別される事業者が管理する店舗が店舗ＩＤ「ＳＩＤ＃１」によって識別され、所在地が「所在地＃１」であり、営業時間が「営業時間＃１」、設定時間が「設定時間＃１」、履歴情報が「履歴情報＃１」、当該事業者が所有する口座が口座ＩＤ「ＡＩＤ＃２」によって識別され、当該事業者が提供する取引対象のうち、取引対象ＩＤ「ＴＩＤ＃１」によって識別される取引対象の価格が「４００円」、画像が「画像＃１」である例を示す。
【００５６】
（利用者情報データベース３３について）
利用者情報データベース３３は、決済サーバ１０が提供するサービスの利用者に関する各種の情報を記憶する。ここで、図６を用いて、利用者情報データベース３３が記憶する情報の一例を説明する。図６は、実施形態に係る利用者情報データベースの一例を示す図である。図６の例において、利用者情報データベース３３は、「利用者ＩＤ」、「決済履歴」、「利用履歴」といった項目を有する。
【００５７】
「利用者ＩＤ」は、利用者を識別するための識別情報を示す。「決済履歴」は、電子決済サービスを利用して行った決済の履歴を示し、例えば、決済先（事業者）や、決済対象（取引対象）、決済金額などといった情報が格納される。「利用履歴」は、事前注文サービスや、その他の各種サービスにおける利用者の利用履歴を示し、例えば、事前注文サービスにおける注文内容を示す情報などが格納される。
【００５８】
すなわち、図６では、利用者ＩＤ「ＵＩＤ＃１」によって識別される利用者の決済履歴が「決済履歴＃１」、利用履歴が「利用履歴＃１」である例を示す。
【００５９】
（制御部４０について）
制御部４０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）等によって、決済サーバ１０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部４０は、コントローラであり、例えば、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）等の集積回路により実現される。実施形態に係る制御部４０は、図３に示すように、取得部４１と、判定部４２と、提供部４３と、決済処理部４６と、受付部４８とを有し、以下に説明する情報処理の機能や作用を実現または実行する。
【００６０】
（取得部４１について）
取得部４１は、所定のプラットフォームを介して取引対象の注文を受け付ける店舗に関する予め定められた登録情報と、当該所定のプラットフォームを介して当該店舗に対して取引対象の注文を行う利用者に関する利用者情報とを取得する。例えば、図１の例において、取得部４１は、事前注文サービスを介して商品の注文を受け付ける店舗Ａに関する登録情報を取得し、事業者情報データベース３２に格納する。なお、登録情報は、予め定められて事業者情報データベース３２に記憶されていてもよい。また、例えば、図１の例において、取得部４１は、事前注文サービスを介して店舗Ａに対して商品の注文を行う利用者Ｕ１に関する利用者情報を取得し、利用者情報データベース３３に格納する。
【００６１】
また、取得部４１は、所定のプラットフォームを介して取引対象の注文を受け付ける店舗に関する現在情報を取得する。例えば、図１の例において、取得部４１は、店舗Ａの現在情報として、店舗Ａの現在の営業状態を取得する。取得部４１は、事業者Ｍ１により、事業者端末２００から所定のプラットフォームを介して入力された現在の営業状態が、“営業中”であるか“閉店中”であるかの情報を取得する。
【００６２】
また、例えば、図１の例において、取得部４１は、店舗Ａの現在情報として、店舗Ａの現在の所在地を取得してもよい。取得部４１は、ＧＰＳセンサ等により測位された店舗Ａの現在位置を示す情報を取得してもよい。取得部４１は、所定のプラットフォームを介して事業者端末２００から入力された店舗Ａの現在の所在地を取得してもよい。
【００６３】
また、例えば、図１の例において、取得部４１は、店舗Ａの現在情報として、店舗Ａの取引対象に関する現在の取引対象情報を取得してもよい。取得部４１は、例えば、所定のプラットフォームを介して事業者端末２００から入力された取引対象情報を取得してもよい。取引対象情報は、商品のメニュー（すなわち取引対象ＩＤ），価格、画像等を含む。
【００６４】
また、取得部４１は、所定のプラットフォームを介して利用者から事前注文サービスを利用しようとした旨の情報を取得してもよい。すなわち、取得部４１は、利用者が予めインストールされた事前注文アプリを起動し、店舗に対して注文を行う画面を表示させた旨の情報を取得してもよい。
【００６５】
また、取得部４１は、所定のプラットフォームを介して利用者が商品を受領した旨の通知を取得してもよい。取得部４１は、利用者が店舗で受け取った商品を自ら撮影し、所定のプラットフォームを介して撮影された画像を取得してもよい。
【００６６】
（判定部４２について）
判定部４２は、店舗の現在情報と登録情報とを照らし合わせ、現在情報と登録情報とが不一致な状態であるか否かを判定する。判定部４２は、取得部４１が所定のプラットフォームを介して利用者から事前注文サービスを利用しようとした旨の情報を取得したタイミングで、現在情報と登録情報との不一致を判定する。なお、判定部４２は、利用者が店舗で商品を受け取ったタイミングで、現在情報と登録情報との不一致を判定してもよい。
【００６７】
判定部４２は、例えば、図１の例において、取得部４１で取得された現在情報のうち、店舗Ａの営業状態の情報を取得する。また、判定部４２は、事業者情報データベース３２から、店舗Ａの登録情報のうち、営業時間の情報を取得する。判定部４２は、取得した営業状態と営業時間とを照らし合わせ、営業時間内に店舗Ａの現在の営業状態が営業中でない場合、店舗Ａの現在情報と登録情報とが不一致な状態であると判定する。
【００６８】
また、判定部４２は、例えば、図１の例において、取得部４１で取得された現在情報のうち、店舗Ａの現在の所在地の情報を取得する。また、判定部４２は、事業者情報データベース３２から、店舗Ａの登録情報のうち、店舗Ａの予め定められた所在地の情報を取得する。判定部４２は、取得した店舗Ａの現在の所在地と、登録情報として予め定められた店舗Ａの所在地とを照らし合わせ、店舗の現在の所在地と予め定められた所在地とが異なる場合、現在情報と登録情報とが不一致な状態であると判定する。また、判定部４２は、後述する受付部４８が、所定のプラットフォームを介して利用者が商品を受領した旨の通知を受領したタイミングで、店舗Ａの現在の所在地と、登録された所在地とを照らし合わせ、所在地が不一致な状態であると判定してもよい。判定部４２は、店舗の現在の所在地と、登録された所在地との距離が所定距離以上である場合に、所在地の現在情報と登録情報とが不一致な状態であると判定してもよい。
【００６９】
また、判定部４２は、例えば、図１の例において、取得部４１で取得された現在情報のうち、店舗Ａの現在の取引対象情報を取得する。また、判定部４２は、事業者情報データベース３２から、店舗Ａの登録情報のうち、店舗Ａの予め定められた取引対象情報を取得する。判定部４２は、現在の取引対象情報と予め定められた取引対象情報とを照らし合わせ、現在の取引対象情報と予め定められた取引対象情報とが異なる場合、現在情報と登録情報とが不一致な状態であると判定する。また、判定部４２は、後述する受付部４８が、所定のプラットフォームを介して、利用者が店舗で受け取った商品を自ら撮影した画像を受領したタイミングで、利用者が撮影した商品の画像と、予め登録された商品の画像とを照らし合わせ、周知の画像解析処理により、２つの画像が類似するか否かを判定してもよい。判定部４２は、２つの画像が類似していないと判定した場合に、取引対象の現在情報と登録情報とが不一致な状態であると判定してもよい。
【００７０】
判定部４２は、以上のようにして、店舗の現在情報と登録情報とが不一致な状態であると判定すると、現在情報と登録情報とが不一致な状態である旨の判定結果を提供部４３に出力する。
【００７１】
（提供部４３について）
提供部４３は、判定部４２で現在情報と登録情報とが不一致な状態であると判定された場合、不一致な状態の是正を店舗に対してリクエストするためのリクエスト手段を所定のプラットフォームを介して利用者に提供する。例えば、図１の例において、提供部４３は、所定のプラットフォームを介して、利用者端末１００にリクエスト手段を表示させる。リクエスト手段には、店舗の現在情報と登録情報との不一致の内容が含まれる。また、リクエスト手段は、不一致の内容を店舗に対して通知するためのボタンを表示させるものであってもよいし、利用者が不一致の内容をテキストで入力可能な入力欄を含むものであってもよい。
【００７２】
また、提供部４３は、後述する受付部４８が、所定のプラットフォームを介して、利用者からリクエスト手段により不一致の是正のリクエストを受け付けたとき、リクエストされた内容を店舗に提供する。例えば、図１の例において、提供部４３は、リクエストされた内容、すなわち、現在情報と登録情報との不一致の是正をリクエストする旨を、所定のプラットフォームを介して事業者端末２００に表示させる。また、提供部４３は、利用者からリクエスト手段によりリクエストされた回数が一定数以上となった場合に、店舗にリクエストの内容を提供してもよい。
【００７３】
（決済処理部４６について）
決済処理部４６は、後述する受付部４８が受け付けた決済情報に従い、決済処理を実行する。例えば、決済処理部４６は、利用者ＩＤが示す利用者の口座から、店舗ＩＤが示す店舗の口座へと、決済金額が示す額の電子マネーを移行させる。
【００７４】
また、決済処理部４６は、所定のプラットフォームを介して利用者から受け付けられた注文内容に基づく処理を実行してもよい。例えば、図１の例において、決済処理部４６は、注文内容に対応する決済情報が示す決済金額分の電子マネーを、利用者Ｕ１が電子決済サービスで保有する第１の口座から、利用者Ｕ１が保有する他の口座であって、利用者Ｕ１が取引に利用できない第２の口座へ移行させる。そして、決済処理部４６は、商品の受領に応じて、利用者Ｕ１の第２の口座から、事業者Ｍ１が電子決済サービスで保有する口座に移行させる。
【００７５】
（受付部４８について）
受付部４８は、利用者から事業者に対する決済に関する決済情報を受け付ける。例えば、受付部４８は、利用者を識別する利用者識別情報と、決済アプリを介して撮影された店舗識別情報と、利用者或いは店舗の店員から入力された決済金額とを示す決済情報を利用者端末１００から受け付ける。
【００７６】
なお、受付部４８は、決済情報を事業者端末２００から受け付けてもよい。例えば、受付部４８は、利用者端末１００に表示された、利用者を識別するための利用者識別情報を、事業者端末２００（店舗端末）が読み取ることで決済が行われた場合、当該決済を示す決済情報を事業者端末２００から受け付ける。
【００７７】
また、受付部４８は、所定の店舗で提供される取引対象の注文を、所定のプラットフォームを介して利用者から受け付けてもよい。例えば、図１の例において、受付部４８は、利用者端末１００にインストールされた決済アプリ内の事前注文アプリを介して、店舗Ａに対する注文内容を受け付ける。
【００７８】
また、受付部４８は、利用者によりリクエスト手段に入力されたリクエストの情報を受け付ける。すなわち、受付部４８は、所定の店舗に関する現在情報と登録情報との不一致の是正をリクエストする旨の情報を受け付ける。受付部４８は、受け付けたリクエストの情報を提供部４３に出力する。
【００７９】
〔３．提供処理のフロー〕
図７を用いて、実施形態に係る決済サーバ１０の提供処理の手順について説明する。図７は、実施形態に係る提供処理の手順の一例を示すフローチャートである。
【００８０】
図７に示すように、決済サーバ１０は、所定のプラットフォームを介して店舗に関する現在情報を取得する（ステップＳ１０１）。続いて、決済サーバ１０は、店舗に関する現在情報と登録情報とを照らし合わせる（ステップＳ１０２）。続いて、決済サーバ１０は、店舗に関する現在情報と登録情報とが不一致な状態であるか否かを判定する（ステップＳ１０３）。決済サーバ１０は、現在情報と登録情報とが不一致な状態であると判定した場合（ステップＳ１０３；Ｙｅｓ）、不一致の是正をリクエストするためのリクエスト手段を利用者に提供する（ステップＳ１０４）。続いて、決済サーバ１０は、利用者からリクエスト手段によりリクエストを受け付ける（ステップＳ１０５）。続いて、決済サーバ１０は、リクエストの内容を店舗に提供し（ステップＳ１０６）、処理を終了する。
【００８１】
一方、決済サーバ１０は、現在情報と登録情報とが不一致な状態でなると判定した場合（ステップＳ１０３；Ｎｏ）、ステップＳ１０１以降の処理を再び実行する。
【００８２】
〔４．変形例〕
上述の実施形態は一例を示したものであり、種々の変更及び応用が可能である。
【００８３】
〔４−１．決済サーバ１０が提供するサービスについて〕
上述の実施形態において、決済サーバ１０により飲食物の事前注文サービスが提供される例を示したが、決済サーバ１０が提供するサービスにおける取引対象はこのような例に限定されない。例えば、決済サーバ１０は、飲食物以外の各種取引対象の事前注文サービスを提供してもよい。また、決済サーバ１０は、役務の予約に関するサービスを提供してもよい。
【００８４】
また、決済サーバ１０は、店舗における余剰在庫（例えば、飲食物の素材）を利用者に提供するサービスを提供してもよい。この場合、決済サーバ１０は、店舗において余剰在庫が発生したことを示す関連情報を受け付け、利用者に提供してもよい。
【００８５】
また、決済サーバ１０が提供するサービスは、利用者が店舗に訪問する前に取引対象の注文を受け付け、テイクアウト品が提供されるサービスに限らない。例えば、決済サーバ１０は、利用者が店舗に訪問する前に取引対象の注文を受け付け、当該店舗内において利用者に取引対象が提供されるサービスを提供してもよい。
【００８６】
また、決済サーバ１０が提供するサービスは、利用者が店舗に訪問する前に取引対象の注文を受け付けるサービスに限らない。例えば、決済サーバ１０は、利用者が店舗に訪問して店舗に設置された卓等に着席した後に、店舗に対する取引対象の注文を受け付けるサービスを提供してもよい。
【００８７】
また、決済サーバ１０が提供するサービスは、金銭の授受が発生するサービスに限らない。例えば、決済サーバ１０は、フードバンクにより供給される食品の提供に関するサービスを提供してもよい。この場合、決済サーバ１０は、フードバンクにより供給される食品の提供要求を利用者から受け付け、食品の提供の可否や、食品の提供場所などといった情報を利用者に通知し、食品が受領されたか否かを示す情報を利用者から受け付ける。
【００８８】
〔４−２．取得部４１、判定部４２および提供部４３による提供について〕
上述の実施形態においては、取得部４１で店舗の現在情報を取得し、判定部４２で現在情報と登録情報とが不一致な状態であると判定された場合、提供部４３が不一致な状態の是正を店舗Ａに対してリクエストするためのリクエスト手段を所定のプラットフォームを介して利用者に提供するものとした。ただし、取得部４１、判定部４２および提供部４３の機能は、上述した例に限定されない。
【００８９】
例えば、取得部４１は、商品が受領可能となる予定の時間（例えば図２に示す“受け取り予定時刻”）までに、店舗から利用者に対して、商品が提供可能である旨の通知（例えば図２に示す“受け取りが可能です”）を行ったか否かの現在情報を取得する。この場合、判定部４２は、取得部４１から当該現在情報を取得する。また、判定部４２は、事業者情報データベース３２から、取引対象を提供するための作業が完了するまでの設定時間を取得する。判定部４２は、当該設定時間に基づいて決定される商品が受領可能となる予定の時間（図２の“受け取り予定時刻”）内に、商品が提供可能である旨の通知が所定のプラットフォームを介して利用者に提供されていなかった場合、現在情報と登録情報とが不一致な状態であると判定する。この場合、提供部４３は、判定部４２で現在情報と登録情報とが不一致な状態であると判定されると、利用者に対して、商品が予定の時間までに受領可能となっておらず、受領可能となるように催促するリクエストを行うためのリクエスト手段を利用者に提供する。さらに、提供部４３は、利用者により催促のリクエストが行われると、その旨を店舗に提供する。これにより、商品の受け取り予定時刻を過ぎても商品が準備されていない場合に、利用者が準備を催促するリクエストを行うことができ、店舗が催促のリクエストを受け付けることができる。
【００９０】
また、例えば、取得部４１は、利用者が所定のプラットフォームを介して店舗に対して注文した取引対象を示す情報含む利用者情報を取得する。当該利用者情報には、利用者が店舗に対して注文した取引回数の情報が含まれる。この場合、提供部４３は、事業者に対してリクエストの情報を提供するとき、利用者の取引回数に応じて提供する態様を変更してもよい。すなわち、提供部４３は、利用者の取引回数に応じて、利用者の通知スコアを算出する。通知スコアは、取引回数が多いほど高く設定されればよい。提供部４３は、例えば、通知スコアが高い利用者からのリクエストを優先的に事業者に提供してもよい。すなわち、提供部４３は、通知スコアが高い利用者からのリクエストほど、通知スコアが低い利用者からのリクエストよりも先に、または、目立つ態様で表示させてもよい。また、提供部４３は、通知スコアが所定値以上の利用者からのリクエストのみ店舗に提供してもよい。提供部４３は、通知スコアが所定値以上の利用者からのリクエストはプッシュ通知が届くようにし、通知スコアが所定値未満の利用者からのリクエストは、店舗側が主体的にリクエストの内容を確認したときに表示させる、といった態様としてもよい。これにより、常連ユーザのリクエストを重要視した店舗運営を行うことが可能となる。
【００９１】
また、提供部４３は、リクエスト手段の一つとして、利用者が商品の受け取り予定時刻を所定時間だけ遅らせて欲しい旨のリクエストを行うための手段を提供するものであってもよい。当該リクエスト手段は、例えば、利用者端末１００に通知ボタンや自由にテキスト入力可能な入力欄を表示させてもよい。所定時間は、予め定められたものであってもよいし、利用者が自由に設定できるものであってもよい。提供部４３は、リクエスト手段により商品の受け取り予定時刻を所定時間だけ遅らせて欲しい旨のリクエストを受け付けると、その旨を店舗に提供する。これにより、受け取り予定時刻を利用者の要望に応じて変更することができる。
【００９２】
また、本実施形態では、決済サーバ１０が利用者に対してリクエスト手段を提供するものとした。ただし、決済サーバ１０は、事前注文サービスの管理者に対してリクエスト手段を提供してもよい。それにより、店舗の現在情報と登録情報とに不一致が生じている場合に、事前注文サービスの管理者が、不一致が生じていることを把握し、店舗に対して是正のリクエストを行うことができる。
【００９３】
〔４−３．処理態様について〕
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、逆に、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
【００９４】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【００９５】
また、上記してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【００９６】
〔５．効果〕
上述してきたように、実施形態に係る決済サーバ１０は、取得部４１と、判定部４２と、提供部４３と、決済処理部４６と、受付部４８とを有する。取得部４１は、所定のプラットフォームを介して取引対象の注文を受け付ける店舗に関する現在情報を取得する。判定部４２は、現在情報と、店舗に関して予め定められた登録情報とを照らし合わせ、現在情報と登録情報とが不一致な状態であるか否かを判定する。提供部４３は、判定部４２で現在情報と登録情報とが不一致な状態であると判定された場合、不一致な状態の是正を店舗に対してリクエストするためのリクエスト手段を所定のプラットフォームを介して利用者に提供する。決済処理部４６は、受付部４８が受け付けた決済情報に従い、決済処理を実行する。受付部４８は、利用者によりリクエスト手段に入力されたリクエストの情報を受け付ける。
【００９７】
これにより、実施形態に係る決済サーバ１０は、店舗に関する現在情報と登録情報とに生じている不一致の是正を利用者がリクエストできるように、リクエスト手段を提供することができる。その結果、事前注文サービスを行う店舗に関する登録情報と、店舗に関する現在情報とに不一致が生じている場合に、不一致の是正を店舗に対して適切にリクエストすることが可能となる。
【００９８】
また、実施形態に係る決済サーバ１０において、例えば、提供部４３は、リクエスト手段によりリクエストされた内容を店舗に提供する。これにより、事業者がリクエストの内容を確認し、店舗に関する現在情報と登録情報との不一致の内容を把握して、是正を図ることが可能となる。
【００９９】
また、実施形態に係る決済サーバ１０において、例えば、現在情報は、店舗の現在の営業状態を含み、登録情報は、店舗の予め定められた営業時間を含み、判定部４２は、営業時間内に店舗の現在の営業状態が営業中でない場合、現在情報と登録情報とが不一致な状態であると判定する。これにより、実施形態に係る決済サーバ１０は、店舗が本来は営業しているはずの時間帯に“営業中”となっていない場合に、利用者にリクエスト手段を提供することができる。その結果、利用者は、リクエスト手段を介して、店舗の営業開始をリクエストすることができる。
【０１００】
また、実施形態に係る決済サーバ１０において、例えば、現在情報は、店舗の現在の所在地を含み、登録情報は、店舗の予め定められた所在地を含み、判定部４２は、店舗の現在の所在地と予め定められた所在地とが異なる場合、現在情報と登録情報とが不一致な状態であると判定する。これにより、実施形態に係る決済サーバ１０は、店舗が本来営業しているはずの所在地で営業していない場合に、利用者にリクエスト手段を提供することができる。その結果、利用者は、リクエスト手段を介して、店舗が本来の営業場所で営業することをリクエストすることができる。特に、店舗が移動型販売店である場合に、好適である。
【０１０１】
また、実施形態に係る決済サーバ１０において、例えば、現在情報は、取引対象に関する現在の取引対象情報を含み、登録情報は、取引対象に関する予め定められた取引対象情報を含み、判定部４２は、現在の取引対象情報と予め定められた取引対象情報とが異なる場合、現在情報と登録情報とが不一致な状態であると判定する。これにより、実施形態に係る決済サーバ１０は、本来の取引対象情報と異なる情報が利用者に提示されている場合に、利用者にリクエスト手段を提供することができる。その結果、利用者は、リクエスト手段を介して、本来の取引対象情報を提示するようにリクエストすることができる。
【０１０２】
また、実施形態に係る決済サーバ１０において、例えば、現在情報は、取引対象が利用者に提供可能となった通知情報を含み、登録情報は、取引対象を提供するための作業が完了するまでの設定時間の情報を含み、判定部４２は、設定時間に基づいて決定される商品が受領可能となる予定の時間内に、通知情報が所定のプラットフォームを介して利用者に提供されなかった場合、現在情報と登録情報とが不一致な状態であると判定する。これにより、利用者が準備を催促するリクエストを行うことができる。
【０１０３】
また、実施形態に係る決済サーバ１０において、取得部４１は、利用者の取引回数を示す履歴情報を取得し、提供部４３は、利用者の取引回数に応じて、リクエストの内容を店舗に提供する態様を変更する。すなわち、提供部４３は、取引回数が多い利用者からリクエスト手段によりリクエストされた内容を優先的に店舗に提供する。これにより、常連ユーザのリクエストを重要視した店舗運営を行うことが可能となる。
【０１０４】
また、実施形態に係る決済サーバ１０において、提供部４３は、リクエスト手段の一つとして、利用者が商品の受け取り予定時刻を所定時間だけ遅らせて欲しい旨のリクエストを行うための手段を提供する。これにより、受け取り予定時刻を利用者の要望に応じて変更することができる。
【０１０５】
〔６．ハードウェア構成〕
また、上述してきた各実施形態に係る決済サーバ１０は、例えば、図８に示すような構成のコンピュータ１０００によって実現される。以下、決済サーバ１０を例に挙げて説明する。図８は、決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。
【０１０６】
ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。
【０１０７】
ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（実施形態のネットワークＮに対応する）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、また、通信網５００を介してＣＰＵ１１００が生成したデータを他の機器へ送信する。
【０１０８】
ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。
【０１０９】
メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital  Versatile  Disc）、ＰＤ（Phase  change  rewritable  Disk）等の光学記録媒体、ＭＯ（Magneto-Optical  disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
【０１１０】
例えば、コンピュータ１０００が決済サーバ１０として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部４０の機能を実現する。また、ＨＤＤ１４００には、決済サーバ１０の記憶装置内の各データが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から所定の通信網を介してこれらのプログラムを取得してもよい。
【０１１１】
〔７．その他〕
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
【０１１２】
また、上述した決済サーバ１０は、機能によっては外部のプラットフォーム等をＡＰＩ（Application  Programming  Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。
【０１１３】
また、特許請求の範囲に記載した「部」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。
【符号の説明】
【０１１４】
１  提供処理システム
１０  決済サーバ
２０  通信部
３０  記憶部
３１  口座データベース
３２  事業者情報データベース
３３  利用者情報データベース
４０  制御部
４１  取得部
４２  判定部
４３  提供部
４６  決済処理部
４８  受付部
１００  利用者端末
２００  事業者端末
【要約】
【課題】事前注文サービスを行う店舗に関する登録情報と、店舗に関する現在情報とに不一致が生じている場合に、不一致の是正をリクエストする。
【解決手段】決済サーバ１０は、取得部４１と、判定部４２と、提供部４３とを有する。取得部４１は、所定のプラットフォームを介して取引対象の注文を受け付ける店舗に関する現在情報を取得する。判定部４２は、現在情報と、店舗に関して予め定められた登録情報とを照らし合わせ、現在情報と登録情報とが不一致な状態であるか否かを判定する。提供部４３は、判定部４２で現在情報と登録情報とが不一致な状態であると判定された場合、不一致な状態の是正を店舗に対してリクエストするためのリクエスト手段を所定のプラットフォームを介して利用者に提供する。
【選択図】図１【図１】
0006957725.tif 000002
【図２】
0006957725.tif 000003
【図３】
0006957725.tif 000004
【図４】
0006957725.tif 000005
【図５】
0006957725.tif 000006
【図６】
0006957725.tif 000007
【図７】
0006957725.tif 000008
【図８】
0006957725.tif 000009