TWI822927B - 訂單結帳裝置、記錄媒體以及訂單結帳方法 - Google Patents

Abstract

提供一種訂單結帳裝置、記錄媒體以及訂單結帳方法，能夠讓訂單結帳變得簡化，並讓使用者的便利性提升。 訂單結帳裝置(50) ，包含：識別資訊取得部(52)，從存取網路商店的使用者的終端裝置(10)，取得包含電話號碼的使用者識別資訊；訂單資料取得部(52)，取得使用者的訂單資料；認證資訊取得部(52)，利用取得的電話號碼，從終端裝置(10)取得認證的認證資訊；以及判定部(54)，利用取得的訂單資料，判定使用者的訂單結帳的可否。

Description

訂單結帳裝置、記錄媒體以及訂單結帳方法

本發明是關於訂單結帳裝置、記錄媒體以及訂單結帳方法。

隨著包含網際網路技術以及加密技術的安全技術之進展，使用個人電腦或智慧型手機的網路購物的用戶正在增加。例如，特開2006-302311號公報揭示了一種線上購物系統，該線上購物系統使用的認證號碼，一旦使用一次之後就無法使用。

然而，特開2006-302311號公報那樣的線上購物系統中，支付購買金額的結帳，大多是利用信用卡或是利用貨到付款。

因此，未持有信用卡的使用者，不便的地方就在於無法線上購物。另外，為了貨到付款而必須待在家裡，對使用者來說並不方便。

本發明是有鑑於此般情事而成，目的在於提供一種訂單結帳裝置、記錄媒體以及訂單結帳方法，能夠讓訂單結帳變得簡化，並讓使用者的便利性提升。

關於本發明的實施形態的訂單結帳裝置，包含：識別資訊取得部，從存取網路商店的使用者的終端裝置，取得包含電話號碼的使用者識別資訊；訂單資料取得部，取得該使用者的訂單資料；認證資訊取得部，利用由該識別資訊取得部取得的該電話號碼，從該終端裝置取得認證的認證資訊；以及判定部，利用由該訂單資料取得部取得的該訂單資料，判定該使用者的訂單結帳的可否。

關於本發明的實施形態的電腦可讀取非暫態記錄媒體，記錄電腦程式，該電腦程式使電腦執行：從存取網路商店的使用者的終端裝置，取得包含電話號碼的使用者識別資訊之處理；取得該使用者的訂單資料之處理；利用取得的該電話號碼，從該終端裝置取得認證的認證資訊之處理；以及利用取得的該訂單資料，判定該使用者的訂單結帳的可否之處理。

關於本發明的實施形態的訂單結帳方法，包含：從存取網路商店的使用者的終端裝置，取得包含電話號碼的使用者識別資訊；取得該使用者的訂單資料；利用取得的該電話號碼，從該終端裝置取得認證的認證資訊；以及利用取得的該訂單資料，判定該使用者的訂單結帳的可否。

根據本發明，能夠讓訂單結帳變得簡化，並讓使用者的便利性提升。

以下，對本發明的實施形態基於圖式進行說明。第1圖為一方塊圖，示意本實施形態的訂單結帳系統的構成的一例。訂單結帳系統具備訂單結帳伺服器50，訂單結帳伺服器50作為訂單結帳裝置。訂單結帳伺服器50與網路1連接，網路1包含網際網路。訂單結帳伺服器50與審查引擎伺服器40連接。審查引擎伺服器40具備學習模型41以及電話號碼驗證部42。另外，網路1與使用者的終端裝置10、網路伺服器20以及企業伺服器30連接。另外，為方便起見，第1圖的範例中，只繪出1台終端裝置10，然而終端裝置10並不僅限於1台。

終端裝置10包含如智慧型手機（手機）、筆記型個人電腦、或平板電腦等。終端裝置10具備：控制裝置全體的控制部11、通訊部12、記憶部13、顯示畫面14以及操作部15。控制部11可以由CPU（中央處理器）、ROM（唯讀記憶體）以及RAM（隨機存取記憶體）等構成。另外，控制部11與企業伺服器30之間具備介面功能。

通訊部12具有透過網路1，與網路伺服器20、訂單結帳伺服器50以及企業伺服器30執行通訊的功能，能夠執行必要資訊的收發。

記憶部13是由硬碟或快閃記憶體等所構成，儲存網路瀏覽器之類的應用程式（未圖示）。

顯示畫面14可以由液晶面板或有機EL（Electro Luminescence，電場發光）顯示器等構成。操作部15可以如由嵌入在顯示畫面14的觸控面板構成，可以接受使用者在顯示畫面14上執行的既定的操作。另外，操作部15可以接受顯示於顯示畫面14的鍵盤上的操作。另外，操作部15可以是硬體鍵盤或滑鼠等。

網路伺服器20提供網路商店（網站），網路商店是運用企業伺服器30的企業（例如，商品的販賣者）所提供。第1圖的範例中，網路商店A（網頁上的假想店鋪）中顯示了商品a、商品b…。使用者可以使用終端裝置10存取網路商店而購買商品。

企業伺服器30具備訂單管理功能。舉例來說，能夠執行訂單履歷的記憶、商品的發送處理等。

訂單結帳伺服器50具備：控制伺服器全體的控制部51、通訊部52、記憶部53、判定部54以及結帳執行部55。控制部51可以由CPU、ROM以及RAM等構成。

通訊部52具有透過網路1，與終端裝置10、網路伺服器20以及企業伺服器30執行通訊的功能，能夠執行必要資訊的收發。

