TW201702952A - 資訊處理裝置、資訊處理方法、記憶媒體 - Google Patents

Abstract

可執行關於商品購入費用之結帳處理操作的第一種使用者與結帳處理操作是被限制的第二種使用者是被管理的電子商務交易系統，可易於掌握第二種使用者的商品購入動向，謀求防止第一種使用者過剩地買東西給第二種使用者的電子商務交易系統之實現。 將第二種使用者投入至購物籃的商品視為購入希望商品而登錄至購入希望商品管理資訊。又，隨應於第二種使用者針對購入希望商品進行了購入操作，使得關於該購入希望商品之購入費用的結帳處理，會基於第一種使用者所做的關於結帳之輸入資訊而被進行。然後，基於與第二種使用者建立關連之第一種使用者之操作，針對與該第二種使用者建立關連之複數第一種使用者之其中至少一名的第一種使用者，進行該第二種使用者的購入希望商品所涉及之結帳處理操作的限制。

Description

資訊處理裝置、資訊處理方法、記憶媒體

本發明係有關於例如網路購物等之電子商務交易中所被使用的資訊處理裝置和其資訊處理方法、實現資訊處理裝置的程式、及記憶程式的記憶媒體，尤其是有關於，在可以執行關於商品購入費用之結帳處理操作的1或2位以上之第一種使用者與前記結帳處理操作是被限制的1或2位以上之第二種使用者之間，由第一種使用者來執行第二種使用者的前記結帳處理操作所需之技術。

〔先前技術文獻〕 〔專利文獻〕

[專利文獻1]日本特開2011-8810號公報

作為電子商務交易之一形態，透過所謂網路購物這類網際網路等之通訊網路而購入商品，係為一般所進行。

作為可進行網路購物的網站，係有所謂被熟知為虛擬商店街的這種，有複數店舖開店之形態的網站(以下記作 「購物網站」)。在購物網站中一般會讓使用者登錄姓名、地址、信用卡號等之資訊，將進行過登錄的使用者當作會員來管理。

在購物網站中，係也有將可執行關於商品購入費用之結帳處理操作的第一種使用者、與結帳處理操作是被限制的第二種使用者建立關連而管理的網站。

例如，身為第二種使用者係為子女(例如未成年)，身為第一種使用者係為子女的父母或祖父、祖母等，將這些使用者視為家族會員等而建立關連進行群組管理。

此處，關於第二種使用者進行了購入操作之商品的購入費用之結帳，係料想會是在與該第二種使用者建立關連的第一種使用者之中，以認可此事的第一種使用者的名義來進行。

此時，作為第一種使用者的認可手續係可想成例如，在第二種使用者的購入手續畫面上，由第一種使用者輸入自己的使用者ID或密碼這樣的手續。但是，設計成如此的認可手續的情況下，第一種使用者係必須要每次都親自介入第二種使用者的購入手續，而很麻煩。

為了避免產生此種認可手續的麻煩，也想到了，第二種使用者進行了購入操作之商品係視為第一種使用者所致之購入商品，以與該第二種使用者建立關連之第一種使用 者的名義自動進行結帳。

然而，若採用如此視為第一種使用者所致之購入商品的手法，則無論是否為第二種使用者的購入商品，都可能被視為第一種使用者的購入商品，而會有難以掌握身為第二種使用者例如子世代的商品購入動向之虞。

又，以進行過認可的第一種使用者的名義來進行關於第二種使用者之購入商品的費用結帳時，若對同一位第二種使用者建立關連的第一種使用者是存在複數位，則也考慮到至少其中一位第一種使用者對該第二種使用者過剩地買東西給他的案例。例如，考量上記所例示的第一種使用者=父母、祖父、祖母，第二種使用者=子女的情況下，祖父或祖母針對子女的購入商品頻繁地進行結帳之認可，而過剩地買東西給子女的案例。這對身為父母的第一種使用者而言，是在子女的教育上想要避免的事態。

本發明係有鑑於上記事情而研發，目的在於，可執行關於商品購入費用之結帳處理操作的第一種使用者與結帳處理操作是被限制的第二種使用者是被管理的電子商務交易系統，可易於掌握第二種使用者的商品購入動向，可以謀求防止第一種使用者過剩地買東西給第二種使用者的電子商務交易系統之實現。

本發明所述之資訊處理裝置，係在可以執行 關於商品購入費用之結帳處理操作的1或2位以上之第一種使用者與前記結帳處理操作是被限制的1或2位以上之第二種使用者之間，由第一種使用者來執行第二種使用者的前記結帳處理操作所需之電子商務交易系統中的資訊處理裝置，其中，具備：關連建立關係資訊記憶部，係記憶表示第一種使用者與第二種使用者之關連建立關係的關連建立關係資訊；和商品登錄部，係隨著每位使用者進行了往購物籃之商品投入操作，而將該已被投入操作之商品當作購入希望商品而登錄至購入希望商品管理資訊；和商品/使用者關連建立部，係在進行了前記商品投入操作的使用者是第二種使用者的情況下，參照前記關連建立關係資訊，對與該第二種使用者建立關連的第一種使用者，將該第二種使用者的購入希望商品予以建立關連；和輸入資訊受理部，係將有關於第二種使用者的購入希望商品之購入費用的第一種使用者所做的關於結帳之輸入資訊，予以受理；和結帳控制部，係隨應於第二種使用者針對已受理前記輸入資訊之第二種使用者的購入希望商品而進行了購入操作，而進行控制，使得有關於該第二種使用者的購入希望商品之購入費用的結帳處理，是基於第一種使用者所做的關於結帳之輸入資訊，而被進行；和限制設定部，係基於與第二種使用者建立關連之第一種使用者之操作，針對與該第二種使用者建立關連之複數第一種使用者之其中至少一名的第一種使用者，設定該第二種使用者的購入希望商品所涉及之前記結帳處理操作之限制資訊；和限制控制 部，係基於前記限制資訊，來進行控制，以使得第一種使用者所做的第二種使用者的購入希望商品所涉及之前記結帳處理操作會被限制。

若依據上記構成，則藉由第二種使用者的購入希望商品管理資訊，就可掌握作為第二種使用者的特定使用者層的商品購入動向。

又，藉由限制控制部，就可防止第一種使用者(例如祖父等)係背地裡過剩地買東西給第二種使用者(例如子女)。

於上記本發明所述之資訊處理裝置，其中，具備：通知控制部，係隨應於第二種使用者進行了往購物籃之商品投入操作，而進行控制，以使得對與該第二種使用者建立關連之第一種使用者的通知會被進行，較為理想。

藉此，就可將有第二種使用者所做的商品投入操作的事實，迅速通知給第一種使用者。

於上記本發明所述之資訊處理裝置，其中，前記通知控制部，係作為前記通知，是進行控制，以使得催促關於前記第二種使用者的購入希望商品之購入費用之結帳的通知會被進行，較為理想。

藉此，就可謀求對第一種使用者的通知內容之明確化。又，對第二種使用者將複數第一種使用者建立關連時，係變成逆競標的舉動。

於上記本發明所述之資訊處理裝置，其中， 具備：商品提示部，係將每位使用者進行了往購物籃之商品投入操作的購入希望商品，提示給該使用者；對第一種使用者的前記商品提示部，係在對於該第一種使用者已經有第二種使用者的購入希望商品被建立關連的情況下，則將該第一種使用者的購入希望商品與該第二種使用者的購入希望商品，予以提示，較為理想。

藉此，第一種使用者就可在自己的購物籃中確認第二種使用者的購入希望商品。

於上記本發明所述之資訊處理裝置，其中，具備：通知資訊提示部，係在已經與第一種使用者建立關連之第二種使用者的購入希望商品之中針對已經受理了第一種使用者所做的前記關於結帳之輸入資訊的購入希望商品，將已經受理了前記關於結帳之輸入資訊之意旨、及用來通知前記關於結帳之輸入資訊是已被受理之第一種使用者的資訊，提示給與進行了該購入希望商品之商品投入操作的第二種使用者建立關連的第一種使用者，較為理想。

藉此，對關於結帳之輸入資訊是已被受理的第一種使用者本人而言，就可確認關於自身之結帳之輸入資訊是否已經被接受。

又，在對第二種使用者有複數第一種使用者被建立關連的情況下，對關於結帳之輸入資訊是已被受理以外的第一種使用者，其他第一種使用者所做的關於結帳之輸入資訊是已被受理之意旨，及用來通知關於結帳之輸入資訊是已被受理之第一種使用者的資訊，會被提示。

於上記本發明所述之資訊處理裝置，其中，具備：條件資訊設定部，係基於與該第二種使用者建立關連之第一種使用者之操作，來設定不需認可商品條件資訊，其係用來將針對第二種使用者的購入希望商品是不需要第一種使用者所做的結帳之認可的商品，進行條件賦予所需；前記結帳控制部，係進行控制，以使得針對基於前記不需認可商品條件資訊而判定為符合不需要前記認可之商品的第二種使用者的購入希望商品，無論前記認可之有無，都是以與該第二種使用者建立關連之第一種使用者之名義，來進行前記結帳處理，較為理想。

藉此，針對第一種使用者認為不需要認可的商品，第一種使用者就可不必一一進行認可。

又，本發明所述之資訊處理方法，係一種資訊處理方法，係在可以執行關於商品購入費用之結帳處理操作的1或2位以上之第一種使用者與前記結帳處理操作是被限制的1或2位以上之第二種使用者之間，由第一種使用者來執行第二種使用者的前記結帳處理操作所需之電子商務交易系統中的資訊處理裝置所執行的資訊處理方法，其係執行：商品登錄步驟，係隨著每位使用者進行了往購物籃之商品投入操作，而將該已被投入操作之商品當作購入希望商品而登錄至購入希望商品管理資訊；和商品/使用者關連建立步驟，係在進行了前記商品投入操作的使用者是第二種使用者的情況下，參照表示第一種使用者與第二種使用者之關連建立關係的關連建立關係資訊，對 與該第二種使用者建立關連的第一種使用者，將該第二種使用者的購入希望商品予以建立關連；和輸入資訊受理步驟，係將有關於第二種使用者的購入希望商品之購入費用的第一種使用者所做的關於結帳之輸入資訊，予以受理；和結帳控制步驟，係隨應於第二種使用者針對已受理前記輸入資訊之第二種使用者的購入希望商品而進行了購入操作，而進行控制，使得有關於該第二種使用者的購入希望商品之購入費用的結帳處理，是基於第一種使用者所做的關於結帳之輸入資訊，而被進行；和限制設定步驟，係基於與第二種使用者建立關連之第一種使用者之操作，針對與該第二種使用者建立關連之複數第一種使用者之其中至少一名的第一種使用者，設定該第二種使用者的購入希望商品所涉及之前記結帳處理操作之限制資訊；和限制控制步驟，係基於前記限制資訊，來進行控制，以使得第一種使用者所做的第二種使用者的購入希望商品所涉及之前記結帳處理操作會被限制。

即使藉由此種資訊處理方法，也可獲得和上記本發明所述之資訊處理裝置同樣的作用。

甚至，本發明所述之程式，係為令資訊處理裝置執行處理以執行上記資訊處理方法的程式。

又甚至，本發明所述之記憶媒體，係記憶上記程式。藉由這些程式或記憶媒體而實現上記的資訊處理裝置。

若依據本發明，則可執行關於商品購入費用之結帳處理操作的第一種使用者與結帳處理操作是被限制的第二種使用者是被管理的電子商務交易系統，可易於掌握第二種使用者的商品購入動向，可以謀求防止第一種使用者過剩地買東西給第二種使用者的電子商務交易系統之實現。

1、1A‧‧‧網路系統

2‧‧‧網路

3、3A‧‧‧購物網站營運系統

