JP7066151B2 - 注文決済装置、コンピュータプログラム及び注文決済方法 - Google Patents

Description

本発明は、注文決済装置、コンピュータプログラム及び注文決済方法に関する。

インターネット技術及び暗号化技術を含むセキュリティ技術の進展に伴って、パーソナルコンピュータやスマートフォンを用いたオンラインショッピングの利用者が増大している。例えば、特許文献１には、一回使用すると使用不可となる認証番号を用いたオンラインショッピングシステムが開示されている。

特開２００６－３０２３１１号公報

しかし、特許文献１のようなオンラインショッピングシステムでは、購入代金の支払の決済は、クレジットカードを利用するものや、代金引換を利用するものが多い。このため、クレジッドカードを保有しないユーザはオンラインショッピングができないという不便がある。また、代金引換のためには在宅する必要があり、ユーザにとって不便である。

本発明は、斯かる事情に鑑みてなされたものであり、注文決済を簡素化してユーザの利便性を向上させることができる注文決済装置、コンピュータプログラム及び注文決済方法を提供することを目的とする。

本発明の実施の形態に係る注文決済装置は、オンラインストアにアクセスしたユーザの端末装置から電話番号を含むユーザ識別情報を取得する識別情報取得部と、前記ユーザの注文データを取得する注文データ取得部と、該識別情報取得部で取得した電話番号を用いて認証された認証情報を前記端末装置から取得する認証情報取得部と、前記注文データ取得部で取得した注文データを用いて前記ユーザの注文決済の可否を判定する判定部とを備える。

本発明の実施の形態に係るコンピュータプログラムは、コンピュータに、オンラインストアにアクセスしたユーザの端末装置から電話番号を含むユーザ識別情報を取得する処理と、前記ユーザの注文データを取得する処理と、取得した電話番号を用いて認証された認証情報を前記端末装置から取得する処理と、取得した注文データを用いて前記ユーザの注文決済の可否を判定する処理とを実行させる。

本発明の実施の形態に係る注文決済方法は、オンラインストアにアクセスしたユーザの端末装置から電話番号を含むユーザ識別情報を取得し、前記ユーザの注文データを取得し、取得された電話番号を用いて認証された認証情報を前記端末装置から取得し、取得された注文データを用いて前記ユーザの注文決済の可否を判定する。

本発明によれば、注文決済を簡素化してユーザの利便性を向上させることができる。

本実施の形態の注文決済システムの構成の一例を示すブロック図である。 本実施の形態の注文決済システムのプロセスの第１例を示す説明図である。 端末装置の表示画面に表示される入力画面の第１例を示す模式図である。 端末装置の表示画面に表示される入力画面の第２例を示す模式図である。 端末装置の表示画面に表示される決済判定結果画面の一例を示す模式図である。 注文データの内容の一例を示す説明図である。 注文決済の可否の判定方法の第１例を示す説明図である。 注文決済の可否の判定方法の第２例を示す説明図である。 注文決済の可否の判定方法の第３例を示す説明図である。 学習モデルの構成の一例を示す模式図である。 注文決済の可否の判定方法の第４例を示す説明図である。 本実施の形態の注文決済システムのプロセスの第２例を示す説明図である。 端末装置での処理手順の一例を示すフローチャートである。 注文決済サーバでの処理手順の一例を示すフローチャートである。

以下、本発明の実施の形態を図面に基づいて説明する。図１は本実施の形態の注文決済システムの構成の一例を示すブロック図である。注文決済システムは、注文決済装置としての注文決済サーバ５０を備える。注文決済サーバ５０は、インターネットを含むネットワーク１に接続されている。注文決済サーバ５０には、審査エンジンサーバ４０が接続されている。審査エンジンサーバ４０は、学習モデル４１及び電話番号検証部４２を備える。また、ネットワーク１には、ユーザの端末装置１０、ウェブサーバ２０及び事業者サーバ３０が接続されている。なお、図１の例では、便宜上、端末装置１０を１台だけ図示しているが、端末装置１０は、１台に限定されない。

端末装置１０は、例えば、スマートフォン（携帯電話）、ノート型パーソナルコンピュータ、タブレットなどを含む。端末装置１０は、装置全体を制御する制御部１１、通信部１２、記憶部１３、表示画面１４及び操作部１５を備える。制御部１１は、ＣＰＵ、ＲＯＭ及びＲＡＭなどで構成することができる。また、制御部１１は、事業者サーバ３０との間にインタフェース機能を備える。

通信部１２は、ネットワーク１を介して、ウェブサーバ２０、注文決済サーバ５０及び事業者サーバ３０との間で通信を行う機能を有し、所要の情報の送受信を行うことができる。

記憶部１３は、ハードディスク又はフラッシュメモリなどで構成され、ウェブブラウザなどのアプリケーションプログラム（不図示）を保持する。

表示画面１４は、液晶パネル又は有機ＥＬ（Electro Luminescence）ディスプレイ等で構成することができる。操作部１５は、例えば、表示画面１４に組み込まれたタッチパネルで構成することができ、ユーザが表示画面１４上で行う所定の操作を受付けることができる。また、操作部１５は、表示画面１４に表示したキ－ボード上の操作を受付けることができる。なお、操作部１５は、ハードウェアキーボード、マウスなどでもよい。

ウェブサーバ２０は、事業者サーバ３０を運用する事業者（例えば、商品の販売者）が用意したオンラインストア（ウェブサイト）を提供する。図１の例では、オンラインストＡ（ウェブページ上の仮想店舗）に、商品ａ、商品ｂ、…が表示されている。ユーザは、端末装置１０を用いてオンラインストアにアクセスし、商品を購入することができる。

事業者サーバ３０は、注文管理機能を備え、例えば、注文履歴の記憶、商品の発送処理などを行うことができる。