通訊部52具備作為識別資訊取得部的功能，從存取網路伺服器20的網路商店的使用者的終端裝置10，取得包含電話號碼的使用者識別資訊。使用者識別資訊除了電話號碼（例如，手機號碼）之外，也可以設為使用者的電子郵件地址。

通訊部52具有作為認證資訊取得部的功能，利用使用者的電話號碼，從終端裝置10取得認證的認證碼（認證資訊）。舉例來說，能夠將認證碼傳送給使用者的手機，終端裝置10將送達的認證碼送出，藉以執行使用者的認證。此時，使用者並不需要事先登錄信用卡，或輸入信用卡的資訊，而能讓使用者的便利性提升。另外，使用者並不需要使用密碼，而是在每次使用時發行認證碼，因此能讓便利性提升，而不損失安全性。

通訊部52具備作為訂單資料取得部的功能，當取得使用者識別資訊後，取得使用者的訂單資料。訂單資料並不僅是本次的訂單資料，也可以包含該使用者過去的訂單資料（訂單履歷資料）。本次的訂單資料可以從網路伺服器20取得。舉例來說，訂單履歷資料能夠基於使用者在網路商店上的帳號資訊等而抽取出，例如，可以從企業伺服器30取得。能夠藉由訂單資料來驗證關於使用者訂單的情況。

更具體來說，訂單結帳伺服器50與存取網路商店的終端裝置10之間的資訊交換，可以用以下的方式執行。換句話說，事先導入企業所準備在網路商店的支付頁面上運作的結帳用應用程式。使用者能夠相應透過終端裝置10所執行的網路商店上的操作，將該結帳用應用程式必要的資訊傳送給訂單結帳伺服器50。另外，將訂單結帳伺服器50必要的資訊傳送給結帳用應用程式後，該資訊將輸出至終端裝置10或顯示於終端裝置10。

判定部54利用取得的訂單資料判定使用者的訂單結帳的可否。舉例來說，基於與使用者的訂單有關的情況，而能夠在使用者的支付情況沒有問題時，判定為訂單可結帳。另外，能夠在存在未付款的情況時，判定為訂單不可結帳。藉此，舉例來說，使用者只需要輸入電話號碼（手機號碼）與電子郵件地址、以及認證碼，就可以完成訂單結帳，因此能讓使用者的便利性提升。訂單結帳的可否的判定方法的詳細將於後面說明。

記憶部53是由硬碟或快閃記憶體等所構成，儲存決定訂單結帳伺服器50的處理順序的電腦程式、訂單履歷DB 531。

結帳執行部55執行訂單金額的支付處理、或請款處理等。支付處理以及請款處理的詳細將於後面說明。

第2圖為一說明圖，示意本實施形態的訂單結帳系統的程序的第1例。第1例示意正常（僅限一次）結帳的情形。以下針對程序P1至P13進行說明。

程序P1當中，使用者使用終端裝置10存取網路商店，決定購買商品，並開始結帳。

程序P2當中，終端裝置10的顯示畫面14顯示了電話號碼以及電子郵件地址的輸入畫面，當使用者輸入電話號碼以及電子郵件地址後，終端裝置10取得輸入的電話號碼以及電子郵件地址。

程序P3當中，終端裝置10將輸入的電話號碼以及電子郵件地址傳送給訂單結帳伺服器50。

程序P4當中，訂單結帳伺服器50取得訂單資料。

程序P5當中，訂單結帳伺服器50取得該使用者的訂單履歷資料。此處，訂單資料是本次的訂單資料；訂單履歷資料是過去的訂單資料，但也可以包含訂單履歷資料而作為訂單資料。

程序P6當中，訂單結帳伺服器50經由SMS（Short Message Service，短訊息服務）將認證碼傳送給終端裝置10。另外，第2圖的範例中，是將認證碼傳送給終端裝置10之構成，然而也可以傳送給不同於終端裝置10的手機。

程序P7當中，終端裝置10的顯示畫面14顯示認證碼的輸入畫面，當使用者輸入認證碼後，終端裝置10取得輸入的認證碼。

程序P8當中，終端裝置10將輸入的認證碼傳送給訂單結帳伺服器50。

程序P9當中，訂單結帳伺服器50基於訂單資料（包含訂單履歷資料），判定訂單結帳的可否。

程序P10當中，判定為訂單可結帳時，訂單結帳伺服器50將結帳資料傳送給企業伺服器30。

程序P11當中，企業伺服器30在執行商品的發送處理後，執行結帳完成；程序P12當中，企業伺服器30將結帳完成通知傳送給訂單結帳伺服器50。藉此，訂單結帳伺服器50代墊使用者的訂單的金額（訂購金額），並支付給企業。

程序P13當中，訂單結帳伺服器50彙整既定期間（例如，1個月）的該使用者的訂購金額而執行請款（1次請款）。

第3圖為一模式圖，示意顯示在終端裝置10的顯示畫面14的輸入畫面100的第1例。輸入畫面100顯示有：顯示使用者決定購買的商品的區域101、輸入電話號碼的區域102、輸入電子郵件地址的區域103、以及支付圖標104。輸入畫面100是根據使用者決定購買的商品，在不繪出的畫面執行支付開始的操作而顯示。區域101顯示使用者購買商品的店舖名（圖例中是網路商店A）、商店名、金額等。使用者輸入自己的電話號碼以及電子郵件地址後，若操作支付圖標104，將顯示後面所述的輸入畫面110。

第4圖為一模式圖，示意顯示在終端裝置10的顯示畫面14的輸入畫面110的第2例。輸入畫面110除了區域101之外，還顯示了輸入認證碼的區域111。認證碼經由SMS傳送給由輸入畫面100輸入的電話號碼（圖例為XXXX）的手機（也可以是終端裝置10）。

