TW202334886A - 下單系統、下單方法、及程式產品 - Google Patents

Abstract

[課題]讓使用者利用電子貨幣來對定期定額商品進行下單。 [解決手段]下單系統(S)的結帳時機判定部(110)，係判定關於使用者所下單之定期定額商品的結帳時機是否已經到來。結帳處理執行部(111)，係在判定為結帳時機已經到來的情況下，基於使用者所保有之電子貨幣、與使用者所指定之定扣額，而執行關於定期定額商品的結帳處理。下單處理執行部(112)，係執行關於定期定額商品的下單處理。

Description

下單系統、下單方法、及程式產品

本揭露係有關於下單系統、下單方法、及程式產品。

先前，投資信託或股票這類各種投資商品，已為人知。例如，專利文獻1中係記載，作為使用者所入金的電子貨幣之運用方法，可劃撥到本金保證的運用帳戶，或是執行關於國債、公司債、或投資信託的結帳處理等等。例如，專利文獻2中係記載，將信用卡的點數轉換成現金，透過銀行帳戶而對投資商品帳戶進行了入金之後，執行對投資商品帳戶所被設定之月繳金所相應之結帳處理。 [先前技術文獻] [專利文獻]

[專利文獻1]日本特開2020-30491號公報 [專利文獻2]日本特表2008-529116號公報

[發明所欲解決之課題]

然而，專利文獻1之技術，係只不過是在使用者每次將電子貨幣進行入金時，就對國債、公司債、或投資信託進行下單而已，因此無法使用電子貨幣來對被定期性下單的定期定額商品，進行下單。專利文獻2之技術，係只不過是利用信用卡的點數來對定期定額商品進行下單而已，因此無法利用電子貨幣來對定期定額商品進行下單。在先前之技術中，無法讓使用者利用電子貨幣來對定期定額商品進行下單。

本揭露的目的之1，係可讓使用者利用電子貨幣來對定期定額商品進行下單。 [用以解決課題之手段]

本揭露所述之下單系統，係含有：結帳時機判定部，係判定關於使用者所下單之定期定額商品的結帳時機是否已經到來；和結帳處理執行部，係在判定為前記結帳時機已經到來的情況下，基於前記使用者所保有之電子貨幣、與前記使用者所指定之定扣額，而執行關於前記定期定額商品的結帳處理；和下單處理執行部，係執行關於前記定期定額商品的下單處理。 [發明效果]

若依據本揭露，則使用者係可利用電子貨幣來對定期定額商品進行下單。

[1.下單系統的全體構成]

說明本揭露所述之下單系統的實施形態之一例。圖1係為下單系統的全體構成之一例的圖示。下單系統S係含有：電子貨幣伺服器10、證券伺服器20、及使用者終端30。這些係可連接至網際網路或LAN等之網路N。下單系統S係只要包含有至少1台電腦即可，不限於圖1的例子。

電子貨幣伺服器10，係為結帳事業者的伺服器電腦。控制部11係含有至少1個處理器。記憶部12係含有RAM等之揮發性記憶體、和硬碟等之非揮發性記憶體。通訊部13係含有有線通訊用的通訊介面、和無線通訊用的通訊介面之至少一方。

證券伺服器20，係為證券公司的伺服器電腦。控制部21、記憶部22、及通訊部23的實體構成，係可分別和控制部11、記憶部12、及通訊部13相同。

使用者終端30，係為使用者的電腦。例如，使用者終端30係為個人電腦、智慧型手機、平板終端、或可穿戴式終端。控制部31、記憶部32、及通訊部33的實體構成，係可分別和控制部11、記憶部12、及通訊部13相同。操作部34，係為觸控面板等之輸入裝置。顯示部35，係為液晶顯示器或有機EL顯示器。

此外，記憶部12、22、32中所被記憶的程式，係亦可透過網路N而被供給。又，資訊記憶媒體中所被記憶的程式，亦可透過用來讀取電腦可讀取之資訊記憶媒體的讀取部(例如光碟驅動機或記憶卡插槽)、或用來與外部機器進行資料之輸出入所需之輸出入部(例如USB埠)而被供給。

[2.下單系統的概要] 在本實施形態中，使用者係可利用由結帳事業者所提供的結帳服務、和由證券公司所提供的投資服務。結帳服務，係為關於電子結帳的服務。電子結帳，有時候也被稱作無現金結帳。在本實施形態中，作為結帳服務中可利用的結帳手段之一例，是說明屬於所謂的預付式支付手段之一種的電子貨幣，但在結帳服務中，亦可利用信用卡或銀行帳戶這類其他的結帳手段。

投資服務，係為關於投資的服務。在投資服務中，投資對象之商品也就是投資商品，係被提供給使用者。投資服務，係亦可藉由證券公司以外之其他業者(例如銀行等之金融機關或其他公司)，而被提供。在本實施形態中，作為投資商品之一例，是說明所定之定扣額會被定期性累積的定期定額商品。然後，作為定期定額商品之一例，是說明投信定期定額。因此，記載為投信定期定額的地方，係可替換成投資商品或定期定額商品。

此外，投資服務中所被提供的投資商品，係可為任意之種類，不限於投信定期定額。例如，投資商品係亦可為像是股票、外幣、國債、其他有價證券、黃金、或白金這類，以投資信託以外的物為對象的商品。投資商品，係亦可不是定期定額商品，亦可為只受理一次下單的商品。下單，係亦可指投資商品的購入或收購。在本實施形態中，由於是在投資商品的結帳方法上存有特徵，因此投資商品的機制本身，係可利用公知的機制。

在本實施形態中，雖然舉出使用者是從使用者終端30的應用程式，來利用結帳服務及投資服務的情況為例，但使用者係亦可從使用者終端30的瀏覽器，來利用結帳服務及投資服務之至少一方，尤其亦可不利用使用者終端30即利用結帳服務及投資服務之至少一方。以下，將結帳事業者所提供的應用程式，稱作結帳應用程式。將證券公司所提供的應用程式，稱作證券應用程式。

例如，使用者係可從結帳應用程式，來利用關於結帳服務所提供之電子貨幣的各種功能。在本實施形態中，作為電子貨幣之一例，是舉出線上型的電子貨幣為例，但電子貨幣係可為任意之形式，不限於線上型的電子貨幣。例如，電子貨幣係亦可為利用IC卡的形式、利用使用者終端30的IC晶片的形式、或利用磁卡的形式。

線上型的電子貨幣，係為可在電子商務交易服務或旅行預約服務這類網際網路服務中做利用的電子貨幣。線上型的電子貨幣，係亦可在實體店舖中做利用。例如，使用者係可利用條碼或二維碼這類代碼，而在實體店舖中利用線上型的電子貨幣。以下，將線上型的電子貨幣，簡稱為電子貨幣。

圖2及圖3係為使用者終端30上所被顯示的畫面之一例的圖示。例如，一旦使用者終端30的證券應用程式啟動，則用來登入至投資服務所需之登入畫面G1係被顯示於顯示部35。使用者，係一旦在輸入表單F10、F11中，輸入了投資服務中的使用者ID及密碼並選擇了按鈕B12，就會執行往投資服務的登入處理。

一旦使用者登入至投資服務，則投資服務的頂層畫面G2係被顯示於顯示部35。使用者，係可選擇按鈕B20~B23來對投資商品進行下單。例如，一旦使用者選擇了用來下單投信定期定額所需之按鈕B21，就可指定投信定期定額之設定也就是定期定額設定。定期定額設定的流程本身，係可為公知的流程，在本實施形態中是舉出投資信託之指定、結帳方法之指定、及定扣額與定扣指定日之指定的這類流程為例。

例如，一旦使用者選擇了按鈕B21，則用來指定投信定期定額之對象的投資信託所需之投資信託指定畫面G3係被顯示於顯示部35。使用者，係可從投資信託指定畫面G3，檢索出可在投資服務中進行下單的投資信託。一旦使用者檢索到所望之投資信託並選擇了按鈕B30，則用來指定結帳方法所需之結帳方法指定畫面G4係被顯示於顯示部35。

結帳方法，係為投信定期定額之結帳時所利用的方法。結帳方法，係亦可稱為定扣額之支付方法或扣款方法。在圖2的例子中，作為投信定期定額之結帳方法，係準備了電子貨幣(在圖2中係為「YYY電子現金」)、信用卡、及證券帳戶這3種。結帳方法，係不限於這些，亦可準備有利用點數等的其他結帳方法。使用者，係藉由選擇按鈕B40~B42任一者，就可指定任意之結帳方法。在本實施形態中，係舉出電子貨幣是被指定來作為結帳方法的情況為例。

例如，一旦使用者選擇了電子貨幣所對應之按鈕B40然後選擇了按鈕B43，就進入圖3，用來指定定扣額與定扣指定日所需之定扣額等指定畫面G5係被顯示於顯示部35。一旦使用者在輸入表單F50、F51中輸入了定扣額與定扣指定日並選擇了按鈕B52，則結帳應用程式就會啟動，結帳服務的登入畫面G6係被顯示於顯示部35。證券應用程式，係會移動到背景執行。

在本實施形態中，使用者，係為了避免因電子貨幣之餘額不足而導致投信定期定額之下單被取消，而可利用電子貨幣的自動加值功能。例如，使用者，在首次利用自動加值功能的情況下，係進行所定之申辦手續。在申辦手續中，會進行利用規範的同意或加值方法之指定。此處係假設，使用者已經完成了自動加值功能的申辦手續。

例如，一旦使用者在輸入表單F60、F61中輸入了結帳服務之使用者ID及密碼並選擇了按鈕B62，就會執行往結帳服務的登入處理。在本實施形態中是舉出，結帳服務的使用者ID、與投資服務的使用者ID係為彼此相同的情況為例。使用者必須要用與登入至投資服務的使用者ID相同的使用者ID，來對結帳服務進行登入。

一旦對結帳服務的登入成功，則用來指定自動加值設定所需之自動加值設定畫面G7係被顯示於顯示部35。在圖3的例子中，作為加值方法，是指定了信用卡。使用者，係亦可從自動加值設定畫面G7來變更加值方法。例如，一旦使用者在輸入表單F70、F71中輸入了加值閾值與加值後餘額並選擇了按鈕B72，自動加值設定就會被保存在結帳服務中。

加值閾值，係為作為是否要執行自動加值處理之基準的餘額之閾值。在本實施形態中雖然是設計成，在未滿加值閾值的情況下會執行自動加值處理，但亦可為，在變成加值閾值以下的情況就執行自動加值處理。使用者，係可指定任意的加值閾值。例如，使用者係將投信定期定額的定扣額以上之數值，指定作為加值閾值。加值閾值，假設係指定了加值後餘額以下之數值。

加值後餘額，係為自動加值處理後的餘額。加值後餘額，係亦可說是電子貨幣中所被常備的餘額。在本實施形態中係說明，不是指定自動加值額，而是指定加值後餘額的情況。亦即，並非「若餘額未滿50,000圓，則進行10,000圓加值」的此種自動加值設定，而是「若餘額未滿50,000圓，則使餘額變成51,000圓」的此種自動加值設定，係被指定。使用者，係可指定任意的加值後餘額。例如，使用者係將投信定期定額的定扣額以上之數值，指定作為加值後餘額。加值後餘額，假設係指定了加值閾值以上之數值。

一旦自動加值設定完成，證券應用程式就會回到前景執行。一旦使用者從證券應用程式做了下單內容之最終確認或個人識別碼之輸入而確定了下單，則表示下單已完成的下單完成畫面G8係被顯示於顯示部35。一旦投信定期定額的下單完成，則使用者所指定的投資信託，就會以使用者所指定之定扣額，在使用者所指定之定扣指定日，自動地被購入。自動加值處理，係會因應需要而被執行。

