TWI847077B - 資訊處理裝置、資訊處理方法及程式產品 - Google Patents

Abstract

[課題] 在使用對查詢系統詢問結帳之可否判定的結帳手段的結帳中，使得該當結帳手段之替代處理可在適切的時序上被開始。 [解決手段] 資訊處理裝置中係具備：結帳要求收訊部，係用以接收結帳要求；和詢問部，係將前記結帳要求所涉及之結帳之可否，對負責判定使用到第一結帳手段之結帳之可否的查詢系統，進行詢問；和結果取得部，係取得前記查詢系統所做的前記可否判定之結果；和結帳確認收訊部，係在等待前記查詢系統所做的前記可否判定之結果之期間中，可從前記結帳要求之發行來源，將詢問前記結帳要求所涉及之結帳結果的結帳確認，進行複數次收訊；和替代處理開始部，係在以前記結帳要求為基準而被決定的第一時點以前所被接收的前記結帳確認之中最後之結帳確認被接收到的時序上，令前記第一結帳手段之替代處理被開始。

Description

資訊處理裝置、資訊處理方法及程式產品

本揭露係有關於，伴隨結帳之可否判定的結帳技術。

先前，使用者系統的代理處理控制裝置，一旦測知來自伺服器裝置之異常，就對遠端維修中心發送異常通知，接收到異常通知的維修中心的代理處理控制裝置，若根據異常內容而判定為可代理，就透過代理處理控制裝置而收取處理要求，將對應的處理程式產品從記憶裝置予以讀出，而在代理伺服器裝置中加以實施的代理處理方法，係已被提出(參照專利文獻1)。 [先前技術文獻] [專利文獻]

[專利文獻1] 日本特開2002-169704號公報

[發明所欲解決之課題]

先前，對查詢系統詢問使用到所定之結帳手段的結帳之可否判定，隨應於從查詢系統所得到的結果而執行或拒絕結帳的系統係已經被使用，又，為了應付從如此查詢系統的可否判定之取得時發生不良(障礙或延遲等)等情況，進行該當結帳手段之替代處理的技術，已被提出。可是，把替代處理之開始的契機設成從結帳要求之發行來源的結帳確認之收訊的情況下，有可能無法在適切的時序上進行替代處理之開始。

本揭露係有鑑於上記的問題，其課題在於，在使用對查詢系統詢問結帳之可否判定的結帳手段的結帳中，可在適切的時序上開始該當結帳手段之替代處理。 [用以解決課題之手段]

本揭露之一例係為，一種資訊處理裝置，係具備：結帳要求收訊手段，係用以接收結帳要求；和詢問手段，係用以將前記結帳要求所涉及之結帳之可否，對負責判定使用到第一結帳手段之結帳之可否的查詢系統，進行詢問；和結果取得手段，係用以取得前記查詢系統所做的前記可否判定之結果；和結帳確認收訊手段，係用以在等待前記查詢系統所做的前記可否判定之結果之期間中，可從前記結帳要求之發行來源，將詢問前記結帳要求所涉及之結帳結果的結帳確認，進行複數次收訊；和替代處理開始手段，係用以在以前記結帳要求為基準而被決定的第一時點以前所被接收的前記結帳確認之中最後之結帳確認被接收到的時序上，令前記第一結帳手段之替代處理被開始。

本揭露係可作為藉由資訊處理裝置、系統、電腦而被執行的方法或令電腦執行的程式產品，而加以界定。又，本揭露係也可作為將此種程式產品記錄至電腦或其他裝置、機械等可讀取之記錄媒體，而加以界定。此處，所謂電腦等可讀取之記錄媒體，係指將資料或程式產品等之資訊以電性、磁性、光學性、機械性或化學性作用而加以積存，並可從電腦等加以讀取的記錄媒體。 [發明效果]

若依據本揭露，則在使用對查詢系統詢問結帳之可否判定的結帳手段的結帳中，可在適切的時序上開始該當結帳手段之替代處理。

以下，將本揭露所述之資訊處理系統、資訊處理裝置、方法及程式產品之實施形態，基於圖式而加以說明。但是，以下所說明的實施形態，係僅為例示實施形態，本揭露所涉及的資訊處理系統、資訊處理裝置、方法及程式產品並非限定於以下所說明的具體構成。在實施之際，可因應實施之態樣而適宜採用具體構成，又，可進行各種的改良或變形。

在本實施形態中是針對，將本揭露所述之資訊處理系統、資訊處理裝置、方法及程式產品，於用來進行與所定之結帳手段(例如信用卡結帳)對應關連的代碼結帳所需之系統中來做實施的情況的實施形態，進行說明。但是，本揭露所涉及之資訊處理系統、資訊處理裝置、方法及程式產品，係可廣泛使用於用來提供結帳所需之技術，本揭露的適用對象係不限定於實施形態中所示的例子。

＜系統的構成＞ 圖1係為本實施形態所述之系統的構成的概略圖。本實施形態所述之系統係具備：藉由被連接至網路而可相互通訊的代碼結帳提供伺服器(以下稱作「結帳伺服器」)1、1或複數個POS(point of sale)終端5、帳號管理伺服器7、1或複數個使用者終端9，並被連接至外部查詢系統。

