TWI793840B

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

Info

Publication number: TWI793840B
Application number: TW110140578A
Authority: TW
Inventors: 中澤愛
Original assignee: 日商樂天集團股份有限公司
Priority date: 2020-11-27
Filing date: 2021-11-01
Publication date: 2023-02-21
Also published as: US20220172240A1; JP7030939B1; TW202221592A; JP2022085087A

Abstract

[課題]在由使用者透過終端來訂購商品的服務中，以抑制配送或店舖的作業負荷為課題。 [解決手段]資訊處理裝置係具備：第一訂單受理部(22)，係從使用者終端受理第一訂單；和使用者特定部(26)，係將第一訂單所涉及之第一使用者所被預先建立關連對應到的1個以上之第二使用者，加以特定；和第二訂單受理部(28)，係用以在第一訂單已被受理後，於所定之期間內，從1個以上之第二使用者受理1個以上之第二訂單；和訂單資訊關連建立部(29)，係用以將第一訂單所涉及之訂單資訊與第二訂單所涉及之訂單資訊建立關連，當作訂單所涉及之店舖是需要合併安排的訂單資訊捆包。

Description

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

本揭露係有關於，由使用者透過終端來訂購商品所需之技術。

先前，具有：將含有顧客已購入之商品之資訊與前記顧客前往店舖之來店預定日期時間的訂單資訊從顧客的使用者終端予以接收的訂單資訊收訊部；和基於來店預定日期時間，而向店員指示商品之準備之開始的準備開始指示部；和隨應於表示顧客已抵達店舖的抵達通知之收訊，而將關於要交付給顧客之商品的資訊進行通知的交付商品資訊通知部；交付商品資訊通知部，係在接收到抵達通知的情況下，在包含其他顧客所訂購之前記商品的2個以上之商品的準備已經完成時，則將關於先準備完成之商品的資訊進行通知的販售管理裝置，係已被提出(參照專利文獻1)。

除此以外，感知商品訂單者的使用者終端之接近，配合來店預想時刻而進行商品的收授準備，在來店時能夠迅速提供的店舖販售系統等，讓使用者透過終端而訂購商品所需之技術，已有數種被提出(參照專利文獻2至4)。 [先前技術文獻] [非專利文獻]

[專利文獻1]日本特開2019-067048號公報 [專利文獻2]日本特開2004-280468號公報 [專利文獻3]日本特開2018-101409號公報 [專利文獻4]日本特開2019-185727號公報

[發明所欲解決之課題]

先前係有，由使用者透過終端來訂購商品，並請人配送至指定之場所的服務(以下稱作「遞送服務」)、或由使用者透過終端來訂購商品，並由使用者自己去店舖拿取商品的服務(以下稱作「事前點餐外帶服務」)等。可是，在如此的服務中，配送或取貨是針對進行了點餐的每位使用者而被進行，配送或店舖的作業負荷係會增大。

本揭露係有鑑於上記的問題，其課題在於，在由使用者透過終端來訂購商品的服務中，抑制配送或店舖的作業負荷。 [用以解決課題之手段]

本揭露之一例係為，一種資訊處理裝置，係具備：第一訂單受理手段，係用以從使用者終端受理第一訂單；和使用者特定手段，係用以將前記第一訂單所涉及之第一使用者所被預先建立關連對應到的1個以上之第二使用者，加以特定；和第二訂單受理手段，係用以在前記第一訂單已被受理後，於所定之期間內，從1個以上之前記第二使用者受理1個以上之第二訂單；和訂單資訊關連建立手段，係用以將前記第一訂單所涉及之訂單資訊與前記第二訂單所涉及之訂單資訊建立關連，當作訂單所涉及之店舖是需要合併安排的訂單資訊捆包。

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

若依據本揭露，則在由使用者透過終端來訂購商品的服務中，可抑制配送或店舖的作業負荷。

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

在本實施形態中係說明，將本揭露所述之技術，在某個使用者利用事前點餐外帶型服務之際，對其他使用者呼喚「搭便車訂購」，在有來自其他使用者之搭便車訂購的情況下，可將該當使用者所訂購之商品與其他使用者所訂購之商品彙整起來在店頭予以收取的系統中做實施時的實施形態。於本實施形態中，雖然是複數個使用者所致之個別的訂購，但商品之收取(取貨或遞送等)是可彙整起來進行的訂購，稱作搭便車訂購。本揭露所涉及之技術，係可廣泛使用於可搭便車訂購之技術，本揭露的適用對象係不限定於實施形態中所示的例子。例如，本揭露所述之技術，係亦可被適用於遞送服務所需之系統。