第5圖為一模式圖，示意顯示在終端裝置10的顯示畫面14的結帳判定結果畫面120的一例。當訂單結帳伺服器50基於使用者的訂單資料判定訂單可結帳時，顯示結帳判定結果畫面120。藉此，使用者只需要輸入電話號碼（手機號碼）與電子郵件地址以及認證碼，就可以完成訂單結帳，因此能讓使用者的便利性提升。另外，第3圖至第5圖所示的畫面為一例，而不限定於該等畫面。

接著，針對基於訂單資料的訂單結帳的可否的判定方法進行說明。首先，針對訂單資料進行說明。

第6圖為一說明圖，示意訂單資料的內容的一例。如第6圖所示，訂單資料包含：網路商店的店舖名、本次的訂單資訊、使用者資訊、使用者的住址（商品的送達地點的住址）、以及履歷資訊。本次的訂單資訊，包含商品ID、商品的個數、商品的名稱以及商品的單價。使用者資訊，包含姓名、電話號碼以及電子郵件地址。履歷資訊，包含在店鋪作成帳號迄今的經過天數、從交易開始到現在的訂單總數、從交易開始到現在的訂單的總額、最後一次訂單的金額、最後一次訂單迄今的經過天數。如第6圖所示，訂單資料可以按照每個使用者記錄在訂單履歷DB 531。利用訂單資料，可以驗證與使用者的訂單有關的情況。另外，訂單資料的內容並不限定於第6圖之例。

接著，針對利用使用者的電話號碼的訂單結帳的可否的判定方法進行說明。

判定部54將訂單資料當中的使用者的電話號碼輸出給審查引擎伺服器40。審查引擎伺服器40的電話號碼驗證部42，具備電話號碼的使用履歷資料庫，探索使用履歷資料庫，特定出從訂單結帳伺服器50輸出的電話號碼的使用履歷。電話號碼驗證部42將特定出的使用履歷輸出給訂單結帳伺服器50。

判定部54具有作為使用履歷取得部的功能，從審查引擎伺服器40取得訂單資料當中的使用者的電話號碼的使用履歷。電話號碼的使用履歷，包含如電話號碼的使用開始迄今的經過期間、或使用次數等。使用履歷的取得，可以利用如電話號碼的使用履歷資料庫等。

判定部54可以基於電話號碼的使用履歷而判定使用者的訂單結帳的可否。

第7圖為一說明圖，示意訂單結帳可否的判定方法的第1例。如第7圖所示，舉例來說，能夠在電話號碼的使用期間（使用開始迄今的經過期間）為6個月以上時，無論本次訂單的金額如何，都判定為訂單可結帳。另外，能夠在電話號碼的使用期間在3個月以上（6個月未滿）時，若本次訂單的金額未滿10000日圓，則判定為訂單可結帳。另外，能夠在電話號碼的使用期間在1個月以上（3個月未滿）時，若本次訂單的金額未滿5000日圓，則判定為訂單可結帳。能夠在電話號碼的使用期間未滿1個月時，判定為訂單不可結帳。另外，第7圖之例為其中一例，期間、金額並不限定於第7圖之例。

如上所述，能夠在使用開始迄今的經過時間很短時，或是連1次都沒使用過的電話號碼等情況時，認為是非法使用或仿冒的可能性高，而判定為訂單不可結帳。藉此，能夠讓使用者的便利性提升的同時，適切判定訂單結帳的可否。

接著，針對利用使用者的住址的訂單結帳的可否的判定方法進行說明。

判定部54可以基於使用者的住址的存在與否或住址的變遷，而判定使用者的訂單結帳的可否。

第8圖為一說明圖，示意訂單結帳的可否的判定方法的第2例。如第8圖所示，舉例來說，能夠在使用者的住址的情況並不真實存在時，判定為訂單不可結帳。另外，能夠在使用者的住址的情況在過去6個月內已變更2次時，判定為訂單不可結帳。另外，能夠在使用者的住址的情況在過去1年以上沒有變更時，判定為訂單可結帳。另外，第8圖之例為其中一例，並不限定於第8圖之例。

如上所述，能夠在使用者的住址為並不真實存在的地址時（然而，送達地點的住址真實存在時），視為該使用者的信用度低，而判定為訂單不可結帳。另外，能夠在使用者的住址在比較短的期間之內變更時，也視為該使用者的信用度低，而判定為訂單不可結帳。藉此，能夠讓使用者的便利性提升的同時，適切判定訂單結帳的可否。

接著，針對利用使用者的未付款資訊的訂單結帳的可否的判定方法進行說明。

判定部54可以基於訂單的未付款資訊而判定使用者的訂單結帳的可否。

第9圖為一說明圖，示意訂單結帳的可否的判定方法的第3例。如第9圖所示，舉例來說，能夠在未付款金額為0日圓時，判定為訂單可結帳。另外，能夠在未付款金額未滿3000日圓時，若未付款天數（支付日期迄今的經過天數）未滿2個月，則判定為訂單可結帳；或未付款天數在2個月以上，則判定為訂單不可結帳。另外，能夠在未付款金額為3000日圓以上且未滿5000日圓時，若未付款天數未滿1個月，則判定訂單可結帳；若未付款天數在1個月以上，則判定訂單不可結帳。另外，能夠在未付款金額為5000以上時，判定為訂單不可結帳。另外，第9圖之例為其中一例，期間、金額並不限定於第9圖之例。

如上所述，能夠在未發生過訂單未付款時，視為該使用者的信用度高，而判定為訂單可結帳。另外，能夠在發生過訂單未付款時，依照未付款金額或未付款期間而判定訂單結帳的可否。藉此，能夠讓使用者的便利性提升的同時，適切判定訂單結帳的可否。

