CN101176360A - 无线寻呼系统 - Google Patents

Abstract

无线寻呼系统允许商家使用现有蜂窝电信网络，通过顾客的现有的移动电话或者其他无线设备对顾客进行自动寻呼，而无需提供单独的本地寻呼网络。该寻呼系统包括部署在商家处的与互联网相连的“本地”计算机，和运行在计算机上的通知和调度程序。通过互联网等，通知程序直接或间接与蜂窝网络的短消息收发服务等相接口。如果顾客到达时不得不等待产品和/或服务，则将顾客的移动电话号码输入到通知程序中。当接收表示产品和/或服务已经变得可用的数据时，例如，当雇员将其输入到本地计算机中时，通知程序生成将通知消息发送到顾客的无线设备的合适命令和/或指令。

Description

无线寻呼系统

技术领域

本发明涉及无线通信系统，更具体而言，涉及无线寻呼和消息收发服务。

背景技术

在某些与服务行业有关的商家中，顾客通常预知(on premise)或不预知(off premise)为其准备好产品或提供服务必须等待不确定时期。例如，如果医生诊断时间超过时间表，则病人可能必须在候诊间等待很长时期。同样，在干洗或修(擦)鞋业中请求加快服务的情形中，可能并不确切知道何时会完成工作。顾客必须就地等待，或重新安排其时间表，并通过电话或个人定期回查该商家。

顾客通常必须进行等待的另一情形是在餐馆中。如果餐馆很忙，顾客又没有预约，可能要等待1个多小时(假设有桌位的话)。另外，即便顾客预约了，如果餐馆已满或恰逢因用餐方用餐时间过长而使得周转很慢，仍可能需要等待。众多餐馆安装有小型本地寻呼系统，用于通知正在等待的顾客何时有桌位或所点菜肴何时准备好。顾客通常持有小型寻呼机，其外形有时如饮料杯垫，其有效范围为在餐馆内及其外部邻近区域。由于顾客必须呆在相对靠近餐馆的区域以待寻呼，这限制了他们的移动性。而且，由于顾客必须返还本地寻呼机，商家通常不赞成顾客不可预知地在过远处逗留。

存在多种与人进行远程联系的装置。例如，无线广域寻呼机可用于为接收者提供用于回叫的电话号码等，或某些其他类型通知。然而，并不是多个人都使用专用寻呼机，对于忙碌的餐馆工作人员要跟踪预约并零星地发出通知是不切实际的。在多个传统寻呼机可能用得越来越少的同时(例如，具有单向数字消息收发的寻呼机)，大多数人目前携带移动电话、无线个人数字助理(PDA)，或用于语音或数字联系的其他无线终端。然而，对于寻呼机的情形，要让忙碌的餐馆工作人员记下顾客的移动电话号码，跟踪预约/等待时间，然后在桌位准备好之前的短暂时间人工呼叫顾客将是不现实的。

发明内容

根据本发明的实施例，无线寻呼系统允许商家使用现有蜂窝电信网络，通过顾客可能已经拥有的无线设备(例如，移动电话)对顾客进行自动寻呼或联系，而无需提供或实现单独的本地或广域寻呼网络。无线寻呼系统包括部署在商家处(例如，诊室、餐馆，或其他服务提供方)的“本地”计算机。通常来讲，本地计算机可为现有计算机或终端。在本地计算机上部署通知程序，用于实现数据输入、调度和通知功能。本地计算机在操作上与互联网相连接。通过互联网，通知程序直接或间接与一个或多个现有蜂窝电信网络(例如，移动电话网)相接口，以便使用蜂窝网络的消息收发功能向无线设备发送消息或其他通知。

在操作时，当顾客到达商家时，如果要获得请求的服务和/或产品需等待或延迟较长时间，则通过通知程序将顾客的消息收发标识符(例如，移动电话号码、文本消息收发地址，或者甚至是电子邮件地址)输入到本地计算机中。通知程序包括数据输入功能，用于将消息收发标识符和其他可能的信息输入和存储在数据库中。使用本地计算机与无线设备之间的局域无线接口(例如，红外光接口)可部分或全部自动实现数据输入。一旦输入顾客信息，通知程序就等待接收“产品数据”，由该数据表示关于产品和/或服务的信息，例如表示所请求的服务和/或产品现在有效或即将变得可用的信息。例如，通知程序可包括调度模块，用于对商家提供的服务进行调度或跟踪。当该产品或服务变得可用时，雇员将该信息输入到调度模块中。基于该信息，通知程序自动启动对蜂窝网络的接入，以便向顾客的无线设备发送表示服务就绪或即将就绪的消息或其他通知。通知可为文本消息、自动语音消息、电子邮件消息等。