一般而言，於代碼結帳中，從POS終端等之店舖終端受理了結帳要求的結帳伺服器，係將該當結帳要求所表示的結帳之可否判定(與代碼結帳對應關連的第一結帳手段是信用卡的情況下，則為使用者的信用查詢)委託給外部查詢系統(例如信用卡公司的信用查詢系統)，隨應於該結果而執行或拒絕結帳。具體而言，結帳伺服器，係在對外部查詢系統的信用查詢之結果，得到了可支付之回應的情況下則執行結帳，得到了不可支付之回應的情況下則不執行結帳(拒絕)。

此處，從外部查詢系統的結帳可否判定之取得時，會有發生不良(障礙或延遲等)的情況。作為從外部查詢系統的結帳可否判定之取得時發生不良的情況係有例如：結帳伺服器與外部查詢系統之間的通訊發生異常、外部查詢系統的處理負荷過大、外部查詢系統中發生了系統錯誤…等多種情況，而會導致針對信用查詢要求的回答即使超過一定時間仍無法送返等之狀況。因此，先前，從外部查詢系統的結帳可否判定之取得時發生了不良的情況下仍使結帳能夠正常運用所需之對策，已有被採用。例如，從外部查詢系統的結帳可否判定之取得時發生了不良的情況下，由結帳伺服器取代外部查詢系統來進行結帳可否判定，可以採用如此的對策。

可是，採用如此對策的結果，在結帳伺服器側所代理進行的判定、與外部查詢系統所進行的判定不相符的情況下(例如結帳伺服器所做的判定：可結帳，外部查詢系統所做的判定：不可結帳)，從提供結帳手段的公司(例如信用卡公司)對使用者的請款及對結帳伺服器之提供事業者(代碼結帳事業者)的結算就會無法進行，變成要由結帳伺服器之提供事業者來代墊對店舖之支付。

於是，在本實施形態所述的系統中，如前述的作為代理處理之結果，由結帳伺服器所代理進行的判定、與外部查詢系統所進行的判定不相符的情況下，就會使用第二結帳手段(例如使用到同一使用者的點數/電子貨幣/銀行存款等的結帳手段)，來充抵該當結帳。

又，在發生大量的結帳要求的情況或來自外部查詢系統的回答需要耗費時間等情況下，為了防止來自POS終端的訊息(例如用來確認處理狀況所需之結帳確認)等造成結帳伺服器的記憶體(佇列)溢滿，POS終端與結帳伺服器之間的處理可採用非同步處理。此處，結帳伺服器是按照結帳要求單位而確保處理用之記憶體並將該當結帳要求所涉及之POS終端與結帳伺服器之間的通訊及結帳完成為止之處理加以管理的處理態樣稱作同步處理，相對於此，結帳伺服器每次從POS終端接收到訊息(結帳要求或結帳確認等)時才確保訊息處理用之記憶體並執行訊息所對應之處理，在對訊息的回應後就將該當訊息處理用記憶體予以釋放的處理態樣，稱作非同步處理。亦即，若採用非同步處理，則即使在發生了大量的結帳要求的情況或來自外部查詢系統的回答需要耗費時間等情況下，仍不會為了結帳要求之處理而佔用大量的結帳伺服器的記憶體，而可應付結帳要求。

可是，在採用了此種非同步處理的情況下，若從POS終端沒有接收到結帳確認則結帳伺服器中的判定代理等之替代處理所需之處理就不會被啟動，又，POS終端發送結帳確認的時序係依存於店舖側的系統之規格，因此在結帳伺服器側要在任意設定的時序上開始替代處理，是有困難的。其結果為，在目標時間(後述的第二所定之時間)內難以完成伴隨替代處理的結帳，或是隨著店舖側的系統之規格而導致伴隨替代處理的結帳完成為止的時間會有參差不齊的情況。

於是，在本實施形態所述的系統中，係基於從POS終端所被發送的結帳要求中所含之店舖ID，而參照從該當店舖之POS終端接收到結帳確認的時序，並隨應於對象之店舖側系統的規格，而將適合作為替代處理之開始觸發的結帳確認加以特定，而開始替代處理的執行。此外，本揭露所述的，將適合作為替代處理之開始觸發的結帳確認予以特定的技術，雖然於上記說明的採用非同步處理的系統中可以達到較高的效果，但可採用本揭露所述之技術的系統，係不限定於上記說明的採用非同步處理的系統。本揭露所述之技術，係於採用同步處理的系統中，也可採用。

圖2係為本實施形態所述之系統的硬體構成之概略的圖示。結帳伺服器1，係為用來對使用者提供代碼結帳服務所需之伺服器。結帳伺服器1，係為具備：CPU(Central Processing Unit)11、ROM(Read Only Memory)12、RAM(Random Access Memory)13、EEPROM (Electrically Erasable and Programmable Read Only Memory)或HDD(Hard Disk Drive)等之記憶裝置14、NIC (Network Interface Card)等之通訊單元15等的電腦。但是，關於結帳伺服器1的具體的硬體構成，係因應實施的態樣而可適宜地省略或置換、追加。又，結帳伺服器1係不限定於由單一的框體所成的裝置。結帳伺服器1，係可藉由使用所謂雲端或分散運算之技術等的複數個裝置來加以實現。