圖4係為投信定期定額之下單完成後的流程之一例的圖示。圖4的t軸，係為時間軸。在圖4中，T(T係自然數)月中所被執行的處理，與T月之前後的月中所被執行的處理，係被圖示。T為1的情況下，係T-1月，係為前年的12月。T為12的情況下，則T+1月，係為翌年的1月。投信定期定額中的時間系列性流程本身，係可利用公知的各種流程，不限於圖4的例子。

在圖4的例子中，使用者係將「基金A」、「基金B」、及「基金C」這3個投信定期定額，以電子貨幣進行下單。「基金A」的定扣額，係為「10,000圓」。「基金A」的指定定扣日，係為「每月3日」。「基金B」的定扣額，係為「15,000圓」。「基金B」的指定定扣日，係為「每月12日」。「基金C」的定扣額，係為「25,000圓」。「基金C」的指定定扣日，係為「每月25日」。

例如，在T-1月的13日，T+1月中的投信定期定額的定期定額設定會被開始。在T月的12日，T+1月中的投信定期定額的定期定額設定係會截止。T月的15日，係為T+1月中的投信定期定額的結帳時機。所謂結帳時機，係為應執行結帳處理的時機。在圖4的例子中雖然圖示了電子貨幣的結帳時機，但結帳時機係亦可隨著結帳方法而不同。例如，作為結帳方法是指定了信用卡的情況下，則亦可為，在T月的13日會執行授權，在T+1月的27日會進行從銀行帳戶之扣款。

一旦來到T月的15日中的所定時刻(例如上午3時)，就基於T月的12日中所被截止的定期定額設定，而執行電子貨幣的結帳處理。在圖4的例子中，使用者所指定之3個投資信託的定期定額金的合計額也就是「50,000圓」，係會從電子貨幣的餘額被扣款。若使用者的自動加值設定，是如圖3所示「若餘額未滿50,000圓，則使餘額變成51,000圓」的此種內容，則電子貨幣的餘額就會總是變成結帳處理中所需要之金額(圖4的例子中係為「50,000圓」)以上。因此，T月的15日中的結帳處理，原則上不會失敗。一旦來到T月的月末，從結帳事業者對證券公司，就會執行T月中已被執行的電子貨幣的結帳處理所相應之入金。

一旦來到T+1月，則在使用者所指定的定扣指定日，就會自動執行使用者所指定之投資信託的下單處理。若為圖4的例子，則一旦來到T+1月的3日，「基金A」就會被下單「10,000圓」。一旦來到T+1月的12日，「基金B」就會被下單「15,000圓」。一旦來到T+1月的25日，「基金C」就會被下單「25,000圓」。在本實施形態的下單系統S中，藉由重複如圖4所示的流程，利用電子貨幣的投信定期定額之下單係被重複。以下，說明下單系統S的細節。

[3.下單系統中所被實現的機能] 圖5係為下單系統S中所被實現的機能之一例的機能區塊圖。

[3-1.電子貨幣伺服器中所被實現的機能] 資料記憶部100，係以記憶部12為主而被實現。其他各機能是以控制部11為主而被實現。

[資料記憶部] 資料記憶部100，係將用來向使用者提供結帳服務所需要的資料，加以記憶。例如，資料記憶部100，係將電子貨幣資料庫DB1，加以記憶。

圖6係為電子貨幣資料庫DB1之一例的圖示。如圖6所示，電子貨幣資料庫DB1係為，儲存有關於結帳服務中的使用者之資訊的資料庫。例如，電子貨幣資料庫DB1中係被儲存有：使用者ID、密碼、電子貨幣之餘額、加值方法資訊、自動加值設定、及結帳設定。電子貨幣資料庫DB1中所被儲存的資訊，係可為關於使用者的任意之資訊，不限於圖6的例子。例如，電子貨幣資料庫DB1中亦可被儲存有，電子貨幣的利用履歷或加值履歷。

使用者ID，係為關於使用者的使用者資訊之一例。因此，針對使用者ID做說明的地方，係可替換成使用者資訊。使用者資訊，係可為能夠識別使用者的任意之資訊，亦可為例如：被稱作使用者帳號的資訊、郵件位址、或電話號碼。使用者資訊，係亦可為使用者的姓名。例如，使用者資訊係為文字、數字、其他符號，或這些的組合。使用者ID及密碼，係為了登入至結帳服務而被利用。電子貨幣之餘額，係為現狀的餘額。餘額，係表示0以上之任意之數值。餘額亦可被設定有上限。

加值方法資訊，係為關於電子貨幣之加值方法的資訊。所謂加值方法，係為在電子貨幣的加值中所利用的結帳手段。加值方法，係可為任意之結帳手段，亦可為例如：信用卡、銀行帳戶、線上跳蚤市場服務的銷售額、加密資產、或點數。例如，信用卡相當於加值方法的情況下，則加值方法資訊係表示：卡號、有效期限、及名義人。例如，銀行帳戶是相當於加值方法的情況下，則加值方法資訊係表示：銀行名、分行名、帳戶號碼、及名義人。其他加值方法的情況也是同樣地，加值方法資訊係只要表示出能夠識別加值方法的資訊即可。加值方法資訊，係可藉由使用者的操作而做變更。

自動加值設定，係為關於自動加值的設定。在本實施形態中雖然說明，自動加值設定是表示加值閾值及加值後餘額的情況，但自動加值設定係亦可僅表示加值閾值或加值後餘額之其中一方。除此以外還亦可為，例如，在使用者可以指定執行自動加值處理的自動加值時機的情況下，則自動加值設定係亦可表示自動加值時機。自動加值設定，係可藉由使用者的操作而做變更。甚至，在使用者以手動進行的通常之加值處理的加值方法，與自動加值處理的加值方法為不同的情況下，自動加值處理的加值方法亦可被自動加值設定所表示。在本實施形態中，雖然說明藉由加值方法資訊所表示的加值方法而執行自動加值處理的情況，但自動加值處理係亦可僅選擇利用到特定之信用卡的加值方法。

結帳設定，係為關於投信定期定額之結帳處理的設定。電子貨幣資料庫DB1中所被儲存之結帳設定，係只要至少包含有，投資資料庫DB2中所被儲存之定期定額設定之中的，電子貨幣之結帳處理所必須之資訊即可。在圖6的例子中，作為結帳設定，假設投資信託ID及定扣額是已被儲存在電子貨幣資料庫DB1中。在使用者可指定結帳時機的情況下，則結帳設定係亦可表示結帳時機。在電子貨幣以外之結帳方法是已被指定的情況下，則結帳設定係亦可表示結帳方法。

此外，資料記憶部100中所被記憶的資料，係不限於電子貨幣資料庫DB1。資料記憶部100，係只要記憶有結帳服務所必須之資料即可。例如，資料記憶部100係亦可記憶，用來令自動加值設定畫面G7等之畫面被使用者終端30進行顯示所必須之資料。

[一致判定部] 在本實施形態中，投信定期定額，係藉由投資服務而被提供。電子貨幣，係藉由異於投資服務的結帳服務而被提供。投資服務中的使用者ID、與結帳服務中的使用者ID，係被利用彼此相同者，因此一致判定部101，係判定投資服務中的使用者ID、結帳服務中的使用者ID是否一致。亦即，一致判定部101係判定，投資服務登入中的使用者、與正要登入至結帳服務的使用者，是否為同一人物。使用者ID為一致，係意味著這是同一人物。

若為圖2及圖3的例子，則一致判定部101係判定，登入畫面G1中所被輸入的使用者ID、與登入畫面G6中所被輸入的使用者ID，是否一致。例如，電子貨幣伺服器10，係在登入畫面G6被顯示前，從證券伺服器20或使用者終端30，取得登入畫面G1中所被輸入的使用者ID。電子貨幣伺服器10係判定，該當已被取得之使用者ID、與登入畫面G6中所被輸入的使用者ID，是否一致。

此外，在使用者ID以外的其他資訊是被當作使用者資訊而利用的情況下，則一致判定部101，係亦可判定其他資訊之一致。例如，使用者的姓名是被當作使用者資訊而利用的情況下，則一致判定部101係亦可判定，投資服務中的使用者的姓名(例如證券帳戶的名義人)、與結帳服務中的使用者的姓名(例如電子貨幣的名義人)，是否一致。在其他資訊是被當作使用者資訊而利用的情況下也是同樣地，一致判定部101係只要判定使用者資訊的一致即可。

[自動加值設定許可部] 自動加值設定許可部102，係基於一致判定部101的判定結果，而許可使用者所做的自動加值設定。自動加值設定許可部102，係在藉由一致判定部101而未被判定為使用者ID一致的情況下，則不許可自動加值設定，在藉由一致判定部101而被判定為使用者ID一致的情況下，則許可自動加值設定。即使自動加值設定未被許可，投信定期定額的下單本身亦可仍是被許可。

若為圖2及圖3的例子，則自動加值設定許可部102，係在藉由一致判定部101而未被判定為使用者ID一致的情況下，則藉由使得自動加值設定畫面G7不被顯示，以不許可自動加值設定。自動加值設定許可部102，係在藉由一致判定部101而被判定為使用者ID一致的情況下，則藉由許可自動加值設定畫面G7之顯示，以許可自動加值設定。亦即，自動加值設定許可部102，係藉由控制是否令自動加值設定畫面G7被顯示，以控制是否許可自動加值設定。

此外，自動加值設定許可部102，係亦可藉由其他方法，來許可自動加值設定。例如，自動加值設定許可部102係亦可為，自動加值設定畫面G7之顯示係為許可，但藉由控制是否限制對自動加值設定畫面G7之輸入，以控制是否許可自動加值設定。例如，自動加值設定許可部102係亦可為，對自動加值設定畫面G7的輸入係為許可，但藉由控制是否要反映至電子貨幣資料庫DB1，以控制是否許可自動加值設定。

[合計額計算部] 合計額計算部103，係在使用者已指定了關於投信定期定額的複數個定期定額設定的情況下，計算關於該當複數個定期定額設定之各者中的定扣額之合計額。合計額，係為結帳處理所必須之金額。在本實施形態中雖然說明，合計額計算部103，係將複數個定期定額設定之各者中的定扣額所合計的值，直接當作合計額而計算的情況，但在會被加算所定之手續費的情況下，則亦可將對定扣額所合計的值加算上手續費後的值，當作合計額而計算。

在本實施形態中，使用者係也可指定電子貨幣以外之其他結帳方法，因此合計額計算部103，係將關於作為結帳方法而被指定的電子貨幣的複數個定期定額設定之各者中的定扣額之合計額，予以計算。指定了電子貨幣以外之其他結帳方法的定期定額設定中的定扣額，係被排除在合計額的計算之外。在某個結帳時機上會發生結帳處理的定期定額設定中的定扣額，係成為合計額之計算對象。

若為圖4的例子，則「基金A」、「基金B」、及「基金C」的合計3個定期定額設定，係被指定。這3個定期定額設定所表示的結帳方法，係為電子貨幣。T月的15日中的結帳時機上，「基金A」的定扣額、「基金B」的定扣額、及「基金C」的定扣額，會成為結帳處理之對象。合計額計算部103，係將「基金A」的定扣額「10,000圓」、「基金B」的定扣額「15,000圓」、及「基金C」的定扣額「25,000圓」予以合計，計算出合計額「50,000圓」。