＜系統的構成＞圖1係為本實施形態所述之系統的硬體構成之概略的圖示。本實施形態所涉及之系統係具備：藉由被連接至網路而可相互通訊的內容配送伺服器1、和1或複數個使用者終端9、和1或複數個店舖終端7。

伺服器1係為，從複數個使用者終端9之每一者受理訂單資訊，在已被受理之訂單資訊之中將滿足所定之條件的複數個訂單資訊予以彙整成1個訂單資訊捆包而發送至店舖終端7，以實現搭便車訂購所需之伺服器。伺服器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，係可藉由使用所謂雲端或分散運算之技術等的複數個裝置來加以實現。

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

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

圖2係本實施形態所述之資訊處理系統的機能構成之概略的圖示。伺服器1，係藉由記憶裝置14中所被記錄的程式，被讀出至RAM13上，被CPU11所執行，而控制伺服器1中所具備的各硬體，以成為具備：資料庫21、第一訂單受理部22、移動時間取得部23、擁擠狀況資訊取得部24、受理期間決定部25、使用者特定部26、受理通知部27、第二訂單受理部28、訂單資訊關連建立部29、下單部30、訂單資訊通知部31及狀況通知部32的資訊處理裝置而發揮機能。此外，在本實施形態及後述的其他實施形態中，伺服器1所具備的各機能，係藉由通用處理器也就是CPU11而被執行，但這些機能的部分或全部係亦可藉由1或複數個專用處理器而被執行。

資料庫21，係為用來將本實施形態中所被揭露之系統中被使用的，包含店舖資訊、使用者資訊、訂單資訊的各種資訊予以積存/管理所需之資料庫。此處，店舖資訊，係包含有：店舖ID、位置資訊、商品資訊及擁擠狀況資訊等，係為可利用事前點餐外帶型服務的店舖所相關之資訊。使用者資訊，係包含有使用者ID、位址(郵件位址或IP位址)、結帳資訊、及該當使用者所屬群組之群組ID，係為利用本系統的使用者所相關之資訊。又，訂單資訊，係包含有：訂單ID、使用者ID、店舖ID、商品資訊、價格、個數、取貨預定時間、及搭便車訂購商品之卸貨場所等之資訊等，係為表示藉由使用者而被下達的訂單之內容的資訊。

第一訂單受理部22，係從使用者終端9受理第一訂單。該當訂單所涉及之使用者，係成為搭便車訂購中的主持人(第一使用者)。

移動時間取得部23，係將第一訂單所涉及之使用者(第一使用者)抵達店舖所需要的移動時間，加以取得。更具體而言，移動時間取得部23，係將基於第一使用者之位置資訊與店舖之位置資訊而被算出的，第一使用者抵達店舖所需到的移動時間，加以取得。移動時間之算出，係只要採用使用地圖資訊或交通資訊而算出2地點間之移動時間的先前之技術即可，因此省略說明。

擁擠狀況資訊取得部24，係從第一訂單所涉及之店舖的店舖終端7，取得該當店舖的擁擠狀況資訊。藉由取得店舖的擁擠狀況資訊，後述的受理期間決定部25，就可對商品等變成可收取為止所必須的準備時間，增加考慮目前的擁擠狀況而決定第二訂單(搭便車訂購)之受理期間。此外，擁擠狀況資訊取得部24，係亦可將營業時間內的每個時間帶的擁擠狀況資訊從店舖預先取得並與店舖ID建立關連而加以保持。例如，從24小時營業的店舖預先取得每個時間帶的擁擠狀況資訊的情況，0-6時係為擁擠度「1」，6-9時係為擁擠度「3」，9-12時係為擁擠度「2」，12-13時係為擁擠度「5」，可取得如此的排行順位。藉由如此設計，用來通知擁擠狀況所需之操作就不需要每次都對店舖側做要求，可使用按照每一時間帶而被預先準備的擁擠狀況資訊。

受理期間決定部25，係在第一訂單已被受理的情況下，決定針對該當第一訂單的可受理第二訂單(搭便車訂購)的受理期間。此處，受理期間決定部25，係基於：(1)已被第一使用者或店舖所指定的預定、(2)已被移動時間取得部23所取得之移動時間、(3)第一訂單中所含之商品之準備完成為止的標準準備時間、及(4)已被擁擠狀況資訊取得部24所取得之擁擠狀況資訊之至少任一者，來決定受理期間。

