A method, device and equipment for processing a multi-person shared bill

Abstract

Embodiments of the present specification provide a processing method, device and equipment for multi-person sharing of bills. The scheme comprises: obtaining a to-be-shared bill from a sharing initiation user's historical payment record based on a preset screening rule; determining a candidate sharing participation user based on the first geographic location information of the sharing initiation user and the second geographic location information of other users; showing the user information of the candidate sharing participation user to the sharing initiation user; receiving the selection instruction of the sharing initiation user and determining a sharing participation user; generating a shared bill set based on the to-be-shared bill and the sharing participation information of the sharing participation user; and sending each shared bill in the shared bill set to each sharing participation user.

Description

Technical Field

[0001] This specification relates to the field of multi-person payment technology in one or more embodiments, and particularly to a method, apparatus and device for processing bills shared by multiple people. Background Technology

[0002] With the widespread adoption of mobile payments, consumption scenarios involving multiple people, such as dining out with friends, traveling, and team building activities, are becoming increasingly frequent, and splitting bills among multiple people has become a high-frequency payment need for users.

[0003] Therefore, improving the convenience of cost sharing has become an urgent technical problem to be solved. Summary of the Invention

[0004] In view of this, one or more embodiments of this specification provide a method, apparatus, and device for processing bills shared by multiple parties, so as to improve the accuracy of processing bills shared by multiple parties.

[0005] According to a first aspect of one or more embodiments of this specification, a method for processing bills shared by multiple people is provided, including: The bill to be allocated is obtained from the historical payment records of the user who initiated the allocation based on preset filtering rules; Based on the first geographic location information of the user initiating the cost-sharing, and the second geographic location information of other users, candidate users for cost-sharing are determined; the distance between the second geographic location information and the first geographic location information of the candidate users is less than a preset distance threshold. Display the user information of the candidate participants in the cost-sharing process to the user who initiated the cost-sharing process. Receive the selection instruction from the user who initiated the cost-sharing, and determine the users participating in the cost-sharing; A set of allocated bills is generated based on the bills to be allocated and the allocation participation information of the participating users. The set of allocated bills includes the allocated bills of each of the participating users. Each of the aforementioned cost-sharing invoices will be sent to each of the aforementioned cost-sharing participants.

[0006] According to a fifth aspect of one or more embodiments of this specification, an apparatus for processing bills shared by multiple parties is provided, comprising: The unallocated bill acquisition module is used to obtain the unallocated bill from the historical payment records of the user who initiated the allocation based on preset filtering rules; The candidate sharing participant determination module is used to determine candidate sharing participants based on the first geographical location information of the sharing initiator user and the second geographical location information of other users; the distance between the second geographical location information of the candidate sharing participants and the first geographical location information is less than a preset distance threshold. The display module is used to display the user information of the candidate participants in the cost-sharing to the user who initiated the cost-sharing; The apportionment participant determination module is used to receive the selection instruction from the apportionment initiator user and determine the apportionment participants. The shared bill generation module is used to generate a shared bill set based on the bill to be shared and the shared participation information of the shared participants, wherein the shared bill set includes the shared bills of each of the shared participants; The shared bill sending module is used to send each of the shared bills to each of the shared participants.

[0007] According to a third aspect of one or more embodiments of this specification, a computing device is provided, including a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein the processor, when executing the computer instructions, implements the steps of the method for processing bills shared by multiple users.

[0008] One embodiment of this specification can achieve at least the following beneficial effects: It retrieves the bill to be shared from the historical payment records of the user initiating the sharing based on preset filtering rules; it determines candidate sharing participants based on the first geographical location information of the user initiating the sharing and the second geographical location information of other users; it displays the user information of the candidate sharing participants to the user initiating the sharing; it receives the selection instruction from the user initiating the sharing and determines the sharing participants; it generates a set of sharing bills based on the bill to be shared and the sharing participation information of the sharing participants; and it sends each sharing bill in the set of sharing bills to each sharing participant. This solution retrieves the bill to be shared from the historical payment records of the user initiating the sharing based on preset filtering rules, eliminating the need for users to manually review bills or recall consumption scenarios, significantly reducing the user's operational burden and improving the convenience of the entire bill sharing process; it determines candidate sharing participants based on the first geographical location information of the user initiating the sharing and the second geographical location information of other users, and the system automatically recommends possible sharing partners nearby, eliminating the need for the user initiating the sharing to manually input or search for companions, further reducing the user's operational steps and improving the convenience of the sharing operation. The user information of the candidate participants in the cost-sharing is displayed to the user who initiates the cost-sharing, allowing the user who initiates the cost-sharing to determine the participants, thus avoiding misrecommendations and ensuring the accuracy and fairness of the cost-sharing. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram illustrating an application scenario of a method for processing bills shared by multiple people, as provided in the embodiments of this specification. Figure 2 This is a flowchart illustrating a method for processing bills shared by multiple people, as provided in the embodiments of this specification. Figure 3 This is a user information display diagram provided in the embodiments of this specification; Figure 4 This is a flowchart illustrating a method for processing bills shared by multiple people, as provided in the embodiments of this specification. Figure 5 This is a schematic diagram of a device for processing bills shared by multiple people, as provided in the embodiments of this specification. Figure 6 This is a schematic diagram of the structure of a computer device provided in the embodiments of this specification. Detailed Implementation

[0011] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0012] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0013] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “an,” “an,” “the,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification includes any or all possible combinations of one or more associated listed items.

[0014] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0015] Although the terms "first," "second," etc., may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, "first" may also be referred to as "second," and similarly, "second" may also be referred to as "first," without departing from the scope of one or more embodiments of this specification. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to facilitate the distinction of objects. For example, "first server" and "second server" usually refer to two servers. To distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0016] Depending on the context, the word "if" as used here can be interpreted as "when," "when," or "in response to determination."

[0017] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0018] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0019] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0020] The following explains the terms and concepts used in one or more embodiments of this specification.

[0021] AA payment refers to the practice of multiple people splitting the cost of a purchase equally.

[0022] Currently, payment platforms offer corresponding AA (shared cost) or group payment functions. In existing technical solutions, after completing a payment, users typically need to manually enter the total amount and select or add participants one by one. The system then generates a bill based on the participants' contribution information and initiates collection from each participant. However, this process of manually entering the total amount and selecting or adding participants is cumbersome and inconvenient.

[0023] To address the shortcomings in related technologies, this solution provides the following embodiments.

[0024] Figure 1 This is a schematic diagram illustrating an application scenario of a method for processing bills shared by multiple people, as provided in the embodiments of this specification.

[0025] The method for processing bills shared by multiple people provided in this application embodiment can be applied to, for example, Figure 1 The application scenarios shown are not limited to these. In, for example... Figure 1 In the application scenario shown, server 101 can connect to one or more client devices, such as the apportionment initiating user client device and the apportionment participating user client devices, via a local area network (LAN), wide area network (WAN), internet connection, or other types of data network. These client devices may include, but are not limited to, smartphones, tablets, laptops, PDAs, personal computers, smart home devices, and in-vehicle devices. Users (apportionment initiating users and apportionment participating users) can interact with the client devices through a graphical user interface to implement the methods provided in the embodiments of this specification.

[0026] like Figure 1As shown, the scheme may include a server 101, a user initiating the cost-sharing 102, and a user participating in the cost-sharing 103. The user initiating the cost-sharing 102 can send a multi-user cost-sharing instruction to the server 101 via a user client device. After receiving the instruction, the server 101 can retrieve the cost-sharing bill from the user initiating the cost-sharing 102's historical payment records; determine candidate users for cost-sharing participation based on the user initiating the cost-sharing 102's first geographical location information and the second geographical location information of other users; display the user information of the determined candidate users for cost-sharing participation to the user initiating the cost-sharing 102 so that the user initiating the cost-sharing 102 can confirm or select user 103; and determine user 103 based on the confirmation or selection instruction of the user initiating the cost-sharing 102; generate a cost-sharing bill set based on the cost-sharing bill and the cost-sharing participation information of user 103, and send each cost-sharing bill in the cost-sharing bill set to user 103.

