CN114205406B

CN114205406B - Red packet receiving and sending method, device, equipment and storage medium

Info

Publication number: CN114205406B
Application number: CN202111484404.9A
Authority: CN
Inventors: 黄俏丹; 张海峰; 林洋; 王桢
Original assignee: CCB Finetech Co Ltd
Current assignee: CCB Finetech Co Ltd
Priority date: 2021-12-07
Filing date: 2021-12-07
Publication date: 2023-06-30
Anticipated expiration: 2041-12-07
Also published as: CN114205406A

Abstract

The invention relates to the technical field of mobile interconnection and discloses a red packet receiving and sending method, a device, equipment and a storage medium. According to the technical scheme, scene induction is carried out on multiple scenes of the red packet, red packet products are rapidly developed for different scenes according to scene identifiers, batch red packets meeting the conditions are generated, the batch red packets can be shared according to a sharing mode corresponding to the batch identifiers and can be picked according to a picking mode corresponding to the batch identifiers, and therefore unified red packet interfaces are achieved, and development and maintenance costs of a server side and a client side are greatly reduced.

Description

Red packet receiving and sending method, device, equipment and storage medium

Technical Field

The present invention relates to the field of mobile interconnection technologies, and in particular, to a method, an apparatus, a device, and a storage medium for sending and receiving a red packet.

Background

In recent years, with the innovation of financial models, innovative forms of red packages are diversified.

The existing method is that a server develops a set of red packet sending and receiving interfaces according to each scene, a client terminal is used for debugging and accessing different interfaces of different scenes, each red packet interface is similar but not identical, development and maintenance cost is extremely high, and debugging and accessing are time-consuming and labor-consuming. For the server side, the simultaneous release of multiple product interfaces also has great maintenance cost, which is unfavorable for daily upgrade and operation and maintenance.

Disclosure of Invention

The invention provides a red packet receiving and sending method, a red packet receiving and sending device, red packet receiving and sending equipment and a storage medium, so that unified red packet interfaces are realized, and development and maintenance costs of a server side and a client side are reduced.

In a first aspect, an embodiment of the present invention provides a method for sending and receiving a red packet, which is applied to a first server, and includes:

generating a scene identification from a scene received from a first client;

generating a batch of red packets according to the scene identification and returning batch identifications corresponding to the batch of red packets to the first client so that the first client shares the red packets according to the batch identifications; the batch of red packets includes at least one red packet;

And after receiving the batch identification sent by the second client, locking the red package according to the batch identification and returning the batch identification to the second client so that the second client can receive the locked red package.

In a second aspect, an embodiment of the present invention further provides another method for sending and receiving a red packet, which is applied to a first client, and includes:

receiving a scene input by a user, and sending the scene to a first server side so that the first server side generates a scene identifier according to the scene received from the first client side and generates a batch of red packets according to the scene identifier;

and receiving a batch identifier corresponding to the batch red package returned by the first server side, and sharing the red package according to the batch identifier.

In a third aspect, an embodiment of the present invention further provides another method for sending and receiving a red packet, which is applied to a second client, and includes:

after receiving the receiving message, obtaining a batch identifier, and uploading the batch identifier to a first server side, so that the first server side locks a red packet according to the batch identifier and returns the batch identifier to a second client side;

and (5) taking the locked red packet.

In a fourth aspect, an embodiment of the present invention further provides a red packet transceiver, which is applied to a first server, and includes:

The scene identification generation module is used for generating a scene identification according to the scene received from the first client;

the batch red package generation module is used for generating batch red packages according to the scene identification and returning batch identifications corresponding to the batch red packages to the first client so that the first client can share the red packages according to the batch identifications; the batch of red packets includes at least one red packet;

and the red package locking module is used for locking the red package according to the batch identifier after receiving the batch identifier sent by the second client and returning the batch identifier to the second client so as to lead the second client to get the locked red package.

In a fifth aspect, an embodiment of the present invention further provides another red packet transceiver, applied to a first client, including:

the sending module is used for receiving the scene input by the user, sending the scene to the first server side, enabling the first server side to generate a scene identifier according to the scene received from the first client side, and generating a batch of red packets according to the scene identifier;

and the sharing module is used for receiving the batch identification corresponding to the batch red packets returned by the first server side and carrying out corresponding red packet sharing according to the batch identification.

In a sixth aspect, an embodiment of the present invention further provides another red packet transceiver, applied to a second client, including:

The sending module is used for obtaining the batch identifier after receiving the receiving message, and sending the batch identifier to the first server side so that the first server side locks the red packet according to the batch identifier and returns the batch identifier to the second client side;

and the receiving module is used for receiving the locked red packet.

In a seventh aspect, an embodiment of the present invention further provides a red packet transceiver device, where the red packet transceiver device includes:

one or more processors;

a storage means for storing one or more programs;

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any of the first, second, and third aspects.

In an eighth aspect, embodiments of the present invention further provide a computer readable storage medium having stored thereon a computer program which when executed by a processor implements a method as in any of the first, second and third aspects.

In a ninth aspect, embodiments of the present invention also provide a computer program product comprising computer executable instructions for implementing the method as in any of the first, second and third aspects when executed.

According to the red package receiving and dispatching method, device, equipment, storage medium and computer program product, scene identification is generated according to the scene received from the first client, batch red packages are generated according to the scene identification, batch identifications corresponding to the batch red packages are returned to the first client, so that the first client can share the red packages according to the batch identifications, after receiving the batch identifications sent by the second client, the red packages are locked according to the batch identifications, the batch identifications are returned to the second client, and the second client can receive the locked red packages, wherein the batch identifications comprise the scene identifications. According to the technical scheme, scene induction is carried out on multiple scenes of the red packet, each scene corresponds to a scene identifier, then red packet products are rapidly developed according to the scene identifiers for different scenes, batch red packets meeting the conditions are generated, the batch red packets can be shared according to a sharing mode corresponding to the batch identifiers and are received according to a receiving mode corresponding to the batch identifiers, and therefore unified red packet interfaces are achieved, and development and maintenance costs of a server side and a client side are greatly reduced.

Drawings

Fig. 1 is a flowchart of a red packet transceiving method according to an embodiment of the present invention;

FIG. 2 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention;

FIG. 3 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention;

FIG. 4 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention;

FIG. 5 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention;

FIG. 6 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention;

FIG. 7 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention;

FIG. 8 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention;

FIG. 9 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention;

fig. 10 is a schematic structural diagram of a red packet transceiver according to an embodiment of the present invention;

fig. 11 is a schematic structural diagram of another red packet transceiver according to an embodiment of the present invention;

fig. 12 is a schematic structural diagram of another red packet transceiver according to an embodiment of the present invention;

fig. 13 is a schematic structural diagram of a red packet transceiver according to an embodiment of the present invention.

Detailed Description

The invention is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting thereof. It should be further noted that, for convenience of description, only some, but not all of the structures related to the present invention are shown in the drawings.