更具體而言，受理期間決定部25，係基於前記(1)及/或(2)而算出取貨預定時間，然後，基於前記(3)及/或(4)而算出商品的準備時間，將藉由「取貨預定時刻-商品的準備時間」而被算出的時間，決定成為搭便車訂購之受理期間。

此處，取貨預定時間係可採用：藉由第一使用者或店舖所指定的時間點(「n分鐘後」或「午前/午後h時m分」等)、或已被移動時間取得部23所取得之移動時間之任一者。又，商品的準備時間係可採用，對預先被登錄在資料庫21中的每一店舖或每一商品的標準準備時間，基於已被擁擠狀況資訊取得部24所取得之擁擠狀況資訊而施以加權/加減處理所得的值。此處，店舖的擁擠狀況，係亦可用大/中/小或數值所致之排行順位而被表示，基於此種擁擠狀況資訊的加權/加減處理，係亦可按照每一店舖而預先決定成像是：大(等待時間20分鐘以上)、中(等待時間未滿20分鐘、大於0分鐘)、小(等待時間0分鐘)，亦可像是大(標準準備時間＊2.0)、中(標準準備時間＊1.5)、小(標準準備時間＊1.0)或大(標準準備時間+30分)、中(標準準備時間+10分)、小(標準準備時間+0分)般地而被算出。

此外，在本實施形態中，作為受理期間，雖然說明了使用從第一訂單之時間點起算的時間的例子，但受理期間係亦可不是藉由時間，而是藉由受理的截止時刻而被表示。此處，截止時刻，係可基於第一使用者所致之訂單時刻而算出。

使用者特定部26，係將第一使用者所被預先建立關連對應到的1個以上之第二使用者，加以特定。此時，使用者特定部26，係亦可將與第一使用者隸屬於同一群組的其他使用者，特定成為第二使用者，亦可將已被第一使用者所預先指定的其他使用者，特定成為第二使用者。第二使用者的特定是基於群組而被進行的情況下，群組係可基於所定之規則而被形成。例如，群組係可基於同一企業、同一辦公室、同一樓層、同一部門等之基準，而被形成。藉由如此而形成群組，例如，在午餐時間的餐點的點餐時，本實施形態所述之系統的利用就會變為簡便。又，群組的形成係亦可採用：向所定之使用者發送邀請連結而將在連結目標之頁面中進行了許可操作的使用者予以追加的方法、或受理來自使用者對群組的參加請求，將請求已被許可的使用者予以追加的方法等。

受理通知部27，係在第一訂單已被受理之後，向已被使用者特定部26所特定之第二使用者，通知第二訂單(搭便車訂購)的受理。

第二訂單受理部28，係在第一訂單已被受理之後，於所定之期間內，從1個以上之第二使用者受理1個以上之第二訂單(搭便車訂購)。此外，於本實施形態中，雖然第二訂單受理部28，係於已被受理期間決定部25所決定之受理期間內受理第二訂單，但可受理第二訂單的期間，係不限定於本實施形態中的例示。例如，可受理第二訂單的期間，係亦可為早於第一訂單前而被預先設定的期間。

訂單資訊關連建立部29，係將第一訂單所涉及之訂單資訊與第二訂單(搭便車訂購)所涉及之訂單資訊建立關連，當作訂單所涉及之店舖必須合併安排的訂單資訊捆包。

下單部30，係將訂單資訊捆包所涉及之下單，當作1次取貨所涉及之下單，而對店舖進行送訊。

訂單資訊通知部31，係將已被第二訂單受理部28所受理之第二訂單(搭便車訂購)所涉及之訂單資訊，通知給第一使用者。

狀況通知部32，係將關於第一使用者所致之商品之取貨及/或卸貨的狀況，通知給第二使用者。

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

圖3係本實施形態所述之店舖/商品資訊提供處理之流程的流程圖。本流程圖中所示的處理，係以接收到已被使用者終端9所發送之檢索要求的這件事情為契機，而被執行。

使用者終端9，係隨應於使用者操作而透過網路連接至伺服器1，進行可利用事前點餐外帶型服務的店舖之檢索要求。此時，本實施形態所述之使用者終端9，係使用該當使用者終端9中所被內建的GPS(Global Positioning System)單元(圖示省略)等而取得現在位置資訊，並對伺服器1發送現在位置資訊。但是，使用者的位置資訊，係亦可藉由GPS以外之手段(例如使用從無線LAN存取點或行動電話網基地台所獲得之資訊的方法等)，來加以取得。受理了檢索要求的伺服器1(步驟S101)，係基於從使用者終端9所得到的位置資訊等，從資料庫21檢索出使用者所能利用之店舖(步驟S102)。

