CN106302575A - 一种发布任务的方法和设备 - Google Patents

Abstract

本申请实施例提供的一种发布任务的方法和设备，用以解决现有技术中存在的任务发布完成后，任何人都可以接受其他用户发布的任务，安全性较低的问题。本申请的方法包括：根据第一用户发送的需求信息生成任务信息，并确定任务信息对应的权限要求信息；将每个任务信息对应的权限要求信息与第二用户进行匹配；向第二用户推送匹配成功的任务信息。由于能够发布有对应权限要求的任务信息，并且每个用户只能查看并接受自身条件能够满足相应权限要求的任务信息。因而用户在发布任务时，可以根据需要限制一些不满足要求的用户接受自己发布的任务，进而提高了发布任务和接受任务的安全性。

Description

一种发布任务的方法和设备

技术领域

本申请涉及通信领域，尤其涉及一种发布任务的方法和设备。

背景技术

随着互联网技术的飞速发展，越来越多的人们喜欢通过网络平台交流互动，在实际生活中，用户可以通过一些用于发布任务的特定工具在网络上发布任务，以期别人能够接受任务，并帮助自己完成一些无法完成或者不方便完成的事情，这种通过网络发布任务的方式，为人们工作生活带来了极大便利。例如，用户可以在一些平台上发布任务以获得其他人的帮助(如寻求家政服务、小时工等等)，或者是通过接受并完成其他人发布任务来获得奖励；游戏玩家可以使用特定道具来发布任务，发布任务后，可由其他玩家去领取及完成任务。然而，上述现有技术中发布的任务，任何人都可以接受该任务，安全性较低。

综上所述，现有技术中任务发布完成后，任何人都可以接受其他用户发布的任务，安全性较低。

发明内容

本申请实施例提供的一种发布任务的方法和设备，用以解决现有技术中存在的任务发布完成后，任何人都可以接受其他用户发布的任务，安全性较低的问题。

一方面，本申请实施例提供的一种发布任务的方法，该方法包括：

根据第一用户发送的需求信息生成任务信息，并确定所述任务信息对应的权限要求信息；

将每个任务信息对应的权限要求信息与第二用户进行匹配；

向所述第二用户推送匹配成功的任务信息。

本申请实施例在发布任务时，由于能够发布有对应权限要求的任务信息，并且每个用户只能查看并接受自身条件能够满足相应权限要求的任务信息。因而用户在发布任务时，可以根据需要限制一些不满足要求的用户接受自己发布的任务，进而提高了发布任务和接受任务的安全性。

任务发布完成后，任何人都可以接受其他用户发布的任务，安全性较低。

可选的，所述权限要求信息包括下列信息中的部分或者全部：

地理位置范围，信用值范围，注册时长要求，实名制认证要求。

由于本申请实施例中权限要求信息可以包括多种信息，因而用户在发布任务时，可以根据需要限定接受用户的多种条件，从而提高了发布任务和接受任务的安全性。

可选的，所述权限要求信息包括地理位置范围；

将每个任务信息对应的权限要求信息与第二用户进行匹配，包括：

判断第二用户对应的地理位置信息是否在每个任务信息对应的地理位置范围中。

由于本申请实施例中权限要求信息包括地理位置范围，因而用户在发布任务时，可以根据需要限定接受任务用户的地理位置，只有满足用户要求的地理位置范围内的用户才可以接受任务，进而用户可以根据需要发布一些附近居民容易帮助自己完成任务，同时也提高了发布任务和接受任务的安全性。

可选的，所述权限要求信息包括信用值范围；

将每个任务信息对应的权限要求信息与第二用户进行匹配，包括：

判断第二用户对应的信用值是否在每个任务信息对应的信用值范围中。

由于本申请实施例中权限要求信息包括信用值范围，因而用户在发布任务时，可以根据需要限定接受任务用户的信用值，只有满足用户信用值要求的用户才可以接受任务，进而用户可以根据需要寻找信用值较高的用户帮助自己完成任务，进而也提高了发布任务和接受任务的安全性。

可选的，所述权限要求信息包括注册时长要求；

将每个任务信息对应的权限要求信息与第二用户进行匹配，包括：

判断第二用户对应的注册时长是否满足每个任务信息对应的注册时长要求。

由于本申请实施例中权限要求信息包括注册时长要求，因而用户在发布任务时，可以根据需要限定接受任务用户的注册时长，只有满足用户注册时长要求的用户才可以接受任务，进而用户可以根据需要寻找注册时长较长的用户帮助自己完成任务，进而也提高了发布任务和接受任务的安全性。

可选的，所述权限要求信息包括实名制认证要求；

将每个任务信息对应的权限要求信息与第二用户进行匹配，包括：

判断第二用户是否通过实名制认证。

由于本申请实施例中权限要求信息包括实名制认证要求，因而用户在发布任务时，可以根据需要限定接受任务用户是否是需要通过实名制认证的用户，只有满足用户对实名制认证要求的用户才可以接受任务，进而用户可以根据需要寻找通过实名制认证的用户帮助自己完成任务，进而也提高了发布任务和接受任务的安全性。

可选的，所述任务信息对应的权限要求信息是所述第一用户在生成任务时所使用的账号对应的预设权限要求信息，或所述需求信息中包括的预设权限要求信息。

由于本申请实施例中权限要求信息可以根据需要预先设定，也可以在生成任务时，用户根据需要输入权限要求信息，进而增加了多样性。

可选的，向所述第二用户推送匹配成功的任务信息之后，还包括：

若所述第二用户接受所述匹配成功的任务信息，则在任务执行过程中，将接收到的所述第二用户发送的任务进度消息，推送给发布所述匹配成功的任务信息的用户。

