TWI613611B - 點餐資訊互動方法、客戶顯示裝置、點餐資訊管理方法及伺服器 - Google Patents

Abstract

一種點餐資訊互動方法，由一客戶顯示裝置執行，與一伺服器連線，包含：(A)自該伺服器讀取一第一店家之一目前用餐號碼及相關於一第一訂位人數的一第一等待訂單數；(B)顯示該目前用餐號碼及該第一等待訂單數；(C)顯示一電子菜單之使用者操作介面並受控產生一第一訂單；(D)傳送該第一訂單至該伺服器，並自該伺服器接收一取餐號碼及一預計取餐時間，其中該預計取餐時間是根據該第一等待訂單數計算；及(E)顯示該取餐號碼及該預計取餐時間。藉此能根據不同的訂位人數顯示訂餐狀況，再據以提供點餐的功能。

Description

點餐資訊互動方法、客戶顯示裝置、點餐資訊 管理方法及伺服器

本發明是有關於一種點餐資訊互動方法，特別是指一種點餐資訊互動方法、客戶顯示裝置、點餐資訊管理方法及伺服器。

現有的賣場或是百貨公司的店家資訊顯示裝置，是以單純顯示各個店家或餐廳的名稱及位置為主，欲用餐的使用者根據顯示的餐廳位置前往餐廳後再進行點餐。在用餐時段，餐廳的櫃台前常大排長龍，許多等待入場點餐的客戶均需花費大量時間排隊等待，且點餐後還需再次等待以便取餐。因此，如何開發一種具整合性且具即時性的系統，供使用者點餐以及提醒使用者取餐，就成為一值得研究的主題。

本發明之一目的，即在提供一種能根據不同的 訂位人數顯示訂餐狀況的點餐資訊互動方法及其相關的客戶顯示裝置，以解決上述之問題。

本發明之另一目的，即在提供一種能根據不同的訂位人數顯示訂餐狀況的點餐資訊管理方法及其相關的點餐資訊管理的伺服器。

為達上述目的及其他目的，本發明點餐資訊互動方法在一些實施態樣中，是由一客戶顯示裝置執行，該客戶顯示裝置與一伺服器連線，並包含一處理單元及一與該處理單元連接的顯示單元，該方法包含以下步驟：

(A)該處理單元自該伺服器讀取一第一店家之一目前用餐號碼及相關於一第一訂位人數的一第一等待訂單數。

(B)該顯示單元顯示該目前用餐號碼及相關於該第一訂位人數的第一等待訂單數。

(C)該顯示單元顯示該第一店家的一電子菜單之使用者操作介面，並受控使該處理單元產生一第一訂單。

(D)該處理單元傳送該第一訂單至該伺服器，並自該伺服器接收一取餐號碼及一預計取餐時間，其中該預計取餐時間是根據該第一等待訂單數計算而相關於該第一訂位人數。

(E)該顯示單元顯示該取餐號碼及該預計取餐時間。

在一些實施態樣中，步驟(A)中該處理單元 還自該伺服器讀取多個第二店家之多個第二店家目前用餐號碼及相關於該第一訂位人數的多個第二店家等待訂單數；步驟(B)是顯示該等第二店家目前用餐號碼及該等第二店家等待訂單數；步驟(C)中該顯示單元是接收選擇該第一店家之輸入後顯示該第一店家的該電子菜單之使用者操作介面，並受控使該處理單元產生該第一訂單。

在一些實施態樣中，該客戶顯示裝置還包含一與該處理單元連接的讀卡單元，該方法還包含於步驟(C)與(D)間執行的步驟(F)及(G)：

(F)該處理單元判斷是否接收到一確認結帳之輸入。

(G)當步驟(F)判斷為是，該處理單元使該讀卡單元讀取卡片，該處理單元並執行結帳作業。

在一些實施態樣中，還包含於步驟(C)與(D)間執行的步驟(H)：該處理單元判斷是否接收到一確認訂位之輸入，若是，進行步驟(D)。

在一些實施態樣中，該客戶顯示裝置還包含一與該處理單元連接的列印單元，該方法還包含於步驟(D)後執行的步驟(I)：該列印單元列印該取餐號碼、該預計取餐時間及一相關於該第一訂單的取餐資訊的第一條碼。

