TWI823109B

TWI823109B - 支付系統、支付方法、及程式產品

Info

Publication number: TWI823109B
Application number: TW110123718A
Authority: TW
Inventors: 佐久間智大
Original assignee: 日商樂天銀行股份有限公司
Priority date: 2020-06-30
Filing date: 2021-06-29
Publication date: 2023-11-21
Also published as: TW202209208A; JP7175938B2; JP2022011709A

Abstract

[課題] 提升利用繳費單或繳費用號碼的支付時的使用者之便利性。 [解決手段] 支付系統(1)的取得手段(101)，係在繳費單上所記載之代碼已被使用者終端(30)所讀取的情況下、或繳費用號碼已被輸入至使用者終端(30)的情況下，取得關於代碼或繳費用號碼所對應之支付的支付資訊。特定手段(102)，係在複數個支付方法之中，特定出已被使用者所選擇之支付方法。執行手段(106)，係基於支付資訊，執行以已被使用者所選擇之支付方法來進行支付所需之支付處理。

Description

支付系統、支付方法、及程式產品

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

先前，藉由在便利商店等中讀取繳費單上所記載之代碼或輸入繳費用號碼等等，以進行公共費用等之支付的技術，已為人知。例如，專利文獻1中係記載，一旦以使用者終端讀取繳費單上所記載之代碼而進行本人認證，就執行從使用者之銀行帳戶往支付目標之銀行帳戶的轉帳處理，藉此以執行繳費單上所被記載之支付的方法。 [先前技術文獻] [專利文獻]

[專利文獻1] 日本特開2005-228156號公報

[發明所欲解決之課題]

然而，專利文獻1的技術，係只能利用銀行轉帳此一單一之支付方法，因此無法充分提升使用者的便利性。

本揭露係有鑑於上述課題而研發，其目的在於提供一種，可提升利用繳費單或繳費用號碼的支付時的使用者之便利性的支付系統、支付方法、及程式產品。 [用以解決課題之手段]

為了解決上記課題，本揭露所述之支付系統，係含有：取得手段，係用以在繳費單上所記載之代碼已被使用者終端所讀取的情況下、或繳費用號碼已被輸入至使用者終端的情況下，取得關於前記代碼或前記繳費用號碼所對應之支付的支付資訊；和特定手段，係用以在複數個支付方法之中，特定出已被使用者所選擇之支付方法；和執行手段，係用以基於前記支付資訊，執行以已被前記使用者所選擇之支付方法來進行前記支付所需之支付處理。

[1.支付系統的全體構成]

以下針對本揭露所述之實施形態之例子，基於圖式而詳細地說明。圖1係為實施形態所述之支付系統之一例的圖示。如圖1所示，例如，支付系統1係含有：銀行伺服器10、電子結帳伺服器20、及使用者終端30，這些係可連接至網際網路等之網路N。此外，在圖1中，銀行伺服器10、電子結帳伺服器20、及使用者終端30之每一者雖然僅各圖示1台，但這些亦可為複數台。又，伺服器電腦係亦可只有1台。

銀行伺服器10，係為銀行所管理的伺服器電腦。例如，銀行伺服器10係含有：控制部11、記憶部12、及通訊部13。控制部11係例如，含有至少1個處理器。記憶部12係含有例如，RAM等之主記憶部或硬碟等之輔助記憶部。控制部11，係依照記憶部12中所記憶之程式或資料，來執行處理。通訊部13，係包含有線通訊或無線通訊用的通訊介面。通訊部13，係可透過網路N而與外部機器進行資料收送訊。

電子結帳伺服器20，係為電子結帳服務之提供者所管理的伺服器電腦。電子結帳服務，係為利用了電腦的電子式結帳。電子結帳，係可為任意之種類，係為利用了例如：信用卡、簽帳卡、電子貨幣、點數、或虛擬通貨的結帳。電子結帳伺服器20係含有：控制部21、記憶部22、及通訊部23。控制部21、記憶部22、及通訊部23的硬體構成，係可分別和控制部11、記憶部12、及通訊部13相同。

使用者終端30，係為使用者所操作的電腦。在本實施形態中，使用者係利用：銀行伺服器10所提供的金融服務、和電子結帳伺服器20所提供的電子結帳服務之雙方。例如，使用者終端30係為行動電話(包含智慧型手機)、攜帶型資訊終端(包含平板型終端及可穿戴式終端)、或個人電腦。

使用者終端30係含有：控制部31、記憶部32、通訊部33、操作部34、顯示部35、及攝影部36。控制部31、記憶部32、及通訊部33的硬體構成，係可分別和控制部11、記憶部12、及通訊部13相同。操作部34，係為輸入裝置，例如觸控面板或滑鼠等之指標裝置或鍵盤。顯示部35係為例如，液晶顯示器或有機EL顯示器。攝影部36，係含有至少1個相機。

此外，作為被記憶在記憶部12、22、32中而說明的程式或資料，係亦可被記憶在電腦可讀取之資訊記憶媒體(例如USB記憶體或SD卡)中而被供給至各電腦，亦可透過網路而被供給至各電腦。又，上記所說明的各電腦之硬體構成，係不限於上記之例子，亦可具備例如：讀取資訊記憶媒體的讀取部(例如SD卡插槽)、或與外部機器直接通訊所需之輸出入部(例如USB端子)。

[2.支付系統的概要] 在本實施形態中，使用者係已經完成了銀行中的帳戶開設，與電子結帳服務的利用登錄。又，使用者終端30中係已被安裝有銀行應用程式與電子結帳應用程式。銀行應用程式，係為為了利用銀行所提供的金融服務所需之應用程式，例如可利用：銀行轉帳、銀行轉帳以外之匯款、餘額核對、入出金明細、或貸款申請。電子結帳應用程式，係為為了利用電子結帳服務所需之應用程式，可執行利用了例如：信用卡、簽帳卡、電子貨幣、點數、或虛擬通貨的結帳。

在本實施形態中，是舉出使用者利用繳費單來進行支付的場面為例，來說明支付系統1之處理。繳費單，係為為了在便利商店等之店舖中進行支付所需之用紙。繳費單，係也會被稱作請款單或納付單。繳費單，係可為任意之形式，係被印刷有例如：支付目標的名稱、支付目標的銀行帳戶之資訊、支付金額、支付期限、及條碼。繳費單，係可被利用於任意的支付，可在例如：繳稅、公共費用、或以網際網路購入的商品之支付中被利用。支付目標，係為使用者之支付的收取者，係為例如最終收取使用者之支付的自治體或公司。此外，收納代理業者亦可相當於支付目標。

例如，繳費單係藉由郵寄而被送往使用者。繳費單，係亦可作為電子式的檔案而被送往使用者，而被使用者所列印出來。除此以外，例如，使用者藉由在便利商店之終端等輸入繳費用號碼而被列印的用紙，亦可相當於繳費單。此外，繳費單，係亦可不被印刷於用紙上，而是在畫面上被電子性地顯示。

條碼中係含有支付所必須之資訊，係含有例如：將各個支付做唯一識別的支付ID、將支付目標做唯一識別的支付目標ID、支付金額、及支付期限這類資訊。在本實施形態中，作為繳費單上所記載之代碼之一例雖然是說明條碼，但繳費單上所記載之代碼，係不限於條碼。繳費單上所記載之代碼，係可利用二維碼等之其他任意的代碼。因此，在本實施形態中記載為條碼的地方，係可替換成其他任意的代碼。