注文決済サーバ５０は、サーバ全体を制御する制御部５１、通信部５２、記憶部５３、判定部５４及び決済実行部５５を備える。制御部５１は、ＣＰＵ、ＲＯＭ及びＲＡＭなどで構成することができる。

通信部５２は、ネットワーク１を介して、端末装置１０、ウェブサーバ２０及び事業者サーバ３０との間で通信を行う機能を有し、所要の情報の送受信を行うことができる。

通信部５２は、識別情報取得部としての機能を備え、ウェブサーバ２０のオンラインストアにアクセスしたユーザの端末装置１０から電話番号を含むユーザ識別情報を取得する。ユーザ識別情報は、電話番号（例えば、携帯電話番号）の他にユーザのメールアドレスとすることができる。

通信部５２は、認証情報取得部としての機能を有し、ユーザの電話番号を用いて認証された認証コード（認証情報）を端末装置１０から取得する。例えば、ユーザの携帯電話に認証コードを送信し、送信した認証コードが端末装置１０から送信されることにより、ユーザの認証を行うことができる。この場合、ユーザは、予めクレジットカードを登録することや、クレジットカードの情報を入力する必要がなく、ユーザの利便性を向上させることができる。また、ユーザは、パスワードを用いる必要がなく、利用の都度、認証コードが発行されるので、安全性を失うことなく利便性を向上させることができる。

通信部５２は、注文データ取得部としての機能を有し、ユーザ識別情報を取得した後に、ユーザの注文データを取得する。注文データは、今回の注文データだけでなく、当該ユーザの過去の注文データ（注文履歴データ）も含めることができる。今回の注文データは、ウェブサーバ２０から取得することができる。注文履歴データは、例えば、ユーザのオンラインストアでのアカウント情報等に基づいて抽出することが可能であり、例えば、事業者サーバ３０から取得することができる。注文データにより、ユーザの注文に関する状況を検証することができる。

より具体的には、注文決済サーバ５０とオンラインストアにアクセスした端末装置１０との間の情報の授受は、以下のようにして行うことができる。すなわち、予め、事業者が用意したオンラインストアの支払いページ上で動作する決済用アプリケーションを導入しておく。ユーザが、端末装置１０を介して行うオンラインストア上での操作に応じて、当該決済用アプリケーションが所要の情報を注文決済サーバ５０へ送信することができる。また、注文決済サーバ５０が所要の情報を決済用アプリケーションへ送信すると、当該情報が端末装置１０に出力又は表示される。

判定部５４は、取得した注文データを用いてユーザの注文決済の可否を判定する。例えば、ユーザの注文に関する状況に基づいて、ユーザの支払い状況に問題がなければ注文決済可と判定することができる。また、未払い状況が存在する場合、注文決済不可と判定することができる。これにより、ユーザは、例えば、電話番号（携帯電話番号）とメールアドレス、及び認証コードを入力するだけで注文決済が完了するので、ユーザの利便性を向上させることができる。注文決済の可否の判定方法の詳細は後述する。

記憶部５３は、ハードディスク又はフラッシュメモリなどで構成され、注文決済サーバ５０の処理手順を定めるコンピュータプログラム、注文履歴ＤＢ５３１を保持する。

決済実行部５５は、注文の金額の支払い処理、請求処理などを行う。支払い処理及び請求処理の詳細は後述する。

図２は本実施の形態の注文決済システムのプロセスの第１例を示す説明図である。第１例は、通常の（一度限りの）決済の場合を示す。以下、プロセスＰ１からＰ１３について説明する。

プロセスＰ１では、ユーザは、端末装置１０を用いてオンラインストアにアクセスし、購入商品を決定し、決済を開始する。

プロセスＰ２では、端末装置１０の表示画面１４に電話番号及びメールアドレスの入力画面が表示され、ユーザが、電話番号及びメールアドレスを入力すると、端末装置１０は、入力された電話番号及びメールアドレスを取得する。

プロセスＰ３では、端末装置１０は、入力された電話番号及びメールアドレスを注文決済サーバ５０へ送信する。

プロセスＰ４では、注文決済サーバ５０は、注文データを取得する。

プロセスＰ５では、注文決済サーバ５０は、当該ユーザの注文履歴データを取得する。ここでは、注文データは、今回の注文のデータであり、注文履歴データは、過去の注文データであるが、注文履歴データを含めて注文データとしてもよい。

プロセスＰ６では、注文決済サーバ５０は、ＳＭＳ（Short Message Service）経由で認証コードを端末装置１０へ送信する。なお、図２の例では、認証コードを端末装置１０に送信する構成であるが、端末装置１０と異なる携帯電話に送信してもよい。

プロセスＰ７では、端末装置１０の表示画面１４に認証コードの入力画面が表示され、ユーザが、認証コードを入力すると、端末装置１０は、入力された認証コードを取得する。

プロセスＰ８では、端末装置１０は、入力された認証コードを注文決済サーバ５０へ送信する。

プロセスＰ９では、注文決済サーバ５０は、注文データ（注文履歴データを含む）に基づいて注文決済の可否を判定する。

プロセスＰ１０では、注文決済可と判定した場合、注文決済サーバ５０は、決済データを事業者サーバ３０へ送信する。

プロセスＰ１１では、事業者サーバ３０は、商品の発送処理を行うと、決済完了を行い、プロセスＰ１２では、事業者サーバ３０は、決済完了通知を注文決済サーバ５０へ送信する。これにより、注文決済サーバ５０は、ユーザの注文の金額（注文額）を立替えて事業者に支払う。

プロセスＰ１３では、注文決済サーバ５０は、所定期間（例えば、１か月間）の当該ユーザの注文額を纏めて請求（１回の請求）を行う。