在本實施形態中，伺服器1係基於從使用者終端9所得到的位置資訊、和資料庫21中所被保持的每一店舖的位置資訊，而檢索出從使用者的現在位置起算而在所定之範圍內的店舖。但是，使用者所能利用之店舖的檢索方法，係不限定於本實施形態中的例示。例如，可利用之店舖，係亦可從按照每一使用者或使用者所隸屬之群組而被預先作成的清單，來加以取得。又，可利用之店舖，係亦可基於藉由使用者或使用者所隸屬之群組而被預先指定的類別(例如和食、咖啡等)，而被抽出。例如，伺服器1，係基於從使用者終端9所得到的位置資訊及所被指定的類別、與資料庫21中所被保持的每一店舖的位置資訊及每一店舖所被設定的類別，而檢索出位於使用者之現在位置所定之範圍內且類別為一致/近似的店舖。一旦檢索出使用者所能利用的店舖，則伺服器1，係將檢索結果中所含之店舖的店舖資訊，發送至使用者終端9，並令其被顯示於使用者終端9(步驟S103)。此時，使用者終端9，係可將檢索結果，以清單形式加以顯示，亦可在地圖上加以顯示。使用者，係從使用者終端9中所被顯示的檢索結果，選擇出欲收取商品的店舖。

一旦藉由使用者而選擇店舖，則使用者終端9，係將已被使用者所選擇之店舖的店舖ID，通知給伺服器1。伺服器1，係一旦接收到來自使用者終端9之通知(步驟S104)，就將已被使用者所選擇之店舖中所能訂購的商品清單，從資料庫21加以取得(步驟S105)，並對使用者終端9進行送訊(步驟S106)。其後，本流程圖中所示的處理係結束。

使用圖3所說明的店舖/商品資訊提供處理中，從伺服器1接收到商品清單的使用者終端9，係將已接收之商品清單加以顯示，並受理來自使用者的商品選擇。使用者，係從已被顯示的商品清單，選擇出欲訂購之商品，指定商品的個數，並輸入訂購指示。又，此時，使用者係亦可輸入取貨預定時間。此處，所謂取貨預定時間，係將使用者想要取貨商品的時間，以「〇〇分鐘後」或時刻之形式來加以指定。

然後，此時，若使用者針對該當訂單而認為可受理搭便車訂購的情況下，則將已取貨之搭便車訂購所涉及之商品的卸貨場所(搭便車訂購的第二使用者之商品的送達場所)，予以輸入。一旦藉由使用者輸入了訂單所需使用的資訊及訂購指示，則使用者終端9，係基於已被使用者所輸入之資訊而生成訂單資訊，對伺服器1進行送訊。此處，訂單資訊係包含有：使用者ID、店舖ID、商品資訊、價格、個數、取貨預定時間、及搭便車訂購商品之卸貨場所等之資訊。

圖4及圖5係為本實施形態所述之訂單管理處理之流程的流程圖。本流程圖中所示的處理，係以接收到已被使用者終端9所發送之訂單資訊的這件事情為契機，而被執行。

在步驟S201及步驟S202中，身為搭便車訂購之主持人的使用者(第一使用者)所致之訂單，係被受理。第一訂單受理部22，係將從使用者終端9所被發送之訂單資訊予以接收，並藉由與使用者終端9進行通訊，以受理使用者所致之商品的訂單(步驟S201)。在本實施形態中，配合訂單之受理，基於從使用者終端9所被接收或使用者資訊中所含有之該當使用者的結帳資訊(信用卡資訊或點數資訊等)，該當訂單所涉及之支付會被處理。藉由訂單受理之時點上完成支付處理，使用者在將商品進行取貨之際，可省略在店舖中的支付。此外，支付處理係採用先前的技術即可，因此支付處理的詳細說明係省略。受理了訂單的伺服器1，係對該當訂單資訊賦予訂單ID，並將含有：訂單ID、使用者ID、店舖ID、商品資訊、價格、個數、取貨預定時間、及搭便車訂購商品之卸貨場所等之資訊的訂單資訊，儲存在資料庫21中(步驟S202)。其後，處理係往步驟S203前進。