[0027] like Figure 1 In the scenario shown, the server can be, but is not limited to, any device, equipment, platform, or device cluster with computing and processing capabilities.

[0028] This application provides a method for processing bills shared by multiple people. This application also relates to an apparatus for processing bills shared by multiple people, and a computing device, which will be described in detail in the following embodiments.

[0029] Figure 2 This is a flowchart illustrating a method for processing bills shared by multiple people, as provided in an embodiment of this specification.

[0030] From a procedural perspective, the entity executing the process can be the payment platform server. It can be understood that this method can be executed by any device, equipment, or cluster of devices with computing and processing capabilities.

[0031] like Figure 2 As shown, the process may include the following steps.

[0032] Step 202: Obtain the bill to be allocated from the historical payment records of the user who initiated the allocation based on the preset filtering rules.

[0033] In one or more embodiments of this specification, preset filtering rules can refer to pre-defined filtering conditions used to quantitatively assess the likelihood that each bill belongs to multiple consumers. For example, preset filtering rules may include conditions such as bill amount, merchant type, and payment period.

[0034] Historical payment records can be transaction records completed by the initiating user through the payment platform within a preset historical period; or they can be a preset number of transaction records completed through the payment platform before the current time. Historical payment records can include information such as the transaction amount, merchant name, payment time, and geographical location for each transaction.

[0035] In practical applications, after the user initiating the cost-sharing payment completes the payment through the payment platform on their terminal device, they can initiate a multi-person cost-sharing instruction using that device. Upon receiving this instruction, the payment platform server can retrieve the initiating user's historical payment records and automatically extract the cost-sharing bill from these records based on preset filtering rules.

[0036] In one or more embodiments of this specification, the bills to be allocated are automatically obtained based on preset filtering rules, eliminating the need for users to manually browse bills or recall consumption scenarios, significantly reducing the user's operational burden and improving the convenience of the entire bill allocation process.

[0037] Step 204: Based on the first geographic location information of the user initiating the cost-sharing and the second geographic location information of other users, determine the candidate users participating in the cost-sharing; the distance between the second geographic location information and the first geographic location information of the candidate users participating in the cost-sharing is less than a preset distance threshold.

[0038] In practical applications, when multiple people hold gatherings, team building activities, or travel activities, the participants are usually located at or near the same consumption venue. Therefore, the participants can be identified based on their geographical location.

[0039] In one or more embodiments of this specification, the first geographic location information is the location information of the user initiating the cost-sharing payment at the time of payment completion or within a preset time period including the payment completion time. In practical applications, the first geographic location information of the user initiating the cost-sharing payment can be obtained based on the location data of the user's terminal device. Specifically, the first geographic location information of the user initiating the cost-sharing payment can be obtained based on GPS, Wi-Fi, or base station location data collected by the terminal's built-in positioning module. Similarly, the second geographic location information of other users can be obtained based on the location data of other users' terminal devices.

[0040] In one or more implementations of this specification, other users can be active users of the payment platform located within a certain geographical range around the user initiating the cost-sharing. It is understood that the second geographical location information is collected at the same time as the first geographical location information.

[0041] Candidate users for cost sharing can be further filtered based on first and second geographic location information. In one or more embodiments of this specification, the distance between the candidate users participating in the cost sharing and the user initiating the cost sharing is less than a preset distance threshold.

[0042] In one or more embodiments of this specification, candidate participants for sharing costs are determined based on the first geographical location information of the user initiating the cost sharing and the second geographical location information of other users. The system automatically recommends possible participants nearby, eliminating the need for the user initiating the cost sharing to manually input or search for companions, thus greatly reducing the number of operation steps. This is especially beneficial in scenarios such as large gatherings or when traveling with strangers, improving the convenience of cost sharing operations.

[0043] Step 206: Display the user information of the candidate participants in the cost-sharing to the user who initiated the cost-sharing.

[0044] User information can be information that identifies the candidate user participating in the cost-sharing. In one or more embodiments of this specification, user information can be used by the cost-sharing initiator to determine whether the candidate user is a participant in the cost-sharing; that is, user information is auxiliary data for the cost-sharing initiator's decision.

[0045] The user information may include at least one of the user's avatar, nickname, and user identifier. For example, if the candidate user participating in the sharing activity is in the friend list of the user initiating the activity, the user information may also include a nickname set by the user initiating the activity for that candidate user. If the candidate user participating in the sharing activity and the user initiating the activity have a pre-defined relationship (such as friends, group members, etc.), the user information may also include a corresponding relationship tag.

[0046] In one or more embodiments of this specification, user information can be displayed in a structured and visual manner through the graphical user interface of the user's terminal device, such as... Figure 3 As shown. Specifically, after determining the list of candidate users to participate in the cost-sharing, the payment platform server can package and send the corresponding user identifiers, nicknames, avatar URLs, and other data to the client device of the user initiating the cost-sharing. The client can then call the interface rendering engine to generate the user information display content according to a preset template.

[0047] In one or more embodiments of this specification, the system filtering results are transformed into information that is easy for users to understand and displayed intuitively to the user initiating the cost allocation, which effectively reduces the cognitive burden on the user initiating the cost allocation and further improves the convenience of the cost allocation operation.

[0048] Step 208: Receive the selection instruction from the user who initiated the cost-sharing and determine the users participating in the cost-sharing.

[0049] The selection command is generated by the user initiating the cost allocation process, based on the user information displayed on the terminal device, through the device's interactive interface. In practical applications, the interactive interface can be configured with user checkboxes that correspond one-to-one with the information of each candidate participating user. The user initiating the cost allocation process can select the corresponding candidate participating users through these checkboxes. The interactive interface can also include a confirmation control; after the user initiating the cost allocation process completes the user checkboxing, clicking the confirmation control generates the user selection command. For example, the interactive interface can also be configured with a one-click select all control, used to select all candidate participating users in batches.

[0050] As one implementation method, the interactive interface can also be configured with a user checkbox corresponding to the user information of the user initiating the cost-sharing. The user initiating the cost-sharing can use the user checkbox corresponding to the user information to choose whether to participate in the cost-sharing. For example, if the checkbox is selected, it means that the user initiating the cost-sharing participates in the cost-sharing; if the checkbox is not selected, it means that the user initiating the cost-sharing does not participate in this cost-sharing.

[0051] As another implementation, after receiving the confirmation instruction from the user who initiated the contribution, a notification is sent to the user inquiring whether they wish to participate in the contribution. The user's participation is determined based on their selection to participate or not, thus generating a final valid selection instruction. This selection instruction is used to select participating users to determine the final user group participating in the contribution.

[0052] In addition, the interactive interface can be configured to manually add user controls, so that users who initiate the cost-sharing process can be supplemented to those who are not included in the system's recommended list but actually need to participate in the cost-sharing.

[0053] In the embodiments described in this specification, having the user initiating the allocation determine the users participating in the allocation effectively avoids misrecommendations, such as those who are at the same table but not traveling together; it also avoids omitting allocation members, such as users who are not on the system's recommended list but should actually participate in the allocation. This ensures the convenience of intelligent recommendations while guaranteeing the accuracy and fairness of the allocation.

[0054] Step 210: Generate a set of allocated bills based on the bills to be allocated and the allocation participation information of the participating users. The set of allocated bills includes the allocated bills of each of the participating users.

