WO2024168318A2

WO2024168318A2 - System and method for integration of disparate information of network participants

Info

Publication number: WO2024168318A2
Application number: PCT/US2024/015279
Authority: WO
Inventors: Eldar CHAIZHUNUSSOV; Julien LUNDGREN
Original assignee: Individual
Current assignee: Individual
Priority date: 2023-02-09
Filing date: 2024-02-09
Publication date: 2024-08-15
Anticipated expiration: 2025-08-09
Also published as: WO2024168318A3

Abstract

An electronic server system receives user data from a plurality of user devices; creates a plurality of user accounts based on the user data; and receives an event creation request specifying an event and two or more user accounts of the plurality of user accounts for association with the event. In response to the event creation request, the server system instantiates a group chat including the two or more user accounts; receives a plurality of first electronic items associated with the event from respective user devices via the group chat, including a plurality of bill totals or a plurality of images; creates a plurality of second electronic items based on the plurality of first electronic items, including a plurality of amounts owed or a plurality of formatted images; and transmits the plurality of second electronic items to the respective user devices via the group chat.

Description

System and Method for Integration of Disparate Information of Network Participants

RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 63/484,158, filed February 9, 2023, entitled “System and Method for Integration of Disparate Information of Network Participants.”

TECHNICAL FIELD

[0002] This application relates generally to computer network technology, including but not limited to systems and methods for real-time, knowledge-based integration of disparate financial, social, and geographical information of network participants.

BACKGROUND

[0003] Spending time with friends and making memories is an invaluable part of our lives. However, there are reoccurring inconveniences that come with friend gatherings. For example, organizing the event, coordinating with friends, evenly splitting the costs, and sharing pictures with each other become more difficult as the group grows and the event becomes more involved. Oftentimes, these difficulties can prevent friend gatherings from happening altogether.

[0004] The use of mobile devices to set up and coordinate friend gatherings can be complicated by the different operating systems of the devices. Depending on the application, some operating systems can be at least partially incompatible with competing operating systems. For example, the group texting experience can be hobbled by proprietary texting formats not supporting each other’s standards. An image or video clip shared through a group chat may be extremely compressed when using short messaging service (SMS), which is often the default standard when competing operating systems do not open up their proprietary texting standards to each other. Thus, in some scenarios, participants in a friend gathering who do not have a mobile device that uses the same operating system as a majority of the group may be left out of group chats.

[0005] Bill splitting is another aspect of friend gatherings. Oftentimes, at the end of an event, friends determine who spent money on what, who owes how much to whom, and so forth. The use of mobile devices to facilitate bill splitting is complicated by the availability or the unavailability of certain peer-to-peer payment applications on each participant’s device. Moreover, even if each participant had the same payment application, it can be difficult to determine the transfer of money when different participants paid for different aspects of the gathering, and multiple friends owe different amounts to, or are owed different amounts from, multiple other friends. In such scenarios, it is common for some friends to underpay at the expense of others.

[0006] Group formation is yet another aspect of friend gatherings that may be overwhelming and difficult to manage. Factors such as group size, availabilities, conflicting budgets, and other differences in personal preferences can make event group formation arduous at best and impossible at worst. In addition, group formation can be affected in scenarios in which there are many different event-related possibilities, such as which event to attend and when to show up. A seemingly minor adjustment to one variable can cause the group to fall apart or event prevent a group from forming in the first place.

[0007] Thus, organization of friend gatherings can be a long and unnecessarily complicated process, with participants feel like they are left out or overpaying, and formation of the gathering becoming overwhelming.

SUMMARY

[0008] Based on the discussion above as well as other problems and disadvantages of the related art, there is a need for a system that can integrate disparate information of network participants and facilitate events and gatherings. A networking platform implementing such a system could handle many of the tedious aspects of friend gatherings, making them easier to organize and smoother to run. Such a platform may be configured to make friend gathering organization easier and more efficient with features to ameliorate specific aspects of friend gatherings such as bill-splitting and picture sharing. The platform can feature electronic invites, group chats with add-on features, and functionality for booking restaurants and hotels and purchasing tickets.

[0009] According to one or more aspects of the networking platform described herein, an electronic server system includes one or more processors and memory storing one or more programs for execution by the one or more processors. The one or more programs include instructions for: receiving user data from a plurality of user devices; creating a plurality of user accounts based on the user data received from the plurality of user devices; and receiving an event creation request from a first user account of the plurality of user accounts, wherein the event creation request specifies an event and two or more user accounts of the plurality of user accounts for association with the event.

[0010] The one or more programs include instructions for: in response to receiving the event creation request, instantiating a group chat including the two or more user accounts; receiving a plurality of first electronic items associated with the event from respective user devices associated with the two or more user accounts via the group chat, wherein the plurality of first electronic items include a plurality of bill totals or a plurality of images; creating a plurality of second electronic items based on the plurality of first electronic items, wherein the plurality of second electronic items include a plurality of amounts owed or a plurality of formatted images; and transmitting the plurality of second electronic items to the respective user devices associated with the two or more user accounts via the group chat.

[0011] In some implementations, the plurality of first electronic items include a plurality of bill totals associated with the event, and the one or more programs further include instructions for: associating each bill total of the plurality of bill totals to a respective user account of the two or more user accounts; and receiving a trigger to process a group bill.

[0012] In some implementations, in response to receiving the trigger, the one or more programs further include instructions for: combining the plurality of bill totals into a group bill total; dividing the group bill total by a total number of the two or more user accounts to determine a per-user contribution amount; determining a plurality of respective differences between the per-user contribution amount and respective bill totals of the plurality of bill totals; and determining a plurality of amounts owed corresponding to respective user accounts of the two or more user accounts based on the plurality of respective differences between the per-user contribution amount and the respective bill totals of the plurality of bill totals; wherein the instructions for transmitting the plurality of second electronic items include instructions for transmitting the plurality of amounts owed corresponding to the respective user accounts of the two or more user accounts.

[0013] In some implementations, the one or more programs further include instructions for: automatically generating one or more peer-to-peer payment links for one or more of the two or more user accounts; and transmitting the one or more peer-to-peer payment links to one or more user devices associated with one or more of the two or more user accounts via the group chat; wherein each of the one or more peer-to-peer payment links is configured to (i) request a payment from one user account of the two or more user accounts corresponding to a respective amount owed of the plurality of amounts owed, and (ii) transfer at least a portion of the payment to another user account of the two or more user accounts.

[0014] In some implementations, the plurality of first electronic items include a plurality of images, and the one or more programs further include instructions for: determining a plurality of user device types based on the user data corresponding to respective user accounts of the two or more user accounts; determining a plurality of image format requirements respectively corresponding to the plurality of user device types; and processing each of the plurality of images to produce the plurality of formatted images according to the plurality of image format requirements; wherein the instructions for transmitting the plurality of second electronic items include instructions for transmitting the plurality of formatted images.

[0015] In some implementations, the one or more programs further include instructions for: receiving a recommendation request from a user device corresponding to one of the two or more user accounts via the group chat, wherein the recommendation request includes an instruction to view a list of events or venues recommended for inclusion in the event; determining the list of events or venues for recommending for inclusion in the event; and transmitting the list of events or venues to the respective user devices associated with the two or more user accounts via the group chat.