POS終端5，係被設置在店舖等之讓使用者購入商品或服務的場所，是在商品/服務被購入之際用來進行支付等所需之終端裝置。POS終端5，係為具備CPU、ROM、RAM、記憶裝置、通訊單元、輸入裝置、輸出裝置等(圖示省略)的電腦。此處，POS終端5，作為輸入裝置，是除了鍵盤或觸控面板以外，還具備有光學讀碼器或RFID讀取器、磁性讀取器等，用來讀取使用者識別資訊所需之裝置。但是，關於POS終端5的具體的硬體構成，係因應實施的態樣而可適宜地省略或置換、追加。例如，作為POS終端5，亦可取代先前的POS收銀機終端，改用具備觸控面板顯示器來作為輸出入裝置，可讓使用者安裝所望之應用程式產品並執行的所謂智慧型手機，可作為POS終端5而使用的機器之種類係沒有限定。又，POS終端5，係不限定於由單一的框體所成的裝置。POS終端5，係可藉由使用所謂雲端或分散運算之技術等的複數個裝置來加以實現。

帳號管理伺服器7，係為用來管理使用者帳號所需之伺服器。帳號管理伺服器7，係為具備CPU、ROM、RAM、記憶裝置、通訊單元等(圖示省略)的電腦。又，帳號管理伺服器7，係不限定於由單一的框體所成的裝置。帳號管理伺服器7，係可藉由使用所謂雲端或分散運算之技術等的複數個裝置來加以實現。結帳伺服器1，係藉由存取帳號管理伺服器7，而取得與使用者ID對應關連的使用者的會員狀態、點數餘額、電子貨幣餘額、銀行存款餘額等，關於使用者的資訊。又，帳號管理伺服器7，係對使用者終端9，發行與使用者ID對應關連的代碼結帳所需之結帳代碼。因此，結帳伺服器1，係藉由對帳號管理伺服器7進行詢問，而無論藉由結帳代碼及使用者ID之哪一者，都能夠特定出使用者。此外，於本系統中，結帳伺服器1與帳號管理伺服器7，係亦可作為具有這些雙方之機能的1台伺服器的方式，而被建構。

使用者終端9，係為被使用者所使用的終端裝置。使用者終端9，係為具備CPU、ROM、RAM、記憶裝置、通訊單元、輸入裝置、輸出裝置等(圖示省略)的電腦。又，使用者終端9，係不限定於由單一的框體所成的裝置。使用者終端9，係可藉由使用所謂雲端或分散運算之技術等的複數個裝置來加以實現。使用者，係透過這些使用者終端9，而從帳號管理伺服器7取得代碼結帳所需之結帳代碼，利用結帳伺服器1所提供的各種服務。

圖3係為本實施形態所述之結帳伺服器1的機能構成之概略的圖示。結帳伺服器1，係藉由記憶裝置14中所被記錄的程式產品，被讀出至RAM13上，被CPU11所執行，而控制結帳伺服器1中所具備的各硬體，以成為具備結帳要求收訊部21、詢問部22、結帳確認收訊部23、結果取得部24、時序記憶部25、替代處理開始部26、判定代理部27、結帳要求處理部28及充抵部29的資訊處理裝置而發揮機能。此外，在本實施形態及後述的其他實施形態中，結帳伺服器1所具備的各機能，係藉由通用處理器也就是CPU11而被執行，但這些機能的部分或全部係亦可藉由1或複數個專用處理器而被執行。

結帳要求收訊部21，係接收結帳要求。在本實施形態中，作為代碼結帳所需之結帳要求，含有已被帳號管理伺服器7所發行之結帳代碼、店舖ID及結帳額的結帳要求，係被接收。但是，結帳要求中所含之用來識別使用者所需之資訊，係亦可使用例如使用者ID本身等其他的識別資訊。

詢問部22，係將結帳要求所涉及之結帳之可否，對負責判定使用到第一結帳手段之結帳之可否的外部查詢系統，進行詢問。此外，在本實施形態中，作為第一結帳手段是說明使用信用卡結帳的態樣，詢問部22係對信用卡公司的信用查詢系統，詢問結帳之可否。但是，可作為第一結帳手段而採用的結帳手段係沒有限定。例如，作為第一結帳手段，亦可採用使用到點數、電子貨幣及銀行存款等之任一者的結帳手段。

結帳確認收訊部23，係在等待外部查詢系統所做的可否判定之結果之期間中，從結帳要求之發行來源(在本實施形態中係為POS終端5)，將詢問結帳要求所涉及之結帳結果的結帳確認，予以接收。此時，結帳確認收訊部23，關於1個結帳，係可接收複數次的結帳確認。

結果取得部24，係取得外部查詢系統所做的可否判定之結果。

時序記憶部25，係將隨著結帳要求之發行來源而不同的結帳確認之收送訊時序，予以預先記憶。於本實施形態所述的系統中，結帳確認的收送訊時序，係會隨著結帳要求之發行來源而不同。這是因為，隨著店舖所導入的每種POS系統，在針對結帳要求而無法獲得結帳結果的情況下，發送出結帳確認的時序是有所不同的緣故。

圖4係為本實施形態所述之，每種POS系統的結帳確認之送訊時序的圖示。時序記憶部25，係按照結帳之際在店舖側的身為對方之POS系統的每一種類，而記憶著結帳確認的送訊時序。在本實施形態中係例如，POS系統P1，係在針對結帳要求(Set訊息)的來自結帳伺服器1之回應訊息被收訊後就立刻發送出最初的結帳確認(Get訊息)，其後係每6秒地發送出結帳確認。另一方面，POS系統P2，係從回應訊息之收訊起1秒後發送出結帳確認，其後係在回應訊息被收訊起每2.5秒地發送出結帳確認。又，POS系統P3，係在結帳要求的1秒後發送出最初的結帳確認，其後係在回應訊息被收訊起每1秒地發送出結帳確認。但是，於本實施形態中所示的結帳確認的收送訊時序係為例示，結帳確認的收送訊時序，係不限定於這裡所舉出的例子。