図３は端末装置１０の表示画面１４に表示される入力画面１００の第１例を示す模式図である。入力画面１００には、ユーザが購入を決定した商品を表示する領域１０１、電話番号を入力する領域１０２、メールアドレスを入力する領域１０３、支払アイコン１０４などが表示される。ユーザが購入する商品を決定して、不図示の画面にて支払開始の操作を行うことにより、入力画面１００が表示される。領域１０１には、ユーザが商品を購入した店舗名（図の例では、オンラインストアＡ）、商品名、金額などが表示される。ユーザは、自分の電話番号及びメールアドレスを入力した後、支払アイコン１０４を操作すると、後述の入力画面１１０が表示される。

図４は端末装置１０の表示画面１４に表示される入力画面１１０の第２例を示す模式図である。入力画面１１０には、領域１０１の他に、認証コードを入力する領域１１１が表示される。認証コードは、入力画面１００で入力した電話番号（図の例では、××××）の携帯電話（端末装置１０でもよい）にＳＭＳ経由で送られる。

図５は端末装置１０の表示画面１４に表示される決済判定結果画面１２０の一例を示す模式図である。注文決済サーバ５０によって、ユーザの注文データに基づいて注文決済可の判定がされると、決済判定結果画面１２０が表示される。これにより、ユーザは、電話番号（携帯電話番号）とメールアドレス及び認証コードを入力するだけで注文決済が完了するので、ユーザの利便性を向上させることができる。なお、図３から図５に示す画面は一例であって、これらの画面に限定されるものではない。

次に、注文データに基づいて注文決済の可否の判定方法について説明する。まず、注文データについて説明する。

図６は注文データの内容の一例を示す説明図である。図６に示すように、注文データは、オンラインストアの店舗名、今回の注文情報、ユーザ情報、ユーザの住所（商品の送付先住所）、及び履歴情報を含む。今回の注文情報は、商品ＩＤ、商品の数、商品の名称及び商品の単価を含む。ユーザ情報は、氏名、電話番号及びメールアドレスを含む。履歴情報は、店舗でアカウントを作成してからの経過日数、取引開始から現在までの注文総数、取引開始から現在までの注文の総額、最後の注文の金額、最後の注文からの経過日数を含む。図６に示すような注文データは、ユーザ毎に、注文履歴ＤＢ５３１に記録することができる。注文データにより、ユーザの注文に関する状況を検証することができる。なお、注文データの内容は図６の例に限定されない。

次に、ユーザの電話番号を用いた注文決済の可否の判定方法について説明する。

判定部５４は、注文データに含まれるユーザの電話番号を審査エンジンサーバ４０へ出力する。審査エンジンサーバ４０の電話番号検証部４２は、電話番号の使用履歴データベースを備え、使用履歴データベースを探索して、注文決済サーバ５０から出力された電話番号の使用履歴を特定する。電話番号検証部４２は、特定した使用履歴を注文決済サーバ５０に出力する。

判定部５４は、使用履歴取得部としての機能を有し、注文データに含まれるユーザの電話番号の使用履歴を審査エンジンサーバ４０から取得する。電話番号の使用履歴は、例えば、電話番号の利用開始からの経過期間、使用回数などを含む。使用履歴の取得は、例えば、電話番号の使用履歴データベース等を利用することができる。

判定部５４は、電話番号の使用履歴に基づいてユーザの注文決済の可否を判定することができる。

図７は注文決済の可否の判定方法の第１例を示す説明図である。図７に示すように、例えば、電話番号の利用期間（利用開始からの経過期間）が６か月以上である場合、今回の注文の金額に関わらず、注文決済可と判定することができる。また、電話番号の利用期間が３か月以上（６か月未満）の場合、今回の注文の金額が１０，０００円未満であれば、注文決済可と判定することができる。また、電話番号の利用期間が１か月以上（３か月未満）の場合、今回の注文の金額が５，０００円未満であれば、注文決済可と判定することができる。電話番号の利用期間が１か月未満である場合、注文決済不可と判定することができる。なお、図７の例は一例であって、期間、金額は図７の例に限定されない。

上述のように、利用開始からの経過期間が短い場合、あるいは、１度も使用されていない電話番号などは、不正利用やなりすまし等の可能性が高いと考えられ、注文決済不可と判定することができる。これにより、ユーザの利便性を向上させつつ、注文決済の可否を適切に判定することができる。

次に、ユーザの住所を用いた注文決済の可否の判定方法について説明する。

判定部５４は、ユーザの住所の存否又は住所の変遷に基づいてユーザの注文決済の可否を判定することができる。

図８は注文決済の可否の判定方法の第２例を示す説明図である。図８に示すように、例えば、ユーザの住所の状況が実在しない場合、注文決済不可と判定することができる。また、ユーザの住所の状況が過去６か月の間に２回変更になっている場合、注文決済不可と判定することができる。また、ユーザの住所の状況が過去１年以上変更なしの場合、注文決済可と判定することができる。なお、図８の例は一例であって、図８の例に限定されない。

上述のように、ユーザの住所が実在しない住所である場合（ただし、送付先住所は実在するような場合）、当該ユーザの信用度は低いとして、注文決済不可と判定することができる。また、ユーザの住所が比較的短期間の間に変更されている場合も、当該ユーザの信用度は低いとして、注文決済不可と判定することができる。これにより、ユーザの利便性を向上させつつ、注文決済の可否を適切に判定することができる。

次に、ユーザの未払い情報を用いた注文決済の可否の判定方法について説明する。

判定部５４は、注文に対する未払い情報に基づいてユーザの注文決済の可否を判定することができる。

図９は注文決済の可否の判定方法の第３例を示す説明図である。図９に示すように、例えば、未払い金額が０円の場合、注文決済可と判定することができる。また、未払い金額が３，０００円未満の場合に、未払日数（支払期日からの経過日数）が２か月未満であれば、注文決済可と判定し、未払日数が２か月以上であれば、注文決済不可と判定することができる。また、未払い金額が３，０００円以上５，０００円未満の場合に、未払日数が１か月未満であれば、注文決済可と判定し、未払日数が１か月以上であれば、注文決済不可と判定することができる。また、未払い金額が５，０００円以上の場合は、注文決済不可と判定することができる。なお、図９の例は一例であって、期間、金額は図９の例に限定されない。