[0016] In some implementations, the one or more programs further include instructions for: receiving a reservation request from a user device corresponding to one of the two or more user accounts via the group chat, wherein the reservation request includes an instruction to process a reservation for a venue associated with the event; automatically processing the reservation for the venue in accordance with the instruction; and transmitting information corresponding to the reservation to the respective user devices associated with the two or more user accounts via the group chat.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] For a better understanding of the various described implementations, reference should be made to the Detailed Description below, in conjunction with the following drawings. Like reference numerals refer to corresponding parts throughout the drawings.

[0018] Figure 1 is a diagram of a networking platform in accordance with some implementations. [0019] Figure 2 is a flow diagram of a networking method in accordance with some implementations.

[0020] Figure 3 is a flow diagram of a bill splitting feature of a networking method in accordance with some implementations.

[0021] Figure 4 is a diagram of a bill splitting example in accordance with some implementations.

[0022] Figure 5 is a flow diagram of an image sharing feature of a networking method in accordance with some implementations.

[0023] Figure 6 is a flow diagram of a recommendation feature of a networking method in accordance with some implementations.

[0024] Figure 7 is a flow diagram of a reservation feature of a networking method in accordance with some implementations.

[0025] Figure 8 is a flow diagram of a group formation feature of a networking method in accordance with some implementations.

DETAILED DESCRIPTION

[0026] Implementations of the networking system described herein provide electronic functionality configured to make friend gatherings easier to organize and smoother to run with additional features to ameliorate specific aspects of friend gatherings such as bill-splitting and picture sharing. Implementations of the networking system described herein feature electronic invites and group-chats with add-on features, such as features for booking restaurants and hotels and buying tickets. Users may send electronic invites to their friends for friend gatherings, whether they be concerts, sports games, or simple meals together. Once people accept the invite, they may be automatically included into a group chat with all of the other people participating in the event.

[0027] Figure 1 is a block diagram of a networking system 100 in accordance with some implementations. The networking system 100 includes a server system 110 and user devices 150a - 150n (also referred to as client devices) communicatively coupled to the server system 100 via one or more networks 140.

[0028] In some implementations, a networking application provides a user interface to the networking system for the user devices 150. The user devices 150 communicate with the server system 110 via a communication protocol (e.g., GSM, CDMA, Wi-Fi, or the like) through one or more communication networks 140. The server system 110 provides server-side functionalities for the networking system 100 for any number of user devices 150.

[0029] Each user devices 150 is a personal electronic device associated with a user. User devices 150 include, but are not limited to, mobile devices, smartphones, tablet computers, laptop computers, smart cards, voice assistant devices, or other technology (e.g., a hardwaresoftware combination) known or yet to be discovered that has structure and/or capabilities similar to the user devices described herein. Each user device 150 includes a communication capability (e.g., modem, transceiver, radio, and so forth) for communicating through the network(s) 140.

[0030] The communication network(s) 140 are configured to convey communications (messages, signals, transmissions, and so forth). The communications include various types of information and/or instructions including, but not limited to, data, commands, bits, symbols, voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, and/or any combination thereof. The communication network(s) 140 use one or more communication protocols, such as any of Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), near- field communication (NFC), ultra-wideband (UWB), radio frequency identification (RFID), infrared wireless, induction wireless, ZigBee, Z-Wave, 6L0WPAN, Thread, 4G, 5G, and the like. Such protocols may be used to send and receive the communications using one or more transmitters, receivers, or transceivers. For example, hard-wired communications (e.g., wired serial communications) may use technology appropriate for hard-wired communications, short- range communications (e.g., Bluetooth) may use technology appropriate for close communications, and long-range communications (e.g., GSM, CDMA, Wi-Fi, wide area network (WAN), local area network (LAN), or the like) may use technology appropriate for remote communications over a distance (e.g., over the Internet). In general, the communication network(s) 140 may include or otherwise use any wired or wireless communication technology that is known or yet to be discovered.

[0031] The server system 110 is implemented on one or more standalone data processing apparatuses or a distributed network of computers. In some implementations, the server system 110 also employs various virtual devices and/or services of third party service providers (e.g., third-party cloud service providers) to provide the underlying computing resources and/or infrastructure resources of the server system 110. In some implementations, the server system 110 includes, but is not limited to, a handheld computer, a tablet computer, a laptop computer, a desktop computer, or a combination of any two or more of these data processing devices or other data processing devices.

[0032] The networking system 100 shown in Figure 1 includes both a client-side portion (e.g., the user devices 150) and a server-side portion (e.g., the server system 110). In some implementations, data processing is implemented as a standalone application installed on the user devices 150. In addition, the division of functionalities between the client and server portions of the networking system 100 can vary in different implementations. For example, in some implementations, the user devices 150 provide only user-facing input and output processing functions, and delegate all other data processing functionalities to a backend server (e.g., the server system 110). Although many aspects of the present technology are described from the perspective of the server system 110, the corresponding actions performed by the user devices 150 would be apparent to ones skilled in the art. Furthermore, some aspects of the present technology may be performed by the server system 110, the user devices 150, or the server system 110 and the user devices 150 cooperatively.

[0033] The server system 110 includes one or more processors 112, memory 114, a communication module 115, and networking system modules 116-130. Although Figure 1 shows various modules, Figure 1 is intended more as a functional description of the various features which may be present in the modules than as a structural schematic of the implementations described herein. In practice, the programs, modules, and data structures shown separately could be combined, and some programs, modules, and data structures could be separated.

[0034] The processor(s) 112 include one or more central processing units (CPUs) or any other electronic circuitry configured to execute instructions comprising a computer program (e.g., the programs stored in the memory 114).

[0035] The memory 114 includes a non-transitory computer readable storage medium, such as volatile memory (e.g., one or more random access memory devices) and/or non-volatile memory (e.g., one or more flash memory devices, magnetic disk storage devices, optical disk storage devices, or other non-volatile solid state storage devices). The memory may include one or more storage devices remotely located from the processor(s). The memory stores programs (described herein as modules and corresponding to sets of instructions) that, when executed by the processor(s) 112, cause the server system 110 to perform functions as described herein. The modules and data described herein need not be implemented as separate programs, procedures, modules, or data structures. Thus, various subsets of these modules and data may be combined or otherwise rearranged in various implementations.

[0036] The communication module 115 connects the server system 110 to other devices (e.g., user devices 150) via one or more wired or wireless network interfaces and network(s) 140 in accordance with some implementations.

[0037] The account creation module 116 facilitates creation of user accounts by obtaining contact, identification, and profile information of users and creating accounts for use with the network system 100 in accordance with some implementations. In some implementations, accounts may include an email or a phone number (e.g., with verification email or text) and may be tied to an existing account (e.g., Apple ID, Facebook, Google, and so forth). In some implementations, accounts may include a profile picture, a name, and/or a short biography (e.g., 200 characters). In some implementations, users may have the ability to display current location through location data associated with accounts. In some implementations, accounts may include an avatar or logo, interests, budget information, and/or availability/schedule information. In some implementations, users have the ability to associate friends with their respective accounts using a QR code, username, or link. In some implementations, users may see friends in the area (e.g., using a map feature).

[0038] The invitation module 118 facilitates the sending and receiving of electronic invites among user devices 150 for the creation of user groups in accordance with some implementations. The invitation module 118 may be configured as a seamless way to invite friends. Electronic invitations may include the time, date, location, and an estimated per-person financial contribution for the friend gathering. Users may be able to see who else is invited and who has already accepted the invitation. Once an invitation is accepted, users may be put into a group chat with everyone else involved to further coordinate the event. In some implementations, an open invite may be created for a select group of friends. Such an open invite may be created close to the start of the event (e.g., at the last minute, or anything up to five hours, or up to ten hours, or up to 24 hours before the start of the event). In some implementations, electronic invitations may arrive as push notifications.