[0055] In one or more embodiments of this specification, the shared bill set is a generalized bill set. The shared bill set contains personalized bills corresponding to each participating user. Specifically, if the participating users include the initiating user, the shared bill corresponding to the initiating user can be a shared confirmation slip. This shared confirmation slip includes at least the amount the initiating user should bear, used for informing the initiating user of the amount and confirming the bill. This shared confirmation slip does not include a payment gateway for self-payment. Additionally, the initiating user's shared bill may also include the amounts payable by other participating users, so that the initiating user knows the specific amount each participating user needs to pay. For other participating users besides the initiating user, the corresponding shared bill can be a payment notification slip. The shared information includes at least the amount payable, the payee (i.e., the initiating user) information, a bill description, and a payment gateway.

[0056] In one or more embodiments of this specification, the cost-sharing participation information may be parameter information describing how each cost-sharing participant bears the cost. In practical applications, each cost-sharing bill in the cost-sharing bill set may be an evenly allocated cost-sharing bill or a non-evenly allocated cost-sharing bill.

[0057] In one implementation, the sharing participation information may include the number of users to be shared. If the sharing mode is equal sharing, the average sharing amount can be calculated based on the number of users to be shared, thereby generating an equal sharing bill. In another implementation, the sharing participation information may also include the sharing ratio. The sharing ratio is the proportion of each user's share, such as A's sharing ratio being 20%, B's being 30%, and C, D, E, F, and G's being 10% each. If the sharing mode is non-equal sharing, the amount to be shared by the user initiating the sharing and each user participating in the sharing can be calculated based on the number of users to be shared and the sharing ratio, thereby generating a non-equal sharing bill.

[0058] In practical applications, the sharing ratio can be manually set by the user initiating the sharing through the terminal device's interactive interface, either after selecting candidate sharing participants using the user checkbox and before or after triggering the confirmation control to generate the selection instruction. As one implementation method, a ratio input box or slider can be configured next to the checkboxes corresponding to the user initiating the sharing and each candidate sharing participant. The user initiating the sharing can then input or adjust the sharing ratio for each selected sharing participant. Alternatively, a one-click "Equal Sharing" control can be provided in the interactive interface, automatically distributing the ratio equally among all selected participants. After the user initiating the sharing completes the selection and ratio settings, clicking the confirmation control will receive the selection instruction containing the user identifier and the corresponding sharing ratio parameters, thereby generating a set of shared bills allocated according to the specified ratio.

[0059] As another implementation method, the system sends a notification to the user who initiated the allocation to ask whether the user will participate in this allocation. After receiving the instruction from the user who initiated the allocation to choose to participate or not to participate, the system can display a ratio setting interface, allowing the user who initiated the allocation to set the allocation ratio for each participating user, thereby completing the allocation ratio setting. Then, an allocation bill set can be generated based on the allocation quantity and allocation ratio.

[0060] In addition, if no sharing ratio is set, the system can default to the average sharing method.

[0061] To facilitate understanding, a specific example is provided below: In practical applications, the payment platform server can first obtain the original total amount of the bill to be shared, let's say 360 yuan; then, based on the total number of participants, let's assume 4 people (including the user who initiated the sharing and 3 participating users), calculate the average sharing amount. The user who initiated the sharing needs to pay 90 yuan themselves and collect 90 yuan from each of the other 3 participating users, for a total of 270 yuan. If the user has customized the sharing ratio (e.g., someone ordered more food), it will be calculated according to the sharing ratio. Let's assume the user who initiated the sharing pays 40%, or 144 yuan, and the other three participating users each pay 20%, or 72 yuan. In this case, the user who initiated the sharing needs to collect 72 yuan from each of the other three users, for a total of 216 yuan, while also paying 144 yuan themselves.

[0062] A shared bill is a structured data record created by the system after performing a sharing calculation based on the total amount of the bill to be shared, the list of users participating in the sharing, and their respective sharing ratios or weights. The record includes fields such as payee, payer, amount, and bill description. The payee is the user who initiated the sharing, the payers are all the users participating in the sharing except the initiator, and the bill description may include information such as the merchant and the time of consumption.

[0063] In one or more embodiments of this specification, a set of apportionment bills is generated based on the bill to be apportioned and the apportionment participation information of the apportionment participants. This can ensure that the apportionment results are fair and accurate, and avoid disputes caused by errors in amount calculation. It also supports batch generation of bills for all apportionment participants, thus improving processing efficiency.

[0064] Step 212: Send each of the aforementioned cost-sharing invoices to each of the aforementioned cost-sharing participants.

[0065] In practical applications, each shared expense invoice in the shared expense invoice set can be sent to the respective participating users. The shared expense invoice of the user who initiated the expense is sent to that user, and the invoices of other participating users are sent to their respective participating users. The shared expense invoices of participating users are used by the initiating user to confirm their share and do not trigger the payment process; the shared expense invoices of other participating users are used to trigger payment. In practice, after receiving the shared expense invoice, other participating users can click on it, and the client can display a payment page where they can complete the payment.

[0066] In practical applications, if the user who initiated the allocation is not included among the participating users (i.e., the user who initiated the allocation does not participate in this allocation, and the entire amount to be allocated is borne by other users), then the allocation bill set only contains payment instructions from each participating user, not the confirmation slip from the user who initiated the allocation. In this case, the system can send each payment bill to the corresponding participating user, and each participating user will receive a notification stating "You need to pay XX yuan to the initiator." In addition, the system can also send a collection summary notification to the user who initiated the allocation to display the amount payable by each participating user, so that the user who initiated the allocation can understand the specific amount that each participating user needs to pay, thereby keeping a real-time view of the overall allocation situation.

[0067] Figure 2 The method described above retrieves the bills to be shared from the historical payment records of the user initiating the bill sharing based on preset filtering rules. This eliminates the need for users to manually review bills or recall consumption scenarios, significantly reducing the user's operational burden and improving the convenience of the entire bill sharing process. Based on the initiating user's primary geographic location information and other users' secondary geographic location information, candidate users for sharing are determined. The system automatically recommends nearby potential sharing partners, eliminating the need for the initiating user to manually input or search for companions, further reducing the initiating user's operational steps and improving the convenience of the sharing operation. Displaying the user information of candidate sharing participants to the initiating user allows the initiating user to confirm the sharing participants, avoiding misrecommendations and ensuring the accuracy and fairness of the sharing.

[0068] based on Figure 2 In addition to the method described herein, this specification also provides some improved implementation methods, which will be described below.

[0069] For ease of understanding, the embodiments in this specification also provide specific methods for obtaining the bills to be allocated.

[0070] Optionally, obtaining the bill to be allocated from the historical payment records of the user initiating the allocation based on preset filtering rules may specifically include: Obtain the historical payment records of the user who initiated the cost-sharing scheme.

[0071] Calculate the apportionment probability score for each of the aforementioned historical payment records.

[0072] The bill corresponding to the historical payment record with the highest apportionment probability score is determined as the bill to be apportioned.

[0073] After receiving a bill-sharing instruction from the initiating user, the payment platform server first queries the user's historical payment records from the database. Then, it calculates a sharing probability score for each payment record. Finally, the bill with the highest score is output as the bill to be shared.

[0074] In one or more embodiments of this specification, a user's historical payment record refers to the transaction details completed by the user initiating the allocation within a preset historical period (such as the most recent 7 days or 30 days) through the payment platform; it can also be the transaction details of a preset number of transactions recently completed by the user initiating the allocation through the payment platform. Each payment record may include information such as transaction amount, merchant name, payment time, and geographical location.

[0075] The apportionment probability score is a numerical indicator. Specifically, the apportionment probability can be a comprehensive numerical indicator. The system can calculate the apportionment probability score for each bill based on multiple preset evaluation dimensions. The higher the score, the greater the likelihood that the bill is an apportionment-related bill. The evaluation dimensions can include bill amount, merchant type, payment time, etc.

[0076] In one or more embodiments of this specification, by calculating the apportionment probability score of each historical payment record and determining the bill with the highest score as the bill to be apportioned, the accuracy of bill recognition is greatly improved.