[可能性判定部] 可能性判定部104，係基於現狀的自動加值設定，來判定下單處理會完成之可能性。所謂下單處理會完成之可能性，係指下單處理是否會確實地完成。換成別的說法，推定在結帳時機上是否有足夠讓下單處理完成之餘額，係相當於判定下單處理會完成之可能性。可能性判定部104，係基於自動加值設定所表示的加值後餘額、與定期定額設定所表示的定扣額，來判定下單處理會完成之可能性。若結帳處理未完成則下單處理就未完成，因此下單處理會完成之可能性，係同義於結帳處理會完成之可能性。

若為圖4的例子，則在T月的15日中的結帳時機上，「基金A」的定扣額、「基金B」的定扣額、及「基金C」的定扣額之合計額「50,000圓」，係為必須。可能性判定部104，係判定現狀的自動加值設定所表示的加值後餘額，是否為定扣額之合計額也就是「50,000圓」以上。可能性判定部104，係若加值後餘額是未滿定扣額之合計額，則判定為有下單處理未完成之可能性，若加值後餘額是定扣額之合計額以上，則判定為有下單處理會完成之可能性。

[自動加值設定畫面顯示部] 自動加值設定畫面顯示部105，係令用來受理自動加值設定之指定的自動加值設定畫面G7，被顯示於使用者終端30。自動加值設定畫面顯示部105，係藉由對使用者終端30，發送自動加值設定畫面G7的顯示資料，以令自動加值設定畫面G7被顯示於使用者終端30。顯示資料，係可為任意之形式。例如，結帳應用程式中所被定義的畫面框格中所被嵌入的各個影像資料，亦可相當於顯示資料。在利用瀏覽器的情況下，則HTML資料亦可相當於顯示資料。例如，自動加值設定畫面顯示部105，係含有金額資訊顯示部106及可能性顯示部107。

金額資訊顯示部106，係令用來受理自動加值設定之指定的自動加值設定畫面G7中，顯示出關於定扣額的金額資訊。在本實施形態中，金額資訊顯示部106，係令自動加值設定畫面G7中顯示出合計額，以作為金額資訊。若為圖3的例子，則金額資訊顯示部106，係令「您的定扣額￥50,000圓」這類的金額資訊，被顯示於自動加值設定畫面G7中。金額資訊顯示部106，係藉由在自動加值設定畫面G7的所定之位置上，配置金額資訊，以令自動加值設定畫面G7顯示出金額資訊。

金額資訊，係只要是關於定扣額的任何資訊皆可，不限於合計額。例如，在使用者是以投信定期定額而只對1個投資信託進行下單的情況下，則金額資訊，係亦可為該當1個投資信託的定扣額。在對定扣額會加算所定之手續費的情況下，則金額資訊係亦可為被加算手續費後的金額。即使在使用者是以投信定期定額而對複數個投資信託進行下單的情況下，仍亦可不是合計額，而是每一者的定扣額，是相當於金額資訊。若為圖4的例子，則亦可像是「基金A的定扣額￥10,000、基金B的定扣額￥15,000、基金C的定扣額￥25,000」的方式，將定扣額之明細顯示於自動加值設定畫面G7。金額資訊，係亦可不是像是圖3的自動加值設定畫面G7的本文，而可為任意之形式。例如，金額資訊，係亦可為小圖示或條狀等其他影像。

圖7係為可能性顯示部107的處理之一例的圖示。可能性顯示部107，係令用來受理自動加值設定之指定的自動加值設定畫面G7中，顯示出可能性判定部104的判定結果。可能性顯示部107，係藉由在自動加值設定畫面G7的所定之位置上，配置表示可能性判定部104之判定結果的資訊，以令自動加值設定畫面G7顯示出可能性判定部104的判定結果。在圖7中，作為該資訊之一例是圖示了訊息M73、M74，但該資訊係可為其他任意之形式，例如亦可為小圖示或其他影像。

在圖7的例子中，可能性顯示部107，係在藉由可能性判定部104而判定為有下單處理會完成之可能性的情況下，則以「已被指定了定扣額以上之金額」這類方式，令表示有下單處理會完成之可能性的訊息M73，被顯示於自動加值設定畫面G7。可能性顯示部107，係在藉由可能性判定部104而判定為有下單處理未完成之可能性的情況下，則以「由於低於定扣額因此會有餘額不足之可能性」這類方式，令表示有下單處理未完成之可能性的訊息M74，被顯示於自動加值設定畫面G7。

[自動加值時機判定部] 自動加值時機判定部108，係判定會定期性到來之自動加值時機是否已經到來。所謂定期性到來，係指每隔所定時間就會到來。亦即，自動加值時機之間隔被固定的這件事情，係相當於定期性到來。自動加值時機，係為應執行自動加值處理的時機。在本實施形態中，雖然舉出全部的使用者間自動加值時機皆為共通的情況為例，但亦可隨著每位使用者來決定自動加值時機。自動加值時機，係亦可由使用者來指定任意之時機。

例如，假設自動加值時機是設成每日的上午3時。自動加值時機判定部108，係利用即時時鐘或GPS訊號等來取得現在日期時間，判定是否已經到了自動加值時機也就是上午3時。自動加值時機判定部108，係在到了上午3時的情況下，判定為自動加值時機已經到來。自動加值時機，係亦可在1日中會到來複數次，亦可複數日才到來1次。

[自動加值處理執行部] 自動加值處理執行部109，係基於定扣額所相應之自動加值設定，而執行關於電子貨幣的自動加值處理。所謂定扣額所相應之自動加值設定，係為被設定成足夠於定扣額的自動加值設定。在本實施形態中，雖然說明使用者是以手動來指定自動加值設定的情況，但自動加值設定係亦可隨應於定扣額而被自動指定。自動加值處理，係為自動執行電子貨幣之加值的處理。電子貨幣之加值，係指增加電子貨幣的餘額。

自動加值處理本身，係可利用公知的各種處理。自動加值處理執行部109，係基於使用者所指定之加值方法，而執行自動加值處理。例如，在使用者指定了信用卡來作為加值方法的情況下，自動加值處理執行部109，係執行信用卡的授權，在授權成功的情況下會使電子貨幣的餘額做增加的方式，來執行加值處理。例如，在使用者指定了銀行帳戶來作為加值方法的情況下，自動加值處理執行部109，係以使得銀行帳戶的餘額做減少而電子貨幣的餘額做增加的方式，來執行加值處理。使用者指定了其他加值方法的情況下，則自動加值處理執行部109，係只要執行其他加值方法所相應之自動加值處理即可。

在本實施形態中，由於是在自動加值設定畫面G7中被指定了自動加值設定，因此自動加值處理執行部109，係基於自動加值設定畫面G7中所被指定的自動加值設定，而執行自動加值處理。在圖3的例子中，雖然說明使用者是在自動加值設定畫面G7中指定加值閾值及加值後餘額之雙方的情況，但在使用者只指定了加值閾值及加值後餘額之其中一方的情況下，則針對他方，係亦可自動地被指定。

在本實施形態中，自動加值設定，係表示自動加值處理被執行後的餘額，但自動加值處理執行部109，係在自動加值設定是指要變成定扣額所相應之加值後餘額的這類情況下，則以會成為自動加值設定所表示的加值後餘額的方式，來執行自動加值處理。自動加值處理執行部109，係基於電子貨幣的現在餘額、自動加值設定所表示的加值後餘額，來決定自動加值額。自動加值處理執行部109，係基於該當已決定之自動加值額，而執行自動加值處理。

在本實施形態中，由於自動加值時機係會定期性地到來，因此自動加值處理執行部109，係在判定為自動加值時機已經到來的情況下，執行自動加值處理。自動加值處理執行部109，係在非判定為自動加值時機已經到來的情況下，就不執行自動加值處理。例如，自動加值處理執行部109，係即使電子貨幣的餘額是未滿加值閾值或加值閾值以下，在判定為自動加值時機已經到來以前，都不會執行自動加值處理。

此外，亦可不設定定期性的自動加值時機。此情況下，自動加值處理執行部109，係亦可在電子貨幣之餘額變成未滿加值閾值或加值閾值以下的情況下，立刻執行自動加值處理。例如，自動加值處理執行部109，係亦可在結帳時機快要來臨之前，執行自動加值處理。例如，自動加值設定中，係亦可不是表示加值後餘額，而是表示加值額，自動加值處理執行部109，係以只加值所定之加值額的方式，來執行自動加值處理。

[結帳時機判定部] 結帳時機判定部110，係判定關於使用者所下單之投信定期定額的結帳時機是否已經到來。結帳時機，係為應執行結帳處理的時機。在本實施形態中，雖然舉出全部的使用者間結帳時機皆為共通的情況為例，但亦可隨著每位使用者來決定結帳時機。結帳時機，係亦可由使用者來指定任意之時機。結帳時機，係亦可基於使用者所指定之定扣指定日，而被自動地決定。

在圖4的例子中，結帳時機，係為每月15日的上午3時。因此，結帳時機，係和自動加值時機同樣地，會定期地到來。結帳時機之間隔係被固定的這件事情，係相當於定期性到來。結帳時機判定部110，係利用即時時鐘或GPS訊號等來取得現在日期時間，判定是否已經到了結帳時機也就是每月15日的上午3時。結帳時機判定部110，係在到了每月15日的上午3時的情況下，判定為結帳時機已經到來。結帳時機，係亦可在1月中會到來複數次，亦可複數月才到來1次。

[結帳處理執行部] 結帳處理執行部111，係在判定為結帳時機已經到來的情況下，基於使用者所保有之電子貨幣、與使用者所指定之定扣額，而執行關於投信定期定額的結帳處理。使用者所指定的定扣額，係被儲存在電子貨幣資料庫DB1中的結帳設定所表示，因此結帳處理執行部111，係基於被結帳設定所表示的定扣額，而執行結帳處理。結帳處理執行部111，係在非判定為結帳時機已經到來的情況下，則不執行結帳處理。結帳處理執行部111，係直到判定為結帳時機已經到來以前，會使結帳處理之執行持續等待。

結帳處理，係為關於投信定期定額中的定扣額之結帳的處理。在本實施形態中，作為結帳方法是指定了電子貨幣，因此結帳處理係為，從電子貨幣之餘額，減去定扣額所相應之金額的處理。例如，結帳處理執行部111，係在使用者指定了複數個定期定額設定的情況下，則基於複數個定期定額設定之各者中的定扣額之合計額，而執行結帳處理。在本實施形態中係舉出，結帳處理執行部111，是以使得電子貨幣之餘額會減少定扣額之合計額的方式，來執行結帳處理情況為例，但結帳處理執行部111，係亦可以使得定扣額之合計額、與所定之手續費所合計的金額，會從電子貨幣之餘額減少的方式，來執行結帳處理。

在本實施形態中，由於是有手動的加值功能與自動加值功能，因此結帳處理執行部111，係可基於加值後的電子貨幣，而執行結帳處理。例如，在結帳處理之前，自動加值處理有被執行的情況下，則結帳處理執行部111，係基於藉由自動加值處理而被加值的電子貨幣，而執行結帳處理。在結帳處理之前，自動加值處理未被執行的情況下，則結帳處理執行部111，係基於使用者以手動進行了加值的電子貨幣，而執行結帳處理。結帳處理執行部111，係亦可基於手動的加值量、與自動加值處理所致之加值量是混合存在於餘額中的電子貨幣，而執行結帳處理。結帳處理執行部111，係亦可僅基於手動的加值量，而執行結帳處理。