[0039] The group chat module 120 instantiates group chat sessions for groups of user devices 150 in accordance with some implementations. In some implementations, once a user accepts an electronic invitation for an event, the user is automatically added to a group chat with all of the other users associated with the event. In some implementations, users in a group chat may suggest venues and/or events for users in the group chat to vote on through a voting system within the group chat before booking and/or buying tickets. The venue and/or event having the highest vote in such implementations may automatically be chosen (or manually be chosen or otherwise confirmed by the user who started the group chat) as the venue and/or event for the group.

[0040] The recommendation module 122 obtains and recommends a plurality of venues and events for users in various user groups in accordance with some implementations. The recommendation module 122 may recommend a well-diversified collection of venues and events. Part of these suggestions may be tailored to a user based on the user’s history with the networking system (e.g. what that users tends or likes to do when the user goes out, age range of the user, how much the user tends to spend when the user goes out, and so forth). Moreover, there may be a diverse filter for users to select suggestions based on cost, type of event, and so forth. The recommendation module 122 may show special discounts that are available to students and other various groups of people. In some implementations, the recommendation module 122 may include a “hot in the area” feature that offers things to do within a set location and based on the user’s predetermined preferences (e.g., a music or food enthusiast for example). An example list of things to do may include between 1-10 or more (e.g., 3-5) items from categories including: promoted events (e.g., concerts, games), promoted restaurants for each cuisine category (e.g., Asian, Italian, American, Mexican, French), promoted venues (e.g. top golf, cinemas, special events), promoted bars, and/or promoted clubs.

[0041] The reservation module 124 books tickets and makes reservations for users in various user groups in accordance with some implementations. Users may book restaurants, hotels, and tickets through the reservation module 124 using various integrations with third- party reservation services. The reservation module 124 may include a loyalty program for users who consistently book through the reservation module with benefits at partner venues and organizations. The reservation module 124 may link to any of the following examples: Booking.com, OpenTable, Ticketmaster, SeatGeek, Vivid Seats, Hotels Tonight, Airbnb, and so forth.

[0042] The media sharing module 126 facilitates sending and receiving of images and videos among user devices 150 in accordance with some implementations. Pictures and videos taken through such a camera feature may be automatically uploaded to the group chat with high quality retention. In some implementations, each of the users in the group chat have access to all of the pictures and videos to either keep as memories or share on social media. In some implementations, picture and video quality is retained throughout the process of sending the media to the group chat and downloading the media into the camera roll on user devices associated with the group chat. In some implementations, confirmation is obtained from each user before an image or video clip is shared (e.g., confirming that the user is sure about sharing the media).

[0043] The bill splitting module 128 obtains an amount spent by each user in a user group and determines how much each user owes or is owed in accordance with some implementations. In some implementations, users may input how much they spent on the group (e.g., group spendings such as Ubers, hotels, and so forth) by either entering the amount or uploading a picture of the bill from which the bill total may be acquired (e.g., an application running on a user device or on a server system may scrape the bill total). At the end of the gathering, there may be a split-evenly button or some other trigger that automatically calculates how much each participant still owes or is owed overall (e.g., total spending divided among people). Such a feature determines whether people overpaid or underpaid. Then, the application may determine who has to pay whom and how much. In some implementations, the bill splitting and payment features may be presented in a separate page or tab within the group chat feature. Such a page or tab may be solely used for money-related features.

[0044] The payment module 130 facilitates sending of peer-to-peer payment links among the user devices 150 in accordance with some implementations. In some implementations, users may send money to each other using integrations with third-party payment applications (e.g., Google Pay, Apple Pay, and so forth). In some implementations, users may pool money into a group account for bigger spending such as purchasing tickets or booking hotel rooms. In some implementations, the bill splitting and payment features may be presented in a separate page or tab within the group chat feature. Such a page or tab may be solely used for money-related features.

[0045] Figure 2 is a flow diagram illustrating an example networking method 200 in accordance with some implementations. The method may be governed by instructions that are stored in a computer memory or non-transitory computer readable storage medium (e.g., 114, Figure 1). The instructions may be included in one or more programs stored in the non-transitory computer readable storage medium. When executed by one or more processors (e.g., 112, Figure 1), the instructions cause the networking system 100 to perform the method. The non-transitory computer readable storage medium may include one or more solid state storage devices (e.g., Flash memory), magnetic or optical disk storage devices, or other non-volatile memory devices. The instructions may include source code, assembly language code, object code, or any other instruction format that can be interpreted by one or more processors. Some operations in the process may be combined, and the order of some operations may be changed.

[0046] At the beginning of method 200, a server system (e.g., 110) receives (202) user data from a plurality of user devices (e.g., 150) via one or more networks (e.g., 140). The server system (e.g., account creation module 116) creates (204) a plurality of user accounts based on the user data received from the plurality of user devices. In some implementations, the user data may include any of

• contact information (e.g., email, phone number, etc.);

• social media account information (e.g., Apple, Facebook, Google, etc.);

• identifying information (e.g., name, profile image, etc.);

• biographical information (e.g., a short description limited to, for example, 200 characters);

• location information (e.g., a current location, permission to display a current location of a corresponding user device, etc.);

• budgeting information (e.g., per-event budget threshold);

• availability information (e.g., open dates and times during which the user is available);

• event-type preference information (e.g., the types of events the user is interested in);

• event trend information (e.g., a history of events the user attended); and/or

• user attribute data (e.g., student status, age, gender, culture, or other identity-related attributes).

[0047] The account creation step may use any of the aforementioned user data in creating accounts for users associated with each of the user devices. As part of account creation (204) or subsequent to account creation, users may add other users to corresponding friend groups or networks. In some implementations, users may add other users by scanning quick response (QR) codes displayed on the user devices, entering usernames corresponding to particular users, selecting referral links corresponding to particular users, and so forth. In some implementations, users may have the ability to see friends in the area using a map feature. [0048] Users may send electronic invites to their friends for friend gathers, whether they be concerts, sports games, or simple meals together. As such, method 200 continues when the server system receives an event creation request from a first user account (e.g., associated with 150a) of the plurality of user accounts, specifying an event and two or more user accounts (e.g., 150b and 150c) for association with the event. In some implementations, the event creation request may specify only one other user account. In some implementations, only the user associated with the first user account may invite others; alternatively, any user associated with an invited user account may invite other users.

[0049] In some implementations, the event creation request (sometimes referred to as an invite or an electronic invite) includes any of event information (e.g., date, time, location), expected cost (e.g., financial contribution from each person), people invited, and invite status (e.g., people who have already accepted the invite and people who have not yet accepted the invite). The server system (e.g., invitation module 118) sends these invites to the user devices corresponding to the invited users in response to receiving the event creation request specifying the invited users. When users accept the invite, the server system receives invite acceptance notifications from corresponding user devices and adds respective user accounts to the friend group for the specified event.

[0050] In response to receiving the event creation request (and once users accept the respective electronic invites), the server system creates an event group including all of the user accounts associated with the users who both sent and accepted electronic invites. As part of the group creation process, the server system (e.g., group chat module 120), in response to receiving the event creation request, instantiates (208) a group chat session including the two or more user accounts (all of the user accounts that sent and accepted electronic invites). In other words, once users accept the invite, they may be automatically included into a group chat with all of the other users participating in the event, in order to further coordinate the event. The group chat session ensures effortless coordination and communication among users in the group.