[0077] In practical applications, relying on a single feature is usually insufficient to accurately determine whether a bill is a joint purchase by multiple people. For example, large purchases may be for personal purchases of valuable items, dining at restaurants may be for a single person, and nighttime payments may also be for individual consumption. Judging by a single indicator is prone to identification errors. Therefore, the embodiments in this specification provide a reliable method for identifying bills jointly purchased by multiple people.

[0078] Optionally, calculating the apportionment probability score for each of the historical payment records may specifically include: The first score is calculated based on the bill amount in the historical payment records.

[0079] A second score is calculated based on the merchant type in the payment record.

[0080] A third score is calculated based on the payment time of the payment record.

[0081] The first score, the second score, and the third score are aggregated to obtain the apportionment probability score of the historical payment record.

[0082] In one or more embodiments of this specification, the multi-person consumption characteristics of the bill are extracted from the consumption scale, consumption scenario and consumption period by combining three independent dimensions: bill amount, merchant type and payment time. The sharing probability score corresponding to each historical payment record is calculated by weighted fusion processing.

[0083] Specifically, regarding the bill amount: based on typical historical spending patterns, the higher the bill amount, the greater the probability that it represents a shared expense by multiple people. Large purchases generally correspond to group spending scenarios such as meals or team building activities, while small purchases are mostly individual daily expenses. For example, bills over 300 yuan are often associated with social spending by multiple people, while bills under 30 yuan are typically for single individuals. This is used to generate the first dimension score, i.e., the first score. In practical applications, different tiered scores can be pre-set for different amount ranges. For example: purchases under 20 yuan are scored as 0 points, purchases between 20 and 100 yuan as 0.2 points, purchases between 100 and 300 yuan as 0.6 points, and purchases over 300 yuan as 1 point.

[0084] In terms of merchant type: the probability of multi-person consumption is determined based on the merchant's business operation attributes. Restaurants and entertainment venues are generally suitable for group consumption, while convenience stores and gas station payment scenarios are more often for individual consumption. Therefore, combined with merchant classification tags, a second-dimensional score, or second score, can be calculated. For example, higher scores (e.g., 0.9–1.0) can be assigned to merchant types suitable for multi-person consumption, such as restaurants, KTVs, murder mystery games, and escape rooms; lower scores (e.g., 0–0.2) can be assigned to merchant types typically for single-person consumption, such as convenience stores, gas stations, and single-person fast food; and medium scores (e.g., around 0.5) can be assigned to merchants in neutral consumption scenarios such as ride-hailing services and scenic spot tickets.

[0085] In terms of payment time: Based on users' daily consumption behavior characteristics, there is a higher frequency of consumption during evening dining hours, weekends, and social gatherings on holidays, while weekday daytime consumption is mostly sporadic personal office work-related spending. This is used to generate a third-dimensional score, or third score. For example, weekday mornings from 9 to 11 am can be marked as 0.2 points, lunchtimes from 11:30 am to 1:30 pm as 0.6 points, dinnertimes from 6:00 pm to 9:00 pm as 0.9 points, and Friday evenings or the entire weekend as 1.0 points.

[0086] In practical applications, the scores from the three dimensions can be aggregated to obtain the apportionment probability score for each historical payment record. Specifically, the apportionment probability score can be obtained by weighted summation of the first, second, and third scores. Alternatively, the weighted summation result can be normalized, and the normalized value can be used as the apportionment probability score.

[0087] In one or more embodiments of this specification, the multi-dimensional comprehensive scoring logic aligns with users' daily consumption judgment habits, comprehensively considering three key information categories: consumption amount, consumption scenario, and consumption time. It also takes into account "how much money was spent," "where it was spent," and "when it was spent," effectively avoiding recognition bias caused by single-dimensional judgment and significantly improving the accuracy of recognizing multiple consumer bills.

[0088] To improve the accuracy of recommending candidate users for resource allocation and avoid initiating resource allocation to irrelevant or unresponsive users, in one or more embodiments of this specification, user characteristics of other users are further obtained, and geographical location information is combined with user characteristics to jointly determine candidate users for resource allocation.

[0089] Optionally, before determining candidate users to participate in the cost-sharing based on the first geographic location information of the user initiating the cost-sharing and the second geographic location information of other users, the process may further include: Obtain user characteristics of other users, including at least one of the online status information of the other users or the social relationship information between the other users and the user initiating the sharing.

[0090] The process of determining candidate users to participate in the cost-sharing based on the first geographic location information of the user initiating the cost-sharing and the second geographic location information of other users may specifically include: Candidate users for sharing the costs are determined based on the first geographical location information of the user initiating the cost sharing, the second geographical location information of other users, and the user characteristics of the other users.

[0091] In one or more embodiments of this specification, user characteristics may be the user's online status information, or the social relationship information between other users and the user initiating the cost-sharing, or the online status information of other users and the social relationship information between other users and the user initiating the cost-sharing.

[0092] The online status information can refer to the user's client's online status. Specifically, online status information can include whether the client is logged in, whether it is running in the foreground, or whether a specified function page is open. In practical applications, during the process of initiating a multi-person bill sharing instruction after the user who initiated the payment has completed the sharing, they can agree with other sharing participants to open a specified function page on the client, such as the sharing function page, thus facilitating the system's identification of candidate sharing participants. The opening of the specified function page can be pre-set by the system to indicate a specific status for participating in multi-person bill sharing.

[0093] Social relationship information reflects the social connections between other users and the user initiating the cost-sharing scheme. For example, other users may be friends with the initiator on the payment platform, in the same instant messaging group or payment group chat, or have previously participated in cost-sharing schemes together. Generally, users with social connections are more likely to go out and spend money together or participate in group activities. Therefore, combining social relationships with the screening of candidate cost-sharing participants can significantly improve accuracy and reduce irrelevant user recommendations.

[0094] In practical applications, after receiving a bill-sharing instruction from multiple users, the payment platform server can first retrieve other active users within a certain radius from the location service module based on the initial geographic location information to obtain a preliminary list. Then, it obtains the online status information of these users. Additionally, it can query the social relationship database to determine if other users found are friends, group members, or have previous bill-sharing records with the user initiating the bill sharing. Finally, users who meet at least one of the following criteria are identified as candidate participants: "active online" or "has a social relationship with the initiator." If both criteria are met, higher priority can be assigned or the user can be individually marked.

[0095] In one or more embodiments of this specification, candidate users for sharing costs are determined based on geographic location information and user characteristics, which significantly improves the accuracy of the recommendation of candidate users for sharing costs and user satisfaction, reduces the need for the user initiating the sharing to manually delete irrelevant or invalid candidates, and improves convenience.

[0096] For ease of understanding, one or more embodiments of this specification also provide specific methods for determining candidate users to participate in cost sharing based on first geographical location information, second geographical location information, and user characteristics of other users.

[0097] Optionally, determining candidate users to participate in the cost-sharing based on the first geographic location information of the user initiating the cost-sharing, the second geographic location information of other users, and the user characteristics of the other users may specifically include: Based on the second geographic location information, other users whose distance from the first geographic location information is less than the preset distance threshold are selected.

[0098] Determine whether the first other user is online.

[0099] If so, then the first other user is determined as a candidate user for cost-sharing participation.

[0100] or, Based on the second geographic location information, other users whose distance from the first geographic location information is less than the preset distance threshold are selected.

[0101] Determine whether there is a preset social relationship between the first other user and the user who initiated the cost-sharing.

[0102] If so, then the first other user is determined as a candidate user for cost-sharing participation.

[0103] In one or more embodiments of this specification, the first geographical coordinates of the user initiating the allocation can be used as a reference to traverse the second geographical coordinates of other users in the vicinity, calculate the spatial distance between the two, and filter users whose distance is less than a preset distance threshold (e.g., 500 meters) to form a first set of other users.