在步驟S203及步驟S204中，搭便車訂購的受理期間係被決定。擁擠狀況資訊取得部24，係將步驟S201中所被接收之訂單資訊中所被表示的店舖ID所涉及之店舖的擁擠狀況資訊，加以取得(步驟S203)。此處所被取得的擁擠狀況資訊，係亦可為從預先店舖被通知給伺服器1而藉由伺服器1與店舖ID建立關連而加以保持的表示該當店舖的現在之擁擠狀況的資訊，亦可為在該當訂單之時間點上藉由從伺服器1向店舖終端7進行查詢以從店舖終端7所獲得的擁擠狀況資訊。受理期間決定部25係決定，對於步驟S201中所被接收之訂單資訊所涉及之訂單的可受理搭便車訂購的受理期間(步驟S204)。其後，處理係往步驟S205前進。

在步驟S205及步驟S206中，搭便車訂購的受理係被開始。使用者特定部26，係基於步驟S201中所被接收之訂單資訊中所被表示的使用者ID，而將要邀請至以該當使用者為主持人(第一使用者)之搭便車訂購的使用者(第二使用者)，加以特定(步驟S205)。第二使用者的特定，係可用各種方法來進行。例如，使用者特定部26，係可從已被第一使用者所預先指定的清單中，特定出第二使用者。又，例如，使用者特定部26，係可將第一使用者所隸屬之群組中所屬的其他使用者，加以特定。此外，分群係可採用，對使用者資訊記錄下該當使用者所隸屬之群組之群組ID的方式，及/或在群組的成員清單中記錄下隸屬於該當群組之使用者的使用者ID的方式等。.

一旦可搭便車之第二使用者被特定，則受理通知部27，係將已被特定之第二使用者之位址從資料庫21加以取得，向已被取得之位址，通知搭便車訂購之受理已經成為可能(搭便車提案。步驟S206)。具體而言，受理通知部27，係在位址是郵件位址的情況下則發送電子郵件，是IP位址等之可識別使用者終端之位址的情況下則向在使用者終端中動作的應用程式發送推播通知等。該當通知中係含有：第一訂單的訂單ID、第一使用者的使用者ID，搭便車訂購為可能的店舖(具體而言係為第一使用者的訂單所涉及之店舖)、搭便車訂購之受理期間、及搭便車訂購商品之卸貨場所等。又，該當通知中亦可還含有第一使用者所訂購之商品資訊等。接收到通知的第二使用者的使用者終端9，係將搭便車訂購係為可能之事實，併同從伺服器1所被提供之資訊，亦即加上搭便車訂購為可能之店舖、搭便車訂購之受理期間、及搭便車訂購商品之卸貨場所等，而顯示可訂購的商品清單。其後，處理係往步驟S207前進。

在步驟S207及步驟S208中，於搭便車訂購的受理期間內，收到搭便車訂購可能通知的使用者所致之搭便車訂購，係被受理。第二訂單受理部28，係直到步驟S204中所被算出之搭便車訂購之受理期間經過以前(步驟S208)，都會將來自於收到搭便車訂購可能通知之使用者終端9的第二訂單(搭便車訂購)予以受理(步驟S207)。第二訂單受理部28，係直到步驟S204中所被算出之搭便車訂購之受理期間經過以前，可從複數個不同的使用者，受理複數個不同的訂單。又，在搭便車訂購之受理期間經過以前之期間中，在第一使用者的使用者終端9上，訂單資訊通知部31係可令其他使用者已經參加、或搭便車訂購之狀況等，予以逐次通知、顯示。

此外，對於搭便車訂購的受理，亦可被設定有受理期間以外之限制。例如，主持人(第一使用者)所能取貨的商品的量係有限度，因此亦可隨應於店舖或商品之種類，而對可搭便車訂購的使用者數、或1個訂單資訊捆包中所能夠包含的商品之數量等，設下限制。

收到受理通知部27所致之通知的第二使用者，係在欲進行搭便車訂購的情況下，於搭便車訂購之受理期間內，可使用自己的終端而向伺服器1進行商品的訂購。具體而言，收到通知的第二使用者，係從通知所涉及之店舖中可訂購的商品清單，選擇出欲訂購的商品，指定商品的個數，並輸入訂購指示。一旦藉由第二使用者輸入了訂單所需使用的資訊，則第二使用者的使用者終端9，係基於已被第二使用者所輸入之資訊而生成第二訂單資訊，對伺服器1進行送訊。此處，第二訂單資訊係含有：第一使用者所致之第一訂單的訂單ID、第二使用者的使用者ID、店舖ID、商品資訊、價格、個數等之資訊。