使用者，係藉由以使用者終端30來讀取繳費單的條碼，而即使不去便利商店等，也能進行繳費單的支付。在本實施形態中，銀行應用程式與電子結帳應用程式之雙方都支援繳費單的支付，使用者係無論利用哪一應用程式皆可。亦即，使用者係可選擇任意之應用程式而選擇任意之支付方法。

在本實施形態中，作為可讓使用者選擇的支付方法，係舉出銀行轉帳、信用卡、及電子貨幣之3者為例。支付方法，係可為電子式的匯款方法，也可為支付手段。銀行轉帳，係可從銀行應用程式來做選擇。信用卡與電子貨幣，係可從電子結帳應用程式來做選擇。雖然亦可為，支付系統1中所被登錄的所有支付目標都有支援這些全部的支付方法，但在本實施形態中，是按照每一支付目標，而定義了可支援的支付方法。

在本實施形態中，支付目標係屬於下記的(A)-(C)之任一類型。亦即，假設關於銀行轉帳，係所有的支付目標都有支援，關於信用卡與電子貨幣，係只有一部分的支付目標有支援。 (A)信用卡、電子貨幣、及銀行轉帳全部都可支援 (B)不支援信用卡，可支援電子貨幣和銀行轉帳 (C)不支援信用卡和電子貨幣，只支援銀行轉帳

此外，在(A)類型之中，假設係存在有：可充抵點數的信用卡支付、與無法充抵點數的信用卡支付。點數，係可利用任意之種類，例如，亦可為電子結帳服務之提供者所管理的點數，亦可為該提供者的合作對象所管理的點數。所謂點數的充抵，係指將支付金額之部分或全部，以點數來進行支付。在可充抵點數的信用卡支付的情況下，信用卡與點數併用的支付係為可能。以下，針對(A)-(C)之每一類型之支付目標的支付之流程，舉例繳費單的條碼是藉由電子結帳應用程式而被讀取的情況來做說明。

圖2及圖3係為，針對(A)類型之支付目標的支付之流程的圖示。圖2係圖示可充抵點數的信用卡支付，圖3係圖示無法充抵點數的信用卡支付。例如，一旦從電子結帳應用程式之選單選擇出繳費單之支付，則如圖2及圖3所示，攝影部36係會啟動，攝影畫面G1係被顯示於顯示部35。攝影部36，係以所定之畫格速率，連續地進行攝影處理。攝影畫面G1中係被顯示有，藉由攝影部36而被拍攝的影像。

使用者終端30，係基於公知的偵測演算法，而從攝影影像，偵測出條碼。使用者終端30，係一旦偵測出條碼，就將條碼中所含之條碼資訊予以抽出並發送至銀行伺服器10。條碼資訊，係亦可經由電子結帳伺服器20而讓其獲取日誌，但在本實施形態中是設成，從使用者終端30直接被發送至銀行伺服器10。

銀行伺服器10，係基於已接收之條碼資訊而將支付目標予以特定，並判定是否為已被登錄在支付系統1中的支付目標。在判定為不是已被登錄在支付系統1中的支付目標的情況下，則由於無法利用使用者終端30來進行支付，因此表示該意旨的錯誤訊息係被顯示於顯示部35。另一方面，在判定為是已被登錄在支付系統1中的支付目標的情況下，則銀行伺服器10係判定，使用者所選擇的支付方法，是否為該支付目標所支援。

例如，假設使用者係將複數個信用卡登錄至電子結帳應用程式，作為通常使用的信用卡，是已選擇了任一信用卡。銀行伺服器10，係在從電子結帳應用程式讀取到條碼的情況下，則判定為，作為支付方法是被選擇了信用卡。銀行伺服器10，係基於已接收之條碼資訊而將支付目標予以特定，並判定該支付目標是否有支援信用卡。此處，由於是(A)類型之支付目標，因此銀行伺服器10係判定為，支付目標有支援信用卡。

如圖2所示，若是可支援可充抵點數的信用卡支付的支付目標，則可充抵點數的確認畫面G2係被顯示於顯示部35。例如，確認畫面G2中係被顯示有：支付目標(或支付的名稱)、支付金額、使用者所保有之點數的資訊、及使用者所選擇之信用卡的資訊。使用者，係一旦選擇按鈕B20，就可將支付金額之部分或全部，以點數進行支付。在圖2的例子中，雖然也可併用電子貨幣，但即使不可併用電子貨幣也無妨。另一方面，如圖3所示，若是可支援無法充抵點數的信用卡支付的支付目標，則確認畫面G2中，點數的資訊與按鈕B20係不被顯示。

一旦使用者將圖2或圖3的確認畫面G2的滑桿B21予以滑動，則對電子結帳伺服器20，相應於確認畫面G2中所被顯示之內容的結帳要求，係被發送。電子結帳伺服器20，係隨應於結帳要求而執行結帳處理，其結果係被發送至銀行伺服器10。銀行伺服器10，係一旦從電子結帳伺服器20接收結帳完成之通知，就對收納代理公司，通知支付已完成之意旨。其後，在使用者終端30上，表示支付已完成的完成畫面G3，係被顯示。

圖4係為針對(B)類型之支付目標的支付之流程的圖示。如圖4所示，一旦攝影畫面G1被顯示而條碼被偵測，與(A)類型之支付目標同樣的處理就被執行，銀行伺服器10係判定支付目標是否有支援信用卡。此處，由於是(B)類型之支付目標，因此銀行伺服器10係判定為，支付目標不支援信用卡。此情況下，含有支付目標不支援信用卡之意旨之訊息的視窗W22，係被顯示於確認畫面G2。

(B)類型之支付目標，係有支援電子貨幣，因此使用者係只要將支付方法變更成電子貨幣，就可直接從電子結帳應用程式進行支付。因此，視窗W22中係被顯示出，催促電子貨幣之利用之意旨的訊息。一旦使用者選擇了按鈕B23，則用來變更支付方法所需之設定畫面G4係被顯示於顯示部35。此外，一旦使用者選擇了按鈕B24，就可取消繳費單之支付。

例如，在設定畫面G4中，作為支付方法是顯示了選擇中的信用卡之資訊。在圖4的例子中，「信用卡A」係被選擇。使用者雖然也有把「信用卡B」登錄至電子結帳服務，但由於支付目標係不支援信用卡，因此「信用卡B」係變成無法選擇。使用者，係選擇按鈕B40、B41，並將支付方法變更成電子貨幣。

一旦使用者選擇了按鈕B40、B41，則表示支付方法已被變更成電子貨幣的視窗W42，係被顯示。一旦使用者選擇了按鈕B43，則用來以電子貨幣進行支付所需之確認畫面G2，係被顯示。該確認畫面G2，係雖然省略圖示，但和圖2及圖3的確認畫面G2大略相同，例如：支付目標、支付金額、及電子貨幣之餘額，係被顯示。一旦使用者滑動了滑桿B21，則電子貨幣所致之支付就完成而顯示出完成畫面G3。

圖5係為針對(C)類型之支付目標的支付之流程的圖示。如圖5所示，一旦攝影畫面G1被顯示而條碼被偵測，與(A)類型之支付目標同樣的處理就被執行，銀行伺服器10係判定支付目標是否有支援信用卡。此處，由於是(C)類型之支付目標，因此銀行伺服器10係判定為，支付目標不支援信用卡。又，銀行伺服器10係判定為，支付目標也不支援電子貨幣。(C)類型之支付目標，係只要是利用了銀行應用程式的銀行轉帳就可支付，因此催促將支付方法變更成銀行轉帳的視窗W25，係被顯示於確認畫面G2。

