餐盒回收及回收处理方法、系统、装置、及存储介质与流程

本申请涉及计算机数据处理领域，具体的涉及一种餐盒回收及回收处理方法、系统、装置、及存储介质。

背景技术：

随着人们生活节奏的加快以及o2o平台的发展，外卖点餐为人们提供了便利的餐饮体验，并发展成为人们的一种生活方式。然而这种便利的餐饮体验带来庞大的消费人群的同时伴随而来的是一次性餐盒的使用数量暴增，数据显示外卖就餐的普及使得每周至少有4亿份外卖产生至少4亿个一次性打包盒和4亿个塑料袋及4亿份一次性餐具的废弃，从而造成了资源的极大浪费与环境的严重污染。

另一方面，外卖餐盒几乎均是采用塑料或纸质原料制成，其使用成本较为低廉但回收成本高，而且由于点餐的种类以及点餐的用户是多种多样的，所以在外卖餐盒使用后的卫生条件和污染程度均是不可把控的。因此，外卖餐盒在回收方面面临着巨大的难题与挑战。

鉴于此，打造环保外卖是亟需解决的问题。

技术实现要素：

鉴于以上所述相关技术的缺点，本申请的目的在于提供一种餐盒回收及回收处理方法、系统、装置、及存储介质，用以克服上述相关技术中存在的餐盒难以回收的技术问题。

为实现上述目的及其他相关目的，本申请公开的第一方面提供一种餐盒回收处理方法，包括以下步骤：基于一餐饮订单获取包含所述餐饮订单的餐饮详情信息；依据所述餐饮详情信息审核所述餐饮订单所配用的餐盒是否满足回收标准；确定所述餐盒满足回收标准时，将相关于餐盒可回收的信息展示在所述订餐系统的展示界面中以供用户选择餐盒可回收的服务；其中，所述餐饮订单是通过一订餐系统提交的，所述订餐系统藉由装载于一用户客户端的应用程序运行。

本申请公开的第二方面提供一种餐盒回收处理系统，包括获取模块、审核模块、以及显示模块，其中，所述获取模块用于基于一餐饮订单获取包含所述餐饮订单的餐饮详情信息；所述审核模块用于依据所述餐饮详情信息审核所述餐饮订单所配用的餐盒是否满足回收标准；所述显示模块用于在确定所述餐盒满足回收标准时，将相关于餐盒可回收的信息展示在所述订餐系统的展示界面中以供用户选择餐盒可回收的服务；其中，所述餐饮订单是通过一订餐系统提交的，所述订餐系统藉由装载于一用户客户端的应用程序运行。

本申请公开的第三方面提供一种云服务器系统，包括至少一存储设备和至少一处理设备，所述至少一存储设备用于存储至少一个程序；所述至少一处理设备与所述存储设备相连，用于运行所述至少一个程序时执行并实现如本申请公开的第一方面提供的任一所述的餐盒回收处理方法。

本申请公开的第四方面提供一种餐盒回收方法，包括以下步骤：在订单详情界面中提交一餐饮订单；接收到所述餐饮订单所配用的餐盒满足回收标准时加载一回收餐盒提醒项，以供用户选择餐盒可回收的服务。

本申请公开的第五方面提供一种订餐系统，包括检测模块、提交模块、以及加载模块，其中，所述检测模块用于检测当前显示界面中的触发操作，所述提交模块用于在订单详情界面中提交一餐饮订单，所述加载模块用于接收到所述餐饮订单所配用的餐盒满足回收标准时加载一回收餐盒提醒项以供用户选择餐盒可回收的服务。

本申请公开的第六方面提供一种电子装置，包括：显示器、至少一个存储器、以及至少一个处理器，其中所述至少一个存储器用于存储至少一个程序；所述至少一个处理器与所述至少一个存储器连接，用于运行所述至少一个程序时以执行并实现本申请公开的第四方面提供餐盒回收方法。

本申请公开的第七方面提供一种计算机可读存储介质，存储有至少一个程序，所述程序被处理器执行时实现如本申请公开的第一方面提供的任一所述的餐盒回收处理方法，或者本申请公开的第四方面提供的任一所述的餐盒回收方法。

综上所述，本申请公开的餐盒回收及回收处理方法、系统、装置、及存储介质，通过服务端审核用户客户端提交的餐饮订单所配用的餐盒是否满足回收标准，从而在餐饮订单所配用的餐盒满足回收标准时，将回收餐盒提醒项展示在用户客户端的展示界面中，一则将对餐盒的审核过程以数字化的方式在服务端实现，大大节约了回收成本以及降低了人接触餐盒所存在的安全风险，另外还在用户客户端为用户提供餐盒回收的功能，有利于餐盒回收流程的简化以及实现餐盒回收过程中流程的把控。

本领域技术人员能够从下文的详细描述中容易地洞察到本申请的其它方面和优势。下文的详细描述中仅显示和描述了本申请的示例性实施方式。如本领域技术人员将认识到的，本申请的内容使得本领域技术人员能够对所公开的具体实施方式进行改动而不脱离本申请所涉及发明的精神和范围。相应地，本申请的附图和说明书中的描述仅仅是示例性的，而非为限制性的。

附图说明

本申请所涉及的发明的具体特征如所附权利要求书所显示。通过参考下文中详细描述的示例性实施方式和附图能够更好地理解本申请所涉及发明的特点和优势。对附图简要说明书如下：

图1显示为本申请餐盒回收处理方法在一实施例中的流程图。

图2显示为本申请餐盒回收方法在一实施例中的流程图。

图3显示为本申请在一实施例中订单详情界面的示意图。

图4显示为本申请在又一实施例中订单详情界面的示意图。

图5显示为本申请在一实施例中包含回收餐盒提醒项的展示界面的示意图。

图6显示为本申请在另一实施例中的餐盒回收方法的流程图。

图7显示为本申请在一实施例中的回收详情页的示意图。

图8显示为本申请餐盒回收处理系统在一实施例中的模块框图。

图9显示为本申请订餐系统在一实施例中的模块框图。

图10显示为本申请云服务器系统在一实施例中的模块框图。

图11显示为本申请电子装置在一实施例中的模块框图。

具体实施方式

以下由特定的具体实施例说明本申请的实施方式，熟悉此技术的人士可由本说明书所揭露的内容轻易地了解本申请的其他优点及功效。

在下述描述中，参考附图，附图描述了本申请的若干实施例。应当理解，还可使用其他实施例，并且可以在不背离本公开的精神和范围的情况下进行模块或单元组成、电气以及操作上的改变。下面的详细描述不应该被认为是限制性的，并且本申请的实施例的范围仅由公布的专利的权利要求所限定。这里使用的术语仅是为了描述特定实施例，而并非旨在限制本申请。

再者，如同在本文中所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文中有相反的指示。应当进一步理解，术语“包含”、“包括”表明存在所述的特征、步骤、操作、元件、组件、项目、种类、和/或组，但不排除一个或多个其他特征、步骤、操作、元件、组件、项目、种类、和/或组的存在、出现或添加。此处使用的术语“或”和“和/或”被解释为包括性的，或意味着任一个或任何组合。因此，“a、b或c”或者“a、b和/或c”意味着“以下任一个：a；b；c；a和b；a和c；b和c；a、b和c”。仅当元件、功能、步骤或操作的组合在某些方式下内在地互相排斥时，才会出现该定义的例外。

如背景技术里所述，外卖点餐的普及造成了资源的极大浪费与环境的严重污染，同时，外卖餐盒在回收方面面临着成本高、以及餐盒卫生条件和污染程度不可控等难题。

鉴于此，本申请提供了一种餐盒回收处理方法，用于包括服务端与至少一用户客户端的网络系统中，所述系统例如为商业实体的在线订餐系统或平台，所述网络可以是因特网、一个或多个内部网、局域网(lan)、广域网(wlan)、存储局域网(san)等，或其适当组合，本申请实施例对包括用户客户端在内的各种客户端、服务端的种类，或者发布者终端与服务器之间、响应者终端与服务器之间通信网络的类型或协议等在均不做限定。

在本申请的某些实施例中，所述用户客户端例如为装载有app应用程序或具备网页/网站访问性能的电子设备，所述电子设备包括存储器、存储器控制器、一个或多个处理单元(cpu)、外设接口、rf电路、音频电路、扬声器、麦克风、输入/输出(i/o)子系统、显示屏、其他输出或控制设备，以及外部端口等组件，这些组件通过一条或多条通信总线或信号线进行通信。所述电子设备包括但不限于如台式电脑、笔记本电脑、平板电脑、智能手机、智能电视等个人计算机。所述电子设备还可以是由带有多个虚拟机的主机和对应每个虚拟机的人机交互装置(如触控显示屏、键盘和鼠标)所构成的电子设备。

在本申请的某些实施例中，所述服务端可以根据功能、负载等多种因素布置在一个或多个实体服务器上。其中，当分布在多个实体服务器时，所述服务端可以由基于云架构的服务器组成。例如，基于云架构的服务器包括公共云(publiccloud)服务端与私有云(privatecloud)服务端，其中，所述公共或私有云服务端包括software-as-a-service(软件即服务，saas)、platform-as-a-service(平台即服务，paas)及infrastructure-as-a-service(基础设施即服务，iaas)等。所述私有云服务端例如美团云计算服务平台、阿里云计算服务平台、亚马逊(amazon)云计算服务平台、百度云计算平台、腾讯云计算平台等。所述服务端还可以由分布的或集中的服务器集群构成。例如，所述服务器集群由至少一台实体服务器构成。每个实体服务器中配置多个虚拟服务器，每个虚拟服务器运行所述服务端中的至少一功能模块，各虚拟服务器之间通过网络通信。