在一些實施態樣中，該第一訂單的取餐資訊包含該取餐號碼及可供連線至該伺服器以查詢可更新之該預計取餐時間的網頁位址或應用程式之連結。

於是，本發明客戶顯示裝置在一些實施態樣中，執行如所述點餐資訊互動方法。

於是，本發明點餐資訊管理方法在一些實施態樣中，是由一伺服器執行，該伺服器與一客戶顯示裝置連線，該伺服器儲存有一第一店家的下列資訊：一取餐號碼及相關於一第一訂位人數的一第一等待訂單數及一第一時間估算參數；該方法包含以下步驟：

(a)該伺服器自該客戶顯示裝置接收具有該第一訂位人數的一第一訂單。

(b)將該取餐號碼加一。

(c)將該第一等待訂單數加一。

(d)根據第一等待訂單數、第一時間估算參數計算預計取餐時間。

(e)向該客戶顯示裝置傳送該取餐號碼及該預計取餐時間。

在一些實施態樣中，還包含於步驟(b)及(c)間執行的步驟(f)：根據該取餐號碼判斷第一訂單是否可取餐；步驟(c)是當步驟(f)之判斷為否時將該第一等待訂單數加一。

在一些實施態樣中，該方法還包含以下步驟：

(g)接收一具有第一訂位人數的用餐完畢通知。

(h)計算第一等待訂單數及該預計取餐時間。

在一些實施態樣中，步驟(h)包含以下步驟：

(h1)判斷第一等待訂單數是否大於0。

(h2)當步驟(h1)判斷為是，將第一等待訂單數減一。

(h3)根據第一等待訂單數、第一時間估算參數計算該預計取餐時間。

在一些實施態樣中，該伺服器還與一餐廳內裝置連線，該方法還包含以下步驟：

(i)自餐廳內裝置接收該取餐號碼。

(j)根據該取餐號碼判斷第一訂單是否可取餐。

(k)當步驟(j)判斷為是，使餐廳內裝置發出警示。

在一些實施態樣中，該伺服器還儲存有該第一店家的下列資訊：具有該第一訂位人數的至少一筆處於用餐中狀態之第二訂單的取餐號碼及至少一筆處於尚未用餐狀態之第三訂單的取餐號碼，以及相關於該第一訂位人數的一第一上限，所述根據該取餐號碼判斷第一訂單是否可取餐，是判斷：該第一訂單的取餐號碼減去一入場順位號碼後是否大於或小於或等於一閒置桌數，若大於該閒置桌數，則判斷結果為否，若小於或等於該閒置桌數則判斷結果為是；其中，該入場順位號碼為小於任一第三訂單的取餐號碼之第二訂單的取餐號碼中的最大值，該閒置桌數為該第一上限減該第二訂單的數量。

在一些實施態樣中，該伺服器還儲存有該第一店家的一目前用餐號碼，步驟(k)還將該目前用餐號碼加一，步驟(e)還向該客戶顯示裝置傳送該目前用餐號碼。

在一些實施態樣中，該伺服器還提供一顯示可更新之該第一訂單之該預計取餐時間的網頁，該第一訂單之該預計取餐時間的更新方式是根據具有該第一訂位人數且取餐號碼小於該第一訂單的取餐號碼的其他訂單數量及該第一時間估算參數計算。

在一些實施態樣中，該伺服器還儲存該第一訂單的一後補序號，於步驟(a)中還使該後補序號等於該第一等待訂單數；當該伺服器接收一具有第一訂位人數的用餐完畢通知，還將該後補序號減一；該第一訂單之該預計取餐時間的更新方式是根據該後補序號及該第一時間估算參數計算。

於是，本發明用於點餐資訊管理的伺服器在一些實施態樣中，執行如所述點餐資訊管理方法。

本發明之功效在於：透過客戶顯示裝置根據不同的訂位人數顯示訂餐及取餐的狀況，再據以提供點餐的功能，使得使用者可以透過客戶顯示裝置知悉每一店家分別對應之目前用餐號碼，以及相關於特定訂位人數的等待訂單數，並可進一步進行點餐而產生訂單。

1‧‧‧伺服器

2‧‧‧客戶顯示裝置

21‧‧‧處理單元

22‧‧‧顯示單元

23‧‧‧列印單元

24‧‧‧讀卡單元

