本申請涉及業(yè)務實現(xiàn)技術領域,尤其涉及一種業(yè)務實現(xiàn)方法及裝置。
背景技術:
隨著網(wǎng)絡技術的發(fā)展,出現(xiàn)了多種多樣的業(yè)務實現(xiàn)方式。以“紅包”形式的虛擬物品交互為例,用戶可以將電子賀卡、禮金等放入“紅包”中,然后單獨發(fā)放至某個用戶,或者發(fā)放至群組內,由群組內的所有成員進行領取。
技術實現(xiàn)要素:
有鑒于此,本申請?zhí)峁┮环N業(yè)務實現(xiàn)方法及裝置,可以優(yōu)化對業(yè)務對象的分配過程。
為實現(xiàn)上述目的,本申請?zhí)峁┘夹g方案如下:
根據(jù)本申請的第一方面,提出了一種業(yè)務實現(xiàn)方法,包括:
第一用戶通過第一客戶端收集用于提取業(yè)務對象的電子憑證;
第一客戶端判斷收集到的電子憑證的類別數(shù)是否達到第一數(shù)量;
當收集到的電子憑證的類別數(shù)達到第一數(shù)量時,向服務端發(fā)起包含若干電子憑證并且包含的電子憑證的類別數(shù)為第一數(shù)量的對象分配請求,以使得所述服務端基于該對象分配請求從業(yè)務對象集合中為所述第一用戶分配業(yè)務對象。
可選的,所述獲取用于提取業(yè)務對象的電子憑證,包括:
獲取服務端為所述第一客戶端下發(fā)的電子憑證;以及
獲取第二用戶通過第二客戶端分享的電子憑證。
可選的,所述第一客戶端提供用于獲取電子憑證的觸發(fā)選項;
所述獲取服務端為所述第一客戶端下發(fā)的電子憑證,包括:
當檢測到所述第一用戶針對所述觸發(fā)選項的觸發(fā)操作時,向所述服務端發(fā)起用于獲取所述電子憑證的請求,以使得所述服務端基于預設下發(fā)規(guī)則向所述第一客戶端下發(fā)電子憑證;
獲取所述服務端基于所述預設下發(fā)規(guī)則為所述第一客戶端下發(fā)的電子憑證;其中,所述服務端為所述第一客戶端下發(fā)的電子憑證的類別數(shù)小于所述第一數(shù)量。
可選的,所述方法還包括:
當收集到電子憑證時,為該電子憑證生成對應的展示圖片;
將生成的展示圖片添加至與所述電子憑證對應的展示位置;
其中,不同種類的電子憑證生成的展示圖片互不相同;不同種類的電子憑證對應的展示位置互不相同。
可選的,所述方法還包括:
在所述展示位置上標注獲取到的所述電子憑證的數(shù)量;
基于該電子憑證的實際剩余數(shù)量對該數(shù)量進行更新。
可選的,所述方法還包括:
當檢測到第一用戶針對任一展示圖片的預設觸發(fā)操作時,將與該展示圖片對應的電子憑證分享至由第一用戶選定的目標用戶。
可選的,所述方法還包括:
當所述服務端為所述第一用戶分配完成業(yè)務對象時,接收所述服務端發(fā)送的分配結果,并將所述分配結果向所述第一用戶展示;
其中,所述分配結果包括以下信息中的一個或者多個:
所述業(yè)務對象的數(shù)量、所述業(yè)務對象的發(fā)送方、所述業(yè)務對象的其它接收方的數(shù)量以及所述業(yè)務對象的分配規(guī)則。
根據(jù)本申請的第二方面,提出一種業(yè)務實現(xiàn)方法,包括:
接收第一用戶通過第一客戶端發(fā)送的對象分配請求;所述對象分配請求 中包含用于提取業(yè)務對象的若干電子憑證;
判斷所述對象分配請求中包含的電子憑證的類別數(shù)是否達到第一數(shù)量;
當所述對象分配請求中包含的電子憑證的類別數(shù)達到第一數(shù)量,基于預設分配規(guī)則從業(yè)務對象集合中為所述第一用戶分配業(yè)務對象。
可選的,所述方法還包括:
當接收到所述第一客戶端發(fā)送的用于獲取所述電子憑證的請求時,基于預設下發(fā)規(guī)則從本地存儲的電子憑證中向所述第一客戶端下發(fā)電子憑證;
其中,為所述第一客戶端下發(fā)的電子憑證的類別數(shù)小于所述第一數(shù)量。
可選的,所述基于預設下發(fā)規(guī)則向所述第一客戶端下發(fā)電子憑證,包括
從本地存儲的電子憑證中隨機向所述第一客戶端下發(fā)電子憑證。
可選的,所述本地存儲的電子憑證至少被預先劃分為低頻下發(fā)集合和高頻下發(fā)集合;
所述基于預設下發(fā)規(guī)則向所述第一客戶端下發(fā)電子憑證,包括
計算所述第一用戶的活躍度;
判斷所述活躍度是否達到預設閾值;
當所述活躍度達到預設閾值時,從所述低頻下發(fā)集合中向所述第一客戶端下發(fā)電子憑證;或者,
從所述低頻下發(fā)集合和高頻下發(fā)集合中向所述第一下發(fā)電子憑證;其中,下發(fā)的電子憑證中包括至少一個低頻下發(fā)集合中的電子憑證。
可選的,所述方法還包括:
當為所述第一用戶分配完成業(yè)務對象時,向所述第一客戶端發(fā)送分配結果,以使所述第一客戶端將所述分配結果向所述第一用戶展示;
其中,所述分配結果包括以下信息中的一個或者多個:
所述業(yè)務對象的數(shù)量、所述業(yè)務對象的發(fā)送方、所述業(yè)務對象的其它接收方的數(shù)量以及所述業(yè)務對象的分配規(guī)則。
根據(jù)本申請的第三方面,提出一種業(yè)務實現(xiàn)裝置,包括:
獲取模塊,用于獲取用于提取業(yè)務對象的電子憑證;
第一判斷模塊,用于判斷獲取到的電子憑證的類別數(shù)是否達到第一數(shù)量;
發(fā)起模塊,用于獲取到的電子憑證的類別數(shù)達到第一數(shù)量時,向服務端發(fā)起包含若干電子憑證并且包含的電子憑證的類別數(shù)為第一數(shù)量的對象分配請求,以使得所述服務端基于該對象分配請求從業(yè)務對象集合中為所述第一用戶分配業(yè)務對象。
可選的,所述獲取模塊具體用于:
獲取服務端為所述第一客戶端下發(fā)的電子憑證;以及
獲取第二用戶通過第二客戶端分享的電子憑證。
可選的,所述第一客戶端提供用于獲取電子憑證的觸發(fā)選項;
所述獲取模塊進一步用于:
當檢測到所述第一用戶針對所述觸發(fā)選項的觸發(fā)操作時,向所述服務端發(fā)起用于獲取所述電子憑證的請求,以使得所述服務端基于預設下發(fā)規(guī)則向所述第一客戶端下發(fā)電子憑證;
獲取所述服務端基于所述預設下發(fā)規(guī)則為所述第一客戶端下發(fā)的電子憑證;其中,所述服務端為所述第一客戶端下發(fā)的電子憑證的類別數(shù)小于所述第一數(shù)量。
可選的,所述裝置還包括:
生成模塊,用于在獲取到電子憑證時,為該電子憑證生成對應的展示圖片;
展示模塊,用于將生成的展示圖片添加至與所述電子憑證對應的展示位置;其中,不同種類的電子憑證生成的展示圖片互不相同;不同種類的電子憑證對應的展示位置互不相同。
可選的,所述生成模塊進一步用于:
在所述展示位置上標注獲取到的所述電子憑證的數(shù)量;
基于該電子憑證的實際剩余數(shù)量對該數(shù)量進行更新。
可選的,所述裝置還包括:
分享模塊,用于在檢測到第一用戶針對任一展示位置中添加的展示圖片 的預設觸發(fā)操作時,將與該展示圖片對應的電子憑證分享至由第一用戶選定的目標用戶。
可選的,所述裝置還包括:
第一接收模塊,用于在所述服務端為所述第一用戶分配完成業(yè)務對象時,接收所述服務端發(fā)送的分配結果,并將所述分配結果向所述第一用戶展示;
其中,所述分配結果包括以下信息中的一個或者多個:
所述業(yè)務對象的數(shù)量、所述業(yè)務對象的發(fā)送方、所述業(yè)務對象的其它接收方的數(shù)量以及所述業(yè)務對象的分配規(guī)則。
根據(jù)本申請的第四方面,提出一種業(yè)務實現(xiàn)裝置,包括:
第二接收模塊,用于接收第一用戶通過第一客戶端發(fā)送的對象分配請求;所述對象分配請求中包含用于提取業(yè)務對象的若干電子憑證;
第二判斷模塊,用于判斷所述對象分配請求中包含的電子憑證的類別數(shù)是否達到第一數(shù)量;
分配模塊,用于在所述對象分配請求中包含的電子憑證的類別數(shù)達到第一數(shù)量,基于預設分配規(guī)則從業(yè)務對象集合中為所述第一用戶分配業(yè)務對象。
可選的,所述裝置還包括:
下發(fā)模塊,用于在接收到所述第一客戶端發(fā)送的用于獲取所述電子憑證的請求時,基于預設下發(fā)規(guī)則從本地存儲的電子憑證中向所述第一客戶端下發(fā)電子憑證;
其中,為所述第一客戶端下發(fā)的電子憑證的類別數(shù)小于所述第一數(shù)量。
可選的,所述下發(fā)模塊具體用于:
從本地存儲的電子憑證中隨機向所述第一客戶端下發(fā)電子憑證。
可選的,所述本地存儲的電子憑證至少被預先劃分為低頻下發(fā)集合和高頻下發(fā)集合;
所述下發(fā)模塊具體用于:
計算所述第一用戶的活躍度;
判斷所述活躍度是否達到預設閾值;
當所述活躍度達到預設閾值時,從所述低頻下發(fā)集合中向所述第一客戶端下發(fā)電子憑證;或者,
從所述低頻下發(fā)集合和高頻下發(fā)集合中向所述第一下發(fā)電子憑證;其中,下發(fā)的電子憑證中包括至少一個低頻下發(fā)集合中的電子憑證。
可選的,所述裝置還包括:
發(fā)送模塊,用于在為所述第一用戶分配完成業(yè)務對象時,向所述第一客戶端發(fā)送分配結果,以使所述第一客戶端將所述分配結果向所述第一用戶展示;
其中,所述分配結果包括以下信息中的一個或者多個:
所述業(yè)務對象的數(shù)量、所述業(yè)務對象的發(fā)送方、所述業(yè)務對象的其它接收方的數(shù)量以及所述業(yè)務對象的分配規(guī)則。
由以上技術方案可見,本申請通過在對第一用戶分配業(yè)務對象時,第一用戶可以通過第一客戶端獲取用于提取業(yè)務對象的電子憑證,當獲取到的電子憑證類別數(shù)達到第一數(shù)量時,第一用戶可以取得業(yè)務對象的分配權限,通過第一客戶端向服務端發(fā)起對象分配請求使得服務端為第一用戶分配業(yè)務對象,從而可以提升業(yè)務分配過程中的趣味性,以及用戶的應用體驗。
附圖說明
圖1是根據(jù)本申請一示例性實施例中的一種業(yè)務實現(xiàn)方法的流程圖;
圖2-6是根據(jù)本申請一示例性實施例中的紅包發(fā)放的界面示意圖;
圖7是根據(jù)本申請一示例性實施例中的一種業(yè)務實現(xiàn)裝置的框圖;
圖8是根據(jù)本申請一示例性實施例中的一種電子設備的結構示意圖;
圖9是根據(jù)本申請一示例性實施例中的另一種業(yè)務實現(xiàn)裝置的框圖;
圖10是根據(jù)本申請一示例性實施例中的一種服務端的結構示意圖。
具體實施方式
圖1是根據(jù)本申請一示例性實施例中的一種業(yè)務實現(xiàn)方法的流程圖,如 圖1所示,該方法應用于客戶端和服務端中,客戶端和服務端相互配合可以執(zhí)行以下步驟:
步驟101,第一用戶通過第一客戶端收集用于提取業(yè)務對象的電子憑證;
步驟102,第一客戶端判斷收集到的電子憑證的類別數(shù)是否達到第一數(shù)量;
步驟103,當收集到的電子憑證的類別數(shù)達到第一數(shù)量時,向服務端發(fā)起包含若干電子憑證并且包含的電子憑證的類別數(shù)為第一數(shù)量的對象分配請求;
步驟104,服務端判斷所述對象分配請求中包含的電子憑證的類別數(shù)是否達到第一數(shù)量;
步驟105,當所述對象分配請求中包含的電子憑證的類別數(shù)達到第一數(shù)量,基于預設分配規(guī)則從業(yè)務對象集合中為所述第一用戶分配業(yè)務對象。
上述客戶端,可以包括電子設備上安裝的應用程序;例如,在“紅包”發(fā)放的應用場景中,上述客戶端可以包括電子設備上安裝的提供紅包發(fā)放功能的客戶端軟件;比如,支付寶;其中,在不同的場景下,上述客戶端可以為不同的客戶端軟件。
上述服務端,可以包括面向客戶端提供服務的服務器、服務器集群或者云平臺;例如,當上述客戶端為支付寶客戶端時,上述服務端可以是支付寶服務平臺。
上述業(yè)務對象,可以為任意形式的業(yè)務交互數(shù)據(jù)。作為一示例性實施例,上述業(yè)務對象可以包括虛擬物品,比如優(yōu)惠券、電子賀卡、禮金等。針對不同的業(yè)務實現(xiàn),上述虛擬物品包含的內容可以互不相同;例如,在支付業(yè)務中,上述業(yè)務對象可以是資金;在商家發(fā)起的商品活動業(yè)務時,上述業(yè)務對象可以是優(yōu)惠券,等等。上述業(yè)務對象集合是指第一用戶可提取的業(yè)務對象的集合;例如,當業(yè)務對象為通過紅包的形式所發(fā)放的資金時,上述業(yè)務對象集合可以是與紅包發(fā)放平臺合作的第三方企業(yè)的紅包發(fā)放賬戶。
上述第一用戶,可以是指業(yè)務對象的提取方。上述第一客戶端,可以是 指第一用戶在提取業(yè)務對象時所使用的客戶端。例如,當任一電子設備上安裝有上述客戶端,第一用戶在使用注冊賬號登錄該客戶端后,可以通過該客戶端與服務端進行交互來提取業(yè)務對象。
上述電子憑證,是指第一用戶向服務端提取業(yè)務對象時的憑證,在實際應用中,上述電子憑證的具體形式不進行限制,可以是字符串、數(shù)字、字符、口令、虛擬卡片,等等。服務端可以對第一用戶提交的電子憑證的內容、數(shù)量或者種類進行驗證,來確定第一用戶是否具備業(yè)務對象的提取權限,并在第一用戶具備提取權限時,從業(yè)務對象集合中為第一用戶分配業(yè)務對象。其中,每個電子憑證可以有對應的類別或者種類,每種類別的電子憑證可以代表一種類型的憑證,每一種類型的憑證可以具有相同或不同的內容。
在本例中,第一用戶可以通過第一客戶端來收集電子憑證,并在收集到的電子憑證的類別數(shù)達到第一數(shù)量時,來取得業(yè)務對象的分配權限。其中,上述類別數(shù)是指用戶收集到的電子憑證的種類數(shù),上述第一數(shù)量的具體取值在本申請中不進行限制,在實際應用中可以根據(jù)實際的需求來確定。
例如,在示出的一個例子中,上述業(yè)務對象可以是通過紅包的形式發(fā)放的資金,上述電子憑證可以是虛擬卡片,上述第一數(shù)量可以為5,當?shù)谝挥脩羰占降奶摂M卡片的類別數(shù)達到5,即當?shù)谝挥脩羰占?種不同種類的虛擬卡片時,則可以取得領取紅包的權限。
在本例中,第一用戶可以通過如下途徑來收集電子憑證;
收集途徑一:獲取服務器下發(fā)的電子憑證。
在本例中,第一用戶可以通過第一客戶端獲取由服務端下發(fā)的電子憑證。
在示出的一種實施方式中,在第一客戶端上可以提供一個用戶獲取電子憑證的觸發(fā)選項,用戶可以通過觸發(fā)該觸發(fā)選項來向服務端獲取電子憑證;例如,該觸發(fā)選項可以是第一客戶端上向用戶提供的一個觸發(fā)按鈕,或者活動入口,等等,用戶可以通過點擊、雙擊或者長按等觸發(fā)操作來觸發(fā)該觸發(fā)選項,向服務端獲取電子憑證。
當?shù)谝豢蛻舳嗽诤笈_檢測到用戶針對該觸發(fā)選項的觸發(fā)操作時,第一客 戶端可以向服務端發(fā)起用于獲取電子憑證的請求,服務端在收到該請求后,可以基于預設的下發(fā)規(guī)則從其本地存儲的電子憑證中向第一客戶端下發(fā)電子憑證。
其中,服務端在向第一客戶端下發(fā)電子憑證時,可以直接將電子憑證下發(fā)至第一客戶端,也可以僅向第一客戶端下發(fā)一個與電子憑證對應的唯一標識,并在本地保存上述唯一標識與電子憑證的對應關系,后續(xù)可以通過該唯一標識來識別對應的電子憑證;例如,假設電子憑證為一個字符串,那么服務端可以直接將作為電子憑證的字符串下發(fā)至第一客戶端,也可以為該字符串生成一個唯一對應的標識,將該標識下發(fā)至第一客戶端,其具體的下發(fā)形式在本實施例中不進行特別限定。
具體實現(xiàn)時,為了防止電子憑證被仿冒,服務端在為用戶生成電子憑證時,可以通過預設的加密算法對電子憑證進行加密;例如,以上述電子憑證為字符串為例,服務端在生成電子憑證時,可以通過預設的加密算法對生成的字符串進行加密,然后向用戶下發(fā)加密的字符串,在驗證用戶發(fā)送的字符串時,可以通過密鑰對收到的字符串進行解密,然后對解密后的字符串進行驗證。通過這種方式,可以避免電子憑證被用戶仿冒。
在本例中,服務端向第一客戶端下發(fā)的電子憑證的類別數(shù),可以小于上述第一數(shù)量,即服務端向第一客戶端下發(fā)的電子憑證的種類小于第一數(shù)量;例如,以上述電子憑證為虛擬卡片為例,假設用戶需要收集到5種不同種類的虛擬卡片才能夠獲得業(yè)務對象的分配權限,那么服務端在下用戶主動下發(fā)虛擬卡片時,下發(fā)的虛擬卡片的類別數(shù)可以是一個小于5類的數(shù)字,比如3類。通過這種方式,可以有效的對具有業(yè)務對象分配權項的用戶數(shù)量進行控制。
當然,服務端在向第一客戶端下發(fā)電子憑證時,除了以上描述的第一用戶可以通過觸發(fā)第一客戶端提供的觸發(fā)選項向服務端主動獲取電子憑證以外,也可以是由服務端主動下發(fā);例如,在示出的一種實現(xiàn)方式中,當?shù)谝挥脩敉ㄟ^注冊賬號成功登錄第一客戶端后,服務端可以主動向該第一客戶端下發(fā) 電子憑證。
另外,需要指出的是,服務端在向第一客戶端下發(fā)電子憑證使所采用的下發(fā)規(guī)則,可以根據(jù)實際的業(yè)務需求進行制定。
在示出的一種實施方式中,上述下發(fā)規(guī)則可以包括隨機下發(fā)。
在這種情況下,服務端在收到第一客戶端發(fā)起的獲取電子憑證的請求后,可以從本地存儲的電子憑證中隨機向第一客戶端下發(fā)電子憑證。
在示出的另一種實施方式中,上述下發(fā)規(guī)則可以包括針對特定人群有選擇的進行下發(fā)。
在這種情況下,服務端可以基于對本地存儲的電子憑證預先劃分為低頻下發(fā)集合和高頻下發(fā)集合。其中,低頻下發(fā)集合中的電子憑證可以用于面向由服務端指定的特定用戶進行下發(fā),而高頻下發(fā)集合中的電子憑證可以用于面向普通用戶進行下發(fā)。
在示出的一種實現(xiàn)方式中,上述特定用戶可以是指活躍度較高的用戶。服務端在下發(fā)電子憑證時,可以優(yōu)先為活躍度較高的用戶下發(fā)低頻下發(fā)集合中的電子憑證,而對于普通用戶則可以優(yōu)先下發(fā)高頻下發(fā)集合中的電子憑證。
在這種情況下,當服務端在向第一用戶下發(fā)電子憑證的時,可以在本地計算第一用戶的活躍度,然后將計算得到的活躍度與預設閾值進行比較來確定第一用戶是否為活躍用戶,如果第一用戶的活躍度達到預設閾值時,可以確定第一用戶為活躍用戶,此時可以從低頻下發(fā)集合中讀取下發(fā)憑證,然后下發(fā)給第一用戶。
例如,在一種實現(xiàn)方式中,當服務端確定第一用戶為活躍用戶時,可以僅從低頻下發(fā)集合中讀取電子憑證向第一用戶下發(fā)。在另一種實現(xiàn)方式中,當服務端確定第一用戶為活躍人群時,可以同時從低頻下發(fā)集合和高頻下發(fā)集合讀取電子憑證向第一用戶下發(fā),但此時需要保證下發(fā)的電子憑證中至少包括一個低頻下發(fā)集合中的電子憑證。而對于活躍度不高的普通用戶來說,服務端可以僅從高頻下發(fā)集合中向該用戶下發(fā)電子憑證。
通過這種方式,可以使得活躍度較高的用戶可以更容易的比較“少見” 的電子憑證,從而將業(yè)務對象的獲取權限向高活躍度的用戶傾斜。
其中,需要指出的是,服務端在計算第一用戶的活躍度時,該活躍度可以基于第一用戶日常的與用戶的活躍度相關的參數(shù)進行表征。例如,在實際應用中,當用戶的好友數(shù)量或者發(fā)起的業(yè)務數(shù)越多,表明該用戶越活躍。因此上述參數(shù)可以包括用戶的好友數(shù)量以及發(fā)起的業(yè)務數(shù)等參數(shù),服務端在計算第一用戶的活躍度時,可以統(tǒng)計第一用戶的好友數(shù)量,或者統(tǒng)計第一用戶發(fā)起的業(yè)務數(shù)量,然后進行閾值化處理,來判定該用戶是否為活躍用戶。
當然,在實際應用中,表征用戶活躍度的參數(shù)并不局限于以上描述的好友數(shù)量以及發(fā)起的業(yè)務數(shù)量,在實現(xiàn)時也使用其他可以表征用戶的活躍度的參數(shù)來計算用戶的活躍度。
收集途徑二:收集其它用戶分享的電子憑證
在本例中,第一用戶可以通過第一客戶端獲取由第二用戶通過第二客戶端分享的電子憑證。其中,該第二用戶可以是指相對于第一用戶而言的其它用戶。第二客戶端可以是與第一客戶端相同的客戶端。第二用戶在通過第二客戶端向第一用戶分享電子憑證時,可以通過客戶端內部進行分享,也可以通過將電子憑證轉發(fā)至第三方的客戶端,然后分享給第一用戶。
例如,在示出的一種實施方式中,以上述電子憑證為虛擬卡片為例,上述第一客戶端和上述第二客戶端均可以是支付寶客戶端,第一客戶端和第二客戶端上均可以提供分享接口,第二用戶可以通過自己的支付寶客戶端將虛擬卡片在支付寶客戶端內部分享給第一用戶,也可以將虛擬卡片通過支付寶客戶端提供的分享接口,以鏈接或者可點擊的圖文的形式分享至第三方的社交平臺,或者即時通信軟件,第一用戶在收到第二用戶分享的虛擬卡片后,可以通過點擊鏈接或者圖文然后跳轉到支付寶客戶端的界面中,來對第二用戶分享的虛擬卡片進行收取。
在本例中,第一客戶端在通過以上描述的兩種收集途徑,收集到的電子憑證時,可以為電子憑證生成對應的展示圖片,并在用戶界面向用戶展示。
其中,在該展示圖片上可以提供一收取選項;比如,當該電子憑證為虛 擬卡片時,該收取選項可以是“收取該卡片”的觸發(fā)選項,當?shù)谝挥脩敉ㄟ^點擊等觸發(fā)操作觸發(fā)該觸發(fā)選項后,第一客戶端可以將生成的該展示圖片添加至在第一客戶端的用戶界面中提供的展示位置上,以向第一用戶直觀的展示當前獲取到的電子憑證。
其中,第一客戶端為電子憑證生成的展示圖片可以與電子憑證的種類相對應,即不同種類的電子憑證所對應的展示圖片互不相同。上述展示圖片上展示的內容,不進行特別限制。同時,第一客戶端在用戶界面中提供的展示位置,也可以與電子憑證的種類相對應,不同的展示位置可以分別對應不同種類的電子憑證。
另外,第一客戶端在將生成的展示圖片添加到對應的展示位置后,還可以在該展示位置上標注當前獲取到的與該展示位置對應的電子憑證的數(shù)量,例如,可以在展示位的右上角生成一個數(shù)字提醒。而且,當某一種類的電子憑證的數(shù)量發(fā)生變化后,第一客戶端還可以基于當前該電子憑證的實際剩余數(shù)量對在與該電子憑證對應的展示位置上標注的數(shù)量進行更新。
在本例中,對于獲取到的電子憑證,還可以由第一用戶分享給其它用戶。
在示出的一種實施方式中,第一用戶可以通過觸發(fā)展示位置中添加的展示圖片,來將與該展示圖片對應的電子憑證分享給其它用戶。
例如,當?shù)谝挥脩粝胍獙δ骋活愲娮討{證進行分享,則可以通過點擊等觸發(fā)操作來觸發(fā)該電子憑證對應的展示位置,當展示位置觸發(fā)后,可以將與該展示位置對應的展示圖片顯示在用戶界面中。
此時,在該展示圖片中可以提供一分享選項,比如當該電子憑證為虛擬卡片時,該分享選項可以是一個“送一張給朋友”的觸發(fā)選項;當?shù)谝挥脩敉ㄟ^點擊等預設觸發(fā)操作觸發(fā)該觸發(fā)選項后,第一客戶端可以輸出一個分享方式的選擇界面,在該選擇界面中可以提供若干種可供第一用戶選擇的分享方式。此時用戶可以在該選擇界面中選擇分享方式,然后選擇本次要分享的目標用戶,當選擇完成后,第一客戶端可以將該電子憑證發(fā)送至用戶選擇的目標用戶。
其中,第一用戶在向目標用戶分享電子憑證時,如果目標用戶為第一用戶在第一客戶端中的聯(lián)系人或者好友時,第一用戶可以在第一客戶端內部將電子憑證分享給目標用戶。在這種情況下,第一客戶端可以通過服務端將需要分享的電子憑證傳輸至目標用戶的客戶端;例如,在一種方式中,第一客戶端可以將需要分享的電子憑證發(fā)送至服務端,再由服務端轉發(fā)至目標用戶的客戶端。在另一種方式中,第一用戶可以向服務端發(fā)送一個通知消息,告知服務端需要分享的電子憑證的id,由服務端向目標用戶重新下發(fā)對應的電子憑證。
當然,如果目標用戶并非為第一用戶在第一客戶端中的聯(lián)系人或者好友時,而是第一用戶在第三方的客戶端中的聯(lián)系人或者好友時,第一用戶也可以通過第三方的客戶端將電子憑證分享給目標用戶。
在這種情況下,第一客戶端可以通過服務端為需要分享的電子憑證生成一個對應的訪問鏈接,然后將生成的訪問鏈接通過第三方的客戶端分享給目標用戶。例如,以上述第一客戶端為支付寶客戶端,上述第三方的客戶端為第三方的社交平臺,或者即時通信軟件為例,支付寶客戶端可以通過服務端為需要分享的電子憑證生成一個對應的訪問鏈接或者可點擊的圖文,然后以鏈接或者圖文的形式分享至第三方的社交平臺,或者即時通信軟件,目標用戶在收到第一用戶分享的電子憑證后,可以通過點擊鏈接或者圖文訪問服務端上的電子憑證,然后跳轉到支付寶客戶端界面中來對該電子憑證進行收取。在本例中,第一用戶通過以上描述的兩種收集途徑收集到電子憑證后,第一客戶端可以在后臺實時的判斷當前收集到的電子憑證的種類是否達到第一數(shù)量,如果達到第一數(shù)量后,此時第一用戶已經可以獲得業(yè)務對象的分配權限,在這種情況下,第一客戶端可以向服務端發(fā)起對象分配請求,并在該對象分配請求中攜帶若干電子憑證。
其中,在示出的一種實施方式中,該對象分配請求中攜帶的電子憑證的數(shù)量和類別數(shù),可以均為上述第一數(shù)量,從而服務端在收到該對象分配請求后,可以獲取該對象分配請求中攜帶的電子憑證,然后進行驗證。
需要說明的是,第一客戶端向服務端發(fā)起對象分配請求的操作,可以由用戶手動觸發(fā),也可以是由第一客戶端在判斷出收集到的電子憑證的類別數(shù)達到第一數(shù)量時自動觸發(fā)。
例如,在一種情況下,當?shù)谝豢蛻舳嗽诤笈_判斷出收集到的電子憑證達到第一數(shù)量時,可以自動向服務端發(fā)起上述對象分配請求。在另一種情況下,可以在與各電子憑證對應的展示位置上,提供一個用于觸發(fā)第一客戶端向服務端發(fā)起對象分配請求的觸發(fā)按鈕(該觸發(fā)按鈕也可以是一個展示位置),當?shù)谝豢蛻舳嗽诤笈_判斷出收集到的電子憑證達到第一數(shù)量時,第一客戶端可以通過該觸發(fā)按鈕向用戶輸出提示,以提示用戶當前已經可以取得業(yè)務對象分配的權限,然后第一客戶端可以根據(jù)用戶針對該觸發(fā)按鈕的觸發(fā)操作,向服務端發(fā)起上述業(yè)務分配請求。
在本例中,如果服務端在對該對象分配請求中攜帶的電子憑證進行驗證后,判斷出該對象分配請求中攜帶的電子憑證的類別數(shù)達到第一數(shù)量,此時可以授予第一用戶分配業(yè)務對象的權限,并立即基于預設的分配規(guī)則從對應的業(yè)務對象集合中為第一用戶分配業(yè)務對象,或者在為本次業(yè)務對象的分配指定的分配時間到達后,基于預設的分配規(guī)則從對應的業(yè)務對象集合中為第一用戶分配業(yè)務對象。
其中,上述分配規(guī)則也可以基于實際的業(yè)務需求進行制定。
在示出的一種實施方式中,服務端可以統(tǒng)計所有授予了對象分配權限的用戶數(shù)量,并基于統(tǒng)計出的用戶數(shù)量計算業(yè)務對象集合中的業(yè)務對象的平均分配數(shù),此時計算出的該平均分配數(shù)即為需要向每一個用戶分配的業(yè)務對象的數(shù)量。在這種情況下,服務端可以基于計算得到的平均分配數(shù),從業(yè)務對象集合中為每一個用戶分配業(yè)務對象。
例如,以紅包發(fā)放業(yè)務為例,服務端可以統(tǒng)計所有獲得紅包領取權限的用戶數(shù)量,然后通過可發(fā)放的紅包總數(shù)除以具有紅包領取權限的用戶數(shù)量得到平均數(shù),然后為按照該平均數(shù)為每一個用戶發(fā)放對應金額的紅包。
在示出的另一種實施方式中,服務端在為第一用戶分配業(yè)務對象時,也 可以從業(yè)務對象集合中為第一用戶隨機抽取一定數(shù)量的業(yè)務對象。例如,服務端可以基于預設的隨機算法結合業(yè)務對象集合中業(yè)務對象的總數(shù)量,為第一用戶計算出一個隨機數(shù),然后按照該隨機數(shù)向用戶分配業(yè)務對象。
當然,除了以上示出的分配規(guī)則,在實際應用中還可以由其它分配規(guī)則,在本申請中不再一一列舉。
在本例中,當服務端為第一用戶分配業(yè)務對象完成后,還可以向第一用戶所在的第一客戶端發(fā)送一個分配結果,第一客戶端在收到該分配結果后,可以將該分配結果向用戶展示。
其中,該分配結果可以包括分配的業(yè)務對象的數(shù)量、業(yè)務對象的發(fā)送方、業(yè)務對象的其它接收方、其它接收方的數(shù)量以及業(yè)務對象的分配規(guī)則等信息中的一個或者多個。例如,以紅包發(fā)放業(yè)務為例,當服務端為第一用戶發(fā)放了紅包后,上述分配結果中向第一用戶展示的信息可以包括:紅包金額、紅包的發(fā)送方、紅包的其它接收者、其它接收者的數(shù)量以及紅包的分配規(guī)則等信息。
可見,在以上各實施例中,通過在對第一用戶分配業(yè)務對象時,第一用戶可以通過第一客戶端獲取用于提取業(yè)務對象的電子憑證,當獲取到的電子憑證類別數(shù)達到第一數(shù)量時,第一用戶可以取得業(yè)務對象的分配權限,通過第一客戶端向服務端發(fā)起對象分配請求使得服務端為第一用戶分配業(yè)務對象,從而可以提升業(yè)務分配過程中的趣味性,以及用戶的應用體驗。
以下結合具體的應用場景對以上實施例中的技術方案進行詳細描述。
在本申請中,圖1所示出的技術方案,可以在不同用戶之間實現(xiàn)不同的業(yè)務。例如,上述業(yè)務可以是紅包發(fā)放業(yè)務。
以下以上述業(yè)務為紅包發(fā)放業(yè)務為例并結合具體的應用場景進行說明。
在示出的一種應用場景中,上述業(yè)務可以是與紅包發(fā)放平臺合作的企業(yè)向用戶發(fā)放紅包的業(yè)務。
在這種應用場景中,上述客戶端可以是用戶的具有紅包功能的支付客戶端;比如,支付寶。上述服務端可以是指具有紅包發(fā)放功能支付平臺;例如 支付寶平臺。上述業(yè)務對象可以包括通過紅包的形式發(fā)放的資金。上述業(yè)務對象集合可以是指與支付平臺合作的企業(yè)的企業(yè)資金賬戶,該企業(yè)資金賬戶下的資金即為該企業(yè)可用于向用戶發(fā)放紅包的資金總額。上述電子憑證可以是紅包發(fā)放平臺用于確認用戶是否具有紅包領取權限的虛擬卡片。
在示出的一種“五福分大獎”的紅包發(fā)放的活動業(yè)務中,紅包發(fā)放平臺可用于向用戶下發(fā)的電子憑證可以包括“壽康?!?、“友愛福”、“國強?!薄ⅰ凹液透!币约啊柏斖!钡?類虛擬卡片,用戶收集到這5類虛擬卡片后,會相應的獲得領取由與支付平臺合作的企業(yè)發(fā)送的“五?!凹t包的權限。
請參見圖2,在用戶的客戶端中,可以提供一個活動入口,該活動入口具體可以是一個“迎五福領紅包”的活動界面,在該活動界面中可以提供一“獲取五??ㄆ庇|發(fā)選項,當用戶通過點擊等觸發(fā)操作觸發(fā)該選項后,支付客戶端可以向支付平臺發(fā)起獲取虛擬卡片的請求,支付平臺在收到該請求后,可以為用戶主動下發(fā)虛擬卡片。
其中,在以上5類虛擬卡片中,支付平臺可以設定一定數(shù)量種類的“少見”虛擬卡片,比如2類。這類“少見”虛擬卡片的發(fā)放與否取決于支付平臺基于用戶的數(shù)據(jù)計算出的該用戶的活躍度,即可以優(yōu)先將這類“少見”虛擬卡片發(fā)放給活躍度較高的用戶。支付平臺在針對普通用戶下發(fā)虛擬卡片時,可以默認僅為用戶下發(fā)“壽康?!?、“友愛?!?、“國強福”、“家和?!币约啊柏斖!钡?類虛擬卡片中的2~3類卡片。
在本例中,用戶除了可以獲取服務端主動下發(fā)的虛擬卡片以外,還可以獲取其它用戶分享的虛擬卡片。
其中,其它用戶在分享虛擬卡片時,可以采用相同的客戶端在客戶端內部進行分享,也可以通過客戶端將虛擬卡片以鏈接或者圖文的形式通過第三方的社交平臺或者即時通信客戶端進行分享。
在本例中,當用戶的客戶端獲取到虛擬卡片時,可以為該虛擬卡片生成一張對應的展示圖片,然后將該展示圖片在活動界面中展示。其中,客戶端 為不同種類的虛擬卡片生成的展示圖片上的內容互不相同。
請參見圖3,在將該展示圖片在活動界面中展示時,該展示圖片上可以提供一“領福啦”的觸發(fā)選項,用戶可以點擊等觸發(fā)操作觸發(fā)該選項,對該虛擬卡片進行收取,然后添加至客戶端提供的對應展示位置上。
其中,客戶端提供的展示位置可以與虛擬卡片的種類一一對應,每一種虛擬卡片可以分別對應一個展示位置。
請參見圖4,可以在活動界面中為“壽康?!薄ⅰ坝褠鄹!?、“國強?!薄ⅰ凹液透!币约啊柏斖!钡?類虛擬卡片分別提供一個展示位置,當客戶端將展示圖片添加至對應的展示位置后,客戶端還可以在該展示位置的預設位置(圖4示出的為右上角)上標注當前獲取到的該虛擬卡片的數(shù)量,同時當與該展示位置對應的虛擬卡片的數(shù)量發(fā)生變化時,客戶端還可以對該數(shù)量進行更新。
請繼續(xù)參見圖4,除了以上5種展示位置,在活動界面的虛擬卡片展示位置上,還可以提供一個“五福”的展示位置,在用戶未成功收集到“壽康福”、“友愛福”、“國強?!?、“家和?!币约啊柏斖!钡?類虛擬卡片的情況下,可以該“五?!闭故疚恢迷O置為灰色,以提示用戶當前未取得領取“五?!奔t包的權限。
在本例中,對于在展示位置上展示的虛擬卡片,還可以由用戶分享給其它用戶。
請參見圖4,當?shù)谟脩粝胍獙δ骋活愄摂M卡片進行分享,可以通過點擊等觸發(fā)操作來觸發(fā)該虛擬卡片對應的展示位置,當展示位置觸發(fā)后,可以將與該展示位置對應的展示圖片顯示在用戶界面中。
此時,在該展示圖片中可以提供一“送一張給朋友”的觸發(fā)選項;當用戶通過點擊等觸發(fā)操作觸發(fā)該觸發(fā)選項后,客戶端可以輸出一個分享方式的選擇界面,在該選擇界面中可以提供若干種可供第一用戶選擇的分享方式;比如,分享方式可以包括“通過微信發(fā)送給朋友”、“通過qq發(fā)送給朋友”以及“通過釘釘發(fā)送給朋友”等選項。
用戶可以在該選擇界面中選擇分享方式,當選擇完成后,用戶還可以在好友列表中指定要分享的目標用戶,然后由客戶端將該虛擬卡片以鏈接或者圖文的形式發(fā)送給該目標用戶。
當用戶通過獲取支付平臺下發(fā)的虛擬卡片,以及獲取其它好友分享的虛擬卡片,成功收集到“壽康福”、“友愛?!?、“國強?!?、“家和?!币约啊柏斖!钡?類虛擬卡片后,此時用戶已具有領取“五?!奔t包的權項。
請參見圖5,當用戶成功收集到“壽康?!薄ⅰ坝褠鄹!?、“國強?!?、“家和福”以及“財旺?!钡?類虛擬卡片后,可以將該“五?!闭故疚恢猛怀鲲@示,比如高亮顯示,以提示用戶當前已具有領取“五?!奔t包的權限。
當用戶獲取到領取“五福”紅包的權限后,用戶可以通過手動觸發(fā)該“五?!闭故疚恢?,觸發(fā)客戶端向支付平臺發(fā)送紅包分配請求,或者由客戶端自動向支付平臺發(fā)送紅包分配請求。此時,該紅包分配請求中可以攜帶已經收集到的5種虛擬卡,支付平臺收到該請求后,可以對該請求中虛擬卡的種類進行驗證,如果支付平臺驗證后確定該請求中攜帶5種虛擬卡,支付平臺可以立即從合作的企業(yè)的企業(yè)資金賬戶中為該用戶發(fā)放一定金額的“紅包”,或者在發(fā)放時間到達時向用戶發(fā)送一定金額的“紅包”。例如,支付平臺可以將統(tǒng)計所有獲得領取“五福”紅包權限的用戶的數(shù)量,然后平均分配企業(yè)資金賬戶中可用于發(fā)放的紅包金額。
當用戶領取“紅包”后,支付平臺可以向客戶端推送一個紅包發(fā)放結果,客戶端在收到該發(fā)放結果后,可以在活動界面中向用戶展示。
請參見圖6,在該紅包發(fā)放結果中展示的信息可以包含本次領取到的金額,本次紅包的發(fā)送者(與支付平臺合作的企業(yè)名稱),本次領取“五?!奔t包的總人數(shù),本次“五?!奔t包的分配規(guī)則(圖7示出的分配規(guī)則為平均分配),等等。
可見,當圖1所示出的技術方案應用在紅包發(fā)放的應用場景中時,用戶可以通過收集到一定數(shù)量的電子憑證來取得紅包領取權限,從而可以提升紅包發(fā)放的趣味性,提升用戶的體驗。
與以上方法實施例對應,本申請還提供了裝置實施例。
請參見圖7,本申請?zhí)岢鲆环N業(yè)務實現(xiàn)裝置70,應用于電子設備;其中,請參見圖8,作為承載所述業(yè)務實現(xiàn)裝置70的終端所涉及的硬件架構中,通常包括cpu、內存、非易失性存儲器、網(wǎng)絡接口以及內部總線等;以軟件實現(xiàn)為例,所述業(yè)務實現(xiàn)裝置70通??梢岳斫鉃榧虞d在內存中的計算機程序,通過cpu運行之后形成的軟硬件相結合的邏輯裝置,所述裝置70包括:
獲取模塊701,用于獲取用于提取業(yè)務對象的電子憑證;
第一判斷模塊702,用于判斷獲取到的電子憑證的類別數(shù)是否達到第一數(shù)量;
發(fā)起模塊703,用于獲取到的電子憑證的類別數(shù)達到第一數(shù)量時,向服務端發(fā)起包含若干電子憑證并且包含的電子憑證的類別數(shù)為第一數(shù)量的對象分配請求,以使得所述服務端基于該對象分配請求從業(yè)務對象集合中為所述第一用戶分配業(yè)務對象。
在本例中,所述獲取模塊701具體用于:
獲取服務端為所述第一客戶端下發(fā)的電子憑證;以及
獲取第二用戶通過第二客戶端分享的電子憑證。
在本例中,所述第一客戶端提供用于獲取電子憑證的觸發(fā)選項;
所述獲取模塊701進一步用于:
當檢測到所述第一用戶針對所述觸發(fā)選項的觸發(fā)操作時,向所述服務端發(fā)起用于獲取所述電子憑證的請求,以使得所述服務端基于預設下發(fā)規(guī)則向所述第一客戶端下發(fā)電子憑證;
獲取所述服務端基于所述預設下發(fā)規(guī)則為所述第一客戶端下發(fā)的電子憑證;其中,所述服務端為所述第一客戶端下發(fā)的電子憑證的類別數(shù)小于所述第一數(shù)量。
在本例中,所述裝置70還包括:
生成模塊704,用于在獲取到電子憑證時,為該電子憑證生成對應的展示圖片;
展示模塊705,用于將生成的展示圖片添加至與所述電子憑證對應的展示位置;其中,不同種類的電子憑證生成的展示圖片互不相同;不同種類的電子憑證對應的展示位置互不相同。
在本例中,所述生成模塊704進一步用于:
在所述展示位置上標注獲取到的所述電子憑證的數(shù)量;
基于該電子憑證的實際剩余數(shù)量對該數(shù)量進行更新。
在本例中,所述裝置70還包括:
分享模塊706,用于在檢測到第一用戶針對任一展示位置中添加的展示圖片的預設觸發(fā)操作時,將與該展示圖片對應的電子憑證分享至由第一用戶選定的目標用戶。
在本例中,所述裝置70還包括:
第一接收模塊707,用于在所述服務端為所述第一用戶分配完成業(yè)務對象時,接收所述服務端發(fā)送的分配結果,并將所述分配結果向所述第一用戶展示;
其中,所述分配結果包括以下信息中的一個或者多個:
所述業(yè)務對象的數(shù)量、所述業(yè)務對象的發(fā)送方、所述業(yè)務對象的其它接收方的數(shù)量以及所述業(yè)務對象的分配規(guī)則。
請參見圖9,本申請?zhí)岢鲆环N業(yè)務實現(xiàn)裝置90,應用于服務端;其中,請參見圖10,作為承載所述業(yè)務實現(xiàn)裝置90的服務端所涉及的硬件架構中,通常包括cpu、內存、非易失性存儲器、網(wǎng)絡接口以及內部總線等;以軟件實現(xiàn)為例,所述業(yè)務實現(xiàn)裝置90通??梢岳斫鉃榧虞d在內存中的計算機程序,通過cpu運行之后形成的軟硬件相結合的邏輯裝置,所述裝置90包括:
第二接收模塊901,用于接收第一用戶通過第一客戶端發(fā)送的對象分配請求;所述對象分配請求中包含用于提取業(yè)務對象的若干電子憑證;
第二判斷模塊902,用于判斷所述對象分配請求中包含的電子憑證的類別數(shù)是否達到第一數(shù)量;
分配模塊903,用于在所述對象分配請求中包含的電子憑證的類別數(shù)達 到第一數(shù)量,基于預設分配規(guī)則從業(yè)務對象集合中為所述第一用戶分配業(yè)務對象。
在本例中,所述裝置90還包括:
下發(fā)模塊904,用于在接收到所述第一客戶端發(fā)送的用于獲取所述電子憑證的請求時,基于預設下發(fā)規(guī)則從本地存儲的電子憑證中向所述第一客戶端下發(fā)電子憑證;
其中,為所述第一客戶端下發(fā)的電子憑證的類別數(shù)小于所述第一數(shù)量。
在本例中,所述下發(fā)模塊904具體用于:
從本地存儲的電子憑證中隨機向所述第一客戶端下發(fā)電子憑證。
在本例中,所述本地存儲的電子憑證至少被預先劃分為低頻下發(fā)集合和高頻下發(fā)集合;
所述下發(fā)模塊904具體用于:
計算所述第一用戶的活躍度;
判斷所述活躍度是否達到預設閾值;
當所述活躍度達到預設閾值時,從所述低頻下發(fā)集合中向所述第一客戶端下發(fā)電子憑證;或者,
從所述低頻下發(fā)集合和高頻下發(fā)集合中向所述第一下發(fā)電子憑證;其中,下發(fā)的電子憑證中包括至少一個低頻下發(fā)集合中的電子憑證。
在本例中,所述裝置90還包括:
發(fā)送模塊905,用于在為所述第一用戶分配完成業(yè)務對象時,向所述第一客戶端發(fā)送分配結果,以使所述第一客戶端將所述分配結果向所述第一用戶展示;
其中,所述分配結果包括以下信息中的一個或者多個:
所述業(yè)務對象的數(shù)量、所述業(yè)務對象的發(fā)送方、所述業(yè)務對象的其它接收方的數(shù)量以及所述業(yè)務對象的分配規(guī)則。
以上所述僅為本申請的較佳實施例而已,并不用以限制本申請,凡在本申請的精神和原則之內,所做的任何修改、等同替換、改進等,均應包含在 本申請保護的范圍之內。