[0104] In one or more embodiments of this specification, after receiving a bill-sharing instruction from multiple users, the payment platform server can first obtain a first list of other users based on geographical location. Then, each first other user can be judged in a serial or parallel manner based on two dimensions: online status and social relationship. Users who meet either condition can be marked as candidate users for bill sharing. Furthermore, the corresponding user identifier, nickname, avatar, and other information can be added to the candidate list for subsequent display.

[0105] In one or more embodiments of this specification, determining whether the first other user is online may refer to determining whether the client on the terminal device of the first other user is online. The online status of the client may be a pre-set system setting used to identify participation in multi-user bill sharing. The online status may be that the client is running in the foreground or that the client is on a designated function page.

[0106] For example, the online status of the first other user can be queried first. If the user is online, the first other user is directly added to the candidate list without querying social relationships, thus saving computing resources. If the user is offline, the social relationship between the first other user and the user who initiated the sharing can be queried. If the first other user and the user who initiated the sharing have a preset social relationship, the first other user is added to the candidate list. If neither of the two conditions is met, the first other user is excluded.

[0107] For example, you can first query the social relationship between the first other user and the user who initiated the sharing. If the first other user and the user who initiated the sharing have a preset social relationship, then add the first other user to the candidate list without querying the online status. If the first other user and the user who initiated the sharing do not have a preset social relationship, then you can continue to query the online status of the first other user. If the first other user is online, then add the first other user to the candidate list. If neither of the two conditions is met, then exclude the first other user.

[0108] For example, the online status of the first other user and the social relationship between the first other user and the user who initiated the sharing can be queried in parallel. When any query result shows that the first other user meets the selection criteria, the other data query process can be terminated to quickly complete the user screening.

[0109] For the first other user who meets both conditions, the system can prioritize them in the candidate list or add special tags, such as "friend and online", to assist in the decision-making of the user initiating the allocation.

[0110] In one or more embodiments of this specification, a specific method for determining whether a first other user is online is also provided.

[0111] Optionally, determining whether the first other user is online may specifically include: Obtain the client running status of the first other user.

[0112] If the client running status indicates that the client is running in the foreground, then it is determined that the first other user is online.

[0113] Client running status refers to the active state of the client on the terminal device. Client running status can include foreground running, background running, and not started. Foreground running means the client is displayed on the terminal device's interface and supports real-time user interaction. Background running means the client is hidden in the terminal's background, without a visual interface, and does not currently support direct interaction. Not started means the client has not been woken up and is not running on the terminal device.

[0114] In practical applications, after the payment platform server identifies the first other user, it can send a status probe message to each of the first other user's terminal devices. Upon receiving this message, the client on the terminal device checks the running status of its own program: if the current interface is in the foreground, it returns a foreground status code, which can be "1" or "foreground"; if the application is in the background or not running, it returns an offline status code, which can be "0" or "background". The payment platform server determines the online status of the first other user based on the terminal feedback.

[0115] In one or more embodiments of this specification, the client being in the foreground running state can be a pre-set state by the system to identify a specified state for participating in multi-person bill sharing. During the process of initiating a multi-person bill sharing instruction after the initiating user completes payment, they can agree with other participating users to open the client and keep it running in the foreground. Since the client being in the foreground running state is a specified state set by the system to identify participation in multi-person bill sharing, the system can determine that the first other user's client is likely a participant in this cost sharing by detecting that the first other user's client is in the foreground running state.

[0116] In one or more embodiments of this specification, a specified state for identifying participants in a multi-person bill sharing is pre-set. Combined with the verbal agreement between the user initiating the sharing and their companions, such as opening the client in advance and keeping it running in the foreground, the accuracy of the system in screening candidate users to participate in this sharing can be improved, the manual deletion of irrelevant or invalid candidates by the user initiating the sharing can be reduced, and convenience can be improved.

[0117] In one or more embodiments of this specification, another specific method for determining whether a first other user is online is also provided.

[0118] Optionally, determining whether the first other user is online may specifically include: Obtain the current page identifier of the client of the first other user.

[0119] If the current page identifier indicates that the first other user is on the specified function page, then it is determined that the first other user is online.

[0120] In one or more embodiments of this specification, the client being on a designated function page may be a pre-set state by the system to identify a participant in multi-person bill sharing. This designated function page may be a multi-person bill sharing function page. During the process of initiating a multi-person bill sharing instruction after the initiating user completes payment, they may agree with other participating users to open the multi-person bill sharing function page. Since the client being on the bill sharing function page is a system-set state to identify participation in multi-person bill sharing, the system can determine that the first other user's client is likely a participant in this cost sharing by detecting that the first other user's client is on the bill sharing function page.

[0121] The current page identifier is a unique identifier used to identify the interface currently displayed on the client. The current page identifier can include a unique interface identifier or a page access path. The unique interface identifier can be a page ID or page name, such as "AA Payment Page" or "Group Payment Page". The page access path can be a page routing string.

[0122] In practical applications, payment platforms can embed tracking points on the client side to record the identifier of each page. After the server identifies the first other user, it sends a "get current page" command through a push channel. The client calls its own page stack management interface to obtain the identifier of the top page of the stack and encapsulates this identifier in a response message. Upon receiving this message, the server compares it with a pre-defined list of identifiers for multi-user bill sharing function pages: if they match, the user is considered online; if they do not match, such as if the user is on a page other than the "My Wallet" or "Bill List" page (not part of the multi-user bill sharing function), the user is considered offline.

[0123] In one or more embodiments of this specification, a designated state for identifying participants in a multi-person bill sharing is pre-set. Combined with the verbal agreement between the user initiating the sharing and their companions, such as opening the multi-person bill sharing function page in advance, the accuracy of the system in filtering candidate users to participate in this sharing is improved, the manual deletion of irrelevant or invalid candidates by the user initiating the sharing is reduced, and the convenience is improved.

[0124] For ease of understanding, one or more embodiments of this specification also provide specific methods for determining whether there is a preset social relationship between the first other user and the user who initiated the cost-sharing.

[0125] Optionally, determining whether the first other user and the user initiating the cost-sharing have a preset social relationship may specifically include: Obtain the social network graph of the first other user and the user who initiated the cost-sharing.

[0126] Based on the social network graph, it is determined whether the first other user and the user who initiated the cost-sharing are friends within the payment application; or whether the first other user and the user who initiated the cost-sharing are in the same instant messaging group; or whether the first other user and the user who initiated the cost-sharing have jointly participated in cost-sharing with multiple people.

[0127] If so, it is determined that the first other user and the user who initiated the cost-sharing have a preset social relationship.

[0128] In one or more embodiments of this specification, a social network graph can refer to a graph-structured data model constructed by a payment platform based on data such as friend relationships, group relationships, and historical interaction records among users. A social network graph uses each user as a node and the relationships between users (such as friends, group members, and jointly participated events) as edges. Based on a social network graph, it is possible to quickly query the direct or indirect relationships between any two users.

[0129] In practical applications, after obtaining the social network graphs corresponding to the first other user and the user who initiated the cost-sharing, it can be determined based on the social network graphs whether the first other user and the user who initiated the cost-sharing are friends on the payment application, whether they are in the same communication group, or whether there are historical records of shared bills. If any one of these conditions is met, it can be determined that the first other user and the user who initiated the cost-sharing have a preset social relationship.

[0130] In practical applications, you can determine if the first other user and the user who initiated the cost-sharing are friends on the payment app by checking if they follow each other or have a confirmed friend relationship. You can also determine if they are in the same communication group by searching the group member table to see if they appear under the same group ID. Finally, you can determine if they have a history of jointly sharing bills by checking if their historical bills contain both of them.

