CN105678654A - 餐饮服务方法和系统 - Google Patents

Abstract

本发明提供的餐饮服务方法和系统，通过匹配消费者端和商户端之间的供需信息，通过匹配规则加以撮合并利用，从而高效地配置餐饮服务的供给和需求，促进交易的精准达成，使商家和消费者利益最大化。

Description

餐饮服务方法和系统

技术领域

本发明涉及软件服务技术领域，特别是涉及餐饮服务方法和系统。

背景技术

在互联网浪潮下，新型信息化餐饮体验成为餐饮消费的新形式和大趋势。人们通过手机APP客户端、团购网站、微信等现代信息化手段，可以不出家门就实现在线点餐、在线支付等。

虽然现阶段互联网餐饮应用的形式多种多样，但缺少一种应用使餐饮商家能主动参与到与消费者交易前的互动中，商家在繁忙时段无力接单时只能降低消费者的体验与服务，而非繁忙时段则资源闲置。因此传统的定价和销售方式已经无法满足当前餐饮店面的营销需求，无法在保证用户体验与服务质量的同时最大化营业收入。

发明内容

鉴于以上所述现有技术的缺点，本发明的目的在于提供餐饮服务方法和系统，通过匹配餐饮商户端和消费者端的供需来提升效率，用于解决现有技术中的交易效率低下的问题。

为实现上述目的及其他相关目的，本发明提供一种餐饮服务方法，应用于通过网络连接的消费者端、服务端及商家端；所述方法包括：消费者端发送已生成的餐饮需求信息；商家端发送已生成的餐饮服务信息；服务端接收所述餐饮需求信息和餐饮服务信息；服务端将所述餐饮需求信息和餐饮服务信息进行匹配；其中，所述匹配条件包括：所述餐饮需求信息和餐饮服务信息均具有相互匹配的餐饮信息参数；服务端将餐饮服务信息转发至与其匹配的餐饮需求信息对应的消费者端；以及将餐饮需求信息转发至与其匹配的餐饮服务信息对应的商家端；用户端接收匹配于其餐饮需求信息的餐饮服务信息；商户端接收匹配于其餐饮服务信息的餐饮需求信息。

于本发明的一实施例中，所述餐饮信息参数还包括：餐饮人数参数、时间参数、饮食类型参数、地理位置参数、价格参数、加价/折扣参数及场地设施参数中的一种或多种组合。

于本发明的一实施例中，所述匹配是根据预设匹配规则执行的，所述匹配规则包括：所述餐饮需求信息和餐饮供给信息至少在时间参数和地理位置参数上匹配。

于本发明的一实施例中，所述匹配是根据预设匹配规则执行的，所述匹配规则包括：所述餐饮需求信息和餐饮供给信息至少在价格参数和加价/折扣参数上匹配。

于本发明的一实施例中，所述的餐饮服务方法，还包括：消费者端获取消费者在匹配的餐饮服务信息中选择下单的选择结果，据以生成下单通知并发送；服务端接收所述下单通知并转发给对应的商家端；商家端获取接受/拒绝所述下单的选择结果，据以生成用于响应所述下单的响应通知并发送；服务端接收所述响应通知并转发给对应的消费者端；消费者端接收所述响应通知。

于本发明的一实施例中，所述的餐饮服务方法，还包括：商家端获取商家在匹配的餐饮需求信息中选择抢单的选择结果，据以生成抢单通知并发送；服务端接收所述抢单通知并转发给对应的消费者端；消费者端获取消费者接受/拒绝所述抢单的选择结果，据以生成用于响应所述抢单的响应通知并发送；服务端接收所述响应通知并转发给对应的商家端；消费者端接收所述响应通知。