3‧‧‧餐廳內裝置

31‧‧‧處理器

32‧‧‧顯示器

33‧‧‧條碼掃描器

4‧‧‧電子佈告欄

41‧‧‧訂位人數欄位

42‧‧‧店家資訊欄位

5‧‧‧電子菜單之使用者操作介面

51‧‧‧結帳確認視窗

S11~S19‧‧‧步驟

S21~S26‧‧‧步驟

S31~S34‧‧‧步驟

S41~S44‧‧‧步驟

本發明之其他的特徵及功效，將於參照圖式的 實施例詳細說明中清楚地呈現，其中：圖1是一方塊圖，說明本發明實施例的一伺服器、一客戶顯示裝置及一餐廳內裝置；圖2是一流程圖，說明本發明實施例之點餐資訊互動方法；圖3是一示意圖，說明該實施例的一電子佈告欄；圖4是一示意圖，說明該實施例的一電子菜單之使用者操作介面；圖5是一示意圖，說明該電子菜單之使用者操作介面；圖6是一示意圖，說明該實施例列印之一取餐號碼、一預計取餐時間及一第一條碼；圖7是一流程圖，說明本發明實施例之點餐資訊管理方法相關於接收一第一訂單所執行之步驟；圖8是一流程圖，說明該點餐資訊管理方法相關於用餐完畢通知所執行之步驟；及圖9是一流程圖，說明該點餐資訊管理方法相關於取餐所執行之步驟。

在本發明被詳細描述之前，應當注意在以下的說明內容中，類似的元件是以相同的編號來表示。

參閱圖1至圖3，本發明實施例之點餐資訊互動方法，由一客戶顯示裝置2執行，該客戶顯示裝置2與一伺服器1連線。本發明實施例之點餐資訊管理方法，則由該伺服器1執行，此部分容後說明。該客戶顯示裝置2 包含一處理單元21及與該處理單元21連接的一顯示單元22、一列印單元23及一讀卡單元24，在本實施例中該客戶顯示裝置2即是所謂的「POS機(POS全文：Point of sale，銷售點)」，該顯示單元22在本實施例中是一觸控顯示螢幕，但不以此為限，只要能方便客戶操作即可。該方法包含以下步驟：

步驟S11-讀取一第一訂位人數(預設或選取)。詳細而言，該處理單元21使該顯示單元22顯示一電子佈告欄4，其中包含一訂位人數欄位41，可供選擇不同的訂位人數，例如1、2、4、6、8、10人，其中最大值為10人，預設值為2人，當使用者尚未選擇時，本步驟所讀取的該第一訂位人數為預設的2人，當使用者選擇其他人數後，本步驟所讀取的該第一訂位人數即為使用者選擇的人數。

步驟S12-該處理單元21自該伺服器1讀取各店家之店家目前用餐號碼及相關於該第一訂位人數的店家等待訂單數並顯示。為方便說明，以下將各店家區分為一第一店家及多個第二店家，並以第一店家為「安平豆花」，第二店家為其餘之店家為例。在本步驟中，該處理單元21自該伺服器1讀取第一店家(安平豆花)之目前用餐號碼(325)及相關於第一訂位人數的第一等待訂單數(0)，並讀取多個第二店家之多個第二店家目前用餐號碼及相關於該第一訂位人數的多個第二店家等待訂單數。然後在電子佈告欄4的一店家資訊欄位42顯示該第一店家及該等第 二店家的名稱、位置、該目前用餐號碼與該等第二店家目前用餐號碼，及該第一等待訂單數與第二店家等待訂單數。其中，該等店家的位置舉例而言是以在顯示畫面上的位置示意顯示。

值得一提的是，由於顯示的是相關於第一訂位人數的第一等待訂單數，可精確反應出第一訂位人數之訂單等待的狀況。

步驟S13-該顯示單元22接收選擇第一店家之輸入，並顯示對應該第一店家之電子菜單之使用者操作介面5(如圖4、圖5)。

步驟S14-該顯示單元22接收於該電子菜單之點餐輸入，使該處理單元21生成一第一訂單。如圖4，舉例而言，使用者選擇「紅豆豆花」1個，按下一結帳確認視窗51中的是，進入圖5之畫面，進行步驟S15。