例如，一旦使用者選擇了按鈕B26，則銀行應用程式係會啟動而確認畫面G2係被顯示於顯示部35。一旦使用者選擇了按鈕B27，就可取消繳費單之支付。此外，銀行應用程式，係亦可不是隨應於按鈕B26之選擇而自動地啟動，而是由使用者以手動來啟動之。銀行應用程式已啟動的情況下，雖然也是可以令其再次讀取條碼，但在本實施形態中係設計成，將利用電子結帳應用程式而被取得的資訊予以沿用。

如圖5所示，一旦銀行應用程式啟動，則確認畫面G5係被顯示於顯示部35。銀行應用程式的確認畫面G5，係和電子結帳應用程式的確認畫面G2大致相同之內容，係被顯示有例如：支付目標、支付金額、及使用者的銀行帳戶之資訊。一旦使用者滑動了滑桿B50，則銀行轉帳所致之支付就完成而完成畫面G6係被顯示於顯示部35。由於是藉由銀行伺服器10而執行銀行轉帳，因此結帳要求係不是送往電子結帳伺服器20而是被發送至銀行伺服器10。

此外，在圖2-圖5中，雖然說明了是由使用者來啟動電子結帳應用程式進行支付的情況，但使用者亦可啟動銀行應用程式而進行支付。此情況下，關於銀行應用程式也是，與電子結帳應用程式的攝影畫面G1相同的攝影畫面係被顯示，一旦偵測到條碼，則確認畫面G5係被顯示。在本實施形態中，已被登錄在支付系統1中的所有支付目標都可支援銀行轉帳，因此在銀行應用程式被利用的情況下，則相當於圖4的視窗W22或圖5的視窗W25的視窗係不被顯示。如後述的變形例，在有不支援銀行轉帳的支付目標存在的情況下，則亦可將催促信用卡等之其他支付方法之利用之意旨的視窗加以顯示。

如以上所述，本實施形態的支付系統1，係從在電子結帳應用程式與銀行應用程式之各者中可做利用的複數個支付方法之中，藉由讓使用者選擇任意之支付方法，以提升利用繳費單之支付時的使用者的便利性。以下，說明支付系統1之構成的細節。

[3.於支付系統中所被實現的機能] 圖6係於支付系統1中所被實現之機能的機能區塊圖。在本實施形態中係說明，在銀行伺服器10、電子結帳伺服器20、及使用者終端30之每一者中所被實現的機能。

[3-1.於銀行伺服器中所被實現的機能] 如圖6所示，在銀行伺服器10中係有：資料記憶部100、取得部101、特定部102、參照部103、判定部104、顯示控制部105、及執行部106被實現。資料記憶部100係以記憶部12為主而被實現，其他的各機能係以控制部11為主而被實現。

[資料記憶部] 資料記憶部100，係記憶著為了執行本實施形態所說明之處理所必須的資料。此處，作為資料記憶部100所記憶的資料之一例，說明支付目標資料庫DB1、和支付資訊資料庫DB2。

圖7係為支付目標資料庫DB1的資料儲存例的圖示。如圖7所示，支付目標資料庫DB1係為，儲存有關於每個支付目標之資訊的資料庫。例如，支付目標資料庫DB1中係被儲存有：支付目標ID、支付目標名稱、及可支援的支付方法。支付目標名稱，係為支付目標的自治體或公司的名稱。

可支援的支付方法，係為在支付系統1中可支援的複數個支付方法之中的部分或全部之支付方法。在本實施形態中，信用卡、電子貨幣、及銀行轉帳之每一者的支援可否，係被表示。關於可支援信用卡的支付目標，係也會表示點數之充抵可否。點數之充抵可否，係也可說是信用卡與點數之併用可否。一旦對支付系統1登錄新的支付目標，則支付目標資料庫DB1中就會作成新的紀錄，關於該支付目標的資訊係被儲存。可支援的支付方法，係可在事後做變更。

圖8係為支付資訊資料庫DB2的資料儲存例的圖示。如圖8所示，支付資訊資料庫DB2係為，儲存有關於每個支付之支付資訊的資料庫。例如，支付資訊資料庫DB2中係被儲存有：支付ID、支付目標ID、支付金額、支付期限、及支付者名。

支付ID，係將各個支付做唯一識別的資訊，因此即使是相同支付目標，只要支付不同，支付ID就會不同。支付ID，係為將繳費單上所被記載之支付做唯一識別的資訊。在本實施形態中，在發生新的支付而發行繳費單的情況下，支付資訊資料庫DB2中就會作成新的紀錄，該支付的支付資訊就被儲存。

此外，資料記憶部100中所被記憶的資料，係不限於上記例子。資料記憶部100，係亦可記憶在銀行轉帳時所必須之資料。例如，資料記憶部100係亦可記憶：在銀行中所被開設之帳戶的分行號碼、帳戶號碼、名義人、及餘額這類資訊所被儲存的帳戶資料庫。該帳戶中係不只含有使用者所開設的帳戶，亦可還包含有：電子結帳服務之提供者用的帳戶、和用來將從該提供者往銀行之送金予以收取所需之帳戶。

又例如，資料記憶部100，係亦可將後述的銀行應用程式與電子結帳應用程式的應用程式ID，加以記憶。假設應用程式ID係已經被建立關連有，用來識別支付方法的資訊。因此，在本實施形態中，一旦銀行伺服器10接收應用程式ID，與該應用程式ID建立關連的支付方法，就被特定成為已被使用者所選擇之支付方法。又例如，資料記憶部100，係亦可將為了與收納代理業者合作所需之資料，加以記憶。又例如，資料記憶部100，係亦可將為了與電子結帳伺服器20、使用者終端30、及收納代理業者之伺服器之每一者合作所需之API，加以記憶。

[取得部] 取得部101，係在繳費單之條碼已被使用者終端30所讀取的情況下，將關於對應於條碼之支付的支付資訊，加以取得。所謂對應於條碼之支付，係指被記載有條碼的繳費單之支付。換成別的說法，對應於條碼之支付，係為基於條碼中所含之資訊而被識別的支付。在本實施形態中，藉由條碼資訊中所含之支付ID而被特定的支付，是相當於對應於條碼之支付。

在本實施形態中，由於各個支付的支付資訊是被儲存在支付資訊資料庫DB2中，因此支付資訊資料庫DB2的各個紀錄中所被儲存的資訊，係相當於支付資訊。支付資訊，係只要是能夠識別支付的資訊即可，不限於圖8的例子。例如，在支付資訊中係亦可不含支付期限。又例如，在支付資訊中係亦可含有收納代理業者的識別資訊。又例如，在支付資訊中係亦可被設有，可讓支付目標做自由設定的資料領域。

例如，支付資訊係含有：關於對應於條碼之支付的支付目標的支付目標資訊。支付目標資訊，係為可識別支付目標的資訊，例如為支付目標ID。除了支付目標ID以外，支付目標名稱亦可相當於支付目標資訊。取得部101，係參照支付資訊資料庫DB2，取得關於對應於條碼之支付的支付資訊。

在本實施形態中，使用者終端30，係一旦讀取條碼，就基於公知的偵測演算法，取得條碼中所含之條碼資訊。條碼資訊中係至少含有支付ID。使用者終端30，係對銀行伺服器10，發送條碼資訊。取得部101，係在支付資訊資料庫DB2之中，參照從使用者終端30所接收到的條碼資訊中所含之支付ID所被儲存的紀錄，取得支付資訊。此外，從使用者終端30對銀行伺服器10，亦可發送攝影影像，而由銀行伺服器10側來取得條碼資訊。