此外，電子貨幣係亦可含有：被限制出金的第1餘額、和可出金的第2餘額。例如，第1餘額，係利用信用卡的消費額度而被加值。為了防止消費額度的現金化，第1餘額之出金係被限制。例如，第2餘額，係藉由被許可現金化的加值方法而被加值。例如，第2餘額，係利用銀行帳戶、線上跳蚤市場之銷售額、加密資產、或信用卡的預借現金額度，而被加值。此情況下，結帳處理執行部111，係亦可基於第1餘額及第2餘額之雙方，而執行結帳處理。

在本實施形態中，投信定期定額，係亦可利用使用者的信用卡來進行結帳處理。結帳處理執行部111，係亦可在有別於信用卡所被設定之投信定期定額的上限額的另一上限額之範圍內，執行結帳處理。例如，假設利用到信用卡的投信定期定額是可達每月50,000圓為止，利用到電子貨幣的投信定期定額是可達每月50,000圓為止。此情況下，使用者係可利用信用卡及電子貨幣而合計達到每月100,000圓為止的投信定期定額。使用者，係若可利用銀行帳戶這類其他結帳方法，就可進行更多的投信定期定額。

[下單處理執行部] 下單處理執行部112，係執行關於投信定期定額的下單處理。下單處理，係為將使用者所指定之投資信託進行下單的處理。下單處理本身，係可利用公知的各種處理。下單處理執行部112，係在所定之下單時機已經到來的情況下，執行下單處理。若為投信定期定額，則下單時機，係為定扣指定日。若為投信定期定額以外之投資商品，則結帳時機與下單時機，係可彼此相同或大略相同。所謂時機大略相同，係意味著時間上的偏差是在所定以內。

在本實施形態中，下單處理執行部112，係在結帳處理已被執行的情況下，執行下單處理。下單處理執行部112，係在結帳處理未被執行的情況下，則不執行下單處理。下單處理執行部112，係藉由對證券伺服器20，發送可用來識別結帳處理已完成之下單的資訊，而執行下單處理。該資訊，係亦可為使用者ID，亦可為使用者所指定之投資信託的識別資訊。此外，下單處理，係亦可在結帳處理之前被執行。

[3-2.證券伺服器中所被實現的機能] 資料記憶部200，係以記憶部22為主而被實現。下單處理執行部201，係以控制部21為主而被實現。

[資料記憶部] 資料記憶部200，係將用來向使用者提供投資服務所需要的資料，加以記憶。例如，資料記憶部200，係將投資資料庫DB2，加以記憶。

圖8係為投資資料庫DB2之一例的圖示。如圖8所示，投資資料庫DB2係為，儲存有關於投資服務中的使用者之資訊的資料庫。例如，投資資料庫DB2中係被儲存有：使用者ID、密碼、及定期定額設定。在圖8的例子中，係在投資服務之中，圖示了關於投信定期定額的資訊，但投資資料庫DB2中所被儲存之資訊，係可為關於投資服務的任意之資訊，不限於圖8的例子。例如，投資資料庫DB2中亦可被儲存有，關於投信定期定額以外之投資商品的資訊。

在本實施形態中下說明，結帳服務的使用者ID、與投資服務的使用者ID係為相同的情況。同樣地，是說明結帳服務的密碼、與投資服務的密碼係為相同的情況。投資資料庫DB2中所被儲存的使用者ID及密碼，係為了登入至投資服務而被利用。

定期定額設定，係為關於投信定期定額的設定。例如，定期定額設定係表示：投資信託ID、結帳方法、定扣額、及定扣指定日。投資信託ID，係為可用來識別投資信託的投資信託識別資訊之一例。投資信託識別資訊，係可為任意之資訊，不限於投資信託ID。例如，投資信託識別資訊，係亦可為投資信託的名稱。在使用者新申辦了投信定期定額的情況下，新的定期定額設定會被生成並被儲存在投資資料庫DB2中。在使用者變更了定期定額設定的情況下，投資資料庫DB2中所被儲存之定期定額設定會被變更。

此外，資料記憶部200中所被記憶的資料，係不限於投資資料庫DB2。資料記憶部200，係只要記憶有投資服務所必須之資料即可。例如，資料記憶部200，係亦可記憶圖2及圖3的各畫面的顯示資料。

[下單處理執行部] 下單處理執行部201，係在結帳處理已被執行的情況下，執行關於投信定期定額的下單處理。下單處理，係為將使用者所指定之投資信託進行下單的處理。下單處理本身，係可利用公知的各種處理。下單處理執行部201，係在結帳處理未被執行的情況下，則不執行下單處理。一旦下單處理被執行，則使用者所指定之定期定額設定所表示的定扣額有多少，定期定額設定所表示的投資信託就被購入多少。

[3-3.使用者終端中所被實現的機能] 資料記憶部300，係以記憶部32為主而被實現。顯示控制部301及操作受理部302，係以控制部31為主而被實現。

[資料記憶部] 資料記憶部300，係將為了讓使用者利用結帳服務及投資服務之各者所需要的資料，加以記憶。例如，資料記憶部300，係將結帳應用程式及證券應用程式，加以記憶。

[顯示控制部] 顯示控制部301，係令任意的畫面被顯示於顯示部35。例如，顯示控制部301，係基於結帳應用程式及證券應用程式之至少一方，而令圖2及圖3中所說明的畫面被顯示於顯示部35。各畫面，係亦可在瀏覽器上被顯示。

[操作受理部] 操作受理部302，係受理使用者所做的任意之操作。例如，操作受理部302，係將對於圖2及圖3中所說明的畫面的操作，予以受理。

[4.下單系統中所被執行的處理] 圖9係為下單系統S中所被執行的處理之一例的圖。該處理係藉由控制部11、21、31分別依照記憶部12、22、32中所被記憶之程式而動作，而被執行。圖9中係針對，在下單系統S中所被執行的處理之中，主要與投信定期定額有關的處理，加以圖示。

如圖9所示，使用者終端30，係啟動證券應用程式而令登入畫面G1被顯示於顯示部35，並與證券伺服器20之間，執行用來登入至投資服務所需之登入處理(S1)。在S1中，亦可要求投資服務中的使用者ID及密碼之輸入，亦可將表示過去曾經登入過投資服務的資訊記憶在使用者終端30中，基於該當資訊，而不要求投資服務中的使用者ID及密碼之輸入。

一旦對投資服務的登入為成功，則使用者終端30係令頂層畫面G2被顯示於顯示部35(S2)。在證券伺服器20及使用者終端30之間，會執行用來受理定期定額設定之指定的處理(S3)。在S3中，投資信託指定畫面G3中的投資信託之指定、結帳方法指定畫面G4中的結帳方法之指定、及定扣額等指定畫面G5中的定扣額等之指定，會被進行。

在電子貨幣伺服器10及使用者終端30之間，會執行用來受理自動加值設定之指定的處理(S4)。在S4中，登入畫面G6中的對結帳服務之登入、與自動加值設定畫面G7中的自動加值設定之指定，係被執行。電子貨幣伺服器10，係將電子貨幣資料庫DB1中所被儲存之自動加值設定，更新成表示自動加值設定畫面G7中所被指定之內容。以下，電子貨幣伺服器10，係每當自動加值時機到來時，就執行自動加值處理。在本實施形態中，由於自動加值處理係被每日執行，因此在圖9中係省略。

在證券伺服器20及使用者終端30之間，會執行用來確定投信定期定額之下單的處理(S5)。在S5中，證券伺服器20，係在投資資料庫DB2中所被儲存之定期定額設定，更新成表示S3中所被指定之定期定額設定，並使下單完成畫面G8被顯示於使用者終端30。證券伺服器20，係對電子貨幣伺服器10，發送下單已經確定的定期定額設定。電子貨幣伺服器10，係一旦接收到定期定額設定，就會將電子貨幣資料庫DB1予以更新，以使得在結帳時機已經到來時，執行定期定額設定所相應之結帳處理。

證券伺服器20，係一旦定期定額設定的開始日(在圖4的例子中係為T-1月的13日)到來，則與使用者終端30之間，執行用來變更定期定額設定所需之處理(S6)。S6的處理，係在T-1月的13日到T月的12日為止，會被執行。在使用者未變更定期定額設定的情況下，則S6的處理係不被執行。證券伺服器20，係在使用者有變更定期定額設定的情況下，則對電子貨幣伺服器10，發送變更後的定期定額設定。電子貨幣伺服器10，係一旦接收到變更後的定期定額設定，就以使得定期定額設定之變更會被反映的方式，來更新電子貨幣資料庫DB1。使用者，係在變更了定期定額設定的情況下，亦可將自動加值設定變更成，會成為變更後的定期定額設定所相應之自動加值設定。

證券伺服器20，係一旦定期定額設定之截止日(在圖4的例子中係為T月的12日)到來，就截止定期定額設定(S7)。在S7中，證券伺服器20，係在使用者終端30中所被顯示的畫面中，將用來進行定期定額設定所需之影像予以限制使其不被顯示。電子貨幣伺服器10，係判定結帳時機(在圖4的例子中係為T月的15日)是否已經到來(S8)。在未判定為結帳時機已經到來的情況下(S8；N)，則再次執行S8的處理。在判定為結帳時機已經到來的情況下(S8；Y)，則電子貨幣伺服器10，係基於電子貨幣資料庫DB1，而執行結帳處理(S9)。

電子貨幣伺服器10，係一旦對證券公司的入金時機(在圖4的例子中係為T月的月末)到來，就執行S9的結帳處理所相應之入金處理(S10)。在S10中，電子貨幣伺服器10，係以使得S9之結帳處理之總額會被入金至證券公司的方式，來執行入金處理。電子貨幣伺服器10，係將可用來識別結帳處理已成功之定期定額下單的資訊，發送至證券伺服器20。證券伺服器20，係一旦使用者所指定之定扣指定日(在圖4的例子中係為T+1月的3日、12日、25日)到來，就執行下單處理(S11)，本處理係結束。

本實施形態的下單系統S，係在判定為結帳時機已經到來的情況下，基於電子貨幣、與使用者所指定的定扣額，而執行結帳處理。下單系統S，係執行關於投信定期定額的下單處理。藉此，使用者就可利用電子貨幣來對投信定期定額進行下單。例如，藉由將電子貨幣變成可利用，不必對證券帳戶進行入金，就可進行投信定期定額之下單，因此可減輕使用者的麻煩。例如，電子貨幣係經常會存在有複數個加值方法，可先將使用者的資產集中於電子貨幣，然後才進行投信定期定額所致之資產運用。例如，即使使用者的資產是分散於線上跳蚤市場服務之銷售額或加密資產等，若是可以利用它們來進行加值的電子貨幣，則可先把已被分散的資產集中於電子貨幣，然後來進行投信定期定額的下單。因此，即使無法以線上跳蚤市場服務之銷售額或加密資產這類其他資產來進行投信定期定額的下單，仍可透過電子貨幣的仲介來進行投信定期定額的下單。例如，先前的電子貨幣，雖然相較於現金而利用目的是有所受限，但由於可利用電子貨幣來對投信定期定額進行下單，因此電子貨幣的利用目的就會增加而提高使用者的便利性。

又，下單系統S，係基於定扣額所相應之自動加值設定，而執行自動加值處理。下單系統S，係可基於加值後的電子貨幣，而執行結帳處理。藉此，即使是相較於銀行帳戶之餘額或信用卡之消費額度等而餘額往往會較容易變少的電子貨幣，仍可藉由自動加值處理而確保一定程度之餘額，因此可避免餘額不足所致之下單取消。例如，使用者不必在結帳時機接近時去注意電子貨幣的餘額，因此可提高使用者的便利性。