另一方面，本申请实施例提供的一种发布任务的设备，该设备包括：

确定模块，用于根据第一用户发送的需求信息生成任务信息，并确定所述任务信息对应的权限要求信息；

匹配模块，用于将每个任务信息对应的权限要求信息与第二用户进行匹配；

推送模块，用于向所述第二用户推送匹配成功的任务信息。

可选的，所述权限要求信息包括下列信息中的部分或者全部：

地理位置范围，信用值范围，注册时长要求，实名制认证要求。

可选的，所述权限要求信息包括地理位置范围；

所述匹配模块具体用于，判断所述第二用户对应的地理位置信息是否在每个任务信息对应的地理位置范围中。

可选的，所述权限要求信息包括信用值范围；

所述匹配模块具体用于，判断所述第二用户对应的信用值是否在每个任务信息对应的信用值范围中。

可选的，所述权限要求信息包括注册时长要求；

所述匹配模块具体用于，判断所述第二用户对应的注册时长是否满足每个任务信息对应的注册时长要求。

可选的，所述权限要求信息包括实名制认证要求；

所述匹配模块具体用于，判断所述第二用户是否通过实名制认证。

可选的，所述任务信息对应的权限要求信息是所述第一用户在生成任务时所使用的账号对应的预设权限要求信息，或所述需求信息中包括的预设权限要求信息。

可选的，所述推送模块还用于，在向所述第二用户推送匹配成功的任务信息之后，若所述第二用户接受所述匹配成功的任务信息，则在任务执行过程中，将接收到的所述第二用户发送的任务进度消息，推送给发布所述匹配成功的任务信息的用户。

附图说明

图1为本申请实施例提供的一种发布任务的方法流程示意图；

图2为本申请实施例提供的发布任务的方法的整体流程示意图；

图3为本申请实施例提供的发布任务和接受任务的流程示意图；

图4为本申请实施例提供的一种发布任务的设备的结构示意图。

具体实施方式

本申请实施例在发布任务时，由于能够发布有对应权限要求的任务信息，并且每个用户只能查看并接受自身条件能够满足相应权限要求的任务信息。因而用户在发布任务时，可以根据需要限制一些不满足要求的用户接受自己发布的任务，进而提高了发布任务和接受任务的安全性。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请。并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

下面结合说明书附图对本申请实施例作进一步详细描述。

如图1所示，本申请实施例提供的一种发布任务的方法包括：

步骤101、根据第一用户发送的需求信息生成任务信息，并确定任务信息对应的权限要求信息；

步骤102、将每个任务信息对应的权限要求信息与第二用户进行匹配；

步骤103、向第二用户推送匹配成功的任务信息。

实际生活中，有多种情况需要发布任务，比如用户需要找家政服务、小时工等等，因而用户可以通过相关网站或者客户端等平台发布任务，寻找相应的家政服务、小时工等；然而，在现有技术中，任务发布完成后，任何人都可以接受其他用户发布的任务，安全性较低。而本申请实施例提供的发布任务的方法，可以生成有对应权限要求信息的任务信息，只有满足权限要求的用户，才有资格接受该任务，进而提高了发布任务和接受任务的安全性。

实施中，本申请实施例可以是用于发布任务的网页版客户端，或是移动终端中一个能够独立运行的应用软件，也可以内嵌到即时通信等客户端软件(例如微信，手机QQ等)中作为一个模块使用。为了方便说明，以下仅以移动终端中一个发布任务的软件，以及以服务器作为执行主体为例对本申请实施例进行详细说明。

也就是说，如果第一用户想通过移动终端中发布任务的软件发布一个任务，则该用户可以在发布任务的软件上输入需求信息，因而服务器可以根据第一用户发送的需求信息生成需要发布的任务信息，并确定该任务信息对应的权限要求信息；服务器会将每个任务信息对应的权限要求信息与第二用户对应的条件信息进行匹配，并向第二用户推送匹配成功的任务信息；由于每个发布的任务信息对应的都有权限要求信息，因而查看任务的第二用户只能查看每个任务对应的权限要求与其他自身条件能够匹配的任务。

实施中，本申请实施例并不限定服务器将任务信息对应的权限要求信息与用户对应的条件信息进行匹配的时序，服务器可以在确定有第二用户使用该应用软件查看任务时，才将将每个任务信息对应的权限要求信息与第二用户对应的条件信息进行匹配；同时，服务器也可以不区分是否有用户查看任务，而是将每个任务信息对应的权限要求信息与所有用户(或者是常用的用户，如在一周内登录的用户)对应的条件信息进行匹配，当有用户查看时，将与该用户的条件信息匹配的任务推送给该用户。

由于本申请实施例中每个发布的任务信息对应的都有权限要求信息，只有满足对应权限要求的用户才能接受对应的任务，而权限要求信息，可以包括多种权限要求信息。可选的，权限要求信息包括下列信息中的部分或者全部：地理位置范围，信用值范围，注册时长要求，实名制认证要求。

其中，权限要求信息用于第一用户在发布任务时，限定能够接受该任务的用户的具体条件，只有满足权限要求信息所对应的要求的用户，才有权查看和接受第一用户发布的任务；地理位置范围用于限定接受对应任务的用户的地理位置；信用值范围用于限定接受对应任务的用户的信用值；注册时长要求用于限定接受对应任务的用户的注册时长；实名制认证要求用于限定接受对应任务的用户是否需要通过实名制认证。

实施中，权限要求信息可以包括上述四种信息中的一种或者多种，用户可以根据需要进行设定；同时，本申请实施例的权限要求信息不仅限于包括上述四种权限要求信息，其它类型的可以作为限定条件的权限要求信息，都可以作为本申请实施例中的权限要求信息。