此外，在本實施形態中係說明，作為用來識別這是哪個第一訂單所涉及之搭便車訂購所需之資訊，是使用第一訂單的訂單ID的例子。但是，作為用來識別這是哪個第一訂單所涉及之搭便車訂購所需之資訊，係亦可採用第一使用者的使用者ID等，其他資訊。又，伺服器1與使用者終端9係彼此通訊而受理第二訂單資訊，此時點上該當搭便車訂購所涉及之支付係被處理，係和步驟S201中所說明的內容概略相同，因此省略說明。藉由在訂單受理之時點上先完成支付處理，就可省略第一使用者(主持人)與第二使用者(搭便車使用者)之間的結算。其後，處理係往步驟S209前進。

在步驟S209至步驟S210中，搭便車訂購所涉及之下單處理係被進行。訂單資訊關連建立部29，係將步驟S201中從第一使用者所被受理之第一訂單資訊、與步驟S208中所被受理之第二訂單資訊建立關連，藉此以將這些複數個訂單資訊當作1個訂單資訊捆包(步驟S209)。然後，下單部30，係將步驟S209中所被建立關連的複數個訂單資訊，當作1個訂單資訊捆包而發送至店舖終端7(步驟S210)。店舖，係確認於店舖終端7中所被受理之訂單資訊捆包中所包含之訂單，在訂單資訊捆包中所含之取貨預定時間內，準備好商品，等待第一使用者所致之商品的取貨。其後，處理係往步驟S211前進。

在步驟S211至步驟S214中，關於商品之取貨的狀況之更新及通知，係被進行。一旦商品之下單完成，則訂單資訊通知部31，係將步驟S208中所被受理之第二訂單資訊、及對店舖的下單已經完成之事實，通知給第一使用者的使用者終端9(步驟S211)。藉由如此設計，搭在有便車訂單的情況下，第一使用者就可掌握自己所需要取貨的商品。但是，關於搭便車訂購之內容，係亦可在步驟S208中每次受理了搭便車訂購時，就被通知給第一使用者。第一使用者，係在取貨預定時間內，自己前往進行了訂購的店舖，將自己所訂購之商品、與搭便車訂購所涉及之商品，予以取貨。

伺服器1，係從店舖終端7接收商品之準備已經完成(商品的取貨已經可能)之意旨的通知，或在已經經過了取貨預定時間的情況下，令第一使用者的使用者終端9顯示出，已取貨商品之第一使用者抵達分配場所，並要將商品進行卸貨(配送)的情況下，所被操作的按鈕(例如「I’m Back」按鈕等)(步驟S212)。在店舖中進行了取貨並已將商品卸貨的第一使用者一旦操作該當按鈕，則使用者終端9，係將該當按鈕已被操作之意旨通知給伺服器1，接收到該當通知的(步驟S213)伺服器1的狀況通知部32，係對進行了搭便車訂購的第二使用者的使用者終端9，通知商品已經被卸貨在所被預先指定的分配場所(步驟S214)。其後，處理係往步驟S215前進。

在步驟S215中，係對第一使用者，賦予獎勵。伺服器1，係對完成了身為搭便車訂購之主持人之角色的第一使用者，賦予點數或優惠券等之獎勵，與使用者ID建立關連而保存在資料庫中。此時，藉由點數或優惠券而第一使用者所能夠收取的獎勵的量，係可隨著這次的搭便車訂購中擔任主持人所負擔的責任或負荷之大小，而做變動。例如，伺服器1，係可將對第一使用者所賦予的獎勵的量，使用像是「進行了搭便車訂購的使用者之數量＊所定點數」或「已被搭便車訂購之商品的量＊所定點數」、「已被搭便車訂購之金額＊所定比率」這類的算出方法，予以算出。其後，本流程圖中所示的處理係結束。

先前，在事前點餐外帶服務中，例如，某個使用者，和與該當使用者在相同職場中工作的複數個使用者，係對同一店舖，在相同的時間帶(時間點)進行了訂購的情況下，必須每個人都要去店舖拿取商品才行，這就是助長店舖擁擠的原因。又，由各使用者對店舖分別進行訂購，也增大了店舖與伺服器間的通訊負荷。