为实现上述目的及其他相关目的，本发明提供一种餐饮服务系统，包括：通过网络连接的消费者端、服务端及商家端；所述消费者端，包括：需求发送模块和供给接收模块；所述需求发送模块，用于发送已生成的餐饮需求信息；所述供给接收模块，用于接收匹配于所述餐饮需求信息的餐饮服务信息；所述商家端，包括：服务发送模块及需求接收模块；所述服务发送模块，用于发送已生成的餐饮服务信息；所述需求接收模块，用于接收匹配于所述餐饮服务信息的餐饮需求信息；所述服务端，包括：商家供给处理模块、消费者需求处理模块及匹配服务模块；所述商家供给处理模块，用于接收来自商家端的餐饮服务信息；所述消费者需求处理模块，用于来自消费者端的餐饮需求信息；所述匹配服务模块，用于将所述餐饮需求信息和餐饮服务信息进行匹配，其中，所述匹配条件包括：所述餐饮需求信息和餐饮服务信息均具有相互匹配的餐饮信息参数，所述餐饮信息参数至少包括：价格参数及其相关的加价/折扣参数；还用于将餐饮服务信息转发至与其匹配的餐饮需求信息对应的消费者端；以及用于将餐饮需求信息转发至与其匹配的餐饮服务信息对应的商家端。

于本发明的一实施例中，所述餐饮信息参数还包括：餐饮人数参数、时间参数、饮食类型参数、地理位置参数、价格参数、加价/折扣参数及场地设施参数中的一种或多种组合。

于本发明的一实施例中，所述匹配是根据预设匹配规则执行的，所述匹配规则包括：所述餐饮需求信息和餐饮供给信息至少在时间参数和地理位置参数上匹配。

于本发明的一实施例中，所述匹配是根据预设匹配规则执行的，所述匹配规则包括：所述餐饮需求信息和餐饮供给信息至少在价格参数和加价/折扣参数上匹配。

于本发明的一实施例中，所述消费者端，还用于获取消费者在匹配的餐饮服务信息中选择下单的选择结果，据以生成下单通知并发送；所述服务端，还用于接收所述下单通知并转发给对应的商家端；所述商家端，还用于获取接受/拒绝所述下单的选择结果，据以生成用于响应所述下单的响应通知并发送；所述服务端，还用于接收所述响应通知并转发给对应的消费者端；所述消费者端，还用于接收所述响应通知。

于本发明的一实施例中，所述商家端，还用于获取商家在匹配的餐饮需求信息中选择抢单的选择结果，据以生成抢单通知并发送；所述服务端，还用于接收所述抢单通知并转发给对应的消费者端；所述消费者端，还用于获取消费者接受/拒绝所述抢单的选择结果，据以生成用于响应所述抢单的响应通知并发送；所述服务端，还用于接收所述响应通知并转发给对应的商家端；所述消费者端，还用于接收所述响应通知。

如上所述，本发明提供的餐饮服务方法和系统，通过匹配消费者端和商户端之间的供需信息，通过匹配规则加以撮合并利用，从而高效地配置餐饮服务的供给和需求，促进交易的精准达成，使商家和消费者利益最大化。

附图说明

图1显示为本发明于一实施例中餐饮服务系统的结构示意图。

图2显示为本发明于一实施例中消费者端功能实现的逻辑模块示意图。

图3显示为本发明于一实施例中商户端功能实现的逻辑模块示意图。

图4显示为本发明于一实施例中服务端功能实现的逻辑模块示意图。

图5显示为本发明于一实施例中餐饮服务方法的流程示意图。

图6显示为本发明于一实施例中餐饮服务方法的流程示意图。

图7显示为本发明于一实施例中餐饮服务方法的流程示意图。

元件标号说明

1消费者端

11需求发送模块

12供给接收模块

2商户端

21供给发送模块

22需求接收模块

3服务端

31供给处理模块

32需求处理模块

33匹配供需模块

S101～S113步骤

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

本发明的技术方案应用于互联网环境中，所述互联网包括：广域网或局域网；通过网络服务来匹配来自消费者的需求信息和餐饮商户能提供的供给信息，从而提升双方建立交易关系的效率。

请参阅图1，本发明提供一实施例中的餐饮服务系统，其包括：通过互联网连接的服务端3、消费者端1及商户端2。

需说明的是，所述服务端3、消费者端1和商户端2可以是电子终端(例如智能手机、平板电脑、PC机、服务器/服务器组等)及其所运行的软件系统(例如安卓、IOS、Windows、Linux等)，亦可抽象理解为所述软件系统。