接著，針對利用學習模型41的訂單結帳的可否的判定方法進行說明。

判定部54具有作為輸入部的功能，將使用者的訂單資料，輸入到基於訂單資料學習的學習模型41。學習模型41可以使用如多層的類神經網路（深層學習），但也可以使用其他的機器學習。學習模型41像是將訂單資料、該訂單資料對應的訂單的信賴性（使用者的信賴性），作為學習資料而學習之學習後的學習模型。

判定部54能夠基於學習模型41的輸出而判定使用者的訂單結帳的可否。藉著利用由多數的訂單資料學習的學習模型41，能夠高精度判定訂單結帳的可否。

第10圖為一模式圖，示意學習模型41的構成的一例。如第10圖所示，是由輸入層、輸出層以及複數個中間層所構成。另外在第10圖中，為了方便起見，繪出了2個中間層，然而中間層的層數並不限定於2個，也可以為3個以上。

輸入層、輸出層以及中間層之中，存在有1個或複數個節點（神經元）；各層的節點與前後層存在的節點，以及一個方向上期望的權重耦合。具有與輸入層的節點個數相同分量的向量，被給定作為學習模型41的輸入資料。輸入資料可以設為如訂單資料，包含：帳號作成後的經過天數、訂單總數、訂單總額、最後一次訂單的金額、最後一次訂單迄今的經過天數等。另外，帳號作成後的經過天數、訂單總數、訂單總額、最後一次訂單的金額等資料，能夠向量化並輸入到輸入層的各節點。

給到輸入層各節點的資料，當輸入到最初的中間層之後，利用權重以及活化函數而算出中間層的輸出，算出的值將給到下一個中間層，以下用相同的方式，接連傳遞到後面的層（下層），直到求得輸出層的輸出為止。另外，所有耦合節點的權重都是由學習演算法所計算。

學習模型41的輸出層，舉例來說，輸出信用度作為輸出資料。輸出資料可以視為向量形式的資料，具有與輸出層的節點個數（輸出層的大小）相同大小的分量。輸出層的節點，舉例來說，可以將使用者的訂單（或是使用者本身）的信用度區分為100%、90%、80%、…、50%。另外，來自於輸出層的輸出值，可以解釋為分類為各類別的信用度的機率。舉例來說，可以將信用度為100%、90%、80%、…、50%的各節點當中，機率最高的節點，或機率在臨界值以上的節點的信用度，作為學習模型41的輸出值。另外，信用度的數值並非限定於第10圖之例，舉例來說，也能夠以5%為間隔輸出，也能夠輸出0%～100%的範圍。另外，來自於輸出層的輸出資料，並不限定於信用度，也可以是未付款的機率。

另外，也可以將第10圖所示的輸入資料以及輸出資料作為學習資料，讓學習模型41學習。

學習模型41可以由硬體的組合所構成，例如：CPU（如實裝多核心的多處理器等）、GPU（Graphics Processing Units，圖像處理器）、DSP（Digital Signal Processors，數位訊號處理器）、或FPGA（Field-Programmable Gate Arrays，場式可程式閘陣列）等。另外，也可以將量子處理器組合。學習模型41並不限定於類神經網路模型，也可以是其他的機器學習模型。

第11圖為一說明圖，示意訂單結帳的可否的判定方法的第4例。如第11圖所示，能夠在學習模型41的輸出值為信用度100%時，判定為訂單可結帳。另外，能夠在學習模型41的輸出值為信用度90%時，若本次的訂單的金額未滿10000日圓，則判定為訂單可結帳。另外，雖然第11圖中並未繪出，但也能夠在學習模型41的輸出值為信用度90%時，若本次的訂單的金額為10000日圓以上，則判定為訂單不可結帳。另外，能夠在學習模型41的輸出值為信用度80%時，若本次的訂單的金額未滿5000日圓，則判定為訂單可結帳。另外，能夠在學習模型41的輸出值為信用度70%以下時，判定為訂單不可結帳。另外，示意信用度的數值（90%等）為其中一例，並不限定於該等數值。

如上所述，判定部54能夠基於學習模型41輸出的信用度而判定使用者的訂單結帳的可否。舉例來說，能夠在信用度為100%時，判定為訂單可結帳。另外，能夠在信用度為80以上時，依照訂單的金額的多寡，判定訂單結帳的可否。另外，能夠在信用度為70%以下時，判定為訂單不可結帳。藉此，能夠讓使用者的便利性提升的同時，高精度判定訂單結帳的可否。

另外，學習模型41輸出的信用度，並未限定於如前面所述的相對值（80%、90%、100%），也可以設為如550分、600分這樣的得分（絕對值）。例如，將信用度的最高分設為1000分，能夠在學習模型41輸出的信用度在900分以上時，判定為訂單可結帳。另外，能夠在學習模型41輸出的信用度未滿900分且在700分以上時，若本次的訂單的金額未滿10000日圓，則判定為訂單可結帳。另外，能夠在學習模型41輸出的信用度未滿700分且在550分以上時，若本次的訂單的金額未滿5000日圓，則判定為訂單可結帳。另外，能夠在學習模型41輸出的信用度未滿550分時，判定為訂單不可結帳。另外，得分為其中一例，並未限定於該等數值。

另外，學習模型將未付款機率作為輸出值輸出時，能夠如以下判定訂單結帳的可否。換言之，判定部54能夠基於學習模型41輸出的未付款的機率，而判定使用者的訂單結帳的可否。舉例來說，能夠在未付款的機率為0%時，判定為訂單可結帳。另外，能夠在未付款的機率未滿30%時，依照訂單的金額的多寡，判定訂單結帳的可否。另外，能夠在未付款的機率為30%以上時，判定為訂單不可結帳。藉此，能夠讓使用者的便利性提升的同時，高精度判定訂單結帳的可否。