The embodiment of the invention provides a red packet receiving and transmitting method, and fig. 1 is a flowchart of the red packet receiving and transmitting method provided by the embodiment of the invention, and the embodiment is applicable to the situation of receiving and transmitting red packets in multiple scenes, and the method is applied to a first server side, and can be executed by a red packet receiving and transmitting device, which can be implemented in a software and/or hardware mode, and can be configured at the first server side. Referring to fig. 1, the method specifically includes the steps of:

step 110, generating a scene identifier according to the scene received from the first client.

Wherein the first client may be a client used by the red envelope initiator. The red package initiator may select a scenario at the first client, where the scenario may include a format of the red package (i.e., in which format the red package is displayed), a distribution manner of the red package (i.e., how the amount of money in the red package is distributed), a sharing manner of the red package (i.e., in which manner the red package is shared out), and a receiving manner of the red package (i.e., in which manner the red package is received). Optionally, the format of the red packet includes a logo page text blessing red packet, a video blessing red packet, and a voice blessing red packet. The distribution mode of the red packet comprises a fixed distribution mode, a random distribution mode and a self-defined distribution mode; under the fixed distribution mode, the amount of each red packet is equal; under the random distribution mode, the amount of each red packet is random; under the self-defined allocation mode, the amount of each red packet is allocated according to the self-defined mode. The sharing mode comprises a link sharing mode and an air sharing mode; in the link sharing mode, the first client generates a receiving link when sharing the red packet, and in the air sharing mode, the red packet scattering range needs to be selected at the first client, so that the second client in the selected range can receive the red packet. The receiving mode comprises a direct receiving mode, an AR red packet receiving mode, a face brushing and color measurement value receiving mode, a password answering receiving mode, a game running receiving mode and a lottery card turning receiving mode.

The red packet initiator selects the above scenes through the first client, and the first client can send the received scenes to the first server, where each scene can correspond to a scene identifier in the first server. Each scene may include a plurality of sub-scenes, for example, when the scene includes a format of a red packet, a distribution manner of the red packet, a sharing manner of the red packet, and a retrieval manner of the red packet, the format of the red packet, the distribution manner of the red packet, the sharing manner of the red packet, and the retrieval manner of the red packet are respectively one sub-scene, and each scene includes 4 sub-scenes. In this step, the scene identifier may be obtained according to the received scene.

Optionally, the scene identifier includes a format identifier, an allocation mode identifier, a sharing mode identifier, and a retrieval mode identifier. After the scene identification is determined, the red packet scene corresponding to the scene identification can be determined, namely, the format of the red packet, the distribution mode of the red packet, the sharing mode of the red packet and the receiving mode of the red packet can be obtained according to the scene identification.

Optionally, the format identifiers include a first format identifier, a second format identifier and a third format identifier, the first format identifier is used for identifying the page text blessing red packet, the second format identifier is used for identifying the video blessing red packet, and the third format identifier is used for identifying the voice blessing red packet.

Optionally, the allocation mode identifier includes a first allocation mode identifier, a second allocation mode identifier and a third allocation mode identifier, where the first allocation mode identifier is used to identify a fixed allocation mode, the second allocation mode identifier is used to identify a random allocation mode, and the third allocation mode identifier is used to identify a custom allocation mode;

optionally, the sharing mode identifier includes a first sharing mode identifier and a second sharing mode identifier, where the first sharing mode identifier is used to identify a link sharing mode, and the second sharing mode identifier is used to identify a sharing mode scattered in the air.

Optionally, the retrieval mode identifier includes a first retrieval mode identifier, a second retrieval mode identifier, a third retrieval mode identifier, a fourth retrieval mode identifier, a fifth retrieval mode identifier and a sixth retrieval mode identifier, where the first retrieval mode identifier is used to identify a direct retrieval mode, the second retrieval mode identifier is used to identify an AR red packet retrieval mode, the third retrieval mode identifier is used to identify a face brushing and color measurement value retrieval mode, the fourth retrieval mode identifier is used to identify a password retrieval mode, the fifth retrieval mode identifier is used to identify a running game retrieval mode, and the sixth retrieval mode identifier is used to identify a lottery card turning retrieval mode.

The scene identification is taken as a scene number, one bit in the scene number is taken as a format identification, the shift is taken as an allocation mode identification, one bit in the scene number is taken as a sharing mode identification, and one bit in the scene number is taken as a retrieval mode identification for illustration, so that when each scene comprises 4 sub-scenes, one bit in the scene number can be corresponding to each sub-scene, and the scene number is 4 bits. Illustratively, the first digit in the scene number represents the format of the red packet, illustratively, 0 represents the page text blessing red packet, 1 represents the video blessing red packet, 2 represents the voice blessing red packet; the second bit in the scene number represents the distribution mode of the red packet, and by way of example, 0 represents a fixed distribution mode, 1 represents a random distribution mode, and 2 represents a self-defined distribution mode; the third bit in the scene number represents the sharing mode of the red packet, and by way of example, 0 represents the link sharing mode and 1 represents the sharing mode scattered in the air; the fourth bit in the scene number represents a red packet receiving mode, and by way of example, 0 represents a direct receiving mode, 1 represents an AR red packet receiving mode, 2 represents a face-brushing face-measuring value receiving mode, 3 represents a response password receiving mode, 4 represents a rushing game receiving mode, and 5 represents a raffle turning card receiving mode. When the first server side generates the scene identifier according to the received scene, the first server side can generate the scene identifier in a bitmap mode.

Step 120, generating a batch of red packets according to the scene identifier and returning a batch identifier corresponding to the batch of red packets to the first client so that the first client shares the red packets according to the batch identifier; the batch of red packets includes at least one red packet.

After the scene identifier is generated, a batch of red packets in the scene corresponding to the scene identifier can be generated, wherein the batch of red packets comprises at least one red packet, and generally, the batch of red packets comprises at least two red packets. Still taking step 110, the scene identifier includes scene numbers, and each scene includes 4 sub-scenes, for example, when the generated scene number is 0000, the generated batch of red packages are all text blessing red packages, fixed amount (corresponding to a fixed allocation mode), link sharing, and direct pickup. After the batch red packet is generated, the first server side can send the batch red packet to the first client side to generate a successful data stream, wherein the data stream can be in a message form, and a batch identifier corresponding to the batch red packet is returned to the first client side. Wherein the lot identification comprises a scene identification. Specifically, the scene identifier includes a sharing manner of the red package, so the batch identifier also includes a sharing manner of the red package, and therefore, the first client determines the sharing manner according to the batch identifier, or the first client performs the sharing action of the red package according to the sharing manner selected by the user when the user selects the scene.

And 130, after receiving the batch identification sent by the second client, locking the red package according to the batch identification and returning the batch identification to the second client so that the second client can pick up the locked red package.