在本申请的某些实施例中，服务端采用本申请提出的餐盒回收处理方法对餐饮订单所配用的餐盒的回收状况进行审核和管理。例如，服务端对用户在订餐系统中提交的餐饮订单进行餐盒回收状况的审核，并依据审核结果为用户在订餐系统中提供餐盒回收功能，服务端还会基于用户触发餐盒回收功能为用户提供上门取餐盒服务，从而完成餐盒的回收。在实施例中，所述订餐系统例如为包括o2o客户端的系统，比如所述o2o客户端例如为美团app、美团外卖app或者大众点评app，又或者饿了么app、或者百度外卖等o2o客户端。

请参阅图1，显示为本申请餐盒回收处理方法在一实施例中的流程图，如图所示，所述餐盒回收处理方法包括步骤s10、步骤s11、以及步骤s12，以下结合图1对本申请提出的餐盒回收处理方法进行详细说明。

在步骤s10中，服务端基于一餐饮订单获取包含所述餐饮订单的餐饮详情信息。

其中，所述餐饮订单是通过一订餐系统提交的，所述订餐系统藉由装载于一用户客户端中的应用程序运行，其具体的结构以及请参阅后叙针对图9的说明，在此不做赘述。在一示例中，所述餐饮订单是藉由触发操作订餐系统中的一提交订餐请求项提交的餐饮订单，例如，在订餐系统中加载有订单详情界面，所述订单详情界面中展示有提交订餐请求项，用户通过触发所述提交订单请求项提交餐饮订单，其具体过程请参阅后叙针对图3的说明。如此，服务端需要对藉由订餐系统提交的所有的餐饮订单进行信息处理与审核。在另一示例中，所述餐饮订单是藉由触发操作订餐系统中的一提交订餐请求项提交的餐饮订单，并且提交的餐饮订单包括用户提交的餐盒审核请求，例如，订餐系统中加载有订单详情界面，所述订单详情界面除了展示有在一示例中所述的提交订餐请求项，还展示有餐盒审核请求项，用户可根据自己的意图选择性的触发操作所述餐盒审核请求项，在此基础上再触发操作所述提交订餐请求项提交餐饮订单，其具体过程请参阅后叙针对图4的说明。如此，服务端仅需对藉由订餐系统提交的包含有餐盒审核请求的餐饮订单进行信息处理与审核，从而在用户并没有餐盒回收意图的情况下，省去了对该餐饮订单的信息处理和审核，节约计算资源并使得流程简约化。需要说明的是，前述以及后叙提及的触发或触发操作包括但不限于点击(例如利用鼠标等输入设备点击、或利用手指触击等)、长按、按压、或者重复触控等，应理解的，用户对一对象执行触发操作可以称之为用户触发该对象，例如，用户对预订界面执行触发操作，也可以称之为用户触发该预订界面。又如，用户触发一热键区域即表示用户对该热键区域执行了触发操作，等等。下文将不再对类似的情况进行赘述。

应理解的，所述的请求项是指可以通过例如触发或点击等操作进行指令或信息输入的组件，例如图3中所示的“提交订单”，或者图4中所示的“为节约资源保护环境，本人同意申请餐盒回收”的区域，又或者图7中所示的“确认”组件等功能。

在一实施例中，所述餐饮详情信息包括所述餐饮订单，所述餐饮订单中包括商家账户信息、餐品信息、以及用户账户信息。其中，所述商家账户信息包括该餐饮订单对应的商家名称以及地理位置等。所述餐品信息包括该餐饮订单对应的餐品以及附加内容，所述餐品可例如为麻辣烫、干锅、米饭、汤羹等任一种或多种用户基于商家提供的餐品而加入到所述餐饮订单中的餐品，附加内容例如为麻辣口味、提供餐具等基于用户自主选择或填写而加入到所述餐饮订单中备注信息。所述用户账户信息包括该餐饮订单对应的用户联系方式及地理位置等。需要说明的是，以上餐饮订单中包括的各信息的具体内容仅为举例示意，实际应用中，本领域技术人员可根据餐饮订单中所实际能够提供的信息进行选择性增减。

在另一实施例中，所述餐饮详情信息还包括服务端基于餐饮订单中的上述信息从服务端数据库中获取的信息。其中，服务端的数据库包括入驻包括该服务端的网络系统平台的商家和用户预先填写以及经所述商家和用户授权从第三方服务商获取到商家数据和用户数据、依据商家数据生成用于表征商家安全状态的二维码数据、以及依据用户数据生成用于表征用户健康状态的二维码数据。其中，所述二维码数据为利用0、1对至少商家数据或用户数据进行编码而得到的由0、1构成的码矩阵。所述二维码数据的编码方式举例但不限于：对商家数据或用户数据中的各数据进行一维编码处理并将各一维编码处理的数据堆叠成二维码数据，例如，采用code16k、code49、或pdf417等方式生成二维码数据；或者，对商家数据或用户数据中的各数据进行交织编码处理，得到二维码数据，例如，采用codeone、maxicode、qrcode、或datamatrix等方式生成二维码数据。

在一示例中，所述服务端基于餐饮订单中的上述信息从服务端数据库中获取的信息为基于所述餐饮订单中的商家账户信息从数据库中获取到商家数据，例如，商家数据为商家为其提供的餐品所配用的餐盒材质、餐盒来源、以及备餐人员健康状况中的一种或多种数据。

在另一示例中，所述服务端基于餐饮订单中的上述信息从服务端数据库中获取的信息除了在一示例中的商家数据外，还包括基于所述餐饮订单中的用户账户信息从数据库中获取到用户数据，所述用户数据包括用户属性信息，例如，用户的姓名、年龄、位置等个人基本信息。但并不以此为限，所述餐饮详情信息还可包括用户安全信息，所述用户安全信息为服务端基于用户账户信息从数据库中获取的用于表征用户健康状态的二维码数据。

需要说明的是，所述数据库中还包括入驻包括该服务端的网络系统平台的配送员预先填写以及经所述配送员授权从第三方服务商获取到配送员数据、依据配送员数据生成用于表征配送员健康状态的二维码数据。鉴于此，在其他示例中，服务端获取到所述餐饮订单被配送员接单，服务端获取的餐饮详情信息还包括配送该餐饮订单的配送员安全信息，所述配送员安全信息为服务端从数据库中获取的用于表征配送员健康状态的二维码数据。

在步骤s11中，服务端依据所述餐饮详情信息审核所述餐饮订单所配用的餐盒是否满足回收标准。

其中，所述回收标准为预设在服务端的衡量餐盒是否能够回收的条件，所述回收标准可例如为依据餐盒属性所建立的用于判断所述餐饮订单所配用的餐盒属性信息是否满足回收的餐盒属性条件，所述回收标准还可例如为依据餐盒安全信息所建立的用于判断所述餐饮订单所配用的餐盒安全信息是否满足回收的餐盒安全条件。但并不以此为限，在其他举例中，所述回收标准也可同时包括餐盒属性条件以及餐盒安全条件，另外，本领域技术人员可以依据实际应用中所必须考虑的因素对回收标准进行更改。

在一实施例中，所述回收标准包括餐盒属性条件，则在步骤s11中还包括：依据所述餐饮详情信息确定所述餐饮订单所配用的餐盒的属性信息。从而步骤s11中服务端依据所述餐饮详情信息审核所述餐饮订单所配用的餐盒是否满足回收标准，可通过审核所配用的餐盒的属性信息来实现。

在一示例中，所述餐盒属性条件为餐盒材质为预设的材质，则需要确定的所配用的餐盒的属性信息为餐盒材质，如前所述，所述餐饮详情信息包括商家数据，并且商家数据可例如为商家为其提供的餐品所配用的餐盒材质、餐盒来源、以及备餐人员健康状况中的一种或多种数据。鉴于此，服务端可直接从商家数据中获知所述餐饮订单所配用的餐盒材质，并将获知的餐饮订单所配用的餐盒材质与预设的材质做对比，如果相同，则认为该餐饮订单所配用的餐盒满足回收标准，如果不同，则认为不满足回收标准。例如，回收标准为餐盒材质为塑料材质，如果服务端从商家数据中获知该餐饮订单的餐品所配用的餐盒材质也为塑料材质，则认为该餐饮订单所配用的餐盒满足回收标准。需要说明的是，预设餐盒材质为塑料材质仅是为了说明而举例，实际中，餐盒材质也可根据实际可回收条件将预设餐盒材质设置为塑料材质、纸质材质中的任意一种或多种，在预设餐盒材质为多种时，所配用的餐盒材质仅需满足多种中的一种即可。

在另一示例中，所述餐盒属性条件为餐盒的污渍程度低于预设程度，则需要确定的配用的餐盒的属性信息为污渍程度。具体地，服务端可以依据餐饮详情信息中的餐品信息确定所述餐饮订单所配用的餐盒的污渍程度，并判断确定的餐盒的污渍程度是否低于预设程度，如果低于，则认为该餐饮订单所配用的餐盒满足回收标准，如果高于或等于，则认为不满足回收标准。例如，服务端可以依据餐品信息中的餐品所属种类并结合餐品信息中的附加内容将餐盒的污渍程度分为无油腻、轻度油腻、以及重度油腻。举例来说，如果回收标准中餐盒的污渍程度预设为重度油腻，一餐饮订单的餐品信息为：餐品为麻辣烫、附加内容为重麻重辣，则确定污渍程度为重度油腻，进一步地认定该餐饮订单不满足回收标准；如果另一餐饮订单的餐品信息为：餐品为麻辣烫、附加内容为微辣，则确定污渍程度为轻度油腻，进一步地认定该餐饮订单满足回收标准；如果又一餐饮订单的餐品信息为：餐品为麻辣烫、附加内容为重麻重辣且使用一次性防护层，则确定污渍程度为无油腻，进一步地认定该餐饮订单满足回收标准。其中，所述一次性防护层为依据用户在订餐系统的选择而由商家设置在餐盒内部的防护层，例如锡纸、塑料薄膜等。