可是，若依據上記說明的實施形態所述之系統，則針對搭便車訂購係由第一使用者來擔任主持人而前往店舖去取貨，因此可緩和店舖的擁擠。又，若依據本實施形態所述之系統，則由於可以增加考量商品的準備時間、進行了訂購的使用者抵達店舖為止的移動時間、店舖之擁擠狀況等，來控制能夠讓其他使用者進行搭便車訂購的期間，因此可減輕伺服器1、終端及店舖之間的通訊負荷。甚至，關於費用的結帳係在店舖與各使用者之間被進行，因此第一使用者(主持人)所致之取貨作業不會變得麻煩。

＜變形例＞在上記說明的實施形態中，雖然說明了將本揭露所述之技術適用於事前點餐外帶型服務所需之系統的例子，但本揭露所述之技術，係可廣泛適用於可搭便車訂購之技術，本揭露的適用對象，係不限定於事前點餐外帶型服務。例如，本揭露所述之技術，係亦可被適用於遞送服務所需之系統。

將本揭露所述之技術適用於遞送服務所需之系統的情況下，在上記說明的具體處理內容之中，第一使用者所致之取貨/卸貨所需之處理，係被置換成配送員所致之遞送所需之處理。具體而言，例如，移動時間取得部23，係取得配送員抵達店舖所需要的移動時間，受理期間決定部25，係不是基於「(1)已被第一使用者或店舖所指定的預定」，而是基於「(1b)已被配送員或店舖所指定的預定」，來決定受理期間。又，訂單資訊通知部31，係將訂單資訊通知給配送員，狀況通知部32，係將關於配送員所致之商品的取貨及/或卸貨的狀況，通知給第一使用者及第二使用者。然後，在使用圖4及圖5的流程圖所說明的處理之中，例如，已取貨商品的配送員抵達了分配場所時所被操作的按鈕(參照步驟S212)，係被顯示於配送員的終端，而被配送員所操作。其他，為了將本揭露所述之技術適用於遞送服務，可採用各種變更。

又，伺服器1，係亦可將使用者所隸屬之群組所致之搭便車訂購服務的利用狀況，對該當使用者的使用者終端進行提供，透過在使用者終端上動作的為了利用本揭露所述之服務所需之應用程式，而可讓使用者瀏覽利用狀況。又，伺服器1，係亦可即使對於參加搭便車訂購的第二使用者，也隨應於該當第二使用者的利用狀況或群組的利用狀況而賦予獎勵，藉此以促進服務之利用。

又，從伺服器1被發送至店舖的訂單資訊中亦可包含有，從資料庫所被取得的，為了取貨而造訪店舖的人(事前點餐外帶型服務的情況下係為第一使用者，遞送服務的情況下則為配送員)的外觀資訊(肖像等)。藉由如此設計，店舖就可容易辨識為了取貨而造訪店舖的使用者。但是，店舖中的使用者判別方法，係亦可為將使用者所提示的ID(可以實體媒體來提示，亦可用電子方式來提示)以店舖側進行讀取等之方法。

甚至，在上記說明的實施形態中，關於費用的結帳係在店舖與各使用者之間被進行，但亦可取代如此方法，改為由第一使用者當作代表而針對全部的訂單先支付費用，在取貨之前或後的任意之時間點上從第二使用者回收該當第二使用者部分的費用。又，關於此時的第一使用者與第二使用者之間的結算，也是可以使用已被登錄在伺服器1中的每位使用者的結帳手段，而被處理。

1:伺服器 7:店舖終端 9:使用者終端 11:CPU 12:ROM 13:RAM 14:記憶裝置 15:通訊單元 21:資料庫 22:第一訂單受理部 23:移動時間取得部 24:擁擠狀況資訊取得部 25:受理期間決定部 26:使用者特定部 27:受理通知部 28:第二訂單受理部 29:訂單資訊關連建立部 30:下單部 31:訂單資訊通知部 32:狀況通知部

[圖1]實施形態所述之資訊處理系統的硬體構成之概略的圖示。 [圖2]實施形態所述之資訊處理系統的機能構成之概略的圖示。 [圖3]實施形態所述之店舖/商品資訊提供處理之流程的流程圖。 [圖4]實施形態所述之訂單管理處理之流程的流程圖(A)。 [圖5]實施形態所述之訂單管理處理之流程的流程圖(B)。

1:伺服器

7:店舖終端

9:使用者終端

21:資料庫

22:第一訂單受理部

23:移動時間取得部

24:擁擠狀況資訊取得部

25:受理期間決定部

26:使用者特定部

27:受理通知部

28:第二訂單受理部

29:訂單資訊關連建立部

30:下單部