Wherein the second client may be a client used by the red envelope retriever. After the first client shares the red packets, the second client acquires the batch identifiers corresponding to the batch red packets, sends the acquired batch identifiers to the first server, locks at least one of the batch red packets corresponding to the batch identifiers according to the batch identifiers, and returns the batch identifiers to the second client, so that the second client can obtain the locked red packets according to the batch identifiers. Specifically, the scene identifier includes a red packet retrieving mode, so the batch identifier also includes a red packet retrieving mode, and therefore, the second client determines the retrieving mode according to the batch identifier and retrieves the red packet.

According to the red package receiving and dispatching method, scene identification is generated according to a scene received from a first client, a batch of red packages are generated according to the scene identification, batch identifications corresponding to the batch of red packages are returned to the first client, so that the first client can share the red packages according to the batch identifications, after receiving the batch identifications sent by a second client, the red packages are locked according to the batch identifications, the batch identifications are returned to the second client, and the second client can receive the locked red packages, wherein the batch identifications comprise the scene identifications. According to the technical scheme, scene induction is carried out on multiple scenes of the red packet, each scene corresponds to a scene identifier, then red packet products are rapidly developed according to the scene identifiers for different scenes, batch red packets meeting the conditions are generated, the batch red packets can be shared according to a sharing mode corresponding to the batch identifiers and are received according to a receiving mode corresponding to the batch identifiers, and therefore unified red packet interfaces are achieved, and development and maintenance costs of a server side and a client side are greatly reduced.

Fig. 2 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention, referring to fig. 2, optionally, the method for sending and receiving red packets includes:

step 210, generating a scene identifier according to a scene received from a first client; the procedure of the step 110 is the same as that of the step 110 in the above embodiment, and will not be described again here;

step 220, generating a batch identifier with a set format according to the scene identifier.

Optionally, the lot identification in the set format includes a scene identification, a global running water identification, and an equipment terminal verification identification, where the global running water identification is used to identify a transaction corresponding to the lot red packet, and the equipment terminal verification identification is used to identify an equipment terminal for installing the first client. One transaction corresponds to a global running water identifier, and the global running water identifiers corresponding to different transactions are different. The device terminal check identifiers are in one-to-one correspondence with the device terminals, and the device terminal check identifiers corresponding to different device terminals are different. The global serial number can be a global serial number identified by a number, and the device terminal check identifier can be a device terminal check code identified by a number.

Optionally, the step 220 includes: and generating a batch identifier in a set format according to the scene identifier and the equipment terminal check identifier received from the first client. Specifically, when the first client sends a scene to the first server, the first client can also send a corresponding device terminal check identifier to the first server, and when the device terminal check identifier is matched with the set check identifier, the first server generates a batch identifier in a set format according to the scene identifier, the device terminal check identifier and the automatically generated global running water identifier. When the equipment terminal check mark is not matched with the set check mark, the first server side does not generate a batch mark, and correspondingly, does not generate a batch red packet. The set check marks can include a plurality of check marks, and the set check marks can include device terminal check marks corresponding to the device terminals, which are allowed to initiate the red packet and are provided with the first client. By judging whether the equipment terminal check mark is matched with the set check mark, the red package initiating action can be properly carried out through the first client side on the equipment terminal which is not compliant, and the safety of the red package initiating is ensured. The batch identifier with the set format can be a scene identifier, a global pipeline identifier and an equipment terminal verification identifier in sequence.

Step 230, generating a batch of red packets according to the distribution mode corresponding to the batch identification, registering a red packet information table, and deducting money according to the red packet information table so that the first client performs corresponding sharing actions according to the sharing mode corresponding to the batch identification;

the red packet information table comprises the total amount of red packets, the total number of red packets, the residual number of red packets and the distribution mode.

Specifically, because the lot identifier includes the scene identifier, the scene identifier includes the distribution mode of the red packets, after the distribution mode is determined, the lot red packets can be generated, and the amount of each red packet in the generated lot red packets is related to the distribution mode, for example, when the distribution mode is a fixed distribution mode, the amount of each red packet is equal; when the distribution mode is a random distribution mode, the amount of each red packet is random. After the batch of red packets are generated, registering a red packet information table, wherein the red packet information table comprises the total amount of the red packets, and when the payment is paid according to the red packet information table, the payment can be paid according to the total amount of the red packets in the red packet information table. The red packet information table may also include red packet initiator information and generation time of batch red packets. In other alternative embodiments of the present invention, a server side for executing the deduction action may be further provided, and the embodiment is not limited herein.

Step 240, after receiving the batch identifier sent by the second client, locking the red packet according to the batch identifier and returning the batch identifier to the second client so that the second client can pick up the locked red packet; this step is the same as the step 130 in the above embodiment, and will not be described here again.

Fig. 3 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention, referring to fig. 3, optionally, the method for sending and receiving red packets includes:

step 310, generating a scene identifier according to the scene received from the first client; the procedure of the step 110 is the same as that of the step 110 in the above embodiment, and will not be described again here;

step 320, generating a batch identifier with a set format according to the scene identifier; this step is the same as the step 220 in the above embodiment, and will not be described here again.

And 330, generating a batch of red packets according to the first distribution mode identification in the batch identification, registering a red packet information table, and deducting money according to the red packet information table so that the first client shares the red packets according to the batch identification.

The first allocation method identifier is used for identifying a fixed allocation method, so that the amount of each red packet in the batch of red packets generated according to the first allocation identifier in the batch identifier is fixed and the same, and when the red packet information table is registered, the fixed amount of each red packet in the batch of red packets is required to be recorded in the red packet information table. Because the batch identifier comprises the scene identifier, the scene identifier comprises the sharing mode identifier, and the first client can share the red package according to the sharing mode identifier in the batch identifier.

Step 340, after the second client obtains the batch identifier, when the red packet is not robbed, any available red packet is locked according to the first allocation mode identifier in the batch identifier.

After the first client performs red package sharing, the second client can receive the receiving link when the sharing mode is a link sharing mode, and can receive the red package shaking message when the sharing mode is an air sharing mode. The retrieval link may carry a lot identifier, and when the user clicks the retrieval link, the second client may obtain the lot identifier. When the user shakes the red packet through the second client, the batch identification corresponding to the batch red packet to which the shake-up red packet belongs can be obtained. After the second client obtains the batch identifier, when the red packets are not robbed, and when the distribution mode identifier included in the batch identifier is the first distribution mode identifier, the distribution mode of the red packets can be determined to be a fixed distribution mode according to the first distribution mode identifier, so that the red packet amount of each red packet is the same, and any available red packet can be locked.

Step 350, inserting a red packet pickup flow water meter.

The red packet retrieval flow list comprises a retriever identifier, a retrieval amount, a retrieval time and a retrieval terminal identifier, namely, in the step, the retriever identifier, the retrieval amount, the retrieval time and the retrieval terminal identifier are inserted into the red packet retrieval flow list.

And step 360, updating the remaining number in the red packet information table.

Specifically, after the red packet is locked, the remaining number in the red packet level table needs to be updated, for example, when one red packet is locked, the remaining number in the red packet information table is reduced by 1, and when two red packets are locked, the remaining number in the red packet information table is reduced by 2.

Step 370, returning the batch identifier to the second client, so that the second client can get the locked red packet.