需要说明的是，所述餐盒属性条件的判断并不以此为限，在其他实施例中，所述餐盒属性条件同时包括餐盒材质和餐盒污渍程度，则餐盒属性条件的具体判断过程为依据前述一示例和另一示例中所具体描述过程进行，并且可以依据优先级别设置餐盒材质和餐盒的污渍程度的判断顺序。例如，如果认为餐盒材质是最重要的回收标准，则优先进行餐盒材质的判断，在餐盒材质为预设材质时才进行餐盒污渍程度的判断，如果餐盒材质并不为预设材质，则不必要再进行餐盒污渍程度的判断，直接认定为餐盒不满足回收标准。以上说明仅为举例，所述餐盒材质和餐盒的污渍程度的优先级别可依据实际需要进行更改，并且本领域技术人员也可依据实际需求增减餐盒属性条件的内容。

在另一实施例中，所述回收标准包括餐盒安全条件，则步骤s11中包括：服务端依据所述餐饮详情信息审核所配用的餐盒是否满足餐盒安全条件。

在一示例中，所述餐饮详情信息包括用户属性信息，服务端可通过所述用户属性信息判断当前餐饮订单所配用的餐盒是否满足餐盒安全条件。例如，服务端可根据用户的年龄信息确定餐盒是否满足餐盒安全条件，在用户属性信息中用户的年龄例如超过四十岁，则认为餐盒不满足餐盒安全条件的回收标准；再如，服务端根据用户的位置信息确定餐盒是否满足餐盒安全条件，在用户属性信息中用户的地位位置例如为医院，则认为餐盒上会有携带病毒或病菌的可能，认为餐盒不满足餐盒安全条件的回收标准。

在另一示例中，所述餐饮详情信息还包括用户安全信息，服务端还通过所述用户安全信息判断当前餐饮订单所配用的餐盒是否满足餐盒安全条件。如前所述，所述用户安全信息为表征用户健康状态的二维码数据，如果服务端根据二维码数据确定用户不存在健康风险(例如身体健康且未接触过传染病患者或未进入过高危场所)，则确定当前餐饮订单所配用的餐盒满足餐盒安全条件的回收标准，如果服务端根据二维码数据确定用户存在健康风险(例如身体处于生病期或接触过传染病患者或未进入过高危场所)，则确定当前餐饮订单所配用的餐盒不满足餐盒安全条件的回收标准。

在其他示例中，所述餐饮详情信息还包括配送员安全信息，服务端还会通过配送员安全信息判断当前餐饮订单所配用的餐盒是否满足餐盒安全条件。如前所述，所述配送员安全信息为表征配送员健康状态的二维码数据，如果服务端根据二维码数据确定配送员不存在健康风险(例如身体健康且未接触过传染病患者或历史配送轨迹未涉及高危场所)，则确定当前餐饮订单所配用的餐盒满足餐盒安全条件的回收标准，如果服务端根据二维码数据确定配送员存在健康风险(例如身体处于生病期或接触过传染病患者或历史配送轨迹涉及高危场所)，则确定当前餐饮订单所配用的餐盒不满足餐盒安全条件的回收标准。

以上示例仅为对餐盒安全条件判断的举例，但并不以此为限，例如，服务端还可根据餐饮详情信息中的商家数据中的餐盒来源以及备餐人员健康状况来判断餐盒安全条件是否满足回收标准。需要说明的是，上述对餐盒安全条件的判断可以根据实际需求同时存在并可依据优先级别设置判断顺序，也可根据需求选择其中任意一个或多个来判断，无论哪种方式，只要其中有一个对餐盒安全条件的判断不满足回收标准，则认为该餐饮订单所配用的餐盒不满足回收标准。

实际应用中，回收标准所设置的条件并不以上述为限，在其他实施例中，所述回收标准同时包括餐盒属性条件和餐盒安全条件，则步骤s11的具体判断过程为依据前述一实施例和另一实施例中所具体描述过程进行，并且可以依据优先级别设置餐盒属性条件和餐盒安全条件的判断顺序。例如，如果认为餐盒属性条件是最重要的回收标准，则优先进行餐盒属性条件的判断，在餐盒属性条件判断为通过时才进行餐盒安全条件的判断，如果餐盒属性条件判断为未通过，则不必要再进行餐盒安全条件的判断，直接认定为餐盒不满足回收标准。以上说明仅为举例，餐盒属性条件和餐盒安全条件的优先级别可依据实际需要进行更改。

在步骤s12中，服务端确定所述餐盒满足回收标准时，将相关于餐盒可回收的信息展示在所述订餐系统的展示界面中以供用户选择餐盒可回收的服务。

依据步骤s11中服务端对所述餐饮订单所配用的餐盒的审核满足回收标准时，服务端将相关于餐盒可回收的信息反馈给用于执行餐盒回收方法的订餐系统，以使得订餐系统将该信息展示在其展示界面中，从而可以供用户点击选择餐盒可回收的服务。关于相关于餐盒可回收的信息如何展示在订餐系统的展示界面请参阅针对图5及其描述所示，在此不再赘述。

如图5所示，相关于餐盒可回收的信息可以以回收餐盒提醒项的方式展示于订餐系统的展示界面中后，用户可以通过触发操作所述回收餐盒提醒项来提交回收餐盒请求，回收餐盒请求中包括回收配置信息，所述回收配置信息包括取件时间、取件地点、以及用户联系方式中的多种信息。具体回收配置信息的配置方式以及如何进行提交回收餐盒请求的过程请参阅针对图7及其描述所示，在此不再赘述。

鉴于此，所述餐盒回收处理方法还包括步骤s13(未予以图示)，在步骤s13中，服务端基于接收的一回收餐盒请求生成一餐盒回收订单展示在配送系统的展示界面中以供配送员接收所述餐盒回收订单。其中，所述回收餐盒请求是通过订餐系统基于前述回收配置信息而提交的。

在一实施例中，服务端接收到所述回收餐盒请求后，基于所述回收餐盒请求生成餐盒回收订单，该餐盒回收订单中包括回收配置信息，即餐盒回收订单中包括取件时间、取件地点、以及用户联系方式中的至少两种信息。服务端进一步地将所述餐盒回收订单发送给所述配送系统，配送系统在接收到所述餐盒回收订单后将其展示在系统的展示界面中，从而配送员可以根据餐盒回收订单中的回收配置信息结合自己的配送路径以及工作时间自主选择对餐盒回收订单的接单，在有配送员提交了接受所述餐盒回收订单后，会产生接收响应发送给服务端。其中，所述配送系统是藉由装载于一配送员客户端中的应用程序运行的。

鉴于此，所述餐盒回收处理方法还包括步骤s14(未予以图示)，在步骤s14中，服务端基于接收的对应所述餐盒回收订单的接收响应生成餐盒回收反馈信息以展示在订餐系统的展示界面中。

在一实施例中，所述服务端在接收到配送系统对餐盒回收订单的接收响应后，从其数据库中获取该餐盒回收订单对应的配送员数据，并依据配送员数据生成餐盒回收反馈信息。在一示例中，餐盒回收反馈信息包括配送员的联系方式、以及为该餐盒回收订单分配的取件码。在另外示例中，餐盒回收反馈信息还可包括配送员的姓名等有关于该餐盒回收订单的配送员数据，在此不再一一列举。

在另一实施例中，所述服务端从其数据库中除了获取对应的配送员数据外，还获取依据配送员数据生成用于表征配送员健康状态的二维码数据，服务端依据配送员数据以及所述二维码数据生成餐盒回收反馈信息。在一示例中，餐盒回收反馈信息包括配送员的联系方式、安全信息、以及为该餐盒回收订单分配的取件码，其中，所述安全信息包括表征配送员健康状态的二维码数据、依据所述二维码数据生成的二维码中的任意一种或两种。在另外示例中，餐盒回收反馈信息还可包括配送员的姓名等有关于该餐盒回收订单的配送员数据，在此不再一一列举。

服务端生成上述餐盒回收反馈信息并将所述餐盒回收反馈信息发送给所述订餐系统，订餐系统将其展示在订餐系统的展示界面中，订餐系统具体的展示方式请参阅后叙针餐盒回收方法的描述，在此不再赘述。

实际应用中，配送员依据餐盒订单中的信息在取件时间到达取件地点回收餐盒，而用户以及餐盒回收反馈信息在取件地点将餐盒交给配送员并为配送员提供取件码作为验证以避免出现误取或接单错误等异常状况，配送员拿到餐盒后将餐盒送回至回收点，由回收点对餐盒统一处理。

为了推行餐盒回收机制，鼓励用户进行餐盒回收，所述餐盒回收处理方法还包括步骤s15(未予以图示)，在步骤s15中，服务端基于接收的对应所述餐盒回收订单的完成响应分配虚拟资源给所述订餐系统，所述虚拟资源以可视化方式展示在订餐系统的展示界面中以供用户获取使用。

所述配送员将从用户处获取的餐盒送到回收点，则认为该回收订单完成。在一示例中，所述餐盒回收订单的完成响应为配送系统检测到配送员触发操作订单完成项时产生的完成响应。但并不以此为限，在另一示例中，所述餐盒回收订单的完成响应为回收系统检测到触发操作订单完成项时产生的完成响应。其中，所述回收系统是藉由装载于一回收点客户端中的应用程序运行的。

进一步地，步骤s15中服务端给订餐系统分配的虚拟资源可例如为预设的固定数额，或者在预设固定范围内的随机数额。其中，所述虚拟资源包括红包、优惠券、代金券、积分、或用户等级等中的任意一种，服务端为订餐系统分配的虚拟资源可为固定数额的红包、优惠券、代金券、积分、或用户等级中的任意一种，或者服务端为订餐系统分配的虚拟资源可为在预设固定范围内随机数额的红包、优惠券、代金券、积分、或用户等级中的任意一种。从而订餐系统在接收到所述虚拟资源时，将所述虚拟资源以红包、优惠券、代金券、积分、或用户等级中任意一种可视化方式展示在其展示界面中，以供用户获取使用。