步驟S15-確認是否結帳？詳細而言，該電子菜單之使用者操作介面5顯示該結帳確認視窗51，該處理單元21判斷是否接收到一確認結帳之輸入，若是，進入步驟S17，否則進入步驟S16。如圖5，舉例而言，該電子菜單之使用者操作介面5顯示使用者選擇了「紅豆豆花」1個及其價格，當按下該結帳確認視窗51中的「是」，進行步驟S17。在圖5所示之畫面中，還可顯示其他內容，諸如信用卡促銷優惠之文字或圖形等，鼓勵使用者一併進行結帳。

步驟S16-確認是否訂位？詳細而言，該處理 單元21判斷是否接收到一確認訂位之輸入(未圖示)，若是，進入步驟S18，否則結束流程。需說明的是，步驟S15與S16不以上述順序為限，也可以是步驟S16先於步驟S15執行，或是兩者同時執行，例如在該電子菜單之使用者操作介面5同時顯示結帳選項及只訂位而不結帳之選項等，此外，也可以只執行其中一步驟而只提供其中一選擇，例如，強制使用者必須結帳才能進行後續步驟。

若欲避免使用者在未結帳訂位後，未前往取餐付款，可結合會員機制，要求使用者以例如會員卡、信用卡或手機號碼登入，如果使用者於步驟S15結帳，在累積一定的消費金額，會有固定的折扣；如果未結帳訂位後，卻未取餐付款，則設置一定的罰則，例如該使用者之帳號不得使用訂位功能一個月等。

步驟S17-該處理單元21使該讀卡單元24讀取卡片，該處理單元21並執行結帳作業。該讀卡單元24舉例而言可讀取接觸式、非接觸式之可進行付款之卡片。以下進行步驟S18。

步驟S18-該處理單元21傳送第一訂單至伺服器1，並自伺服器1接收取餐號碼及預計取餐時間，該顯示單元22並顯示該取餐號碼及該預計取餐時間。補充說明的是，雖然在本步驟中傳送第一訂單後才取得確定之該取餐號碼，但在未取得確定之該取餐號碼前該處理單元21仍可根據目前已有訂單的取餐號碼來估算該第一訂單的取餐號碼，而於電子菜單之使用者操作介面5中顯示(如圖 5)。

值得一提的是，其中該預計取餐時間是根據該第一等待訂單數計算而相關於該第一訂位人數，以該第一訂位人數為2人為例，該第一等待訂單數即為訂位人數為2人之等待訂單數，所計算的預計取餐時間亦是根據訂位人數為2人的訂單來計算，因此預計取餐時間不會受到其他訂位人數之訂單的干擾而有較大的偏差。該預計取餐時間是由伺服器1所計算，此部分容後說明。以下進行步驟S19。

步驟S19-使列印單元23列印該取餐號碼、預計取餐時間及一相關於該第一訂單的取餐資訊的第一條碼(如圖6)。在本實施例中還列印目前時間，但不以此為限。其中，該第一訂單的取餐資訊包含該取餐號碼及可供連線至該伺服器1以查詢可更新之該預計取餐時間的網頁位址或應用程式之連結。

該第一條碼在本實施例中是以QR code為例，該第一條碼目的是，使用者可以藉由手機掃描QR code，連線到一網頁或一應用程式相關頁面，使手機執行瀏覽器或對應應用程式來即時提醒使用者目前用餐號碼，使用者的(該第一訂單的)取餐號碼，秀出預計的取餐時間，甚至將預計取餐時間和目前時間相減做一個倒數計時，等到使用者可以用餐的時候，手機就會以鈴聲和震動提醒使用者趕快到餐廳來用餐或取餐。等號碼的時間到了以後，使用者直接拿著這張熱感應紙去餐廳用餐或取餐。如果使用 者遺失熱感應紙的話，可透過剛剛的手機QR code掃描，在手機裡留一個訂位結帳記錄，做為一樣的憑證用餐。

總結來說，客戶顯示裝置2除了顯示各店家的名稱、位置，還根據不同的訂位人數顯示訂餐及取餐的狀況，再據以提供點餐的功能。使用者可以透過客戶顯示裝置2知悉該層樓可以點餐或訂位的地方，每一店家之目前用餐號碼，以及相關於特定訂位人數的等待訂單數，並可進一步進行點餐。