在生成任务信息时，发布任务的软件可以通过不同的方式确定该任务信息对应的权限要求信息。可选的，任务信息对应的权限要求信息是第一用户在生成任务时所使用的账号对应的预设权限要求信息，或需求信息中包括的预设权限要求信息。

实施中，用户在使用发布任务的软件发布任务时，在通过预先注册的账号登陆该软件后，可以根据需要设定该账号下对应的权限要求信息，也就是说，用户在设定完权限要求信息后，每次发布任务时，服务器会根据该账号所对应的预设权限要求信息生成任务信息，进而服务器确定生成的该任务信息对应的权限要求信息为该账号所对应的预设权限要求信息。

或者是，用户在使用发布任务的软件发布任务时，为了生成任务信息所发送的需求信息中包含相应的权限要求信息，也就是说，用户每次发送的需求信息中，包括可以根据需要选择设定相应的权限要求信息，进而服务器确定生成的该任务信息对应的权限要求信息为需求信息中包含的权限要求信息。

又或者是，本申请实施例中用户即可以预先设定默认的权限要求信息，又可以在发送的需求信息中包含相应的权限要求信息；也就是说，用户可以根据需要预先设定默认的相关权限要求信息，用户在发布任务时，若用户在发送需求信息时包含了权限要求信息，则服务器确定该任务信息对应的权限要求信息为用户发送的需求信息中包含的权限要求信息；若用户没有选择设定相应的权限要求信息，则服务器确定该任务信息对应的权限要求信息为预设的默认预设权限要求信息。

例如，第一用户在发布任务时，通过预先注册的账号登陆发布任务的软件后，可以根据需要设定该账号下对应的默认权限要求信息为：地理位置范围为A小区附近，信用值范围的要求为信用值分数为600分以上，注册时长要求1年以上，并且要求通过实名制认证；因而，第一用户每次使用该账号发布任务时，服务器确定生成的任务信息对应的权限要求信息为该账号所对应的预设权限要求信息，即地理位置范围为A小区附近，信用值范围的要求为信用值分数为600分以上，注册时长要求1年以上，并且要求通过实名制认证。

又例如，第一用户在发布任务时，每次都可以根据需要在发送需求信息时输入相应的权限要求信息，如第一用户想发布一个找人帮忙买菜的任务，因而用户可以根据需要在发送需求信息时包含权限要求信息，即限定接受任务的用户的地理位置范围为A小区附近；因而服务器确定第一用户发布的找人帮忙买菜的任务信息对应的权限要求信息为第一用户发送需求信息时包含的权限要求信息，即地理位置范围为A小区附近。

又例如，第一用户预先通过预先注册的账号登陆发布任务的软件后，预先设定该账号下对应的默认权限要求信息为：地理位置范围为A小区附近，信用值范围的要求为信用值分数为600分以上，注册时长要求1年以上，并且要求通过实名制认证；则在第一用户以后通过该账号发布任务时，若第一用户在发送需求信息时包含了权限要求信息(即地理位置范围为A小区附近)，则服务器确定该任务信息对应的权限要求信息为第一用户发送的需求信息中包含的权限要求信息，即地理位置范围为A小区附近；若第一用户在发送需求信息时，没有选择设定相应的权限要求信息，则服务器确定该任务信息对应的权限要求信息为预设的默认预设权限要求信息，即接受任务的用户必须满足：地理位置范围为A小区附近，信用值范围的要求为信用值分数为600分以上，注册时长要求1年以上，并且要求通过实名制认证。

其中，本申请实施例提供的发布任务的软件或者是网站等，用户需要通过账号登录，登录成功后，才有权查看或者发布任务；而登录的账号可以是用户预先注册的账号，也可以是其它已经注册使用的交易软件的账号(如淘宝账号等)；为了用户的个人信息的安全，用户可以选择匿名登录，例如，用户选择匿名登录后，用户在发布任务时，该任务中并不会显示用户的个人信息，或者是隐藏部分信息，只有某用户接受该发布任务的用户的任务之后，才可以看到发布任务的用户的真实个人信息(如用户的手机号码等)。

实施中，上述确定所生成的任务信息对应的权限要求信息的方式只是为了方便说明，其他的确定权限要求信息的方式也适用于本申请实施例的方法。

由于本申请实施例中的权限要求信息可以限制接受任务用户的条件，通过这些权限要求，可以进一步提高发布任务和接受任务的安全性，而该权限要求信息可以包括地理位置范围，信用值范围，注册时长要求，实名制认证要求等多种信息的部分或者全部，可选的，下面分别对权限要求信息单独包括上述四种要求信息中的一种时的情况进行详细介绍。

一、权限要求信息包括地理位置范围。

具体的，步骤102中，判断第二用户对应的地理位置信息是否在每个任务信息对应的地理位置范围中。

实施中，若权限要求信息只包括地理位置范围，针对每个任务信息，服务器都需要判断第二用户对应的地理位置信息是否在该任务信息对应的地理位置范围中，若是，则表示匹配成功，服务器为该第二用户显示该匹配成功的任务信息；否则，则表示匹配失败，该第二用户无权查看该任务信息。

本申请实施例中地理位置范围的要求可以保证用户生活区域有高度重合性。在用户发布一些特定任务时，可以通过地理位置范围的权限要求，限定接受任务用户的地理位置。

例如，用户A住在B小区，周六下午有个快递会送到家，但由于周六下午用户A有事外出不在家，所以想发布一个任务请人在周六下午帮忙接收一下快递，因而用户A在发布任务时，若权限要求信息只包括地理位置范围，即地理位置范围必须在B小区附近，因而服务器判断用户C对应的地理位置信息是否是在B小区附近，若是，则表示匹配成功，服务器将用户A发布的任务推送给用户C。