結帳執行部55具有作為支付部的功能，當判定部54判定使用者的訂單結帳為可時，代墊網路商店的使用者的訂購金額，並支付給網路商店側（意即，企業伺服器30、運用網路商店的企業或販賣者等）。

結帳執行部55具有作為請款部的功能，向使用者側（例如，終端裝置10或其他使用者所使用的手機或資訊處理裝置等）請款使用者的訂購金額在既定期間內的合計金額。既定期間可以設為如1個月。藉此，即便使用者在既定期間之內下訂單複數次，也不會每次下訂單都被請款，而是在每個既定期間，僅彙整為1次而請款，因此對使用者來說，好處是不會產生每次購物的手續費等的費用。

接著，針對定期購買（例如，定期購買某商品）的情形進行說明。

第12圖為一說明圖，示意本實施形態的訂單結帳系統的程序的第2例。第2例示意定期購買結帳的情形。以下針對程序P21至P38進行說明。

程序P21當中，使用者使用終端裝置10存取網路商店，決定購買商品，並開始定期購買的結帳。

以下，由於程序P22至程序P28與第2圖例示的程序P2至程序P8相同，故省略說明。

程序P29當中，訂單結帳伺服器50產生定期購買識別資訊。定期購買識別資訊為使用者識別資訊（各企業識別使用者的帳號的資訊），是用來在訂單結帳伺服器50執行使用者的結帳。

程序P30當中，訂單結帳伺服器50基於訂單資料（包含訂單履歷資料）判定訂單結帳的可否。

程序P31當中，當判定為訂單可結帳時，訂單結帳伺服器50將結帳資料以及定期購買識別資訊傳送給企業伺服器30。

程序P32當中，企業伺服器30執行商品的發送處理後，執行結帳完成；程序P33當中，企業伺服器30將結帳完成通知傳送給訂單結帳伺服器50。藉此，訂單結帳伺服器50代墊使用者的訂單的金額（訂購金額），並支付給企業。

程序P34當中，訂單結帳伺服器50彙整既定期間（例如，1個月）的該使用者的訂購金額並請款（1次請款）。

程序P35當中，終端裝置10將下次的定期購買的訂單傳送給訂單結帳伺服器50。

程序P36當中，利用該使用者的定期購買識別資訊，將結帳資料傳送給企業伺服器30。

程序P37當中，企業伺服器30執行商品的發送處理後，執行結帳完成；程序P38當中，企業伺服器30將結帳完成通知傳送給訂單結帳伺服器50。藉此，訂單結帳伺服器50代墊使用者的訂單的金額（訂購金額），並支付給企業。

程序P39當中，訂單結帳伺服器50彙整既定期間（例如，1個月）的該使用者的訂購金額並請款（1次請款）。之後，重複程序P34至程序P38相同的程序。

另外，在上述的例子中，也可以在不執行程序P35的情況下，執行第2次以後的定期購買。也就是說，也可以事先決定第2次以後的結帳處理日、商品的發送日等，直到該日來臨時，再來執行程序P36至程序P38。

結帳執行部55具有作為產生部的功能，在使用者的認證後（更具體來說，是在判定訂單可否結帳之前），產生用於網路商店上的定期購買的購買識別資訊。

結帳執行部55在接受使用者的定期購買的訂單時，基於產生的購買識別資訊代墊使用者的訂購金額，並支付給網路商店側。結帳執行部55向使用者側請款使用者的訂購金額在既定期間內的合計金額。藉由使用購買識別資訊，而能夠針對使用者的訂單繼續徵收金額；而使用者能夠進行定期購買。

第13圖為一流程圖，示意在終端裝置10的處理順序的一例。以下為了方便起見，將處理的主體作為控制部11進行說明。控制部11存取網路商店(S11)，相應使用者的操作而決定購買商品(S12)。控制部11相應使用者的操作而開始訂單的結帳(S13)。

控制部11接收使用者輸入的電話號碼、電子郵件地址(S14)，將接收到的電話號碼、電子郵件地址傳送給訂單結帳伺服器50(S15)。使用者看到經由SMS送到手機（終端裝置10也可）的認證碼，將認證碼輸入到終端裝置10後，控制部11接收輸入的認證碼(S16)，將接收到的認證碼傳送給訂單結帳伺服器50(S17)。

控制部11從訂單結帳伺服器50接收結帳判定結果(S18)，判定可否結帳(S19)。若可結帳(在S19為YES)，則控制部11判定是否接受其他商品的購買(S20)，若接受其他商品的購買(在S20為YES)，則繼續步驟S12以後的處理。

若不接受其他商品的購買(在S20為NO)，則控制部11結束處理。若不可結帳(在S19為NO)，則控制部通知不可結帳(S21)並結束處理。

第14圖為一流程圖，示意在訂單結帳伺服器50的處理順序的一例。以下為了方便起見，將處理的主體作為控制部51進行說明。控制部51判定開始結帳與否(S31)，若結帳並未開始(在S31為NO)，則繼續步驟S31的處理。若結帳已經開始(在S31為YES)，則控制部51從終端裝置10接收電話號碼、電子郵件地址(S32)，並取得使用者的訂單資料(S33)。

控制部51經由SMS傳送認證碼(S34)。控制部51判定是否已經從終端裝置10收到認證碼(S35)，當收到認證碼時(在S35為YES)，若比對收到的認證碼與傳送的認證碼一致，則利用使用者的訂單資料判定結帳可否(S36)。