[0051] While users communicate with the group chat, they may coordinate the event by obtaining recommendations (described in more detail below with reference to Figure 6) and making reservations (described in more detail below with reference to Figure 7). During the event, users may, via the group chat, share image and video (described in more detail below with reference to Figure 5), and at the end of the event (or during the event), users may, via the group chat or via a separate page in the group chat, interact with bill splitting features (described in more detail below with reference to Figures 3-4).

[0052] Referring back to Figure 2, method 200 continues with the server system receiving (210) a plurality of first electronic items associated with the event from respective user devices via the group chat, including a plurality of bill totals (or amounts paid by each user) or a plurality of images (or other media). The server system creates (212) a plurality of second electronic items based on the plurality of first electronic items, including a plurality of amounts owed or a plurality of formatted images. Finally, the server system transmits (214) the plurality of second electronic items to the respective user devices via the group chat.

[0053] In some implementations, if the first electronic items are indications of amounts paid by each user, then the server system determines, as the second electronic items, how much each user owes or is owed in order to split the event-related bills among the users in the group (described in more detail below with reference to Figures 3-4). The server system sends the amounts owed to the relevant user devices.

[0054] In some implementations, if the first electronic items are media items (e.g., images or video clips) captured by particular users, then the server system optimizes the media items (the optimized media items being the second electronic items) for display in the group chats of each user device in the group (described in more detail below with reference to Figure 5). The server system sends the optimized media items to the user devices that are included in the group.

[0055] Figure 3 is a flow diagram of a bill splitting method 300 of a networking system in accordance with some implementations. The method 300 may be governed by instructions that are stored in a computer memory or non-transitory computer readable storage medium (e.g., 114, Figure 1). The instructions may be included in one or more programs stored in the non- transitory computer readable storage medium. When executed by one or more processors (e.g., 112, Figure 1), the instructions cause the server system (e.g., bill splitting module 128 of server system 110, Figure 1) to perform the method. The non-transitory computer readable storage medium may include one or more solid state storage devices (e.g., Flash memory), magnetic or optical disk storage devices, or other non-volatile memory devices. The instructions may include source code, assembly language code, object code, or any other instruction format that can be interpreted by one or more processors. Some operations in the process may be combined, and the order of some operations may be changed. [0056] In some implementations, the operations of method 300 may be performed as part of operations 210 and 212 of method 2, wherein the plurality of first electronic items include a plurality of bill totals (or amounts paid) associated with the event, and the plurality of second electronic items include a plurality of amounts owed by each user of the group.

[0057] The server system receives the bill totals (or amounts paid) from user devices in operation 210 (Figure 2) and operates on these amounts in method 300. Each bill total represents a bill paid for by a particular user. For example, if a user pays for a restaurant bill for the group, then the bill total for that user is the amount the user paid associated with that particular bill. In some implementations, the bill totals or amounts paid are received as a result of a plurality of users in the event group accessing a bill splitting tool of the networking application running on their user devices and submitting the respective bill totals or amounts paid. The bill splitting tool may be accessible within the group chat or via a separate page within the networking application.

[0058] Each user may input the amount that the user spent on the group (e.g., group spending such as Ubers, hotels, meals, tickets, and so forth) by directly entering the amount at the client device, or by capturing an image of a bill at the client device. For the latter option, the networking application may be configured to scrape the bill total from the image of the bill using, for example, optical character recognition (OCR). Alternatively, the networking application may send the image to the server system for bill total scraping. In this way, the networking application keeps track of the group’s spending during the gathering.

[0059] Referring to Figure 3, the server system receives these bill totals or amounts paid from respective user devices and associates (302) each bill total or amount paid to a respective user account in the group of users.

[0060] The server system receives (304) a trigger to process a group bill. In some implementations, the trigger is user input (at a user device) corresponding to a request to split the group payments (e.g., a split evenly button in the user interface of the networking application). Thus, the user input includes an instruction to calculate amounts owed by each of the users in the group.

[0061] In some implementations, the trigger corresponds to a predetermined time of day (e.g., the end of the day, or a preselected time). Thus, in response to the server system determining that a predetermined time of day has been reached, the server system proceeds to calculate amounts owed by each of the users in the group. [0062] In some implementations, the trigger corresponds to a predetermined time or indication corresponding to the end of the event or gathering. Thus, in response to a scheduled end time of an event (such as the end of a concert) or any indication that the users are leaving at the end of the gather (e.g., using location information of each user), the server system proceeds to calculate amounts owed by each of the users in the group.

[0063] Thus, the trigger may be received by the server system when one user (e.g., the group leader, or any user in the group) selects an option to process group payments.

Alternatively, the trigger may be automatically timed for the end of the event or the end of the day.

[0064] In response to the trigger, the server system combines (306) the plurality of bill totals into a group bill total. The group bill total represents all of the money that was spent for the group as a whole, including all of the bill totals and amounts entered by each user throughout the duration of the event or gathering. In some implementations, the group total can be continuously updated (and viewable in the group chat) as users contribute and submit amounts paid throughout the gathering.

[0065] The server system divides (308) the group bill total by the total number of user accounts associated with the group (the number of users in the group) to determine a per-user contribution amount. For example, if the group total is $100 and there are five users in the group, then the per-user contribution amount is $100 / 5 = $20 per user. In some implementations, the per-user contribution amounts can be continuously updated (and viewable in the group chat) as users contribute and submit amounts paid throughout the gathering.

[0066] The server system determines (310) a plurality of respective differences between the per-user contribution amount and respective bill totals. For example, if the per-user contribution amount is $20 per user, a first user contributed $15, a second user contributed $20, and a third user contributed $25, then the respective differences are $20 - $15 = $5 for the first user, $20 - $20 = $0 for the second user, and $20 - $25 = -$5 for the third user.

[0067] The system determines (312) a plurality of amounts owed corresponding to respective user accounts based on the plurality of respective differences. For example, continuing with the above example, the first user owes $5 due to having contributed $5 less than the per-user contribution amount, the second user does not owe anything due to having contributed the exact per-user contribution amount, and the third user is owed $5 due to having contributed $5 over the per-user contribution amount. [0068] In some implementations, the server system transmits the aforementioned amounts owed to the respective user devices as the second electronic items in operation 212 (Figure 2). In some implementations, in addition to or as an alternative to the amounts owed, the server system transmits payment links to the respective user devices as the second electronic items in operation 212 (Figure 2). That way, users can send money to each other through the networking application through integrations (e.g., using application programming interfaces) with third-party peer-to-peer payment providers (e.g., Venmo, Zelle, Google Pay, Apple Pay, and so forth). Information regarding peer-to-peer payment accounts may be included in the user data corresponding to the user accounts of each user. In some implementations, users can pool money into a group account for bigger spending (e.g., purchasing tickets, booking hotel rooms, and so forth). That way, one user can use the pooled money to make the purchase.

[0069] Figure 4 is a diagram of a bill splitting example 400 in accordance with some implementations. Example 400 is implemented by the server system using the operations in method 300 (Figure 3). In example 400, four users A, B, C, and D are in an event group. User A covers lunch for everybody and enters $50 as the amount paid (or captures and uploads an image of the bill), User B buys concert tickets for everybody in the group and enters $100 as the amount paid (or captures and uploads an image of the receipt), User C pays for parking for the group and enters $10 as the amount paid (or captures and uploads an image of the receipt), and User D pays for nothing.