3a、3aA‧‧‧購物伺服器

3c‧‧‧第一種使用者DB(資料庫)

3d‧‧‧第二種使用者DB

3e‧‧‧第一放入購物籃商品DB

3f‧‧‧第二放入購物籃商品DB

3g‧‧‧關連建立資訊DB

3h‧‧‧限制資訊DB

3i‧‧‧不需認可商品資訊DB

4‧‧‧使用者終端

5‧‧‧店舖終端

6‧‧‧卡片公司伺服器

101‧‧‧CPU

F1‧‧‧商品登錄處理部

F2‧‧‧商品/使用者關連建立處理部

F3‧‧‧第二種使用者商品提示處理部

F4‧‧‧輸入資訊受理處理部

F5‧‧‧結帳控制處理部

F6‧‧‧限制設定處理部

F7‧‧‧限制控制處理部

F8‧‧‧不需認可商品設定處理部

[圖1]第1實施形態的網路系統之例子的圖示。

[圖2]第一種使用者DB(資料庫)之儲存資訊的例示圖。

[圖3]第二種使用者DB之儲存資訊的例示圖。

[圖4]構成實施形態之網路系統的電腦裝置之硬體構成的區塊圖。

[圖5]將第1實施形態之資訊處理裝置所具有的第二種使用者購入希望商品之購入費用結帳所涉及之機能予以區塊化表示的機能區塊圖。

[圖6]第一種使用者購物籃網頁之例子的圖示。

[圖7]第二種使用者購物籃網頁之例子的圖示。

[圖8]關連建立資訊DB中所被儲存之商品/使用者關連建立資訊之例子的圖示。

[圖9]第二種使用者購入希望商品所被提示之第一種使用者購物籃網頁之例子的圖示。

[圖10]購入鈕是已被活化的第二種使用者購物籃網頁之例子的圖示。

[圖11]認可確認資訊所被提示之第一種使用者購物籃網頁之例子的圖示。

[圖12]限制資訊設定網頁之例子的圖示。

[圖13]限制資訊DB中所被儲存之限制管理資訊之例子的圖示。

[圖14]限制資訊之設定所涉及之處理的流程圖。

[圖15]第二種使用者所做的往購物籃之商品投入所對應之處理的流程圖。

[圖16]第一種使用者購物籃網頁之提示所涉及之處理的流程圖。

[圖17]認可鈕之操作所對應之處理的流程圖。

[圖18]第二種使用者所做的購入操作所對應之處理的流程圖。

[圖19]第2實施形態的網路系統之例子的圖示。

[圖20]將第2實施形態之資訊處理裝置所具有的第二種使用者購入希望商品之購入費用結帳所涉及之機能予以區塊化表示的機能區塊圖。

[圖21]不需認可商品資訊DB中所被儲存之不需認可商品管理資訊之例子的圖示。

[圖22]第2實施形態中的第二種使用者所做的購入操作所對應之處理的流程圖。

[圖23]第2實施形態中的第二種使用者所做的購入 操作所對應之處理的流程圖。

以下，按照以下順序來說明實施形態。

<1.第1實施形態>

〔1-1.網路系統之概要〕

〔1-2.電腦裝置之硬體構成〕

〔1-3.第二種使用者購入希望商品之購入費用結帳所涉及之機能之概要〕

〔1-4.處理程序〕

〔1-5.第1實施形態的總結〕

<2.第2實施形態>

〔2-1.網路系統之概要〕

〔2-2.第2實施形態的機能之概要〕

〔2-3.處理程序〕

〔2-4.第2實施形態的總結〕

<3.程式及記憶媒體>

<4.變形例>

<1.第1實施形態> 〔1-1.網路系統之概要〕

圖1中圖示了，第1實施形態的網路系統1之例子。網路系統1，係成為EC(EC：electronic commerce(電子商務交易))系統而發揮機能。

網路系統1係被構成為，例如，透過作為網際網路之網路2，而可讓購物網站營運系統3、複數使用者終端4、4...、複數店舖終端5、5...、及卡片公司伺服器6相互通訊。

使用者終端4，係為具備網頁瀏覽器的電腦裝置。作為使用者終端4係可舉出例如高機能行動電話(智慧型手機)或行動電話機、攜帶型資訊終端(PDA)、攜帶型或桌上型的個人電腦(PC)等，但使用者終端4的種類並不限定於這些。

使用者終端4，係將HTTP(Hypertext Transfer Protocol)請求發送至購物網站營運系統3中的購物伺服器3a或卡片公司伺服器6等，以要求網頁或所定之處理。又，使用者終端4係將隨應於HTTP請求而被送來的網頁予以接收並顯示在網頁瀏覽器上。藉此，使用者係可瀏覽或操作所望之網頁。

購物網站營運系統3係具備：分別由電腦裝置所構成的購物伺服器3a、商品DB(資料庫)3b、第一種使用者DB3c、第二種使用者DB3d、第一放入購物籃商品DB3e、第二放入購物籃商品DB3f、關連建立資訊DB3g、及限制資訊DB3h。這些各裝置，係透過例如LAN(Local Area Network)等之網路而可彼此通訊。

購物伺服器3a，係基於從使用者終端4所送來的HTTP請求而進行各種處理。例如，執行各種網頁(例如商品網頁、購物籃網頁、訂購網頁等)之生成及送 訊、或使用者所做的購入操作(訂購確定操作)所相應之購入處理等。

在網路系統1中，藉由購物伺服器3a而把虛擬商店街之網站(以下記作「購物網站」)，提供給使用者(使用者終端4之使用者)。在購物網站內係有複數店舖(虛擬商店街之加盟店)存在。各店舖之工作人員將自家店舖之商品透過身為店舖終端5之電腦裝置而加以登錄，藉此，各式各樣之店舖的各式各樣之商品，就被上傳至購物網站上。使用者係可由使用者終端4存取購物網站而購入所望之商品。

此外，本發明中的所謂「商品」，係不限於有體物，包含例如旅館或飯店等之宿泊設施所提供的宿泊服務等之服務、或電子書籍等之無體物。

於購物網站營運系統3中，商品DB3b中係記憶著，透過店舖終端5而被登錄的商品的相關資訊。具體而言，與用來識別商品所需之識別元也就是商品ID建立對應，而記憶著商品名、商品的類型、商品的影像、規格、商品介紹之摘要文等之商品資訊、或廣告資訊等。又，商品DB3b中係還記憶有：以HTML(HyperText Markup Language)、XML(Extensible Markup Language)等之標記語言等所撰寫而成的商品網頁之檔案(網頁資料)等。

藉由此種商品DB3b，例如基於輸入關鍵字等而可進行商品檢索等。

此處，使用者係在利用購物網站時，可以向購物網站營運系統3進行會員登錄。會員登錄之際，至少使用者係將使用者ID(使用者識別資訊)、密碼、姓名、郵件位址、商品之寄送目的地資訊(地址資訊)等之必要資訊，予以登錄。使用者係藉由使用已經登錄的使用者ID而登入至購物網站，在購物網站中購入商品之際關於在上記必要資訊之中在購入時所必需的資訊(例如姓名、地址、信用卡號)，就可省去進行再度輸入的麻煩。

此處，於本實施形態的購物網站中，可將身為會員的使用者，分成可執行關於商品購入費用之結帳處理操作的第一種使用者和該結帳處理操作是被限制的第二種使用者而加以管理。此外，所謂結帳處理操作，係指為了使結帳處理被執行所必需的操作，具體而言，可舉出例如，結帳方法的指定操作、或將自己設成結帳名義的購入之確定操作等。

又，本實施形態的購物網站中，可將所要之第一種使用者與第二種使用者建立關連而做群組管理。

本例中，第二種使用者，係由已經登錄會員的第一種使用者，透過所定之登錄畫面(網頁)而對購物網站進行登錄。在購物網站中，係如此進行過登錄手續的第一種使用者，與藉由該登錄手續而已被登錄之第二種使用者是被當成隸屬於同一群組的使用者，而被建立關連而管理。

又，在本例中，對同一第二種使用者係可將複數第一種使用者建立關連。例如，身為父親的第一種使用者將自 己的子女也就是第二種使用者藉由上記登錄手續做了登錄的情況下，作為對該子女建立關連的群組使用者(第一種使用者)，可以不只父親而還可把母親、祖父、祖母等，做追加性關連建立。

此外，對同一第二種使用者建立關連的第一種使用者的追加申請，係由進行了該第二種使用者之登錄手續的第一種使用者來進行，或亦可由希望追加的第一種使用者自己來進行申請均可。

在第一種使用者DB3c中係記憶，關於第一種使用者的資訊。

又，在第二種使用者DB3d中係記憶，關於第二種使用者的資訊。

圖2係第一種使用者DB3c之儲存資訊的例示圖。

如圖示，於第一種使用者DB3c中，係按照第一種使用者的每一使用者ID，將密碼、姓名、郵件位址、地址之各資訊、及信用卡資訊，建立對應而記憶。作為信用卡資訊係記憶有：卡號、名義人(卡片名義人之姓名)、及有效期限之各資訊。

圖3係第二種使用者DB3d之儲存資訊的例示圖。

於第二種使用者DB3d中，係按照第二種使用者的每一使用者ID，將密碼、姓名、郵件位址、地址之各資訊、及關連建立使用者的使用者ID，建立對應而記憶。 關連建立使用者的使用者ID，係意味著已經與第二種使用者建立關連的第一種使用者的使用者ID。

此外，如此對第二種使用者的每一使用者ID，把已經與該第二種使用者建立關連的第一種使用者的使用者ID建立對應而成的第二種使用者DB3d之儲存資訊，係作為用來表示第一種使用者與第二種使用者之關連建立關係的「關連建立關係資訊」而發揮機能。

於圖1中，購物網站營運系統3所具備的第一放入購入籃商品DB3e，係用來管理第一種使用者投入至購物籃之商品所需之資訊(後述的第一種購入希望商品管理資訊I1)所被記憶的DB，第二放入購物籃商品DB3f，係用來管理第二種使用者投入至購物籃之商品所需之資訊(後述的第二種購入希望商品管理資訊I2)所被記憶的DB。

於購物網站中，一旦使用者在登入狀態下操作被設在商品網頁中的購物籃投入鈕，則該商品網頁之刊載商品就被投入至該使用者的購物籃。一旦使用者係在非登入狀態下操作上記之購物籃投入鈕，則會被要求登入，一旦進行登入，則該商品網頁之刊載商品就被投入至該使用者的購物籃。

如後述，於本例的購物網站中，商品的購入操作，係先將該商品投入至購物籃然後才進行。一旦針對已被使用者投入至購物籃之商品的購入操作被進行，則該商品的購入手續就完成(該商品之訂購係確定)。

此外，關於第一放入購物籃商品DB3e、第二放入購物籃商品DB3f中所被儲存之資訊，係於後述。

又，在購物網站營運系統3中係具備有關連建立資訊DB3g、限制資訊DB3h，但關於這些DB中所被儲存之資訊，係於後述。

購物伺服器3a，係一旦藉由使用者而進行了商品之購入操作，則執行關於被進行該購入操作的商品(以下記作「購入對象商品」)的購入處理。

於購入處理中，購物伺服器3a，係基於購入對象商品之價格的資訊來計算該購入對象商品之購入費用(結帳金額)，同時，進行控制，以使得該購入費用所致之結帳處理(在本例中係為卡片結帳)會被進行。具體而言，於本例中，是將所計算的購入費用所致之訂購資訊(含有購入費用或身為結帳者的使用者之信用卡號等之資訊)，對購入對象商品的販售來源店舖之店舖終端5，進行送訊。

接收到訂購資訊的店舖終端5，係將該訂購資訊發送至卡片公司伺服器6而要求結帳處理。