需要说明的是，上述步骤s13至s15中由于回收订单请求是依据用户是否想要回收餐盒的意图而选择性触发的，故而步骤s13至步骤s15既可能被触发执行，也可能不被触发执行。

由上述步骤s10至步骤s15中描述可知，订餐系统会藉由用户客户端与服务端交互以完成餐盒管理和回收，以下结合图2至图7来说明用户客户端如何进行餐盒回收。请参阅图2，显示为本申请餐盒回收方法在一实施例中的流程图，如图所示，所述餐盒回收方法包括步骤s20、以及步骤s21。

在步骤s20中，用户客户端在订单详情界面中提交一餐饮订单。

在一实施例中，所述用户客户端在一订餐系统的应用程序被打开时，可以基于该订餐系统中各商家的展示界面中用户的触发操作添加用户所选择的餐品，并在检测到用户触发操作结算项时加载订单详情界面。

在一示例中，所述订单详情界面中展示有餐饮订单，所述餐饮订单包括商家账户信息、餐品信息、以及用户账户信息。其中，所述商家账户信息包括用户在订餐系统中触发操作所选商家的商家名称、或地理位置等信息。所述餐品信息包括用户触发操作在所选商家中所选择的餐品以及附加内容项，用户可以通过触发附件内容项以在餐饮订单中添加附加内容，例如餐品口味、是否需要一次性餐具等。所述用户账户信息包括该餐饮订单对应的用户联系方式及地理位置等，用户可以通过触发操作对用户账户信息进行修改。需要说明的是，以上餐饮订单中包括的各信息的具体内容仅为举例示意，实际应用中，本领域技术人员可根据餐饮订单中所实际能够提供的信息进行选择性增减。

在另一示例中，所述订单详情界面中还展示有提交订餐请求项，用户可以通过触发操作该提交订餐请求项提交餐饮订单。请参阅图3，显示为本申请在一实施例中订单详情界面的示意图，如图所示，图中a区域用于展示餐饮订单，图中“提交订单”即作为提交订餐请求项的虚拟按键，在该虚拟按键被触发时，用户客户端提交餐饮订单给服务端，服务端依据所述餐饮订单执行前述步骤s10至步骤s12。

在又一示例中，所述订单详情界面中还展示有餐盒审核请求项，所述餐饮订单是藉由触发操作所述提交订餐请求项提交的餐饮订单，所述提交的餐饮订单包括用户触发操作所述餐盒审核请求项提交的餐盒审核请求。请参阅图4，显示为本申请在又一实施例中订单详情界面的示意图，如图所示，图中a区域用于展示餐饮订单，a区域中“为节约资源保护环境，本人同意申请餐盒回收”作为餐盒审核请求项的虚拟按键，在该虚拟按键被触发时，界面上“为节约资源保护环境，本人同意申请餐盒回收”显示为被选中(例如可以以颜色由灰色变为其它颜色、在餐盒审核请求项相应位置显示勾选等方式表示被选中)，在此基础上用户再触发操作虚拟按键“提交订单”提交餐饮订单，从而使得提交给服务端的餐饮订单包括用户提交的餐盒审核请求，服务端依据所述餐饮订单执行前述步骤s10至步骤s12。

在步骤s21中，用户客户端接收到所述餐饮订单所配用的餐盒满足回收标准时加载一回收餐盒提醒项，以供用户选择餐盒可回收的服务。

在服务端执行前述步骤s10至步骤s12审核步骤s20中提交的餐饮订单所配用的餐盒满足回收标准时，会将相关于餐盒可回收的信息发送给用户客户端，用户客户端依据相关于餐盒可回收的信息加载回收餐盒提醒项。其中，所述回收餐盒提醒项可加载于装载于用户客户端的订餐系统的任意展示界面中，例如，如图5所示，其显示为本申请在一实施例中包含回收餐盒提醒项的展示界面的示意图，如图所示，回收餐盒提醒项在订餐系统的展示界面的上方以文字显示为“餐饮订单中的餐盒可回收，请点击回收”的方式提醒用户，但并不以此为限，也可依据设置以图像、文字、或文字结合图像的方式选择性的加载于订单详情界面、或餐饮订单完成界面等展示界面中。

于实际应用中，用户可以通过触发操作所述回收餐盒提醒项以选择餐盒可回收的服务。鉴于此，请参阅图6，显示为本申请在另一实施例中的餐盒回收方法的流程图，如图所示，所述餐盒回收方法还包括步骤s22，在步骤s22中，用户客户端检测到所述回收餐盒提醒项被触发时提交回收餐盒请求。其中，所述回收餐盒请求用于生成餐盒回收订单展示在配送系统中，所述配送系统藉由装载于一配送员客户端中应用程序运行。

在一实施例中，用户客户端检测到所述回收餐盒提醒项被触发时加载一回收详情页。在一些示例中，所述回收详情页中展示有回收配置列目以供用户通过触发操作在对应的列目下配置回收配置信息，所述回收配置信息包括取件时间、取件地点、以及用户联系方式中的至少两种信息。进一步地，所述回收详情页中还展示有提交回收餐盒请求项，用户在完成回收配置信息的配置后，通过触发操作所述提交回收餐盒请求项提交回收餐盒请求，其中，回收餐盒请求中包括所述回收配置信息。

请参阅图7，显示为本申请在一实施例中的回收详情页的示意图，如图所示，所述回收详情页中展示有回收配置列目，回收配置列目包括取件时间、取件地点、联系方式。通过用户对取件时间的下拉按键的触发操作可实现对取件时间进行选择。通过用户对取件地点的触发操作可实现对取件地点的获取，例如选择通过获取预先存储的地址作为取件地点、或通过手动输入添加新地址作为取件地点、再或者通过获取定位信息作为取件地点。通过用户对联系方式的触发操作可实现对联系方式的配置，例如选择通过获取预先存储的号码作为联系方式、或通过手动输入添加新号码作为联系方式、再或者通过获取通讯录中号码作为联系方式。在回收配置列目下完成回收配置信息的配置后，用户通过触发操作作为提交回收餐盒请求项的虚拟按键“确认”提交回收餐盒请求给服务端。

用户客户端将所述回收餐盒请求提交给服务端，服务端依据前述步骤s13和步骤s14生成餐盒回收反馈信息，鉴于此，所述餐盒回收方法还包括步骤s23(未予以图示)，在步骤s23中，用户客户端接收餐盒回收反馈信息并展示在展示界面中。

如前所述，所述餐盒回收反馈信息包括配送员的联系方式、安全信息、以及取件码中的多种信息，所述安全信息包括表征配送员健康状态的二维码数据或二维码。故而，用户客户端可基于接收到的餐盒回收反馈信息选择性的将餐盒回收反馈信息中的多种信息部分展示或全部展示在展示界面中。例如，用户客户端在用户提交所述回收餐盒请求的触发操作后加载一反馈信息展示界面，并在所述反馈信息展示界面中展示餐盒回收反馈信息，在一示例中，所述反馈信息展示界面中仅展示有配送员的联系方式、以及取件码。在另一示例中，所述反馈信息展示界面中展示有配送员的联系方式、取件码、以及表征配送员健康状态的二维码，举例来说，在表征配送员健康状态为健康时，所述二维码展示为绿色放心图标，在表征配送员健康状态为一般时，所述二维码展示为黄色提醒图标，表征配送员健康状态为不健康时，所述二维码展示为红色警告图标。需要说明的是，在其它一些示例中，反馈信息展示界面中还可展示有拒绝此次回收餐盒请求项或更换配送员请求项，用于在用户依据安全信息认定此次回收餐盒存在风险时，及时为用户提供其它解决方案的路径以避免此次风险。

实际应用中，配送员依据餐盒订单中的信息在取件时间到达取件地点回收餐盒，而用户以及餐盒回收反馈信息在取件地点将餐盒交给配送员并为配送员提供取件码作为验证以避免出现误取或接单错误等异常状况，配送员拿到餐盒后将餐盒送回至回收点，由回收点对餐盒统一处理。

如前所述，为了推行餐盒回收机制，鼓励用户进行餐盒回收，餐盒回收处理系统藉由装载的服务端执行步骤s15以基于餐盒回收订单的完成响应分配虚拟资源给所述订餐系统，所述订餐系统藉由装载于所述用户客户端的应用程序运行。鉴于此，所述餐盒回收方法还包括步骤s24(未予以图示)，在步骤s24中，用户客户端接收所述虚拟资源并展示在展示界面中。

如前所示，服务端给装载于用户客户端的订餐系统分配的虚拟资源可例如为预设的固定数额，或者在预设固定范围内的随机数额。其中，所述虚拟资源包括红包、优惠券、代金券、积分、或用户等级等中的任意一种，服务端为用户客户端分配的虚拟资源可为固定数额的红包、优惠券、代金券、积分、或用户等级中的任意一种，或者服务端为用户客户端分配的虚拟资源可为在预设固定范围内随机数额的红包、优惠券、代金券、积分、或用户等级中的任意一种。从而用户客户端在接收到所述虚拟资源时，将依据接收到的虚拟资源的类型将所述虚拟资源加载为红包、优惠券、代金券、积分、或用户等级中任意一种形式展示在订餐系统的展示界面中，例如，用户可通过触发操作展示在其展示界面中的虚拟资源而使其从当前界面消失、或者虚拟资源在展示界面中展示预设时间(例如3s)而从当前界面消失，后期用户可以通过触发操作订餐系统的用户账户详情页中的红包卡券项查看其获取的虚拟资源。