于一实施例中，所述消费者端1优选通过智能手机、平板电脑或PC机等实现，该些电子终端提供触摸屏、鼠标、键盘等输入装置与消费者交互，通过监听消费者输入内容而生成餐饮需求信息，并发送至服务端3；优选的，所述服务端3将所述餐饮需求信息以具有有效期的方式发布，一旦到期则失效或删除。

而在商户端2一侧其亦可通过智能手机、平板电脑或PC机等实现，该些电子终端提供触摸屏、鼠标、键盘等输入装置与消费者交互，通过监听消费者输入内容而生成餐饮供给信息，并发送至服务端3；优选的，所述服务端3将所述餐饮需求信息以具有有效期的方式发布，一旦到期则失效或删除。

服务端3根据预设的匹配规则来匹配所述餐饮供给信息和餐饮需求信息。具体的，所述匹配规则中至少定义了几种餐饮参数，而该几种餐饮参数应当为餐饮供给信息和餐饮需求信息所包含。

所述餐饮参数可以包括：价格参数、加价/折扣参数、餐饮人数参数、时间参数、饮食类型参数、地理位置参数、及场地设施参数等中的一种或多种组合。

举例来说，所述价格参数，是与餐饮消费的价格相关，例如包括人均预算、人均实际消费金额、最低消费等；所述加价/折扣参数，是例如在某一时段(如人流高低峰期、节假日等)商户在原价格基础上愿意给出的折扣或希望的提价，及消费者愿意在原价格基础上付出的加价或希望享受的折扣，本发明的技术方案中创新性地提出这一加价/折扣参数，若将其放入匹配规则中，可实现“动态定价”，使得供需更趋于平衡，使商户和消费者利益最大化。

另外，所述餐饮人数参数，在餐饮需求信息中例如为就餐的人数，而在所述餐饮供给信息例如为对应可供匹配的可接待人数；所述时间参数，在餐饮需求信息中例如为就餐时间、就餐时长等等，而在所述餐饮供给信息中例如对应可供匹配的接待时间、店面营业时间等；所述饮食类型参数例如为饮食种类：中餐、西餐、火锅、烧烤等等；所述地理位置参数可分为两种，一种是位置点信息包括：例如餐饮商户所在的商圈、行政区等，还可为地理位置范围信息，例如消费者距离各餐饮商户的距离信息，消费者自行设定的用餐范围，餐饮商户自行设定的服务覆盖范围等；所述场地设施参数例如就餐环境、座位安排等。

需说明的是，在进行判断距离远近或位置时，所述餐饮服务系统中的各端均可利用电子地图(LBS)来确定，在电子地图上可以得到地理位置或地理范围的信息，从而加以利用。

所述匹配规则，可以有多种类别，例如消费者端1和商户端2之间共用的，或者每个消费者端1均可自定制匹配规则并上传至服务端3，用于匹配(亦相当于过滤)各个商户端2存储在服务端3的餐饮供给信息，同理，每个商户端2亦可自定制匹配规则上传服务端3，用于匹配希望接收的餐饮需求信息。

而在上述餐饮参数中可任意选择一个或多个组合作为匹配规则所使用的参数，且各个参数可以有不同的优先级，以下举例说明：

1)于一实施例中，所述匹配是根据预设匹配规则执行的，所述匹配规则包括：餐饮需求信息和餐饮供给信息至少在时间参数和位置参数上匹配；若不匹配，则可例如不考虑其它餐饮参数；

举例来讲，餐饮商户关于其产品(如新品，活动，折扣等)生成含有时间参数(如折扣、活动的有效时间段)，以及地理位置参数及距离参数(如商户所在地理位置、及服务覆盖范围)的餐饮供给信息，并可附上发布时效的要求(一般是在有效时间段之前)，发送至服务端3；消费者的餐饮需求信息则含有时间参数(如用餐时间)和地理位置参数(例如消费者所在地理位置、就餐范围)；所述匹配规则可以是：若餐饮商户服务的服务覆盖范围和消费者的就餐范围具有交集，并且所述商家的有效时间段和消费者的用餐时间有交集，则认为匹配。