[0131] In practical applications, users with social connections are more likely to go out for consumption or participate in group activities together. In one or more embodiments of this specification, by obtaining a social network graph, it is determined whether the first other user and the user who initiated the sharing are friends, in the same group, or have a history of sharing together to determine the preset social relationship, thereby filtering users who have social connections with the user who initiated the sharing. This improves the social matching degree between the candidate sharing participants and the user who initiated the sharing, and reduces the embarrassment and harassment risk of initiating sharing with unrelated users.

[0132] In practical applications, in multi-person consumption scenarios such as travel and dining out, multiple people often pay for different portions of the bill. For example, one person pays for the main course, another for drinks, and a third for a deposit. Traditional multi-person cost-sharing schemes typically only allocate costs based on a single bill and cannot automatically identify and merge multiple payment records from the same consumption scenario. This leads to unfair cost-sharing results or requires users to manually calculate the difference, which is complex and prone to errors. To address this technical problem, this specification provides further solutions in one or more embodiments.

[0133] Optionally, before generating the apportionment bill based on the bill to be apportioned and the apportionment participation information of the participating users, the process may further include: The system checks whether any of the users participating in the cost-sharing process have any targeted payment records for the merchant to which the bill to be shared belongs.

[0134] If such a situation exists, a merged accounting query is sent to the user who initiated the apportionment process. The merged accounting query is used to inquire whether the user agrees to merge the targeted payment bill corresponding to the targeted payment record with the bill to be apportioned.

[0135] The process of generating a set of allocated bills based on the bills to be allocated and the allocation participation information of the participating users may specifically include: If an instruction is received from the user who initiated the cost-sharing to agree to merge the cost-sharing, a cost-sharing bill set is generated based on the cost-sharing participation information of the targeted payment bill and the bill to be shared.

[0136] In one or more embodiments of this specification, a targeted payment record refers to other payment records generated by participating users within a preset time period for the same merchant as the bill to be shared. Participating users include the user initiating the sharing and other participating users. The preset time period can be a preset time window before or after the payment time of the bill to be shared, such as one hour before the payment of the bill to be shared and twenty minutes after the payment. Targeted payment records typically reflect situations where multiple people pay different amounts in the same consumption scenario, such as one person paying for a main dish, another paying for drinks, and a third paying a deposit.

[0137] After determining the users participating in the cost-sharing, the server can iterate through the most recent payment records of each user, filter out payment records from the same merchant and with similar times as the bill to be shared, generate a consolidation inquiry message, and send it to the device terminal of the user initiating the cost-sharing. The consolidation inquiry is displayed in interactive forms such as pop-ups and system notifications. For example, the consolidation inquiry content could be as follows: "It was detected that participant 'Bao Ge' paid 50 yuan at XX Hot Pot Restaurant at 19:35, and Huan Yan paid 30 yuan at XX Hot Pot Restaurant at 19:28. Should these amounts be consolidated and calculated uniformly?" The server can also provide "Consolidation" and "Calculate Only Based on My Bills" option buttons for each targeted payment bill, allowing the user initiating the cost-sharing to choose.

[0138] In practical applications, after the server identifies the participating users, the merchant identifiers corresponding to the bills to be allocated, and the preset time range, it can query the payment records of each participating user one by one, matching transaction records of the same merchant and within the same time interval. If only the user who initiated the allocation has a corresponding bill, there are no additional targeted payment records; if other participating users have payment records for the same merchant during the same period, the corresponding transaction records are extracted as targeted payment records. A merged accounting query message is generated from these targeted payment records and sent to the initiator's terminal.

[0139] If the user who initiated the cost-sharing confirms the merger, the server can aggregate the payment amounts from the bill to be shared and all targeted payment records, recalculate the average cost-sharing amount per person based on the number of participants, and automatically settle the difference that each user should pay or be refunded. If the user who initiated the cost-sharing refuses to merge, only the original bill to be shared will be allocated, ignoring the other targeted payment records.

[0140] In one or more embodiments of this specification, by identifying multiple scattered payment transactions from the same merchant and within similar time periods, users can choose whether to merge bills for unified accounting, effectively adapting to dining scenarios where multiple people pay separately. Compared to traditional cost-sharing methods that cannot identify separate bills and require manual calculation of differences, this significantly reduces the complexity of calculations and the probability of errors, improving the fairness of cost-sharing and ease of use; at the same time, the adoption of a manual confirmation and inquiry mechanism avoids the system automatically erroneously merging bills, fully protecting the user's right to choose.

[0141] The following is in conjunction with the appendix Figure 4 This paper further explains how to handle the splitting of bills among multiple people, using the example of splitting the bill after a friend's meal. Figure 4 A flowchart illustrating a method for processing bills shared by multiple people according to an embodiment of this specification is shown, including the following steps.

[0142] Step 402: Obtain the bill to be allocated from the historical payment records of the user who initiated the allocation based on the preset filtering rules.

[0143] Suppose Zhang, Li, Wang, and Zhao dine together, spending a total of 360 yuan. Zhang pays using a payment platform. Zhang then opens the multi-person bill-sharing function on the payment platform and clicks to initiate a multi-person bill-sharing instruction. Upon receiving the instruction, the payment platform server retrieves Zhang's payment history for the past 7 days, totaling 10 transactions. The system calculates the probability score for each transaction based on the bill amount, merchant type, and payment time. The hot pot restaurant bill receives the highest score, and the system automatically identifies this hot pot bill as the bill to be shared.

[0144] Step 404: Based on the first geographical location information of the user who initiated the cost sharing, filter out the first other users whose distance from the first geographical location information is less than the preset distance threshold.

[0145] The system obtains Xiao Zhang's current GPS coordinates and searches for other active users within 5 meters of him, identifying 10 nearby users. These 10 users are the first group of other users.

[0146] Step 406: Select the second group of other users who are online from the first group of other users as candidate users to participate in the cost sharing.

[0147] The "online" status among the first "other users" refers to the online status of the client device on the terminal device of the first "other user." This online status is pre-set by the system to identify a specific state for participating in multi-user bill sharing. In practical applications, when Xiao Zhang initiates a multi-user bill sharing instruction after payment, he can agree with other participating users to open their clients in advance to ensure they are online. This facilitates the system's screening of candidate participants, improving the accuracy of the system's screening process, reducing the need for the initiating user to manually delete irrelevant or invalid candidates, and enhancing convenience.

[0148] Continuing with the previous example, assuming that among the 10 users mentioned above, Xiao Li, Xiao Wang, Xiao Zhao, Xiao Qian, and Xiao Wu are online, the system can identify Xiao Li, Xiao Wang, Xiao Zhao, Xiao Qian, and Xiao Wu as candidate users to participate in the cost sharing.

[0149] Step 408: Display the user information of the candidate participants in the sharing to the user who initiated the sharing.

[0150] The payment platform server can send the avatars, nicknames, and relationship tags (such as "friends" or "group members") of the above five candidate users to Xiao Zhang's client. The client can display them in a horizontal scrolling list: the first row shows Xiao Li, Xiao Wang, and Xiao Zhao (marked "friends"), and the second row shows Xiao Qian and Xiao Zhou (marked "XX group"), with checkboxes.

[0151] Step 410: Receive the selection instruction from the user who initiated the cost-sharing and determine the users participating in the cost-sharing.

[0152] After seeing the list, Xiao Zhang can select the three users who actually participated in the meal: Xiao Li, Xiao Wang, and Xiao Zhao, and then click the "Confirm" button. The system receives the selection instruction and confirms Xiao Li, Xiao Wang, and Xiao Zhao as the participants in the meal sharing. Xiao Zhang can also select himself to participate in the sharing using the "My Participation" button on the interface. In actual application, the user who initiates the sharing can be selected by default, ultimately confirming a total of four participants: Xiao Zhang, Xiao Li, Xiao Wang, and Xiao Zhao.

[0153] Step 312: Determine whether any of the users participating in the cost-sharing have a record of targeted payment to the merchant to which the bill to be shared belongs.