例如，对于需要与客户或顾客通过文本或自动语音消息自动进行联系而不必安装局域、专用寻呼系统的商家，该无线寻呼系统非常有用。例如，餐馆不必提供用于向顾客通知他们何时有桌位的局域寻呼系统，也不必分发可能会丢失或受损的专用寻呼设备(例如，杯垫形寻呼机)，而是可使用无线寻呼系统通过顾客自己现有的移动电话或其他无线设备自动与他们联系。

附图说明

结合附图，通过阅读后面关于非限定性实施例的描述，将更好地理解本发明，其中：

图1表示根据本发明实施例的无线寻呼系统的示意图；

图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。SMS 40是蜂窝网络20的现有功能，其允许用户利用适当配置的无线设备通过蜂窝网络20向另一无线设备发送文本消息。为了发送文本消息，与用于联系接收方的消息收发标识符22一起，将消息输入到用户的无线设备12中。如上所述，消息收发标识符可为接收方的移动电话号码，或根据具体网络和SMS系统，它可为消息收发地址或号码，例如，指定用于文本消息收发的流水线化的号码或地址。网络20对文本消息进行处理，以便将其路由到接收方。消息长度通常限制到80-160个字符，接收方可能需要兼容的无线设备。

本地计算机14通过互联网或其他网络18与蜂窝网络20间接相连。为启动使用SMS 40生成文本消息或其他通知，本地计算机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包括NotePagerPro^TM和PageGate^TM，二者可在网站www.notepager.com获得。

SMS接口部件42还可为用于与一个或多个现有基于互联网的文本消息收发端口44相接口的程序或脚本。某些基于互联网的端口专门针对特定无线服务提供商，并仅可用于向特定服务提供商的用户发送消息。然而，某些通用端口允许对独立于无线服务提供商的无线终端进行文本消息收发。示例包括www.smseverywhere.com和www.telefilp.com。脚本或程序54可结合通知程序16在本地计算机14上操作，并可用于接入基于互联网的文本消息收发端口44，以便将文本消息发送到无线设备12。或者，脚本或程序54可被用于与本地计算机14上的现有电子邮件程序或服务器相接口(例如，Microsoft Outlook^TM)，以便向文本消息收发电子邮件地址发送合适配置的电子邮件消息。文本消息收发电子邮件地址由某些蜂窝网络服务提供商和/或文本消息收发端口44保持，以允许用户使用电子邮件消息发送文本消息。为启动文本消息的发送，将电子邮件消息发送到特定电子地址。一般而言，电子邮件地址将具有类似以下的格式：(messaging_identifier)@domain_name.com。显然可以看出，电子邮件消息的主体形成消息文本，电子邮件消息题目形成文本消息题目，电子邮件地址的“messaging_identifier”部分形成预期接收方无线设备的消息收发标识符。示例性地址包括(messaging_identifier)@vtext.com和(messaging_identifier)@telefiip.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输入到“Send To”字段或等效物中；将题目输入到“Subject”字段或等效物中；将消息输入到“Message”字段或等效物中；检查是否已超过字符最大数量；以及启动“Send Now”功能，以便将消息发送到与消息收发标识符22相关联的无线设备12。

在消息传递验证可用的蜂窝网络20中，可以通知寻呼系统10消息被成功传递以及是否对其进行接入。在另一情形中，若否，则将对商家雇员进行提示，或将消息重新发送。

无线寻呼系统10允许使用标准商用无线设备取代本地寻呼系统或提供新的寻呼或其他功能，而不必安装不同于现有商用无线系统20的无线系统。不为顾客提供专用局域寻呼机等通过本地寻呼系统进行通知，而是通过顾客可能已经拥有的无线设备12(例如，移动电话)对他们进行通知。这样的操作可通过人工(采用当服务就绪时由雇员呼叫顾客的方式)。然而，在大的商家处于忙碌时段期间，这样做很快就变得不实际。由此，通过调度模块32和数据库24，根据改进和自动化的调度功能，无线寻呼系统10自动对顾客进行通知。

现在，将参照应用于饮食服务行业(例如，餐馆或类似商家)中的示例性实施方式，进一步描述调度模块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发出表示如“Your table will be ready in 5 minutes.”之类的SMS消息。或者，系统向客户发送预先记录的或计算机产生的语音消息。该系统可用于其他商家，例如，医院。提供以上所述寻呼/消息收发功能类型的一种方式可以是构建定制硬件和软件。然而，还有可能对现有硬件和软件产生影响，上述实现方式使用标准、容易获得的计算机设备和网络。对于特定应用，例如排队准则，可进行某种定制，或自动识别向顾客发送寻呼或消息必需的触发器。