判定為可結帳時(在S37為YES)，控制部51將可結帳通知傳送給終端裝置10(S38)，並將關於訂單的結帳資料傳送給企業伺服器30(S39)。控制部51判定是否已經從企業伺服器30收到結帳完成通知(S40)，若沒有收到結帳完成通知(在S40為NO)，則繼續步驟S40的處理。

若已收到結帳完成通知(在S40為YES)，則控制部51彙整既定期間的該使用者的訂單的總額以及請款(S41)，並結束處理。若未收到認證碼 (在S35為NO)，或是判定為不可結帳(在S37為NO)，則控制部將不可結帳通知傳送給終端裝置10(S42)，並結束處理。

訂單結帳伺服器50能夠利用具備CPU（處理器）、RAM等的電腦來實現。將定義如第14圖所示的處理的順序的電腦程式（可記錄於電腦可讀取的非暫態記錄媒體）載入電腦具備的RAM，並由CPU（處理器）執行電腦程式，能夠藉以在電腦上實現訂單結帳伺服器50。

如上所述，根據本實施形態，使用者只要輸入電話號碼以及電子郵件地址，就可以完成在網路商店的訂單的結帳，因此，即使未持有信用卡，也能夠執行線上購物。另外，由於可以減輕信用卡的登錄或信用卡資訊輸入的時間與心力，因此使用者的便利性得以提升。另外，使用信用卡時並不會產生安全的疑慮。另外，使用者並不需要使用密碼，而是在每次使用時發行認證碼，因此能讓便利性提升，而不損失安全性。

另外，根據本實施形態，由於並不需要像貨到付款那樣的支付方法，因此並不需要待在家中等待商品的到貨，而提升使用者的便利性。

另外，根據本實施形態，在既定期間內（例如，1個月）即使多次購買商品，也不會在每一次購買時支付，只要在既定期間內支付1次的購買金額即可，舉例來說，每次購買商品都不會產生手續費的費用。藉此，能夠得到的好處在於使用者不需要支付無謂的費用。

另外，根據本實施形態，使用者購買商品後，能夠在企業（加盟店）確定有貨並在出貨時執行的抓貨(Capture)處理時完成結帳，而企業能夠收取購買金額，舉例來說，不會產生取貨付款造成的取消風險。

關於本實施形態的訂單結帳裝置，具備：識別資訊取得部，從存取網路商店的使用者的終端裝置，取得包含電話號碼的使用者識別資訊；訂單資料取得部，取得該使用者的訂單資料；認證資訊取得部，利用由該識別資訊取得部取得的該電話號碼，從該終端裝置取得認證的認證資訊；以及判定部，利用由該訂單資料取得部取得的該訂單資料，判定該使用者的訂單結帳的可否。

關於本實施形態的電腦可讀取非暫態記錄媒體，記錄電腦程式，該電腦程式使電腦執行：從存取網路商店的使用者的終端裝置，取得包含電話號碼的使用者識別資訊之處理；取得該使用者的訂單資料之處理；利用取得的該電話號碼，從該終端裝置取得認證的認證資訊之處理；以及利用取得的該訂單資料，判定該使用者的訂單結帳的可否之處理。

關於本實施形態的訂單結帳方法，包含：從存取網路商店的使用者的終端裝置，取得包含電話號碼的使用者識別資訊；取得該使用者的訂單資料；利用取得的該電話號碼，從該終端裝置取得認證的認證資訊；以及利用取得的該訂單資料，判定該使用者的訂單結帳的可否。

識別資訊取得部，從存取網路商店的使用者的終端裝置，取得包含電話號碼的使用者識別資訊。使用者識別資訊，除了電話號碼（例如，手機號碼）之外，也可以設為使用者的電子郵件地址。終端裝置，可以是智慧型手機，也可以是個人電腦或平板電腦。

訂單資料取得部，取得使用者的訂單資料。訂單資料，不僅包含本次的訂單資料之外，還可以包含該使用者過去的訂單資料（訂單履歷資料）。訂單履歷資料，舉例來說，可以基於使用者在網路商店上的帳號資訊等而抽取出。能夠藉由訂單資料來驗證關於使用者訂單的情況。

認證資訊取得部，利用取得的電話號碼，從終端裝置取得認證的認證資訊。舉例來說，能夠藉由傳送認證資訊到使用者的手機，終端裝置將送達的認證資訊送出，藉以執行使用者的認證。此時，使用者並不需要事先登錄信用卡，或輸入信用卡的資訊，而能讓使用者的便利性提升。

判定部，利用取得的訂單資料判定使用者的訂單結帳的可否。舉例來說，基於與使用者的訂單有關的情況，而能夠在使用者的支付情況沒有問題時，判定為訂單可結帳。另外，能夠在存在未付款的情況時，判定為訂單不可結帳。藉此，使用者只需要輸入使用者識別資訊以及認證資訊，就可以完成訂單結帳，因此能讓使用者的便利性提升。

關於本實施形態的訂單結帳裝置，其中，該訂單資料取得部，取得該訂單資料當中的該使用者的住址；該判定部，基於該使用者的住址存在與否或住址的變遷，判定該使用者的訂單結帳的可否。

訂單資料取得部，取得訂單資料當中的使用者的住址。判定部，基於使用者的住址的存在與否或住址的變遷，判定使用者的訂單結帳的可否。舉例來說，能夠在使用者的住址為並不真實存在的地址時（然而，送達地點的住址真實存在時），視為該使用者的信用度低，而判定為訂單不可結帳。另外，能夠在使用者的住址在比較短的期間之內變更時，也視為該使用者的信用度低，而判定為訂單不可結帳。藉此，能夠讓使用者的便利性提升的同時，適切判定訂單結帳的可否。