需要说明的是，上述步骤s22至s24是依据用户是否想要回收餐盒的意图而选择性触发的，故而步骤s22至步骤s24既可能被触发执行，也可能不被触发执行。

综上所述，本申请公开的餐盒回收处理方法以及餐盒回收方法，通过服务端审核用户客户端提交的餐饮订单所配用的餐盒是否满足回收标准，从而在餐饮订单所配用的餐盒满足回收标准时，将回收餐盒提醒项展示在用户客户端的展示界面中，一则将对餐盒的审核过程以数字化的方式在服务端实现，大大节约了回收成本以及降低了人接触餐盒所存在的安全风险，另外还在用户客户端为用户提供餐盒回收的功能，有利于餐盒回收流程的简化以及实现餐盒回收过程中流程的把控。

本申请还提供一种餐盒回收处理系统以实现对餐盒回收的审核和流程控制，在实施例中，所述餐盒回收处理系统例如为一服务端，所述服务端可以根据功能、负载等多种因素布置在一个或多个实体服务器上。其中，当分布在多个实体服务器时，所述服务端可以由基于云架构的服务器组成。例如，基于云架构的服务器包括公共云服务端与私有云服务端，其中，所述公共或私有云服务端包括saas、paas及iaas等。所述私有云服务端例如美团云计算服务平台、阿里云计算服务平台、亚马逊云计算服务平台、百度云计算平台、腾讯云计算平台等。所述服务端还可以由分布的或集中的服务器集群构成。例如，所述服务器集群由至少一台实体服务器构成。每个实体服务器中配置多个虚拟服务器，每个虚拟服务器运行商家信息管理服务端中的至少一功能模块，各虚拟服务器之间通过网络通信。

请参阅图8，显示为本申请餐盒回收处理系统在一实施例中的模块框图，如图所示，所述餐盒回收处理系统10包括获取模块11、审核模块12、以及显示模块13。

所述获取模块11用于基于一餐饮订单获取包含所述餐饮订单的餐饮详情信息。

其中，所述餐饮订单是通过一订餐系统提交的，所述订餐系统藉由装载于一用户客户端中的应用程序运行，其具体的结构以及请参阅后叙针对图9及其描述的说明，在此不做赘述。在一示例中，所述餐饮订单是藉由触发操作订餐系统中的一提交订餐请求项提交的餐饮订单，例如，在订餐系统中加载有订单详情界面，所述订单详情界面中展示有提交订餐请求项，用户通过触发所述提交订单请求项提交餐饮订单，其具体过程请参阅针对图3的说明。如此，餐盒回收处理系统10需要对藉由订餐系统提交的所有的餐饮订单进行信息处理与审核。在另一示例中，所述餐饮订单是藉由触发操作订餐系统中的一提交订餐请求项提交的餐饮订单，并且提交的餐饮订单包括用户提交的餐盒审核请求，例如，订餐系统中加载有订单详情界面，所述订单详情界面除了展示有在一示例中所述的提交订餐请求项，还展示有餐盒审核请求项，用户可根据自己的意图选择性的触发操作所述餐盒审核请求项，在此基础上再触发操作所述提交订餐请求项提交餐饮订单，其具体过程请参阅针对图4的说明。如此，餐盒回收处理系统10仅需对藉由订餐系统提交的包含有餐盒审核请求的餐饮订单进行信息处理与审核，从而在用户并没有餐盒回收意图的情况下，省去了对该餐饮订单的信息处理和审核，节约计算资源并使得流程简约化。需要说明的是，前述以及后叙提及的触发或触发操作包括但不限于点击(例如利用鼠标等输入设备点击、或利用手指触击等)、长按、按压、或者重复触控等，应理解的，用户对一对象执行触发操作可以称之为用户触发该对象，例如，用户对预订界面执行触发操作，也可以称之为用户触发该预订界面。又如，用户触发一热键区域即表示用户对该热键区域执行了触发操作，等等。下文将不再对类似的情况进行赘述。

应理解的，所述的请求项是指可以通过例如触发或点击等操作进行指令或信息输入的组件，例如图3中所示的“提交订单”，或者图4中所示的“为节约资源保护环境，本人同意申请餐盒回收”的区域，又或者图7中所示的“确认”组件等功能。

在一实施例中，所述餐饮详情信息包括所述餐饮订单，所述餐饮订单中包括商家账户信息、餐品信息、以及用户账户信息。其中，所述商家账户信息包括该餐饮订单对应的商家名称以及地理位置等。所述餐品信息包括该餐饮订单对应的餐品以及附加内容，所述餐品可例如为麻辣烫、干锅、米饭、汤羹等任一种或多种用户基于商家提供的餐品而加入到所述餐饮订单中的餐品，附加内容例如为麻辣口味、提供餐具等基于用户自主选择或填写而加入到所述餐饮订单中备注信息。所述用户账户信息包括该餐饮订单对应的用户联系方式及地理位置等。需要说明的是，以上餐饮订单中包括的各信息的具体内容仅为举例示意，实际应用中，本领域技术人员可根据餐饮订单中所实际能够提供的信息进行选择性增减。

在另一实施例中，所述餐饮详情信息还包括获取模块11基于餐饮订单中的上述信息从服务端数据库中获取的信息。其中，服务端数据库包括入驻包括该服务端的网络系统平台的商家和用户预先填写以及经所述商家和用户授权从第三方服务商获取到商家数据和用户数据、依据商家数据生成用于表征商家安全状态的二维码数据、以及依据用户数据生成用于表征用户健康状态的二维码数据。其中，所述二维码数据为利用0、1对至少商家数据或用户数据进行编码而得到的由0、1构成的码矩阵。所述二维码数据的编码方式举例但不限于：对商家数据或用户数据中的各数据进行一维编码处理并将各一维编码处理的数据堆叠成二维码数据，例如，采用code16k、code49、或pdf417等方式生成二维码数据；或者，对商家数据或用户数据中的各数据进行交织编码处理，得到二维码数据，例如，采用codeone、maxicode、qrcode、或datamatrix等方式生成二维码数据。

在一示例中，所述获取模块11基于餐饮订单中的上述信息从服务端数据库中获取的信息为基于所述餐饮订单中的商家账户信息从数据库中获取到商家数据，例如，商家数据为商家为其提供的餐品所配用的餐盒材质、餐盒来源、以及备餐人员健康状况中的一种或多种数据。

在另一示例中，所述获取模块11基于餐饮订单中的上述信息从服务端数据库中获取的信息除了在一示例中的商家数据外，还包括基于所述餐饮订单中的用户账户信息从数据库中获取到用户数据，所述用户数据包括用户属性信息，例如，用户的姓名、年龄、位置等个人基本信息。但并不以此为限，所述餐饮详情信息还可包括用户安全信息，所述用户安全信息为服务端基于用户账户信息从数据库中获取的用于表征用户健康状态的二维码数据。

需要说明的是，所述数据库中还包括入驻包括该服务端的网络系统平台的配送员预先填写以及经所述配送员授权从第三方服务商获取到配送员数据、依据配送员数据生成用于表征配送员健康状态的二维码数据。鉴于此，在其他示例中，获取模块11获取到所述餐饮订单被配送员接单，获取模块11获取的餐饮详情信息还包括配送该餐饮订单的配送员安全信息，所述配送员安全信息为获取模块11从数据库中获取的用于表征配送员健康状态的二维码数据。

所述审核模块12用于依据所述餐饮详情信息审核所述餐饮订单所配用的餐盒是否满足回收标准。

其中，所述回收标准为预设在餐盒回收处理系统10的衡量餐盒是否能够回收的条件，所述回收标准可例如为依据餐盒属性所建立的用于判断所述餐饮订单所配用的餐盒属性信息是否满足回收的餐盒属性条件，所述回收标准还可例如为依据餐盒安全信息所建立的用于判断所述餐饮订单所配用的餐盒安全信息是否满足回收的餐盒安全条件。但并不以此为限，在其他举例中，所述回收标准也可同时包括餐盒属性条件以及餐盒安全条件，另外，本领域技术人员可以依据实际应用中所必须考虑的因素对回收标准进行更改。

在一实施例中，所述回收标准包括餐盒属性条件，则审核模块12还用于依据所述餐饮详情信息确定所述餐饮订单所配用的餐盒的属性信息。从而审核模块12在依据所述餐饮详情信息审核所述餐饮订单所配用的餐盒是否满足回收标准，可通过审核所配用的餐盒的属性信息来实现。

在一示例中，所述餐盒属性条件为餐盒材质为预设的材质，则需要确定的所配用的餐盒的属性信息为餐盒材质，如前所述，所述餐饮详情信息包括商家数据，并且商家数据可例如为商家为其提供的餐品所配用的餐盒材质、餐盒来源、以及备餐人员健康状况中的一种或多种数据。鉴于此，审核模块12可直接从商家数据中获知所述餐饮订单所配用的餐盒材质，并将获知的餐饮订单所配用的餐盒材质与预设的材质做对比，如果相同，则认为该餐饮订单所配用的餐盒满足回收标准，如果不同，则认为不满足回收标准。例如，回收标准为餐盒材质为塑料材质，如果审核模块12从商家数据中获知该餐饮订单的餐品所配用的餐盒材质也为塑料材质，则认为该餐饮订单所配用的餐盒满足回收标准。需要说明的是，预设餐盒材质为塑料材质仅是为了说明而举例，实际中，餐盒材质也可根据实际可回收条件将预设餐盒材质设置为塑料材质、纸质材质中的任意一种或多种，在预设餐盒材质为多种时，所配用的餐盒材质仅需满足多种中的一种即可。