[特定部] 特定部102，係在複數個支付方法之中，特定出已被使用者所選擇之支付方法。在本實施形態中，由於準備了信用卡、電子貨幣、及銀行轉帳之3個支付方法，因此特定部102係在這些3個支付方法之中，特定出已被使用者所選擇之支付方法。

可讓使用者做選擇的支付方法，係亦可全部的使用者皆為共通，亦可隨著使用者而定。例如，在有只利用電子結帳應用程式的使用者存在的情況下，則亦可讓其只能夠選擇信用卡與電子貨幣之2個支付方法。使用者，係只要選擇至少1個支付方法即可，亦可選擇複數個支付方法。在使用者選擇複數個支付方法的情況下，則這些複數個支付方法亦可在1個支付中被併用，亦可基於預先設定的優先順位而自動地選擇要用哪個支付方法。

在本實施形態中，電子結帳應用程式係準備有複數個支付方法，因此已被使用者所選擇之支付方法，係為電子結帳應用程式中所能利用的複數個支付方法之中的任一者。在圖2-圖5的例子中，雖然說明使用者選擇信用卡的情況，但使用者亦可選擇電子貨幣。又，在圖2-圖5的例子中，雖然說明了，已被使用者所選擇之支付方法，是利用使用者終端30之電子結帳應用程式的支付方法的情況，但已被使用者所選擇之支付方法，亦可為利用銀行應用程式的支付方法。

例如，使用者終端30，係對銀行伺服器10，發送用來特定已被使用者所選擇之支付方法所需之資訊，特定部102係基於該資訊，而特定出已被使用者所選擇之支付方法。在本實施形態中，作為該資訊之一例，說明應用程式的識別資訊。應用程式的識別資訊，係為可是別使用者所選擇之應用程式的資訊，係為例如應用程式每次被安裝時所被發行的應用程式ID。當使用者重新安裝應用程式的情況下，則會發行新的應用程式ID。在本實施形態中，係對電子結帳應用程式與銀行應用程式之每一者，發行了應用程式ID。此外，應用程式的識別資訊，係亦可不是應用程式ID，而是應用程式的名稱等。

特定部102，係在複數個應用程式之中，基於已被使用者所選擇之應用程式的應用程式ID，而特定出已被使用者所選擇之支付方法。假設關於應用程式ID與支付方法之對應關係，係預先被記憶在資料記憶部100中。例如，特定部102，係若應用程式ID是屬於電子結帳應用程式的，則判定為使用者選擇了信用卡或電子貨幣。至於使用者是選擇了信用卡或電子貨幣之何者，係亦可連同應用程式ID一起被發送，若是電子結帳應用程式則亦可把信用卡特定成為預設的支付目標。又例如，特定部102，係若應用程式ID是屬於銀行應用程式的，則判定為使用者選擇了銀行轉帳。

此外，特定部102所致之特定方法，係不限於上記的例子。亦可不是應用程式ID，而世界由已被使用者所選擇之支付方法的識別資訊，來特定出已被使用者所選擇之支付方法。此情況下，使用者終端30，係對銀行伺服器10，發送支付方法的識別資訊。例如，該識別資訊中係表示，信用卡、電子貨幣、或銀行轉帳之哪一者被選擇。該識別資訊，係亦可預先被記憶在使用者終端30中，亦可在條碼的讀取前或讀取後，讓使用者來選擇支付方法然後基於該選擇結果而被生成。

除此以外還亦可為，例如，特定部102，係亦可不是基於從使用者終端30所接收到的資訊，而是基於銀行伺服器10中所被記憶之資訊，而特定出已被使用者所選擇之支付方法。此情況下，假設已被使用者所選擇之支付方法的識別資訊，是已經被記憶在資料記憶部100中。例如，亦可將儲存使用者之基本資訊的使用者資料庫記憶在資料記憶部100中，然後對使用者資料庫，儲存已被使用者所選擇之支付方法(預設之支付方法)。此情況下，特定部102係亦可從使用者終端30取得使用者的識別資訊(使用者ID或使用者名等)，將與該識別資訊建立關連的支付方法，特定作為已被使用者所選擇之支付方法。

[參照部] 參照部103係參照：把複數個支付目標之每一者、與複數個支付方法之中可支援的支付方法予以建立關連的支付目標資料庫DB1。參照部103，係參照支付目標資料庫DB1，而將與對應於條碼之支付建立關連的可支援的支付方法，加以特定。在本實施形態中，由於在支付目標資料庫DB1中，支付目標ID與可支援的支付方法是被建立關連，因此參照部103係將對應於條碼之支付的支付目標ID所被建立關連的可支援的支付方法，加以特定。此外，對應於條碼之支付的支付目標ID，係亦可被包含在從使用者終端30所接收之條碼資訊中，亦可從條碼資訊中所含之支付ID而被檢索。

在本實施形態中，(A)類型之支付目標，係存在有可充抵點數的信用卡支付、和無法充抵點數的信用卡支付，因此參照部103係參照，把複數個支付目標之每一者、與支付方法之併用可否予以建立關連的支付目標資料庫DB1。參照部103，係參照支付目標資料庫DB1，而將與對應於條碼之支付建立關連的併用可否。在本實施形態中，由於在支付目標資料庫DB1中，支付目標ID與併用可否是被建立關連，因此參照部103係將對應於條碼之支付的支付目標ID所被建立關連的併用可否，加以特定。在本實施形態中，可充抵點數的信用卡支付，是屬於可併用的支付方法，無法充抵點數的信用卡支付，是屬於不可併用的支付方法。關於電子貨幣與銀行轉帳也是屬於不可併用的支付方法。

[判定部] 判定部104，係基於支付目標ID與支付目標資料庫DB1，來判定在對應於條碼之支付的支付目標中，已被使用者所選擇之支付方法是否為可支援。判定部104係將已被使用者所選擇之支付方法、與支付目標資料庫DB1中所被儲存之可支援的支付方法，進行比較。判定部104，係若已被使用者所選擇之支付方法是作為可支援的支付方法而被定義在支付目標資料庫DB1中，則判定為已被使用者所選擇之支付方法是可支援。判定部104，係若已被使用者所選擇之支付方法並未作為可支援的支付方法而被定義在支付目標資料庫DB1中，則判定為已被使用者所選擇之支付方法是不可支援。

在本實施形態中，由於有像是可充抵點數的信用卡支付這類可併用的支付方法存在，因此判定部104，係基於支付目標資訊與支付目標資料庫DB1，來判定在對應於條碼之支付的支付目標中，支付方法之併用是否為可能。判定部104係將已被使用者所選擇之支付方法、與支付目標資料庫DB1中所被儲存之併用可否，進行比較。判定部104，係若已被使用者所選擇之支付方法是作為可併用而被定義在支付目標資料庫DB1中，則判定為已被使用者所選擇之支付方法係為可併用。判定部104，係若已被使用者所選擇之支付方法並未作為可併用而被定義在支付目標資料庫DB1中，則判定為已被使用者所選擇之支付方法係為不可併用。

[顯示控制部] 顯示控制部105，係令使用者終端30顯示出各種畫面。例如，顯示控制部105，係在藉由判定部104而判定為並非可支援的情況下，則將對應於條碼之支付的支付目標中可支援的其他支付方法，令使用者終端30做顯示。其他支付方法，係為未被使用者所選擇之支付方法。其他支付方法是複數存在的情況下，則顯示控制部105，係亦可令複數個其他支付方法全部都被顯示，亦可只顯示其一部分。所謂令其他支付方法被顯示，係指令表示其他支付方法的影像被顯示、或令可選擇其他支付方法的影像被顯示。在本實施形態中，由於是藉由銀行伺服器10來實現顯示控制部105，因此顯示控制部105，係藉由將用來令這些影像做顯示所需之資料，發送至使用者終端30，以令這些影像被顯示。