特別需強調的是，若無前述根據不同的訂位人數統計取餐狀況之技術，則會有餐廳桌位使用效率不彰的問題，舉例而言，當6人的桌位被使用中，使得訂位人數為6人的訂單處於等待狀態時，2人的桌位已有空位，但若訂單未區分訂位人數，則在6人的訂單之後產生的2人訂單，均需等待6人的訂單可取餐後，才可取餐。相同的例子套用在本實施例中，由於6人與2人的訂位人數是完全分開進行統計，不會有前述的狀況發生。

參閱圖1、7，以下說明本發明實施例之點餐資訊管理方法。該伺服器1除與該客戶顯示裝置連線外，還與一餐廳內裝置3連線。為配合前述點餐資訊互動方法，該伺服器1需執行點餐資訊管理方法以提供客戶顯示裝置2必要之資訊。該伺服器1儲存有第一店家的下列資訊：目前的取餐號碼及相關於第一訂位人數的第一等待訂單數及第一時間估算參數。該方法包含以下步驟：

步驟S21-自該客戶顯示裝置接收具有第一訂 位人數的第一訂單。如前所述，該第一訂單是客戶顯示裝置2於步驟S18(參閱圖2)傳送至該伺服器1。

步驟S22-將該取餐號碼加一。詳細而言，該取餐號碼的初始值為0，並隨訂單數量的增加而在本步驟中增加。

步驟S23-根據該取餐號碼判斷第一訂單是否可取餐。

為判斷第一訂單是否可取餐，該伺服器1還儲存有該第一店家的下列資訊：具有該第一訂位人數的多筆處於用餐中狀態之第二訂單的取餐號碼及多筆處於尚未用餐狀態之第三訂單的取餐號碼，以及相關於該第一訂位人數的一第一上限，所述根據該取餐號碼判斷第一訂單是否可取餐，是判斷：該第一訂單的取餐號碼減去一入場順位號碼後是否大於或小於或等於一閒置桌數，若大於該閒置桌數，則判斷結果為否，若小於或等於該閒置桌數則判斷結果為是；其中，該入場順位號碼為小於任一第三訂單的取餐號碼之第二訂單的取餐號碼中的最大值，該閒置桌數為該第一上限減該第二訂單的數量。

簡言之，是根據該第一訂位人數的訂單的用餐狀況進行判斷，該第一上限簡言之即為該第一店家的該第一訂位人數的「桌數」或「最大同時用餐訂單數」。

參閱表1，舉例而言，該第一訂位人數為2人，第一店家的該第一上限為5，並設有桌號01至05，其中除桌號04外均為用餐中，用餐中之取餐號碼分別為320 至322及324，也就是說，該等第二訂單的取餐號碼分別為320至322及324。

此外，進一步舉例，等待用餐的訂單的取餐號碼-也就是該等第三訂單的取餐號碼-分別為323及325，而該第一訂單的取餐號碼為326。

在此例中，「小於任一第三訂單的取餐號碼之第二訂單的取餐號碼」，也就是小於323且小於325之第二訂單的取餐號碼為320、321、322，當中的最大值為322，因此該入場順位號碼即為322。

該等處於用餐中狀態之第二訂單的取餐號碼為320至322及324，其數量為4，因此該第一上限(5)減該等處於用餐中狀態之第二訂單的數量(4)，即5-4=1，得到該閒置桌數為1。

「該第一訂單的取餐號碼減去一入場順位號碼後是否大於或小於或等於一閒置桌數，若大於該閒置桌數，則判斷結果為否，若小於或等於該閒置桌數則判斷結 果為是」即是判斷是否「該第一訂單的取餐號碼-322≦1」，由此可知在此例中可取餐的取餐號碼須小於或等於323才會使判斷結果為是，但此例中該第一訂單的取餐號碼為326，因此代入判斷是否可取餐的結果為否。

此外，為避免部分使用者到號未取餐的情況，而產生空桌過久的情形，在本例中，可進一步在當取餐號碼323成為可取餐的時間點後一預定時間長度後，自動或受控取消保留其位置(暫時視同已用餐完畢，見步驟S31)，以使後續訂單能順利取餐，該預定時間長度可視其是否已結帳而定；而取消保留其位置後，亦可以人工或其他計算方式延後其入場時間，或進行其他處理。