[0070] As the gathering progresses, each user enters the corresponding amounts paid (operation 302, Figure 3), causing the server system to receive them. At some point during the day or in the evening (e.g., upon user selection of a split evenly button, or at the end of the concert or the end of the day), a trigger is received (operation 304, Figure 3), which causes the rest of the bill splitting operations to commence.

[0071] The server system adds up all of the amounts paid to determine a $160 group total (operation 306, Figure 3), and divides the group total by 4 (the number of users) (operation 308, Figure 3), thereby determining each user’s contribution amount to be $40.

[0072] The server system determines differences for each user between the user’s amount paid and the per-user contribution amount (operation 310, Figure 3). Here, User A overpaid by $10, User B overpaid by $50, User C underpaid by $30, and User D underpaid by $40. [0073] The server system determines the amounts owed by and to the users in the group based on the aforementioned differences (operation 312, Figure 3). Here, User A is owed $10, User B is owed $60, User C owes $30, and User D owes $40. Thus, the server system sends these amounts and/or personalized payment links accordingly. Here, User C receives a first peer- to-peer payment request in the amount of $10 with User A as the recipient and a second peer-to- peer payment request in the amount of $20 with User B as the recipient, while user D receives a peer-to-peer payment request in the amount of $40 with User B as the recipient. Thus, User C pays a total of $30, User D pays a total of $40, User A automatically gets $10 deposited into an associated financial account, and User B automatically gets $60 deposited into a corresponding financial account.

[0074] Figure 5 is a flow diagram of a media sharing method 500 of a networking system in accordance with some implementations. The method 500 may be governed by instructions that are stored in a computer memory or non-transitory computer readable storage medium (e.g., 114, Figure 1). The instructions may be included in one or more programs stored in the non-transitory computer readable storage medium. When executed by one or more processors (e.g., 112, Figure 1), the instructions cause the server system (e.g., media sharing module 126 of server system 110, Figure 1) to perform the method. The non-transitory computer readable storage medium may include one or more solid state storage devices (e.g., Flash memory), magnetic or optical disk storage devices, or other non-volatile memory devices. The instructions may include source code, assembly language code, object code, or any other instruction format that can be interpreted by one or more processors. Some operations in the process may be combined, and the order of some operations may be changed.

[0075] In some implementations, the operations of method 500 may be performed as part of operations 210 and 212 of method 2, wherein the plurality of first electronic items include a plurality of media items (e.g., images or video clips) captured by users of the group during the event or gathering, and the plurality of second electronic items include a plurality of formatted media items (e.g., reformatted according to formatting requirements of the user devices).

[0076] Once in the group chat, all media items captured and saved (e.g., using a camera feature of the networking application) may be directly uploaded to the group chat via the server system for everyone to have access to. Importantly, the networking application and server system retain image/video quality throughout the process of transmitting the media items to the group chat and causing the media items to be downloaded to the camera rolls of the user devices.

[0077] Referring to Figure 5, the server system determines (502) a plurality of user device types based on (included in) the user data corresponding to respective user accounts of the user accounts in the group. For example, device types may include any of: mobile device type, operating system type, and texting standard (e.g., iMessages, Rich Communication Services (RCS), Short Message Service (SMS), and so forth).

[0078] The server system determines (504) a plurality of media format requirements (e.g., size and format of images, video clips, and so forth) respectively corresponding to the plurality of user device types. The server system processes (506) each of the plurality of media items to produce the plurality of formatted media items according to the plurality of media format requirements. For example, the server system optimizes each media item for display in the group chat of each user device based on the media format requirements. The processed media clips are referred to as formatted or reformatted media clips, images, video clips, and so forth.

[0079] The server system proceeds to transmit the processed media clips as the second electronic items to the user devices via the group chat (212, Figure 2).

[0080] In some implementations, the images may be posted in the networking application for other users and groups to view. The server system may host these images and serve them in an image feed to user devices corresponding to other users and/or groups of users. Thus, users in such groups may showcase or post the time they spent and images and/or video they took during the event. In some implementations, only group photos uploaded by a group (or a group leader) are allowed to be posted on the networking application. In other words, a restriction or rule regarding who gets to upload group images may be in place in such implementations, thereby incentivizing users to join groups, attend events as part of the groups, and interact with the networking application in the group setting.

[0081] Figure 6 is a flow diagram of a recommendation method 600 of a networking system in accordance with some implementations. The method 600 may be governed by instructions that are stored in a computer memory or non-transitory computer readable storage medium (e.g., 114, Figure 1). The instructions may be included in one or more programs stored in the non-transitory computer readable storage medium. When executed by one or more processors (e.g., 112, Figure 1), the instructions cause the server system (e.g., recommendation module 122 of server system 110, Figure 1) to perform the method. The non-transitory computer readable storage medium may include one or more solid state storage devices (e.g., Flash memory), magnetic or optical disk storage devices, or other non-volatile memory devices. The instructions may include source code, assembly language code, object code, or any other instruction format that can be interpreted by one or more processors. Some operations in the process may be combined, and the order of some operations may be changed.

[0082] Using method 600, the networking application may recommend a diversified collection of venues and events for users to view. Examples include events (e.g., concerts, games), restaurants for different cuisine categories (e.g., Asian, Italian, American, Mexican, French), venues (e.g. golf, cinemas, special events), bars, clubs, and so forth.

[0083] The server system receives (602) a recommendation request from a user device corresponding to one of the user accounts in the group via the group chat, wherein the recommendation request includes an instruction to view a list of events or venues recommended for inclusion in the gathering.

[0084] In response to receiving the recommendation request, the server system determines (604) a list of specific events or venues for recommending for inclusion in the gathering. The server system may obtain the list by communicating with a recommendation platform via an application programming interface (API) associated with the recommendation platform.

[0085] Upon having determined the list of specific events or venues, the server system transmits (606) the list of specific events or venues to the respective user devices associated with the user accounts in the group via the group chat.

[0086] In some implementations, in addition to or instead of the recommendations being provided as a requested list in the form of a pull notification, the server system 110 may transmit (e.g., via communication module 115) one or more recommendations to user devices via push notifications. For example, a venue business (e.g., bar, restaurant, etc.) may configure push notifications through a business dashboard. With the business dashboard, the venue business may create a custom notification (e.g., including title and text) and configure a target audience based on interest groups. Then, a business representative may specify, via the dashboard, a quantity of users to be reached and the location boundaries (e.g., by city) of a push notification blast. The business representative may, via the dashboard, cause the push notifications to be sent via the communication module 115 to targeted user devices. In some implementations, such notifications may require pre-approval from an admin panel. This is a dynamic way for businesses to communicate with local targets in real time to optimize their occupancies.

[0087] Figure 7 is a flow diagram of a reservation method 700 of a networking system in accordance with some implementations. The method 700 may be governed by instructions that are stored in a computer memory or non-transitory computer readable storage medium (e.g., 114, Figure 1). The instructions may be included in one or more programs stored in the non- transitory computer readable storage medium. When executed by one or more processors (e.g., 112, Figure 1), the instructions cause the server system (e.g., reservation module 124 of server system 110, Figure 1) to perform the method. The non-transitory computer readable storage medium may include one or more solid state storage devices (e.g., Flash memory), magnetic or optical disk storage devices, or other non-volatile memory devices. The instructions may include source code, assembly language code, object code, or any other instruction format that can be interpreted by one or more processors. Some operations in the process may be combined, and the order of some operations may be changed.