例如，顯示控制部105，係針對類型(B)之支付目標，在使用者選擇了信用卡的情況下，如圖4的確認畫面G2所示，於視窗W22中，作為其他支付方法是令電子貨幣被顯示。此情況下，其他支付方法係為，在與使用者選擇了支付方法的應用程式相同的應用程式中所能夠利用的其他支付方法。又例如，顯示控制部105，係針對類型(C)之支付目標，在使用者選擇了信用卡或電子貨幣的情況下，如圖5的確認畫面G2所示，於視窗W25中，作為其他支付方法是令銀行轉帳被顯示。此情況下，其他支付方法就變成，利用了與使用者選擇了支付方法的電子結帳應用程式不同的銀行應用程式的支付方法。

[執行部] 執行部106，係基於支付資訊，執行以已被使用者所選擇之支付方法來進行支付所需之支付處理。支付處理，係只要是關於對應於條碼之支付的處理即可，例如結帳處理本身亦可相當於支付處理，為了結帳處理而必須之準備處理亦可相當於支付處理。例如，準備處理係為，對電子結帳伺服器20或使用者終端30，發送結帳處理所必須之資訊。此外，收納檔案之作成或向收納代理公司的電文之送訊，亦可相當於支付處理。

銀行伺服器10係可執行銀行轉帳，因此藉由使用者而選擇了銀行轉帳的情況下，則執行部106係執行銀行轉帳，來作為支付處理。銀行轉帳本身，係只要藉由公知的方法來執行即可，例如，執行部106係執行，從使用者之銀行帳戶對支付目標之銀行帳戶的支付金額之轉帳處理。

另一方面，藉由使用者而選擇了信用卡或電子貨幣的情況下，則由於電子結帳伺服器20會執行結帳處理，因此執行部106係執行信用卡或電子貨幣之結帳所必須之準備處理。此情況的準備處理，係可為任意之處理，例如：向使用者終端30發送支付資訊、或向電子結帳伺服器20委託結帳處理之執行。

如上述，執行部106，係隨應於已被使用者所選擇之支付方法，而使支付處理的處理內容有所不同。亦即，執行部106的處理內容，係隨著已被使用者所選擇之支付方法而不同。支付方法與處理內容之關係，係假設預先被描述在程式碼中。執行部106係執行，已被使用者所選擇之支付方法所相應之處理內容的支付處理。

在本實施形態中，執行部106，係在藉由判定部104而被判定為可支援的情況下，執行支付處理。執行部106，係在藉由判定部104而被判定為不可支援的情況下，則不執行已被使用者所選擇之支付方法的支付處理，而是以藉由判定部104而被判定為可支援作為條件，來執行已被使用者所選擇之支付方法的支付處理。

例如，(A)類型之支付目標的情況下，由於任一支付方法被選擇皆被判定為可支援，因此執行部106係執行已被使用者所選擇之支付方法的支付處理。又例如，(B)類型之支付目標的情況下，在電子貨幣或銀行轉帳的情況下會被判定為可支援，因此執行部106係在電子貨幣或銀行轉帳之任一支付方法是已被使用者所選擇的情況下，執行該支付方法的支付處理。又例如，(C)類型之支付目標的情況下，在銀行轉帳的情況下會被判定為可支援，因此執行部106係在藉由使用者選擇了銀行轉帳的情況下，才執行銀行轉帳的支付處理。

在本實施形態中，在藉由判定部104而被判定為無法支援的情況下，則由於可以選擇其他支付方法，因此執行部106係在藉由使用者而選擇了其他支付方法的情況下，執行為了以其他支付方法來執行支付所需之支付處理。在本實施形態中，(A)類型之支付目標的情況下，由於任一支付方法被選擇皆被判定為可支援，因此在(B)或(C)類型之支付目標的情況下，會發生其他支付方法之選擇。

例如，(B)類型之支付目標的情況下，若使用者選擇信用卡則會被判定為無法支援，使用者係可選擇電子貨幣來作為其他支付方法。執行部106，係在藉由使用者而選擇了電子貨幣的情況下，執行電子貨幣之支付處理。又例如，(C)類型之支付目標的情況下，若使用者選擇信用卡或電子貨幣則會被判定為無法支援，使用者係可選擇銀行轉帳來作為其他支付方法。執行部106，係在藉由使用者而選擇了銀行轉帳的情況下，執行銀行轉帳之支付處理。

在本實施形態中，由於可以併用複數個支付方法，因此執行部106係執行，將已被使用者所選擇之複數個支付方法加以併用來進行支付所需之支付處理。該支付處理，係只要是關於複數個支付方法之併用的處理即可，例如：執行複數個支付方法之全部的結帳處理、執行一部分之支付方法的結帳處理與其他支付方法的準備處理、或執行複數個支付方法之全部的準備處理。

在本實施形態中，由於並非所有的支付目標都能併用，因此執行部106係在藉由判定部104而被判定為可併用的情況下，則執行將已被使用者所選擇之複數個支付方法予以併用來進行支付所需之支付處理。執行部106，係在藉由判定部104而被判定為可併用的情況下，則不執行併用了複數個支付方法的支付處理，以藉由判定部104而被判定為可支援作為條件，執行併用了複數個支付方法的支付處理。

例如，(A)類型之中，可支援可充抵點數之信用卡支付的支付目標，係由於併用了信用卡與點數的支付係為可能，因此執行部106係執行將這些予以併用來進行支付所需之支付處理。關於信用卡與點數係由電子結帳伺服器20來執行結帳處理，因此執行部106係執行為了信用卡與點數之各者的結帳所必須之準備處理。準備處理的意思係如前述。例如，執行部106係將一部分之支付金額設成信用卡之支付，將剩餘的部分設成點數之支付。將全額設成點數之支付的情況下，信用卡之結帳亦可用0圓而被執行。

[3-2.於電子結帳伺服器中所被實現的機能] 如圖6所示，在電子結帳伺服器20中係被有資料記憶部200和結帳部201被實現。資料記憶部200，係以記憶部22為主而被實現，結帳部201，係以控制部21為主而被實現。

[資料記憶部] 資料記憶部200，係記憶著結帳時所必須之資料。例如，資料記憶部200係記憶著，儲存有關於利用電子結帳服務之使用者的資訊的使用者資料庫。在該使用者資料庫中，係按照利用電子結帳服務的每一使用者，而儲存了電子結帳應用程式的應用程式ID、信用卡資訊、電子貨幣資訊、及點數資訊等。

信用卡資訊，係為使用者所登錄的信用卡之號碼或有效期限等。電子貨幣資訊，係為使用者所保有的電子貨幣之餘額等。點數資訊，係為使用者所保有的點數之餘額等。利用了信用卡、電子貨幣、或點數的支付，係基於這些資訊而執行結帳。結帳的執行方法本身，係只要利用公知的手法即可。

[結帳部] 結帳部201，係基於使用者資料庫中所被記憶的結帳資訊，來執行對應於條碼之支付的結帳。例如，藉由使用者而選擇了信用卡的情況下，結帳部201，係基於使用者資料庫中所被儲存的信用卡資訊，來執行信用卡結帳。又例如，藉由使用者而選擇了電子貨幣的情況下，執行部106，係基於使用者資料庫中所被儲存的電子貨幣資訊，來執行電子貨幣結帳。在可利用其他支付方法的情況下，則結帳部201係只要基於該支付方法所相應之結帳資訊，來執行該支付方法所相應之結帳處理即可。