实施中，上述任务信息对应的地理位置范围可以是用户在发布任务时，在发送的需求信息中包括的地理位置范围，此时服务器确定生成的该任务信息对应的权限要求信息为需求信息中包含的地理位置范围；也可以是用户在通过预先注册的账号登陆该软件后，预先设定该账号默认的地理位置范围，此时服务器确定生成的任务信息对应的权限要求信息为该账号下对应的预设地理位置范围；又或者是，用户在发布任务时，若通过已经注册使用的交易软件的账号登陆该发布任务的软件，如用户通过淘宝账号登陆该发布任务的软件，则服务器可以根据淘宝账号中对应的收货地址来确定本申请实施例中的地理位置范围。

例如，用户A通过自己已有的淘宝账号登陆发布任务的软件后，该淘宝账号中有两个常用地址，公司地址C和家庭住址D，则用户A在发布任务时，服务器会根据该淘宝账号下已有的常用地址，自动提示用户是否选择设定公司地址C和家庭住址D中一个为该任务对应的地理位置，若用户A选择家庭住址D为该任务对应的地理位置，则服务器根据家庭住址D，确定相应的地理位置范围作为该任务对应的权限要求信息，因而当用户通过已经注册使用的交易软件的账号登陆发布任务的软件时，可以根据该账号对应的收货地址信息确定本申请实施例中的地理位置范围，无需用户再自行输入地理位置要求或者是设定默认的地理位置。

实施中，上述确定每个用户的地理位置的方式只是为了方便说明，本申请实施例并不仅限于以上确定方式，其他的确定地理位置的方式也适用于本申请实施例的方法。

同时，为了增加发布任务的用户对接受任务用户的信任，权限要求信息还可以包括信用值范围，下面具体介绍。

二、权限要求信息包括信用值范围。

具体的，步骤102中，判断第二用户对应的信用值是否在每个任务信息对应的信用值范围中。

实施中，若权限要求信息只包括信用值范围，针对每个任务信息，服务器都需要判断第二用户对应的信用值是否在任务信息对应的信用值范围中，若是，则表示匹配成功，服务器为该第二用户显示该匹配成功的任务信息；否则，则表示匹配失败，该第二用户无权查看该任务信息。

本申请实施例中信用值范围的要求，可以在发布任务时选择信用值较高的用户来接受任务，增加用户对接受任务的用户的信任度。在用户发布一些特定的需要较高信任度的任务时，可以通过信用值范围的权限要求，限定接受任务用户的信用值。

例如，用户A住在B小区，每天需要接送孩子上下学，但由于周三下午用户A有急事外出，无法去学校接孩子放学，所以想发布一个任务请人在周三下午帮忙接孩子放学，因而用户A在发布任务时，不仅可以限定有权查看和接受该任务的用户的地理位置范围必须在B小区附近，而且可以设定对接受任务的用户的信用值范围的要求为655分以上，服务器会根据用户设定的信用值范围的要求，确定用户发布的任务对应的权限要求为信用值655分以上，进而用户可以根据需要设定只有满足信用值要求的用户才有权接受用户A发布的任务。

实施中，上述任务信息对应的信用值范围可以是用户在发布任务时，在发送的需求信息中包括的信用值范围；也可以是用户预先设定的默认的信用值范围。其中，本申请实施例提供的第二用户对应的信用值的确定也包括多种方式，例如，发布任务的软件在登录后，需要用户通过实名认证，然后可以直接调用评价用户信用的***中该用户对应的信用值信息，如芝麻信用***、腾讯征信***或者个人征信***等各种用于评价用户信用的***；同时，也可以根据用户所使用账号之前完成任务后收到的评价确定的好评度等来确定用户的信用值。

例如，发布任务的软件根据芝麻信用***中用户的信息分值来确定每个用户的信用值，用户A通过已经实名认证的账号登陆后，用户A的相应的信用分值也确定为该用户的芝麻信用分值(如芝麻信用分值为655，即信用等级良好)，而用户A在接受和查看别人发布的任务时，服务器只会向用户A推送对应的信用值范围要求在655以下的任务，而不会向用户A推送超过自己信用分值的任务；同时，用户A在发布任务时，也可以根据自己的需要设定信用值的范围为350到950之间(芝麻分的范围为350到950)的数值范围，因而服务器会确定只有信用值满足用户A发布任务中对信用值要求的用户，才有权查看和接受用户A发布的任务。

又例如，可以根据需要设定，本申请实施例提供的发布任务的方法，每次用户在接受并完成任务以后，可以提示发布任务的第一用户对接受任务的第二用户完成任务的情况进行评价，服务器根据第二用户收到的所有评价确定第二用户的信用值，若第二用户在预设的三次评价时分数都较低，则将第二用户的信用值的数值降低一分；或者是，服务器根据第二用户收到的所有评价确定第二用户对应的好评度等，以便可以方便其他用户的查看第二用户之前完成任务的情况。

实施中，上述确定每个用户的信用值的方式只是为了方便说明，本申请实施例并不仅限于以上确定方式，其他的确定信用值的方式也适用于本申请实施例的方法。

为了增加发布任务的用户对接受任务用户条件要求的多样性，使发布任务的用户可以通过更多的权限要求进一步限定接受任务的用户，权限要求信息还可以包括注册时长要求，下面具体介绍。

三、权限要求信息包括注册时长要求。

具体的，步骤102中，判断第二用户对应的注册时长是否满足每个任务信息对应的注册时长要求。

实施中，若权限要求信息只包括注册时长要求，针对每个任务信息，服务器都需要判断第二用户对应的注册时长是否满足任务信息对应的注册时长要求，若是，则表示匹配成功，服务器为该第二用户显示该匹配成功的任务信息；否则，则表示匹配失败，该第二用户无权查看该任务信息。