再者，所述匹配规则还可根据消费者及商家所在地理位置点的间距，以计算消费者在商户端2的发布时间段内的任意时间和有效时间段的开始时间的时间间隔是否小于消费者所在的地理位置到达商户的地理位置所需要的时间(该时间可以根据现有方式获得，例如百度地图中的估算两地点间到达时间的)，若小于，则表明消费者不可能在折扣的有效时间段内到达商户，则即使其他餐饮参数匹配，也不应作为匹配的情况；该判断可应用于在实际情况中，若消费者未对地理位置参数进行要求，则通过该先决判断可以滤除看似匹配实际并不匹配的餐饮供给信息。

2)于又一实施例中，所述匹配规则包括：餐饮需求信息和餐饮供给信息至少在价格参数及加价/折价参数上匹配；以下举一在较为极端的例子，以价格及加价/折价参数为最高优先级而不考虑其它参数的情况，例如消费者提供的需求为“晚上18:00、就餐3人、价格人均消费50～100元、可接受最少7折”，而商户提供的服务为“晚上19:00～20:00、有2人空位、价格人均消费80～90元、可提供5折优惠”，则亦可认为匹配；当然在一般情况下，匹配规则可以商家供给信息和消费者需求信息在其他参数例如(时间参数、地理位置参数等)与价格参数、加价/折扣参数上均匹配作为判定匹配的条件。

所述服务端3根据所述匹配规则匹配后，将匹配的商户供给信息传送至对应的消费者端1，且将匹配的消费者需求信息传送至对应的商户端2。

需说明的是，所述匹配并非为上述举例中所示的需求和供给信息中各项参数完全一致，也可以通过计算匹配度的方式进行，例如对不同餐饮参数设定不同的权重值，从而计算总的匹配度，在匹配度大于预定值的时候算作匹配；举例来说，例如消费者提供的需求为“晚上19:00、就餐4人、价格人均消费50～100元、可接受最少95折”，而商户提供的服务为“晚上20:00、有四人空位、价格人均消费80～90元起、可提供最多9折”，假设时间参数、人数参数、价格参数、加价/折扣参数分别的权重为15％、20％、50％、15％，且预设匹配度阈值为70％，而计算后，匹配度达到了85％大于预设匹配度阈值，则算作匹配；当然，此仅为一种匹配度的计算方式，并非以此为限；优选的，在后续的发送信息的过程中，匹配出的发送给用户端的餐饮供给信息或匹配出的发送给商户端2的餐饮需求信息均可以按匹配度从高到低的方式展示。

在一实施例中，由于该些餐饮参数中有部分是“定性”的，例如场地设施等，而有部分是“定量”的，例如时间、距离、就餐人数、价格、折扣等，对于该部分定量的数值参数，亦可将餐饮需求信息中的参数数值和餐饮供给信息中的参数数值进行比较以偏差或偏差比例不大于某个阈值而作为匹配规则，例如消费者提供的需求为“晚上19:00、就餐4人、价格人均消费50～100元、可接受最少95折”，而商户提供的服务为“晚上19:30、有四人空位、价格人均消费105元、可提供最多9折”，而匹配规则中包含有“预设时间参数偏差不大于1小时、价格偏差不大于最大值的10％”的条件，则可算作匹配。

结合上述实施例可知，所述匹配并非需餐饮需求信息和餐饮供给信息中的各项餐饮参数完全一致，亦可通过对匹配规则加以设定而实现不同的匹配结果。

在完成匹配之后，服务端3即可将餐饮供给信息转发至与其匹配的餐饮需求信息对应的消费者端1；将餐饮需求信息转发至与其匹配的餐饮供给信息对应的商户端2。

在完成发送匹配的上述信息后，消费者端1和商户端2之间即可根据所接收信息形成交易，交易方式可选择以下至少一种：

交易方式1：消费者端1在接收到与其发布的餐饮需求信息匹配的餐饮供给信息后，其可从中选择希望就餐的商户的供给信息进行“下单”(即下订单，后文还将其作为名词以与商户端2的“抢单”区分)，从而生成下单通知，通过互联网发送给所述服务端3而由所述服务端3转发至对应的商户端2，商户端2监听商户输入的选择接受/或拒绝所述下单的选择结果，生成响应通知而再经由服务端3转发至对应消费者端1；若商户选择接受，则在消费者就餐付款后，交易完毕。