上述のように、注文に対する未払いが発生していない場合、当該ユーザの信用度は高いとして、注文決済可と判定することができる。また、注文に対する未払いが発生している場合、未払い金額や未払い期間に応じて注文決済の可否を判定することができる。これにより、ユーザの利便性を向上させつつ、注文決済の可否を適切に判定することができる。

次に、学習モデル４１を用いた注文決済の可否の判定方法について説明する。

判定部５４は、入力部としての機能を有し、注文データに基づいて学習した学習モデル４１に、ユーザの注文データを入力する。学習モデル４１は、例えば、多層のニューラルネットワーク（深層学習）を用いることができるが、他の機械学習を用いてもよい。学習モデル４１は、例えば、注文データと、当該注文データに対応する注文の信頼性（ユーザの信頼性）を教師データとして学習した学習済の学習モデルである。

判定部５４は、学習モデル４１の出力に基づいてユーザの注文決済の可否を判定することができる。多数の注文データによって学習した学習モデル４１を用いることによって、精度よく注文決済の可否を判定することができる。

図１０は学習モデル４１の構成の一例を示す模式図である。図１０に示すように、入力層、出力層及び複数の中間層から構成されている。なお、図１０では、便宜上、２つ中間層を図示しているが、中間層の層数は２つに限定されず、３つ以上であってもよい。

入力層、出力層及び中間層には、１つ又は複数のノード（ニューロン）が存在し、各層のノードは、前後の層に存在するノードと一方向に所望の重みで結合されている。入力層のノードの数と同数の成分を有するベクトルが、学習モデル４１の入力データとして与えられる。入力データは、例えば、アカウント作成後の経過日数、注文総数、注文総額、最後の注文の金額、最後の注文からの経過日数などを含む注文データとすることができる。なお、アカウント作成後の経過日数、注文総数、注文総額、最後の注文の金額、最後の注文からの経過日数などのデータは、ベクトル化して入力層の各ノードに入力することができる。

入力層の各ノードに与えられたデータは、最初の中間層に入力して与えられると、重みおよび活性化関数を用いて中間層の出力が算出され、算出された値が次の中間層に与えられ、以下同様にして出力層の出力が求められるまで次々と後の層（下層）に伝達される。なお、ノードを結合する重みのすべては、学習アルゴリズムによって計算される。

学習モデル４１の出力層は、例えば、出力データとして信用度を出力する。出力データは、出力層のノードの数（出力層のサイズ）と同じサイズの成分を有するベクトル形式のデータとすることができる。出力層のノードは、例えば、ユーザの注文（又はユーザ自身）の信用度が１００％、９０％、８０％、…、５０％のように区分することができる。なお、出力層からの出力値は、各区分に分類される信用度の確率と解釈することができる。例えば、信用度が１００％、９０％、８０％、…、５０％の各ノードのうち、確率が最も高いノード、あるいは確率が閾値以上であるノードの信用度を学習モデル４１の出力値とすることができる。また、信用度の数値は、図１０の例に限定されるものではなく、例えば、５％間隔で出力してもよく、０％～１００％の範囲を出力するようにしてもよい。また、出力層からの出力データは、信用度に限定されるものではなく、未払いの確率などであってもよい。

なお、学習モデル４１は、図１０に示すような入力データ及び出力データを教師データとして学習させることができる。

学習モデル４１は、例えば、ＣＰＵ（例えば、複数のプロセッサコアを実装したマルチ・プロセッサなど）、ＧＰＵ（Graphics Processing Units）、ＤＳＰ（Digital Signal Processors）、ＦＰＧＡ（Field-Programmable Gate Arrays）などのハードウェアを組み合わせることによって構成することができる。また、量子プロセッサを組み合わせることもできる。学習モデル４１は、ニューラルネットワークモデルに限定されるものではなく、他の機械学習モデルでもよい。

図１１は注文決済の可否の判定方法の第４例を示す説明図である。図１１に示すように、学習モデル４１の出力値が信用度１００％の場合、注文決済可と判定することができる。また、学習モデル４１の出力値が信用度９０％の場合、今回の注文の金額が１０，０００円未満であれば、注文決済可と判定することができる。なお、図示していないが、学習モデル４１の出力値が信用度９０％の場合、今回の注文の金額が１０，０００円以上であれば、注文決済不可と判定することができる。また、学習モデル４１の出力値が信用度８０％の場合、今回の注文の金額が５，０００円未満であれば、注文決済可と判定することができる。また、学習モデル４１の出力値が信用度７０％以下の場合、注文決済不可と判定することができる。なお、信用度を示す数値（９０％など）は一例であって、これらの値に限定されるものではない。

上述のように、判定部５４は、学習モデル４１が出力する信用度に基づいてユーザの注文決済の可否を判定することができる。例えば、信用度が１００％であれば、注文決済可と判定することができる。また、信用度が８０％以上であれば、注文の金額の多少に応じて、注文決済の可否を判定することができる。また、信用度が７０％以下であれは、注文決済不可と判定することができる。これにより、ユーザの利便性を向上させつつ、精度よく注文決済の可否を判定することができる。

なお、学習モデル４１が出力する信用度は、前述のような相対値（８０％、９０％、１００％）に限定されるものではなく、５５０点、６００点の如く得点（絶対値）としてもよい。例えば、信用度の最高点を１，０００点とし、学習モデル４１が出力する信用度が９００点以上の場合、注文決済可と判定することができる。また、学習モデル４１が出力する信用度が９００点未満であって７００点以上の場合、今回の注文の金額が１０，０００円未満であれば、注文決済可と判定することができる。また、学習モデル４１が出力する信用度が７００点未満であって５５０点以上の場合、今回の注文の金額が５，０００円未満であれば、注文決済可と判定することができる。また、学習モデル４１が出力する信用度が５５０点未満の場合、注文決済不可と判定することができる。なお、得点は一例であって、これらの値に限定されるものではない。