本发明的一个实施例的特征在于一种用于通过网络(例如，蜂窝网络20)与无线设备(例如，顾客的移动电话12)进行通信或联系的方法，其通过通知程序16执行。首先，通知程序接收产品数据，例如，关于所请求产品和/或服务的可用性的信息。例如，雇员可将表示特定餐桌变得可用的信息输入到计算机14中。然后，基于产品数据，通知程序16自动向无线设备发送通知或其他消息。还可对接收数据自动进行处理，以确定是否向无线设备发送通知。这样的处理可包括将时间戳以及其他顾客数据与接收数据(例如，表示产品/或服务变得可用的数据)相关，和/或根据多个商家策略对接收数据和/或顾客数据进行处理，如在算法中实施的(例如，参见图6以及相关描述)。

图8示出了寻呼系统的可选实施例72。此处，不是通过互联网或其他网络18(参见图1)与蜂窝网络20相接口，而是寻呼系统72可包括与本地计算机14相连接的无线模块74。无线模块74将具有与典型无线设备12(例如，用于与基站34进行通信的RF收发器和天线)同样或相似的功能，以及接收和发送文本消息等的功能。另外，无线模块74将具有数据/功率总线76，用于从计算机接收电功率以及与计算机，例如IEEE 1394接口交换数据。另外，本地计算机14和无线模块74将还具有用于启动消息收发接口42以便与无线模块74进行通信以及对其进行控制的互通软件程序。应该理解，尽管图8示出了无线模块74和顾客无线设备12通过一个蜂窝网络进行通信，它也可为这样的情形，即采用标准方式，通过互联网、公共交换电话网等实现不同网络互通，由不同蜂窝网络和/或服务提供商对无线模块74和无线设备12提供服务。

在不偏离此处所涉及本发明精神和范围的条件下，可对上述无线寻呼系统进行某种改变，应该注意，应将以上描述和附图中示出的所有内容理解为仅仅作为用于在此处说明本发明原理的示例，而不应将其视为对本发明的限制。

Claims (10)

1.一种在网络上与无线设备进行通信的方法，所述方法包括步骤：

接收产品数据；以及

基于所述产品数据，通过所述网络自动向所述无线设备发送通知。

2.根据权利要求1的方法，还包括步骤：

自动对所述产品数据进行处理，以便确定是否发送所述通知。

3.根据权利要求2的方法，其中所述产品数据涉及被请求产品和/或服务的可用性；

所述方法还包括步骤：

存储关于所述产品和/或服务何时被请求的时间戳数据；以及

对所述产品数据进行处理的步骤包括：

将所述产品数据与所述时间戳数据相关。

4.根据权利要求3的方法，其中将所述产品数据与所述时间戳数据相关的步骤包括：

确定对于所述产品和/或服务的不同请求之间的优先级。

5.根据权利要求1的方法，其中所述网络为具有短消息收发服务(SMS)的无线网络；并且

所述通知为使用SMS发送的文本消息。

6.根据权利要求5的方法，还包括步骤：

自动对所述产品数据进行处理，以确定是否发送所述文本消息。

7.根据权利要求6的方法，其中所述产品数据涉及被请求产品和/或服务的可用性；

所述方法还包括步骤：

存储关于所述产品和/或服务何时被请求的时间戳数据；以及

对所述产品数据进行处理的步骤包括：

将所述产品数据与所述时间戳数据相关。

8.一种通过网络与无线设备进行通信的方法，所述方法包括步骤：

接收数据；

基于所述接收的数据，自动确定是否将通知发送到所述无线设备；以及，如果这样的话，

通过所述网络自动将通知发送到所述无线设备。

9.一种通过网络与无线设备进行通信的方法，所述方法包括步骤：

存储顾客数据；

接收产品数据；

将所述产品数据与所述顾客数据相关；以及

基于所述相关，通过所述网络自动将通知发送到所述无线设备。

10.根据权利要求9的方法，其中所述产品数据涉及被请求产品和/或服务的可用性；

所述顾客数据包括关于所述产品和/或服务何时被请求的时间戳数据；

将所述产品数据与所述顾客数据相关的步骤包括：

至少部分地基于所述时间戳数据，确定对于所述产品和/或服务的不同请求之间的优先级；

所述网络包括短消息收发服务(SMS)；以及

所述通知是通过SMS发送的文本消息。

Images