替代處理開始部26，係在以結帳要求為基準而被決定的第一時點T1以前所被接收的結帳確認之中最後之結帳確認被接收到的時序上，以結帳確認的收訊為契機，令第一結帳手段之替代處理被開始。此處，第一時點T1係為，相較於以對外部查詢系統的詢問所涉及之所定之時點為起點而被預先設定的第二時點T2，提前了基於替代處理之處理時間而被決定之替代處理用時間以上的時序。替代處理所需要的時間為n秒的情況下，藉由將第一時點T1設成，較第二時點T2提前了n秒以上之時點，就可以在第二時點T2以前，對POS終端5回送判定結果。

替代處理開始部26，係基於從時序記憶部25所被取得的，結帳要求之發行來源所關連的收送訊時序，而特定出最後之結帳確認。結帳要求之發行來源，係可基於店舖ID而加以特定。若舉出具體的例子，作為第二時點T2是設定從結帳要求之收訊起算的8秒，而替代處理所需要的時間是未滿1秒的情況下，則藉由將第一時點T1設成從結帳要求之收訊起算的7秒，就可在第二時點T2以前，對店舖回送判定結果。若基於圖4所示的例子，則雖然隨著訊息收送訊之延遲等而可能會有所變動，但大致而言，以下的結帳確認，係被特定成為「在第一時點T1以前所被接收的結帳確認之中最後之結帳確認」。 關於來自POS系統P1的結帳要求：從結帳伺服器1接收到回應訊息起約6秒後所被發送的結帳確認。 關於來自POS系統P2的結帳要求：從結帳伺服器1接收到回應訊息起約5秒後所被發送的結帳確認。 關於來自POS系統P3的結帳要求：從結帳伺服器1接收到回應訊息起約6秒後所被發送的結帳確認。

又，替代處理開始部26，係令後述的充抵部29所致之充抵所需之處理被開始，以作為替代處理。在本實施形態中，作為充抵部29所致之充抵所需之處理，是令後述的判定代理部27所做的判定代理處理被開始。但是，隨著實施形態，亦可省略判定代理部27所做的判定代理處理，而開始充抵部29所致之充抵處理。

判定代理部27，係在從外部查詢系統的可否判定之取得時有不良的情況下，則取代外部查詢系統，基於與外部查詢系統不同的獨有的方法/基準，來判定結帳要求所涉及之結帳之可否。於本實施形態中，所謂從外部查詢系統的可否判定之取得時有不良的情況，係指對外部查詢系統沒有送出詢問的情況、或從外部查詢系統經過所定時間以上都得不到詢問結果的情況等，在如此的情況下，判定代理部27，係在從外部查詢系統取得可否判定之結果之前，會取代外部查詢系統，來判定結帳要求所涉及之結帳之可否。

例如，判定代理部27，作為與外部查詢系統不同的獨有之方法/基準，是基於後述的第二結帳手段所致之充抵可能性，來判定結帳要求所涉及之結帳之可否。更具體而言，例如，判定代理部27，係藉由判定是否滿足以下所示之複數個基準之中至少1個以上之基準，就可判定結帳之可否。 1)將基於結帳代碼/使用者ID而從帳號管理伺服器7所被取得之該當使用者以第二結帳手段所能夠充抵的結帳額之上限、與結帳要求中所含之結帳額進行比較，判定結帳額是否為上限以下。 2)基於結帳要求中所含之店舖ID而判定該當店舖是否許可第二結帳手段所致之充抵。

此外，作為使用者以第二結帳手段所能夠充抵的結帳額之上限，係亦可參照針對該當使用者而被預先設定的上限額，亦可參照該當使用者所擁有的額值(點數、電子貨幣或銀行存款等)之餘額。又，針對該當使用者而該當額值的負值餘額是被容許的情況下，則亦可將對額值之餘額加算可負值額度所得到的額度當作上限而進行判定。

結帳要求處理部28，係基於已被結果取得部24所取得之可否判定之結果、或判定代理部27所做的判定之結果(替代處理之結果)，而將結帳要求加以處理。此外，結帳的執行，係藉由對被結帳伺服器1所管理的帳本檔案(圖示省略)的記錄，而被進行。本實施形態所述之結帳，係為與信用卡對應關連的代碼結帳，因此在結帳的執行後，帳本檔案中所被記錄之結帳內容所相應的相當於結帳額之額值，係從結帳伺服器1之提供事業者往店舖、從信用卡公司往結帳伺服器1之提供事業者、從在店舖中購入了商品等的使用者往信用卡公司，分別被支付。又，結帳要求處理部28，係在經過了以結帳要求為基準而被決定的第二時點T2(例如從結帳要求被收訊起算8秒後的時序)為止都未取得外部查詢系統所做的可否判定之結果的情況下，就令結帳要求所涉及之結帳進行錯誤結束。