また、学習モデル４１が出力値として未払い確率を出力する場合、以下のように注文決済の可否を判定することができる。すなわち、判定部５４は、学習モデル４１が出力する未払いの確率に基づいてユーザの注文決済の可否を判定することができる。例えば、未払いの確率が０％であれば、注文決済可と判定することができる。また、未払いの確率が３０％未満であれば、注文の金額の多少に応じて、注文決済の可否を判定することができる。また、未払いの確率が３０％以上であれは、注文決済不可と判定することができる。これにより、ユーザの利便性を向上させつつ、精度よく注文決済の可否を判定することができる。

決済実行部５５は、支払部としての機能を有し、判定部５４でユーザの注文決済が可であると判定した場合、オンラインストアでのユーザの注文額を立替えてオンラインストア側（すなわち、事業者サーバ３０、オンラインストを運用する事業者又は販売者など）に支払う。

決済実行部５５は、請求部としての機能も有し、ユーザの注文額の所定期間内の合計額をユーザ側（例えば、端末装置１０又はその他のユーザが使用する携帯電話又は情報処理装置など）に請求する。所定期間は、例えば、１か月とすることができる。これにより、ユーザは、所定期間の間に複数回注文をした場合でも、注文の都度支払いを請求されるのではなく、所定期間毎に纏めて１回だけ支払いを請求されるので、ユーザにとっては、買い物ごとに手数料などの支払いが発生しないというメリットがる。

次に、定期購入（例えば、ある商品を定期的に購入）する場合について説明する。

図１２は本実施の形態の注文決済システムのプロセスの第２例を示す説明図である。第２例は、定期購入の決済の場合を示す。以下、プロセスＰ２１からＰ３８について説明する。

プロセスＰ２１では、ユーザは、端末装置１０を用いてオンラインストアにアクセスし、購入商品を決定し、定期購買の決済を開始する。

以下、プロセスＰ２２からプロセスＰ２８までは、図２に例示したプロセスＰ２からプロセスＰ８までと同様であるので説明は省略する。

プロセスＰ２９では、注文決済サーバ５０は、定期購買識別情報を生成する。定期購買識別情報は、注文決済サーバ５０でユーザの決済を行うためのユーザ識別情報（事業者毎にユーザのアカウントを識別する情報）である。

プロセスＰ３０では、注文決済サーバ５０は、注文データ（注文履歴データを含む）に基づいて注文決済の可否を判定する。

プロセスＰ３１では、注文決済可と判定した場合、注文決済サーバ５０は、決済データ及び定期購買識別情報を事業者サーバ３０へ送信する。

プロセスＰ３２では、事業者サーバ３０は、商品の発送処理を行うと、決済完了を行い、プロセスＰ３３では、事業者サーバ３０は、決済完了通知を注文決済サーバ５０へ送信する。これにより、注文決済サーバ５０は、ユーザの注文の金額（注文額）を立替えて事業者に支払う。

プロセスＰ３４では、注文決済サーバ５０は、所定期間（例えば、１か月間）の当該ユーザの注文額を纏めて請求（１回の請求）を行う。

プロセスＰ３５では、端末装置１０は、次回の定期購買の注文を注文決済サーバ５０へ送信する。

プロセスＰ３６では、当該ユーザの定期購買識別情報を用いて、決済データを事業者サーバ３０へ送信する。

プロセスＰ３７では、事業者サーバ３０は、商品の発送処理を行うと、決済完了を行い、プロセスＰ３８では、事業者サーバ３０は、決済完了通知を注文決済サーバ５０へ送信する。これにより、注文決済サーバ５０は、ユーザの注文の金額（注文額）を立替えて事業者に支払う。

プロセスＰ３９では、注文決済サーバ５０は、所定期間（例えば、１か月間）の当該ユーザの注文額を纏めて請求（１回の請求）を行う。以降、プロセスＰ３４からプロセスＰ３８が同様に繰り返される。

なお、上述の例において、プロセスＰ３５を行うことなく、２回目以降の定期購買を行うこともできる。すなわち、２回目以降の決済処理日、商品の発送日などを予め定めておき、当該日になったときに、プロセスＰ３６からプロセスＰ３８までを行ってもよい。

決済実行部５５は、生成部としての機能を有し、ユーザの認証後に（より具体的には、注文決済可否判定前に）、オンラインストアでの定期購買のための購買識別情報を生成する。

決済実行部５５は、ユーザの定期購買の注文を受け付けた場合、生成した購買識別情報に基づいてユーザの注文額を立替えてオンラインストア側に支払う。決済実行部５５は、ユーザの注文額の所定期間内の合計額をユーザ側に請求する。購買識別情報を用いることにより、ユーザの注文に対する継続課金を行うことができ、ユーザは、定期購入をすることができる。

図１３は端末装置１０での処理手順の一例を示すフローチャートである。以下では、便宜上、処理の主体を制御部１１として説明する。制御部１１は、オンラインストアにアクセスし（Ｓ１１）、ユーザの操作に応じて購入商品を決定する（Ｓ１２）。制御部１１は、ユーザの操作に応じて注文の決済を開始する（Ｓ１３）。

制御部１１は、ユーザが入力した電話番号、メールアドレスを受け付け（Ｓ１４）、受け付けた電話番号、メールアドレスを注文決済サーバ５０へ送信する（Ｓ１５）。ユーザが、ＳＭＳ経由で携帯電話（端末装置１０でもよい）に送られてきた認証コードを見て、端末装置１０に認証コードを入力すると、制御部１１は、入力された認証コードを受け付け（Ｓ１６）、受け付けた認証コードを注文決済サーバ５０へ送信する（Ｓ１７）。