[0154] After the system identifies four users—Zhang, Li, Wang, and Zhao—as participants in the cost-sharing, it can obtain the merchant information for the bill to be shared, assuming it's a hot pot restaurant (XX), and the payment time, assuming it's Friday evening at 7:30 PM. Then, it can iterate through payment records made by Zhang, Li, Wang, and Zhao at that merchant, where the payment time differs from the bill's time by no more than a preset threshold. The detection results show that: Xiao Zhang: There is only one bill of 360 yuan to be shared (no other records).

[0155] Xiao Li: There was a payment of 50 yuan for alcohol, with the same merchant, and the payment time was 19:35.

[0156] Xiao Wang: No other payment records.

[0157] Xiao Zhao: There was a payment of 30 yuan for adding dishes, with the same merchant, and the payment time was 19:28.

[0158] You can mark Xiao Li's 50 yuan and Xiao Zhao's 30 yuan as targeted payment records.

[0159] Step 414: If yes, send a consolidated accounting query to the user who initiated the allocation; if no, proceed to step 320. The consolidated accounting inquiry is used to ask whether the user agrees to consolidate the targeted payment bill corresponding to the targeted payment record with the bill to be allocated.

[0160] Because a targeted payment record was detected, the system sent a consolidation query to the user who initiated the cost-sharing, Xiao Zhang. This query, presented as a pop-up or notification, could read: "Participants 'Xiao Li' paid 50 yuan at XX Hot Pot Restaurant at 19:35, and 'Xiao Zhao' paid 30 yuan at XX Hot Pot Restaurant at 19:28. Should these amounts be consolidated for unified accounting?" Xiao Zhang can also choose between "Consolidation" and "Accounting Only Based on My Bills" options for each targeted payment transaction.

[0161] Step 416: Determine if an instruction has been received from the user who initiated the cost-sharing to agree to merge the cost-sharing.

[0162] Step 418: If yes, generate a set of apportionment bills based on the apportionment participation information of the targeted payment bills and the bills to be apportioned. If no, proceed to step 320.

[0163] In practical application, if Xiao Zhang clicks the "Consolidate Accounting" button, the system can receive an instruction to agree to the consolidation. The payment platform server can then execute the consolidation accounting. Specifically, the bill to be allocated can be merged with the designated payment bill. Assuming the bill to be allocated is 360 yuan, the total amount is 360 + 50 + 30 = 440 yuan. There are 4 users involved in the allocation; calculated using an average allocation method, each person should pay 110 yuan. Further calculations can be made to determine the amount each person should pay or be refunded. Xiao Zhang: I have already paid 360 yuan, I should pay 110 yuan, and I overpaid 250 yuan (250 yuan should be recovered).

[0164] Xiao Li: I have already paid 50 yuan, I should pay 110 yuan, and I need to pay an additional 60 yuan.

[0165] Xiao Zhao: I have already paid 30 yuan, I should pay 110 yuan, and I need to pay an additional 80 yuan.

[0166] Xiao Wang: The payment has not been made. You should pay 110 yuan. You need to pay 110 yuan.

[0167] Step 420: Generate a set of allocated bills based on the allocation participation information of the bills to be allocated.

[0168] Step 422: Send each contribution bill to each participating user.

[0169] The server pushed the payment bill to Xiao Li, Xiao Wang, and Xiao Zhao respectively, and all three received a notification on their mobile phones. At the same time, a payment sharing confirmation was pushed to Xiao Zhang, showing "You need to pay 90 yuan. Payment has been initiated to 3 people, with a total of 250 yuan due." After Xiao Li clicked to pay, Xiao Zhang received a notification of receipt in real time. Once all three had completed their payments, this multi-person payment sharing ended.

[0170] Through the above steps, Xiao Zhang no longer needs to manually enter the amount, search for friends, or calculate the cost per person. The system automatically completes bill recognition, user referral for allocation, allocation calculation, and payment delivery, significantly improving the convenience and efficiency of handling bills shared by multiple people.

[0171] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods.

[0172] Figure 5 This is a schematic diagram of a device for processing bills shared by multiple people, provided as an embodiment of this specification.

[0173] like Figure 5 As shown, the device may include: The bill to be allocated module 502 is used to obtain the bill to be allocated from the historical payment records of the user who initiated the allocation based on preset filtering rules.

[0174] The candidate sharing participant determination module 504 is used to determine candidate sharing participants based on the first geographical location information of the sharing initiator user and the second geographical location information of other users; the distance between the second geographical location information of the candidate sharing participants and the first geographical location information is less than a preset distance threshold.

[0175] The display module 506 is used to display the user information of the candidate participants in the sharing to the user who initiated the sharing.

[0176] The user allocation participant determination module 508 is used to receive the selection instruction from the user initiating the allocation and determine the users participating in the allocation.

[0177] The shared bill generation module 510 is used to generate a shared bill set based on the bill to be shared and the sharing participation information of the sharing participants.

[0178] The shared bill sending module 512 is used to send each of the shared bills to each of the shared participants.

[0179] Optionally, the bill to be allocated acquisition module 502 may specifically include: The acquisition unit is used to acquire the historical payment records of the user who initiated the cost-sharing.

[0180] A calculation unit is used to calculate the apportionment probability score for each of the historical payment records.

[0181] The determining unit is used to determine the bill corresponding to the historical payment record with the highest apportionment probability score as the bill to be apportioned.

[0182] Optionally, the computing unit may be specifically used for: The first score is calculated based on the bill amount in the historical payment records.

[0183] A second score is calculated based on the merchant type in the payment record.

[0184] A third score is calculated based on the payment time of the payment record.

[0185] The first score, the second score, and the third score are aggregated to obtain the apportionment probability score of the historical payment record.

[0186] Optional, such as Figure 4 The apparatus shown may further include: The user feature acquisition module is used to acquire user features of other users, wherein the user features include at least one of the online status information of the other users or the social relationship information between the other users and the user who initiated the sharing.

[0187] The candidate allocation participant determination module 504 can be specifically used for: Candidate users for sharing the costs are determined based on the first geographical location information of the user initiating the cost sharing, the second geographical location information of other users, and the user characteristics of the other users.

[0188] Optionally, the candidate apportionment participant determination module 504 may specifically include: The first other user filtering unit is used to filter out first other users whose distance from the first geographical location information is less than the preset distance threshold based on the second geographical location information.

[0189] The first judgment unit is used to determine whether the first other user is online.

[0190] The candidate cost-sharing participant determination unit is used to determine the first other user as a candidate cost-sharing participant if the condition is met. or, The first other user filtering unit is used to filter out first other users whose distance from the first geographical location information is less than the preset distance threshold based on the second geographical location information.

[0191] The second judgment unit is used to determine whether there is a preset social relationship between the first other user and the user who initiated the sharing.

[0192] The candidate cost-sharing participant determination unit is used to determine the first other user as a candidate cost-sharing participant if the condition is met.

[0193] Optionally, the first determination unit may be specifically used for: Obtain the client running status of the first other user.

[0194] If the client running status indicates that the client is running in the foreground, then it is determined that the first other user is online.

[0195] Optionally, the first determination unit may be specifically used for: Obtain the current page identifier of the client of the first other user.

[0196] If the current page identifier indicates that the first other user is on the multi-user bill sharing function page, then it is determined that the first other user is online.

[0197] Optionally, the second determination unit may be specifically used for: Obtain the social network graph of the first other user and the user who initiated the cost-sharing.

[0198] Based on the social network graph, it is determined whether the first other user and the user who initiated the cost-sharing are friends within the payment application; or whether the first other user and the user who initiated the cost-sharing are in the same instant messaging group; or whether the first other user and the user who initiated the cost-sharing have jointly participated in cost-sharing with multiple people.

[0199] If so, it is determined that the first other user and the user who initiated the cost-sharing have a preset social relationship.