卡片公司伺服器6，係進行卡片資訊之管理、及指定了卡號的授信核對或銷售額請款等所相對的處理。

具體而言，卡片公司伺服器6，係一旦從店舖終端5接收上記的訂購資訊，就基於該訂購資訊中所含之卡號而進行授信核對，若為授信OK，則將含有授信認可號碼的授信認可通知，發送至店舖終端5，並且，將信用卡的卡號所涉及之銷售額的速報資訊(利用日、利用金額等)， 通知給身為結帳者的使用者的郵件位址。

店舖終端5，係在所定之銷售額請款時序上，向卡片公司伺服器6發送以信用卡的卡號與授信認可號碼為基礎的銷售額請款。

卡片公司伺服器6，係基於該當銷售額請款，而對符合的卡號，將與符合之授信認可號碼建立關連的結帳金額，當作銷售額而予以登錄。藉由進行如此的銷售額登錄，在其後的所定之時序上，會從該當卡號所建立關連的戶頭，執行結帳金額之扣款處理。

此外，於圖1中，想定網路2之構成係有多種例子。例如，以網際網路為首，可想定為：企業內網路、企業間網路、LAN(Local Area Network)、CATV(Community Antenna TeleVision)通訊網、虛擬專用網(Virtual Private Network)、電話線路網、移動體通訊網、衛星通訊網等。

又，關於構成網路2之全部或部分的傳輸媒體也被想定有多種例子。例如：IEEE(Institute of Electrical and Electronics Engineers)1394、USB(Universal Serial Bus)、電力線載送、電話線等之有線也好、IrDA(Infrared Data Association)這類紅外線、藍牙(註冊商標)、802.11無線、行動電話網、衛星線路、地表波數位網等之無線都可利用。

〔1-2.電腦裝置之硬體構成〕

圖4中圖示了，以圖1所示的購物伺服器3a為首的構成各裝置(商品DB3b、第一種使用者DB3c、第二種使用者DB3d、第一放入購物籃商品DB3e、第二放入購物籃商品DB3f、關連建立資訊DB3g、限制資訊DB3h、使用者終端4、店舖終端5、卡片公司伺服器6)的電腦裝置之硬體構成。

於圖4中，電腦裝置之CPU(Central Processing Unit)101，係依照ROM(Read Only Memory)102中所記憶之程式、或從記憶部108載入至RAM(Random Access Memory)103之程式，而執行各種處理。RAM103中係還適宜記憶著，CPU101執行各種處理時所必須之資料等。

CPU101、ROM102、及RAM103，係透過匯流排104而彼此連接。該匯流排104上係還連接有輸出入介面105。

輸出入介面105上係被連接有鍵盤、滑鼠、觸控面板等所成之輸入裝置106、LCD(Liquid Crystal Display)、CRT(Cathode Ray Tube)、有機EL(Electroluminescence)面板等所成之顯示器(顯示裝置)，以及揚聲器等所成之輸出裝置107、HDD(Hard Disk Drive)或快閃記憶體裝置等所構成的記憶部108、與外部裝置之間進行相互通訊所需之通訊部109。

輸出入介面105上係還可因應需要而連接有媒體驅動器110，可適宜裝著磁碟、光碟、光磁碟、或半導體記憶 體等之可移除式媒體111，對可移除式媒體111進行資訊之寫入或讀出。

在如此電腦裝置中，藉由通訊部109所致之通訊而進行資料或程式之上傳、下載，或可透過可移除式媒體111進行資料或程式之收授。

CPU101基於各種程式來進行處理動作，尤其是在身為購物伺服器3a的電腦裝置中，就會執行以下所說明的資訊處理或通訊。

〔1-3.第二種使用者購入希望商品之購入費用結帳所涉及之機能之概要〕

圖5係購物伺服器3a所實現的機能之中，將第二種使用者購入希望商品的購入費用結帳所涉及之機能予以區塊化而表示的機能區塊圖。

如圖5所示，購物伺服器3a中，作為機能區塊，是具備有：商品登錄處理部F1、商品/使用者關連建立處理部F2、第二種使用者商品提示處理部F3、輸入資訊受理處理部F4、結帳控制處理部F5、限制設定處理部F6、及限制控制處理部F7。

商品登錄處理部F1，係隨應於使用者進行了該使用者往購物籃之商品投入操作，而將該已被投入操作之商品當作該使用者的購入希望商品而登錄至購入希望商品管理資訊。

具體而言，商品登錄處理部F1，係在第一種使用者 進行了該第一種使用者的往購物籃之商品投入操作的情況下，隨應於此，將該已被投入操作之商品當作該第一種使用者的購入希望商品而登錄至第一種購入希望商品管理資訊I1。

雖然圖示省略，但第一種購入希望商品管理資訊I1係為，按照第一種使用者的每一使用者ID，將被該使用者ID所界定之第一種使用者投入至購物籃的商品(但僅限於後述的購入操作尚未被進行的商品)的商品ID予以建立對應而成的資訊。商品登錄處理部F1，係隨應於第一種使用者進行了該第一種使用者往購物籃之商品投入操作，而將該已被投入操作之商品的商品ID，與第一種購入希望商品管理資訊I1中的進行過該投入操作之第一種使用者的使用者ID，建立對應而登錄。

圖1中所示的第一放入購入籃商品DB3e，係為如此的第一種購入希望商品管理資訊I1所被儲存的DB。

圖6係圖示了，刊載第一種使用者往購物籃的投入商品的網頁(以下記作「第一種使用者購物籃網頁pb1」)的例子。

如圖示，第一種使用者購物籃網頁pb1中，除了刊載第一種使用者所投入的商品之資訊，還按照每一商品而提示有購入鈕b1。第一種使用者，係在有想要進入購入手續的商品時，則操作該商品的購入鈕b1(例如點選操作或輕點操作等之所定操作)。

此處，購物伺服器3a，係一旦購入鈕b1被操 作，則對進行了該操作的第一種使用者，提示購入手續畫面。在該購入手續畫面中，商品購入所必須之資訊(前述的姓名、地址，信用卡號資訊等)之輸入，係被要求。此外，如前述，此時的必要資訊之輸入，係若第一種使用者是處理登入狀態則可省略。在購入手續畫面，設有用來確定係購入所需之確定鈕，第一種使用者係藉由操作該確定鈕，就可向購物伺服器3a要求執行前述的購入處理。

此外，在本例中，上記確定鈕之操作係相當於「購入操作」。

本說明書中所謂的「購入操作」，係意味著如此確定購入的操作。

於本例中，購物伺服器3a，係第一種使用者每次進行往購物籃之新商品投入時，就將第一種使用者購物籃網頁pb1，提示給該第一種使用者。又，購物伺服器3a，係即使在購物網站中的例如頂層網頁等之所定之網頁上所被設置的「購物籃」鈕被操作之際，仍會向進行了該操作的第一種使用者，提示第一種使用者購物籃網頁pb1。

第一種使用者投入至購物籃的商品，係可被視為該第一種使用者所希望購入的商品，因此針對該商品，以下係也記作「第一種使用者購入希望商品」。

又，第一種使用者購物籃網頁pb1中所被提示的資訊，係可說成是第一種使用者購入希望商品的清單資訊，以下也記作「第一種使用者購入希望商品清單」。

又，商品登錄處理部F1，係在第二種使用者進行了該第二種使用者的往購物籃之商品投入操作的情況下，隨應於此，將該已被投入操作之商品當作該第二種使用者的購入希望商品而登錄至第二種購入希望商品管理資訊I2。

第二種購入希望商品管理資訊I2係為，按照第二種使用者的每一使用者ID，將被該使用者ID所界定之第二種使用者投入至購物籃的商品(此情況下也是僅限於購入操作尚未被進行的商品)的商品ID予以建立對應而成的資訊。商品登錄處理部F1，係隨應於第二種使用者進行了該第二種使用者的往購物籃之商品投入操作，而將該已被投入操作之商品的商品ID，與第二種購入希望商品管理資訊I2中的進行過該投入操作之第二種使用者的使用者ID，建立對應而登錄。

圖1中所示的第二放入購入籃商品DB3f，係為如此的第二種購入希望商品管理資訊I2所被儲存的DB。

此外，以下，被第二種使用者投入至購物籃的商品，係也記作「第二種使用者購入希望商品」。

圖7係圖示了，刊載第二種使用者往購物籃的投入商品的網頁(以下記作「第二種使用者購物籃網頁pb2」)的例子。

第二種使用者購物籃網頁pb2中，除了刊載第二種使用者所投入的商品之資訊，還按照每一商品而提示有購入鈕b1。

此處，在本實施形態中，第二種使用者係為被限制結帳處理操的使用者，因此針對第二種使用者投入至購物籃的商品，只有在與該第二種使用者建立關連的第一種使用者，針對該商品的購入費用進行了關於結帳之輸入的情況下，才將第二種使用者所做的購入操作設成可行。具體而言，在本例中，只有在針對該商品之購入費用進行了結帳之認可的情況下，才將第二種使用者所做的購入操作設成可行。

因此，購物伺服器3a，係第二種使用者購物籃網頁pb2中所刊載的商品之中針對上記未獲得認可的商品，係如圖示作為購入鈕b1而提示非活化狀態(無法操作之狀態：不可遷移至購入手續畫面的狀態)的購入鈕b1。

此外，即使關於第二種使用者購物籃網頁pb2也是，每次第二種使用者往購物籃進行新的商品投入操作時就對該第二種使用者做提示，並且，當上記「購物籃」鈕被操作時，也會對進行了該操作的第二種使用者做提示。

此處，於本例的購物網站中，第一種使用者、第二種使用者的帳號係分別為獨立的帳號。因此，第一種使用者，作為其商品的投入操作是只能夠往自己的購物籃進行投入操作，又，關於購入操作也是，只能夠針對自己的購物籃中的投入商品而為之，關於與自己建立關連的第二種使用者的購物籃中所被投入的商品，是無法進行購入操作。

同樣地，第二種使用者，作為其商品的投入操作是只能夠往自己的購物籃進行投入操作，又，關於購入操作也是，只能夠針對自己的購物籃中所被投入之商品而為之。

回到圖5說明。

商品/使用者關連建立處理部F2，係基於表示第一種使用者與第二種使用者之關連建立關係的關連建立關係資訊，將第二種使用者購入希望商品，與進行了該第二種使用者購入希望商品之投入操作的第二種使用者所關連之第一種使用者，建立關連。

具體而言，商品/使用者關連建立處理部F2，係一旦第二種使用者針對新的商品進行了往購物籃的投入操作，則將該已被投入操作之商品的商品ID加以取得，同時，將與進行了該投入操作之第二種使用者建立關連的第一種使用者的使用者ID，基於第二種使用者DB的儲存資訊(關連建立關係資訊：參照圖3)而加以取得。然後，將如此所取得的商品ID與第一種使用者的使用者ID建立對應而儲存至圖1所示的關連建立資訊DB3g。

圖8係圖示了，藉由如上記的作為商品/使用者關連建立處理部F2之機能而在關連建立資訊DB3g中所被建構的商品/使用者關連建立資訊I3之例子。

如圖示，於商品/使用者關連建立資訊I3中，係對第二種使用者已經投入至購物籃的商品的每一商品ID，把與該第二種使用者建立關連之第一種使用者的使用者ID，建立對應。

雖然在本例的商品/使用者關連建立資訊I3中，係可按照每一商品ID而將認可者使用者ID、資訊消去預定日之資訊予以建立對應，但關於這些認可者使用者ID、資訊消去預定日係於後述。