本申请实施例中注册时长的要求，可以在发布任务时选择注册时长较长的用户来接受任务，增加用户对接受任务的用户的信任度。在用户发布任务时，不仅可以设定上述的地理位置范围和信用值范围要求，也可以根据需要设定对接受任务的用户的注册时长的要求。

实施中，上述任务信息对应的注册时长要求可以是用户在发布任务时，在发送的需求信息中包括的注册时长要求；也可以是用户预先设定的默认的注册时长要求。其中，本申请实施例提供的第二用户对应的注册时长是第二用户登陆发布任务的软件所使用账号对应的注册时长。

例如，用户A的淘宝账号的注册时长为3年5个月，而注册发布任务的软件的账号的时长为6个月；若用户A通过淘宝账号登陆发布任务的软件，则服务器在生成任务时，会确定用户A对应的注册时长为3年5个月，因而服务器会判断用户A的注册时长是否满足每个任务对应的对注册时长的要求，若是(即任务对应的注册时长的要求小于或等于3年5个月)，则服务器向用户A推送对应的注册时长的要求小于或等于3年5个月的任务；而若用户A通过发布任务软件的账号登陆发布任务的软件，则服务器在生成任务时，会确定用户A对应的注册时长为6个月，因而服务器会判断用户A的注册时长是否满足每个任务对应的对注册时长的要求，若是(即任务对应的注册时长的要求小于或等于6个月)，则服务器向用户A推送对应的注册时长的要求小于或等于6个月的任务。

实施中，上述确定每个用户的注册时长的方式只是为了方便说明，本申请实施例并不仅限于以上确定方式，其他的确定注册时长的方式也适用于本申请实施例的方法。

为了增加发布任务的用户对接受任务用户条件要求的多样性，使发布任务的用户可以通过更多的权限要求进一步限定接受任务的用户，权限要求信息还可以包括实名制认证要求，下面具体介绍。

四、权限要求信息包括实名制认证要求。

具体的，步骤102中，判断第二用户是否通过实名制认证。

实施中，若权限要求信息只包括实名制认证要求，针对每个任务信息，服务器都需要判断第二用户是否通过实名制认证，若是，则表示匹配成功，服务器为该第二用户显示该匹配成功的任务信息；否则，则表示匹配失败，该第二用户无权查看该任务信息。

本申请实施例中实名制认证要求，可以在发布任务时选择通过实名制认证的用户来接受任务，增加用户对接受任务的用户的信任度。在用户发布任务时，不仅可以设定上述的地理位置范围、信用值范围要求和注册时长要求，也可以根据需要设定对接受任务的用户是否通过实名制认证的要求。

实施中，上述任务信息对应的实名制认证要求可以是用户在发布任务时，在发送的需求信息中包括的实名制认证要求；也可以是用户预先设定的默认的实名制认证要求。其中，本申请实施例提供的第二用户对应的实名制认证信息是第二用户登陆发布任务的软件所使用账号对应的是否通过实名制认证的信息。

例如，用户A的淘宝账号的已经通过实名制认证，而注册发布任务的软件的账号并未通过实名制认证；若用户A通过淘宝账号登陆发布任务的软件，则服务器在生成任务时，会确定用户A对应的信息为已经通过实名制认证，因而服务器会向用户A推送对应的要求必须通过实名制认证的任务，又会向用户A推送对应的不要求必须通过实名制认证的任务；而若用户A通过发布任务软件的账号登陆发布任务的软件，则服务器在生成任务时，会确定用户A对应的信息为未通过实名制认证，因而服务器会判断用户A未通过实名制认证是否满足每个任务对应的对实名制认证信息的要求，若是(即任务并不要求必须通过实名制认证的任务)，则服务器向用户A推送对应的不要求必须通过实名制认证的任务。

上述确定每个用户是否通过实名制制认证的方式只是为了方便说明，本申请实施例并不仅限于以上确定方式，其他的确定的方式也适用于本申请实施例的方法。

实施中，任务信息对应的权限要求信息不仅可以单独包括上述四种要求信息中的一种，同时也可能包括四种信息中的部分或者全部，用户可以根据实际需要进行选择设定，若用户一直未设定默认权限要求信息，且在生成任务时也未发送权限要求信息，则可以预设每种信息在未选择时有一个固定的默认权限要求信息。

其中，上述各个要求信息的确定方式等也适用于权限要求信息包括四种要求信息中的部分或者全部信息的情况，只是在权限要求信息包括多种要求信息时，有权接受任务的用户必须满足所有的要求信息，具体的如何将每个任务信息对应的权限要求信息与接受任务的用户进行匹配的过程，与上述单独包括四种要求信息中的一种时的匹配过程相同，因而此处不再重复赘述。

实施中，上述权限要求信息可以包括多种类型的要求信息，为了方便说明，本申请实施例仅对上述四种要求信息进行详细说明，但本申请实施例的方法并不仅局限于适用以上四种要求信息，其他的要求信息也适用于本申请实施例的方法。

在向第二用户推送匹配成功的任务信息后，第二用户可以查看到相应匹配成功的任务信息，若第二用户接受某个匹配成功的任务，则执行任务的过程中，可以根据需要向发布任务的第一用户发送任务进度消息。可选的，在步骤103之后，若第二用户接受匹配成功的任务信息，则在任务执行过程中，将接收到的第二用户发送的任务进度消息，推送给发布匹配成功的任务信息的用户。

实施中，在第二用户接受某个匹配成功的任务后，在执行任务的过程中，第二用户可以实时向发布该任务的用户反馈任务进度消息，发布任务的软件会实时提醒发布该任务的用户，目前任务完成的进度消息。