交易方式2：商户端2在接收到与其发布的餐饮供给信息匹配的餐饮需求信息后，其可从中选择希望提供服务的消费者的需求信息进行“抢单”(即相比于其他商户抢先下订单，后文还将其作为名词以与消费者端1的“下单”区分)，从而生成抢单通知，通过互联网发送给所述服务端3而由所述服务端3转发至对应的消费者端1，消费者端1监听消费者输入的选择接受/或拒绝所述抢单的选择结果，生成响应通知而再经由服务端3转发至对应商户端2；若消费者选择接受，则在消费者就餐付款后，交易完毕。

于一实施例中，优选的，所述服务端3还可具有多个存储模块，用于存储例如链接到商家的具体地址信息、描述、特点、该商户的供给信息与商家的对应关系；和/或存储链接到消费者的具体需求信息、地址位置信息与消费者的对应关系；和/或存储每次交易的交易信息，包括交易的商户供给信息、消费者需求信息及交易结果信息等。

请参阅图2至4，分别显示为为实现上述实施例而在消费者端1、服务端3和商户端2需实现的逻辑功能模块图；各端的功能皆可通过搭载软件APP实现，例如，所述；其它实现的技术细节可参考前述实施例，此处不作重复赘述。

如图2所示，所述消费者端1，包括：需求发送模块11和供给接收模块22；所述需求发送模块11，用于发送已生成的餐饮需求信息；所述供给接收模块22，用于接收匹配于所述餐饮需求信息的餐饮供给信息。

如图3所示，所述商户端2，包括：供给发送模块21和需求接收模块22；所述供给发送模块21，用于发送已生成的餐饮供给信息；所述需求接收模块22，用于接收匹配于所述餐饮供给信息的餐饮需求信息。

如图4所示，所述服务端3，包括：供给处理模块31、需求处理模块32及匹配供需模块33；所述供给处理模块31，用于接收来自商户端2的餐饮供给信息；所述需求处理模块32，用于来自消费者端1的餐饮需求信息；所述匹配供需模块33，用于将所述餐饮需求信息和餐饮供给信息进行匹配，其中，所述匹配是根据预设匹配规则执行的，所述匹配规则包括：所述餐饮需求信息和餐饮供给信息具有相互匹配的餐饮信息参数，所述餐饮信息参数至少包括：价格参数及其相关的加价/折扣参数；还用于将餐饮供给信息转发至与其匹配的餐饮需求信息对应的消费者端1；以及用于将餐饮需求信息转发至与其匹配的餐饮供给信息对应的商户端2。

对应实现前述交易方式1，于一实施例中，所述消费者端1还可包括下单模块，用于获取消费者在匹配的餐饮供给信息中选择下单的选择结果，据以生成下单通知并通过所述发送模块发送；还用于接收接受/拒绝所述下单的响应通知；

所述服务端3还可包括交易处理模块，用于转发来自消费者端的下单通知至对应商户端，其中，所述下单通知是消费者端通过获取消费者在匹配的餐饮供给信息中选择下单的选择结果来据以生成并发送的；并用于转发所述商户端发来的接受/拒绝所述下单的响应通知至所述消费者端；

所述商家端2还可包括下单响应模块，用于接收下单通知，其中，所述下单通知是根据消费者在匹配的餐饮供给信息中选择下单的选择结果来对应生成并发送的，且获取接受/拒绝所述下单的选择结果，据以生成用于响应所述下单的响应通知并发送。

而对应实现前述交易方式2，于一实施例中，所述商家端2还可包括抢单模块，用于获取商户在匹配的餐饮需求信息中选择抢单的选择结果，据以生成抢单通知并发送；还用于接收接受/拒绝所述抢单的响应通知；

所述服务端3还可包括交易处理模块，用于转发来自商户端的抢单通知至对应消费者端，其中，所述抢单通知是商户端根据商户在匹配的餐饮需求信息中选择抢单的选择结果来据以生成并发送的；还用于转发所述消费者端发来的接受/拒绝所述抢单的响应通知至所述商户端；

