無線尋呼系統的製作方法

2023-09-15 00:04:30

專利名稱：：無線尋呼系統的製作方法
技術領域：
：本發明涉及無線通信系統，更具體而言，涉及無線尋呼和消息收發服務。
背景技術：
：在某些與服務行業有關的商家中，顧客通常預知(onpremise)或不預知(offpremise)為其準備好產品或提供服務必須等待不確定時期。例如，如果醫生診斷時間超過時間表，則病人可能必須在候診間等待很長時期。同樣，在乾洗或修(擦)鞋業中請求加快服務的情形中，可能並不確切知道何時會完成工作。顧客必須就地等待，或重新安排其時間表，並通過電話或個人定期回查該商家。顧客通常必須進行等待的另一情形是在餐館中。如果餐館很忙，顧客又沒有預約，可能要等待1個多小時(假設有桌位的話)。另外，即便顧客預約了，如果餐館已滿或恰逢因用餐方用餐時間過長而使得周轉很慢，仍可能需要等待。眾多餐館安裝有小型本地尋呼系統，用於通知正在等待的顧客何時有桌位或所點菜餚何時準備好。顧客通常持有小型尋呼機，其外形有時如飲料杯墊，其有效範圍為在餐館內及其外部鄰近區域。由於顧客必須呆在相對靠近餐館的區域以待尋呼，這限制了他們的移動性。而且，由於顧客必須返還本地尋呼機，商家通常不贊成顧客不可預知地在過遠處逗留。存在多種與人進行遠程聯繫的裝置。例如，無線廣域尋呼機可用於為接收者提供用於回叫的電話號碼等，或某些其他類型通知。然而，並不是多個人都使用專用尋呼機，對於忙碌的餐館工作人員要跟蹤預約並零星地發出通知是不切實際的。在多個傳統尋呼機可能用得越來越少的同時(例如，具有單向數字消息收發的尋呼機)，大多數人目前攜帶行動電話、無線個人數字助理(PDA)，或用於語音或數字聯繫的其他無線終端。然而，對於尋呼機的情形，要讓忙碌的餐館工作人員記下顧客的行動電話號碼，跟蹤預約/等待時間，然後在桌位準備好之前的短暫時間人工呼叫顧客將是不現實的。
發明內容根據本發明的實施例，無線尋呼系統允許商家使用現有蜂窩電信網絡，通過顧客可能已經擁有的無線設備(例如，行動電話)對顧客進行自動尋呼或聯繫，而無需提供或實現單獨的本地或廣域尋呼網絡。無線尋呼系統包括部署在商家處(例如，診室、餐館，或其他服務提供方)的"本地"計算機。通常來講，本地計算機可為現有計算機或終端。在本地計算機上部署通知程序，用於實現數據輸入、調度和通知功能。本地計算機在操作上與網際網路相連接。通過網際網路，通知程序直接或間接與一個或多個現有蜂窩電信網絡(例如，行動電話網)相接口，以便使用蜂窩網絡的消息收發功能向無線設備發送消息或其他通知。在操作時，當顧客到達商家時，如果要獲得請求的服務和/或產品需等待或延遲較長時間，則通過通知程序將顧客的消息收發標識符(例如，行動電話號碼、文本消息收發地址，或者甚至是電子郵件地址)輸入到本地計算機中。通知程序包括數據輸入功能，用於將消息收發標識符和其他可能的信息輸入和存儲在資料庫中。使用本地計算機與無線設備之間的局域無線接口(例如，紅外光接口)可部分或全部自動實現數據輸入。一旦輸入顧客信息，通知程序就等待接收"產品數據"，由該數據表示關於產品和/或服務的信息，例如表示所請求的服務和/或產品現在有效或即將變得可用的信息。例如，通知程序可包括調度模塊，用於對商家提供的服務進行調度或跟蹤。當該產品或服務變得可用時，僱員將該信息輸入到調度模塊中。基於該信息，通知程序自動啟動對蜂窩網絡的接入，以便向顧客的無線設備發送表示服務就緒或即將就緒的消息或其他通知。通知可為文本消息、自動語音消息、電子郵件消息等。例如，對於需要與客戶或顧客通過文本或自動語音消息自動進行聯繫而不必安裝局域、專用尋呼系統的商家，該無線尋呼系統非常有用。例如，餐館不必提供用於向顧客通知他們何時有桌位的局域尋呼系統，也不必分發可能會丟失或受損的專用尋呼設備(例如，杯墊形尋呼機)，而是可使用無線尋呼系統通過顧客自己現有的行動電話或其他無線設備自動與他們聯繫。結合附圖，通過閱讀後面關於非限定性實施例的描述，將更好地理解本發明，其中圖l表示根據本發明實施例的無線尋呼系統的示意圖2表示無線尋呼系統的消息收發接口部分的操作流程圖3是示出如何將顧客數據輸入到無線尋呼系統中的流程圖4是示出當顧客有不可預期的長時間等待時自動對僱員進行提示的方法的流程圖5和6是示出用於確定何時通過無線尋呼系統與等待顧客進行聯繫的一種可能方法的流程圖7示出了根據本發明的一個實施例的數據相關表；以及圖8表示無線尋呼系統的可選實施例的示意圖。具體實施例方式參看圖1-7，本發明的實施例涉及允許商家使用現有蜂窩電信網絡，通過顧客可能已經擁有的無線設備12(例如，行動電話)，釆用自動尋呼或其他方式與顧客進行聯繫，而無需提供或實現不同局域或廣域尋呼網絡的無線尋呼系統10。隨著預訂某些類型無線服務以及擁有無線設備12的人數比例增大，無線電信產業的增長導致高滲透率。這些無線設備包括(但不限於)傳統行動電話、"高端"或"3-G"行動電話設備(例如，其具有高數據傳輸速率)、傳統尋呼機、PDA型行動電話、專業數據設備(例如，PC數據卡)和其他設備。由於有這樣的高滲透率，這些現有設備被用作為無線尋呼系統10的一部分。無線尋呼系統10包括部署在商家處(例如，醫師診室、餐館，或其他服務提供者)的"本地"計算機14。通知程序16運行在計算機14上，用於實現數據輸入、調度和通知功能。本地計算機14在操作上以標準方式與網際網路或其他網絡18相連，並與一個或多個現有蜂窩電信網絡20(例如，行動電話網絡)相接口，用於向無線設備12自動發送消息或其他通知。在操作時，當顧客到達商家時，如果要獲得請求的服務和/或產品需等待或延遲較長時間，則通過通知程序16將顧客的消息收發或其他通信標識符22(例如，行動電話號碼或消息收發地址)輸入到本地計算機14中。通知程序16包括具有數據輸入功能的用戶接口，用於將顧客信息輸入到資料庫24中。通過使用本地計算機與無線設備之間的局域無線接口(例如，紅外光接口等)，數據輸入可實現完全或部分自動化。顧客信息包括消息收發標識符22，並可包括諸如顧客姓名26以及服務變得可用前與顧客進行聯繫的預計通知量28的附加相關信息。一旦輸入顧客信息，通知程序16就等待接收表示服務或產品現在可用或即將變得可用的產品數據30。例如，通知程序16可包括調度模塊32，用於對商家提供的服務進行調度或跟蹤。當請求的服務變得可用時，僱員通過本地計算機14或通過另一計算機、終端或設備將相應產品數據30輸入到調度模塊中。該產品數據30用作啟動向顧客進行通知的"觸發器"，並可經歷用於確定是否和/或何時向顧客的無線設備12發送通知的處理。通知程序16直接或間接接入蜂窩網絡20,以使將表示服務就緒或即將就緒的消息或其他通知發送到顧客的無線設備12。該通知可為文本消息、自動語音消息、電子郵件消息等。應該理解的是，本發明可用於發送與產品和/或服務有關的通知。由此，術語"產品數據，，如此處所使用的，表示關於產品(表示物理項)、服務(表示要採取的動作)，和/或二者組合(例如，在餐館被提供食物)的信息。一般而言，產品數據將涉及被請求產品和/或服務的可用性，其中，"被請求"表示產品和/或服務已被請求但需要等待或延時。圖1示出了典型蜂窩網絡20的拓樸。網絡20在地理上被劃分為多個小區或扇區，它們通常毗鄰，且一起限定出網絡的覆蓋區域。每個小區由基站34提供服務，基站34包括一個或多個固定/靜止收發信機以及用於與向網絡用戶提供服務的無線設備12進行無線通信的天線36。基站34進而與網絡的其餘部分38相連(通過無線或陸地線路)，網絡的其餘部分38通常將包括網絡/網際網路網關和一個或多個移動交換中心("MSC")，根據網絡容量和配置，網絡/網際網路網關和一個或多個移動交換中心均用作特定數量的基站。移動交換中心起到網絡無線/無線電端20與公共交換電話網絡或其他網絡18之間接口的作用，包括執行建立呼叫或與無線設備12來回傳送其他數據所需的信令功能。網關起到網絡20與網際網路或其他網絡18之間物理和邏輯接口的作用，以便在此之間進行通信。應該理解，本發明並不取決於具體蜂窩網絡的配置，它通常會(通過網際網路或其他方式間接或直接)結合多個不同蜂窩網絡20得以實施。可將多個蜂窩網絡配置成不同於圖1所示的網絡20。蜂窩網絡20還包括短消息收發服務("SMS")40。SMS40是蜂窩網絡20的現有功能，其允許用戶利用適當配置的無線設備通過蜂窩網絡20向另一無線設備發送文本消息。為了發送文本消息，與用於聯繫接收方的消息收發標識符22—起，將消息輸入到用戶的無線設備12中。如上所述，消息收發標識符可為接收方的行動電話號碼，或根據具體網絡和SMS系統，它可為消息收發地址或號碼，例如，指定用於文本消息收發的流水線化的號碼或地址。網絡20對文本消息進行處理，以便將其路由到接收方。消息長度通常限制到80-160個字符，接收方可能需要兼容的無線設備。本地計算機14通過網際網路或其他網絡18與蜂窩網絡20間接相連。為啟動l吏用SMS40生成文本消息或其他通知，本地計算機14設有SMS接口裝置42，用於與蜂窩網絡的SMS系統40直接或間接相接口。SMS接口裝置42結合或作為部分通知程序16工作。適宜的SMS接口裝置42包括直接接口46，商業上可獲得的文本消息收發軟體包48，和/或用於與一個或多個基於網際網路的文本消息收發埠44相接口的程序或腳本54。直接接口46將是定製的SMS接入程序，所述定製的SMS接入程序被配置成使用網絡20上設置的協議和/或命令結構，以直接方式與蜂窩網絡20和/或SMS系統40相接口，以便接入SMS系統40，以及生成和處理文本消息。根據特定的蜂窩網絡20，這可能需要預訂或者對於蜂窩網絡的用戶帳號，以及可能專用的接口硬體。不使用SMS直接接入程序46,而是可使用商用的文本消息收發軟體包48與SMS系統40相接口。文本消息收發軟體48將運行在本地計算機14上，並將包括用戶接口50和網絡接口52。網絡接口部分52用於通過網際網路或其他網絡18接入SMS系統40，而用戶接口50提供用於用戶接入和使用網絡接口52功能的流水線化的直觀方式，例如，圖形用戶界面等。在操作時，不使用定製程序來生成協議消息或其他命令等直接接入SMS系統40,而是用戶簡單地將消息收發標識符22等鍵入到用戶接口50中，網絡接口部分52根據內置程序編碼自動接入SMS系統40。用戶接口50除可為個人使用外，還可配置為由通知程序16進行操作，例如通知程序16可在操作上與網絡接口52相連接，這可能通過用戶接口50實現。應該理解的是，文本消息收發軟體程序48可易於實現尋呼系統10，由於通知程序16僅僅必須被配置成接入流水線化或簡化的用戶接口50，無需提供定製的直接接口46。適宜的文本消息收發軟體48包括NotePagerProTM和PageGate,二者可在網站www.notepager.com獲得。SMS接口部件42還可為用於與一個或多個現有基於網際網路的文本消息收發埠44相接口的程序或腳本。某些基於網際網路的埠專門針對特定無線服務提供商，並僅可用於向特定服務提供商的用戶發送消息。然而，某些通用埠允許對獨立於無線服務提供商的無線終端進行文本消息收發。示例包括www.smseverywhere.com和www.telefilp.com。腳本或程序54可結合通知程序16在本地計算機14上操作，並可用於接入基於網際網路的文本消息收發埠44，以便將文本消息發送到無線設備12。或者，腳本或程序54可被用於與本地計算機14上的現有電子郵件程序或伺服器相接口(例如，MicrosoftOutlookTM)，以便向文本消息收發電子郵件地址發送合適配置的電子郵件消息。文本消息收發電子郵件地址由某些蜂窩網絡服務提供商和/或文本消息收發埠44保持，以允許用戶^f吏用電子郵件消息發送文本消息。為啟動文本消息的發送，將電子郵件消息發送到特定電子地址。一般而言，電子郵件地址將具有類似以下的格式(messaging—identifier)@domain_name.com。顯然可以看出，電子郵件消息的主體形成消息文本，電子郵件消息題目形成文本消息題目，電子郵件地址的"messaging—identifier"部分形成預期接收方無線設備的消息收發標識符。示例性地址包括(messaging—identifier)@vtext.com和(messaging—identifier)@teleflip.com。前者專用於Verizon⑧網絡，而後者並非是網絡專用的。然而，服務在資料庫中查詢消息收發標識符，以確定消息收發標識符的服務提供商，以及相應地還確定發送文本消息的方式。圖2示出了SMS接口裝置42的一般性操作。在步驟100,結合或作為部分通知程序16運行在本地計算機14上的SMS接口42，等待來自通知程序16的一個或多個指令56。指令56通常將包括將被通知的顧客的消息收發標識符22和將被發送的消息文本。指令56還可包括用於對SMS接口42進行控制的一個或多個命令等。在步驟102，SMS接口42可選性地檢查指令56是否被合適地格式化，以及是否包含必要的信息。若否，在步驟104，向通知程序16發送錯誤消息。如果指令56被合適地配置，在步驟106，若需要的話，根據接入SMS系統40的具體方式，SMS接口42生成用於接入SMS系統40的一個或多個協議命令58。通過"協議命令"，表示為直接或間接接入SMS系統40所需的電子指令、信號，或傳輸，以便將消息發送到無線設備12。此外，還需要對消息收發標識符22和消息進行格式化。在步驟108，接入蜂窩網絡20和/或網際網路或其他網絡18。然後，在步驟110，SMS接口42發送協^義命令58、消息收發標識符22和消息。根據具體SMS接口42，可按不同順序執行步驟106-110。如果SMS接口42為定製的SMS直接接入程序46，協議命令可包括與表示要將消息發送到消息收發標識符22所標識出的無線設備的一個或多個指令或信號一起的預訂帳戶名和密碼。如果SMS接口42為文本消息收發軟體程序48,則通常會發送相似的協議命令。然而，這將根據文本消息收發軟體的現有編程實現，其中通知程序16被設置成用於生成通過其用戶接口50等對文本消息收發軟體程序48進行控制的指令。根據其具體配置，如果SMS接口42是與基於網際網路的文本消息收發埠44一起使用的腳本54，則協議命令將是通過使用埠44發送消息所需的指令或信號。例如，對於使用www.smseverwhere.com的情形，腳本54將自動執行以下功能/步驟的其中一個或多個接入www.smseverywhere.com網站；通過會員網頁(會員是可選的，但將提供不受限的消息收發)登錄到服務；將具體消息收發標識符22輸入到"SendTo"欄位或等效物中；將題目輸入到"Subject，，欄位或等效物中；將消息輸入到"Message"欄位或等效物中；檢查是否已超過字符最大數量；以及啟動"SendNow，，功能，以便將消息發送到與消息收發標識符22相關聯的無線設備12。在消息傳遞驗證可用的蜂窩網絡20中，可以通知尋呼系統10消息被成功傳遞以及是否對其進行接入。在另一情形中，若否，則將對商家僱員進行提示，或將消息重新發送。無線尋呼系統10允許使用標準商用無線設備取代本地尋呼系統或提供新的尋呼或其他功能，而不必安裝不同於現有商用無線系統20的無線系統。不為顧客提供專用局域尋呼機等通過本地尋呼系統進行通知，而是通過顧客可能已經擁有的無線設備12(例如，行動電話)對他們進行通知。這樣的操作可通過人工(採用當服務就緒時由僱員呼叫顧客的方式)。然而，在大的商家處於忙碌時段期間，這樣做很快就變得不實際。由此，通過調度模塊32和資料庫24，根據改進和自動化的調度功能，無線尋呼系統IO自動對顧客進行通知。現在，將參照應用於飲食服務行業(例如，餐館或類似商家)中的示例性實施方式，進一步描述調度模塊32和資料庫24。儘管對於商家而言可能以稍有不同的方式實現這些組件，但總體操作和功能通常是一樣的。無線尋呼系統10決不受餐飲等應用的限制，而是此處出於說明的目的，下面將展開這些描述。圖3示出了在對於就餐團通常出現在優質餐館處的那些有關事件的情境中，當就餐團到達時，為了將信息輸入到資料庫24中，調度模塊32和資料庫24如何進行運作。例如，在步驟120，一個或多個顧客的就餐團到達餐館，例如希望確保有桌位，並提供最近在當地新聞餐飲導讀部分中登出的具有特色的5道名菜。在步驟122，服務人員確定就餐團是否要等待桌位。若否，在步驟124，邀請就餐團就座。若是，在步驟126，詢問就餐團是否要在附近的等候區域內等待，或者在桌位就緒時想通過無線設備獲得通知。如果僅需很短時間的等待(例如，5-10分鐘)，則就餐團可能想在附近等待，當為其準備好桌位時進行語音尋呼，以避免就餐團不利地"走開(wanderoff)，，。如果就餐團選擇在附近等待，則接待人員會對該就餐團人工跟蹤何時有桌位。然而，特別是對於長時間等待(接待人員可能難以進行跟蹤)，桌位可用性則通過系統10自動進行跟蹤。在這樣的情形中，在步驟128，將通過調度模塊32，將就餐團名稱26與就餐團大小60及諸如就餐團是否偏好有煙或無煙餐桌的任何其他相關信息一起，輸入到資料庫24中。不輸入任何消息收發標識符22或通知28,調度模塊32使用這些作為就餐團本地等待的表示，並且也不會通過無線設備12進行通知。在步驟130,調度模塊32將可選性地自動對資料庫24添加時間戳或時間輸入表示62，作為就餐團何時到達的表示。應該理解，該組合就餐團信息(名稱、就餐團大小、時間戳等)實際將包括在資料庫24中的數據記錄64，例如，一組相關的關聯數據或信息。如果就餐團選擇通過無線設備12得以通知，在步驟132，接待人員將就餐團名稱26、消息收發標識符22、就餐團大小60、以及可選性地包括通知28預期量，輸入到資料庫24中。同樣，在組合中的該信息將形成資料庫24中的數據記錄64。在步驟130，調度模塊32將可選性地添加表示就餐團何時到達的時間戳62。參照圖4，時間戳62可以被用作用於識別就餐團比預期相比已等待了更長時間的情形的"備用"單元。例如，調度模塊32可以周期性地運行對於每個數據記錄64的"時間檢查"子例程66。在步驟134，調度模塊32通過計算當前時間與時間戳62之間的差來確定就餐團的等待時間。在步驟136，將等待時間與餐館確定的表示最大預期等待時間的預設值進行比較。在步驟138,確定等待時間是否超過預設最大值。若是，則在步驟140，調度模塊32對接待人員進行提示。若否，在步驟142，將等待時間與先前由接待人員輸入或確定的計劃等待時間進行比較。(一般而言，餐館的接待人員將為就餐團提供關於計劃等待時間的某些指示，可將其與就餐團名稱等一道輸入到資料庫24中。)在步驟144,調度模塊32確定實際等待時間是否超過計劃等待時間某一預定合適值"X"，例如，15分鐘。若是，則如在步驟140那樣對接待人員進行提示。若否，則退出時間檢查子例程66，直至其下一個周期性實現方式。如上所述，將產品數據30輸入到調度模塊32中，以便用於確定何時向等待方進行通知。在餐館的情形中，數據30通常會成為關於餐館中哪張餐桌變得可為新顧客使用的信息。調度模塊32用於將該數據30與存儲在資料庫24中的等待方數據記錄64相關。例如，參照圖5中的步驟150，當現有就餐團騰出桌位時，接待人員訪問本地計算機14上的通知程序16，並輸入表示特定桌號剛好騰空的數據30。通知程序16在資料庫24中包括將桌號與其各自容量相關的查詢表或其他數據組。由此，在步驟152，調度模塊32訪問查詢表以便將騰空桌桌號與餐桌容量相關。接待人員還可表示餐桌目前是否可用或仍被坐滿(bussed)，調度模塊32假設根據後者情形餐桌將在一定時期內可為新就餐團就座。在步驟154，調度模塊32將最新可用餐桌與處於等待的就餐團的數據記錄64進行比較，以便在步驟156找出合適匹配，例如，確定為哪個就餐團指定空位。然後，在步驟158，通知程序16開始向匹配的就餐團發送消息或其他通知。出於通知考慮，如果在步驟126(圖3)就餐團選擇等待，或者如果就餐團中沒有人攜帶無線設備12，則通知程序16提示接待人員有可用餐桌，以便人工或自動(例如，計算機生成)發出有聲局域尋呼。例如，通知程序16可在本地計算機顯示屏上生成合適的"彈出"消息或窗口，包括有就餐團名稱、規模和可用餐桌。如果在步驟126就餐團選擇通過無線設備進行通知，則通知程序16開始發送合適的文本消息等，如上所述。可選性地，通知程序16還可提示接待人員就餐團有可用餐桌。例如，通知程序16可在本地計算機顯示屏上保持有識別出已為其發送了通知消息的就餐團的列表。然後，當每個就餐團到達就座時，接待人員將從表中刪除該項，且通知程序16自動從資料庫24中刪除相應記錄64。可選性地，通知程序16將周期性地檢查得到通知的就餐團的列表，對於在一定時期內未刪除的任何項，通過無線設備或其他方式重新發送通知。如所示出的，在步驟154和156，調度才莫塊32確定如何為處於等待的就餐團分配新騰空的餐桌。這可採用多種不同的方式實現，取決於餐館具體運作方式，並且根據多個可能的資料庫查詢和分類選項。圖6示出了由調度模塊32執行的用於確定如何分配餐桌的一種可能數據分類子例程68。(當然，也可能存在任何數量的其他子例程。)首先，對就餐團數據記錄64進行分類以形成分類列表。為此，在步驟170,子例程進行到資料庫24中的第一數據記錄64，或者，如果已經對一個或多個數據記錄進行了分類則進行到下一個數據記錄。在步驟172，對於當前訪問的數據記錄，確定最新可用餐桌對於就餐團大小60是否具有足夠大容量。若否，則子例程進行到步驟174，確定是否有任何剩餘數據記錄64進行分類。從步驟174，如果要對剩餘數據記錄進行分類，則回退到步驟170,子例程進行到下一數據記錄。回到步驟172，如果餐桌對於就餐團大小有足夠大的容量，則子例程在步驟176確定餐桌對於就餐團大小而言是否顯得"過大"。例如，餐館可能有從來不會將很大的桌子分配給非常小的就餐團以避免浪費餐桌空間的策略。在圖7中示出了一個可能餐桌容量配置70的示例性列表，其中，"最優"意指最優化利用餐桌空間的就餐團大小與餐桌容量之間的最佳匹配，"可接受"意指餐桌利用並不最優但還可接受的匹配。例如，如圖7所示，從來不會將6人容量的餐桌分配給少於4位的顧客，分配給4位顧客也不最優，最優的是將其分配給5或6位顧客。(同樣，應該想到，作為示例，這只是基於一種可能餐館策略的可能配置。)如果在步驟176確定最新可用餐桌對於就餐團大小並不"過大"，則在步驟178將當前數據記錄添加到分類列表。如杲認定餐桌容量特別大，則不將當前數據記錄添加到分類列表。在另一情形中，子例程68繼續到步驟174，以便確定當前數據記錄是否為最後數據記錄。若否，子例程返回到步驟170。若是，則對所有數據記錄64進行分類，完成分類列表。子例程68繼續到步驟180，確定分類列表上等待時間最長的就餐團，例如，它找出具有最早時間戳62的數據記錄64。此時，調度模塊32可簡單地將最新可用餐桌分配給等待時間最長的就餐團。然而，通過對分類列表進行進一步處理，有可能更好地利用餐桌容量。為此，作為一個可能示例，在步驟182，子例程檢查等待時間最長的就餐團與最新可用餐桌是否具有最優匹配。同樣，這通過參考數據相關表，例如如圖7所示表格，將餐桌容量與就餐團大小進行比較來實現。例如，如果最新可用餐桌可容納4位顧客，則在該餐桌就座的最優就餐團大小應為3或4人。如果等待時間最長的就餐團與餐桌容量具有最優匹配，則在步驟184，將該餐桌分配給等待時間最長的就餐團。若否，則子例程68繼續將餐桌分配給等待時間更短的最優匹配就餐團，但只有該就餐團在等待時間最長就餐團的合理短時段內到達才會如此。例如，為最優利用餐桌容量，如果4人就餐團剛好在1人就餐方到達之後到達，則在1人就餐方之前讓4人就餐團就座於4座餐桌更合理。另一方面，如果1人就餐方已等了相當長的時間，則餐館策略可能規定首先讓該就餐方就座，即便是很大容量的餐桌也是如此。從而，在步驟186，子例程確定分類列表中是否有在等待時間最長就餐團的"X"分鐘內到達的任何就餐團，其中，"X"表示根據餐館策略賦予某值的變量。例如，X可能從5到10分鐘。若否，則在步驟184將該餐桌分配給等待時間最長的就餐團。若如此，子例程然後在步驟188檢查是否有任何其他就餐團與最新可用餐桌的容量具有最優匹配。若否，則在步驟184將餐桌分配給等待時間最長的就餐團。若如此，則在步驟190，反而將餐桌分配給那些具有最優匹配中的等待時間最長的就餐團。並不是通過訪問本地計算機14上的通知程序將餐桌或其他觸發器數據30輸入到資料庫24中，僱員而是使用遠程或其他終端輸入數據。例如，每個接待人員都能夠訪問操作上與本地計算機14無線連接的無線PDA。此外，並不是由僱員將餐桌或其他信息30人工輸入到系統10中，而是基於何時支付餐桌帳單，例如從收銀機系統自動輸入，或者基於計算機的檢測裝置，例如視頻攝像機。通知程序16包括調度模塊32,可設有用於對顧客通知進行調度和修改的多個附加功能。例如，可為接待人員賦予刪除或修改數據記錄以改變餐桌配置，輸入和保持提前預約，發送人工通知等功能。通知程序16可設有圖形用戶接口。為參照簡明示例概括性描述尋呼系統10的操作，當顧客首次到達餐館時，顧客需要就座，並被告知將等一段時間。顧客向接待人員提供他或她的行動電話號碼以及顧客對桌位可用性關注程度的某種表示。然後，接待人員通過通知程序16將電話號碼22和通知間隔信息28輸入到資料庫24中。基於自動或人工提供給系統的餐桌可用性信息30，系統10開始與顧客的行動電話12進行聯繫。例如，系統向顧客的移動站12發出表示j口"Yourtablewillbereadyin5minutes."之類的SMS消息。或者，系統向客戶發送預先記錄的或計算機產生的語音消息。該系統可用於其他商家，例如，醫院。提供以上所述尋呼/消息收發功能類型的一種方式可以是構建定製硬體和軟體。然而，還有可能對現有硬體和軟體產生影響，上述實現方式使用標準、容易獲得的計算機設備和網絡。對於特定應用，例如排隊準則，可進行某種定製，或自動識別向顧客發送尋呼或消息必需的觸發器。本發明的一個實施例的特徵在於一種用於通過網絡(例如，蜂窩網絡20)與無線設備(例如，顧客的行動電話12)進行通信或聯繫的方法，其通過通知程序16執行。首先，通知程序接收產品數據，例如，關於所請求產品和/或服務的可用性的信息。例如，僱員可將表示特定餐桌變得可用的信息輸入到計算機14中。然後，基於產品數據，通知程序16自動向無線設備發送通知或其他消息。還可對接收數據自動進行處理，以確定是否向無線設備發送通知。這樣的處理可包括將時間戳以及其他顧客數據與接收數據(例如，表示產品/或服務變得可用的數據)相關，和/或根據多個商家策略對接收數據和/或顧客數據進行處理，如在算法中實施的(例如，參見圖6以及相關描述)。圖8示出了尋呼系統的可選實施例72。此處，不是通過網際網路或其他網絡18(參見圖1)與蜂窩網絡20相接口，而是尋呼系統72可包括與本地計算機14相連接的無線模塊74。無線模塊74將具有與典型無線設備12(例如，用於與基站34進行通信的RF收發器和天線)同樣或相似的功能，以及接收和發送文本消息等的功能。另外，無線模塊74將具有數據/功率總線76，用於從計算機接收電功率以及與計算機，例如IEEE1394接口交換數據。另外，本地計算機14和無線模塊74將還具有用於啟動消息收發接口42以便與無線模塊74進行通信以及對其進行控制的互通軟體程序。應該理解，儘管圖8示出了無線模塊74和顧客無線設備12通過一個蜂窩網絡進行通信，它也可為這樣的情形，即採用標準方式，通過網際網路、公共交換電話網等實現不同網絡互通，由不同蜂窩網絡和/或服務提供商對無線模塊74和無線設備12提供服務。在不偏離此處所涉及本發明精神和範圍的條件下，可對上述無線尋呼系統進行某種改變，應該注意，應將以上描述和附圖中示出的所有內容理解為僅僅作為用於在此處說明本發明原理的示例，而不應將其視為對本發明的限制。權利要求1.一種在網絡上與無線設備進行通信的方法，所述方法包括步驟接收產品數據；以及基於所述產品數據，通過所述網絡自動向所述無線設備發送通知。2.根據權利要求l的方法，還包括步驟自動對所述產品數據進行處理，以便確定是否發送所述通知。3.根據權利要求2的方法，其中所述產品數據涉及被請求產品和/或服務的可用性；所述方法還包括步驟存儲關於所述產品和/或服務何時被請求的時間戳數據；以及對所述產品數據進行處理的步驟包括將所述產品數據與所述時間戳數據相關。4.根據權利要求3的方法，其中將所述產品數據與所述時間戳數據相關的步驟包括確定對於所述產品和/或服務的不同請求之間的優先級。5.根據權利要求l的方法，其中所述網絡為具有短消息收發服務(SMS)的無線網絡；並且所述通知為使用SMS發送的文本消息。6.根據權利要求5的方法，還包括步驟自動對所述產品數據進行處理，以確定是否發送所述文本消息。7.根據權利要求6的方法，其中所述產品數據涉及被請求產品和/或服務的可用性；所述方法還包括步驟存儲關於所述產品和/或服務何時被請求的時間戳數據；以及對所述產品數據進行處理的步驟包括將所述產品數據與所述時間戳數據相關。8.—種通過網絡與無線設備進行通信的方法，所述方法包括步驟接收數據；基於所述接收的數據，自動確定是否將通知發送到所述無線設備；以及，如果這樣的話，通過所述網絡自動將通知發送到所述無線設備。9.一種通過網絡與無線設備進行通信的方法，所述方法包括步驟存儲顧客數據；接收產品數據；將所述產品數據與所述顧客數據相關；以及基於所述相關，通過所述網絡自動將通知發送到所述無線設備。10.根據權利要求9的方法，其中所述產品數據涉及被請求產品和/或服務的可用性；所述顧客數據包括關於所述產品和/或服務何時被請求的時間戳數據；將所述產品數據與所述顧客數據相關的步驟包括至少部分地基於所述時間戳數據，確定對於所述產品和/或服務的不同請求之間的優先級；所述網絡包括短消息收發服務(SMS);以及所述通知是通過SMS發送的文本消息。全文摘要無線尋呼系統允許商家使用現有蜂窩電信網絡，通過顧客的現有的行動電話或者其他無線設備對顧客進行自動尋呼，而無需提供單獨的本地尋呼網絡。該尋呼系統包括部署在商家處的與網際網路相連的「本地」計算機，和運行在計算機上的通知和調度程序。通過網際網路等，通知程序直接或間接與蜂窩網絡的短消息收發服務等相接口。如果顧客到達時不得不等待產品和/或服務，則將顧客的行動電話號碼輸入到通知程序中。當接收表示產品和/或服務已經變得可用的數據時，例如，當僱員將其輸入到本地計算機中時，通知程序生成將通知消息發送到顧客的無線設備的合適命令和/或指令。文檔編號H04W68/00GK101176360SQ200680016798公開日2008年5月7日申請日期2006年4月28日優先權日2005年5月16日發明者約瑟夫·安東尼·塔雷羅申請人:朗迅科技公司