此處，本例中的購物伺服器3a，係隨應於第二種使用者針對新的商品進行了往購物籃之投入操作，而進行控制，以使得對與該第二種使用者建立關連之第一種使用者的通知，會被進行。作為該通知係為，對第一種使用者，至少表示與該第一種使用者建立關連之第二種使用者係進行了商品投入操作之意旨的通知即可。

在本例中，作為該通知，係使得用來催促第二種使用者針對新進行投入操作之商品(第二種使用者購入希望商品)之購入費用的結帳的通知，會被進行。具體而言，例如「○○先生(第二種使用者)正在針對商品××而要求結帳。」等，使得含有用來向第一種使用者催促結帳所需之文字資訊的通知，會被進行。

藉此，就可謀求對第一種使用者的通知內容之明確化。又，對第二種使用者將複數第一種使用者建立關連時，係變成逆競標的舉動，而可提供娛樂性。

此外，在本例的情況下，上記的通知，係基於第一種使用者DB3c中所被儲存之郵件位址之資訊而向對應的第一種使用者發送電子郵件，而加以實現。

於圖5中，第二種使用者商品提示處理部F3，係於第一種使用者購物籃網頁pb1(第一種使用者購 入希望商品清單)中，將商品/使用者關連建立處理部F2已經對第一種使用者(開啟了第一種使用者購物籃網頁pb1的第一種使用者)建立了關連的第二種使用者購入希望商品，予以提示。

亦即，於本實施形態中，一旦第二種使用者往購物籃進行商品投入，則該商品係會在與該第二種使用者建立關連之第一種使用者的第一種使用者購物籃網頁pb1中被提示。

圖9係圖示了，第二種使用者購入希望商品所被提示之第一種使用者購物籃網頁pb1之例子。

第二種使用者商品提示處理部F3，係在有第一種使用者所做的第一種使用者購物籃網頁pb1之提示要求時，若與該第一種使用者建立關連的第二種使用者係為存在，則基於關連建立資訊DB3g中所被儲存之商品/使用者關連建立資訊I3(圖8)，來判定與該第一種使用者建立關連之第二種使用者購入希望商品的有無，若有該第二種使用者購入希望商品時，則將刊載了該第二種使用者購入希望商品的第一種使用者購物籃網頁pb1，予以提示。

在圖9中，係圖示了，要求了第一種使用者購物籃網頁pb1之提示的第一種使用者，係被假設為往購物籃之商品投入狀態是處於之前圖6之狀態的第一種使用者，且與該第一種使用者建立關連之第二種使用者係如之前圖7所示般地進行了往購物籃之商品投入時所被提示的第一種使用者購物籃網頁pb1之例子。

於此情況下的第一種使用者購物籃網頁pb1中，除了圖6所示的商品之資訊及購入鈕b1以外，還有圖7所示的商品之資訊，亦即第二種使用者已經投入至購物籃的商品之資訊，會被提示。甚至，對於這些第二種使用者所投入至購物籃之商品(第二種使用者購入希望商品)之資訊，還提示有認可鈕b2。

第一種使用者，係藉由操作認可鈕b2，而可對購物伺服器3a進行，認可關於該認可鈕b2所被提示之第二種使用者購入希望商品之購入費用之結帳之意旨的輸入。

輸入資訊受理處理部F4，係將有關於第二種使用者購入希望商品之購入費用的第一種使用者所做的關於結帳之輸入資訊，予以受理。亦即，在本例中，於第二種使用者購入希望商品所被提示的第一種使用者購物籃網頁pb1(第一種使用者購入希望商品清單)中，關於該已被提示之第二種使用者購入希望商品之購入費用的結帳是否認可所涉及之輸入資訊會加以受理，具體而言，是將第一種使用者購物籃網頁pb1中所被提示之認可鈕b2的操作輸入資訊，予以受理。

本例的購物伺服器3a，係在藉由第一種使用者操作了認可鈕b2的情況下(亦即針對第二種使用者購入希望商品之購入費用的關於結帳之輸入資訊是已被受理的情況下)，係進行控制，以使得對第二種使用者的通知，會被進行。具體而言，對將認可鈕b2是已被操作之商品投入至購物籃的第二種使用者，針對該商品之購入費 用的結帳是已被認可之意旨、及關於表示進行了該認可之第一種使用者之資訊的通知，會被進行。

藉此，第二種使用者係可得知，針對自己已經投入至購物籃之商品已經獲得第一種使用者所做之認可的意旨、以及進行了認可的第一種使用者。

此外，在本例的情況下，上記的通知，係基於第二種使用者DB3d中所被儲存之郵件位址之資訊而向對應的第二種使用者發送電子郵件，而加以實現。

又，本例的購物伺服器3a，係在藉由第一種使用者操作了認可鈕b2的情況下，使第二種使用者購物籃網頁pb2中的關於認可已被進行之商品的購入鈕b1，變成活化。

在圖10中係圖示，之前圖7所示的關於雙方之商品而獲得第一種使用者所做之認可以後所被提示的第二種使用者購物籃網頁pb2之例子。如圖之情況下的第二種使用者購物籃網頁pb2中，各個購入鈕b1係以活化狀態而被提示，第二種使用者係可針對各個商品進行購入操作。

然後，本例的購物伺服器3a，係針對第一種使用者所做的關於結帳之輸入資訊是已被受理的第二種使用者購入希望商品，將關於結帳之輸入資訊是已被受理之意旨、及將關於結帳之輸入資訊是已被受理之第一種使用者予以通知的資訊，提示給與進行了該第二種使用者購入希望商品之商品投入操作的第二種使用者建立關連的第一種使用者。具體而言，針對第一種使用者購物籃網頁pb1 中所被提示的第二種使用者購入希望商品之中已經進行過認可的商品，將認可已被進行之意旨、及表示進行了認可的第一種使用者的資訊，在與進行了該商品之投入操作的第二種使用者建立關連的第一種使用者的第一種使用者購物籃網頁pb1中，予以提示。

圖11係圖示了，這些認可已被進行之意旨及表示進行了認可之第一種使用者的資訊(以下記作「認可確認資訊Is」)所被提示的第一種使用者購物籃網頁pb1之例子。如圖示，作為認可確認資訊Is，係將含有例如「○×已經認可結帳了」等之文字資訊的資訊，予以提示。在本例中，關於已被認可的商品，係提示如此的認可確認資訊Is，而不進行認可鈕b2之提示。

此外，在圖11中係圖示，對於操作了之前圖9所示的第一種使用者購物籃網頁pb1上之認可鈕b2的第一種使用者本人而被提示的第一種使用者購物籃網頁pb1之例子。此情況下，認可確認資訊Is，係隨應於以圖9所示之狀態而操作了認可鈕b2，而例如與該認可鈕b2做替換而被顯示。

藉由如上記般地將針對進行了認可之商品的認可確認資訊Is在第一種使用者購物籃網頁pb1中做提示，對進行了認可的第一種使用者本人而言，就可確認自己所進行過的認可是否已被接受。

又，在對第二種使用者有複數第一種使用者被建立關連的情況下，對進行了認可以外的第一種使用者，藉由其 他第一種使用者而被進行了認可之意旨、及表示進行了認可之第一種使用者的資訊，係在自己的第一種使用者購物籃網頁pb1中被提示，透過第一種使用者購物籃網頁pb1，就可掌握彼此的認可狀況。

此處，認可確認資訊Is之提示係可為，該認可確認資訊Is是被第一種使用者瀏覽一次以後就不再進行提示等，可隨著第一種使用者所做的瀏覽次數而結束提示。或者，認可確認資訊Is之提示，係亦可隨著認可被進行起算的經過時間而結束提示。

在本例中，作為使認可確認資訊Is之提示被結束的手法，是採用後者之手法，具體而言，隨著認可被進行的日子起經過所定日數，而使認可確認資訊Is之提示被結束。

採用上記的手法的情況下，即使認可被進行後，在所定日數之間係仍被要求將認可確認資訊Is設成可提示，因此在本例中，對於之前圖8所示的商品/使用者關連建立資訊I3，可以使得對認可已被進行之商品的認可者使用者ID之登錄、資訊消去預定日之登錄，成為可行。資訊消去預定日，係表示關於認可已被進行之商品的該商品/使用者關連建立資訊I3中的登錄資訊之消去預定日。

購物伺服器3a，係隨應於第一種使用者所做的關於第二種使用者購入希望商品之認可已被進行之事實，而取得已被認可之商品的商品ID，同時，將進行了 認可的第一種使用者的使用者ID，當作認可者使用者ID而加以取，將已取得之認可者使用者ID，與商品/使用者關連建立資訊I3中的上記已取得之商品ID建立對應而記憶。然後，作為資訊消去預定日，將現在日期加上上記的所定日數而計算出日期，將該計算出來之日期與商品/使用者關連建立資訊I3中的上記已取得之商品ID建立對應而記憶。

購物伺服器3a，係可基於商品/使用者關連建立資訊I3中的認可者使用者ID的對應建立之有無，來判定作為對象的第二種使用者購入希望商品是否已經認可。又，針對認可者使用者ID是已被建立對應的第二種使用者購入希望商品，係可基於該認可者使用者ID而將認可確認資訊Is予以提示。

甚至，商品/使用者關連建立資訊I3中的登錄資訊之中，資訊消去預定日所被建立對應到的登錄資訊，係在該資訊消去預定日所表示的日期，會被消去。因此，關於資訊消去預定日是已被建立對應到的第二種使用者購入希望商品(已認可商品)的認可確認資訊Is之提示，係從認可已被進行之日期起經過了上記之所定日數之後就不被行。

回到圖5說明。

結帳控制處理部F5，係隨應於關於已經受理了關於結帳之輸入資訊的第二種使用者購入希望商品而已經由第二種使用者進行了購入操作之事實，而進行控制，以使得 關於該第二種使用者購入希望商品之購入費用的結帳處理，會基於第一種使用者所做的關於結帳之輸入資訊而被進行。具體而言，於本例中，關於認可鈕b2是被操作而於第二種使用者購物籃網頁pb2中購入鈕b1是變成活化狀態的第二種使用者購入希望商品，隨應於第二種使用者操作該購入鈕b1而進行了商品之購入操作，而進行控制，以使得關於該商品之購入費用的結帳處理，會以針對該商品進行了認可之第一種使用者的名義，而被進行。

如前述，本例的購物伺服器3a，係對由關於購入操作已被進行之商品(購入對象商品)的購入處理，是進行以下處理：將含有商品之購入費用或身為結帳者的使用者之信用卡號等之資訊的訂購資訊，對購入對象商品的販售來源店舖之店舖終端5，進行送訊。隨應於此，本例的結帳控制處理部F5，作為上記的訂購資訊，係生成將結帳者的信用卡號設成已經進行了關於購入對象商品之認可的第一種使用者之信用卡號的訂購資訊，並進行將該訂購資訊發送至相應之店舖終端5的處理。

如前述而接收到訂購資訊的店舖終端5，係將該訂購資訊發送至卡片公司伺服器6而進行結帳要求，隨應於此，而在卡片公司伺服器6中，在其後的所定之時序上，執行從該訂購資訊中所含之信用卡號所建立關連的戶頭將結帳金額予以扣款的處理。

限制設定處理部F6，係基於與第二種使用者建立關連之第一種使用者之操作，針對與該第二種使用者 建立關連之複數第一種使用者之其中至少一名的第一種使用者，設定第二種使用者購入希望商品所涉及之結帳處理操作之限制資訊。

圖12係圖示了，為了設定限制資訊而對第一種使用者所提示的網頁(以下記作「限制資訊設定網頁pr」)之例子。

於本例的購物網站中，限制資訊設定網頁pr係被設計成，在對同一第二種使用者建立關連有複數第一種使用者的情況下，是可由這些複數第一種使用者(亦即屬於同一群組的第一種使用者)之每一者要求提示的網頁，而無法由其他第一種使用者要求提示。在圖12中係圖示，隨應於從與同一第二種使用者建立關連的3位第一種使用者之其中一人所送來的提示要求而被提示的限制資訊設定網頁pr之例子。