例如，假设根据需要将每个任务对应的划分为三个阶段：第一接受任务阶段，第二任务基本完成阶段，第三任务已经完成阶段。用户E在成功接受用户A发布的接孩子放学的任务后，表示已经进入第一阶段；在用户E执行任务的过程中，服务器可以根据用户E发送的任务进度消息，实时的向用户A反馈任务完成的进度消息，如用户A在接到孩子以后，此时任务基本完成，用户E可以选择进入第二阶段，并在发布任务的软件中上传拍的孩子照片(或者是直接发送给用户A)，则发布任务的软件会实时提醒用户A，任务已经进入第二阶段；当用户E顺利将孩子送到用户A家后，此时任务已经顺利完成，用户E可以选择进入第三阶段，并在发布任务的软件中上传拍的孩子在家的照片(或者是直接发送给用户A)，则发布任务的软件会实时提醒用户A，任务已经进入第三阶段，任务已经完成。

实施中，发布任务的软件除了具有上述功能外，还可以实现发布任务的用户和接受任务的用户之间的聊天沟通，如用户在选择需要和其他用户聊天时，可以直接显示页面聊天窗口或者是直接转到其他聊天软件进行沟通。同时，为了提高完成任务的效率和积极性，发布任务的用户可以对自己发布的任务设置一定的奖励，当接受任务的一方顺利完成任务时，会得到相应金额的奖励。

又或者是，用户可以与其他用户约定交换帮对方任务，进而将自己在某时刻不方便完成的事情找人替自己完成，并在预设时间内帮对方完成其它的任务。例如，用户A和用户E在之前达成约定交换任务的协议，在用户E帮用户A完成接孩子放学的任务后，服务器可以根据需要记录用户E已经完成交换任务，并在预设时间段内，周期性提醒用户A需要帮助用户E完成交换的任务，若用户A在预设时间段内并未履行协议，帮用户E完成任务，则服务器会按照预先设定的规则相应的给用户A一定惩罚，如降低用户A的信用值或者好评度等。

本申请实施例上述各部分的执行过程都在网站侧实现，但是具体执行主体可以由一个服务器实现，也可以将各功能分布在多个服务器实现，只要是能够实现本申请实施例中的方法即可，并不限定具体的执行主体的类型或者是结构。

如图2所示，为本申请实施例提供的发布任务的方法的整体流程示意图，其中，假设权限要求信息为地理位置范围，且第一用户发布的任务被第二用户接受，则该整体流程包括：

步骤201、根据第一用户发送的需求信息生成任务信息，并确定任务信息对应的地理位置范围；

步骤202、判断第二用户对应的地理位置信息是否在每个任务信息对应的地理位置范围中，若是，则执行步骤203，否则，结束本流程；

步骤203、确定对应的任务信息匹配成功，并向第二用户推送匹配成功的任务信息，并执行步骤204；

步骤204、判断第二用户是否接受匹配成功的任务信息，若是，则执行步骤205，否则，结束本流程；

步骤205、在任务执行过程中，将接收到的第二用户发送的任务进度消息，推送给发布匹配成功的任务信息的用户。

为了更加充分的说明本申请实施例中发布任务的方法，下面以发布任务的软件为例，对上述方法的发布任务的流程进行说明。如图3所示，为本申请实施例提供的发布任务和接受任务的流程示意图。主要包括发布任务(实线箭头的流程，即流程一)和查看任务(虚线箭头的流程，即流程二)两个流程。

流程一、用户在打开发布任务的软件后，服务器根据用户的需求发布任务，在任务发布成功后，服务器等待其他人接受该任务，若确定有其他人接受任务，并顺利完成该任务，则关闭对应的任务。

流程二、用户在打开发布任务的软件后，若服务器确定需要查看他人发布的任务，则服务器判断该用户的条件是否能够满足每个任务对应的权限要求信息，若满足，则向该用户推送满足的任务，若服务器确定用户接受他人的任务，并顺利完成该任务，则关闭对应的任务。

基于同一发明构思，本申请实施例中还提供了一种发布任务的设备，由于该设备解决问题的原理与本申请实施例发布任务的方法相似，因此该设备的实施可以参见方法的实施，重复之处不再赘述。

如图4所示，本申请实施例提供的发布任务的设备包括：确定模块401、匹配模块402、推送模块403。

确定模块401，用于根据第一用户发送的需求信息生成任务信息，并确定任务信息对应的权限要求信息；

匹配模块402，用于将每个任务信息对应的权限要求信息与第二用户进行匹配；

推送模块403，用于向第二用户推送匹配成功的任务信息。

本申请实施例在发布任务时，由于能够发布有对应权限要求的任务信息，并且每个用户只能查看并接受自身条件能够满足相应权限要求的任务信息。因而用户在发布任务时，可以根据需要限制一些不满足要求的用户接受自己发布的任务，进而提高了发布任务和接受任务的安全性。

可选的，权限要求信息包括下列信息中的部分或者全部：

地理位置范围，信用值范围，注册时长要求，实名制认证要求。

其中，权限要求信息用于第一用户在发布任务时，限定能够接受该任务的用户的具体条件，只有满足权限要求信息所对应的要求的用户，才有权查看和接受第一用户发布的任务；地理位置范围用于限定接受对应任务的用户的地理位置；信用值范围用于限定接受对应任务的用户的信用值；注册时长要求用于限定接受对应任务的用户的注册时长；实名制认证要求用于限定接受对应任务的用户是否需要通过实名制认证。