[3-3.使用者終端中所被實現的機能] 如圖6所示，在使用者終端30中，係有：資料記憶部300、偵測部301、受理部302、及顯示控制部303被實現。資料記憶部300，係以記憶部32為主而被實現，其他的各機能，係以控制部31為主而被實現。

[資料記憶部] 資料記憶部300係記憶著，為了執行對應於條碼之支付所必須之資料。例如，資料記憶部300係記憶著，為了利用複數個支付方法之每一者所需之應用程式。亦即，資料記憶部300，係將複數個支付方法所分別對應的複數個應用程式，加以記憶。在本實施形態中，係有電子結帳應用程式和銀行應用程式之2個應用程式存在，使用者可選擇任一應用程式。因此，電子結帳應用程式與銀行應用程式之任一應用程式亦可相當於第1應用程式，亦可相當於第2應用程式。只要使用者先選擇的應用程式是相當於第1應用程式，在該應用程式之支付方法是無法支援的情況下所被選擇的其他應用程式是相當於第2應用程式即可。

資料記憶部300，係亦可記憶為了登入至應用程式所需之資訊，亦可記憶已被使用者所選擇之支付方法。在本實施形態中，電子結帳應用程式，係可登錄預設的支付方法，因此資料記憶部300係亦可記憶用來識別已被使用者所選擇之預設之支付方法的資訊。

[偵測部] 偵測部301，係偵測繳費單的條碼。在本實施形態中，雖然說明藉由攝影部36而被拍攝的攝影影像是被利用的情況，但使用者終端30中亦可具備專用的讀碼器。例如，偵測部301係將攝影影像進行影像解析，而偵測出條碼。偵測部301，係將所偵測到的條碼中所含之條碼資訊，加以取得。

[受理部] 受理部302，係受理使用者之操作。例如，受理部302係受理，從複數個支付方法之中使用者所做的選擇。在本實施形態中，由於是藉由應用程式之選擇而選擇支付方法，因此受理部302係受理電子結帳應用程式或銀行應用程式之哪一者的選擇。又例如，受理部302係在已被使用者所選擇之支付方法是被判定為無法支援的情況下，受理其他支付方法之選擇。

[顯示控制部] 顯示控制部303，係令本實施形態中所說明的各種畫面被顯示。顯示控制部303，係啟動應用程式而令各畫面被顯示。顯示控制部303，係從銀行伺服器10的顯示控制部303接收到關於其他支付方法的資訊的情況下，則令關於其他支付方法的資訊被顯示。

[4.於支付系統中所被執行的處理] 圖9-圖11係為支付系統1中所被執行之處理的流程圖。圖9-圖11所示的處理，係藉由控制部11、21、31之各者依照記憶部12、22、32中所被記憶之程式而動作，而被執行。該處理，係為各機能區塊所執行的處理之一例。

如圖9所示，使用者終端30，係基於使用者之操作，而啟動電子結帳應用程式或銀行應用程式(S1)。電子結帳應用程式被啟動的情況下(S1；電子結帳應用程式)，則使用者終端30係啟動攝影部36，令攝影畫面G1被顯示於顯示部35(S2)。於S2中，使用者終端30，係基於攝影部36的偵測訊號而連續地取得攝影影像，令攝影畫面G1顯示出攝影影像。

使用者終端30，係基於攝影影像，而偵測出條碼(S3)。於S3中，使用者終端30，係基於公知的偵測演算法，將攝影影像進行影像解析而偵測出條碼。使用者終端30，係基於偵測演算法中所被定義的規則，而取得條碼中所含之條碼資訊。假設條碼資訊中係至少含有支付ID和支付目標ID。

使用者終端30，係將電子結帳應用程式的應用程式ID、和從條碼所取得的條碼資訊，發送至銀行伺服器10(S4)。銀行伺服器10，係一旦接收應用程式ID和條碼資訊，就參照支付資訊資料庫DB2，取得支付資訊(S5)。銀行伺服器10係判定，是否為已被登錄在支付目標資料庫DB1中的支付目標(S6)。於S6中，銀行伺服器10係判定，條碼資訊中所含之支付目標ID，是否存在於支付目標資料庫DB1中。

在判定為並非已被登錄在支付目標資料庫DB1中的支付目標的情況下(S6；N)，本處理就結束。此情況下，銀行伺服器10，係令使用者終端30顯示出錯誤訊息，將這是在支付系統1中所無法處理的支付目標的事實，通知給使用者。

另一方面，在判定為是已被登錄在支付目標資料庫DB1中的支付目標的情況下(S6；Y)，則銀行伺服器10係特定出信用卡來作為已被使用者所選擇之支付方法(S7)，基於支付目標資料庫DB1，判定是否為有支援信用卡的支付目標(S8)。於S7中，銀行伺服器10，係由於S5中所接收到的應用程式ID是表示電子結帳應用程式，因此將信用卡特定成為支付方法。於S8中，銀行伺服器10，係在有支援信用卡的支付目標的情況下，還針對點數之充抵可否，進行判定。

在判定為是有支援可充抵點數之信用卡支付的支付目標的情況下(S8；可充抵)，則銀行伺服器10係對使用者終端30，將條碼資訊中所含之支付ID所對應之支付資訊(S5中所取得之支付資訊)，連同可充抵點數之意旨的通知，予以發送(S9)。

使用者終端30，係一旦接收到支付資訊與通知，就令可充抵點數的確認畫面G2被顯示於顯示部35(S10)。S10中所被顯示的確認畫面G2，係變成圖2的狀態。在使用者選擇了按鈕B20的情況下，則將支付金額之部分或全部，以點數進行充抵。此外，使用者所保有之點數或電子貨幣之資訊或信用卡資訊，係亦可被記憶在電子結帳應用程式內，亦可在確認畫面G2被顯示的時序上，從電子結帳伺服器20而被取得。

使用者終端30，係在滑桿B21被滑動的情況下，對電子結帳伺服器20，發送結帳要求(S11)。假設結帳要求中係含有：支付ID、支付金額、已被選擇之信用卡之資訊、及所被充抵的點數與電子貨幣之金額。

電子結帳伺服器20，係一旦接收到結帳要求，就執行結帳(S12)，對銀行伺服器10，發送結帳完成通知(S13)。於S13中，電子結帳伺服器20，係基於支付金額而執行信用卡結帳。使用者已選擇了點數與電子貨幣之充抵的情況下，則電子結帳伺服器20係執行，恰好該金額的點數與電子貨幣之結帳。這些結帳處理本身，係可適用公知的處理。假設結帳完成通知中係含有：從使用者終端30所接收到的支付ID。

銀行伺服器10，係一旦接收到結帳完成通知，就基於支付資訊資料庫DB2，而將收納檔案予以作成，並將收納電文，發送至外部的收納代理公司的伺服器(S14)。銀行伺服器10，係對使用者終端30，發送支付完成通知(S15)，在翌營業日以後，從電子結帳服務用的帳戶往銀行的不同帳戶進行入金(S16)。S14與S16之處理，係只要將利用公知的繳費單的支付中所被進行的處理加以利用即可。例如，假設對電子結帳服務用之帳戶，係有S12中的結帳相當額被進行入金。此外，在本實施形態中，雖然從讀取條碼到支付完成通知為止的處理，與企業間的資金移動，是以非同步方式進行的情況來做說明，但這些亦可為同步。使用者終端30，係一旦接收到支付完成通知，就令完成畫面G3被顯示於顯示部35(S17)，本處理係結束。