又，下單系統S，係基於金額資訊所被顯示的自動加值設定畫面G7中所被指定之自動加值設定，而執行自動加值處理。藉此，為了使餘額不足不要發生，必須進行何種自動加值設定才好，這可在自動加值設定畫面G7上容易理解，因此可提高使用者的便利性。例如，可更確實地避免餘額不足所致之下單取消。

又，下單系統S，係在自動加值設定是指要成為定扣額所相應之加值後餘額的這類情況下，則以會成為自動加值設定所表示的加值後餘額的方式，來執行自動加值處理。藉此，可更確實地避免餘額不足所致之下單取消。例如，在「若餘額未滿50,000圓，則進行30,000圓加值」的這類自動加值設定的情況下，在餘額未滿20,000圓的情況下，則由於加值後餘額會變成未滿50,000圓，因此會有餘額不足所致之下單取消發生之可能性。例如，在「若餘額未滿50,000圓，則進行50,000圓加值」的這類自動加值設定的情況下，在餘額稍微低於50,000圓的情況下，加值後餘額就會變成將近100,000圓，因此會變成多到不需要之餘額。如實施形態中所說明的例子般地，在「若餘額未滿50,000圓，則使餘額變成51,000圓」的這類自動加值設定的情況下，可一面使其成為投信定期定額的定扣額以上之加值後餘額，同時防止變成多到不需要的餘額，因此可提高使用者的便利性。

又，下單系統S，係在使用者指定了複數個定期定額設定的情況下，將關於該當複數個定期定額設定之各者中的定扣額之合計額，當作金額資訊而令其被顯示於自動加值設定畫面G7。藉此，即使在使用者對複數個投信定期定額進行下單的情況下也是，為了使餘額不足不要發生，必須進行何種自動加值設定才好，這可在自動加值設定畫面G7上容易理解，因此可提高使用者的便利性。例如，可更確實地避免餘額不足所致之下單取消。

又，下單系統S，係基於現狀的自動加值設定，來判定下單處理會完成之可能性而令自動加值設定畫面G7顯示出判定結果。藉此，為了使餘額不足不要發生，必須進行何種自動加值設定才好，這可在自動加值設定畫面G7上容易理解，因此可提高使用者的便利性。例如，可更確實地避免餘額不足所致之下單取消。

又，下單系統S，係在判定為會定期性到來之自動加值時機已經到來的情況下，執行自動加值處理。藉此，在結帳服務側可容易管理自動加值處理。例如，藉由在電子貨幣伺服器10的處理負荷比較輕的深夜時間帶中設定自動加值時機，可以防止在電子貨幣伺服器10的處理負荷比較高的時間帶中執行自動加值處理。其結果為，可使自動加值處理被確實地完成。

又，下單系統S，係判定投資服務中的使用者ID、與結帳服務中的使用者ID，是否一致。下單系統S，係基於該判定結果，而許可使用者所做的自動加值設定。藉此，會先確認對投信定期定額進行下單的使用者、與進行自動加值設定的使用者是同一人物，然後才會許可自動加值設定，因此可防止第三者所致之不正行為。

又，下單系統S，係基於電子貨幣是被限制出金的第1餘額、和可出金的第2餘額之雙方，而執行結帳處理。藉此，使用者，係可利用第1餘額及第2餘額之雙方來對投信定期定額進行下單，因此可進行有效的投資。例如，在利用信用卡的消費額度來對電子貨幣進行加值的情況下，為了防止消費額度的現金化，對第1餘額限制加值及出金為佳。這點，由於利用到電子貨幣的投信定期定額之下單，係不必對證券帳戶進行入金就能完成下單，因此即使利用出金是被限制的第1餘額，仍可確實地防止消費額度的現金化。

又，下單系統S，係在有別於信用卡所被設定之投信定期定額的上限額的另一上限額之範圍內，執行結帳處理。藉此，使用者係可利用信用卡及電子貨幣之雙方，來進行有效的投資。例如，即使利用到信用卡的投信定期定額的上限額為每月50,000圓，且利用到電子貨幣的投信定期定額的上限額為每月50,000圓，使用者係可利用信用卡及電子貨幣之雙方來進行每月100,000圓為止的投信定期定額之下單，因此可進行有效的投資。

[5.變形例] 此外，本揭露係不限定於以上說明的實施形態。在不脫離本揭露之宗旨的範圍內，可做適宜變更。

圖10係為變形例中的機能區塊之一例的圖示。自動加值設定更新部113、詢問部202、定期定額設定指定畫面顯示部203、自動加值設定更新畫面顯示部204、及必要性判定部205係被實現。自動加值設定更新部113，係以控制部11為主而被實現。詢問部202、定期定額設定指定畫面顯示部203、自動加值設定更新畫面顯示部204、及必要性判定部205，係以控制部21為主而被實現。

[5-1.變形例1] 例如，假設自動加值時機是每日上午3時，每月15日的結帳時機是上午11時。此情況下，從自動加值時機到結帳時機為止之間，若使用者因購物等而利用了電子貨幣，則會有在結帳時機上發生餘額不足之可能性。因此，自動加值處理執行部109，係亦可在結帳時機快要來臨之前，執行自動加值處理。若為上記的例子，則自動加值處理執行部109，係在每日上午3時執行自動加值處理，且在每月15日的上午11時快要來臨之前，執行自動加值處理。

所謂結帳時機快要來臨之前，係為結帳時機的所定時間前的時機。該所定時間，係可為任意之長度，例如亦可為數秒~1小時左右。該所定時間越短，變成餘額不足的機率就越低。該所定時間，係為全部使用者的自動加值處理可以完成之程度的長度即可。在變形例1中係會存在有：會定期性到來的第1自動加值時機(在上記的例子中係為每日上午3時)、和結帳時機快要來臨之前的第2自動加值時機(在上記的例子中係為每月15日的上午11時的所定時間前)。

自動加值時機判定部108，係和實施形態同樣地，判定第1自動加值時機是否已經到來。變形例1的自動加值時機判定部108，係基於現在日期時間，而判定第2自動加值時機是否已經到來。自動加值處理執行部109，係在藉由自動加值時機判定部108而判定為第2自動加值時機已經到來的情況下，則執行自動加值處理。結帳處理執行部111，係在自動加值處理剛被執行後，執行結帳處理。自動加值處理及結帳處理本身，係和實施形態相同。

此外，亦可第1自動加值時機係為不存在，而只有第2自動加值時機存在。亦即，亦可定期性的自動加值處理係不被執行，而只有結帳時機快要來臨之前的自動加值處理會被執行。此情況下，使用者因為購物等之其他目的而利用了電子貨幣的情況下，雖然會有發生餘額不足之可能性，但由於在結帳時機快要來臨之前就會執行自動加值處理，因此關於投信定期定額中的餘額不足之發生，係可確實地防止。

變形例1的下單系統S，係在結帳時機快要來臨之前，執行自動加值處理。下單系統S，係在自動加值處理剛被執行後，執行結帳處理。藉此，可更確實地防止餘額不足所致之下單取消。例如，使用者因為購物等之其他目的而利用電子貨幣的情況下，有時候就算餘額會用完也不怎麼在乎。例如，也有的使用者會對電子貨幣之餘額總是維持高額這件事情抱持抗拒。針對如此的使用者，藉由只有在結帳時機快要來臨之前才會執行自動加值處理，在其他時機上就不會執行自動加值處理，因此可提高使用者的便利性。

[5-2.變形例2] 例如，在實施形態中係說明，即使使用者指定了複數個定期定額設定，在複數個定期定額設定間結帳時機仍為共通的情況，但複數個定期定額設定之各者中的結帳時機亦可彼此互異。若為圖4的例子，則在實施形態中係說明，「基金A」、「基金B」、及「基金C」的結帳時機是每月15日的情況，但「基金A」、「基金B」、及「基金C」之各者的結帳時機亦可彼此互異。

圖11係為複數個定期定額設定之各者中的結帳時機為彼此互異的情況之一例的圖示。在圖11的例子中，假設在定扣指定日，結帳時機會到來。例如，若在定扣指定日的上午10時執行下單處理，則結帳時機係在上午10時快要來臨之前被執行。快要來臨之前之意思，係如同變形例1中所說明。在變形例2中，假設結帳時機係為下單處理的10分鐘前也就是上午9時50分。

例如，T+1月中的「基金A」的投信定期定額的結帳時機，係為「基金A」的定扣指定日也就是「3日」中的上午9時50分。T+1月中的「基金B」的投信定期定額的結帳時機，係為「基金B」的定扣指定日也就是「12日」中的上午9時50分。T+1月中的「基金C」的投信定期定額的結帳時機，係為「基金C」的定扣指定日也就是「25日」中的上午9時50分。從結帳服務往投資服務的入金處理，係亦可在結帳處理快要來臨之前被執行，亦可在每日被決定的時間被執行。

變形例2的投資資料庫DB2中所被儲存之定期定額設定中，表示了結帳時機。電子貨幣資料庫DB1中所被儲存之結帳設定中，係表示了定期定額設定中的結帳時機。在變形例2中，雖然說明是以與定扣指定日同日的方式，來自動決定結帳時機的情況，但亦可由使用者來指定結帳時機。此情況下，使用者，係以與定扣指定日同日、或較定扣指定日之前的日子的方式，來指定結帳時機。使用者，係亦可不只指定結帳時機的日期，還可指定時刻。定期定額設定及結帳設定中，係亦可不只表示結帳時機的日期，還可表示結帳時機的時刻。

在變形例2中，如變形例1般地，假設在結帳時機快要來臨之前，自動加值時機會到來。又，假設按照每一結帳時機，而指定了自動加值設定。因此，在電子貨幣資料庫DB1，係按照每一結帳時機，而被儲存有自動加值設定。結帳時機的數量、與自動加值時機的數量係為相同，因此按照每一自動加值時機，而指定了自動加值設定，在電子貨幣資料庫DB1中，係按照每一自動加值時機，而被儲存有自動加值設定。對應於某個定期定額設定的自動加值設定，係為該定期定額設定中的定扣額所相應之設定。

若為圖11的例子，則每月的結帳時機及自動加值時機，係為「3日」、「12日」、及「25日」的3次，因此會指定3個自動加值設定並儲存在電子貨幣資料庫DB1中。例如，「3日」的自動加值設定，係會是「基金A」的定扣額「10,000圓」所相應之內容的方式，而指定了「若餘額未滿10,000圓，則將餘額變成11,000圓」此一內容。

例如，「12日」的自動加值設定，係會是「基金B」的定扣額「15,000圓」所相應之內容的方式，而指定了「若餘額未滿15,000圓，則將餘額變成16,000圓」此一內容。「25日」的自動加值設定，係會是「基金C」的定扣額「25,000圓」所相應之內容的方式，而指定了「若餘額未滿25,000圓，則將餘額變成26,000圓」此一內容。

變形例2的自動加值處理執行部109，係在使用者指定了關於投信定期定額的複數個定期定額設定，且該當複數個定期定額設定之各者中的結帳時機是彼此互異的情況下，則基於每一結帳時機的自動加值設定，而執行自動加值處理。自動加值處理執行部109，係在電子貨幣資料庫DB1中所被儲存的複數個自動加值之中，基於最近的結帳時機所相應之自動加值設定，而執行自動加值處理。自動加值處理的內容本身，係如同實施形態中所說明。