所述消费者端1还可包括抢单响应模块，用于接收来自服务端发来的商户的抢单通知，且获取消费者接受/拒绝所述抢单的选择结果，据以生成用于响应所述抢单的响应通知并发送。

再如图5所示，本发明再提供一服务方法的实施例，与前述实施例原理大致相同，因此相同的技术细节不再重复赘述：

其包括：

步骤S101：消费者端1发送已生成的餐饮需求信息给服务端3；

步骤S102：商户端2发送已生成的餐饮供给信息给服务端3；需说明的是，所述S101和S102不限定先后顺序；

步骤S103：服务端3将所述餐饮需求信息和餐饮供给信息进行匹配；其中，所述匹配是根据预设匹配规则执行的，所述匹配规则包括：所述餐饮需求信息和餐饮供给信息具有相互匹配的餐饮信息参数，所述餐饮信息参数至少包括：价格参数及其相关的加价/折扣参数；

步骤S104：服务端3将餐饮供给信息转发至与其匹配的餐饮需求信息对应的消费者端1；

步骤S105：将餐饮需求信息转发至与其匹配的餐饮供给信息对应的商户端2。

需说明的是，所述S104和S105不限定先后顺序。

进一步优选的，如图6所示，本发明再提供餐饮服务方法中消费者端1根据所接收匹配的餐饮服务信息生成下单至商家端处理的流程：

步骤S106：消费者端1获取消费者在匹配的餐饮供给信息中选择下单的选择结果，据以生成下单通知并发送；

步骤S107：服务端3接收所述下单通知并转发给对应的商户端2；

步骤S108：商户端2获取接受/拒绝所述下单的选择结果，据以生成用于响应所述下单的响应通知并发送；

步骤S109：服务端3接收所述响应通知并转发给对应的消费者端1。

若商家接受下单，则商家准备线下服务，消费者收到通知后进行就餐，在付款后交易成立。

进一步优选的，如图7所示，本发明再提供餐饮服务方法中商户端2根据所接收匹配的信息生成抢单发送至消费者端1处理的流程：

步骤S110：商户端2获取商户在匹配的餐饮需求信息中选择抢单的选择结果，据以生成抢单通知并发送；

步骤S111：服务端3接收所述抢单通知并转发给对应的消费者端1；

步骤S112：消费者端1获取消费者接受/拒绝所述抢单的选择结果，据以生成用于响应所述抢单的响应通知并发送；

步骤S113：服务端3接收所述响应通知并转发给对应的商户端2。

若消费者接受抢单，则商家收到通知后准备线下服务，消费者进行就餐，在付款后交易成立。

本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims (12)

1.一种餐饮服务方法，其特征在于，应用于通过网络连接的消费者端、服务端及商家端；所述方法包括：

消费者端发送已生成的餐饮需求信息；

商家端发送已生成的餐饮服务信息；

服务端接收所述餐饮需求信息和餐饮服务信息；

服务端将所述餐饮需求信息和餐饮服务信息进行匹配；其中，所述匹配条件包括：所述餐饮需求信息和餐饮服务信息均具有相互匹配的餐饮信息参数；

服务端将餐饮服务信息转发至与其匹配的餐饮需求信息对应的消费者端；以及将餐饮需求信息转发至与其匹配的餐饮服务信息对应的商家端；

用户端接收匹配于其餐饮需求信息的餐饮服务信息；

商户端接收匹配于其餐饮服务信息的餐饮需求信息。

2.根据权利要求1所述的餐饮服务方法，其特征在于，所述餐饮信息参数还包括：餐饮人数参数、时间参数、饮食类型参数、地理位置参数、价格参数、加价/折扣参数及场地设施参数中的一种或多种组合。

3.根据权利要求2所述的餐饮服务方法，其特征在于，所述匹配是根据预设匹配规则执行的，所述匹配规则包括：所述餐饮需求信息和餐饮供给信息至少在时间参数和地理位置参数上匹配。