關於本實施形態的訂單結帳裝置，其中，該判定部，基於訂單的未付款資訊，判定該使用者的訂單結帳的可否。

判定部，基於訂單的未付款資訊，判定使用者的訂單結帳的可否。舉例來說，能夠在未發生過訂單未付款時，視為該使用者的信用度高，而判定為訂單可結帳。另外，能夠在發生過訂單未付款時，依照未付款金額或未付款期間而判定訂單結帳的可否藉此，能夠讓使用者的便利性提升的同時，適切判定訂單結帳的可否。

關於本實施形態的訂單結帳裝置，具備：使用履歷取得部，取得該訂單資料當中的該使用者的電話號碼的使用履歷；該判定部，基於該電話號碼的使用履歷，判定該使用者的訂單結帳的可否。

使用履歷取得部，取得訂單資料當中的使用者的電話號碼的使用履歷。電話號碼的使用履歷，包含如電話號碼的使用開始迄今的經過期間、或使用次數等。使用履歷的取得，可以利用如電話號碼的使用履歷資料庫等。

判定部，基於電話號碼的使用履歷，判定使用者的訂單結帳的可否。舉例來說，能夠在使用開始迄今的經過時間很短時，或是連1次都沒使用過的電話號碼等情況時，認為是非法使用或仿冒的可能性高，而判定為訂單不可結帳。藉此，能夠讓使用者的便利性提升的同時，適切判定訂單結帳的可否。

關於本實施形態的訂單結帳裝置，具備：輸入部，將該訂單資料輸入至學習模型，該學習模型基於該訂單資料而學習；該判定部，基於該學習模型的輸出，判定該使用者的訂單結帳的可否。

輸入部，將使用者的訂單資料輸入至學習模型，該學習模型基於使用者的訂單資料而學習。學習模型可以使用如多層的類神經網路（深層學習），但也可以使用其他的機器學習。學習模型像是將訂單資料、該訂單資料對應的訂單的信賴性（使用者的信賴性），作為學習資料而學習之學習後的學習模型。

判定部，基於學習模型的輸出而判定使用者的訂單結帳的可否。藉著利用由多數的訂單資料學習的學習模型，能夠高精度判定訂單結帳的可否。

關於本實施形態的訂單結帳裝置，其中，該判定部，基於該學習模型輸出的未付款的機率，判定該使用者的訂單結帳的可否。

判定部，基於學習模型輸出的未付款的機率，判定使用者的訂單結帳的可否。舉例來說，能夠在未付款的機率為0%時，判定為訂單可結帳。另外，能夠在未付款的機率未滿30%時，依照訂單的金額的多寡，判定訂單結帳的可否。另外，能夠在未付款的機率為30%以上時，判定為訂單不可結帳。藉此，能夠讓使用者的便利性提升的同時，高精度判定訂單結帳的可否。

關於本實施形態的訂單結帳裝置，其中，該判定部，基於該學習模型輸出的信用度，判定該使用者的訂單結帳的可否。

判定部，基於學習模型輸出的信用度，判定使用者的訂單結帳的可否。舉例來說，能夠在信用度為100%時，判定為訂單可結帳。另外，能夠在信用度為80以上時，依照訂單的金額的多寡，判定訂單結帳的可否。另外，能夠在信用度為70%以下時，判定為訂單不可結帳。藉此，能夠讓使用者的便利性提升的同時，高精度判定訂單結帳的可否。

關於本實施形態的訂單結帳裝置，具備：支付部，當該判定部判定該使用者的訂單結帳為可時，代墊該網路商店上的該使用者的訂購金額，並支付給該網路商店側；以及請款部，向該使用者側請款該使用者的訂購金額在既定期間內的合計金額。

支付部，當判定部判定使用者的訂單結帳為可時，代墊網路商店上的使用者的訂購金額，並支付給網路商店側。請款部，向使用者請款使用者的訂購金額在既定時間內的合計金額。既定期間，可以設為如1個月。藉此，即便使用者在既定期間之內下訂單複數次，也不會每次下訂單都被請款，而是在每個既定期間，僅彙整為1次而請款，因此對使用者來說，好處是不會產生每次購物的手續費等的費用。

關於本實施形態的訂單結帳裝置，具備：產生部，當該判定部判定該使用者的定期購買的訂單結帳為可時，產生購買識別資訊，該購買識別資訊用於該網路商店上的定期購買；支付部，當接受該使用者的定期購買的訂單時，基於該產生部產生的購買識別資訊，代墊該使用者的訂購金額，並支付給該網路商店側；以及請款部，向該使用者側請款該使用者的訂購金額在既定期間內的合計金額。

產生部，當判定部判定使用者的定期購買的訂單結帳為可時，產生購買識別資訊，該購買識別資訊用於網路商店上的定期購買。

支付部，當接受使用者的定期購買的訂單時，基於產生部產生的購買識別資訊，代墊使用者的訂購金額，並支付給網路商店側。請款部，向使用者側請款使用者的訂購金額在既定期間內的合計金額。藉由使用購買識別資訊，而能夠針對使用者的訂單繼續徵收金額；而使用者能夠進行定期購買。

1:網路 10:終端裝置 11:控制部 12:通訊部 13:記憶部 14:顯示畫面 15:操作部 20:網路伺服器 30:企業伺服器 40:審查引擎伺服器 41:學習模型 42:電話號碼驗證部 50:訂單結帳伺服器 51:控制部 52:通訊部 53:記憶部 531:訂單履歷DB 54:判定部 55:結帳執行部 100:輸入畫面 101:區域 102:區域 103:區域 104:支付圖標 110:輸入畫面 111:區域 120:結帳判定結果畫面 121:圖標 P1、P2、…、P13:程序 P21、P22、…、P39:程序 S11、S12、…、S21:步驟 S31、S32、…、S42:步驟