充抵部29，係針對在從外部查詢系統的可否判定之取得時有不良且藉由判定代理部27而被判定為可結帳的結帳要求所涉及之結帳，從外部查詢系統取得了不可結帳之結果的情況下，則使用第二結帳手段，來對結帳要求所涉及之結帳進行充抵。但是，充抵部29，係在從外部查詢系統的可否判定之取得時有不良的情況下，亦可不經判定代理部27所做的判定或外部查詢系統所做的判定結果之取得，就使用第二結帳手段，來對結帳要求所涉及之結帳進行充抵(關於「有不良的情況」之具體例，係參照上記判定代理部27之說明)。此外，於本實施形態中，結帳伺服器1或帳號管理伺服器7，按照每一使用者，將表示關於進行使用到第二結帳手段之充抵是否有從使用者獲得同意的資訊與使用者ID建立關連而保持；充抵部29，係藉由參照該當資訊，針對對象之結帳要求，而決定是否進行第二結帳手段所致之充抵。

此處，第二結帳手段，係為與結帳要求所涉及之第一結帳手段相同的使用者所涉及之結帳手段，例如，係為使用到與第一結帳手段相同的使用者所擁有的點數、電子貨幣及銀行存款等之任一者的結帳手段。充抵部29，係以使用者ID等為檢索鍵而對帳號管理伺服器7進行詢問，藉此以特定出與結帳要求所涉及之第一結帳手段相同的使用者所涉及之第二結帳手段，使用已被特定之第二結帳手段，來執行結帳要求所涉及之結帳。

更具體而言，作為第二結帳手段是使用點數支付的情況下，充抵部29，係基於結帳要求中所含之結帳代碼/使用者ID而特定出該當使用者之點數帳號，從已被特定之點數帳號之餘額，減去相當於結帳額的點數。此外，在點數之餘額是未滿結帳額的情況下，則亦可將點數餘額設成負值(例如點數餘額：300點，結帳額：500圓之時，將使用者的點數餘額更新成負200點)。又，作為第二結帳手段是使用電子貨幣支付的情況下，充抵部29，係基於結帳要求中所含之結帳代碼/使用者ID而特定出該當使用者之電子貨幣帳號，從已被特定之電子貨幣帳號之餘額，減去相當於結帳額的電子貨幣。此外，作為電子貨幣，係亦可使用儲值值型電子貨幣，亦可使用伺服器型電子貨幣。又，作為第二結帳手段是使用從銀行存款的支付的情況下，充抵部29，係基於結帳要求中所含之結帳代碼/使用者ID而特定出該當使用者之銀行帳戶，對已被特定之銀行帳戶，進行相當於結帳額的請款。

＜處理的流程＞ 接著說明，藉由本實施形態所述之資訊處理系統而被執行的處理的流程。此外，以下說明的處理的具體內容及處理順序，係為為了實施本揭露所需之一例。具體的處理內容及處理順序，係可隨著本揭露的實施形態而做適宜選擇。

圖5係為本實施形態所述之，藉由結帳伺服器1而被執行的結帳處理之概要的流程圖。使用者，係在希望結帳伺服器1所提供的結帳服務所致之結帳(在本實施形態中係為代碼結帳)的情況下，藉由使用者終端9而將從帳號管理伺服器7所取得的結帳代碼予以出示，將該當結帳代碼讓店舖的POS終端5進行讀取。然後，本流程圖中所示的處理，係以含有結帳所需之資訊的結帳要求(例如含有藉由帳號管理伺服器7而被發行的結帳代碼、店舖ID及結帳額)，從店舖之POS終端5被結帳伺服器1所接收為契機，而被執行。此外，在本實施形態中，作為結帳要求中所含之用來識別使用者所需之資訊，雖然針對使用從帳號管理伺服器7所被取得的結帳代碼的例子來做說明，但用來識別使用者所需之資訊，係亦可使用例如使用者ID等其他的識別資訊。

在步驟S101及步驟S102中，係依照已被接收之結帳要求，而對外部查詢系統進行結帳可否之詢問。一旦結帳要求收訊部21接收到藉由POS終端5而被發送的結帳要求(在本實施形態中係為，結帳伺服器1之提供事業者所提供的代碼結帳之要求)(步驟S101)，則結帳伺服器1係對POS終端5發送用來通知結帳要求已被受理所需之回應訊息。然後，詢問部22，係將與該當結帳要求對應關連的第一結帳手段(在本實施形態中係為信用卡結帳)予以特定，對負責判定使用到已被特定之第一結帳手段之結帳之可否的外部查詢系統，詢問該當結帳要求所涉及之結帳之可否(步驟S102)。詢問部22，係基於結帳要求中所含之結帳代碼，而將對象使用者的使用者ID及信用卡資訊從帳號管理伺服器7加以取得，藉由將結帳之可否判定上所必須的資訊(例如從帳號管理伺服器7所被取得的信用卡資訊、及結帳要求中所含之結帳額)，對外部查詢系統進行送訊，以詢問結帳之可否。其後，處理係往步驟S103前進。