实施中，权限要求信息可以包括上述四种信息中的一种或者多种，用户可以根据需要进行设定；同时，本申请实施例的权限要求信息不仅限于包括上述四种权限要求信息，其它类型的可以作为限定条件的权限要求信息，都可以作为本申请实施例中的权限要求信息。

可选的，权限要求信息包括地理位置范围；

匹配模块402具体用于，判断第二用户对应的地理位置信息是否在每个任务信息对应的地理位置范围中。

实施中，若权限要求信息只包括地理位置范围，针对每个任务信息，匹配模块402都需要判断第二用户对应的地理位置信息是否在该任务信息对应的地理位置范围中，若是，则表示匹配成功，匹配模块402为该第二用户显示该匹配成功的任务信息；否则，则表示匹配失败，该第二用户无权查看该任务信息。

本申请实施例中地理位置范围的要求可以保证用户生活区域有高度重合性。在用户发布一些特定任务时，可以通过地理位置范围的权限要求，限定接受任务用户的地理位置。

可选的，权限要求信息包括信用值范围；

匹配模块402具体用于，判断第二用户对应的信用值是否在每个任务信息对应的信用值范围中。

实施中，若权限要求信息只包括信用值范围，针对每个任务信息，匹配模块402都需要判断第二用户对应的信用值是否在任务信息对应的信用值范围中，若是，则表示匹配成功，匹配模块402为该第二用户显示该匹配成功的任务信息；否则，则表示匹配失败，该第二用户无权查看该任务信息。

本申请实施例中信用值范围的要求，可以在发布任务时选择信用值较高的用户来接受任务，增加用户对接受任务的用户的信任度。在用户发布一些特定的需要较高信任度的任务时，可以通过信用值范围的权限要求，限定接受任务用户的信用值。

可选的，权限要求信息包括注册时长要求；

匹配模块402具体用于，判断第二用户对应的注册时长是否满足每个任务信息对应的注册时长要求。

实施中，若权限要求信息只包括注册时长要求，针对每个任务信息，匹配模块402都需要判断第二用户对应的注册时长是否满足任务信息对应的注册时长要求，若是，则表示匹配成功，匹配模块402为该第二用户显示该匹配成功的任务信息；否则，则表示匹配失败，该第二用户无权查看该任务信息。

本申请实施例中注册时长的要求，可以在发布任务时选择注册时长较长的用户来接受任务，增加用户对接受任务的用户的信任度。在用户发布任务时，不仅可以设定上述的地理位置范围和信用值范围要求，也可以根据需要设定对接受任务的用户的注册时长的要求。

可选的，权限要求信息包括实名制认证要求；

匹配模块402具体用于，判断第二用户是否通过实名制认证。

实施中，若权限要求信息只包括实名制认证要求，针对每个任务信息，匹配模块402都需要判断第二用户是否通过实名制认证，若是，则表示匹配成功，匹配模块402为该第二用户显示该匹配成功的任务信息；否则，则表示匹配失败，该第二用户无权查看该任务信息。

本申请实施例中实名制认证要求，可以在发布任务时选择通过实名制认证的用户来接受任务，增加用户对接受任务的用户的信任度。在用户发布任务时，不仅可以设定上述的地理位置范围、信用值范围要求和注册时长要求，也可以根据需要设定对接受任务的用户是否通过实名制认证的要求。

可选的，任务信息对应的权限要求信息是第一用户在生成任务时所使用的账号对应的预设权限要求信息，或需求信息中包括的预设权限要求信息。

实施中，用户在使用发布任务的软件发布任务时，在通过预先注册的账号登陆该软件后，可以根据需要设定该账号下对应的权限要求信息，也就是说，用户在设定完权限要求信息后，每次发布任务时，确定模块401会根据该账号所对应的预设权限要求信息生成任务信息，进而确定模块401确定生成的该任务信息对应的权限要求信息为该账号所对应的预设权限要求信息。

或者是，用户在使用发布任务的软件发布任务时，为了生成任务信息所发送的需求信息中包含相应的权限要求信息，也就是说，用户每次发送的需求信息中，包括可以根据需要选择设定相应的权限要求信息，进而确定模块401确定生成的该任务信息对应的权限要求信息为需求信息中包含的权限要求信息。

又或者是，本申请实施例中用户即可以预先设定默认的权限要求信息，又可以在发送的需求信息中包含相应的权限要求信息；也就是说，用户可以根据需要预先设定默认的相关权限要求信息，用户在发布任务时，若用户在发送需求信息时包含了权限要求信息，则确定模块401确定该任务信息对应的权限要求信息为用户发送的需求信息中包含的权限要求信息；若用户没有选择设定相应的权限要求信息，则确定模块401确定该任务信息对应的权限要求信息为预设的默认预设权限要求信息。

可选的，推送模块403还用于，在向第二用户推送匹配成功的任务信息之后，若第二用户接受匹配成功的任务信息，则在任务执行过程中，将接收到的第二用户发送的任务进度消息，推送给发布匹配成功的任务信息的用户。

实施中，在第二用户接受某个匹配成功的任务后，在执行任务的过程中，第二用户可以实时向发布该任务的用户反馈任务进度消息，推送模块403会实时提醒发布该任务的用户，目前任务完成的进度消息。

例如，假设根据需要将每个任务对应的划分为三个阶段：第一接受任务阶段，第二任务基本完成阶段，第三任务已经完成阶段。用户E在成功接受用户A发布的接孩子放学的任务后，表示已经进入第一阶段；在用户E执行任务的过程中，推送模块403可以根据用户E发送的任务进度消息，实时的向用户A反馈任务完成的进度消息，如用户A在接到孩子以后，此时任务基本完成，用户E可以选择进入第二阶段，并在发布任务的软件中上传拍的孩子照片(或者是直接发送给用户A)，则发布任务的软件会实时提醒用户A，任务已经进入第二阶段；当用户E顺利将孩子送到用户A家后，此时任务已经顺利完成，用户E可以选择进入第三阶段，并在发布任务的软件中上传拍的孩子在家的照片(或者是直接发送给用户A)，则发布任务的软件会实时提醒用户A，任务已经进入第三阶段，任务已经完成。