[0088] Using method 700, the networking application facilitates the booking of restaurants, hotels, and tickets. The networking application may be linked to ticket and restaurant booking platforms (e.g., Booking.com, Opentable, Ticketmaster, Seatgeek, Vividseats, and so forth) via corresponding APIs. In some implementations, the server system may provide a loyalty program for users who consistently book through the networking application with benefits at partner venues and organizations.

[0089] The server system receives (702) a reservation request from a user device corresponding to one of the user accounts in the group via the group chat, wherein the reservation request includes an instruction to process a reservation for a venue associated with the event.

[0090] In response to the reservation request, the server system automatically processes (704) the reservation for the venue in accordance with the instruction. The server system may process the reservation by communicating with a ticket or booking platform via corresponding APIs associated with the respective venues.

[0091] Upon having processed the reservation, the server system transmits (706) information corresponding to the reservation (e.g., location and time) to the respective user devices associated with the user accounts in the group via the group chat. [0092] The following discussion focuses on group formation. As noted above, group formation may be overwhelming and difficult to manage. Factors such as group size, availabilities, conflicting budgets, and other differences in personal preferences can make event group formation arduous at best and impossible at worst. In addition, group formation can be affected in scenarios in which there are many different event-related possibilities, such as which event to attend and when to show up. A seemingly minor adjustment to one variable can cause the group to fall apart or event prevent a group from forming in the first place.

[0093] To address the aforementioned challenges, some implementations of the networking system 100 automatically connect and/or match users for events based on their likeliness to accept invitations to attend the events. Likeliness to accept an invitation to attend an event may be influenced according to user data associated with each user account, and a matching of such user data with event data corresponding to the event.

[0094] Specifically, when a given user creates an event (e.g., by selecting an event in a list of recommended events, or by manually providing event details), the user may be automatically presented with a filtered list of contacts that are most likely to accept an invitation to the event. In some implementations, rather than presenting the user with the filtered list of contacts, the networking system 100 may automatically send invitations to those contacts. As such, from the user’s point of view, group formation is automatically handled behind the scenes. In these implementations, upon creating an event, the networking system 100 automatically forms a group of friends that are confirmed for attending the event with each other.

[0095] As noted above, user data for each user account may be collected at the time of account creation (by account creation module 116). In some implementations, user data may be continually updated based on user activities (e.g., which events are attended, evolving preferences, and so forth). Based on a matching of the user data to event data, networking system 100 may select one or more prospective user accounts.

[0096] In one example, user data for each user account may include budgeting information (e.g., a per-event budget threshold). This allows users to keep to a personalized budget. If an event is associated with an expected per-user spending amount that fits within the user’s budget, then that user may be invited to the event. If a user is on a budget, then the user may have an expected contribution - an approximate amount the user may or may not pay. Each potential event may be associated with a total expected spending amount, a per-person spending amount, or any other spending that is expected to correspond to the event. [0097] This event data can be compared to each user’s per-event budget threshold, and users associated with per-event budget thresholds that do not exceed the expected contribution for a given event may be included in a list of prospective users to be invited to the event. This, invites may be filtered, or events may be recommended, based on personal budgets of each user. Thus, the user invites others based on their budgets. Budgets of other users may be presented to the inviter during the group formation stage. Alternatively, an indication as to whether certain users meet or do not meet expected budget restrictions may be presented to the inviter during the group formation stage (thus, keeping exact budget numbers private). From the point of view of the inviter, only users who can afford a given event are invited to attend, thus removing the need for the inviter to inquire as to whether certain users can afford the event. From the point of view of the invitee, users are only invited to events that they can afford, thus removing the need for a user to turn down an invitation for an event that is too expensive, or to wonder if the event will be affordable.

[0098] Similarly, for event recommendations, events may only be promoted or otherwise recommended for users who are known to be able to afford them based on the budget information for each user. In other words, event recommendations can be tailored to the budget of each user.

[0099] In another example, user data for each user account may include availability information (e.g., open dates and times during which the user is available). In this example, the event data includes an event date and time, and only user accounts associated with open dates and times that correspond to the event date and time may be invited to attend the event. From the point of view of the inviter, only users who are available to attend a given event are invited to attend, thus removing the need for the inviter to inquire as to whether certain users available. From the point of view of the invitee, users are only invited to events that they are available to attend, thus removing the need for a user to turn down an invitation for which the user is unavailable, or to wonder if the event will fit in to the user’s schedule.

[0100] Similarly, for event recommendations, events may only be promoted or otherwise recommended for users who are known to be available based on the availability information for each user. In other words, event recommendations can be tailored to the availability of each user.

[0101] In another example, user data for each user account may include event-type preference information (e.g., the types of events the user is interested in). This allows users to elect to attend events in which like-minded people are also attending. In this example, the event data includes an event type or characteristic (e.g., a charity race, an alcohol-free event, a patent drafting seminar, and so forth), and user accounts that have matching event-type preference information (e.g., charity events, dry events, scientific events, and so forth) may be invited to attend the event. From the point of view of the inviter, only users who are like-minded or known to be interested in the specific type of event are invited to attend, thus removing the need for the inviter to inquire as to whether users would be interested in attending such an event. From the point of view of the invitee, users are only invited to events that they are known to be interested in, thus removing the need for a user to turn down an invitation for which there is a lack of interest, or to consider if the event is desirable enough to attend.

[0102] Similarly, for event recommendations, events may only be promoted or otherwise recommended for users who are known to be interested in attending based on the event type. In other words, event recommendations can be tailored to the interests of each user.

[0103] In another example, user data for each user account may include event trend information (e.g., a history of events the user attended). This allows users to be presented with events that are similar to those they have attended in the past. In some implementations, event trend information may include or otherwise take into account past reviews from the user regarding the past events. Events that are similar to highly rated past events may be presented, while events that are similar to past events with low ratings may not be presented. From the point of view of the inviter, only users who are known to be interested in the type of event due to their past activity and/or ratings are invited to attend, thus removing the need for the inviter to inquire as to whether users would be interested in attending such an event. From the point of view of the invitee, users are only invited to events that they are known to be interested in due to their past activity and/or ratings, thus removing the need for a user to turn down an invitation for which there is a lack of interest, or to consider if the event is desirable enough to attend.

[0104] Similarly, for event recommendations, events may only be promoted or otherwise recommended for users who are known to be interested in attending based on the user’s event history and/or ratings. In other words, event recommendations can be tailored to the interests of each user as characterized by the user’s past event attendance and/or rating activity.

[0105] In another example, user data for each user account may include user attribute data (e.g., student status, age, gender, culture, or other identity-related attributes). This allows users to be presented with events that are attended by people with similar attributes to those of the user (e.g., events tailored for students, certain religions or cultures, certain age groups, and so forth). From the point of view of the inviter, only users who are known to have attributes that correspond to the event type, or otherwise be interested in the type of event due to their attributes are invited to attend, thus removing the need for the inviter to inquire as to whether users would be interested in attending such an event. From the point of view of the invitee, users are only invited to events that they are known to be interested in due to their attributes, thus removing the need for a user to turn down an invitation for which there is a lack of interest, or to consider if the event is desirable enough to attend.

[0106] Similarly, for event recommendations, events may only be promoted or otherwise recommended for users who are known to be interested in attending based on the user’s attributes. In other words, event recommendations can be tailored to the interests of each user as characterized by the user’s attributes.