在步驟S103至步驟S106中，係等待來自外部查詢系統的結帳可否之判定結果。結帳伺服器1，係直到下列任一條件被滿足為止： 1)外部查詢系統所做的結帳可否之判定結果被接收(步驟S103的YES)； 2)第一時點T1(在本實施形態中係為，從結帳要求被接收起算經過7秒的時點)經過之前的最後之結帳確認被接收(步驟S106的YES)；及 3)第二時點T2(在本實施形態中係為，從結帳要求被接收起算經過8秒的時點)已經過(步驟S104的YES)； 會一直反覆執行步驟S103至步驟S106之處理，而等待來自外部查詢系統的結帳可否之判定結果。此外，此期間中，若藉由結帳確認收訊部23而接收到，在來自外部查詢系統的結帳可否之判定結果尚未被接收的狀態下所被接收到的結帳確認，且並非第一時點T1經過之前的最後之結帳確認(步驟S106的NO)的結帳確認的情況下，則結帳伺服器1係將用來通知正在處理中的回應訊息，對POS終端5進行送訊，以應對之。此外，如上述，隨著結帳要求之發行來源，第一時點T1經過之前的最後之結帳確認被收送訊的時序會不同。因此，替代處理開始部26，係基於從時序記憶部25所被取得的，結帳要求之發行來源所關連的收送訊時序，來判定已被接收之結帳確認，是否為第一時點T1經過之前的最後之結帳確認。

在外部查詢系統所做的結帳可否之判定結果是已被接收的情況下(步驟S103的YES)，處理係往步驟S108前進。又，在第一時點T1經過之前的最後之結帳確認是已被接收的情況下(步驟S106的YES)，處理係往步驟S112前進。另一方面，在第二時點T2已經過的情況下(步驟S104的YES)，處理係往步驟S107前進。

在步驟S107中，結帳要求係被錯誤結束。第二時點T2已經過的情況下(步驟S104的YES)，結帳伺服器1係令結帳要求被錯誤結束，並對結帳要求之送訊來源的POS終端5，將結帳要求所涉及之結帳為失敗(結帳不成立)，當作對於來自POS終端5之結帳確認的回應訊息而進行通知。其後，本流程圖中所示的處理係結束。

在步驟S108至步驟S111中，基於外部查詢系統所做的可否判定之結果，結帳要求係被處理。在外部查詢系統所做的結帳可否之判定結果是已被接收的情況下(步驟S103的YES)，結帳要求處理部28係確認已被結果取得部24所接收之判定結果的內容(步驟S108)。已被接收之判定結果為不可結帳的情況下，結帳要求處理部28，係令結帳要求所涉及之結帳被錯誤結束，將結帳要求已被拒絕(結帳不成立)，當作對於來自POS終端5之結帳確認的回應訊息而對POS終端5進行通知(步驟S109)。另一方面，已被接收之判定結果為可結帳的情況下，結帳要求處理部28，係隨應於來自POS終端5之結帳確認而執行結帳要求所涉及之結帳(步驟S110)，對結帳要求之送訊來源的POS終端5，將結帳成立，當作對於來自POS終端5之結帳確認的回應訊息而進行通知。又，結帳伺服器1，係對外部查詢系統，通知結帳已被執行(步驟S111)。其後，本流程圖中所示的處理係結束。

在步驟S112至步驟S115中，係進行替代處理。在第一時點T1經過之前的最後之結帳確認是已被接收的情況下(步驟S106的YES)，判定代理部27係判斷為，從外部查詢系統的可否判定之取得時有不良，而取代外部查詢系統，來判定結帳要求所涉及之結帳之可否(步驟S112)。判定代理部27所做的判定結果為不可結帳的情況下(步驟S113的NO)，結帳要求處理部28，係令結帳要求所涉及之結帳被錯誤結束，將結帳要求已被拒絕(結帳不成立)，當作對於來自POS終端5之結帳確認的回應訊息而對POS終端5進行通知(步驟S114)。另一方面，判定代理部27所做的判定結果為可結帳的情況下(步驟S113的YES)，結帳要求處理部28，係執行結帳要求所涉及之結帳(步驟S115)，對結帳要求之送訊來源的POS終端5，將結帳成立，當作對於來自POS終端5之結帳確認的回應訊息而進行通知。其後，本流程圖中所示的處理係結束。

此外，於本實施形態中，結帳伺服器1係在判定代理部27所做的判定代理(參照圖5的步驟S112)已被執行後，仍會持續等待外部查詢系統所做的結帳可否之判定結果之收訊。但是，詢問部22係亦可在判定代理部27所做的判定被進行後，先將步驟S102中所被進行的詢問一度予以取消，並將判定代理部27所做的判定代理已被執行的結帳要求所涉及之結帳之可否，再次對外部查詢系統進行詢問。

圖6係為本實施形態所述之，藉由結帳伺服器1而被執行的充抵管理處理之概要的流程圖。本流程圖所示的處理，係針對上記說明的結帳處理中判定代理部27所做的判定代理(參照圖5的步驟S112)已被執行的每一結帳要求，以外部查詢系統所做的結帳可否之判定結果已被接收為契機，而被執行。但是，本流程圖中所示的處理所被執行的時序，係不限定於這裡所說明的例子。由於從POS終端5所接收到的結帳要求所對應之處理是已經完成，因此本流程圖所示的處理所被執行的時序，係亦可為判定代理剛被進行之後，亦可為判定代理被進行起經過了一定時間之後。