第1圖為一方塊圖，示意本實施形態的訂單結帳系統的構成的一例。 第2圖為一說明圖，示意本實施形態的訂單結帳系統的程序的第1例。 第3圖為一模式圖，示意顯示在終端裝置的顯示畫面的輸入畫面的第1例。 第4圖為一模式圖，示意顯示在終端裝置的顯示畫面的輸入畫面的第2例。 第5圖為一模式圖，示意顯示在終端裝置的顯示畫面的結帳判定結果畫面的一例。 第6圖為一說明圖，示意訂單資料的內容的一例。 第7圖為一說明圖，示意訂單結帳可否的判定方法的第1例。 第8圖為一說明圖，示意訂單結帳可否的判定方法的第2例。 第9圖為一說明圖，示意訂單結帳可否的判定方法的第3例。 第10圖為一模式圖，示意學習模型的構成的一例。 第11圖為一說明圖，示意訂單結帳可否的判定方法的第4例。 第12圖為一說明圖，示意本實施形態的訂單結帳系統的程序的第2例。 第13圖為一流程圖，示意在終端裝置的處理順序的一例。 第14圖為一流程圖，示意在訂單結帳伺服器的處理順序的一例。

1:網路

10:終端裝置

11:控制部

12:通訊部

13:記憶部

14:顯示畫面

15:操作部

20:網路伺服器

30:企業伺服器

40:審查引擎伺服器

41:學習模型

42:電話號碼驗證部

50:訂單結帳伺服器

51:控制部

52:通訊部

53:記憶部

531:訂單履歷DB

54:判定部

55:結帳執行部

Claims (11)

1. 一種訂單結帳裝置，包含：識別資訊取得部，從存取網路商店的使用者的終端裝置，取得包含電話號碼的使用者識別資訊；訂單資料取得部，取得該使用者的訂單資料；認證資訊取得部，利用由該識別資訊取得部取得的該電話號碼，從該終端裝置取得認證的認證資訊；以及判定部，利用由該訂單資料取得部取得的該訂單資料，判定該使用者的訂單結帳的可否；該訂單資料包含本次的訂單資料以及屬於該使用者過去的訂單資料的訂單履歷資料。
2. 如申請專利範圍第1項所述之訂單結帳裝置，其中，該訂單資料取得部，取得該訂單資料當中的該使用者的住址；其中，該判定部，基於該使用者的住址存在與否或住址的變遷，判定該使用者的訂單結帳的可否。
3. 如申請專利範圍第1項所述之訂單結帳裝置，其中，該判定部，基於訂單的未付款資訊，判定該使用者的訂單結帳的可否。
4. 如申請專利範圍第1項至第3項的任何一項所述之訂單結帳裝置，包含：使用履歷取得部，取得該訂單資料當中的該使用者的電話號碼的使用履歷；其中，該判定部， 基於該電話號碼的使用履歷，判定該使用者的訂單結帳的可否。
5. 如申請專利範圍第1項至第3項的任何一項所述之訂單結帳裝置，包含：輸入部，將該訂單資料輸入至學習模型，該學習模型基於該訂單資料而學習；其中，該判定部，基於該學習模型的輸出，判定該使用者的訂單結帳的可否。
6. 如申請專利範圍第5項所述之訂單結帳裝置，其中，該判定部，基於該學習模型輸出的未付款的機率，判定該使用者的訂單結帳的可否。
7. 如申請專利範圍第5項所述之訂單結帳裝置，其中，該判定部，基於該學習模型輸出的信用度，判定該使用者的訂單結帳的可否；該信用度為基於該使用者的住址存在與否或住址的變遷。
8. 如申請專利範圍第1項至第3項的任何一項所述之訂單結帳裝置，包含：支付部，當該判定部判定該使用者的訂單結帳為可時，代墊該網路商店上的該使用者的訂購金額，並支付給該網路商店側；以及請款部，向該使用者側請款該使用者的訂購金額在既定期間內的合計金額。
9. 如申請專利範圍第1項至第3項的任何一項所述之訂單結帳裝置，包含：產生部，當該判定部判定該使用者的定期購買的訂單結帳為可時，產生購買識別資訊，該購買識別資訊用於該網路商店上的定期購買；支付部，當接受該使用者的定期購買的訂單時，基於該產生部產生的購買識 別資訊，代墊該使用者的訂購金額，並支付給該網路商店側；以及請款部，向該使用者側請款該使用者的訂購金額在既定期間內的合計金額。
10. 一種電腦可讀取非暫態記錄媒體，記錄電腦程式，該電腦程式使電腦執行：從存取網路商店的使用者的終端裝置，取得包含電話號碼的使用者識別資訊之處理；取得該使用者的訂單資料之處理；利用取得的該電話號碼，從該終端裝置取得認證的認證資訊之處理；以及利用取得的該訂單資料，判定該使用者的訂單結帳的可否之處理；該訂單資料包含本次的訂單資料以及屬於該使用者過去的訂單資料的訂單履歷資料。
11. 一種訂單結帳方法，包含：從存取網路商店的使用者的終端裝置，取得包含電話號碼的使用者識別資訊；取得該使用者的訂單資料；利用取得的該電話號碼，從該終端裝置取得認證的認證資訊；以及利用取得的該訂單資料，判定該使用者的訂單結帳的可否；該訂單資料包含本次的訂單資料以及屬於該使用者過去的訂單資料的訂單履歷資料。

Images