制御部１１は、注文決済サーバ５０から決済判定結果を受信し（Ｓ１８）、決済可であるか否かを判定する（Ｓ１９）。決済可である場合（Ｓ１９でＹＥＳ）、制御部１１は、他の商品の購入を受け付けたか否かを判定し（Ｓ２０）、他の商品の購入を受け付けた場合（Ｓ２０でＹＥＳ）、ステップＳ１２以降の処理を続ける。

他の商品の購入を受け付けていない場合（Ｓ２０でＮＯ）、制御部１１は、処理を終了する。決済不可である場合（Ｓ１９でＮＯ）、制御部１１は、決済不可を通知し（Ｓ２１）、処理を終了する。

図１４は注文決済サーバ５０での処理手順の一例を示すフローチャートである。以下では、便宜上、処理の主体を制御部５１として説明する。制御部５１は、決済が開始されたか否かを判定し（Ｓ３１）、決済が開始されていない場合（Ｓ３１でＮＯ）、ステップＳ３１の処理を続ける。決済が開始された場合（Ｓ３１でＹＥＳ）、制御部５１は、電話番号、メールアドレスを端末装置１０から受信し（Ｓ３２）、ユーザの注文データを取得する（Ｓ３３）。

制御部５１は、認証コードをＳＭＳ経由で送信する（Ｓ３４）。制御部５１は、端末装置１０から認証コードを受信したか否かを判定し（Ｓ３５）、認証コードを受信した場合（Ｓ３５でＹＥＳ）、受信した認証コードが送信した認証コードと一致することを照合すると、ユーザの注文データを用いて、決済可否を判定する（Ｓ３６）。

決済可と判定した場合（Ｓ３７でＹＥＳ）、制御部５１は、決済可通知を端末装置１０に送信し（Ｓ３８）、注文に関する決済データを事業者サーバ３０へ送信する（Ｓ３９）。制御部５１は、決済完了通知を事業者サーバ３０から受信したか否かを判定し（Ｓ４０）、決済完了通知を受信していない場合（Ｓ４０でＮＯ）、ステップＳ４０の処理を続ける。

決済完了通知を受信した場合（Ｓ４０でＹＥＳ）、制御部５１は、所定期間の当該ユーザの注文の総額をまとめて請求し（Ｓ４１）、処理を終了する。認証コードを受信していない場合（Ｓ３５でＮＯ）、あるいは決済不可と判定した場合（Ｓ３７でＮＯ）、制御部５１は、決済不可通知を端末装置１０に送信し（Ｓ４２）、処理を終了する。

注文決済サーバ５０は、ＣＰＵ（プロセッサ）、ＲＡＭなどを備えたコンピュータを用いて実現することもできる。図１４に示すような処理の手順を定めたコンピュータプログラム（記録媒体に記録可能）をコンピュータに備えられたＲＡＭにロードし、コンピュータプログラムをＣＰＵ（プロセッサ）で実行することにより、コンピュータ上で注文決済サーバ５０を実現することができる。

上述のように、本実施の形態によれば、ユーザは電話番号及びメールアドレスを入力するだけで、オンラインストアでの注文の決済が完了するので、クレジットカードを保有していなくてもオンラインショッピングを行うことができる。また、クレジットカードの登録や、クレジットカード情報の入力の手間も軽減できるので、ユーザの利便性が向上する。また、クレジットカードを使用する場合のセキュリティ不安も生じない。また、ユーザは、パスワードを用いる必要がなく、利用の都度、認証コードが発行されるので、安全性を失うことなく利便性を向上させることができる。

また、本実施の形態によれば、代金引換のような支払い方法も必要ないので、商品の到着を待って在宅する必要もなく、ユーザの利便性が向上する。

また、本実施の形態によれば、所定期間（例えば、１か月間）に何回商品を購入しても、その都度支払いが発生せずに、所定期間に１回だけ購入代金を支払えばよいので、例えば、商品購入の都度、手数料の支払いが発生しない。これにより、ユーザは無駄な費用を支払う必要がないというメリットを得ることができる。

また、本実施の形態によれば、ユーザが商品を購入した後に、事業者（加盟店）の在庫が確定し出荷時に行われるキャプチャー処理時に、決済が完了し、事業者は購入代金を受け取ることができるので、例えば、代引きによるキャンセルリスクが発生しない。

本実施の形態に係る注文決済装置は、オンラインストアにアクセスしたユーザの端末装置から電話番号を含むユーザ識別情報を取得する識別情報取得部と、前記ユーザの注文データを取得する注文データ取得部と、該識別情報取得部で取得した電話番号を用いて認証された認証情報を前記端末装置から取得する認証情報取得部と、前記注文データ取得部で取得した注文データを用いて前記ユーザの注文決済の可否を判定する判定部とを備える。

本実施の形態に係るコンピュータプログラムは、コンピュータに、オンラインストアにアクセスしたユーザの端末装置から電話番号を含むユーザ識別情報を取得する処理と、前記ユーザの注文データを取得する処理と、取得した電話番号を用いて認証された認証情報を前記端末装置から取得する処理と、取得した注文データを用いて前記ユーザの注文決済の可否を判定する処理とを実行させる。

本実施の形態に係る注文決済方法は、オンラインストアにアクセスしたユーザの端末装置から電話番号を含むユーザ識別情報を取得し、前記ユーザの注文データを取得し、取得された電話番号を用いて認証された認証情報を前記端末装置から取得し、取得された注文データを用いて前記ユーザの注文決済の可否を判定する。

識別情報取得部は、オンラインストアにアクセスしたユーザの端末装置から電話番号を含むユーザ識別情報を取得する。ユーザ識別情報は、電話番号（例えば、携帯電話番号）の他にユーザのメールアドレスとすることができる。端末装置は、スマートフォンでもよく、パーソナルコンピュータやタブレットでもよい。