於S8中，在判定為是支援無法充抵點數的信用卡支付的支付目標的情況下(S8；點數充抵不可)，則前進至圖10，銀行伺服器10，係基於支付資訊資料庫DB2，而對使用者終端30，將條碼資訊中所含之支付ID所對應之支付資訊，連同無法充抵點數之意旨的通知，一併予以發送(S18)。

使用者終端30，係一旦接收到支付資訊與通知，就令無法充抵點數的確認畫面G2被顯示於顯示部35(S19)。S19中所被顯示的確認畫面G2，係變成圖3的狀態。以後，前進至S11之處理，隨應於使用者滑動滑桿B21，信用卡結帳就被執行。但是，此情況下，由於無法充抵點數，因此於S12中，點數的結帳等係不被執行，僅執行信用卡結帳。

於S8中，在判定為是不支援信用卡的支付目標的情況下(S8；N)，則前進至圖10，銀行伺服器10，係基於支付目標資料庫DB1，而判定是否為有支援電子貨幣的支付目標(S20)。在判定為是有支援電子貨幣的支付目標的情況下(S20；Y)，則銀行伺服器10，係基於支付資訊資料庫DB2，而對使用者終端30，將條碼資訊中所含之支付ID所對應之支付資訊，連同能夠支援電子貨幣之意旨的通知，一併予以發送(S21)。

使用者終端30，係一旦接收到支付資訊與通知，就令含有視窗W22的確認畫面G2被顯示於顯示部35(S22)。S22中所被顯示的確認畫面G2，係變成圖4的狀態。使用者終端30，係在按鈕B23已被選擇的情況下，令設定畫面G4被顯示於顯示部35(S23)。

使用者終端30，係基於使用者之操作而變更支付方法並令設定畫面G4顯示出視窗W42(S24)，令用來以電子貨幣進行支付所需的確認畫面G2被顯示於顯示部35(S25)。以後，前進至S11之處理，隨應於使用者滑動滑桿B21，於S12中執行電子貨幣結帳。

於S20中，在判定為是不支援電子貨幣的支付目標的情況下(S20；N)，則銀行伺服器10，係基於支付資訊資料庫DB2，而對使用者終端30，將條碼資訊中所含之支付ID所對應之支付資訊，連同催促銀行轉帳之意旨的通知，一併發送至使用者終端30(S26)。使用者終端30，係一旦接收到支付資訊與通知，就令含有視窗W25的確認畫面G2被顯示於顯示部35(S27)，一旦按鈕B26被選擇，則銀行應用程式就會啟動然後前進至後述的S36之處理。

於S1中，銀行應用程式被啟動的情況下(S1；銀行應用程式)，則前進至圖11，使用者終端30係啟動攝影部36，令與攝影畫面G1相同的攝影畫面被顯示於顯示部35(S28)。後續的S29～S33之處理，係分別和S3～S7之處理相同。於S33中，一旦藉由銀行應用程式的應用程式ID而特定出支付方法係為銀行轉帳，則銀行伺服器10，銀行伺服器10係基於支付資訊資料庫DB2，而對使用者終端30，將條碼資訊中所含之支付ID所對應之支付資訊，連同可支援銀行轉帳之意旨的通知，一併予以發送(S34)。

使用者終端30，係一旦接收到支付資訊與通知，就令銀行轉帳的確認畫面G5被顯示於顯示部35(S35)。S35中所被顯示的確認畫面G5，係變成圖5的狀態。使用者終端30，係在滑桿B50被滑動的情況下，對銀行伺服器10，發送結帳要求(S36)。假設結帳要求中係含有：使用者的識別資訊、支付ID、及支付金額。銀行伺服器10，係一旦接收結帳要求，就執行結帳(S37)。於S37中，銀行伺服器10，係基於使用者的識別資訊而特定出使用者的帳戶，執行銀行轉帳。後續的S38～S40之處理，係分別和S14、S16～S17之處理相同。

若依據以上說明的支付系統1，則在複數個支付方法之中，使用已被使用者所選擇之支付方法，來執行繳費單上所記載之代碼所對應之支付之支付處理，因此可讓使用者使用所望的支付方法來進行支付，可提高使用者的便利性。又，在本實施形態中，銀行伺服器10，係在使用者終端30中讀取了條碼的情況下，藉由接收應用程式ID與條碼資訊，就可特定出該時序上已被使用者所選擇之支付方法。因此，可減少銀行伺服器10與使用者終端30的通訊次數。例如，銀行伺服器10進行圖9的S6之判定而確認了是已被登錄的支付目標之後，將支付目標名稱或支付金額發送至使用者終端30，將已被使用者所選擇之支付方法從使用者終端30予以接收並判定是否可支援的情況下，則銀行伺服器10與使用者終端30的通訊次數係會增加，但是若依據實施形態的支付系統1，則可省去這類麻煩，可減少通訊次數。支付系統1，係即使是相同條碼，仍可藉由讀取其的應用程式而由銀行伺服器10來特定出支付方法。

又，支付系統1係判定，在繳費單上所記載之代碼所對應之支付的支付目標中，已被使用者所選擇之支付方法是否為可支援，在判定為可支援的情況下，以已被使用者所選擇之支付方法，來執行繳費單上所記載之代碼所對應之支付，藉此支付目標可令使用者以所望之支付方法來進行支付，可提高支付目標的企業或自治體等的便利性。

又，支付系統1係在判定為，在繳費單上所記載之代碼所對應之支付的支付目標中，已被使用者所選擇之支付方法是無法支援的情況下，則將繳費單上所記載之代碼所對應之支付的支付目標中所能夠支援的其他支付方法，令使用者終端30做顯示。在藉由使用者而選擇了其他支付方法的情況下，藉由以其他支付方法，來執行繳費單上所記載之代碼所對應之支付，藉此，即使最初的支付方法是沒有支援，仍可以作為替代手段的其他支付方法來進行支付，可提更使用者的便利性。

又，在支付系統1中，已被使用者所選擇之支付方法，係為應用程式中所能利用的複數個支付方法之中的任一者，其他支付方法，係為該應用程式中所能利用的其他支付方法，藉此，在某個應用程式內可以使用作為替代手段的其他支付方法來進行支付，因此可省去啟動其他應用程式的麻煩，可提高使用者的便利性。

又，支付系統1係為，已被使用者所選擇之支付方法係為利用了使用者終端30的第1應用程式(例如電子結帳應用程式)的支付方法，其他支付方法係為利用了使用者終端30的第2應用程式(例如銀行應用程式)的支付方法，因此，即使某個應用程式的支付方法係為未支援，仍可利用其他應用程式來作為替代手段而進行支付，可提高使用者的便利性。

又，支付系統1係為，在使用者終端30中係被記憶有複數個支付方法所分別對應的複數個應用程式，在複數個應用程式之中，基於已被使用者所選擇之應用程式的識別資訊，來特定出已被使用者所選擇之支付方法，因此銀行伺服器10係只要能夠接收應用程式的識別資訊，就能特定出支付方法。其結果為，如前述般地，可達成通訊次數之削減。

又，支付系統1，係藉由將已被使用者所選擇之複數個支付方法加以併用，來執行對應於繳費單之條碼之支付的支付處理，而可提高使用者的便利性。

又，支付系統1係判定，在對應於繳費單之條碼之支付的支付目標中，已被使用者所選擇之複數個支付方法之併用是否為可能，在判定為可併用的情況下，只有在認可支付方法之併用的支付目標中才讓併用的支付成為可能，可提高支付目標的企業或自治體等的便利性。

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

(1)例如，雖然說明了，(B)類型之支付目標的情況下，如圖4的確認畫面G2所示，會催促支付方法變更成電子貨幣之意旨的情況，但亦可讓使用者來選擇電子貨幣與銀行轉帳之哪一者。