如圖示，在限制資訊設定網頁pr中，與進行了該限制資訊設定網頁pr之提示要求的第一種使用者屬於同一群組的第一種使用者之一覽係被提示，同時，針對這些每位第一種使用者，表示限制類型之區別的資訊、具體而言係為表示類型A、類型B的各個文字資訊、和對類型A之文字資訊而被配置的勾選盒cba及輸入盒bia、和對類型B之文字資訊而被配置的勾選盒cbb及輸入盒bib、和用來進行設定指示所需之設定鈕b3，係被提示。

在本例的情況下，限制的類型A係被設計成，對同一第二種使用者的每個月的能夠認可次數(可結帳次數)之 限制，限制的類型B係被設計成，對同一第二種使用者的每個月的能夠認可金額(能夠認可的購入費用之額度：可結帳額)之限制。

第一種使用者，係在限制資訊設定網頁pr中所被提示的第一種使用者(在本例中係也包含進行限制設定的本人)之中針對所望之第一種使用者，藉由在勾選盒cba或cbb之任一者中打勾以選擇類型A、類型B之任一者，對輸入盒bia或bib之中已選擇之類型側的輸入盒bi進行了資訊輸入之後，操作設定鈕b3。藉此，針對上記所望之第一種使用者，可將第二種使用者購入希望商品所涉及之結帳權之限制資訊之設定，對購物伺服器3a進行指示。

隨應於如此的限制資訊之設定指示被進行，限制設定處理部F6係進行，相應於對限制資訊設定網頁pr之輸入資訊的限制資訊之設定處理。具體而言，限制設定處理部F6，係基於對限制資訊設定網頁pr之輸入資訊，而取得被視為限制資訊之設定對象的第一種使用者的使用者ID、及限制類型、及限制基準資訊。此外，所謂限制基準資訊，係輸入盒bia或bib中所被輸入的資訊，在本例中係為表示次數的數值資訊、或表示金額的數值資訊之任一者。

然後，限制設定處理部F6，係對已取得的第一種使用者的使用者ID，將已取得的限制類型及限制基準資訊建立對應而記憶在圖1所示的限制資訊DB3h中。

圖13係圖示了，藉由如上記的身為限制設定 處理部F6之機能而在限制資訊DB3h中所被建構的限制管理資訊I4之例子。

如圖示，於限制管理資訊I4中，按照被視為限制資訊之設定對象的第一種使用者的每一使用者ID，把限制類型之資訊及限制基準資訊予以建立對應。

此處，在本例的限制管理資訊I4中，係對這些使用者ID、限制類型之資訊、及限制基準資訊的集合，還將歷程資訊予以建立對應。歷程資訊，係表示有關於該歷程資訊所被建立對應到的第一種使用者所做的每個月之認可次數、或認可金額的現狀值的資訊。如後述，被視為限制資訊之設定對象的第一種使用者是否超出限制基準，係基於與該第一種使用者建立對應到的歷程資訊與限制基準資訊，而被判定。

此外，作為歷程資訊之數值的初期值係為「0」。又，作為歷程資訊之數值係每個月被重置。

回到圖5，限制控制處理部F7，係基於限制設定處理部F6所設定的限制資訊，來進行控制，以使得第一種使用者所做的第二種使用者購入希望商品所涉及之結帳處理操作，會被限制。

具體而言，限制控制處理部F7，係在藉由第一種使用者而進行了關於第二種使用者購入希望商品的認可操作時，判定該第一種使用者是否為被視為限制資訊之設定對象的第一種使用者。亦即，判定該第一種使用者的使用者ID是否存在於限制管理資訊I4中。然後，若是被視為限 制資訊之設定對象的第一種使用者，則限制控制處理部F7，係基於限制管理資訊I4中的與該第一種使用者建立對應到的歷程資訊和限制基準資訊，來判定該第一種使用者是否超出了限制基準資訊所表示的限制基準。具體而言，在限制類型為類型A的情況下，係判定與該第一種使用者建立對應到的歷程資訊所表示之現狀下的每個月的認可次數(不包含本次認可操作的次數)，是否為限制基準資訊所表示的每個月的能夠認可次數以上。又，在限制類型為類型B的情況下，係判定對與該第一種使用者建立對應到的歷程資訊所表示的現狀下的每個月的認可金額，加算本次被認可操作的第二種使用者購入希望商品的購入費用而成的金額，是否比限制基準資訊所表示的每個月的能夠認可金額還多。

若判定為已經超出了限制基準資訊所表示之限制基準，則限制控制處理部F7係不接受認可操作，將認可視為NG。具體而言，在本例中，已被認可操作的第二種使用者購入希望商品的購入鈕b1係不被活化，關於該第二種使用者購入希望商品的第二種使用者所做的購入操作係維持成不可行的狀態。

藉此，基於限制設定處理部F6所設定的限制資訊，第一種使用者所做的第二種使用者購入希望商品所涉及之結帳處理操作，就被限制。

〔1-4.處理程序〕

接下來，為了實現上記所說明之第二種使用者購入希望商品的購入費用結帳所涉及之各機能而應執行的具體處理之程序，參照圖14~圖18之流程圖來說明。此外，這些流程圖所示的處理，係由購物伺服器3a的CPU101依照例如記憶部108等之記憶裝置中所記憶之程式，而執行之。

圖14係圖示了限制資訊之設定所涉及之處理。該圖所示的處理，係隨應於藉由第一種使用者進行了限制資訊設定網頁pr之提示要求之事實，而被開始。

於圖14中，購物伺服器3a(CPU101)，作為步驟S101之限制資訊設定網頁pr之提示處理，是進行用來對進行了上記之提示要求的第一種使用者之使用者終端4顯示限制資訊設定網頁pr所需之處理。具體而言，基於第二種使用者DB3d之儲存資訊，將與進行了上記之提示要求的第一種使用者屬於同一群組的第一種使用者加以界定，將該已界定之第一種使用者的姓名資訊，由第一種使用者DB3c加以取得。然後，生成將已取得之姓名資訊、和按照該每一姓名資訊而應提示的限制類型之資訊、勾選盒cba、cbb、輸入盒bia、bib、及設定鈕b3，以之前圖12所說明的態樣所配置成的限制資訊設定網頁pr之網頁資料，將該網頁資料發送至上記之使用者終端4。

接著在步驟S102中，購物伺服器3a係等待直到對限制資訊設定網頁pr的輸入資訊是被上記使用者終端4所接收為止。此外，對限制資訊設定網頁pr的輸 入資訊，係隨應於設定鈕b3之操作而從使用者終端4被發送。

對限制資訊設定網頁pr的輸入資訊已被接收的情況下，購物伺服器3a係在步驟S103中，基於輸入資訊而將限制管理資訊I4予以更新。亦即，基於已接收之輸入資訊，取得被視為限制資訊之設定對象的第一種使用者的使用者ID、及應設定之限制類型、及限制基準資訊，對所取得的第一種使用者的使用者ID，將已取得之限制類型及限制基準資訊建立對應而記憶在限制資訊DB3h中。

購物伺服器3a係隨應於步驟S103之處理的執行而結束圖14所示的處理。

圖15係圖示了第二種使用者所做的往購物籃之商品投入所對應之處理。

於圖15中，購物伺服器3a，係等待直到步驟S201中第二種使用者所做的往購物籃之商品投入操作被進行為止，在該商品投入操作被進行時，步驟S202中，基於第二種使用者DB3d的儲存資訊來界定與該第二種使用者建立關連之第一種使用者。亦即，取得該第一種使用者的使用者ID。

在後續的步驟S203中，購物伺服器3a係對已界定之第一種使用者，將購物籃投入商品建立關連。亦即，取得第二種使用者投入購物籃之商品的商品ID，將該商品ID、和步驟S202中所界定之第一種使用者的使用 者ID建立對應而記憶在關連建立資訊DB3g。

隨應於步驟S203的關連建立處理的進行，購物伺服器3a係在步驟S204中，進行用來向已界定之第一種使用者發送結帳認可要求郵件所需之處理。

亦即進行，用來將含有用來催促關於上記進行了投入操作之商品之購入費用的結帳認可所需之文字資訊的電子郵件，發送至進行了該投入操作之第二種使用者之郵件位址所需之處理。此外，步驟S204的處理，係可為實際發送電子郵件的處理，亦可為將電子郵件追加至送訊清單等，進行電子郵件之送訊預約或送訊指示的處理。

購物伺服器3a係隨應於步驟S204之處理的執行而結束圖15所示的處理。

圖16係第一種使用者之購物籃網頁(第一種使用者購物籃網頁pb1)之提示所涉及之處理。

於圖16中，購物伺服器3a，係等待直到步驟S301中第一種使用者的購物籃網頁(第一種使用者購物籃網頁pb1)之提示要求被進行為止，若有該提示要求，則在步驟S302中取得該第一種使用者的購物籃投入中商品的資訊。該第一種使用者的購物籃投入中商品的資訊，係基於第一放入購物籃商品DB3e中所被儲存之第一種購入希望商品管理資訊I1，而加以取得。此外，有時候該第一種使用者的購物籃投入中商品係不存在，此時則取得視為沒有該當商品之資訊。

在後續的步驟S303中購物伺服器3a，係基於 第二種使用者DB3d的儲存資訊來判定是否有與該第一種使用者建立關連的第二種使用者存在。

若判定為與該第一種使用者建立關連的第二種使用者係為不存在，則購物伺服器3a係前進至步驟S305，基於該第一種使用者的購物籃投入中商品的資訊而進行第一種使用者購物籃網頁pb1的提示處理。亦即，僅刊載該第一種使用者的購物籃投入中商品來作為刊載商品，生成對該購物籃投入中商品配置有購入鈕b1的第一種使用者購物籃網頁pb1的網頁資料，將該網頁資料對該第一種使用者的使用者終端4進行送訊。此外，在上述的視為沒有該當商品之資訊已被取得的情況下，沒有刊載購物籃投入中商品及購入鈕b1的第一種使用者購物籃網頁pb1會被提示，這件事情不再贅述。

又，於步驟S303中，若判定為與該第一種使用者建立關連的第二種使用者係為存在，則購物伺服器3a係前進至步驟S304，判定在商品/使用者關連建立資訊I3中是否有該第一種使用者的使用者ID存在。

若判定為該第一種使用者的使用者ID不存在，則購物伺服器3a係執行上記步驟S305的提示處理。

另一方面，若判定為該第一種使用者的使用者ID係為存在，則購物伺服器3a係前進至步驟S306，基於該第一種使用者的購物籃投入中商品的資訊、及商品/使用者關連建立資訊I3中的與該第一種使用者建立關連之資訊，而執行第一種使用者購物籃網頁pb1的提示處 理。具體而言，如之前圖9所示，生成該第一種使用者的購物籃投入中商品及購入鈕b1、和商品/使用者關連建立資訊I3中的與該第一種使用者建立關連的商品及認可鈕b2是被所定配置的第一種使用者購物籃網頁pb1的網頁資料，並將該網頁資料對該第一種使用者的使用者終端4進行送訊。

此外，此時也是，在上述的視為沒有該當商品之資訊已被取得的情況下，沒有刊載該第一種使用者之購物籃投入中商品及購入鈕b1的第一種使用者購物籃網頁pb1會被提示，這件事情不再贅述。

又，在步驟S306的提示處理中，若在商品/使用者關連建立資訊I3中，對於與該第一種使用者建立關連之商品，沒有認可者使用者ID被建立對應的情況下，則變成會提示出取代認可鈕b2而改為前述之認可確認資訊Is的第一種使用者購物籃網頁pb1。