若為圖11的例子，則自動加值處理執行部109，係在結帳時機及自動加值時機也就是「3日」已經到來的情況，基於「3日」的自動加值設定，而執行自動加值處理。自動加值處理執行部109，係在結帳時機及自動加值時機也就是「12日」已經到來的情況，基於「12日」的自動加值設定，而執行自動加值處理。自動加值處理執行部109，係在結帳時機及自動加值時機也就是「25日」已經到來的情況，基於「25日」的自動加值設定，而執行自動加值處理。

此外，即使在結帳時機快要來臨之前以外之其他時機上，亦可執行自動加值處理。若為圖4的例子，則每月的「1日」~「3日」，係亦可基於「3日」的自動加值設定，而執行自動加值處理。每月的「4日」~「12日」，係亦可基於「12日」的自動加值設定，而執行自動加值處理。每月的「13日」~「25日」，係亦可基於「25日」的自動加值設定，而執行自動加值處理。

變形例2的下單系統S，係在使用者指定了複數個定期定額設定，且該當複數個定期定額設定之各者中的結帳時機是彼此互異的情況下，則基於每一結帳時機的自動加值設定，而執行自動加值處理。藉此，會執行相應於結帳時機的彈性的自動加值處理，可提高使用者的便利性。例如，對於不想變成超出需求之餘額的使用者而言，直到結帳時機以前都可維持必要的餘額，因此可提高使用者的便利性。

[5-3.變形例3] 例如，如變形例2般地，設成每一結帳時機之自動加值設定的情況下，則自動加值設定畫面顯示部105，係亦可令用來受理每一結帳時機之自動加值設定之指定的自動加值設定畫面G7被顯示。自動加值處理執行部109，係基於自動加值設定畫面G7中所被指定的每一結帳時機的自動加值設定，而執行自動加值處理。自動加值處理的內容本身，係如同實施形態中所說明。

例如，假設使用者已經完成「基金A」及「基金B」的定期定額設定，而要新指定「基金C」的定期定額設定。變形例3的自動加值設定畫面G7，係為用來受理結帳時機及自動加值時機也就是「25日」中所被執行的自動加值處理之自動加值設定之指定的畫面。其他結帳時機及其他自動加值時機也就是「3日」及「12日」的自動加值設定也是同樣地，亦可令其他結帳時機及其他自動加值時機之自動加值設定畫面G7被顯示。

變形例3的下單系統S，係令用來受理每一結帳時機之自動加值設定之指定的自動加值設定畫面G7被顯示。下單系統S，係基於自動加值設定畫面G7中所被指定之每一結帳時機之自動加值設定，而執行自動加值處理。藉此，可讓使用者指定相應於結帳時機的彈性的自動加值設定，因此可提高使用者的便利性。

[5-4.變形例4] 例如，如實施形態中所說明，自動加值處理執行部109，係在使用者指定了關於投信定期定額的複數個定期定額設定，且該當複數個定期定額設定之各者中的結帳時機是彼此相同的情況下，則基於該當複數個定期定額設定之各者中的定扣額之合計額所相應之自動加值設定，而執行自動加值處理。若為實施形態中所說明的圖4的例子，則有「基金A」的定期定額設定、「基金B」的定期定額設定、及「基金C」的定期定額設定這3個定期定額設定存在。這3個定期定額設定之各者中的結帳時機，係為每月「15日」而為相同。此情況下，自動加值設定係被指定成，使得這些3個定期定額設定之各者中的定扣額之合計額會變成「50,000圓」。這點，係如同實施形態中所說明。

如變形例1~3般地，即使結帳時機未被固定，在某個定期定額設定中的結帳時機、與其他定期定額設定中的結帳時機，是彼此相同的情況下，則自動加值處理執行部109，係基於這些定期定額設定之各者中的定扣額之合計額所相應之自動加值設定，而執行自動加值處理。例如，於圖11的例子中，假設「基金C」的結帳時機，是與「基金B」相同的「12日」。此情況下，「12日」的自動加值設定係會變成，相應於「基金B」的定扣額「15,000圓」、與「基金C」的定扣額「25,000圓」之合計額「40,000圓」的「若餘額未滿40,000圓，則將餘額變成41,000圓」此一內容。自動加值處理的內容本身，係如同實施形態中所說明。

變形例4的下單系統S，係在使用者指定了複數個定期定額設定，且該當複數個定期定額設定之各者中的結帳時機是彼此相同的情況下，則基於該當複數個定期定額設定之各者中的定扣額之合計額所相應之自動加值設定，而執行自動加值處理。藉此，即使設計成定期定額設定所相應之結帳時機而提高了使用者的便利性，仍可更確實地防止餘額不足所致之下單取消。

[5-5.變形例5] 例如，如實施形態中所說明，自動加值設定，係亦可表示關於電子貨幣之餘額的閾值(在實施形態中係為加值閾值)。此情況下，自動加值處理執行部109，係亦可在結帳時機快要來臨之前以外之期間中，即使電子貨幣之餘額是未滿閾值或閾值以下，仍不執行自動加值處理，在結帳時機快要來臨之前，電子貨幣之餘額是未滿閾值或閾值以下的情況下，則執行自動加值處理。

在變形例5中，如變形例2般地，假設在結帳時機快要來臨之前，自動加值時機會到來。甚至，假設在結帳時機快要來臨之前以外之其他時機上，自動加值處理係不會被執行。亦即，假設變形例1中所說明的第1自動加值時機係為不存在，而只有第2自動加值時機存在。因此，若為圖11的例子，則每月的自動加值時機，係為「3日」、「12日」、及「25日」這3次。

若為圖11的例子，則自動加值處理執行部109，係在結帳時機及自動加值時機也就是「3日」已經到來的情況，基於「3日」的自動加值設定，而執行自動加值處理。自動加值處理執行部109，係在結帳時機及自動加值時機也就是「12日」已經到來的情況，基於「12日」的自動加值設定，而執行自動加值處理。自動加值處理執行部109，係在結帳時機及自動加值時機也就是「25日」已經到來的情況，基於「25日」的自動加值設定，而執行自動加值處理。在結帳時機快要來臨之前以外之其他時機「1日」、「2日」、「4日」~「11日」、「13日」~「24日」、及「26日以後」，自動加值處理係不被執行。

此外，使用者，係也想定會因為購物等之其他目的而利用電子貨幣，而亦可指定定期定額設定所相應之自動加值設定以外之其他自動加值設定。若為圖11的例子，則「3日」、「12日」、及「25日」以外之其他日子的自動加值設定亦可被指定。該自動加值設定，係為了在投信定期定額以外之目的上利用電子貨幣所需。例如，在使用者平常只會在小額的結帳來利用電子貨幣的情況下，則亦可在其他日子，指定「若餘額未滿1000圓，則將餘額變成1100圓」此一自動加值設定。

變形例5的下單系統S，係在結帳時機快要來臨之前以外之期間中，即使電子貨幣之餘額是未滿閾值或閾值以下，仍不執行自動加值處理，在結帳時機快要來臨之前，電子貨幣之餘額是未滿閾值或閾值以下的情況下，則執行自動加值處理。藉此，會執行相應於結帳時機的彈性的自動加值處理，可提高使用者的便利性。例如，對於不想變成超出需求之餘額的使用者而言，可以只有在結帳時機快要來臨之前才維持必要的餘額，因此可提高使用者的便利性。

[5-6.變形例6] 例如，使用者指定了定期定額設定的情況下，自動加值設定亦可被自動地更新。在變形例6中雖然舉出，使用者變更了已指定之定期定額設定的情況下，自動加值設定會被自動地更新的情況為例，但在使用者新指定定期定額設定的情況下，自動加值設定亦可被自動地更新。亦即，在使用者對新的投信定期定額進行下單的情況下，自動加值設定亦可被自動地更新。

圖12係為使用者變更定期定額設定的流程之一例的圖示。例如，一旦使用者令證券應用程式啟動而進行用來變更定期定額設定所需之變更操作，則用來受理變更後的定期定額設定之指定所需之定期定額設定指定畫面G9，係被顯示於顯示部35。變更操作係可為，可在任意之畫面中予以受理的操作。例如，亦可從頂層畫面G2或投資信託指定畫面G3，進行變更操作。使用者，係從輸入表單F90~F92，將結帳方法、定扣額、及定扣指定日之至少1者予以變更。此處說明，使用者將定扣額予以變更的情況。

例如，假設使用者係將「基金A」的定扣額從「10,000圓」變更成「20,000圓」。在變形例6中，假設使用者係沒有下單其他基金，在電子貨幣中並沒有超過可利用之上限額。一旦使用者選擇了按鈕B93，則自動加值設定更新畫面G10係被顯示於顯示部35。假設證券伺服器20，係在自動加值設定更新畫面G10被顯示前，從電子貨幣伺服器10取得現狀的自動加值設定。自動加值設定更新畫面G10，係作為證券應用程式之畫面而被顯示。因此，在自動加值設定更新畫面G10被顯示前，結帳應用程式係不會啟動，證券應用程式是維持在前景執行之狀態而更新自動加值設定。

在圖12的例子中，更新後的自動加值設定是被自動地決定，但使用者係亦可對自動加值設定更新畫面G10，指定更新後的自動加值設定。一旦使用者選擇了按鈕B100，而被要求了定期定額設定之變更內容之確認或個人識別碼之輸入後，設定變更完成畫面G11係被顯示於顯示部35。此情況下，定期定額設定及自動加值設定之雙方係被變更。假設證券伺服器20，係將更新後的自動加值設定之內容、或使用者已選擇了按鈕B100之意旨的通知，發送至電子貨幣伺服器10。電子貨幣伺服器10，係基於從證券伺服器20所接收到的資訊，來更新自動加值設定即可。一旦使用者選擇了按鈕B101，則只有定期定額設定被變更，自動加值設定係不被變更。此情況下，使用者，係可從結帳應用程式以手動來變更自動加值設定。

變形例6的下單系統S，係含有：自動加值設定更新部113、詢問部202、定期定額設定指定畫面顯示部203、及自動加值設定更新畫面顯示部204。定期定額設定指定畫面顯示部203，作為投資服務時的畫面，係令用來受理定期定額設定之指定的定期定額設定指定畫面G9被顯示。圖12的定期定額設定指定畫面G9，係為用來受理定期定額設定之變更所需之畫面，但亦可為用來受理新的定期定額設定之指定的畫面。假設定期定額設定指定畫面G9的顯示資料，係被記憶在資料記憶部200及資料記憶部300之至少一方中。

所謂投資服務時的畫面，係為投資服務所提供的畫面。例如，證券應用程式上的畫面，係相當於投資服務時的畫面。在利用瀏覽器的情況下，則證券服務之網域的畫面，係相當於投資服務時的畫面。換成別的說法，藉由使用者終端30與證券伺服器20進行通訊而被顯示的畫面，係相當於投資服務時的畫面。在下單系統S中，係有投資服務時的畫面、與結帳服務時的畫面存在。

所謂結帳服務時的畫面，係為結帳服務所提供的畫面。例如，結帳應用程式上的畫面，係相當於結帳服務時的畫面。在利用瀏覽器的情況下，則結帳服務之網域的畫面，係相當於結帳服務時的畫面。換成別的說法，藉由使用者終端30與電子貨幣伺服器10進行通訊而被顯示的畫面，係相當於結帳服務時的畫面。

自動加值設定更新畫面顯示部204，作為投資服務時的畫面，係令用來更新自動加值設定所需之自動加值設定更新畫面G10被顯示。假設自動加值設定更新畫面G10的顯示資料，係被記憶在資料記憶部200及資料記憶部300之至少一方中。