注文データ取得部は、ユーザの注文データを取得する。注文データは、今回の注文データだけでなく、当該ユーザの過去の注文データ（注文履歴データ）も含めることができる。注文履歴データは、例えば、ユーザのオンラインストアでのアカウント情報等に基づいて抽出することが可能である。注文データにより、ユーザの注文に関する状況を検証することができる。

認証情報取得部は、取得した電話番号を用いて認証された認証情報を端末装置から取得する。例えば、ユーザの携帯電話に認証情報を送信し、送信した認証情報が端末装置から送信されることにより、ユーザの認証を行うことができる。この場合、ユーザは、予めクレジットカードを登録することや、クレジットカードの情報を入力する必要がなく、ユーザの利便性を向上させることができる。

判定部は、取得した注文データを用いてユーザの注文決済の可否を判定する。例えば、ユーザの注文に関する状況に基づいて、ユーザの支払い状況に問題がなければ注文決済可と判定することができる。また、未払い状況が存在する場合、注文決済不可と判定することができる。これにより、ユーザは、ユーザ識別情報と認証情報を入力するだけで注文決済が完了するので、ユーザの利便性を向上することができる。

本実施の形態に係る注文決済装置において、前記注文データ取得部は、前記注文データに含まれる前記ユーザの住所を取得し、前記判定部は、前記ユーザの住所の存否又は住所の変遷に基づいて前記ユーザの注文決済の可否を判定する。

注文データ取得部は、注文データに含まれるユーザの住所を取得する。判定部は、ユーザの住所の存否又は住所の変遷に基づいてユーザの注文決済の可否を判定する。例えば、ユーザの住所が実在しない住所である場合（ただし、送付先住所は実在するような場合）、当該ユーザの信用度は低いとして、注文決済不可と判定することができる。また、ユーザの住所が比較的短期間の間に変更されている場合も、当該ユーザの信用度は低いとして、注文決済不可と判定することができる。これにより、ユーザの利便性を向上させつつ、注文決済の可否を適切に判定することができる。

本実施の形態に係る注文決済装置において、前記判定部は、注文に対する未払い情報に基づいて前記ユーザの注文決済の可否を判定する。

判定部は、注文に対する未払い情報に基づいてユーザの注文決済の可否を判定する。例えば、注文に対する未払いが発生していない場合、当該ユーザの信用度は高いとして、注文決済可と判定することができる。また、注文に対する未払いが発生している場合、未払い金額や未払い期間に応じて、注文決済の可否を判定することができる。これにより、ユーザの利便性を向上させつつ、注文決済の可否を適切に判定することができる。

本実施の形態に係る注文決済装置は、前記注文データに含まれる前記ユーザの電話番号の使用履歴を取得する使用履歴取得部を備え、前記判定部は、前記電話番号の使用履歴に基づいて前記ユーザの注文決済の可否を判定する。

使用履歴取得部は、注文データに含まれるユーザの電話番号の使用履歴を取得する。電話番号の使用履歴は、例えば、電話番号の利用開始からの経過期間、使用回数などを含む。使用履歴の取得は、例えば、電話番号の使用履歴データベース等を利用することができる。

判定部は、電話番号の使用履歴に基づいてユーザの注文決済の可否を判定する。例えば、利用開始からの経過期間が短い場合、１度も使用されていない電話番号などは、不正利用やなりすまし等の可能性が高いと考えられ、注文決済不可と判定することができる。これにより、ユーザの利便性を向上させつつ、注文決済の可否を適切に判定することができる。

本実施の形態に係る注文決済装置は、注文データに基づいて学習した学習モデルに、前記注文データを入力する入力部を備え、前記判定部は、前記学習モデルの出力に基づいて前記ユーザの注文決済の可否を判定する。

入力部は、注文データに基づいて学習した学習モデルに、ユーザの注文データを入力する。学習モデルは、例えば、多層のニューラルネットワーク（深層学習）を用いることができるが、他の機械学習を用いてもよい。学習モデルは、例えば、注文データと、当該注文データに対応する注文の信頼性（ユーザの信頼性）を教師データとして学習した学習済の学習モデルである。

判定部は、学習モデルの出力に基づいてユーザの注文決済の可否を判定する。多数の注文データによって学習した学習モデルを用いることによって、精度よく注文決済の可否を判定することができる。

本実施の形態に係る注文決済装置において、前記判定部は、前記学習モデルが出力する未払いの確率に基づいて前記ユーザの注文決済の可否を判定する。

判定部は、学習モデルが出力する未払いの確率に基づいてユーザの注文決済の可否を判定する。例えば、未払いの確率が０％であれば、注文決済可と判定することができる。また、未払いの確率が３０％未満であれば、注文の金額の多少に応じて、注文決済の可否を判定することができる。また、未払いの確率が３０％以上であれは、注文決済不可と判定することができる。これにより、ユーザの利便性を向上させつつ、精度よく注文決済の可否を判定することができる。

本実施の形態に係る注文決済装置において、前記判定部は、前記学習モデルが出力する信用度に基づいて前記ユーザの注文決済の可否を判定する。

判定部は、学習モデルが出力する信用度に基づいてユーザの注文決済の可否を判定する。例えば、信用度が１００％であれば、注文決済可と判定することができる。また、信用度が８０％以上であれば、注文の金額の多少に応じて、注文決済の可否を判定することができる。また、信用度が７０％以下であれは、注文決済不可と判定することができる。これにより、ユーザの利便性を向上させつつ、精度よく注文決済の可否を判定することができる。

本実施の形態に係る注文決済装置は、前記判定部で前記ユーザの注文決済が可であると判定した場合、前記オンラインストアでの前記ユーザの注文額を立替えて前記オンラインストア側に支払う支払部と、前記ユーザの注文額の所定期間内の合計額を前記ユーザ側に請求する請求部とを備える。