購物伺服器3a，係隨應於步驟S306的提示處理，或之前的步驟S305之提示處理的執行，而結束圖16所示的處理。

圖17係認可鈕b2之操作所對應之處理。

於圖17中，購物伺服器3a，係在步驟S401中等待認可鈕b2的操作，當認可鈕b2被操作時則在步驟S402中，判定在限制管理資訊I4中是否有該第一種使用者(進行了認可鈕b2之操作的第一種使用者)的使用者ID存在。這相當於判定，該第一種使用者是否為關於結帳處 理操作是已被設定限制的使用者。

若判定為該第一種使用者的使用者ID係為存在，則購物伺服器3a係前進至步驟S403，進行關於限制之解析處理。具體而言，在步驟S403的解析處理中，取得限制管理資訊I4中與該第一種使用者的使用者ID建立對應的控制類型、限制基準資訊、歷程資訊。又，在步驟S403的解析處理中，若限制類型是類型B，則作為在下個步驟S404的判定處理中所使用的資訊，是算出對歷程資訊所表示的現狀下的每個月之認可金額，加算本次已被認可操作之第二種使用者購入希望商品之購入費用而成的金額(判定用金額)。

在後續的步驟S404中，購物伺服器3a係判定是否超出限制基準。具體而言，作為該步驟S404的判定處理，係若步驟S403的解析處理中所取得的限制類型是類型A，則判定步驟S403中所取得之歷程資訊所表示的現狀下的每個月的認可次數，是否為步驟S403中所取得之限制基準資訊所表示的每個月的能夠認可次數以上。又，若步驟S403中所取得之限制類型是類型B，則判定步驟S403中所算出之上記的判定用金額，是否比步驟S403中所取得之限制基準資訊所表示的每個月的能夠認可金額還多。

此外，從以下的說明可知，歷程資訊係在步驟S406中被更新，因此步驟S404中限制類型為類型A時所被使用的上記「歷程資訊所表示的現狀下的每個月的認可次 數」，係為不包含本次的認可操作的次數(亦即本次認可操作若被接受則認可次數為「3」的情況下，上記「歷程資訊所表示的現狀下的每個月的認可次數」係為「2」)。

於步驟S404中判定為超出限制基準的情況下，則購物伺服器3a係前進至步驟S405，執行認可NG處理而結束圖17所示的處理。作為認可NG處理，係不接受認可操作，進行將認可視為NG所需之處理。具體而言，例如，使已被認可操作的第二種使用者購入希望商品的購入鈕b1不被活化，使關於該第二種使用者購入希望商品的第二種使用者所做的購入操作維持成不可行的狀態。

又，於步驟S404中判定為沒有超出限制基準的情況下，則購物伺服器3a係前進至步驟S406，進行歷程資訊更新處理。亦即，關於在限制管理資訊I4中與該第一種使用者的使用者ID建立對應的歷程資訊，在限制類型為類型A的情況下，將該歷程資訊之數值更新成對步驟S403所取得之歷程資訊之數值加算「1」之後的值，在限制類型為類型B的情況下，將該歷程資訊之數值更新成步驟S403所算出之上記的判定用金額的值。

隨應於步驟S406的更新處理之執行，購物伺服器3a係在步驟S407中，進行對商品/使用者關連建立資訊I3的認可者使用者ID、及資訊消去預定日之登錄。亦即，在商品/使用者關連建立資訊I3中的商品ID之 中，對步驟S401中被偵測出認可操作的商品的商品ID，作為認可者使用者ID是將進行了認可操作的第一種使用者的使用者ID，又作為資訊消去預定日是將現在日期加算前述的所定日數而成的日期，分別予以登錄。

在後續的步驟S408中，購物伺服器3a係執行用來向第二種使用者發送認可通知郵件所需之處理。具體而言，對於將步驟S401中偵測到認可操作之商品投入至購物籃的第二種使用者，進行用來發送含有針對該商品之購入費用的結帳是已被認可之意旨、及表示進行了該認可之第一種使用者之資訊的電子郵件所需之處理。

此外，作為步驟S408的處理，也是可為實際發送電子郵件的處理，亦可為將電子郵件追加至送訊清單等，進行電子郵件之送訊預約或送訊指示的處理。

購物伺服器3a係隨應於步驟S408之處理的執行而結束圖17所示的處理。

又，在之前的步驟S402中，判定為在限制管理資訊I4中沒有該第一種使用者(進行了認可鈕b2之操作的第一種使用者)的使用者ID存在的情況下，購物伺服器3a係略過步驟S403~S406而使處理往步驟S407前進。亦即，該第一種使用者係為關於結帳處理操作之限制是沒有被設定的使用者的情況下，基於限制管理資訊I4的限制之解析處理或超出判定處理、及限制管理資訊I4中的歷程資訊之更新處理係被略過，對商品/使用者關連建立資訊I3的該第一種使用者的使用者ID(認可者使用 者ID)之登錄、及資訊消去預定日之登錄(S407)，和用來向第二種使用者發送認可通知郵件所需之處理(S408)，會被執行。

此外，在上記中，雖然舉出認可通知是只對第二種使用者進行的例子，但進行了認可的第一種使用者所屬之群組中有其他第一種使用者存在的情況下，亦可對這些第一種使用者進行認可通知。

圖18係第二種使用者所做的購入操作所對應之處理。

於圖18中，購物伺服器3a係在步驟S501中，等待第二種使用者的購入操作，若有該購入操作時則前進至步驟S502，基於商品/使用者關連建立資訊I4而界定，進行了已被購入操作之商品之結帳認可的第一種使用者。

在後續的步驟S503中，購物伺服器3a係執行用來發送把已界定之第一種使用者設成結帳者之訂購資訊所需之處理。具體而言，係生成將結帳者的信用卡號設成上記已界定之第一種使用者之信用卡號的訂購資訊，進行用來將該訂購資訊發送至相應之店舖終端5(購入操作是已被進行之商品的販售來源店舖的店舖終端5)所需之處理。該步驟S503的處理，係可為實際發送訂購資訊的處理，亦可為將訂購資訊追加至送訊清單等，進行訂購資訊之送訊預約或送訊指示的處理。

購物伺服器3a，係隨應於步驟S503之處理的執行而結束圖18所示的處理。

此外，在上記中係舉出了，將第一種使用者設成結帳名義人的關於第二種使用者購入希望商品的結帳控制處理，係基於第一種使用者所做的認可鈕b2之操作輸入而被進行的例子。亦即例示了，為了進行關於第二種使用者購入希望商品之結帳控制處理而向第一種使用者要求的「關於結帳之輸入資訊」，是被設成認可鈕b2的操作輸入資訊的情形。

然而，「關於結帳之輸入資訊」，係並非限定於認可鈕b2的操作輸入資訊。例如，不提示認可鈕b2而是提示「進行結帳」按鈕，一旦該「進行結帳」按鈕被第一種使用者所操作，則引導至關於第二種使用者購入希望商品的結帳手續網頁，隨應於該結帳手續網頁中藉由第一種使用者進行了結帳手續所需之操作輸入，而將關於該第二種使用者購入希望商品的購入鈕b1予以活化(亦即變成可以購入操作)，亦可採用如此的手法。此情況下，「關於結帳之輸入資訊」，係相當於上記的結帳手續網頁中的輸入資訊。

〔1-5.第1實施形態的總結〕

如上述，第1實施形態的資訊處理裝置(購物伺服器3a)，係具備：關連建立關係資訊記憶部(關連建立資訊DB3g)，係記憶表示第一種使用者與第二種使用者之關連建立關係的關連建立關係資訊；和商品登錄部(商品登錄處理部F1)，係隨著每位使用者進行了往購物籃之商 品投入操作，而將該已被投入操作之商品當作購入希望商品而登錄至購入希望商品管理資訊；和商品/使用者關連建立部(商品/使用者關連建立處理部F2)，係在進行了商品投入操作的使用者是第二種使用者的情況下，參照關連建立關係資訊，對與該第二種使用者建立關連的第一種使用者，將該第二種使用者的購入希望商品予以建立關連。

又，具備：輸入資訊受理部(輸入資訊受理處理部F4)，係將有關於第二種使用者的購入希望商品之購入費用的第一種使用者所做的關於結帳之輸入資訊，予以受理；和結帳控制部(結帳控制處理部F5)，係隨應於第二種使用者針對已受理輸入資訊之第二種使用者的購入希望商品而進行了購入操作，而進行控制，使得有關於該第二種使用者的購入希望商品之購入費用的結帳處理，是基於第一種使用者所做的關於結帳之輸入資訊，而被進行。

然後，還具備：限制設定部(限制設定處理部F6)，係基於與第二種使用者建立關連之第一種使用者之操作，針對與該第二種使用者建立關連之複數第一種使用者之其中至少一名的第一種使用者，設定該第二種使用者的購入希望商品所涉及之結帳處理操作之限制資訊；和限制控制部(限制控制處理部F7)，係基於限制資訊，來進行控制，以使得第一種使用者所做的第二種使用者的購入希望商品所涉及之結帳處理操作會被限制。

若依據上記構成，則藉由第二種使用者的購 入希望商品管理資訊，就可掌握作為第二種使用者的特定使用者層的商品購入動向。

又，藉由上記的限制控制部，就可防止第一種使用者(例如祖父等)係背地裡過剩地買東西給第二種使用者(例如子女)。

因此，若依據第1實施形態的資訊處理裝置，則可執行關於商品購入費用之結帳處理操作的第一種使用者與結帳處理操作是被限制的第二種使用者是被管理的電子商務交易系統，可易於掌握第二種使用者的商品購入動向，可以謀求防止第一種使用者過剩地買東西給第二種使用者的電子商務交易系統之實現。

又，若依據第1實施形態的資訊處理裝置，則由於第一種使用者係可於自己的購入希望商品清單中掌握第二種使用者的購入希望商品並進行認可，因此不需要為了認可而每次都去存取第二種使用者的購入希望商品清單，這點來看也可謀求減輕購入費用結帳所涉及的第一種使用者的麻煩。

又，第1實施形態的資訊處理裝置，係具備：通知控制部，係隨應於第二種使用者進行了往購物籃之商品投入操作，而進行控制，以使得對與該第二種使用者建立關連之第一種使用者的通知會被進行。

藉此，就可將有第二種使用者所做的商品投入操作的事實，迅速通知給第一種使用者。

因此可謀求，縮短第一種使用者所做的結帳認可等， 關於結帳之輸入被進行以前的第二種使用者的等待時間。

然後，於第1實施形態的資訊處理裝置中，通知控制部係進行控制，以使得催促關於第二種使用者的購入希望商品之購入費用之結帳的通知會被進行，來作為通知。

藉此，就可謀求對第一種使用者的通知內容之明確化。

又，對第二種使用者將複數第一種使用者建立關連時，係變成逆競標的舉動，可對第二種使用者與和其建立關連之第一種使用者透過購物而提供娛樂性。

又甚至，於資訊處理裝置，其中，具備：商品提示部，係將每位使用者進行了往購物籃之商品投入操作的購入希望商品，提示給該使用者；對第一種使用者的商品提示部，係在對於該第一種使用者已經有第二種使用者的購入希望商品被建立關連的情況下，則將該第一種使用者的購入希望商品與該第二種使用者的購入希望商品，予以提示，較為理想。

藉此，第一種使用者可在自己的購物籃中確認第二種使用者的購入希望商品。

又，第1實施形態的資訊處理裝置，係具備：通知資訊提示部，係在已經與第一種使用者建立關連之第二種使用者的購入希望商品之中針對已經受理了第一種使用者所做的關於結帳之輸入資訊的購入希望商品，將已經受理了關於結帳之輸入資訊之意旨、及用來通知關於 結帳之輸入資訊是已被受理之第一種使用者的資訊，提示給與進行了該購入希望商品之商品投入操作的第二種使用者建立關連的第一種使用者。