詢問部202，係在使用者指定了定期定額設定的情況下，向使用者詢問是否要更新自動加值設定。若為圖12的例子，則詢問部202，係藉由令按鈕B100、B101被顯示，以進行對使用者之詢問。詢問，係只要是對使用者要求某種操作即可。例如，詢問部202，係亦可利用核取方塊、滑桿、或選項按鈕這類其他表單來進行詢問，亦可利用推播通知或互動視窗這類其他媒體來進行詢問。

自動加值設定更新部113，係基於使用者對於詢問部202所致之詢問的回答，而將自動加值設定予以更新。例如，自動加值設定更新部113，係在使用者進行了不要更新自動加值設定之意旨的回答的情況下，則不更新自動加值設定，在使用者進行了要更新自動加值設定之意旨的回答的情況下，則將自動加值設定予以更新。

在變形例6中，由於是藉由電子貨幣伺服器10來實現自動加值設定更新部113，因此自動加值設定更新部113，係從證券伺服器20，接收到要更新自動加值設定之意旨的通知的情況下，則基於該當通知，而將自動加值設定予以更新。在藉由證券伺服器20來實現自動加值設定更新部113的情況下，則自動加值設定更新部113，係藉由發送該通知，以更新自動加值設定。假設通知中係包含有，更新後的自動加值設定或使用者ID這類更新上所必須的資訊。

自動加值設定更新部113，係在使用者指定了關於投信定期定額的定期定額設定的情況下，基於該當已被指定之定期定額設定，而將自動加值設定予以更新。如變形例6般地，在使用者要變更定期定額設定的情況下，則自動加值設定更新部113，係將自動加值設定予以更新，以使其變成變更後的定期定額設定所相應之設定內容。例如，自動加值設定更新部113，係將自動加值設定予以更新，以使其變成變更後的定扣額所相應之加值後餘額。該加值後餘額，係為變更後的定扣額以上之金額。在有複數個定期定額設定存在的情況下，則該加值後餘額，係為變更後的定扣額之合計額以上之金額。

在變形例6中，自動加值設定更新部113，係基於作為投資服務時的畫面而被顯示的自動加值設定更新畫面G10中的使用者之操作，而將自動加值設定予以更新。自動加值設定更新部113，係亦可不對使用者進行詢問，就變更自動加值設定。自動加值處理執行部109，係在自動加值設定已被更新的情況下，基於更新後的自動加值設定，而執行自動加值處理。自動加值處理的內容本身，係如同實施形態中所說明。

變形例6的下單系統S，係在使用者指定了定期定額設定的情況下，基於該當已被指定之定期定額設定，而將自動加值設定予以更新。下單系統S，係在自動加值設定已被更新的情況下，基於更新後的自動加值設定，而執行自動加值處理。藉此，使用者可省去手動進行自動加值設定的麻煩，因此可提高使用者的便利性。例如，新的投信定期定額之下單時，若自動加值設定也是以手動來做指定，則被認為使用者會感到厭煩，而不去完成投信定期定額的下單，但藉由省去自動加值設定的麻煩，就可防止如此的機會損失。

下單系統S，係在使用者指定了定期定額設定的情況下，向使用者詢問是否要更新自動加值設定。下單系統S，係基於使用者對於詢問部202所致之詢問的回答，而將自動加值設定予以更新。藉此，可先確認使用者的意思，然後才更新自動加值設定，因此可提高使用者的便利性。例如，針對不需要自動加值設定之自動更新的使用者，係可設成不去更新自動加值設定。

下單系統S，作為投資服務時的畫面，係令定期定額設定指定畫面G9及自動加值設定更新畫面G10被顯示。下單系統S，係基於作為投資服務時的畫面而被顯示的自動加值設定更新畫面G10中的使用者之操作，而將自動加值設定予以更新。藉此，在投資服務側的畫面中，從定期定額設定之指定到自動加值設定之更新為止都可完成，因此可提高使用者的便利性。例如，不會發生在證券應用程式之啟動中又要啟動結帳應用程式而切換畫面等等，或是重新導向至結帳服務之網站等等，因此可滑順地完成自動加值設定之更新。

[5-7.變形例7] 例如，於變形例6中，隨著使用者所指定之定期定額設定，而也會有不需要更新現狀的自動加值設定的時候。在圖4的例子中，使用者將「基金A」的定扣額從「10,000圓」變更成「5,000圓」的情況下，則即使不變更現狀的自動加值設定之加值後餘額，不會變成餘額不足的可能性仍為高。如此，亦可判定自動加值設定之更新的必要性，並將判定結果通知給使用者。

變形例7的下單系統S，係含有必要性判定部205。必要性判定部205，係基於使用者所指定之定期定額設定，而判定更新自動加值設定之必要性。這裡所謂的必要性，係為自動加值設定之更新之要否。例如，必要性判定部205係判定，使用者所指定之定期定額設定中的定扣額，是否為現狀的自動加值設定中的加值後餘額以上。必要性判定部205，係若現狀的加值後餘額是定扣額以上，則判定為沒有更新自動加值設定之必要，若現狀的加值後餘額是未滿定扣額，則判定為有更新自動加值設定之必要。

此外，在使用者指定了複數個定期定額設定的情況下，則必要性判定部205，係比較複數個定期定額設定之各者中的定扣額之合計額、與加值後餘額即可。如變形例1-4般地，在複數個定期定額設定之各者的結帳時機可能彼此互異的情況下，則必要性判定部205，係只要每到結帳時機，就將該當結帳時機之結帳處理上所必須之金額、與加值後餘額，進行比較即可。

自動加值設定更新部113，係基於必要性判定部205的判定結果，而將自動加值設定予以更新。自動加值設定更新部113，係在藉由必要性判定部205而判定為沒有更新自動加值設定之必要的情況下，則不更新自動加值設定，在藉由必要性判定部205而判定為有更新自動加值設定之必要的情況下，則將自動加值設定予以更新。

變形例7的下單系統S，係基於使用者所指定之定期定額設定，而判定更新自動加值設定之必要性。下單系統S，係基於該判定結果，而將自動加值設定予以更新。藉此，可防止在沒有更新自動加值設定之必要時，自動加值設定被自動地更新，可提高使用者的便利性。

[5-8.變形例8] 例如，投信定期定額，係亦可有通常時的定扣額、與獎金時的定扣額存在。所謂通常時，係為獎金時以外的時候。獎金時，係亦可被預先制定，亦可由使用者來自由地指定。在變形例8中，係將獎金時設成6月和12月。獎金時的定扣額，係較通常時的定扣額為多。假設獎金時的定扣額，係作為定期定額設定而被儲存在投資資料庫DB2中。

變形例8的結帳處理執行部111，係亦可基於通常時的定扣額，而執行通常時的結帳處理，並基於獎金時的定扣額，而執行獎金時的結帳處理。雖然通常時與獎金時之間的定扣額有所不同的這點上是與實施形態不同，但結帳處理本身，係如同實施形態中所說明。

自動加值處理執行部109，係在通常時，基於通常時的定扣額所相應之自動加值設定，而執行自動加值處理，在獎金時，基於獎金時的定扣額所相應之自動加值設定，而執行自動加值處理。雖然通常時與獎金時之間的自動加值設定有所不同的這點上是與實施形態不同，但自動加值處理本身，係如同實施形態中所說明。獎金時的自動加值設定，係以會成為獎金時的定扣額或合計額以上之加值後餘額的方式，而被設定。

變形例8的下單系統S，係基於通常時的定扣額，而執行通常時的結帳處理，並基於獎金時的定扣額，而執行獎金時的結帳處理。下單系統S，係在通常時，基於通常時的定扣額所相應之自動加值設定，而執行自動加值處理，在獎金時，基於獎金時的定扣額所相應之自動加值設定，而執行自動加值處理。藉此，就可進行通常時與獎金時之各者所相應之結帳處理與自動加值處理，因此可提高使用者的便利性。

[5-9.變形例9] 例如，實施形態及變形例1-8中所說明的自動加值功能，係亦可適用於投信定期定額以外之投資商品的下單。在變形例9中，作為投資商品之一例，是舉出股票為例子。投資商品，係亦可為股票及投信定期定額以外之其他商品。其他商品之例子，係如同實施形態中所說明。下單系統S，係含有：自動加值處理執行部109、結帳處理執行部111、及下單處理執行部112。

自動加值處理執行部109，係基於關於使用者所指定之投資商品的投資額所相應之自動加值設定，而執行關於使用者之電子貨幣的自動加值處理。只要將實施形態中所說明的自動加值處理中的定扣額替換成投資額，並將投信定期定額替換成投資商品即可。即便是被整匹下單的投資商品，藉由以會成為該投資商品之投資額以上之加值後餘額的方式來指定自動加值設定，仍可防止下單時的餘額不足。例如，於股票的下單時，以會成為某支股票之投資額以上之加值後餘額的方式，來指定自動加值設定。

結帳處理執行部111，係可基於藉由自動加值處理而被加值的電子貨幣、與投資額，來執行關於投資商品的結帳處理。只要將實施形態中所說明的自動加值處理中的投信定期定額，替換成投資商品即可。在變形例9中，股票的下單也可利用電子貨幣。下單處理執行部112，係在結帳處理已被執行的情況下，執行關於投資商品的下單處理。投資商品的下單處理本身，係和實施形態同樣地，可適用公知的各種處理。

變形例9的下單系統S，係基於關於使用者所下單之投資商品的投資額所相應之自動加值設定，而執行自動加值處理。下單系統S，係可基於藉由自動加值處理而被加值的電子貨幣、與投資額，而執行結帳處理。下單系統S，係執行關於投資商品的下單處理。下單處理與結帳處理之何者先被執行皆可的這點，係如同實施形態中所說明。藉此，使用者就可利用電子貨幣來對投資商品進行下單。可提高藉由自動加值處理來下單投資商品的使用者的便利性這點，也是和實施形態及變形例1-9相同。

[5-10.其他變形例] 例如，亦可將上記說明的變形例加以組合。

例如，電子貨幣，係亦可不具有自動加值功能。即使沒有自動加值功能，若依據實施形態等之處理，則使用者，係仍可利用電子貨幣來對定期定額商品或其他投資商品進行下單。例如，在受理了自動加值設定之指定的情況下，金額資訊亦可不被顯示。例如，亦可不是加值後餘額，而是加值額是被自動加值設定所表示。

例如，下單系統S，係亦可只含有電子貨幣伺服器10。此情況下，證券伺服器20及使用者終端30，係亦可存在於下單系統S之外部。例如，下單系統S，係亦可只含有證券伺服器20。此情況下，電子貨幣伺服器10及使用者終端30，係亦可存在於下單系統S之外部。例如，作為是在電子貨幣伺服器10中所被實現而說明的機能，係亦可在證券伺服器20或其他伺服器電腦中被實現。作為是在證券伺服器20中所被實現而說明的機能，係亦可在電子貨幣伺服器10或其他伺服器電腦中被實現。例如，作為是在電子貨幣伺服器10或證券伺服器20中所被實現而說明的機能，係亦可被複數台電腦所分擔。各機能，係只要在至少1台電腦中被實現即可。