4.根据权利要求2所述的餐饮服务方法，其特征在于，所述匹配是根据预设匹配规则执行的，所述匹配规则包括：所述餐饮需求信息和餐饮供给信息至少在价格参数和加价/折扣参数上匹配。

5.根据权利要求1所述的餐饮服务方法，其特征在于，还包括：

消费者端获取消费者在匹配的餐饮服务信息中选择下单的选择结果，据以生成下单通知并发送；

服务端接收所述下单通知并转发给对应的商家端；

商家端获取接受/拒绝所述下单的选择结果，据以生成用于响应所述下单的响应通知并发送；

服务端接收所述响应通知并转发给对应的消费者端；

消费者端接收所述响应通知。

6.根据权利要求1所述的餐饮服务方法，其特征在于，还包括：

商家端获取商家在匹配的餐饮需求信息中选择抢单的选择结果，据以生成抢单通知并发送；

服务端接收所述抢单通知并转发给对应的消费者端；

消费者端获取消费者接受/拒绝所述抢单的选择结果，据以生成用于响应所述抢单的响应通知并发送；

服务端接收所述响应通知并转发给对应的商家端；

消费者端接收所述响应通知。

7.一种餐饮服务系统，其特征在于，包括：通过网络连接的消费者端、服务端及商家端；

所述消费者端，包括：需求发送模块和供给接收模块；

所述需求发送模块，用于发送已生成的餐饮需求信息；

所述供给接收模块，用于接收匹配于所述餐饮需求信息的餐饮服务信息；

所述商家端，包括：

所述服务发送模块，用于发送已生成的餐饮服务信息；

所述需求接收模块，用于接收匹配于所述餐饮服务信息的餐饮需求信息；

所述服务端，包括：商家供给处理模块、消费者需求处理模块及匹配服务模块；

所述商家供给处理模块，用于接收来自商家端的餐饮服务信息；

所述消费者需求处理模块，用于来自消费者端的餐饮需求信息；

所述匹配服务模块，用于将所述餐饮需求信息和餐饮服务信息进行匹配，其中，所述匹配条件包括：所述餐饮需求信息和餐饮服务信息均具有相互匹配的餐饮信息参数，所述餐饮信息参数至少包括：价格参数及其相关的加价/折扣参数；还用于将餐饮服务信息转发至与其匹配的餐饮需求信息对应的消费者端；以及用于将餐饮需求信息转发至与其匹配的餐饮服务信息对应的商家端。

8.根据权利要求7所述的餐饮服务系统，其特征在于，所述餐饮信息参数还包括：餐饮人数参数、时间参数、饮食类型参数、地理位置参数、价格参数、加价/折扣参数及场地设施参数中的一种或多种组合。

9.根据权利要求8所述的餐饮服务系统，其特征在于，所述匹配是根据预设匹配规则执行的，所述匹配规则包括：所述餐饮需求信息和餐饮供给信息至少在时间参数和地理位置参数上匹配。

10.根据权利要求8所述的餐饮服务系统，其特征在于，所述匹配是根据预设匹配规则执行的，所述匹配规则包括：所述餐饮需求信息和餐饮供给信息至少在价格参数和加价/折扣参数上匹配。

11.根据权利要求7所述的餐饮服务系统，其特征在于，

所述消费者端，还用于获取消费者在匹配的餐饮服务信息中选择下单的选择结果，据以生成下单通知并发送；

所述服务端，还用于接收所述下单通知并转发给对应的商家端；

所述商家端，还用于获取接受/拒绝所述下单的选择结果，据以生成用于响应所述下单的响应通知并发送；

所述服务端，还用于接收所述响应通知并转发给对应的消费者端；

所述消费者端，还用于接收所述响应通知。

12.根据权利要求7所述的餐饮服务系统，其特征在于，

所述商家端，还用于获取商家在匹配的餐饮需求信息中选择抢单的选择结果，据以生成抢单通知并发送；

所述服务端，还用于接收所述抢单通知并转发给对应的消费者端；

所述消费者端，还用于获取消费者接受/拒绝所述抢单的选择结果，据以生成用于响应所述抢单的响应通知并发送；

所述服务端，还用于接收所述响应通知并转发给对应的商家端；

所述消费者端，还用于接收所述响应通知。