And after the batch identification is returned to the second client, the second client enters a corresponding retrieval interface according to a retrieval mode corresponding to the batch identification. When the receiving mode identifier included in the batch identifier is an inter-game receiving mode, the second client enters a game interface, and the user receives the locked red package after playing the game.

Fig. 4 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention, referring to fig. 4, optionally, the method for sending and receiving red packets includes:

step 410, generating a scene identifier according to a scene received from a first client; the procedure of the step 110 is the same as that of the step 110 in the above embodiment, and will not be described again here;

step 420, generating a batch identifier with a set format according to the scene identifier; this step is the same as the step 220 in the above embodiment, and will not be described here again.

Step 430, generating a batch red packet according to the second distribution formula identifier or the third distribution identifier in the batch identifier, and recording a red packet distribution table.

The second distribution mode identifier is used for identifying a random distribution mode, and the third distribution mode identifier is used for identifying a self-defined distribution mode, so that the amount of each red packet in the batch red packets generated according to the second distribution identifier in the batch identifier is random; and according to the third distribution mode identification in the batch identification, the amount of each red packet in the generated batch red packets is distributed in a self-defined mode. The user may define a specific allocation manner of the custom allocation manner after selecting the custom allocation manner by the first client, and may define that a portion of the red packets in the batch of red packets are equal in fixed amount, and another portion of the red packets are random in amount. When the batch identifier comprises a second allocation identifier, the corresponding allocation mode is a random allocation mode; when the batch identifier comprises the third allocation identifier, the corresponding allocation mode is a self-defined allocation mode. When the distribution mode is a random distribution mode or a custom distribution mode, the amount of each red packet in the batch of red packets can be unequal, so that the red packet distribution table is also required to be recorded, and the red packet distribution table comprises the red packet serial numbers, the red packet amounts and the acquisition states of the red packets in the batch of red packets.

And 440, registering the red packet information table, and deducting money according to the red packet information table so that the first client side shares the red packet according to the batch identification.

The red packet information table comprises the total amount of the batch of red packets, and the deduction can be carried out according to the total amount in the red packet information table when the deduction is carried out. Because the batch identifier comprises the scene identifier, the scene identifier comprises the sharing mode identifier, and the first client can share the red package according to the sharing mode identifier in the batch identifier.

Step 450, after the second client obtains the batch identifier, when the red packet is not robbed, obtaining the red packet serial number corresponding to the available red packet from the red packet distribution table according to the second distribution mode identifier or the third distribution mode identifier in the batch identifier.

After the first client performs red package sharing, the second client can receive the receiving link when the sharing mode is a link sharing mode, and can receive the red package shaking message when the sharing mode is an air sharing mode. The retrieval link may carry a lot identifier, and when the user clicks the retrieval link, the second client may obtain the lot identifier. When the user shakes the red packet through the second client, the batch identification corresponding to the batch red packet to which the shake-up red packet belongs can be obtained. And after the second client acquires the batch identifier, when the red packet is not robbed, and the allocation mode identifier included in the batch identifier is the second allocation mode identifier and the third allocation mode identifier, acquiring a red packet serial number corresponding to the available red packet from the red packet allocation table, wherein the available red packet is a red packet with a non-taken state, and the unavailable red packet is a red packet with a taken state.

Step 460, inserting a red packet leading flow water meter.

This step is the same as the step 350 in the above embodiment, and will not be described here again. The red package pickup flow list comprises a pickup person identifier, a pickup amount, a pickup time and a pickup terminal identifier.

Step 470, updating the remaining number in the red packet information table. This step is the same as the step 350 in the above embodiment, and will not be described here again.

Step 480, returning the batch identifier, the red packet serial number and the maximum retrievable amount to the second client, so that the second client retrieves the locked red packet.

When the allocation mode identifier in the batch identifier is the second allocation mode identifier or the third allocation mode identifier, the batch identifier is returned to the second client, and meanwhile, a red packet serial number and a maximum acceptable amount are required to be returned, wherein the red packet serial number is one or more of available red packet serial numbers determined in the step 450, and the maximum acceptable amount can be an amount corresponding to a red packet with the maximum amount in the red packets available in the red packet forwarding table. After the second client receives the batch identifier and the red packet serial number, the second client can receive the locked red packet according to the batch identifier and the red packet serial number.

Fig. 5 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention, referring to fig. 5, optionally, the method for sending and receiving red packets includes:

Step 510, generating a scene identifier according to the scene received from the first client; the procedure of the step 110 is the same as that of the step 110 in the above embodiment, and will not be described again here;

step 520, generating a batch identifier with a set format according to the scene identifier; this step is the same as the step 220 in the above embodiment, and will not be described here again.

And 530, generating a batch of red packets according to the distribution mode corresponding to the batch identification, registering a red packet information table, and deducting money according to the red packet information table so that the first client performs corresponding sharing actions according to the sharing mode corresponding to the batch identification.

Optionally, the step 530 includes:

and 531, generating a batch of red packets according to the distribution mode corresponding to the batch identification, registering a red packet information table, and deducting money according to the red packet information table, so that the first client generates a pickup link according to the first sharing mode identification in the batch identification.

Specifically, the first client may determine that the sharing manner of the red packet is a connection sharing manner according to the first sharing manner identifier in the batch identifier, and generate the pickup connection accordingly.

Step 532, generating a batch of red packets according to the distribution mode corresponding to the batch identification, registering a red packet information table, and deducting money according to the red packet information table, so that the first client sends the batch identification, the sharing time and the geographical position information to the second server based on the received red packet scattering range according to the second sharing mode identification in the batch identification, wherein the geographical position information comprises the geographical position and the red packet scattering range of the first client, so that the second server stores the batch identification, the sharing time and the geographical position information.

Specifically, the first client may determine that the sharing manner of the red packet is a scattering sharing manner according to the second sharing manner identifier in the batch identifier, and is configured to select a scattering red packet range at the first client, where the first client sends the batch identifier, the sharing time and the geographic location information to the second server based on the received scattering red packet range, where the second server may be a different server from the first server, and the second server is used as a local server and stores the received batch identifier, the sharing time and the geographic location information.

Step 540, after receiving the batch identifier sent by the second client, locking the red packet according to the batch identifier and returning the batch identifier to the second client, so that the second client can receive the locked red packet.

Specifically, when the sharing mode identifier in the batch identifier is the first sharing mode identifier, the second client receives the picking link sent by the first client, and after the user clicks the picking link, the second client sends the batch identifier carried by the picking link to the first server, so that the first server locks the red packet according to the batch identifier. When the sharing mode identifier in the batch identifier is the second sharing mode identifier, the second client receives the shaking packet signal, the second client sends positioning information of the second client of the user shaking the red packet to the second server and requests the second server to return the red packet, the second server can search whether the positioning information of the second client is in a red packet scattering range corresponding to the batch red packet, if so, the batch identifier corresponding to the batch red packet and the red packet initiator information are returned to the second client to enable the second client to acquire the batch identifier, the acquired batch identifier is sent to the first server, and the first server locks the red packet according to the batch identifier and returns the batch identifier to the second client to enable the second client to receive the locked red packet.