[0200] Optional, such as Figure 5 The apparatus shown may further include: The targeted payment record detection module is used to detect whether there are any targeted payment records for the merchant to which the bill to be shared belongs among the users participating in the cost-sharing.

[0201] The merged accounting query sending module is used to send a merged accounting query to the user who initiated the apportionment if such a query exists. The merged accounting query is used to ask whether the user agrees to merge the targeted payment bill corresponding to the targeted payment record with the bill to be apportioned.

[0202] The apportionment bill generation module 410 can be used specifically for: If an instruction is received from the user who initiated the cost-sharing to agree to merge the cost-sharing, a cost-sharing bill set is generated based on the cost-sharing participation information of the targeted payment bill and the bill to be shared.

[0203] The above is a schematic scheme of a bill-sharing processing device for multiple users according to this embodiment. It should be noted that the technical solution of this bill-sharing processing device and the technical solution of the bill-sharing processing method described above belong to the same concept. For details not described in detail in the technical solution of the bill-sharing processing device, please refer to the description of the technical solution of the bill-sharing processing method described above.

[0204] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments.

[0205] Figure 6 A schematic diagram of the structure of a computing device 600 provided according to an embodiment of this specification is shown.

[0206] The computing device 600 includes: Memory 610 and processor 620; The memory 610 is used to store computer programs / instructions, and the processor 620 is used to execute the computer programs / instructions, which, when executed by the processor 620, implement the steps of the method for processing bills shared by multiple people.

[0207] Specifically, the components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and the database 650 is used to store data.

[0208] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0209] In one embodiment of this specification, the above-described components of the computing device 600 and Figure 6 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0210] The computing device 600 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 600 can also be a mobile or stationary server.

[0211] The processor 620 executes the computer instructions to implement the steps of the method for processing bills shared by multiple users.

[0212] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described method for processing bills shared by multiple users belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described method for processing bills shared by multiple users.

[0213] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for apparatuses, devices, and embodiments, since they are basically similar to the method embodiments, the descriptions are relatively simple, and relevant parts can be referred to the descriptions of the method embodiments. The apparatuses, devices, and methods provided in the embodiments of this specification are corresponding to each other, and therefore the apparatuses and devices also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding apparatuses and devices will not be repeated here.

[0214] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0215] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0216] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0217] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0218] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0219] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, the invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0220] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0221] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0222] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0223] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0224] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0225] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital character versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0226] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0227] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for processing bills shared by multiple people, comprising: The bill to be allocated is obtained from the historical payment records of the user who initiated the allocation based on preset filtering rules; Based on the first geographic location information of the user initiating the cost-sharing, and the second geographic location information of other users, candidate users for cost-sharing are determined; the distance between the second geographic location information and the first geographic location information of the candidate users is less than a preset distance threshold. Display the user information of the candidate participants in the cost-sharing process to the user who initiated the cost-sharing process. Receive the selection instruction from the user who initiated the cost-sharing, and determine the users participating in the cost-sharing; A set of allocated bills is generated based on the bills to be allocated and the allocation participation information of the participating users. The set of allocated bills includes the allocated bills of each of the participating users. Each of the aforementioned cost-sharing invoices will be sent to each of the aforementioned cost-sharing participants.

2. The method according to claim 1, wherein obtaining the bill to be allocated from the historical payment records of the user initiating the allocation based on preset filtering rules specifically includes: Obtain the historical payment records of the user who initiated the cost-sharing scheme; Calculate the apportionment probability score for each of the aforementioned historical payment records; The bill corresponding to the historical payment record with the highest apportionment probability score is determined as the bill to be apportioned.

3. The method according to claim 2, wherein calculating the apportionment probability score for each of the historical payment records specifically includes: Calculate the first score based on the bill amount in the historical payment records; Calculate the second score based on the merchant type in the payment record; Calculate the third score based on the payment time of the payment record; The first score, the second score, and the third score are aggregated to obtain the apportionment probability score of the historical payment record.

4. The method according to claim 1, before determining the candidate users to participate in the cost-sharing based on the first geographic location information of the user initiating the cost-sharing and the second geographic location information of other users, further comprising: Obtain user characteristics of other users, wherein the user characteristics include at least one of the online status information of the other users or the social relationship information between the other users and the user initiating the sharing; The process of determining candidate users to participate in the cost-sharing based on the first geographic location information of the user initiating the cost-sharing and the second geographic location information of other users specifically includes: Candidate users for sharing the costs are determined based on the first geographical location information of the user initiating the cost sharing, the second geographical location information of other users, and the user characteristics of the other users.

5. The method according to claim 4, wherein determining candidate users to participate in the cost-sharing based on the first geographic location information of the user initiating the cost-sharing, the second geographic location information of other users, and the user characteristics of the other users specifically includes: Based on the second geographic location information, other first users whose distance from the first geographic location information is less than the preset distance threshold are selected. Determine whether the first other user is online; If so, then the first other user is determined to be a candidate user for cost-sharing participation; or, Based on the second geographic location information, other first users whose distance from the first geographic location information is less than the preset distance threshold are selected. Determine whether there is a preset social relationship between the first other user and the user who initiated the cost-sharing; If so, then the first other user is determined as a candidate user for cost-sharing participation.

6. The method according to claim 5, wherein determining whether the first other user is online specifically includes: Obtain the client running status of the first other user; If the client running status indicates that the client is running in the foreground, then it is determined that the first other user is online.

7. The method according to claim 5, wherein determining whether the first other user is online specifically includes: Obtain the current page identifier of the client of the first other user; If the current page identifier indicates that the first other user is on the multi-user bill sharing function page, then it is determined that the first other user is online.

8. The method according to claim 5, wherein determining whether there is a preset social relationship between the first other user and the user initiating the cost-sharing specifically includes: Obtain the social network graph of the first other user and the user who initiated the cost-sharing; Based on the social network graph, it is determined whether the first other user and the user who initiated the cost-sharing are friends within the payment application; Alternatively, whether the first other user and the user who initiated the cost-sharing are in the same instant messaging group; or whether the first other user and the user who initiated the cost-sharing have jointly participated in a multi-person cost-sharing scheme. If so, it is determined that the first other user and the user who initiated the cost-sharing have a preset social relationship.

9. The method according to claim 1, further comprising, before generating the set of allocated bills based on the bills to be allocated and the allocation participation information of the participating users: Detect whether there are any targeted payment records for the merchant to which the bill to be shared belongs among the users participating in the cost-sharing; If it exists, a merged accounting query is sent to the user who initiated the allocation; The consolidated accounting inquiry is used to ask whether the user agrees to consolidate and allocate the targeted payment bill corresponding to the targeted payment record with the bill to be allocated. The process of generating a set of allocated bills based on the bills to be allocated and the allocation participation information of the participating users specifically includes: If an instruction is received from the user who initiated the cost-sharing to agree to merge the cost-sharing, a cost-sharing bill set is generated based on the cost-sharing participation information of the targeted payment bill and the bill to be shared.

10. A processing apparatus for sharing bills among multiple people, comprising: The unallocated bill acquisition module is used to obtain the unallocated bill from the historical payment records of the user who initiated the allocation based on preset filtering rules; The candidate sharing participant determination module is used to determine candidate sharing participants based on the first geographical location information of the sharing initiator user and the second geographical location information of other users; the distance between the second geographical location information of the candidate sharing participants and the first geographical location information is less than a preset distance threshold. The display module is used to display the user information of the candidate participants in the cost-sharing to the user who initiated the cost-sharing; The apportionment participant determination module is used to receive the selection instruction from the apportionment initiator user and determine the apportionment participants. The shared bill generation module is used to generate a set of shared bills based on the bill to be shared and the shared participation information of the users participating in the shared bill; The shared bill sending module is used to send each of the shared bills to each of the shared participants.

11. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 9.

Images