从上述内容可以看出：本申请实施例在发布任务时，由于能够发布有对应权限要求的任务信息，并且每个用户只能查看并接受自身条件能够满足相应权限要求的任务信息。因而用户在发布任务时，可以根据需要限制一些不满足要求的用户接受自己发布的任务，进而提高了发布任务和接受任务的安全性。

以上参照示出根据本申请实施例的方法、装置(***)和/或计算机程序产品的框图和/或流程图描述本申请。应理解，可以通过计算机程序指令来实现框图和/或流程图示图的一个块以及框图和/或流程图示图的块的组合。可以将这些计算机程序指令提供给通用计算机、专用计算机的处理器和/或其它可编程数据处理装置，以产生机器，使得经由计算机处理器和/或其它可编程数据处理装置执行的指令创建用于实现框图和/或流程图块中所指定的功能/动作的方法。

相应地，还可以用硬件和/或软件(包括固件、驻留软件、微码等)来实施本申请。更进一步地，本申请可以采取计算机可使用或计算机可读存储介质上的计算机程序产品的形式，其具有在介质中实现的计算机可使用或计算机可读程序代码，以由指令执行***来使用或结合指令执行***而使用。在本申请上下文中，计算机可使用或计算机可读介质可以是任意介质，其可以包含、存储、通信、传输、或传送程序，以由指令执行***、装置或设备使用，或结合指令执行***、装置或设备使用。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (16)

1.一种发布任务的方法，其特征在于，该方法包括：

根据第一用户发送的需求信息生成任务信息，并确定所述任务信息对应的权限要求信息；

将每个任务信息对应的权限要求信息与第二用户进行匹配；

向所述第二用户推送匹配成功的任务信息。

2.根据权利要求1所述的方法，其特征在于，所述权限要求信息包括下列信息中的部分或者全部：

地理位置范围，信用值范围，注册时长要求，实名制认证要求。

3.根据权利要求2所述的方法，其特征在于，所述权限要求信息包括地理位置范围；

将每个任务信息对应的权限要求信息与第二用户进行匹配，包括：

判断第二用户对应的地理位置信息是否在每个任务信息对应的地理位置范围中。

4.根据权利要求2所述的方法，其特征在于，所述权限要求信息包括信用值范围；

将每个任务信息对应的权限要求信息与第二用户进行匹配，包括：

判断第二用户对应的信用值是否在每个任务信息对应的信用值范围中。

5.根据权利要求2所述的方法，其特征在于，所述权限要求信息包括注册时长要求；

将每个任务信息对应的权限要求信息与第二用户进行匹配，包括：

判断第二用户对应的注册时长是否满足每个任务信息对应的注册时长要求。

6.根据权利要求2所述的方法，其特征在于，所述权限要求信息包括实名制认证要求；

将每个任务信息对应的权限要求信息与第二用户进行匹配，包括：

判断第二用户是否通过实名制认证。

7.根据权利要求1所述的方法，其特征在于，所述任务信息对应的权限要求信息是所述第一用户在生成任务时所使用的账号对应的预设权限要求信息，或所述需求信息中包括的预设权限要求信息。

8.根据权利要求1～7任一所述的方法，其特征在于，向所述第二用户推送匹配成功的任务信息之后，还包括：

若所述第二用户接受所述匹配成功的任务信息，则在任务执行过程中，将接收到的所述第二用户发送的任务进度消息，推送给发布所述匹配成功的任务信息的用户。

9.一种发布任务的设备，其特征在于，该设备包括：

确定模块，用于根据第一用户发送的需求信息生成任务信息，并确定所述任务信息对应的权限要求信息；

匹配模块，用于将每个任务信息对应的权限要求信息与第二用户进行匹配；

推送模块，用于向所述第二用户推送匹配成功的任务信息。

10.根据权利要求9所述的设备，其特征在于，所述权限要求信息包括下列信息中的部分或者全部：

地理位置范围，信用值范围，注册时长要求，实名制认证要求。

11.根据权利要求10所述的设备，其特征在于，所述权限要求信息包括地理位置范围；

所述匹配模块具体用于，判断所述第二用户对应的地理位置信息是否在每个任务信息对应的地理位置范围中。

12.根据权利要求10所述的设备，其特征在于，所述权限要求信息包括信用值范围；

所述匹配模块具体用于，判断所述第二用户对应的信用值是否在每个任务信息对应的信用值范围中。

13.根据权利要求10所述的设备，其特征在于，所述权限要求信息包括注册时长要求；

所述匹配模块具体用于，判断所述第二用户对应的注册时长是否满足每个任务信息对应的注册时长要求。

14.根据权利要求10所述的设备，其特征在于，所述权限要求信息包括实名制认证要求；

所述匹配模块具体用于，判断所述第二用户是否通过实名制认证。

15.根据权利要求9所述的设备，其特征在于，所述任务信息对应的权限要求信息是所述第一用户在生成任务时所使用的账号对应的预设权限要求信息，或所述需求信息中包括的预设权限要求信息。

16.根据权利要求9～15任一所述的设备，其特征在于，所述推送模块还用于，在向所述第二用户推送匹配成功的任务信息之后，若所述第二用户接受所述匹配成功的任务信息，则在任务执行过程中，将接收到的所述第二用户发送的任务进度消息，推送给发布所述匹配成功的任务信息的用户。