Fig. 6 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention, referring to fig. 6, optionally, the method for sending and receiving red packets includes:

step 610, generating a scene identifier according to a scene received from the first client; the procedure of the step 110 is the same as that of the step 110 in the above embodiment, and will not be described again here;

step 620, generating a batch of red packets according to the scene identifier and returning a batch identifier corresponding to the batch of red packets to the first client so that the first client shares the red packets according to the batch identifier; this step is the same as the step 120 in the above embodiment, and will not be described here again.

Step 630, after the lot identifier sent by the second client is obtained, the validity of the request for the second client is determined.

Optionally, the second client may send the lot identifier to the first server, and also send a check code of the equipment terminal where the second client is located to the first server, where the first server may determine the validity of the request for the second client according to the check code of the equipment terminal where the second client is located. In other optional embodiments of the present invention, the validity of the request for the second client may be determined in other manners, which is not limited herein.

Step 640, when the second client-side retrieval request is legal, determining whether the batch of red packets is repeatedly retrieved.

Specifically, after determining that the second client-side acquisition request is legal, judging that the second client-side can acquire the red packet. The first server needs to determine whether the batch of red packages is repeatedly picked up, specifically, whether the second client has picked up the batch of red packages.

When the request received by the second client is illegal, a prompt for illegal request can be returned to the second client, and the subsequent steps are not performed.

Step 650, when the red packet is not repeatedly picked up, it is determined whether the batch of red packets has been robbed.

After the red packets are not repeatedly picked up, judging whether the red packets are robbed or not, namely judging whether each red packet of the batch of red packets is robbed or not.

Step 660, when the red packet is not robbed, locking the red packet according to the batch identifier and returning the batch identifier to the second client, so that the second client can pick up the locked red packet.

Alternatively, the locked red packets may be identified according to the allocation pattern in the lot identification. Specifically, when the red packet is not robbed, any available red packet is locked according to a first distribution mode identifier in the batch identifier; or according to the second distribution mode identification or the third distribution mode identification in the batch identification, obtaining the available red packet serial number corresponding to the available red packet from the red packet distribution table, and further locking the available red packet corresponding to the red packet serial number.

The method can further comprise the step of sending a message notification of the robbery of the red packet batch to the second server side when the red packet batch is robbed, so that the second server side sends a message of the robbery of the red packet to the second client side when receiving the request for returning the red packet again.

On the basis of the above technical solutions, optionally, after the second client retrieves the locked red packet, the method for receiving and sending the red packet further includes: updating the state of the red package in the batch of red packages, and designating the amount of the retrieved red package for accounting.

Specifically, the red packet status may be a pickup status of the red packet, where when the allocation manner identifier included in the lot identifier is the first allocation manner identifier, the red packet status may be recorded in the red packet information table; when the allocation identifier included in the batch identifier is the second allocation formula identifier and the third allocation formula identifier, the red packet status may be recorded in a red packet allocation table.

Fig. 7 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention, where the method is applicable to a case of sending and receiving red packets in multiple scenes, and the method is applied to a first client, and may be executed by a red packet sending and receiving device, where the device may be implemented in a software and/or hardware manner, and the device may be configured in the first client. Referring to fig. 7, the method specifically includes the steps of:

Step 710, receiving a scene input by a user, and sending the scene to the first server, so that the first server generates a scene identifier according to the scene received from the first client, and generates a batch of red packets according to the scene identifier.

Specifically, after the first client receives the scene input by the user, the received scene may be sent to the first server. The first client may present a selection interface of the scene, and the user (may be a red packet initiator) realizes the input of the scene through the selection of the scene. The first server side generates a scene identifier according to the scene received from the first client side, then generates a batch red packet according to the scene identifier, and returns a batch identifier corresponding to the batch red packet to the first client side.

Step 720, receiving a batch identifier corresponding to the batch red packet returned by the first server, and sharing the red packet according to the batch identifier.

Specifically, in this step, the first client may perform a corresponding red packet sharing action according to the sharing mode identifier in the batch identifier, and optionally, when the sharing mode identifier is the first sharing mode identifier, the first client generates a pickup link, and when the sharing mode identifier is the second sharing mode identifier, the first client may present a red packet scattering range selection interface, further receive a red packet scattering range input by the user, and perform red packet sharing on the second client within the range based on the red packet scattering range.

According to the red packet receiving and dispatching method, scene induction is carried out on multiple scenes of the red packet, each scene corresponds to a scene identifier, red packet products are further rapidly developed for different scenes according to the scene identifiers, batch red packets meeting the conditions are generated, the batch red packets can be shared according to a sharing mode corresponding to the batch identifiers and are received according to a receiving mode corresponding to the batch identifiers, and therefore unified red packet interfaces are achieved, and development and maintenance costs of a server side and a client side are greatly reduced.

An embodiment of the present invention provides another method for sending and receiving red packets, and fig. 8 is a flowchart of another method for sending and receiving red packets, where the embodiment of the present invention is applicable to a case of sending and receiving red packets in multiple scenes, the method is applied to a second client, and may be executed by a red packet sending and receiving device, where the device may be implemented in a software and/or hardware manner, and the device may be configured in the second client. Referring to fig. 8, the method specifically includes the steps of:

step 810, after receiving the get message, obtaining the batch identifier, and uploading the batch identifier to the first server, so that the first server locks the red packet according to the batch identifier and returns the batch identifier to the second client.

Specifically, when the sharing mode in the batch identifier is the first sharing mode, the pickup message received by the second client may be a pickup link; when the sharing mode in the batch identifier is the second sharing mode, the receiving message received by the second client may be a shake-red packet message. After the second client receives the receiving message, the batch identifier is obtained and sent to the first server, so that the first server can lock the red packet according to the batch identifier and return the batch identifier to the second client.

Step 820, retrieving the locked red packet.

Specifically, in this step, when the locked red packet is retrieved, the locked red packet may be retrieved according to the lot identifier. Specifically, when the allocation mode identifier included in the batch identifier is the first allocation mode identifier, the amount of each red packet in the batch red packet is equal, so that the first server side can lock the red packet according to the batch identifier to be any available red packet, and the second client side can directly receive the red packet according to the batch identifier. When the distribution mode identifier included in the batch identifier is the second distribution mode identifier or the third distribution mode identifier, the amount of each red packet in the batch red packet is not necessarily equal, the first server returns the batch identifier to the second client and also returns a red packet serial number, and the second client obtains the locked red packet according to the batch identifier and the red packet serial number.

The red packet receiving and sending method can unify red packet interfaces and greatly reduce development and maintenance costs of a server side and a client side.

Optionally, the step 820 includes: and entering a corresponding retrieval interface according to a retrieval mode corresponding to the batch identification.