一旦外部查詢系統所做的結帳可否之判定結果被接收，則結帳要求處理部28係確認已被接收之判定結果的內容(步驟S201)。已被接收之判定結果為可結帳的情況下，結帳要求處理部28，係對外部查詢系統，通知上記說明的結帳處理中的步驟S115中所被執行的結帳之內容(步驟S202)。另一方面，已被接收之判定結果為不可結帳的情況下，則會判定該當結帳要求所涉及之結帳是否已被執行完畢(參照圖5的步驟S115)(步驟S203)，若為結帳已被執行完畢的情況，則充抵部29係使用第二結帳手段，來對結帳要求所涉及之結帳進行充抵(步驟S204)。其後，本流程圖中所示的處理係結束。

若依據上記說明的本實施形態所述的系統，則由結帳伺服器1取代外部查詢系統來進行結帳可否判定並且判定為結帳可能而已經被執行的結帳，在之後被外部查詢系統判定為不可結帳的情況下，則將該當結帳相當額，使用對象使用者的其他結帳手段(使用到點數/電子貨幣/銀行存款等的結帳手段)來進行充抵，藉此就可減輕結帳伺服器1之提供事業者的負擔。

甚至，若依據本實施形態所述的系統，則在結帳伺服器1取代外部查詢系統來進行結帳可否判定之際，基於表示結帳要求之送訊來源的POS終端5所關連之店舖的資訊，而將會成為開始判定代理之觸發的結帳確認加以特定，藉此就可一面實現所定時間內之結帳(防止使用者的機會損失)，同時能夠進行盡可能正確的(原本的)判定。

＜變形例＞ 在上記說明的實施形態中係說明了，於結帳處理中，在等待來自外部查詢系統的結帳可否之判定結果之際，會執行將會成為開始替代處理之觸發的結帳確認加以特定的處理(參照步驟S103至步驟S106)的例子。可是，用來特定會成為開始替代處理之觸發的結帳確認的處理，亦可被省略。

圖7係為變形例所述之，藉由結帳伺服器1而被執行的結帳處理之概要的流程圖。本流程圖所示的處理之中，步驟S301及步驟S302所示的處理之內容，係和參照圖5所說明的步驟S101及步驟S102之處理概略相同，因此省略說明。

在步驟S303及步驟S306中，係等待來自外部查詢系統的結帳可否之判定結果。結帳伺服器1，係直到滿足：外部查詢系統所做的結帳可否之判定結果被接收(步驟S303的YES)、及第一時點T1(在本實施形態中係為，從結帳要求被接收起算經過7秒的時點)已經過(步驟S306的YES)，之任一條件為止，會一直反覆執行步驟S303及步驟S306之處理，而等待來自外部查詢系統的結帳可否之判定結果。此外，此期間中，若藉由結帳確認收訊部23，在來自外部查詢系統的結帳可否之判定結果尚未被接收的狀態下，接收到結帳確認的情況下，則結帳伺服器1係將用來通知正在處理中的回應訊息，對POS終端5進行送訊，以應對之。

在外部查詢系統所做的結帳可否之判定結果是已被接收的情況下(步驟S303的YES)，處理係往步驟S308前進。又，在第一時點T1已經過的情況下(步驟S306的YES)，處理係往步驟S312前進。步驟S308以後所示的處理之內容，係和參照圖5所說明的步驟S108以後的處理概略相同，因此省略說明。

又，在上記說明的實施形態中係說明了，在所定之時間內未獲得來自外部查詢系統的回答的情況下，則進行判定代理所致之結帳可否之判定的例子。可是，在所定之時間內未獲得來自外部查詢系統的回答的情況下，亦可省略判定代理所致之結帳可否之判定，而將結帳要求所涉及之結帳，一律使用第二結帳手段而加以執行。

圖8係為變形例所述之，藉由結帳伺服器1而被執行的結帳處理之概要的流程圖。本流程圖所示的處理之中，步驟S401及步驟S402所示的處理之內容，係和參照圖5所說明的步驟S101及步驟S102之處理概略相同，因此省略說明。又，步驟S403及步驟S406所示的處理之內容，係和參照圖7所說明的步驟S303及步驟S306之處理概略相同，因此省略說明。

在外部查詢系統所做的結帳可否之判定結果是已被接收的情況下(步驟S403的YES)，處理係往步驟S408前進。步驟S408至步驟S411所示的處理之內容，係和參照圖5所說明的步驟S108至步驟S111之處理概略相同，因此省略說明。

又，在第一時點T1已經過的情況下(步驟S406的YES)，處理係往步驟S415前進。結帳要求處理部28，係執行結帳要求所涉及之結帳(步驟S415)，並對結帳要求之送訊來源的POS終端5，將結帳成立，當作對於來自POS終端5之結帳確認的回應訊息而進行通知。然後，充抵部29，係使用第二結帳手段，來對結帳要求所涉及之結帳進行充抵(步驟S416)。亦即，在本實施形態中，在參照圖5所說明的處理之中，步驟S112至步驟S114之判定代理處理係被省略，在所定之時間內未獲得來自外部查詢系統之回答的結帳要求所涉及之結帳，是一律使用第二結帳手段而被執行。其後，本流程圖中所示的處理係結束。

此外，在參照圖8所說明的變形例中，由於省略了判定代理處理，因此充抵管理處理(參照圖6)係可被省略。

1:結帳伺服器 5:POS終端 7:帳號管理伺服器 9:使用者終端 11:CPU 12:ROM 13:RAM 14:記憶裝置 15:通訊單元 21:結帳要求收訊部 22:詢問部 23:結帳確認收訊部 24:結果取得部 25:時序記憶部 26:替代處理開始部 27:判定代理部 28:結帳要求處理部 29:充抵部