圖12係為變形例(1)中的針對(B)類型之支付目標的支付之流程的圖示。如圖12所示，在本變形例中，於確認畫面G2中，可以選擇電子貨幣或銀行轉帳之哪一者的視窗W28，係被顯示。一旦使用者選擇了按鈕B29，則圖4的設定畫面G4係被顯示於使用者終端30。一旦使用者選擇了按鈕B30，則銀行應用程式就會啟動而圖5的確認畫面G5就被顯示於使用者終端30。此外，一旦使用者選擇了按鈕B31，就可取消繳費單之支付。

本變形例的顯示控制部105，係將在對應於條碼之支付的支付目標中可支援的複數個其他支付方法，令使用者終端30做顯示。複數個其他支付方法，係亦可為相同的應用程式，亦可為彼此不同的應用程式。顯示控制部105，係令複數個其他支付方法，被顯示成可選擇。例如，顯示控制部105，係於視窗W28中，令電子貨幣或銀行轉帳之任一者被顯示成可選擇。

執行部106係執行，在複數個其他支付方法之中，以已被使用者所選擇之其他支付方法來進行支付所需之支付處理。支付處理本身，係如同實施形態中所說明。執行部106之處理，係在已被使用者所選擇之其他支付方法之支付處理會被執行的這點上，有所不同。

若依據變形例(1)，則在對應於條碼之支付的支付目標中可支援的複數個其他支付方法之中，藉由執行為了以已被使用者所選擇之其他支付方法來進行支付所需之支付處理，就可增加作為替代手段的支付方法之選項，可提高使用者的便利性。

(2)又例如，在實施形態中，雖然舉出利用了繳費單的支付為例來做說明，但亦可不是繳費單，即使針對讓人輸入繳費用號碼的支付，也可利用相同的處理。繳費用號碼，係將支付做唯一識別的資訊。繳費用號碼，係亦可與支付ID相同，亦可為與支付ID不同的資訊。繳費用號碼，係以電子郵件等而被通知給使用者。一旦使用者在便利商店之終端等中輸入了繳費用號碼，則用來進行支付所需之用紙(繳費單之一種)就被列印，就可以用店員所操作的終端等來進行支付。在本變形例中係說明，藉由將如此的繳費用號碼輸入至使用者終端30，以進行支付的情況。

假設在本變形例的支付資訊資料庫DB2中，係與支付ID建立關連而被儲存有繳費用號碼。本變形例的支付目標，係並非支援條碼的支付目標，而是支援繳費用號碼的支付目標。支付系統1中所被執行的處理，係與實施形態中所說明的處理大致相同，但由使用者終端30來讀取條碼而取得條碼資訊中所含之支付ID的處理，是被置換成利用已被輸入至使用者終端30的繳費用號碼來取得支付ID的處理，這點有所不同。

取得部101，係在繳費用號碼是已被輸入至使用者終端30的情況下，取得關於對應於繳費用號碼之支付的支付資訊。所謂對應於繳費用號碼之支付，係為基於繳費用號碼而被識別的支付。在支付資訊資料庫DB2之中，藉由使用者而被輸入的繳費用號碼所被儲存的紀錄所對應之支付，係為對應於繳費用號碼之支付。關於支付已被特定後的處理，係和實施形態相同。

若依據變形例(2)，則在複數個支付方法之中，使用已被使用者所選擇之支付方法，來執行對應於繳費用號碼之支付，因此可讓使用者使用所望的支付方法來進行支付，可提高使用者的便利性。

(3)又例如，亦可將上記變形例加以組合。

又例如，在實施形態中，雖然說明了支付目標是(A)-(C)之任一類型的情況，但支付目標之類型係不限於這些。支付目標，係只要支援複數個支付方法之中的至少1者即可。例如，亦可有不支援銀行轉帳，但可支援信用卡的支付目標存在。此情況下，亦可為，使用者以銀行應用程式來讀取條碼或將繳費用號碼予以輸入等情況下，催促信用卡支付的訊息就被顯示於使用者終端30，電子結帳應用程式就會啟動。又例如，支付方法係不限於信用卡、電子貨幣、及銀行轉帳，可適用任意之支付方法的組合。

又例如，雖然說明了，電子結帳應用程式與銀行應用程式之2個被安裝於使用者終端30的情況，但使用者終端30中亦可只被安裝有其中任一應用程式。又例如，使用者終端30亦可利用電子結帳應用程式及銀行應用程式以外之應用程式，來讀取繳費單的條碼或是輸入繳費用號碼等等。又例如，亦可不必特地利用應用程式，而是利用瀏覽器等來進行支付。又例如，作為金融機關之一例雖然說明了銀行，但亦可為利用了銀行以外的金融機關的支付方法。

又例如，以電子結帳應用程式來讀取條碼或輸入繳費用號碼等情況下，銀行應用程式之安裝的有無，亦可被通知給銀行伺服器10。此情況下，銀行伺服器10，係亦可只有在銀行應用程式有被安裝的情況下，才令用來催促如圖5所示的銀行轉帳的訊息被顯示。如此，以電子結帳應用程式來讀取條碼或輸入繳費用號碼等情況下，已被使用者所選擇之支付方法以外之其他支付方法(使用者所能支援的其他支付方法)係亦可被通知給銀行伺服器10，銀行伺服器10係在已被使用者所選擇之支付方法是在支付目標中並沒有支援的情況下，則令已被通知的其他支付方法，被顯示於使用者終端30。

又例如，資料記憶部100，係亦可藉由與銀行伺服器10不同的資料庫伺服器來加以實現。又例如，作為在銀行伺服器10中被實現而做說明的機能，係亦可在電子結帳伺服器20或使用者終端30中被實現。又例如，作為在電子結帳伺服器20或使用者終端30中被實現而做說明的機能，係亦可在銀行伺服器10中被實現。除此以外，例如，各機能係亦可在其他電腦中被實現，亦可被複數台電腦所分擔。

1:支付系統

N:網路

10:銀行伺服器

11,21,31:控制部

12,22,32:記憶部

13,23,33:通訊部

20:電子結帳伺服器

30:使用者終端

34:操作部

35:顯示部

36:攝影部

G1:攝影畫面

G2:確認畫面

G3:完成畫面

G4:設定畫面

G5:確認畫面

G6:完成畫面

100:資料記憶部

101:取得部

102:特定部

103:參照部

104:判定部

105:顯示控制部

106:執行部

200:資料記憶部

201:結帳部

300:資料記憶部

301:偵測部

302:受理部

303:顯示控制部

B20,B23,B24,B26,B27,B29,B30,B31,B40,B41,B43:按鈕

B21,B50:滑桿

DB1:支付目標資料庫

DB2:支付資訊資料庫

W22,W25,W28,W42:視窗

[圖1]實施形態所述之支付系統之一例的圖示。 [圖2]針對(A)類型之支付目標的支付之流程的圖示。 [圖3]針對(A)類型之支付目標的支付之流程的圖示。 [圖4]針對(B)類型之支付目標的支付之流程的圖示。 [圖5]針對(C)類型之支付目標的支付之流程的圖示。 [圖6]於支付系統中所被實現之機能的機能區塊圖。 [圖7]支付目標資料庫的資料儲存例的圖示。 [圖8]支付資訊資料庫資料儲存例的圖示。 [圖9]支付系統中所被執行之處理的流程圖。 [圖10]支付系統中所被執行之處理的流程圖。 [圖11]支付系統中所被執行之處理的流程圖。 [圖12]變形例(1)中的針對(B)類型之支付目標的支付之流程的圖示。