Specifically, the retrieval mode can be identified according to the retrieval mode identifier in the batch identifier, and the corresponding retrieval interface can be accessed according to the retrieval mode. After the user performs the picking action on the picking interface, the second client can send a message of the picking completion to the first server, so that the first server updates the state of the red packet and instructs the first server to check in the amount corresponding to the picked red packet.

Fig. 9 is a flowchart of another method for sending and receiving red packets according to an embodiment of the present invention, and referring to fig. 9, the method for sending and receiving red packets includes:

the method comprises the steps that a first client receives a scene input by a user and sends the scene to a first server;

the first server side generates scene identification according to the scene received from the first client side, and generates batch red packets according to the scene identification;

the first server side returns batch identifiers corresponding to the batch red packages to the first client side

The first client receives a batch identifier corresponding to the batch red packet returned by the first server and shares the red packet according to the batch identifier;

The second client receives the receiving message, acquires the batch identifier, and sends the batch identifier to the first server;

after receiving the batch identifier sent by the second client, the first server locks the red packet according to the batch identifier and returns the batch identifier to the second client;

and the second client receives the locked red packet.

Fig. 10 is a schematic structural diagram of a red packet transceiver provided in an embodiment of the present invention, where the red packet transceiver is provided at a first server, and the red packet transceiver may be used to execute a red packet transceiver method applied to the first server, and referring to fig. 10, the red packet transceiver includes:

a scene identifier generating module 10, configured to generate a scene identifier according to a scene received from a first client;

The batch red packet generation module 20 is configured to generate a batch red packet according to the scene identifier and return a batch identifier corresponding to the batch red packet to the first client, so that the first client performs red packet sharing according to the batch identifier; the batch of red packets includes at least one red packet;

and the red package locking module 30 is configured to lock the red package according to the batch identifier after receiving the batch identifier sent by the second client, and return the batch identifier to the second client, so that the second client can receive the locked red package.

The red packet transceiver device of the embodiment has the beneficial effects of being arbitrarily applied to the red packet transceiver method of the first server side, and is not described herein.

Fig. 11 is a schematic structural diagram of another red packet transceiver provided in an embodiment of the present invention, where the red packet transceiver is provided at a first client, and the red packet transceiver may be used to perform a red packet transceiving method applied to the first client, and referring to fig. 11, the red packet transceiver includes:

the sending module 40 is configured to receive a scene input by a user, and send the scene to the first server, so that the first server generates a scene identifier according to the scene received from the first client, and generates a batch of red packets according to the scene identifier;

And the sharing module 50 is used for receiving the batch identification corresponding to the batch red package returned by the first server side and carrying out corresponding red package sharing according to the batch identification.

The red packet transceiver device of the embodiment has the beneficial effects of the red packet transceiver method arbitrarily applied to the first client, and is not described herein.

Fig. 12 is a schematic structural diagram of another red packet transceiver provided in an embodiment of the present invention, where the red packet transceiver is provided at a second client, and the red packet transceiver may be used to perform a red packet transceiver method applied to the second client, and referring to fig. 12, the red packet transceiver includes:

the uploading module 60 is configured to obtain a batch identifier after receiving the pickup message, and upload the batch identifier to the first server, so that the first server locks the red packet according to the batch identifier and returns the batch identifier to the second client;

and a retrieving module 70 for retrieving the locked red packet.

The red packet transceiver device of the embodiment has the beneficial effects of being arbitrarily applied to the red packet transceiver method of the second client, and is not described herein.

The embodiment of the invention also provides a red packet receiving and transmitting device, and fig. 13 is a schematic structural diagram of the red packet receiving and transmitting device. Fig. 13 shows a block diagram of an exemplary red packet transceiving device suitable for use in implementing an embodiment of the present invention. The red packet transceiving device 41 shown in fig. 13 is only an example, and should not be construed as limiting the function and scope of use of the embodiment of the present invention.

As shown in fig. 13, the red packet transceiving equipment 41 is represented in the form of a general-purpose equipment. The components of the red envelope transceiver device 41 may include, but are not limited to: one or more processors 416, a storage 428, and a bus 418 that connects the various system components (including the storage 428 and the processors 416).

Bus 418 represents one or more of several types of bus structures, including a memory device bus or memory device controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include industry standard architecture (Industry Subversive Alliance, ISA) bus, micro channel architecture (Micro Channel Architecture, MAC) bus, enhanced ISA bus, video electronics standards association (Video Electronics Standards Association, VESA) local bus, and peripheral component interconnect (Peripheral Component Interconnect, PCI) bus.

The red envelope transceiver device 41 typically includes a variety of computer system readable media. Such media can be any available media that can be accessed by the red packet transceiver device 41 and includes both volatile and nonvolatile media, removable and non-removable media.

The storage 428 may include computer system readable media in the form of volatile memory, such as random access memory (Random Access Memory, RAM) 431 and/or cache memory 432. The red packet transceiving device 41 may further comprise other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 434 may be used to read from or write to non-removable, nonvolatile magnetic media (not shown in FIG. 13, commonly referred to as a "hard disk drive"). Although not shown in fig. 13, a magnetic disk drive for reading from and writing to a removable nonvolatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable nonvolatile optical disk such as a Read Only Memory (CD-ROM), digital versatile disk (Digital Video Disc-Read Only Memory, DVD-ROM), or other optical media, may be provided. In such cases, each drive may be coupled to bus 418 via one or more data medium interfaces. Storage 428 may include at least one program product having a set (e.g., at least one) of program modules configured to carry out the functions of embodiments of the invention.

A program/utility 441 having a set (at least one) of program modules 442 may be stored, for example, in the storage 428, such program modules 442 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each or some combination of which may include an implementation of a network environment. Program modules 442 generally perform the functions and/or methodologies in the described embodiments of the invention.

The red packet transceiving device 41 may also communicate with one or more external devices 414 (e.g., keyboard, pointing terminal, display 424, etc.), with one or more terminals that enable a user to interact with the red packet transceiving device 41, and/or with any terminal (e.g., network card, modem, etc.) that enables the red packet transceiving device 41 to communicate with one or more other computing terminals. Such communication may occur through an input/output (I/O) interface 422. Also, the red packet transceiving device 41 may communicate with one or more networks (e.g., local area network (Local Area Network, LAN), wide area network (Wide Area Network, WAN) and/or public network, such as the internet) through network adapter 421. As shown in fig. 13, the network adapter 421 communicates with other modules of the red packet transceiving device 41 via the bus 418. It should be appreciated that although not shown, other hardware and/or software modules may be used in connection with the red packet transceiving device 41, including but not limited to: microcode, end drives, redundant processors, external disk drive arrays, disk array (Redundant Arrays of Independent Disks, RAID) systems, tape drives, data backup storage systems, and the like.

The processor 416 executes various functional applications and data processing by running a program stored in the storage device 428, for example, to implement a red packet transceiving method applied to the first server side according to an embodiment of the present invention, and the method includes:

generating a scene identification from a scene received from a first client;