S:下單系統 N:網路 10:電子貨幣伺服器 11,21,31:控制部 12,22,32:記憶部 13,23,33:通訊部 20:證券伺服器 30:使用者終端 34:操作部 35:顯示部 G1:登入畫面 G2:頂層畫面 G3:投資信託指定畫面 G4:結帳方法指定畫面 G5:定扣額等指定畫面 G6:登入畫面 G7:自動加值設定畫面 G8:下單完成畫面 G9:定期定額設定指定畫面 100:資料記憶部 101:一致判定部 102:自動加值設定許可部 103:合計額計算部 104:可能性判定部 105:自動加值設定畫面顯示部 106:金額資訊顯示部 107:可能性顯示部 108:自動加值時機判定部 109:自動加值處理執行部 110:結帳時機判定部 111:結帳處理執行部 112:下單處理執行部 113:自動加值設定更新部 200:資料記憶部 201:下單處理執行部 202:詢問部 203:定期定額設定指定畫面顯示部 204:自動加值設定更新畫面顯示部 205:必要性判定部 300:資料記憶部 301:顯示控制部 302:操作受理部 B12,B20,B21,B30,B40,B43,B52,B62,B72,B92:按鈕 DB1:電子貨幣資料庫 DB2:投資資料庫 F10,F50,F60,F70,F90:輸入表單 G10:自動加值設定更新畫面 G11:設定變更完成畫面 M73:訊息 M74:訊息 B100,B101:按鈕

[圖1]下單系統的全體構成之一例的圖示。 [圖2]使用者終端上所被顯示的畫面之一例的圖示。 [圖3]使用者終端上所被顯示的畫面之一例的圖示。 [圖4]投信定期定額之下單完成後的流程之一例的圖示。 [圖5]下單系統中所被實現的機能之一例的機能區塊圖。 [圖6]電子貨幣資料庫之一例的圖示。 [圖7]可能性顯示部的處理之一例的圖示。 [圖8]投資資料庫之一例的圖示。 [圖9]下單系統中所被執行的處理之一例的圖示。 [圖10]變形例中的機能區塊之一例的圖示。 [圖11]複數個定期定額設定之各者中的結帳時機為彼此互異的情況之一例的圖示。 [圖12]使用者變更定期定額設定的流程之一例的圖示。

10:電子貨幣伺服器

20:證券伺服器

30:使用者終端

100:資料記憶部

101:一致判定部

102:自動加值設定許可部

103:合計額計算部

104:可能性判定部

105:自動加值設定畫面顯示部

106:金額資訊顯示部

107:可能性顯示部

108:自動加值時機判定部

109:自動加值處理執行部

110:結帳時機判定部

111:結帳處理執行部

112:下單處理執行部

200:資料記憶部

201:下單處理執行部

300:資料記憶部

301:顯示控制部

302:操作受理部

DB1:電子貨幣資料庫

DB2:投資資料庫

Claims (23)

1. 一種下單系統，係含有： 結帳時機判定部，係判定關於使用者所下單之定期定額商品的結帳時機是否已經到來；和 結帳處理執行部，係在判定為前記結帳時機已經到來的情況下，基於前記使用者所保有之電子貨幣、與前記使用者所指定之定扣額，而執行關於前記定期定額商品的結帳處理；和 下單處理執行部，係執行關於前記定期定額商品的下單處理。
2. 如請求項1所記載之下單系統，其中， 前記下單系統係還含有：自動加值處理執行部，係基於前記定扣額所相應之自動加值設定，而執行關於前記電子貨幣的自動加值處理； 前記結帳處理執行部，係可基於加值後的前記電子貨幣，而執行前記結帳處理。
3. 如請求項2所記載之下單系統，其中， 前記下單系統係還含有：金額資訊顯示部，係令用來受理前記自動加值設定之指定的自動加值設定畫面，顯示出關於前記定扣額的金額資訊； 前記自動加值處理執行部，係基於前記自動加值設定畫面中所被指定的前記自動加值設定，而執行前記自動加值處理。
4. 如請求項2或3所記載之下單系統，其中， 前記自動加值設定，係表示前記自動加值處理被執行後之餘額； 前記自動加值處理執行部，係在前記自動加值設定是指要變成前記定扣額所相應之加值後餘額的這類情況下，則以會成為前記自動加值設定所表示之加值後餘額的方式，來執行前記自動加值處理。
5. 如請求項3所記載之下單系統，其中， 前記下單系統係還含有：合計額計算部，係在前記使用者已指定了關於前記定期定額商品的複數個定期定額設定的情況下，計算關於該當複數個定期定額設定之各者中的前記定扣額之合計額； 前記金額資訊顯示部，係令前記自動加值設定畫面顯示出前記合計額，以作為前記金額資訊。
6. 如請求項2或3所記載之下單系統，其中， 前記下單系統係還含有： 可能性判定部，係基於現狀的前記自動加值設定，來判定前記下單處理會完成之可能性；和 可能性顯示部，係令用來受理前記自動加值設定之指定的自動加值設定畫面，顯示出前記可能性判定部的判定結果； 前記自動加值處理執行部，係基於前記自動加值設定畫面中所被指定的前記自動加值設定，而執行前記自動加值處理。
7. 如請求項2或3所記載之下單系統，其中， 前記下單系統係還含有：自動加值時機判定部，係判定會定期性到來之自動加值時機是否已經到來； 前記自動加值處理執行部，係在判定為前記自動加值時機已經到來的情況下，執行前記自動加值處理。
8. 如請求項2或3所記載之下單系統，其中， 前記自動加值處理執行部，係在前記結帳時機快要來臨之前，執行前記自動加值處理； 前記結帳處理執行部，係在前記自動加值處理剛被執行後，執行前記結帳處理。
9. 如請求項2或3所記載之下單系統，其中， 前記自動加值處理執行部，係在前記使用者指定了關於前記定期定額商品的複數個定期定額設定，且該當複數個定期定額設定之各者中的前記結帳時機是彼此互異的情況下，則基於每一前記結帳時機的前記自動加值設定，而執行前記自動加值處理。
10. 如請求項9所記載之下單系統，其中， 前記下單系統係還含有：自動加值設定畫面顯示部，係令用來受理每一前記結帳時機的前記自動加值設定之指定的自動加值設定畫面被顯示； 前記自動加值處理執行部，係基於前記自動加值設定畫面中所被指定的每一前記結帳時機的前記自動加值設定，而執行前記自動加值處理。
11. 如請求項2或3所記載之下單系統，其中， 前記自動加值處理執行部，係在前記使用者指定了關於前記定期定額商品的複數個定期定額設定，且該當複數個定期定額設定之各者中的前記結帳時機是彼此相同的情況下，則基於該當複數個定期定額設定之各者中的前記定扣額之合計額所相應之前記自動加值設定，而執行前記自動加值處理。
12. 如請求項2或3所記載之下單系統，其中， 前記自動加值設定，係表示關於前記電子貨幣之餘額的閾值； 前記自動加值處理執行部，係在前記結帳時機快要來臨之前以外之期間中，即使前記電子貨幣之餘額是未滿前記閾值或為前記閾值以下，仍不執行前記自動加值處理，在前記結帳時機快要來臨之前，前記電子貨幣之餘額是未滿前記閾值或為前記閾值以下的情況下，則執行前記自動加值處理。
13. 如請求項2或3所記載之下單系統，其中， 前記下單系統係還含有：自動加值設定更新部，係在前記使用者指定了關於前記定期定額商品的定期定額設定的情況下，基於該當已被指定之定期定額設定，而將前記自動加值設定予以更新； 前記自動加值處理執行部，係在前記自動加值設定已被更新的情況下，基於更新後的前記自動加值設定，而執行前記自動加值處理。
14. 如請求項13所記載之下單系統，其中， 前記下單系統係還含有：詢問部，係在前記使用者指定了前記定期定額設定的情況下，向前記使用者詢問是否要更新前記自動加值設定； 前記自動加值設定更新部，係基於前記使用者對於前記詢問部所致之詢問的回答，而將前記自動加值設定予以更新。
15. 如請求項13所記載之下單系統，其中， 前記定期定額商品，係藉由投資服務而被提供； 前記電子貨幣，係藉由異於前記投資服務的結帳服務而被提供； 前記下單系統係還含有： 定期定額設定指定畫面顯示部，係令用來受理前記定期定額設定之指定的定期定額設定指定畫面被顯示，以作為前記投資服務時的畫面；和 自動加值設定更新畫面顯示部，係令用來更新前記自動加值設定所需之自動加值設定更新畫面被顯示，以作為前記投資服務時的畫面； 前記自動加值設定更新部，係基於作為前記投資服務時的畫面而被顯示的前記自動加值設定更新畫面中的前記使用者之操作，而將前記自動加值設定予以更新。
16. 如請求項13所記載之下單系統，其中， 前記下單系統係還含有：必要性判定部，係基於前記使用者所指定之前記定期定額設定，來判定前記自動加值設定的更新之必要性； 前記自動加值設定更新部，係基於前記必要性判定部的判定結果，而將前記自動加值設定予以更新。
17. 如請求項2或3所記載之下單系統，其中， 前記定期定額商品，係藉由投資服務而被提供； 前記電子貨幣，係藉由異於前記投資服務的結帳服務而被提供； 前記下單系統係還含有： 一致判定部，係判定前記投資服務中的關於前記使用者的使用者資訊、與前記結帳服務中的關於前記使用者的使用者資訊，是否一致；和 自動加值設定許可部，係基於前記一致判定部的判定結果，而許可前記使用者所做的前記自動加值設定。
18. 如請求項2或3所記載之下單系統，其中， 前記結帳處理執行部，係基於通常時的前記定扣額，而執行通常時的前記結帳處理，並基於獎金時的前記定扣額，而執行獎金時的前記結帳處理； 前記自動加值處理執行部，係在前記通常時，基於前記通常時的前記定扣額所相應之前記自動加值設定，而執行前記自動加值處理，在前記獎金時，基於前記獎金時的前記定扣額所相應之前記自動加值設定，而執行前記自動加值處理。
19. 如請求項1~3之任一項所記載之下單系統，其中， 前記電子貨幣係含有：被限制出金的第1餘額、和可出金的第2餘額； 前記結帳處理執行部，係基於前記第1餘額及前記第2餘額之雙方，而執行前記結帳處理。
20. 如請求項1~3之任一項所記載之下單系統，其中， 前記定期定額商品，係也可利用前記使用者之信用卡來進行結帳處理； 前記結帳處理執行部，係在有別於前記信用卡所被設定之前記定期定額商品之上限額的另一上限額之範圍內，執行前記結帳處理。
21. 一種下單系統，係含有： 自動加值處理執行部，係基於關於使用者所下單之投資商品的投資額所相應之自動加值設定，而執行關於前記使用者之電子貨幣的自動加值處理；和 結帳處理執行部，係可基於藉由前記自動加值處理而被加值的前記電子貨幣、與前記投資額，而執行關於前記投資商品的結帳處理；和 下單處理執行部，係執行關於前記投資商品的下單處理。
22. 一種下單方法，係含有： 結帳時機判定步驟，係判定關於使用者所下單之定期定額商品的結帳時機是否已經到來；和 結帳處理執行步驟，係在判定為前記結帳時機已經到來的情況下，基於前記使用者所保有之電子貨幣、與前記使用者所指定之定扣額，而執行關於前記定期定額商品的結帳處理；和 下單處理執行步驟，係執行關於前記定期定額商品的下單處理。
23. 一種程式產品，係用來使電腦發揮機能而成為： 結帳時機判定部，係判定關於使用者所下單之定期定額商品的結帳時機是否已經到來； 結帳處理執行部，係在判定為前記結帳時機已經到來的情況下，基於前記使用者所保有之電子貨幣、與前記使用者所指定之定扣額，而執行關於前記定期定額商品的結帳處理； 下單處理執行部，係執行關於前記定期定額商品的下單處理。

Images