但判斷是否可取餐的方式不以上述為限，只要能針對各訂位人數進行統計及判斷即可。當本步驟之判斷若為否，進行步驟S24，若為是則進行步驟S25。

步驟S24-第一等待訂單數加一。本步驟意謂該第一訂單尚未可取餐，因此將第一等待訂單數加一，然後進行步驟S25。

詳細而言，該第一等待訂單數的初始值為0，延續前述該第一上限為5之例，前五筆訂單產生時，經步驟S23之判斷必然均為是，因為縱使前四筆訂單在第五筆訂單產生時均處於用餐中，閒置桌數仍為1，因此第五筆訂單仍可取餐。且當第五筆訂單產生完畢時，該第一等待訂單數仍會為0，也就是前述步驟S12中該客戶顯示裝置2顯示的該第一等待訂單數仍為0。

有多種情況會產生如表1的狀態，為簡化起見，以前五筆訂單之取餐號碼即為320至324(以下以取餐號碼簡稱各訂單，例如：320訂單~324訂單)為例，且表1的狀態未改變的情況來說明，此時第一等待訂單數即為0，當325訂單開始由步驟S11進行訂位流程時，該客戶顯示裝置2顯示的該第一等待訂單數仍為0，而在進入步驟S23時，325訂單將被判斷為不可取餐，因此該第一等待訂單數加一而成為1，而在326訂單開始由步驟S11進行訂位流程時，該客戶顯示裝置2顯示的該第一等待訂單數亦為1。當326訂單隨著流程進入步驟S23時，將被判斷為不可取餐，因此該第一等待訂單數會再加一而成為2。

以下進入步驟S25。

步驟S25-根據第一等待訂單數、第一時間估算參數計算預計取餐時間。

再以該第一訂位人數為2人，第一等待訂單數為2為例，第一時間估算參數是由該第一店家所設定，若該第一店家沒有更改設定，則為該伺服器1或該餐廳內裝置3本身所儲存的一預設值，該第一時間估算參數包括一基本換桌時間10分鐘及一同時換桌調整權重80%，則預計取餐時間即為2×10×80%=16分鐘。但不以此為限。

步驟S26-向該客戶顯示裝置2傳送該取餐號碼及該預計取餐時間。

此外，該伺服器1還使第一店家的該餐廳內裝置3顯示該第一訂單的內容，以供第一店家準備餐點。

參閱圖1、8，該第一等待訂單數除了在步驟S24會變更外，當有客戶用餐完畢時亦需變更，因此，該方法還包含該伺服器1執行的以下步驟：

步驟S31-接收具有第一訂位人數的用餐完畢通知。該用餐完畢通知的產生方式有多種實施態樣，舉例而言，第一種方式是由餐廳內或餐桌上的攝影機監控，當影像分析一限定範圍內，均無人員影像超過一預設時間，即對伺服器發送用餐完畢通知；第二種方式是於椅子上裝設壓力感測器，每一桌所對應的多張椅子上的壓力感測器均沒有感測到壓力超過一預設時間，即對伺服器發送用餐完畢通知；第三種方式是餐廳人員透過該餐廳內裝置3輸入指令，該餐廳內裝置3便傳送該類型(幾人桌)的桌次及該訂單的號碼給伺服器，通知該訂單已用餐完畢；第四種方式是本步驟還計算每一訂單成為可取餐狀態後所經時間，當有訂單可取餐但經過前述(見【0073】段)預定時間長度後仍未取餐的情況下，為使後續訂單能順利取餐、避免空桌情況持續過久，該餐廳內裝置3自動或受控(提示餐廳人員進行操控)發出該用餐完畢通知。但不以此為限，不論何種方式，只要能使該伺服器1接收該用餐完畢通知即可。

步驟S32-判斷第一等待訂單數是否大於0，若是，進行步驟S33，否則進行步驟S34。

步驟S33-將第一等待訂單數減一。

步驟S34-根據第一等待訂單數、第一時間估 算參數計算預計取餐時間。