The embodiment of the invention also provides another red packet receiving and transmitting device, which comprises: one or more processors; a storage means for storing one or more programs; when one or more programs are executed by one or more processors, the one or more processors implement a red packet transceiving method applied to a first client according to an embodiment of the present invention, where the method includes:

and receiving the scene input by the user, and sending the scene to the first server side so that the first server side generates a scene identifier according to the scene received from the first client side and generates a batch of red packets according to the scene identifier.

The embodiment of the invention also provides another red packet receiving and transmitting device, which comprises: one or more processors; a storage means for storing one or more programs; when one or more programs are executed by one or more processors, the one or more processors implement the red packet transceiving method applied to the second client provided by the embodiment of the present invention, and the method includes:

and (5) taking the locked red packet.

The fifth embodiment of the present invention further provides a computer readable storage medium having a computer program stored thereon, where the program when executed by a processor implements a red packet transceiving method applied to a first server according to the present invention, the method including:

generating a scene identification from a scene received from a first client;

The computer storage media of embodiments of the invention may take the form of any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or terminal. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The embodiment of the invention also provides another computer readable storage medium, on which a computer program is stored, the program when executed by a processor implementing the red packet receiving and sending method applied to the first client provided by the embodiment of the invention, the method includes:

The embodiment of the invention also provides another computer readable storage medium, on which a computer program is stored, the program when executed by a processor implementing the red packet receiving and sending method applied to the second client provided by the embodiment of the invention, the method includes:

and (5) taking the locked red packet.

Embodiments of the present invention also provide a computer program product comprising computer executable instructions for performing the red packet transceiving method in the method embodiment described above when executed by a computer processor.

Of course, the computer program product provided by the embodiments of the present application, whose computer executable instructions are not limited to the method operations described above, may also perform the relevant operations in the methods provided by any of the embodiments of the present application.

Note that the above is only a preferred embodiment of the present invention and the technical principle applied. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, while the invention has been described in connection with the above embodiments, the invention is not limited to the embodiments, but may be embodied in many other equivalent forms without departing from the spirit or scope of the invention, which is set forth in the following claims.

Claims

1. The red packet receiving and sending method is characterized by being applied to a first server side and comprising the following steps:

generating a scene identification from a scene received from a first client;

generating a batch of red packets according to the scene identification and returning batch identifications corresponding to the batch of red packets to the first client so that the first client shares the red packets according to the batch identifications; the batch of red packets comprises at least one red packet;

After receiving the batch identification sent by the second client, locking the red package according to the batch identification and returning the batch identification to the second client so that the second client can get the locked red package; generating a batch of red packages according to the scene identification and returning batch identifications corresponding to the batch of red packages to the first client so that the first client shares the batch of red packages according to the batch identifications, wherein the method comprises the following steps:

generating the batch identification in a set format according to the scene identification;

generating a batch of red packets according to the distribution mode corresponding to the batch identification, registering a red packet information table, and deducting money according to the red packet information table so that the first client performs corresponding sharing actions according to the sharing mode corresponding to the batch identification;

the red packet information table comprises the total amount of red packets, the total number of red packets, the residual number of red packets and distribution modes; the batch identifier with the set format comprises the scene identifier, a global running water identifier and an equipment terminal verification identifier, wherein the global running water identifier is used for identifying a transaction corresponding to the batch of red packets, and the equipment terminal verification identifier is used for identifying an equipment terminal for installing the first client;

The scene identifier comprises a format identifier, an allocation mode identifier, a sharing mode identifier and a retrieval mode identifier.

2. The method of claim 1, wherein generating the lot identification in a set format from the scene identification comprises:

and generating the batch identification in a set format according to the scene identification and the equipment terminal verification identification received from the first client.

3. The method of claim 2, wherein generating the lot identification in a set format based on the scene identification and the device terminal verification identification received from the first client comprises:

and when the equipment terminal check identifier is matched with the set check identifier, generating the batch identifier in a set format according to the scene identifier, the equipment terminal check identifier and the global running water identifier which is automatically generated.

4. The method for sending and receiving red packets according to claim 1, wherein the format identifiers comprise a first format identifier, a second format identifier and a third format identifier, the first format identifier is used for identifying page text blessing red packets, the second format identifier is used for identifying video blessing red packets, and the third format identifier is used for identifying voice blessing red packets;

And/or the allocation mode identifier comprises a first allocation mode identifier, a second allocation mode identifier and a third allocation mode identifier, wherein the first allocation mode identifier is used for identifying a fixed allocation mode, the second allocation mode identifier is used for identifying a random allocation mode, and the third allocation mode identifier is used for identifying a self-defined allocation mode;

and/or the sharing mode identifier comprises a first sharing mode identifier and a second sharing mode identifier, wherein the first sharing mode identifier is used for identifying a link sharing mode, and the second sharing mode identifier is used for identifying a sharing mode scattered in the air;

and/or, the retrieval mode identification comprises a first retrieval mode identification, a second retrieval mode identification, a third retrieval mode identification, a fourth retrieval mode identification, a fifth retrieval mode identification and a sixth retrieval mode identification, wherein the first retrieval mode identification is used for identifying a direct retrieval mode, the second retrieval mode identification is used for identifying an AR to find a red packet retrieval mode, the third retrieval mode identification is used for identifying a face brushing and color measurement value retrieval mode, the fourth retrieval mode identification is used for identifying a password retrieval mode, the fifth retrieval mode identification is used for identifying a break game retrieval mode, and the sixth retrieval mode identification is used for identifying a raffle and turn-over card retrieval mode.

5. The method for sending and receiving red packets according to claim 4, wherein generating a batch of red packets according to the allocation mode corresponding to the batch identifier, registering a red packet information table, and deducting money according to the red packet information table, so that the first client performs red packet sharing according to the batch identifier, includes:

generating a batch of red packets according to a first distribution mode identifier in the batch identifier, registering a red packet information table, and deducting money according to the red packet information table so that the first client side shares the red packets according to the batch identifier;

wherein the red packet information table also comprises a fixed amount of each red packet.

6. The method for sending and receiving a red packet according to claim 5, wherein after receiving the lot identifier sent by the second client, locking the red packet according to the lot identifier and returning the lot identifier to the second client, so that the second client can receive the locked red packet, comprising:

after the second client acquires the batch identifier, when the red packet is not robbed, locking any available red packet according to a first distribution mode identifier in the batch identifier;

Inserting a red packet leading water meter;

updating the residual number in the red packet information table;

returning a batch identifier to the second client so that the second client can receive the locked red packet;

the red packet retrieval flow table comprises a retriever identifier, a retrieval amount, a retrieval time and a retrieval terminal identifier.

7. The method for sending and receiving red packets according to claim 4, wherein generating a batch of red packets according to the allocation mode corresponding to the batch identifier, registering a red packet information table, and deducting money according to the red packet information table, so that the first client performs red packet sharing according to the batch identifier, includes:

generating a batch of red packets according to a second distribution formula identifier or a third distribution identifier in the batch identifiers, and recording a red packet distribution table;

registering a red packet information table, and deducting money according to the red packet information table so that the first client side shares red packets according to the batch identification;