藉此，對關於結帳之輸入資訊是已被受理的第一種使用者本人而言，可確認關於自身之結帳之輸入資訊是否已經被接受。

又，在對第二種使用者有複數第一種使用者被建立關連的情況下，對關於結帳之輸入資訊是已被受理以外的第一種使用者，其他第一種使用者所做的關於結帳之輸入資訊是已被受理之意旨，及用來通知關於結帳之輸入資訊是已被受理之第一種使用者的資訊，會被提示，因此父母或祖父、祖母係可容易掌握買給狀況(誰買給了什麼東西)。在本例的情況下，各第一種使用者，係可透過自己的購入希望商品而掌握彼此的狀況，因此可使該清單，透過第二種使用者之商品購入而變成一種溝通工具而發揮機能。

<2.第2實施形態> 〔2-1.網路系統之概要〕

圖19係圖示了，第2實施形態之網路系統1A(EC系統)之例子。

此外，以下的說明中，和已經說明過的部分相同的部分係標示同一符號並省略說明。

與圖1所示的網路系統1之差異，係取代掉購物網站 營運系統3而改為設置購物網站營運系統3A這點。購物網站營運系統3A，係取代掉購物伺服器3a改為設置購物伺服器3aA，並追加了不需認可商品資訊DB3i，這點是和購物網站營運系統3不同。

此外，關於不需認可商品資訊DB3i係可由以下說明而明瞭。

又，購物伺服器3aA、不需認可商品資訊DB3i的電腦裝置之硬體構成，係和之前的圖4所示相同。

〔2-2.作為第2實施形態的處理之概要〕

圖20係將購物伺服器3aA所具有的第二種使用者購入希望商品的購入費用結帳所涉及之機能予以區塊化而表示的機能區塊圖。

與第1實施形態中的購物伺服器3a之差異，係為被追加了不需認可商品設定處理部F8這點。

不需認可商品設定處理部F8，係基於與第二種使用者建立關連之第一種使用者之操作，來設定不需認可商品條件資訊If，其係用來將針對第二種使用者的購入希望商品的結帳之認可係為不需要的不需認可商品，進行條件賦予所需。

具體而言，不需認可商品設定處理部F8，係向第一種使用者，提示用來進行不需認可商品條件資訊If之設定所需之不需認可商品條件設定網頁。該不需認可商品條件設定網頁係被設成，可由第二種使用者所建立關連之第 一種使用者來要求提示的網頁，不可由其他第一種使用者要求提示。

在本例中，作為不需認可商品條件資訊If，可以設定不需認可之商品的類型資訊。亦即，不需認可商品條件設定網頁係被設計成，用來受理第一種使用者針對不需認可之商品之類型資訊所做的輸入資訊、及設定指示的網頁。

又，本例的不需認可商品條件設定網頁係被設計成，也用來受理進行關於不需認可商品之購入費用之結帳的第一種使用者之設定指示的網頁。例如，對於進行了不需認可商品條件設定網頁之提示要求的第一種使用者，若有屬於同一群組的其他第一種使用者存在，則該不需認可商品條件設定網頁，係以可以從該群組中所屬之第一種使用者之中受理進行不需認可商品之購入費用結帳的第一種使用者之指定及設定指示的態樣，而被提示。

不需認可商品設定處理部F8，係一旦透過不需認可商品條件設定網頁而由第一種使用者進行不需認可商品條件資訊If的設定指示，則將該已被指示之不需認可商品條件資訊If，與進行了不需認可商品條件設定網頁之提示要求的第一種使用者所建立關連之第二種使用者的使用者ID建立對應而記憶在圖19所示的不需認可商品資訊DB3i中。

圖21係圖示，藉由上記的不需認可商品設定處理部F8之機能而在不需認可商品資訊DB3i中所被建構 的不需認可商品管理資訊I5之例子。

如圖示，不需認可商品管理資訊I5係為，針對第二種使用者的每一使用者ID，把作為不需認可商品條件資訊If的不需認可商品類型之資訊予以建立對應而成的資訊。

本例的情況下，對於不需認可商品管理資訊I5，係有第二種使用者的使用者ID和不需認可商品類型之資訊，以及結帳者使用者ID，是被建立對應。結帳者使用者ID，係於不需認可商品條件設定網頁中作為進行關於不需認可商品之購入費用之結帳者而被設定指示的第一種使用者的使用者ID。

亦即，不需認可商品設定處理部F8，係隨應於透過不需認可商品條件設定網頁而進行了不需認可商品類型之資訊、及進行不需認可商品之購入費用結帳的第一種使用者的設定指示，而將該已被指示之不需認可商品類型之資訊、和該已被指示之第一種使用者的使用者ID(結帳者使用者ID)、和與進行了該不需認可商品條件設定網頁之提示要求的第一種使用者建立關連之第二種使用者的使用者ID，建立對應而記憶在不需認可商品資訊DB3i中。

在第2實施形態中，當第二種使用者把不需認可商品投入至購物籃時，作為該第二種使用者的第二種使用者購物籃網頁pb2中所被提示的關於該不需認可商品之購入鈕b2，係提示出活化狀態的購入鈕b2。藉此，第二種使用者係針對該商品無論是否有來自第一種使用者之 認可，都可進行購入操作。

於第2實施形態中，結帳控制處理部F5，係在第二種使用者進行了關於不需認可商品之購入操作時，進行控制，以使得關於該商品之結帳處理，是以與該第二種使用者建立關連之第一種使用者的名義而被進行。

具體而言，本例中的結帳控制處理部F5，係而進行控制，以使得不需認可商品的結帳處理，是以透過不需認可商品條件設定網頁而由第一種使用者進行了設定指示的第一種使用者的名義，而被進行。

〔2-3.處理程序〕

參照圖22及圖23的流程圖，說明為了實現上記所說明的第2實施形態之機能而應執行的具體之處理的程序。

此外，這些圖22及圖23所示的處理，係由購物伺服器3a的CPU101依照例如記憶部108等之記憶裝置中所記憶之程式，而執行之。

圖22係第2實施形態中的第二種使用者購物籃網頁pb2之提示所涉及之處理的流程圖。

於圖22中，購物伺服器3aA(CPU101)係在步驟S601中，等待直到第二種使用者所做的往購物籃之商品投入操作被進行為止，在該商品投入操作被進行時，在步驟S602中判定不需認可商品管理資訊I5中是否有使用者的使用者ID存在。這係相當於，判定是否有對該第二種使用者設定不需認可商品。

於步驟S602中，若判定為不需認可商品管理資訊I5中沒有該第二種使用者的使用者ID存在，則購物伺服器3aA係前進至步驟S605，進行將關於該商品(步驟S601中偵測出投入操作之商品)的購入鈕b1設成非活化狀態的第二種使用者購物籃網頁pb2的提示處理。

另一方面，於步驟S602中，若判定為不需認可商品管理資訊I5中有該第二種使用者的使用者ID存在，則購物伺服器3aA係前進至步驟S603，進行關於商品類型之解析處理。亦即，進行將步驟S601中被偵測出投入操作之商品的類型之資訊由商品DB3b加以取得，又，將不需認可商品管理資訊I5中與該第二種使用者的使用者ID建立對應的不需認可商品類型之資訊加以取得的處理。

在後續的步驟S604中，購物伺服器3aA係判定該商品(步驟S601中偵測出投入操作的商品)是否為不需認可商品。

若判定該商品並非不需認可商品，則購物伺服器3aA係前進至之前的步驟S605而執行將購入鈕b1設成非活化狀態的第二種使用者購物籃網頁pb2的提示處理。

另一方面，若判定該商品並非不需認可商品，則購物伺服器3aA係前進至步驟S606，執行將關於該商品之購入鈕b1設成活化狀態的第二種使用者購物籃網頁pb2的提示處理。

購物伺服器3aA，係隨應於步驟S605之提示 處理，或步驟S606之提示處理的執行，而結束圖22所示的處理。

圖23係第2實施形態中的第二種使用者所做的購入操作所對應之處理的流程圖。

此外，於圖23中，與圖18所示處理相同的處理係標示同一步驟號碼而省略說明。

於圖23中，購物伺服器3aA係在步驟S501中有第二種使用者所做的購入操作時，則前進至步驟S701，判定已被購入操作之商品是否為不需認可商品。具體而言，係判定不需認可商品管理資訊I5中是否有進行了購入操作之第二種使用者的使用者ID存在，若該使用者ID不存在則獲得並非不需認可商品的判定結果。又，若判定為該使用者ID是存在，則判定不需認可商品管理資訊I5中與該使用者ID建立對應之不需認可商品類型，是否與已被購入操作之商品的類型一致，若為不一致則獲得並非不需認可商品的判定結果，若為一致則獲得係為不需認可商品的判定結果。

若於步驟S701中判定為是不需認可商品，則購物伺服器3aA係前進至步驟S702，基於不需認可商品管理資訊I5，將已被購入操作之商品的結帳者也就是第一種使用者，予以界定。亦即，於不需認可商品管理資訊I5中，將與進行了購入操作的第二種使用者的使用者ID建立對應的結帳者使用者ID，加以取得。此時，像是圖21所示的關於使用者ID「u2020」的登錄資訊，對同一第二 種使用者是有複數筆不需認可商品類型之資訊被建立對應的情況下(亦即對該同一第二種使用者進行了複數次不需認可商品類型之設定的情況下)，在這些不需認可商品類型的資訊之中，將與已被判定為與已被購入操作之商品的類型一致的不需認可商品類型之資訊建立對應到的認可者使用者ID，加以取得。藉此，對同一第二種使用者所被進行的各個不需認可商品類型的設定時，可對應於作為結帳者而分別設定不同第一種使用者的情形。

購物伺服器3aA，係一旦在步驟S702中界定出身為結帳者的第一種使用者，則使處理前進至步驟S503。藉此，就會以前述的不需認可商品條件設定網頁中被設定指示成為結帳者的第一種使用者的名義，進行關於不需認可商品的結帳。

又，購物伺服器3aA，係在之前的步驟S701中判定係為不需認可商品的情況下，則使處理往步驟S502前進。藉此，若已被購入操作之商品並非不需認可商品，則會以進行了該商品之認可的第一種使用者之名義來進行結帳。

此外，在上記中，雖然例示了作為不需認可商品條件資訊If是設定商品的類型之資訊的情形，但作為不需認可商品條件資訊If，係亦可設定例如：關鍵字之資訊(將商品名等中含有該關鍵字的商品視為不需認可商品)、店舖之資訊(將該店舖的陳列商品視為不需認可商品)等。或者，亦可設定不想要認可的商品的商品ID 等，可設定來作為不需認可商品條件資訊If的資訊係可有多樣考量。

又，在上記中，雖然將不需認可商品之結帳者，在不需認可商品條件資訊If之設定時，設計成可讓第一種使用者來做設定指示，但這並非必須。例如，不需認可商品之結帳者，係可設定成進行了不需認可商品條件資訊If之設定的第一種使用者、或同一群組內的第一種使用者之中被預先決定的第一種使用者等，可考量多樣的設定手法。

〔2-4.第2實施形態的總結〕

如上述，第2實施形態的資訊處理裝置(購物伺服器3aA)，係具備：條件資訊設定部(不需認可商品設定處理部F8)，係基於與該第二種使用者建立關連之第一種使用者之操作，來設定不需認可商品條件資訊，其係用來將針對第二種使用者的購入希望商品是不需要第一種使用者所做的結帳之認可的商品，進行條件賦予所需。