在另一示例中，所述餐盒属性条件为餐盒的污渍程度低于预设程度，则需要确定的配用的餐盒的属性信息为污渍程度。具体地，审核模块12可以依据餐饮详情信息中的餐品信息确定所述餐饮订单所配用的餐盒的污渍程度，并判断确定的餐盒的污渍程度是否低于预设程度，如果低于，则认为该餐饮订单所配用的餐盒满足回收标准，如果高于或等于，则认为不满足回收标准。例如，审核模块12可以依据餐品信息中的餐品所属种类并结合餐品信息中的附加内容将餐盒的污渍程度分为无油腻、轻度油腻、以及重度油腻。举例来说，如果回收标准中餐盒的污渍程度预设为重度油腻，一餐饮订单的餐品信息为：餐品为麻辣烫、附加内容为重麻重辣，则确定污渍程度为重度油腻，进一步地认定该餐饮订单不满足回收标准；如果另一餐饮订单的餐品信息为：餐品为麻辣烫、附加内容为微辣，则确定污渍程度为轻度油腻，进一步地认定该餐饮订单满足回收标准；如果又一餐饮订单的餐品信息为：餐品为麻辣烫、附加内容为重麻重辣且使用一次性防护层，则确定污渍程度为无油腻，进一步地认定该餐饮订单满足回收标准。其中，所述一次性防护层为依据用户在订餐系统的选择而由商家设置在餐盒内部的防护层，例如锡纸、塑料薄膜等。

需要说明的是，所述餐盒属性条件的判断并不以此为限，在其他实施例中，所述餐盒属性条件同时包括餐盒材质和餐盒污渍程度，则餐盒属性条件的具体判断过程为依据前述一示例和另一示例中所具体描述过程进行，并且可以依据优先级别设置餐盒材质和餐盒的污渍程度的判断顺序。例如，如果认为餐盒材质是最重要的回收标准，则优先进行餐盒材质的判断，在餐盒材质为预设材质时才进行餐盒污渍程度的判断，如果餐盒材质并不为预设材质，则不必要再进行餐盒污渍程度的判断，直接认定为餐盒不满足回收标准。以上说明仅为举例，所述餐盒材质和餐盒的污渍程度的优先级别可依据实际需要进行更改，并且本领域技术人员也可依据实际需求增减餐盒属性条件的内容。

在另一实施例中，所述回收标准包括餐盒安全条件，则审核模块12还用于依据所述餐饮详情信息审核所配用的餐盒是否满足餐盒安全条件。

在一示例中，所述餐饮详情信息包括用户属性信息，审核模块12可通过所述用户属性信息判断当前餐饮订单所配用的餐盒是否满足餐盒安全条件。例如，审核模块12可根据用户的年龄信息确定餐盒是否满足餐盒安全条件，在用户属性信息中用户的年龄例如超过四十岁，则认为餐盒不满足餐盒安全条件的回收标准；再如，审核模块12根据用户的位置信息确定餐盒是否满足餐盒安全条件，在用户属性信息中用户的地位位置例如为医院，则认为餐盒上会有携带病毒或病菌的可能，认为餐盒不满足餐盒安全条件的回收标准。

在另一示例中，所述餐饮详情信息还包括用户安全信息，审核模块12还通过所述用户安全信息判断当前餐饮订单所配用的餐盒是否满足餐盒安全条件。如前所述，所述用户安全信息为表征用户健康状态的二维码数据，如果审核模块12根据二维码数据确定用户不存在健康风险(例如身体健康且未接触过传染病患者或未进入过高危场所)，则确定当前餐饮订单所配用的餐盒满足餐盒安全条件的回收标准，如果审核模块12根据二维码数据确定用户存在健康风险(例如身体处于生病期或接触过传染病患者或未进入过高危场所)，则确定当前餐饮订单所配用的餐盒不满足餐盒安全条件的回收标准。

在其他示例中，所述餐饮详情信息还包括配送员安全信息，审核模块12还会通过配送员安全信息判断当前餐饮订单所配用的餐盒是否满足餐盒安全条件。如前所述，所述配送员安全信息为表征配送员健康状态的二维码数据，如果审核模块12根据二维码数据确定配送员不存在健康风险(例如身体健康且未接触过传染病患者或历史配送轨迹未涉及高危场所)，则确定当前餐饮订单所配用的餐盒满足餐盒安全条件的回收标准，如果审核模块12根据二维码数据确定配送员存在健康风险(例如身体处于生病期或接触过传染病患者或历史配送轨迹涉及高危场所)，则确定当前餐饮订单所配用的餐盒不满足餐盒安全条件的回收标准。

以上示例仅为对餐盒安全条件判断的举例，但并不以此为限，例如，审核模块12还可根据餐饮详情信息中的商家数据中的餐盒来源以及备餐人员健康状况来判断餐盒安全条件是否满足回收标准。需要说明的是，上述对餐盒安全条件的判断可以根据实际需求同时存在并可依据优先级别设置判断顺序，也可根据需求选择其中任意一个或多个来判断，无论哪种方式，只要其中有一个对餐盒安全条件的判断不满足回收标准，则认为该餐饮订单所配用的餐盒不满足回收标准。

实际应用中，回收标准所设置的条件并不以上述为限，在其他实施例中，所述回收标准同时包括餐盒属性条件和餐盒安全条件，则审核模块12的具体审核过程为依据前述一实施例和另一实施例中所具体描述过程进行，并且可以依据优先级别设置餐盒属性条件和餐盒安全条件的判断顺序。例如，如果认为餐盒属性条件是最重要的回收标准，则优先进行餐盒属性条件的判断，在餐盒属性条件判断为通过时才进行餐盒安全条件的判断，如果餐盒属性条件判断为未通过，则不必要再进行餐盒安全条件的判断，直接认定为餐盒不满足回收标准。以上说明仅为举例，餐盒属性条件和餐盒安全条件的优先级别可依据实际需要进行更改。

所述显示模块13用于在确定所述餐盒满足回收标准时，将相关于餐盒可回收的信息展示在所述订餐系统的展示界面中以供用户选择餐盒可回收的服务。

审核模块12对所述餐饮订单所配用的餐盒的审核满足回收标准时，显示模块13将相关于餐盒可回收的信息反馈给用于执行餐盒回收方法的订餐系统，以使得订餐系统将该信息展示在其展示界面中，从而可以供用户点击选择餐盒可回收的服务。关于相关于餐盒可回收的信息如何展示在订餐系统的展示界面请参阅针对图5及其描述所示，在此不再赘述。

如图5所示，相关于餐盒可回收的信息可以以回收餐盒提醒项的方式展示于订餐系统的展示界面中后，用户可以通过触发操作所述回收餐盒提醒项来提交回收餐盒请求，回收餐盒请求中包括回收配置信息，所述回收配置信息包括取件时间、取件地点、以及用户联系方式中的多种信息。具体回收配置信息的配置方式以及如何进行提交回收餐盒请求的过程请参阅针对图7及其描述所示，在此不再赘述。

鉴于此，所述显示模块13还会基于接收的一回收餐盒请求生成一餐盒回收订单展示在配送系统的展示界面中以供配送员接收所述餐盒回收订单。其中，所述回收餐盒请求是通过订餐系统基于前述回收配置信息而提交的。

在一实施例中，显示模块13接收到所述回收餐盒请求后，基于所述回收餐盒请求生成餐盒回收订单，该餐盒回收订单中包括回收配置信息，即餐盒回收订单中包括取件时间、取件地点、以及用户联系方式中的至少两种信息。显示模块13进一步地将所述餐盒回收订单发送给所述配送系统，配送系统在接收到所述餐盒回收订单后将其展示在系统的展示界面中，从而配送员可以根据餐盒回收订单中的回收配置信息结合自己的配送路径以及工作时间自主选择对餐盒回收订单的接单，在有配送员提交了接受所述餐盒回收订单后，会产生接收响应发送给服务端。其中，所述配送系统是藉由装载于一配送员客户端中的应用程序运行的。

鉴于此，所述显示模块13还基于接收的对应所述餐盒回收订单的接收响应生成餐盒回收反馈信息以展示在订餐系统的展示界面中。

在一实施例中，所述显示模块13在接收到配送系统对餐盒回收订单的接收响应后，藉由获取模块11从服务端数据库中获取该餐盒回收订单对应的配送员数据，并依据配送员数据生成餐盒回收反馈信息。在一示例中，餐盒回收反馈信息包括配送员的联系方式、以及为该餐盒回收订单分配的取件码。在另外示例中，餐盒回收反馈信息还可包括配送员的姓名等有关于该餐盒回收订单的配送员数据，在此不再一一列举。

在另一实施例中，所述显示模块13藉由获取模块11从服务端数据库中除了获取对应的配送员数据外，还获取依据配送员数据生成用于表征配送员健康状态的二维码数据，显示模块13依据配送员数据以及所述二维码数据生成餐盒回收反馈信息。在一示例中，餐盒回收反馈信息包括配送员的联系方式、安全信息、以及为该餐盒回收订单分配的取件码，其中，所述安全信息包括表征配送员健康状态的二维码数据、依据所述二维码数据生成的二维码中的任意一种或两种。在另外示例中，餐盒回收反馈信息还可包括配送员的姓名等有关于该餐盒回收订单的配送员数据，在此不再一一列举。

显示模块13生成上述餐盒回收反馈信息并将所述餐盒回收反馈信息发送给所述订餐系统，订餐系统将其展示在订餐系统的展示界面中，订餐系统具体的展示方式请参阅后叙针餐盒回收系统的描述，在此不再赘述。

实际应用中，配送员依据餐盒订单中的信息在取件时间到达取件地点回收餐盒，而用户以及餐盒回收反馈信息在取件地点将餐盒交给配送员并为配送员提供取件码作为验证以避免出现误取或接单错误等异常状况，配送员拿到餐盒后将餐盒送回至回收点，由回收点对餐盒统一处理。