wherein the red packet distribution table comprises a red packet serial number, a red packet amount and a pickup state.

8. The method for sending and receiving a red packet according to claim 7, wherein after receiving the batch identifier sent by the second client, locking the red packet according to the batch identifier and returning the batch identifier to the second client, so that the second client can receive the locked red packet, comprising:

After the second client acquires the batch identifier, when the red packet is not robbed, acquiring a red packet serial number corresponding to the available red packet from the red packet distribution table according to a second distribution mode identifier or a third distribution mode identifier in the batch identifier;

inserting a red packet leading water meter;

updating the residual number in the red packet information table;

returning the batch identifier, the red packet serial number and the maximum retrievable amount to the second client so that the second client retrieves the locked red packet;

9. The method for sending and receiving a red packet according to claim 4, wherein generating a batch of red packets according to the allocation method corresponding to the batch identifier, registering a red packet information table, and deducting money according to the red packet information table, so that the first client shares the red packets according to the batch identifier, includes:

generating a batch of red packets according to the distribution mode corresponding to the batch identification, registering a red packet information table, and deducting money according to the red packet information table so that the first client performs corresponding sharing actions according to the sharing mode corresponding to the batch identification.

10. The method for sending and receiving a red packet according to claim 9, wherein the generating a batch of red packets according to the allocation method corresponding to the batch identifier, registering a red packet information table, and deducting money according to the red packet information table, so that the first client performs a corresponding sharing action according to the sharing method corresponding to the batch identifier, includes:

generating a batch of red packets according to the distribution mode corresponding to the batch identification, registering a red packet information table, and deducting money according to the red packet information table so that the first client generates a receiving link according to a first sharing mode identification in the batch identification.

11. The method for sending and receiving a red packet according to claim 9, wherein the generating a batch of red packets according to the allocation method corresponding to the batch identifier, registering a red packet information table, and deducting money according to the red packet information table, so that the first client performs a corresponding sharing action according to the sharing method corresponding to the batch identifier, includes:

generating a batch of red packets according to the distribution mode corresponding to the batch identification, registering a red packet information table, deducting money according to the red packet information table, enabling the first client to send the batch identification, the sharing time and the geographical position information to a second server based on the received red packet scattering range according to a second sharing mode identification in the batch identification, wherein the geographical position information comprises the geographical position of the first client and the red packet scattering range, and enabling the second server to store the batch identification, the sharing time and the geographical position information;

The second server is a server which is different from the first server, and serves as a local server to store the received batch identification, sharing time and geographic position information.

12. The method for sending and receiving a red packet according to claim 1, wherein after receiving the lot identifier sent by the second client, locking the red packet according to the lot identifier and returning the lot identifier to the second client, so that the second client can receive the locked red packet, comprising:

after the batch identifier sent by the second client is obtained, judging the validity of the request received by the second client;

when the second client-side acquisition request is legal, judging whether the batch of red packets are repeatedly acquired or not;

when the red packets are not repeatedly picked up, judging whether the batch of red packets is robbed or not;

and when the red packet is not robbed, locking the red packet according to the batch identification and returning the batch identification to the second client so that the second client can pick up the locked red packet.

13. The method of red envelope transreceiving of claim 12, further comprising:

And when the batch of red packets is robbed, sending a message notification that the batch of red packets is robbed to a second server side.

14. The method of any one of claims 5-13, further comprising, after the second client retrieves the locked red packet:

updating the state of the red package in the batch of red packages, and designating the amount of the retrieved red package for accounting.

15. The red packet receiving and sending method is characterized by being applied to a first client and comprising the following steps of:

receiving a scene input by a user, sending the scene to a first server side, enabling the first server side to generate a scene identifier according to the scene received from a first client side, generating a batch of red packets according to the scene identifier, and returning a batch identifier corresponding to the batch of red packets to the first client side, so that the first client side shares the red packets according to the batch identifier; the batch of red packets comprises at least one red packet;

receiving a batch identifier corresponding to the batch of red packets returned by the first server, and sharing the red packets according to the batch identifier;

generating a batch of red packages according to the scene identification and returning batch identifications corresponding to the batch of red packages to the first client so that the first client shares the batch of red packages according to the batch identifications, wherein the method comprises the following steps:

generating a batch of red packets according to the distribution mode corresponding to the batch identification, registering a red packet information table, and deducting money according to the red packet information table so that the first client performs corresponding sharing actions according to the sharing mode corresponding to the batch identification; the red packet information table comprises the total amount of red packets, the total number of red packets, the residual number of red packets and distribution modes;

the batch identifier with the set format comprises the scene identifier, a global running water identifier and an equipment terminal verification identifier, wherein the global running water identifier is used for identifying a transaction corresponding to the batch of red packets, and the equipment terminal verification identifier is used for identifying an equipment terminal for installing the first client; the scene identifier comprises a format identifier, an allocation mode identifier, a sharing mode identifier and a retrieval mode identifier.

16. The red packet receiving and sending method is characterized by being applied to a second client and comprising the following steps of:

after receiving the receiving message, obtaining a batch identifier, and uploading the batch identifier to a first server side, so that the first server side locks a red packet according to the batch identifier and returns the batch identifier to the second client side;

The locked red packet is picked up;

generating a scene identifier at the first server according to a scene received from a first client;

17. The method of claim 16, wherein the retrieving the locked red packet comprises:

and entering a corresponding retrieval interface according to the retrieval mode corresponding to the batch identifier.

18. The red packet receiving and transmitting device is characterized by being applied to a first server side and comprising:

the batch red package generation module is used for generating batch red packages according to the scene identification and returning batch identifications corresponding to the batch red packages to the first client so that the first client can share the red packages according to the batch identifications; the batch of red packets comprises at least one red packet;

the red package locking module is used for locking the red package according to the batch identification after receiving the batch identification sent by the second client and returning the batch identification to the second client so as to lead the second client to get the locked red package;

19. A red packet transceiver device, applied to a first client, comprising:

the sending module is used for receiving a scene input by a user, sending the scene to the first server side, enabling the first server side to generate a scene identifier according to the scene received from the first client side, generating a batch of red packets according to the scene identifier, and returning the batch identifier corresponding to the batch of red packets to the first client side, so that the first client side can share the red packets according to the batch identifier; the batch of red packets comprises at least one red packet;

The sharing module is used for receiving the batch identification corresponding to the batch of red packets returned by the first server side and carrying out corresponding red packet sharing according to the batch identification;

20. A red packet transceiver device, for use in a second client, comprising:

the uploading module is used for acquiring a batch identifier after receiving the receiving message, and uploading the batch identifier to a first server side so that the first server side locks a red packet according to the batch identifier and returns the batch identifier to the second client side;

the receiving module is used for receiving the locked red packet;

21. A red packet transceiving equipment, characterized in that the red packet transceiving equipment comprises:

one or more processors;

a storage means for storing one or more programs;

when executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-17.

22. A computer readable storage medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any of claims 1-17.