然後，結帳控制部，係針對基於不需認可商品條件資訊而判定為相當於不需認可之商品的第二種使用者的購入希望商品，係無論有無認可，都進行控制而使結帳處理是以與該第二種使用者建立關連之第一種使用者的名義而被進行。

藉此，關於第一種使用者認為不需認可的商品，就不需要讓第一種使用者一一進行認可。

因此，可謀求認可所涉及之第一種使用者的負擔減輕。

此外，作為不需認可商品可以想成是，例如第二種使用者是子女的情況下，可以設定為，文具等學校生活中需要適宜補充的商品。

<3.程式及記憶媒體>

以上，說明了本發明所述的作為資訊處理裝置之實施形態的購物伺服器3a、3aA，但實施形態的程式，係為令資訊處理裝置(CPU等)，執行購物伺服器3a、3aA之處理的程式。

實施形態的程式，係令資訊處理裝置實現：商品登錄機能，係隨著每位使用者進行了往購物籃之商品投入操作，而將該已被投入操作之商品當作購入希望商品而登錄至購入希望商品管理資訊；和商品/使用者關連建立機能，係在進行了前記商品投入操作的使用者是第二種使用者的情況下，參照表示第一種使用者與第二種使用者之關連建立關係的關連建立關係資訊，對與該第二種使用者建立關連的第一種使用者，將該第二種使用者的購入希望商品予以建立關連；和輸入資訊受理機能，係將有關於第二種使用者的購入希望商品之購入費用的第一種使用者所做的關於結帳之輸入資訊，予以受理；和結帳控制機能，係隨應於第二種使用者針對已受理前記輸入資訊之第二種使用者的購入希望商品而進行了購入操作，而進行控 制，使得有關於該第二種使用者的購入希望商品之購入費用的結帳處理，是基於第一種使用者所做的關於結帳之輸入資訊，而被進行；和限制設定機能，係基於與第二種使用者建立關連之第一種使用者之操作，針對與該第二種使用者建立關連之複數第一種使用者之其中至少一名的第一種使用者，設定該第二種使用者的購入希望商品所涉及之前記結帳處理操作之限制資訊；和限制控制機能，係基於前記限制資訊，來進行控制，以使得第一種使用者所做的第二種使用者的購入希望商品所涉及之前記結帳處理操作會被限制。

亦即，該程式係相當於，例如令購物伺服器3a、3aA等之資訊處理裝置，執行圖14~圖19、圖22、圖23等所說明之處理的程式。

藉由此種程式，可實現上述的作為購物伺服器3a、3aA的資訊處理裝置。

然後，此種程式係可預先記憶在電腦裝置等之機器中所內建的作為記憶媒體之HDD、或具有CPU的微電腦內之ROM等中。又或者，可以暫時或永久性地被儲存(記憶)在半導體記憶體、記憶卡、光碟、光磁碟、磁碟等之可移除式記憶媒體中。又此種可移除式記憶媒體，係可用所謂的套裝軟體的方式來做提供。

又，此種程式，係除了可從可移除式記憶媒體安裝至個人電腦等以外，也可從下載網站，透過LAN、網際網路等之網路而下載之。

<4.變形例>

本發明係不限定於上記所說明的具體例，可考慮各種變形例。

例如，上記雖然作為結帳的手法是以進行信用卡結帳的情形為前提，但本發明係在作為結帳手法是採用其他手法(例如銀行匯款、代扣、虛擬預付卡等)的情況下，也能理想適用。

又，上記雖然例示了，將第二種使用者購入希望商品所涉及之結帳處理操作的限制資訊，讓與同一第二種使用者建立關連的全部第一種使用者都可設定指示的情形，但該限制資訊係亦可只有與同一第二種使用者建立關連的一部分第一種使用者可以為之。例如亦可為，將與同一第二種使用者建立關連之第一種使用者之一部分設定成上級使用者，將其他設定成下級使用者，只有上級使用者，可以對下級使用者進行限制資訊之設定指示。

又，上記雖然例示了，作為限制資訊是設定每個月的能夠認可次數或能夠認可金額的情形，但當然亦可設定例如禁止認可的設定等其他限制資訊。

3a‧‧‧購物伺服器

F1‧‧‧商品登錄處理部

F2‧‧‧商品/使用者關連建立處理部

F3‧‧‧第二種使用者商品提示處理部

F4‧‧‧輸入資訊受理處理部

F5‧‧‧結帳控制處理部

F6‧‧‧限制設定處理部

F7‧‧‧限制控制處理部

Claims (8)

1. 一種資訊處理裝置，係在可以執行關於商品購入費用之結帳處理操作的1或2位以上之第一種使用者與前記結帳處理操作是被限制的1或2位以上之第二種使用者之間，由第一種使用者來執行第二種使用者的前記結帳處理操作所需之電子商務交易系統中的資訊處理裝置，其中，具備：關連建立關係資訊記憶部，係記憶表示第一種使用者與第二種使用者之關連建立關係的關連建立關係資訊；和商品登錄部，係隨著每位使用者進行了往購物籃之商品投入操作，而將該已被投入操作之商品當作購入希望商品而登錄至購入希望商品管理資訊；和商品/使用者關連建立部，係在進行了前記商品投入操作的使用者是第二種使用者的情況下，參照前記關連建立關係資訊，對與該第二種使用者建立關連的第一種使用者，將該第二種使用者的購入希望商品予以建立關連；和輸入資訊受理部，係將有關於第二種使用者的購入希望商品之購入費用的第一種使用者所做的關於結帳之輸入資訊，予以受理；和結帳控制部，係隨應於第二種使用者針對已受理前記輸入資訊之第二種使用者的購入希望商品而進行了購入操作，而進行控制，使得有關於該第二種使用者的購入希望商品之購入費用的結帳處理，是基於第一種使用者所做的 關於結帳之輸入資訊，而被進行；和限制設定部，係基於與第二種使用者建立關連之第一種使用者之操作，針對與該第二種使用者建立關連之複數第一種使用者之其中至少一名的第一種使用者，設定該第二種使用者的購入希望商品所涉及之前記結帳處理操作之限制資訊；和限制控制部，係基於前記限制資訊，來進行控制，以使得第一種使用者所做的第二種使用者的購入希望商品所涉及之前記結帳處理操作會被限制。
2. 如請求項1所記載之資訊處理裝置，其中，具備：通知控制部，係隨應於第二種使用者進行了往購物籃之商品投入操作，而進行控制，以使得對與該第二種使用者建立關連之第一種使用者的通知會被進行。
3. 如請求項2所記載之資訊處理裝置，其中，前記通知控制部，係作為前記通知，是進行控制，以使得催促關於前記第二種使用者的購入希望商品之購入費用之結帳的通知會被進行。
4. 如請求項1所記載之資訊處理裝置，其中，具備：商品提示部，係將每位使用者進行了往購物籃之商品投入操作的購入希望商品，提示給該使用者；對第一種使用者的前記商品提示部，係在對於該第一種使用者已經有第二種使用者的購入希望商品被建立關連的情況下，則將該第一種使用者的購入希望商品與該第二 種使用者的購入希望商品，予以提示。
5. 如請求項1所記載之資訊處理裝置，其中，具備：通知資訊提示部，係在已經與第一種使用者建立關連之第二種使用者的購入希望商品之中針對已經受理了第一種使用者所做的前記關於結帳之輸入資訊的購入希望商品，將已經受理了前記關於結帳之輸入資訊之意旨、及用來通知前記關於結帳之輸入資訊是已被受理之第一種使用者的資訊，提示給與進行了該購入希望商品之商品投入操作的第二種使用者建立關連的第一種使用者。
6. 如請求項1所記載之資訊處理裝置，其中，具備：條件資訊設定部，係基於與該第二種使用者建立關連之第一種使用者之操作，來設定不需認可商品條件資訊，其係用來將針對第二種使用者的購入希望商品是不需要第一種使用者所做的結帳之認可的商品，進行條件賦予所需；前記結帳控制部，係進行控制，以使得針對基於前記不需認可商品條件資訊而判定為符合不需要前記認可之商品的第二種使用者的購入希望商品，無論前記認可之有無，都是以與該第二種使用者建立關連之第一種使用者之名義，來進行前記結帳處理。
7. 一種資訊處理方法，係在可以執行關於商品購入費用之結帳處理操作的1或2位以上之第一種使用者與前記結帳處理操作是被限制的1或2位以上之第二種使用者 之間，由第一種使用者來執行第二種使用者的前記結帳處理操作所需之電子商務交易系統中的資訊處理裝置所執行的資訊處理方法，其中，執行：商品登錄步驟，係隨著每位使用者進行了往購物籃之商品投入操作，而將該已被投入操作之商品當作購入希望商品而登錄至購入希望商品管理資訊；和商品/使用者關連建立步驟，係在進行了前記商品投入操作的使用者是第二種使用者的情況下，參照表示第一種使用者與第二種使用者之關連建立關係的關連建立關係資訊，對與該第二種使用者建立關連的第一種使用者，將該第二種使用者的購入希望商品予以建立關連；和輸入資訊受理步驟，係將有關於第二種使用者的購入希望商品之購入費用的第一種使用者所做的關於結帳之輸入資訊，予以受理；和結帳控制步驟，係隨應於第二種使用者針對已受理前記輸入資訊之第二種使用者的購入希望商品而進行了購入操作，而進行控制，使得有關於該第二種使用者的購入希望商品之購入費用的結帳處理，是基於第一種使用者所做的關於結帳之輸入資訊，而被進行；和限制設定步驟，係基於與第二種使用者建立關連之第一種使用者之操作，針對與該第二種使用者建立關連之複數第一種使用者之其中至少一名的第一種使用者，設定該第二種使用者的購入希望商品所涉及之前記結帳處理操作 之限制資訊；和限制控制步驟，係基於前記限制資訊，來進行控制，以使得第一種使用者所做的第二種使用者的購入希望商品所涉及之前記結帳處理操作會被限制。
8. 一種記憶媒體，係記憶有，令在可以執行關於商品購入費用之結帳處理操作的1或2位以上之第一種使用者與前記結帳處理操作是被限制的1或2位以上之第二種使用者之間，由第一種使用者來執行第二種使用者的前記結帳處理操作所需之電子商務交易系統中的資訊處理裝置執行處理的程式，其中，該記憶媒體係記憶了令前記資訊處理裝置實現下述機能的程式：商品登錄機能，係隨著每位使用者進行了往購物籃之商品投入操作，而將該已被投入操作之商品當作購入希望商品而登錄至購入希望商品管理資訊；和商品/使用者關連建立機能，係在進行了前記商品投入操作的使用者是第二種使用者的情況下，參照表示第一種使用者與第二種使用者之關連建立關係的關連建立關係資訊，對與該第二種使用者建立關連的第一種使用者，將該第二種使用者的購入希望商品予以建立關連；和輸入資訊受理機能，係將有關於第二種使用者的購入希望商品之購入費用的第一種使用者所做的關於結帳之輸入資訊，予以受理；和結帳控制機能，係隨應於第二種使用者針對已受理前記輸入資訊之第二種使用者的購入希望商品而進行了購入 操作，而進行控制，使得有關於該第二種使用者的購入希望商品之購入費用的結帳處理，是基於第一種使用者所做的關於結帳之輸入資訊，而被進行；和限制設定機能，係基於與第二種使用者建立關連之第一種使用者之操作，針對與該第二種使用者建立關連之複數第一種使用者之其中至少一名的第一種使用者，設定該第二種使用者的購入希望商品所涉及之前記結帳處理操作之限制資訊；和限制控制機能，係基於前記限制資訊，來進行控制，以使得第一種使用者所做的第二種使用者的購入希望商品所涉及之前記結帳處理操作會被限制。