[0107] In another example, user data for each user account may include discounts that the user may have applied for and/or received. This allows users to be presented with events that qualify for such discounts. Similarly, for event recommendations, events may be promoted or otherwise recommended for users who qualify for discounts associated with the events. In other words, event recommendations can be tailored or otherwise filtered based on discounts that the user has qualified for.

[0108] Any of the other user data described above (e.g., contact information, social media account information, identifying information, biographical information, and location information) can additionally or alternatively be used as a basis for selecting users as potential users for receiving event invitations from other users, as a basis for recommending users for invitations, and/or as a basis for event recommendations.

[0109] Figure 8 is a flow diagram of a group formation method 800 of a networking system in accordance with some implementations. The method 800 may be governed by instructions that are stored in a computer memory or non-transitory computer readable storage medium (e.g., 114, Figure 1). The instructions may be included in one or more programs stored in the non-transitory computer readable storage medium. When executed by one or more processors (e.g., 112, Figure 1), the instructions cause the server system (e.g., reservation module 124 of server system 110, Figure 1) to perform the method. The non-transitory computer readable storage medium may include one or more solid state storage devices (e.g., Flash memory), magnetic or optical disk storage devices, or other non-volatile memory devices. The instructions may include source code, assembly language code, object code, or any other instruction format that can be interpreted by one or more processors. Some operations in the process may be combined, and the order of some operations may be changed.

[0110] At the beginning of method 800, a server system (e.g., 110) receives (802) user data from a plurality of user devices (e.g., 150) via one or more networks (e.g., 140). The server system (e.g., account creation module 116) creates (804) a plurality of user accounts based on the user data received from the plurality of user devices. In some implementations, operation corresponds to account creation operation 204 (Figure 2).

[OHl] The server system receives (806) an event creation request from a first user account of the plurality of user accounts, wherein the event creation request specifies event data. In response to receiving the event creation request from the first user account, the server system selects (808) one or more prospective user accounts of the plurality of user accounts based on a matching of the event data and respective user data corresponding to the one or more prospective user accounts, transmits (810) an electronic invitation to each of the one or more prospective user accounts, wherein the electronic invitation includes the event data, receives (812) positive responses to the electronic invitation from at least some of the one or more prospective user accounts, and instantiates (814) a group chat including the at least some of the one or more prospective user accounts in accordance with receiving the positive responses.

[0112] In some implementations, in response to receiving the positive responses, the server system transmits a notification to a user device associated with the first user account including the at least some of the one or more prospective user accounts; and receiving confirmation regarding one or more of the at least some of the one or more prospective user accounts; and includes only the one or more of the at least some of the one or more prospective user accounts in the group chat. In other words, in such implementations, the server system allows for manual selection of the suggested users for inclusion in the group before sending the invites, rather than automatically sending the invites.

[0113] In some implementations, in response to receiving the positive responses, the server system scores each of the at least some of the one or more prospective user accounts according to a probability of receiving a positive response; wherein the notification causes the user device associated with the first user account to display the at least some of the one or more prospective user accounts in an order according to the scoring. In other words, the user device displays the suggested users in the order of the likelihood that the respective users will accept the invite. For example, users listed toward the top are most likely to accept the invite. [0114] In some implementations, the event creation request includes a maximum group size threshold; and selecting the one or more prospective user accounts includes selecting only a number of prospective user accounts that does not exceed the maximum group size threshold. Thus, the user can limit the group size, and the server system sends a number of invites that correspond to the selected group size.

[0115] In some implementations, the user data includes per-event budget thresholds; the event data includes an estimated per-person spending amount; and selecting the one or more prospective user accounts includes selecting only user accounts associated with a per-event budget threshold that is less than the estimated per-person spending amount. Thus, the server system may tailor invitations to users based on budget. In some implementations, the server system may similarly tailor event recommendations based on budget.

[0116] In some implementations, the user data includes open dates and times during which users corresponding to the plurality of user accounts are available; the event data includes an event date and time; and selecting the one or more prospective user accounts includes selecting only user accounts associated with open dates and times that correspond to the event date and time. Thus, the server system may tailor invitations to users based on availability. In some implementations, the server system may similarly tailor event recommendations based on availability.

[0117] In some implementations, the user data includes event-type preferences; the event data includes an event type or characteristic; and selecting the one or more prospective user accounts includes selecting only user accounts associated with event-type preferences that correspond to the event type or characteristic. Thus, the server system may tailor invitations to users based on event preferences. In some implementations, the server system may similarly tailor event recommendations based on event preferences.

[0118] In some implementations, the user data includes past events attended by respective users; the event data includes an event type or characteristic; and selecting the one or more prospective user accounts includes selecting only user accounts associated with past events that correspond to the event type or characteristic. Thus, the server system may tailor invitations to users based on event activity trends. In some implementations, the server system may similarly tailor event recommendations based on event activity trends.

[0119] In some implementations, the user data includes user attributes; the event data includes an event type or characteristic; and selecting the one or more prospective user accounts includes selecting only user accounts associated with user attributes that correspond to the event type or characteristic. Thus, the server system may tailor invitations to users based on user attributes. In some implementations, the server system may similarly tailor event recommendations based on user attributes.

[0120] In some implementations, the networking system may implement an advertising feature. For example, venues may log into the networking system with a separate account (potentially through a separate website) and pay a subscription fee or a one-time fee to be part of a suggestions page within the networking system and be recommended to an appropriate audience within the networking system.

[0121] In some implementations, the networking system may charge user fees for features such as bookings, reservations, tickets, and/or sending money.

[0122] In some implementations, the networking system may implement premium membership features for fee-paying users, including premium features such as prioritized reservations for tickets, seats, and restaurants. Premium members may have access to exclusive “last minute offers” from venues and/or have access to tickets, tables, and other things that are unavailable to non-premium members. Premium members may have access to discounts, giveaways, and extra profile features.

[0123] Reference have been made in detail to various implementations, examples of which are illustrated in the accompanying drawings. In the above detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention and the described implementations. However, the invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the implementations.

[0124] It will be understood that, although the terms “first,” “second,” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first device could be termed a second device, and, similarly, a second device could be termed a first device, without changing the meaning of the description, so long as all occurrences of the first device are renamed consistently and all occurrences of the second device are renamed consistently. The first device and the second device are both devices, but they are not the same device.

[0125] The terminology used herein is for the purpose of describing particular implementations only and is not intended to be limiting of the claims. As used in the description of the implementations and the appended claims, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[0126] As used herein, the term “if’ may be construed to mean “when” or “upon” or “in response to determining” or “in accordance with a determination” or “in response to detecting,” that a stated condition precedent is true, depending on the context. Similarly, the phrase “if it is determined [that a stated condition precedent is true]” or “if [a stated condition precedent is true]” or “when [a stated condition precedent is true]” may be construed to mean “upon determining” or “in response to determining” or “in accordance with a determination” or “upon detecting” or “in response to detecting” that the stated condition precedent is true, depending on the context.

[0127] The foregoing description, for purpose of explanation, has been described with reference to specific implementations. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The implementations were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various implementations with various modifications as are suited to the particular use contemplated.

Claims

What is claimed is:

1. A method, comprising: at an electronic server system including one or more processors and memory storing one or more programs for execution by the one or more processors: receiving user data from a plurality of user devices; creating a plurality of user accounts based on the user data received from the plurality of user devices; receiving an event creation request from a first user account of the plurality of user accounts, wherein the event creation request specifies an event and two or more user accounts of the plurality of user accounts for association with the event; in response to receiving the event creation request, instantiating a group chat including the two or more user accounts; receiving a plurality of first electronic items associated with the event from respective user devices associated with the two or more user accounts via the group chat, wherein the plurality of first electronic items include a plurality of bill totals or a plurality of images; creating a plurality of second electronic items based on the plurality of first electronic items, wherein the plurality of second electronic items include a plurality of amounts owed or a plurality of formatted images; and transmitting the plurality of second electronic items to the respective user devices associated with the two or more user accounts via the group chat.

2. The method of claim 1, wherein the plurality of first electronic items include a plurality of bill totals associated with the event, and the method further includes: associating each bill total of the plurality of bill totals to a respective user account of the two or more user accounts; receiving a trigger to process a group bill; in response to receiving the trigger: combining the plurality of bill totals into a group bill total; dividing the group bill total by a total number of the two or more user accounts to determine a per-user contribution amount; determining a plurality of respective differences between the per-user contribution amount and respective bill totals of the plurality of bill totals; and determining a plurality of amounts owed corresponding to respective user accounts of the two or more user accounts based on the plurality of respective differences between the per-user contribution amount and the respective bill totals of the plurality of bill totals; wherein transmitting the plurality of second electronic items includes transmitting the plurality of amounts owed corresponding to the respective user accounts of the two or more user accounts.

3. The method of claim 2, further comprising: receiving via the group chat amounts paid from each of the two or more user accounts; wherein the plurality of bill totals respectively correspond to the amounts paid.

4. The method of claim 2, further comprising: receiving via the group chat images of receipts from each of the two or more user accounts; and scraping the images of the receipts to determine amounts paid from each of the two or more user accounts; wherein the plurality of bill totals respectively correspond to the amounts paid.

5. The method of claim 2, wherein receiving the trigger includes receiving a user input from a user device corresponding to one of the two or more user accounts, the user input including an instruction to calculate amounts owed by each of the two or more user accounts.

6. The method of claim 2, wherein receiving the trigger includes determining that a predetermined time of day has been reached.

7. The method of claim 2, wherein receiving the trigger includes determining that a predetermined time corresponding to an end of the event has been reached.

8. The method of claim 2, further comprising: automatically generating one or more peer-to-peer payment links for one or more of the two or more user accounts; and transmitting the one or more peer-to-peer payment links to one or more user devices associated with one or more of the two or more user accounts via the group chat; wherein each of the one or more peer-to-peer payment links is configured to (i) request a payment from one user account of the two or more user accounts corresponding to a respective amount owed of the plurality of amounts owed, and (ii) transfer at least a portion of the payment to another user account of the two or more user accounts.

9. The method of claim 1, wherein the plurality of first electronic items include a plurality of images, and the method further includes: determining a plurality of user device types based on the user data corresponding to respective user accounts of the two or more user accounts; determining a plurality of image format requirements respectively corresponding to the plurality of user device types; and processing each of the plurality of images to produce the plurality of formatted images according to the plurality of image format requirements; wherein transmitting the plurality of second electronic items includes transmitting the plurality of formatted images.

10. The method of claim 1, further comprising: receiving a recommendation request from a user device corresponding to one of the two or more user accounts via the group chat, wherein the recommendation request includes an instruction to view a list of events or venues recommended for inclusion in the event; determining the list of events or venues for recommending for inclusion in the event; and transmitting the list of events or venues to the respective user devices associated with the two or more user accounts via the group chat.

11. The method of claim 10, wherein determining the list of events or venues for recommending for inclusion in the event includes communicating with a recommendation platform via an application programming interface associated with the recommendation platform.

12. The method of claim 1, further comprising: receiving a reservation request from a user device corresponding to one of the two or more user accounts via the group chat, wherein the reservation request includes an instruction to process a reservation for a venue associated with the event; automatically processing the reservation for the venue in accordance with the instruction; and transmitting information corresponding to the reservation to the respective user devices associated with the two or more user accounts via the group chat.

13. The method of claim 12, wherein automatically processing the reservation includes communicating with a ticket or booking platform via an application programming interface associated with the venue.

14. An electronic server system including one or more processors and memory storing one or more programs for execution by the one or more processors, the one or more programs including instructions for performing one or more of the operations recited in any of claims 1-13.

15. A non-transitory computer readable storage medium storing one or more programs configured for execution by an electronic server system, the one or more programs including instructions for performing one or more of the operations recited in any of claims 1-13.

16. A method, comprising: at an electronic server system including one or more processors and memory storing one or more programs for execution by the one or more processors: receiving user data from a plurality of user devices; creating a plurality of user accounts based on the user data received from the plurality of user devices; receiving an event creation request from a first user account of the plurality of user accounts, wherein the event creation request specifies event data; in response to receiving the event creation request from the first user account: selecting one or more prospective user accounts of the plurality of user accounts based on a matching of the event data and respective user data corresponding to the one or more prospective user accounts; transmitting an electronic invitation to each of the one or more prospective user accounts, wherein the electronic invitation includes the event data; receiving positive responses to the electronic invitation from at least some of the one or more prospective user accounts; and instantiating a group chat including the at least some of the one or more prospective user accounts in accordance with receiving the positive responses.

17. The method of claim 16, further comprising: in response to receiving the positive responses, transmitting a notification to a user device associated with the first user account including the at least some of the one or more prospective user accounts; and receiving confirmation regarding one or more of the at least some of the one or more prospective user accounts; and including only the one or more of the at least some of the one or more prospective user accounts in the group chat.

18. The method of claim 17, further comprising: in response to receiving the positive responses, scoring each of the at least some of the one or more prospective user accounts according to a probability of receiving a positive response; wherein the notification causes the user device associated with the first user account to display the at least some of the one or more prospective user accounts in an order according to the scoring.

19. The method of claim 16, wherein: the event creation request includes a maximum group size threshold; and selecting the one or more prospective user accounts includes selecting only a number of prospective user accounts that does not exceed the maximum group size threshold.

20. The method of claim 16, wherein: the user data includes per-event budget thresholds; the event data includes an estimated per-person spending amount; and selecting the one or more prospective user accounts includes selecting only user accounts associated with a per-event budget threshold that is less than the estimated per-person spending amount.

21. The method of claim 16, wherein: the user data includes open dates and times during which users corresponding to the plurality of user accounts are available; the event data includes an event date and time; and selecting the one or more prospective user accounts includes selecting only user accounts associated with open dates and times that correspond to the event date and time.

22. The method of claim 16, wherein: the user data includes event-type preferences; the event data includes an event type or characteristic; and selecting the one or more prospective user accounts includes selecting only user accounts associated with event-type preferences that correspond to the event type or characteristic.

23. The method of claim 16, wherein: the user data includes past events attended by respective users; the event data includes an event type or characteristic; and selecting the one or more prospective user accounts includes selecting only user accounts associated with past events that correspond to the event type or characteristic.

24. The method of claim 16, wherein: the user data includes user attributes; the event data includes an event type or characteristic; and selecting the one or more prospective user accounts includes selecting only user accounts associated with user attributes that correspond to the event type or characteristic.

25. The method of claim 16, further comprising one or more of the operations recited in any of claims 1-13.

26. An electronic server system including one or more processors and memory storing one or more programs for execution by the one or more processors, the one or more programs including instructions for performing one or more of the operations recited in any of claims 16-24.

27. A non-transitory computer readable storage medium storing one or more programs configured for execution by an electronic server system, the one or more programs including instructions for performing one or more of the operations recited in any of claims 16-24.