为了推行餐盒回收机制，鼓励用户进行餐盒回收，所述显示模块13还基于接收的对应所述餐盒回收订单的完成响应分配虚拟资源给所述订餐系统，所述虚拟资源以可视化方式展示在订餐系统的展示界面中以供用户获取使用。

所述配送员将从用户处获取的餐盒送到回收点，则认为该回收订单完成。在一示例中，所述餐盒回收订单的完成响应为配送系统检测到配送员触发操作订单完成项时产生的完成响应。但并不以此为限，在另一示例中，所述餐盒回收订单的完成响应为回收系统检测到触发操作订单完成项时产生的完成响应。其中，所述回收系统是藉由装载于一回收点客户端中的应用程序运行的。

进一步地，显示模块13给订餐系统分配的虚拟资源可例如为预设的固定数额，或者在预设固定范围内的随机数额。其中，所述虚拟资源包括红包、优惠券、代金券、积分、或用户等级等中的任意一种，显示模块13为订餐系统分配的虚拟资源可为固定数额的红包、优惠券、代金券、积分、或用户等级中的任意一种，或者显示模块13为订餐系统分配的虚拟资源可为在预设固定范围内随机数额的红包、优惠券、代金券、积分、或用户等级中的任意一种。从而订餐系统在接收到所述虚拟资源时，将所述虚拟资源以红包、优惠券、代金券、积分、或用户等级中任意一种可视化方式展示在其展示界面中，以供用户获取使用。

本申请还提供一种订餐系统用于为用户提供餐盒回收功能，在实施例中，所述订餐系统例如为一用户客户端，所述用户客户端例如为装载有app应用程序或具备网页/网站访问性能的电子设备，所述电子设备包括存储器、存储器控制器、一个或多个处理单元(cpu)、外设接口、rf电路、音频电路、扬声器、麦克风、输入/输出(i/o)子系统、显示屏、其他输出或控制设备，以及外部端口等组件，这些组件通过一条或多条通信总线或信号线进行通信。所述电子设备包括但不限于如台式电脑、笔记本电脑、平板电脑、智能手机、智能电视、等。所述用户终端还可以是由带有多个虚拟机的主机和对应每个虚拟机的人机交互装置(如触控显示屏、键盘和鼠标)所构成的电子设备。

在实施例中，所述用户客户端与网络系统中的服务端通信，所述系统例如为商业实体的在线订餐系统或平台，所述网络可以是因特网、一个或多个内部网、局域网、广域网、存储局域网等，或其适当组合，本申请实施例对包括用户客户端在内的各种客户端、服务端的种类，或者发布者终端与服务器之间、响应者终端与服务器之间通信网络的类型或协议等在本申请中均不做限定。

在本申请的某些实施例中，所述服务端可以根据功能、负载等多种因素布置在一个或多个实体服务器上。其中，当分布在多个实体服务器时，所述服务端可以由基于云架构的服务器组成。例如，基于云架构的服务器包括公共云服务端与私有云服务端，其中，所述公共或私有云服务端包括saas、paas及iaas等。所述私有云服务端例如美团云计算服务平台、阿里云计算服务平台、亚马逊云计算服务平台、百度云计算平台、腾讯云计算平台等。所述服务端还可以由分布的或集中的服务器集群构成。例如，所述服务器集群由至少一台实体服务器构成。每个实体服务器中配置多个虚拟服务器，每个虚拟服务器运行商家信息管理服务端中的至少一功能模块，各虚拟服务器之间通过网络通信。

请参阅图9，显示为本申请订餐系统在一实施例中的模块框图，如图所示，所述订餐系统20包括检测模块21、提交模块22、以及加载模块23。

所述检测模块21用于检测在当前显示界面中的触发操作。在实施例中，所述检测模块21例如为触控屏检测器或事件监测器，触控屏检测器检测管理者在当前显示页面中的触发事件时执行相应的操作。比如用户触发操作以打开回收详情页或者用户触发操作以打开订单详情界面，再或者用户触发操作以提交回收餐盒请求，又或者用户通过触发操作进行信息配置等。所述事件监测器从外围设备接口接收事件信息。事件信息包括关于子事件(例如，作为多触摸手势的一部分的触敏显示器系统上的用户触摸)的信息。

所述提交模块22用于在订单详情界面中提交一餐饮订单。

在一实施例中，用户客户端在订餐系统20的应用程序被打开时，可以基于该订餐系统20中各商家的展示界面中用户的触发操作添加用户所选择的餐品，并在检测模块21检测到用户触发操作结算项时加载订单详情界面。

在一示例中，所述订单详情界面中展示有餐饮订单，所述餐饮订单包括商家账户信息、餐品信息、以及用户账户信息。其中，所述商家账户信息包括用户在订餐系统20中触发操作所选商家的商家名称、或地理位置等信息。所述餐品信息包括用户触发操作在所选商家中所选择的餐品以及附加内容项，用户可以通过触发附件内容项以在餐饮订单中添加附加内容，例如餐品口味、是否需要一次性餐具等。所述用户账户信息包括该餐饮订单对应的用户联系方式及地理位置等，用户可以通过触发操作对用户账户信息进行修改。需要说明的是，以上餐饮订单中包括的各信息的具体内容仅为举例示意，实际应用中，本领域技术人员可根据餐饮订单中所实际能够提供的信息进行选择性增减。

在另一示例中，所述订单详情界面中还展示有提交订餐请求项，用户可以通过触发操作该提交订餐请求项提交餐饮订单。如图3所示的订单详情界面的示意图，图中a区域用于展示餐饮订单，图中“提交订单”即作为提交订餐请求项的虚拟按键，检测模块21在该虚拟按键被触发时，提交模块22提交餐饮订单给装载有餐盒回收处理系统的服务端，服务端依据前述餐盒回收处理方法对餐盒进行审核和回收处理。

在又一示例中，所述订单详情界面中还展示有餐盒审核请求项，所述餐饮订单是藉由触发操作所述提交订餐请求项提交的餐饮订单，所述提交的餐饮订单包括用户触发操作所述餐盒审核请求项提交的餐盒审核请求。如图4所示的订单详情界面的示意图，图中a区域用于展示餐饮订单，a区域中“为节约资源保护环境，本人同意申请餐盒回收”作为餐盒审核请求项的虚拟按键，在该虚拟按键被触发时，界面上“为节约资源保护环境，本人同意申请餐盒回收”显示为被选中(例如可以以颜色由灰色变为其它颜色、在餐盒审核请求项相应位置显示勾选等方式表示被选中)，在此基础上用户再触发操作虚拟按键“提交订单”提交餐饮订单，从而使得提交给服务端的餐饮订单包括用户提交的餐盒审核请求，服务端依据前述餐盒回收处理方法对餐盒进行审核和回收处理。

所述加载模块23用于接收到所述餐饮订单所配用的餐盒满足回收标准时加载一回收餐盒提醒项，以供用户选择餐盒可回收的服务。

在服务端执行餐盒回收处理方法时审核提交模块22所提交的餐饮订单所配用的餐盒满足回收标准时，会将相关于餐盒可回收的信息发送给用户客户端，加载模块23依据相关于餐盒可回收的信息加载回收餐盒提醒项。其中，所述回收餐盒提醒项可加载于的订餐系统20的任意展示界面中，例如，如图5所示的包含回收餐盒提醒项的展示界面，回收餐盒提醒项在订餐系统20的展示界面的上方以文字显示为“餐饮订单中的餐盒可回收，请点击回收”的方式提醒用户，但并不以此为限，也可依据设置以图像、文字、或文字结合图像的方式选择性的加载于订单详情界面、或餐饮订单完成界面等展示界面中。

于实际应用中，用户可以通过触发操作所述回收餐盒提醒项以选择餐盒可回收的服务。鉴于此，所述提交模块22还用于在所述检测模块检测到所述回收餐盒提醒项被触发时提交回收餐盒请求。其中，所述回收餐盒请求用于生成餐盒回收订单展示在配送系统中，所述配送系统藉由装载于一配送员客户端中应用程序运行。

在一实施例中，加载模块23藉由检测模块21检测到所述回收餐盒提醒项被触发时加载一回收详情页。在一些示例中，所述回收详情页中展示有回收配置列目以供用户通过触发操作在对应的列目下配置回收配置信息，所述回收配置信息包括取件时间、取件地点、以及用户联系方式中的至少两种信息。进一步地，所述回收详情页中还展示有提交回收餐盒请求项，用户在完成回收配置信息的配置后，提交模块22藉由检测模块21检测到触发操作所述提交回收餐盒请求项时提交回收餐盒请求，其中，回收餐盒请求中包括所述回收配置信息。

如图7所示的回收详情页的示意图，所述回收详情页中展示有回收配置列目，回收配置列目包括取件时间、取件地点、联系方式。通过用户对取件时间的下拉按键的触发操作可实现对取件时间进行选择。通过用户对取件地点的触发操作可实现对取件地点的获取，例如选择通过获取预先存储的地址作为取件地点、或通过手动输入添加新地址作为取件地点、再或者通过获取定位信息作为取件地点。通过用户对联系方式的触发操作可实现对联系方式的配置，例如选择通过获取预先存储的号码作为联系方式、或通过手动输入添加新号码作为联系方式、再或者通过获取通讯录中号码作为联系方式。在回收配置列目下完成回收配置信息的配置后，用户通过触发操作作为提交回收餐盒请求项的虚拟按键“确认”时，提交模块22提交回收餐盒请求给服务端。

提交模块22将所述回收餐盒请求提交给服务端，服务端依据前述餐盒回收处理方法生成餐盒回收反馈信息，鉴于此，所述加载模块23还用于接收餐盒回收反馈信息并展示在展示界面中。