支払部は、判定部でユーザの注文決済が可であると判定した場合、オンラインストアでのユーザの注文額を立替えてオンラインストア側に支払う。請求部は、ユーザの注文額の所定期間内の合計額をユーザ側に請求する。所定期間は、例えば、１か月とすることができる。これにより、ユーザは、所定期間の間に複数回注文をした場合でも、注文の都度請求されるのではなく、所定期間毎に纏めて１回だけ請求されるので、ユーザにとっては、買い物ごとに手数料などの支払いが発生しないというメリットがある。

本実施の形態に係る注文決済装置は、前記判定部で前記ユーザの定期購買の注文決済が可であると判定した場合、前記オンラインストアでの定期購買のための購買識別情報を生成する生成部と、前記ユーザの定期購買の注文を受け付けた場合、前記生成部で生成した購買識別情報に基づいて前記ユーザの注文額を立替えて前記オンラインストア側に支払う支払部と、前記ユーザの注文額の所定期間内の合計額を前記ユーザ側に請求する請求部とを備える。

生成部は、判定部でユーザの定期購買の注文決済が可であると判定した場合、オンラインストアでの定期購買のための購買識別情報を生成する。

支払部は、ユーザの定期購買の注文を受け付けた場合、生成部で生成した購買識別情報に基づいてユーザの注文額を立替えてオンラインストア側に支払う。請求部は、ユーザの注文額の所定期間内の合計額をユーザ側に請求する。購買識別情報を用いることにより、ユーザの注文に対する継続課金を行うことができ、ユーザは、定期購入をすることができる。

１ ネットワーク
１０ 端末装置
１１ 制御部
１２ 通信部
１３ 記憶部
１４ 表示画面
１５ 操作部
２０ ウェブサーバ
３０ 事業者サーバ
４０ 審査エンジンサーバ
４１ 学習モデル
４２ 電話番号検証部
５０ 注文決済サーバ
５１ 制御部
５２ 通信部
５３ 記憶部
５３１ 注文履歴ＤＢ
５４ 判定部
５５ 決済実行部

Claims (10)

1. オンラインストアにアクセスしたユーザの端末装置から電話番号を含むユーザ識別情報を取得する識別情報取得部と、
   前記ユーザの、店舗でアカウントを作成してからの経過日数、取引開始から現在までの注文総数、取引開始から現在までの注文の総額、及び最後の注文からの経過日数の少なくとも一つを含む注文データを取得する注文データ取得部と、
   該識別情報取得部で取得した電話番号を用いて認証された認証情報を前記端末装置から取得する認証情報取得部と、
   前記注文データ取得部で取得した注文データ、並びに注文に対する未払い金額及び未払い期間に応じて前記ユーザの注文決済の可否を判定する判定部と
   を備える注文決済装置。
2. 前記注文データ取得部は、
   前記注文データに含まれる前記ユーザの住所を取得し、
   前記判定部は、
   前記ユーザの住所の存否又は住所の変遷に基づいて前記ユーザの注文決済の可否を判定する請求項１に記載の注文決済装置。
3. 前記注文データに含まれる前記ユーザの電話番号の使用履歴を取得する使用履歴取得部を備え、
   前記判定部は、
   前記電話番号の使用履歴に基づいて前記ユーザの注文決済の可否を判定する請求項１又は請求項２に記載の注文決済装置。
4. 注文データに基づいて学習した学習モデルに、前記注文データを入力する入力部を備え、
   前記判定部は、
   前記学習モデルの出力に基づいて前記ユーザの注文決済の可否を判定する請求項１から請求項３のいずれか一項に記載の注文決済装置。
5. 前記判定部は、
   前記学習モデルが出力する未払いの確率に基づいて前記ユーザの注文決済の可否を判定する請求項４に記載の注文決済装置。
6. 前記判定部は、
   前記学習モデルが出力する信用度に基づいて前記ユーザの注文決済の可否を判定する請求項４又は請求項５に記載の注文決済装置。
7. 前記判定部で前記ユーザの注文決済が可であると判定した場合、前記オンラインストアでの前記ユーザの注文額を立替えて前記オンラインストア側に支払う支払部と、
   前記ユーザの注文額の所定期間内の合計額を前記ユーザ側に請求する請求部と
   を備える請求項１から請求項６のいずれか一項に記載の注文決済装置。
8. 前記判定部で前記ユーザの定期購買の注文決済が可であると判定した場合、前記オンラインストアでの定期購買のための購買識別情報を生成する生成部と、
   前記ユーザの定期購買の注文を受け付けた場合、前記生成部で生成した購買識別情報に基づいて前記ユーザの注文額を立替えて前記オンラインストア側に支払う支払部と、
   前記ユーザの注文額の所定期間内の合計額を前記ユーザ側に請求する請求部と
   を備える請求項１から請求項６のいずれか一項に記載の注文決済装置。
9. コンピュータに、
   オンラインストアにアクセスしたユーザの端末装置から電話番号を含むユーザ識別情報を取得する処理と、
   前記ユーザの、店舗でアカウントを作成してからの経過日数、取引開始から現在までの注文総数、取引開始から現在までの注文の総額、及び最後の注文からの経過日数の少なくとも一つを含む注文データを取得する処理と、
   取得した電話番号を用いて認証された認証情報を前記端末装置から取得する処理と、
   取得した注文データ、並びに注文に対する未払い金額及び未払い期間に応じて前記ユーザの注文決済の可否を判定する処理と
   を実行させるコンピュータプログラム。
10. オンラインストアにアクセスしたユーザの端末装置から電話番号を含むユーザ識別情報を識別情報取得部が取得し、
    前記ユーザの、店舗でアカウントを作成してからの経過日数、取引開始から現在までの注文総数、取引開始から現在までの注文の総額、及び最後の注文からの経過日数の少なくとも一つを含む注文データを注文データ取得部が取得し、
    取得された電話番号を用いて認証された認証情報を前記端末装置から認証情報取得部が取得し、
    取得された注文データ、並びに注文に対する未払い金額及び未払い期間に応じて前記ユーザの注文決済の可否を判定部が判定する注文決済方法。

Images