[圖1]實施形態所述之系統之構成的概略圖。 [圖2]實施形態所述之系統之硬體構成的概略圖。 [圖3]實施形態所述之結帳伺服器之機能構成的概略圖。 [圖4]實施形態所述之，每種POS系統的結帳確認之送訊時序的圖示。 [圖5]實施形態所述之結帳處理之概要的流程圖。 [圖6]實施形態所述之充抵管理處理之概要的流程圖。 [圖7]變形例所述之結帳處理之概要的流程圖。 [圖8]變形例所述之結帳處理之概要的流程圖。

1:結帳伺服器

21:結帳要求收訊部

22:詢問部

23:結帳確認收訊部

24:結果取得部

25:時序記憶部

26:替代處理開始部

27:判定代理部

28:結帳要求處理部

29:充抵部

Claims (8)

1. 一種資訊處理裝置，係具備：結帳要求收訊手段，係用以接收結帳要求；和詢問手段，係用以將前記結帳要求所涉及之結帳之可否，對負責判定使用到第一結帳手段之結帳之可否的查詢系統，進行詢問；和結果取得手段，係用以取得前記查詢系統所做的前記可否判定之結果；和結帳確認收訊手段，係用以在等待前記查詢系統所做的前記可否判定之結果之期間中，可從前記結帳要求之發行來源，將詢問前記結帳要求所涉及之結帳結果的結帳確認，進行複數次收訊；和替代處理開始手段，係用以在以前記結帳要求為基準而被決定的第一時點以前所被接收的複數個前記結帳確認之中最後之結帳確認被接收到的時序上，令前記第一結帳手段之替代處理被開始。
2. 如請求項1所記載之資訊處理裝置，其中，還具備：記憶手段，係用以將隨著前記結帳要求之發行來源而不同的前記結帳確認之收送訊時序，予以預先記憶；前記替代處理開始手段，係基於前記結帳要求之發行來源所關連的前記收送訊時序，而特定出前記最後之結帳確認。
3. 如請求項1或2所記載之資訊處理裝置，其中，還具備：結帳要求處理手段，係用以基於已被前記結果取得手段所取得之前記可否判定之結果、或前記替代處理之結果，而將前記結帳要求予以處理；前記結帳要求處理手段，係在經過了以前記結帳要求為基準而被決定的第二時點為止都未取得到前記查詢系統所做的前記可否判定之結果的情況下，就令前記結帳要求所涉及之結帳進行錯誤結束；前記第一時點係為，從前記第二時點起，提前了基於前記替代處理之處理時間而被決定之替代處理用時間以上的時序。
4. 如請求項1或2所記載之資訊處理裝置，其中，前記替代處理係為，以接收到前記結帳確認為契機而被執行的處理。
5. 如請求項1或2所記載之資訊處理裝置，其中，還具備：充抵手段，係用以在從前記查詢系統取得前記可否判定之結果之前，使用第二結帳手段，來對前記結帳要求所涉及之結帳進行充抵；前記替代處理開始手段，係令前記充抵手段所致之充抵所需之處理被開始，以作為替代處理。
6. 如請求項5所記載之資訊處理裝置，其 中，還具備：判定代理手段，係用以在從前記查詢系統取得前記可否判定之結果之前，取代前記查詢系統，來判定前記結帳要求所涉及之結帳之可否；前記充抵手段，係針對藉由前記判定代理手段而已被判定為可結帳的前記結帳要求所涉及之結帳，在從前記查詢系統取得了不可結帳之結果的情況下，使用第二結帳手段，來對前記結帳要求所涉及之結帳進行充抵。
7. 一種資訊處理方法，係由電腦來執行：結帳要求收訊步驟，係用以接收結帳要求；和詢問步驟，係用以將前記結帳要求所涉及之結帳之可否，對負責判定使用到第一結帳手段之結帳之可否的查詢系統，進行詢問；和結果取得步驟，係用以取得前記查詢系統所做的前記可否判定之結果；和結帳確認收訊步驟，係用以在等待前記查詢系統所做的前記可否判定之結果之期間中，可從前記結帳要求之發行來源，將詢問前記結帳要求所涉及之結帳結果的結帳確認，進行複數次收訊；和替代處理開始步驟，係用以在以前記結帳要求為基準而被決定的第一時點以前所被接收的複數個前記結帳確認之中最後之結帳確認被接收到的時序上，令前記第一結帳手段之替代處理被開始。
8. 一種程式產品，係用來使電腦發揮機能 而成為：結帳要求收訊手段，係用以接收結帳要求；和詢問手段，係用以將前記結帳要求所涉及之結帳之可否，對負責判定使用到第一結帳手段之結帳之可否的查詢系統，進行詢問；和結果取得手段，係用以取得前記查詢系統所做的前記可否判定之結果；和結帳確認收訊手段，係用以在等待前記查詢系統所做的前記可否判定之結果之期間中，可從前記結帳要求之發行來源，將詢問前記結帳要求所涉及之結帳結果的結帳確認，進行複數次收訊；和替代處理開始手段，係用以在以前記結帳要求為基準而被決定的第一時點以前所被接收的複數個前記結帳確認之中最後之結帳確認被接收到的時序上，令前記第一結帳手段之替代處理被開始。

Images