9折”，假设时间参数、人数参数、价格参数、加价/折扣参数分别的权重为15%、20%、50%、15%，且预设匹配度阈值为70%，而计算后，匹配度达到了85%大于预设匹配度阈值，则算作匹配；当然，此仅为一种匹配度的计算方式，并非以此为限;优选的，在后续的发送信息的过程中，匹配出的发送给用户端的餐饮供给信息或匹配出的发送给商户端2的餐饮需求信息均可以按匹配度从高到低的方式展示。
[0058]在一实施例中，由于该些餐饮参数中有部分是“定性”的，例如场地设施等，而有部分是“定量”的，例如时间、距离、就餐人数、价格、折扣等，对于该部分定量的数值参数，亦可将餐饮需求信息中的参数数值和餐饮供给信息中的参数数值进行比较以偏差或偏差比例不大于某个阈值而作为匹配规则，例如消费者提供的需求为“晚上19:00、就餐4人、价格人均消费50?100元、可接受最少95折”，而商户提供的服务为“晚上19:30、有四人空位、价格人均消费105元、可提供最多9折”，而匹配规则中包含有“预设时间参数偏差不大于I小时、价格偏差不大于最大值的10%”的条件，则可算作匹配。
[0059]结合上述实施例可知，所述匹配并非需餐饮需求信息和餐饮供给信息中的各项餐饮参数完全一致，亦可通过对匹配规则加以设定而实现不同的匹配结果。
[0060]在完成匹配之后，服务端3即可将餐饮供给信息转发至与其匹配的餐饮需求信息对应的消费者端I;将餐饮需求信息转发至与其匹配的餐饮供给信息对应的商户端2。
[0061]在完成发送匹配的上述信息后，消费者端I和商户端2之间即可根据所接收信息形成交易，交易方式可选择以下至少一种:
[0062]交易方式1:消费者端I在接收到与其发布的餐饮需求信息匹配的餐饮供给信息后，其可从中选择希望就餐的商户的供给信息进行“下单”(即下订单，后文还将其作为名词以与商户端2的“抢单”区分)，从而生成下单通知，通过互联网发送给所述服务端3而由所述服务端3转发至对应的商户端2，商户端2监听商户输入的选择接受/或拒绝所述下单的选择结果，生成响应通知而再经由服务端3转发至对应消费者端I;若商户选择接受，则在消费者就餐付款后，交易完毕。
[0063]交易方式2:商户端2在接收到与其发布的餐饮供给信息匹配的餐饮需求信息后，其可从中选择希望提供服务的消费者的需求信息进行“抢单”(即相比于其他商户抢先下订单，后文还将其作为名词以与消费者端I的“下单”区分)，从而生成抢单通知，通过互联网发送给所述服务端3而由所述服务端3转发至对应的消费者端I，消费者端I监听消费者输入的选择接受/或拒绝所述抢单的选择结果，生成响应通知而再经由服务端3转发至对应商户端2;若消费者选择接受，则在消费者就餐付款后，交易完毕。
[0064]于一实施例中，优选的，所述服务端3还可具有多个存储模块，用于存储例如链接到商家的具体地址信息、描述、特点、该商户的供给信息与商家的对应关系;和/或存储链接到消费者的具体需求信息、地址位置信息与消费者的对应关系;和/或存储每次交易的交易信息，包括交易的商户供给信息、消费者需求信息及交易结果信息等。
[0065]请参阅图2至4，分别显示为为实现上述实施例而在消费者端1、服务端3和商户端2需实现的逻辑功能模块图；各端的功能皆可通过搭载软件APP实现，例如，所述;其它实现的技术细节可参考前述实施例，此处不作重复赘述。
[0066]如图2所示，所述消费者端I，包括:需求发送模块11和供给接收模块22;所述需求发送模块11，用于发送已生成的餐饮需求信息;所述供给接收模块22，用于接收匹配于所述餐饮需求信息的餐饮供给信息。
[0067]如图3所示，所述商户端2，包括:供给发送模块21和需求接收模块22;所述供给发送模块21，用于发送已生成的餐饮供给信息;所述需求接收模块22，用于接收匹配于所述餐饮供给信息的餐饮需求信息。
[0068]如图4所示，所述服务端3，包括:供给处理模块31、需求处理模块32及匹配供需模块33;所述供给处理模块31，用于接收来自商户端2的餐饮供给信息;所述需求处理模块32，用于来自消费者端I的餐饮需求信息;所述匹配供需模块33，用于将所述餐饮需求信息和餐饮供给信息进行匹配，其中，所述匹配是根据预设匹配规则执行的，所述匹配规则包括:所述餐饮需求信息和餐饮供给信息具有相互匹配的餐饮信息参数，所述餐饮信息参数至少包括:价格参数及其相关的加价/折扣参数;还用于将餐饮供给信息转发至与其匹配的餐饮需求信息对应的消费者端I;以及用于将餐饮需求信息转发至与其匹配的餐饮供给信息对应的商户端2。
[0069]对应实现前述交易方式I，于一实施例中，所述消费者端I还可包括下单模块，用于获取消费者在匹配的餐饮供给信息中选择下单的选择结果，据以生成下单通知并通过所述发送模块发送;还用于接收接受/拒绝所述下单的响应通知；
[0070]所述服务端3还可包括交易处理模块，用于转发来自消费者端的下单通知至对应商户端，其中，所述下单通知是消费者端通过获取消费者在匹配的餐饮供给信息中选择下单的选择结果来据以生成并发送的；并用于转发所述商户端发来的接受/拒绝所述下单的响应通知至所述消费者端；
[0071]所述商家端2还可包括下单响应模块，用于接收下单通知，其中，所述下单通知是根据消费者在匹配的餐饮供给信息中选择下单的选择结果来对应生成并发送的，且获取接受/拒绝所述下单的选择结果，据以生成用于响应所述下单的响应通知并发送。
[0072]而对应实现前述交易方式2，于一实施例中，所述商家端2还可包括抢单模块，用于获取商户在匹配的餐饮需求信息中选择抢单的选择结果，据以生成抢单通知并发送;还用于接收接受/拒绝所述抢单的响应通知；
[0073]所述服务端3还可包括交易处理模块，用于转发来自商户端的抢单通知至对应消费者端，其中，所述抢单通知是商户端根据商户在匹配的餐饮需求信息中选择抢单的选择结果来据以生成并发送的；还用于转发所述消费者端发来的接受/拒绝所述抢单的响应通知至所述商户端；
[0074]所述消费者端I还可包括抢单响应模块，用于接收来自服务端发来的商户的抢单通知，且获取消费者接受/拒绝所述抢单的选择结果，据以生成用于响应所述抢单的响应通知并发送。
[0075]再如图5所示，本发明再提供一服务方法的实施例，与前述实施例原理大致相同，因此相同的技术细节不再重复赘述:
[0076]其包括:
[0077]步骤SlOl:消费者端I发送已生成的餐饮需求信息给服务端3;
[0078]步骤S102:商户端2发送已生成的餐饮供给信息给服务端3;需说明的是，所述SlOl和S102不限定先后顺序；
[0079]步骤S103:服务端3将所述餐饮需求信息和餐饮供给信息进行匹配;其中，所述匹配是根据预设匹配规则执行的，所