如前所述，所述餐盒回收反馈信息包括配送员的联系方式、安全信息、以及取件码中的多种信息，所述安全信息包括表征配送员健康状态的二维码数据或二维码。故而，加载模块23可基于接收到的餐盒回收反馈信息选择性的将餐盒回收反馈信息中的多种信息部分展示或全部展示在展示界面中。例如，加载模块23在检测模块21检测到用户提交所述回收餐盒请求的触发操作后加载一反馈信息展示界面，并在所述反馈信息展示界面中展示餐盒回收反馈信息，在一示例中，所述反馈信息展示界面中仅展示有配送员的联系方式、以及取件码。在另一示例中，所述反馈信息展示界面中展示有配送员的联系方式、取件码、以及表征配送员健康状态的二维码，举例来说，在表征配送员健康状态为健康时，所述二维码展示为绿色放心图标，在表征配送员健康状态为一般时，所述二维码展示为黄色提醒图标，表征配送员健康状态为不健康时，所述二维码展示为红色警告图标。需要说明的是，在其它一些示例中，反馈信息展示界面中还可展示有拒绝此次回收餐盒请求项或更换配送员请求项，用于在用户依据安全信息认定此次回收餐盒存在风险时，及时为用户提供其它解决方案的路径以避免此次风险。

实际应用中，配送员依据餐盒订单中的信息在取件时间到达取件地点回收餐盒，而用户以及餐盒回收反馈信息在取件地点将餐盒交给配送员并为配送员提供取件码作为验证以避免出现误取或接单错误等异常状况，配送员拿到餐盒后将餐盒送回至回收点，由回收点对餐盒统一处理。

如前所述，为了推行餐盒回收机制，鼓励用户进行餐盒回收，餐盒回收处理系统藉由装载的服务端执行前述餐盒回收处理方法，从而实现基于餐盒回收订单的完成响应分配虚拟资源给所述订餐系统20。鉴于此，所述加载模块23还用于接收所述虚拟资源并展示在展示界面中。

如前所示，服务端给订餐系统20分配的虚拟资源可例如为预设的固定数额，或者在预设固定范围内的随机数额。其中，所述虚拟资源包括红包、优惠券、代金券、积分、或用户等级等中的任意一种，服务端为订餐系统20分配的虚拟资源可为固定数额的红包、优惠券、代金券、积分、或用户等级中的任意一种，或者服务端为订餐系统20分配的虚拟资源可为在预设固定范围内随机数额的红包、优惠券、代金券、积分、或用户等级中的任意一种。从而加载模块23在接收到所述虚拟资源时，将依据接收到的虚拟资源的类型将所述虚拟资源加载为红包、优惠券、代金券、积分、或用户等级中任意一种形式展示在订餐系统20的展示界面中，例如，用户可通过触发操作展示在其展示界面中的虚拟资源而使其从当前界面消失、或者虚拟资源在展示界面中展示预设时间(例如3s)而从当前界面消失，后期用户可以通过触发操作订餐系统20的用户账户详情页中的红包卡券项查看其获取的虚拟资源。

本申请还提供一种云服务器系统，在实施例中，所述云服务器系统可以根据功能、负载等多种因素布置在一个或多个实体服务器上。其中，当分布在多个实体服务器时，所述服务端可以由基于云架构的服务器组成。例如，基于云架构的服务器包括公共云服务端与私有云服务端，其中，所述公共或私有云服务端包括saas、paas及iaas等。所述私有云服务端例如美团云计算服务平台、阿里云计算服务平台、亚马逊云计算服务平台、百度云计算平台、腾讯云计算平台等。所述服务端还可以由分布的或集中的服务器集群构成。例如，所述服务器集群由至少一台实体服务器构成。每个实体服务器中配置多个虚拟服务器，每个虚拟服务器运行所述商家信息管理服务端中的至少一功能模块，各虚拟服务器之间通过网络通信。

请参阅图10，显示为本申请云服务器系统在一实施例中的模块框图，如图所示，所述云服务器系统30包括至少一个存储设备31以及至少一个处理设备32。

所述至少一存储设备31，用于存储至少一个程序；在实施例中，所述存储设备31包括存储服务器或者存储器，所述存储器可包括高速随机存取存储器，并且还可包括非易失性存储器，例如一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。在某些实施例中，存储器还可以包括远离一个或多个处理器的存储器，例如经由rf电路或外部端口以及通信网络(未示出)访问的网络附加存储器，其中所述通信网络可以是因特网、一个或多个内部网、局域网、广域网、存储局域网等，或其适当组合。存储器控制器可控制设备的诸如cpu和外设接口之类的其他组件对存储器的访问。

所述至少一处理设备32与所述存储设备31相连，用于运行所述至少一个程序时以执行如并实现上述针对餐盒回收处理方法所描述的至少一种实施例。所述处理设备32例如为包括处理器的服务器，比如应用服务器等，所述处理器可操作地与存储器和/或非易失性存储设备耦接。更具体地，处理器可执行在存储器和/或非易失性存储设备中存储的指令以在计算设备中执行操作，诸如生成图像数据和/或将图像数据传输到电子显示器。如此，处理器可包括一个或多个通用微处理器、一个或多个专用处理器(asic)、一个或多个现场可编程逻辑阵列(fpga)、或它们的任何组合。

本申请还提供一种电子装置，请参阅图11，显示为本申请电子装置在一实施例中的模块框图，如图所示，本申请的电子装置40，包括：显示器41，至少一个存储器42，以及至少一个处理器43。

在实施例中，所述电子装置例如为装载有app应用程序或具备网页/网站访问性能的电子设备，所述电子设备包括存储器、存储器控制器、一个或多个处理单元(cpu)、外设接口、rf电路、音频电路、扬声器、麦克风、输入/输出(i/o)子系统、显示屏、其他输出或控制设备，以及外部端口等组件，这些组件通过一条或多条通信总线或信号线进行通信。所述电子装置包括但不限于如台式电脑、笔记本电脑、平板电脑、智能手机、智能电视等个人计算机。所述电子装置还可以是由带有多个虚拟机的主机和对应每个虚拟机的人机交互装置(如触控显示屏、键盘和鼠标)所构成的电子设备。

所述显示器41是功能是通过电子装置中的图形模块及显示其控制器实现的，所述图形模块包括用于在触摸屏上呈现和显示图形的各种已知软件组件。注意术语“图形”包括可以显示给用户的任何对象，包括但不局限于文本、网页、图标(例如包括软按键在内的用户界面对象)、数字图像、视频、动画等等。显示屏例如为触摸屏，在设备与用户之间同时提供输出接口和输入接口。触摸屏控制器接收/发送来自/去往触摸屏的电信号。该触摸屏则向用户显示可视输出。这个可视输出可以包括文本、图形、视频及其任意组合。

所述至少一个存储器42用于存储至少一个程序；在实施例中，所述存储器可包括高速随机存取存储器，并且还可包括非易失性存储器，例如一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。在某些实施例中，存储器还可以包括远离一个或多个处理器的存储器，例如经由rf电路或外部端口以及通信网络访问的网络附加存储器，其中所述通信网络可以是因特网、一个或多个内部网、局域网、广域网、存储局域网等，或其适当组合。存储器控制器可控制设备的诸如cpu和外设接口之类的其他组件对存储器的访问。

在一实施例中，所述至少一个处理器43与所述至少一个存储器42连接，用于运行所述至少一个程序时以执行并实现如上述餐盒回收方法所描述的至少一种实施例，比如图2至图7中任一所描述的实施例。在实施例中，所述处理器43可操作地与存储器和/或非易失性存储设备耦接。更具体地，处理器可执行在存储器和/或非易失性存储设备中存储的指令以在计算设备中执行操作，诸如生成图像数据和/或将图像数据传输到电子显示器。如此，处理器可包括一个或多个通用微处理器、一个或多个专用处理器、一个或多个现场可编程逻辑阵列、或它们的任何组合。

本申请还提供一种计算机可读写存储介质，存储有计算机程序，所述计算机程序被执行时实现上述针对餐盒回收处理方法所描述的至少一种实施例，比如图1中所描述的实施例，或者被执行时实现上述针对餐盒回收方法所描述的至少一种实施例，比如图2至图7任一中所描述的实施例。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

于本申请提供的实施例中，所述计算机可读写存储介质可以包括只读存储器、随机存取存储器、eeprom、cd-rom或其它光盘存储装置、磁盘存储装置或其它磁存储设备、闪存、u盘、移动硬盘、或者能够用于存储具有指令或数据结构形式的期望的程序代码并能够由计算机进行存取的任何其它介质。另外，任何连接都可以适当地称为计算机可读介质。例如，如果指令是使用同轴电缆、光纤光缆、双绞线、数字订户线(dsl)或者诸如红外线、无线电和微波之类的无线技术，从网站、服务器或其它远程源发送的，则所述同轴电缆、光纤光缆、双绞线、dsl或者诸如红外线、无线电和微波之类的无线技术包括在所述介质的定义中。然而，应当理解的是，计算机可读写存储介质和数据存储介质不包括连接、载波、信号或者其它暂时性介质，而是旨在针对于非暂时性、有形的存储介质。如申请中所使用的磁盘和光盘包括压缩光盘(cd)、激光光盘、光盘、数字多功能光盘(dvd)、软盘和蓝光光盘，其中，磁盘通常磁性地复制数据，而光盘则用激光来光学地复制数据。

在一个或多个示例性方面，本申请所述方法的计算机程序所描述的功能可以用硬件、软件、固件或其任意组合的方式来实现。当用软件实现时，可以将这些功能作为一个或多个指令或代码存储或传送到计算机可读介质上。本申请所公开的方法或算法的步骤可以用处理器可执行软件模块来体现，其中处理器可执行软件模块可以位于有形、非临时性计算机可读写存储介质上。有形、非临时性计算机可读写存储介质可以是计算机能够存取的任何可用介质。

本申请上述的附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。基于此，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这根据所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以通过执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以通过专用硬件与计算机指令的组合来实现。

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