補充說明的是，該伺服器1還儲存該第一訂單的一後補序號，當該第一訂單產生時(步驟S21)，使該後補序號等於該第一等待訂單數。當該第一訂單產生後步驟S33又被執行時，還將該後補序號減一(但步驟S24並未將該後補序號加一)。該伺服器1還提供一顯示可更新之該第一訂單之該預計取餐時間的網頁，該第一訂單之該預計取餐時間的更新方式是根據具有該第一訂位人數且取餐號碼小於該第一訂單的取餐號碼的其他訂單及該第一時間估算參數計算，也就是：該後補序號×該基本換桌時間×該同時換桌調整權重。

參閱圖1、9，該餐廳內裝置3包括一處理器31及與該處理器31連接的一顯示器32及一條碼掃描器33，當使用者持列印出來之第一條碼至第一店家欲取餐時，該伺服器1還執行以下步驟：

步驟S41-接收餐廳內裝置3之條碼掃描器33掃描之第一條碼，解析出取餐號碼。

步驟S42-根據該取餐號碼判斷第一訂單是否可取餐，若是，進行步驟S43，否則進行步驟S44。本步驟的判斷方式與前述步驟S23相同，在此不再贅述。

步驟S43-使餐廳內裝置3發出警示，例如使其顯示器32顯示相關於第一訂單的取餐通知，告知第一店家的人員該第一訂單的客戶已前來取餐。

步驟S44-顯示預計取餐時間。本步驟是告知 該第一訂單的客戶尚未可取餐，並顯示其預計取餐時間。

此外，該伺服器1還儲存有該第一店家的目前用餐號碼，步驟S43還將該目前用餐號碼加一，步驟S26還向該客戶顯示裝置傳送該目前用餐號碼。該伺服器1亦儲存有多個第二店家的多個第二店家目前用餐號碼，其運作方式與對該第一店家的目前用餐號碼的處理方式相似，在此不再贅述。

以上即為本發明實施例之點餐資訊管理方法，該伺服器1可提供該客戶顯示裝置所需的資訊、傳送訂單、提供顯示預計取餐時間的網頁、發出取餐通知等功能，配合客戶顯示裝置2執行之本發明實施例之點餐資訊互動方法，能提供具整合性且具即時性的點餐及取餐功能，故確實能達成本發明之目的。

惟以上所述者，僅為本發明之實施例而已，當不能以此限定本發明實施之範圍，即大凡依本發明申請專利範圍及專利說明書內容所作之簡單的等效變化與修飾，皆仍屬本發明專利涵蓋之範圍內。

S11~S19‧‧‧步驟

Claims (15)