31:訂單資訊通知部

32:狀況通知部

Claims

一種資訊處理裝置，係具備：第一訂單受理手段，係用以從使用者終端受理第一訂單；和使用者特定手段，係用以將前記第一訂單所涉及之第一使用者所被預先建立關連對應到的1個以上之第二使用者，加以特定；和第二訂單受理手段，係用以在前記第一訂單已被受理後，於所定之期間內，從1個以上之前記第二使用者受理1個以上之第二訂單；和訂單資訊關連建立手段，係用以將前記第一訂單所涉及之訂單資訊與前記第二訂單所涉及之訂單資訊建立關連，當作訂單所涉及之店舖是需要合併安排的訂單資訊捆包。
如請求項1所記載之資訊處理裝置，其中，還具備：受理期間決定手段，係用以在已經受理了前記第一訂單的情況下，決定可受理該第一訂單所涉及之前記第二訂單的受理期間；前記第二訂單受理手段，係於前記受理期間中，受理前記第二訂單。
如請求項2所記載之資訊處理裝置，其中，還具備：移動時間取得手段，係用以取得前記第一使用者抵達店舖所需要的移動時間；前記受理期間決定手段，係至少基於前記移動時間，來決定前記受理期間。
如請求項2或3所記載之資訊處理裝置，其中，前記受理期間決定手段，係至少基於前記第一訂單中所含之商品之準備完成為止的準備時間，來決定前記受理期間。
如請求項4所記載之資訊處理裝置，其中，還具備：擁擠狀況資訊取得手段，係用以從前記第一訂單所涉及之店舖的店舖終端，取得該店舖的擁擠狀況資訊；前記受理期間決定手段，係至少基於前記準備時間及前記擁擠狀況資訊，來決定前記受理期間。
如請求項2或3所記載之資訊處理裝置，其中，前記受理期間決定手段，係基於已被前記第一使用者或店舖所指定的預定，來決定前記受理期間。
如請求項1至3之任一項所記載之資訊處理裝置，其中，還具備：受理通知手段，係用以在前記第一訂單已被受理後，對已被前記使用者特定手段所特定之前記第二使用者，通知前記第二訂單之受理。
如請求項1至3之任一項所記載之資訊處理裝置，其中，前記使用者特定手段，係將與前記第一使用者隸屬於同一群組的其他使用者，特定成為前記第二使用者。
如請求項1至3之任一項所記載之資訊處理裝置，其中，前記使用者特定手段，係將已被前記第一使用者所預先指定的其他使用者，特定成為前記第二使用者。
如請求項1至3之任一項所記載之資訊處理裝置，其中，還具備：訂單資訊通知手段，係用以將已被前記第二訂單受理手段所受理之前記第二訂單所涉及之訂單資訊，通知給前記第一使用者。
如請求項1至3之任一項所記載之資訊處理裝置，其中，還具備：狀況通知手段，係用以將關於前記第一使用者所致之商品之取貨及/或卸貨的狀況，通知給前記第二使用者。
如請求項1至3之任一項所記載之資訊處理裝置，其中，還具備：下單手段，係用以將前記訂單資訊捆包所涉及之下單當作1筆下單而對店舖進行送訊。
一種資訊處理方法，係由電腦來執行以下步驟：藉由第一訂單受理部，從使用者終端受理第一訂單；藉由使用者特定部，將前記第一訂單所涉及之第一使用者所被預先建立關連對應到的1個以上之第二使用者，加以特定；藉由第二訂單受理部，在前記第一訂單已被受理後，於所定之期間內，從1個以上之前記第二使用者受理1個以上之第二訂單；藉由訂單資訊關連建立部，將前記第一訂單所涉及之訂單資訊與前記第二訂單所涉及之訂單資訊建立關連，當作訂單所涉及之店舖是需要合併安排的訂單資訊捆包。
一種程式產品，係用來使電腦發揮機能而成為：第一訂單受理手段，係用以從使用者終端受理第一訂單；和使用者特定手段，係用以將前記第一訂單所涉及之第一使用者所被預先建立關連對應到的1個以上之第二使用者，加以特定；和第二訂單受理手段，係用以在前記第一訂單已被受理後，於所定之期間內，從1個以上之前記第二使用者受理1個以上之第二訂單；和訂單資訊關連建立手段，係用以將前記第一訂單所涉及之訂單資訊與前記第二訂單所涉及之訂單資訊建立關連，當作訂單所涉及之店舖是需要合併安排的訂單資訊捆包。