1. 一種點餐資訊互動方法，由一客戶顯示裝置執行，該客戶顯示裝置與一伺服器連線，並包含一處理單元及一與該處理單元連接的顯示單元，該方法包含以下步驟：(A)該處理單元自該伺服器讀取一第一店家之一目前用餐號碼及相關於一第一訂位人數的一第一等待訂單數；(B)該顯示單元顯示該目前用餐號碼及相關於該第一訂位人數的第一等待訂單數；(C)該顯示單元顯示該第一店家的一電子菜單之使用者操作介面，並受控使該處理單元產生一第一訂單；(D)該處理單元傳送該第一訂單至該伺服器，並自該伺服器接收一取餐號碼及一預計取餐時間，其中該預計取餐時間是根據該第一等待訂單數計算而相關於該第一訂位人數；及(E)該顯示單元顯示該取餐號碼及該預計取餐時間。
2. 如請求項1所述點餐資訊互動方法，其中，步驟(A)中該處理單元還自該伺服器讀取多個第二店家之多個第二店家目前用餐號碼及相關於該第一訂位人數的多個第二店家等待訂單數；步驟(B)是顯示該等第二店家目前用餐號碼及該等第二店家等待訂單數；步驟(C)中該顯示單元是接收選擇該第一店家之輸入後顯示該第一 店家的該電子菜單之使用者操作介面，並受控使該處理單元產生該第一訂單。
3. 如請求項1所述點餐資訊互動方法，其中，該客戶顯示裝置還包含一與該處理單元連接的讀卡單元，該方法還包含於步驟(C)與(D)間執行的步驟(F)及(G)：(F)該處理單元判斷是否接收到一確認結帳之輸入；(G)當步驟(F)判斷為是，該處理單元使該讀卡單元讀取卡片，該處理單元並執行結帳作業。
4. 如請求項1所述點餐資訊互動方法，還包含於步驟(C)與(D)間執行的步驟(H)：該處理單元判斷是否接收到一確認訂位之輸入，若是，進行步驟(D)。
5. 如請求項1所述點餐資訊互動方法，其中，該客戶顯示裝置還包含一與該處理單元連接的列印單元，該方法還包含於步驟(D)後執行的步驟(I)：該列印單元列印該取餐號碼、該預計取餐時間及一相關於該第一訂單的取餐資訊的第一條碼，該第一訂單的取餐資訊包含該取餐號碼及可供連線至該伺服器以查詢可更新之該預計取餐時間的網頁位址或應用程式之連結。
6. 一種客戶顯示裝置，執行如請求項1至5中任一請求項所述點餐資訊互動方法。
7. 一種點餐資訊管理方法，由一伺服器執行，該伺服器與一客戶顯示裝置連線，該伺服器儲存有一第一店家的下 列資訊：一取餐號碼及相關於一第一訂位人數的一第一等待訂單數及一第一時間估算參數；該方法包含以下步驟：(a)該伺服器自該客戶顯示裝置接收具有該第一訂位人數的一第一訂單；(b)將該取餐號碼加一；(c)將該第一等待訂單數加一；(d)根據第一等待訂單數、第一時間估算參數計算預計取餐時間；(e)向該客戶顯示裝置傳送該取餐號碼及該預計取餐時間。
8. 如請求項7所述點餐資訊管理方法，還包含於步驟(b)及(c)間執行的步驟(f)：根據該取餐號碼判斷第一訂單是否可取餐；步驟(c)是當步驟(f)之判斷為否時將該第一等待訂單數加一。
9. 如請求項7所述點餐資訊管理方法，該方法還包含以下步驟：(g)接收一具有第一訂位人數的用餐完畢通知；(h)計算第一等待訂單數及該預計取餐時間。
10. 如請求項9所述點餐資訊管理方法，其中，步驟(h)包含以下步驟：(h1)判斷第一等待訂單數是否大於0；(h2)當步驟(h1)判斷為是，將第一等待訂單數減一；及 (h3)根據第一等待訂單數、第一時間估算參數計算該預計取餐時間。
11. 如請求項7所述點餐資訊管理方法，其中，該伺服器還與一餐廳內裝置連線，並儲存有該第一店家的一目前用餐號碼，該方法還包含以下步驟：(i)自餐廳內裝置接收該取餐號碼；(j)根據該取餐號碼判斷第一訂單是否可取餐；及(k)當步驟(j)判斷為是，使餐廳內裝置發出警示，並將該目前用餐號碼加一；步驟(e)還向該客戶顯示裝置傳送該目前用餐號碼。
12. 如請求項8或11所述點餐資訊管理方法，其中，該伺服器還儲存有該第一店家的下列資訊：具有該第一訂位人數的至少一筆處於用餐中狀態之第二訂單的取餐號碼及至少一筆處於尚未用餐狀態之第三訂單的取餐號碼，以及相關於該第一訂位人數的一第一上限，所述根據該取餐號碼判斷第一訂單是否可取餐，是判斷：該第一訂單的取餐號碼減去一入場順位號碼後是否大於或小於或等於一閒置桌數，若大於該閒置桌數，則判斷結果為否，若小於或等於該閒置桌數則判斷結果為是；其中，該入場順位號碼為小於任一第三訂單的取餐號碼之第二訂單的取餐號碼中的最大值，該閒置桌數為該第一上限減該第二訂單的數量。
13. 如請求項7所述點餐資訊管理方法，其中，該伺服器還提供一顯示可更新之該第一訂單之該預計取餐時間的網頁，該第一訂單之該預計取餐時間的更新方式是根據具有該第一訂位人數且取餐號碼小於該第一訂單的取餐號碼的其他訂單數量及該第一時間估算參數計算。
14. 如請求項13所述點餐資訊管理方法，其中，該伺服器還儲存該第一訂單的一後補序號，於步驟(a)中還使該後補序號等於該第一等待訂單數；當該伺服器接收一具有第一訂位人數的用餐完畢通知，還將該後補序號減一；該第一訂單之該預計取餐時間的更新方式是根據該後補序號及該第一時間估算參數計算。
15. 一種用於點餐資訊管理的伺服器，執行如請求項7至14中任一請求項所述點餐資訊管理方法。