CN111194455A - Group travel system in online marketplace - Google Patents

Abstract

Systems and methods are provided for receiving a request to register a group trip including at least one travel item from a first computing device associated with a first user and receiving authorization from a second computing device associated with a second user to be included in the group trip, the request including parameters for the group trip. Systems and methods are also provided for receiving a request from a first computing device for travel items to book a group trip, approving the request for travel items to book the group trip based on determining that the travel items satisfy parameters for the group trip, and automatically charging a payment device associated with the first user and a payment device associated with a second user according to parameters related to the group trip.

Description

Group tourism system in online market

Priority

This patent application claims priority from us patent application No. 15/692,076 filed on 31/8/2017, which is incorporated herein by reference in its entirety.

Background

People typically leave a vacation together in a group of friends, family meeting in a city, or employees of a company who are standing together while attending a meeting. Planning and paying vacation or travel expenses can be time consuming and expensive. This is particularly true for group travel, which requires reservations for many personnel. Furthermore, the person making the subscription will typically end up paying for all. Typically, the individual must then seek to make a payment to the individual in the group, which may be collected by a number of different methods, such as cash, check or electronic payment. In some cases, this process can take months as people "busy" or "forget" and, in some cases, even never pay. But others have attempted to offset travel expenses by paying other things (living goods, airline tickets, gasoline, etc.) and keeping a ledger/account of what they spend to offset the initial people's expenses spent on their premises. This process is both cumbersome and undesirable for the person making the reservation on behalf of the group, and may bias the subscriber towards choosing a cheaper residence to avoid paying too much advance payment, or may not book the trip to avoid the annoyance of making the reservation and processing the payment collection process.

This further complicates travel platforms that require payment for advance payment for a reservation. This means that the person making the reservation must not only pay the amount on behalf of the other, but may also take months to pay off the money, and only after the trip can the rest of the group be paid. For example, for a 12 month vacation, 7 months have booked and paid. After the end of the trip, the subscriber collects payment from the group members for 1 month, which means that the money for the rest of the group has been prepaid for six months.

Another complication is that on a travel platform such as a family-sharing website, it is not always clear whether a particular reservation will be accepted, and multiple attempts may be required before confirming the reservation. Thus, the amount of payment required may be adjusted depending on which residence is ultimately reserved.

Drawings

The various drawings in the figures illustrate only example embodiments of the disclosure and are not to be considered limiting of its scope.

Fig. 1 is a block diagram illustrating a networked system according to some example embodiments.

Fig. 2 is a block diagram illustrating a reservation system according to some example embodiments.

FIG. 3 is a flow diagram illustrating aspects of a method for processing a request to register a group trip, according to some example embodiments.

FIG. 4 is a flow diagram illustrating aspects of a method for processing reservations and transactions for group travel items, according to some example embodiments.

FIG. 5 is a flow diagram illustrating aspects of a method for processing cancellations for group travel items, according to some example embodiments.

Fig. 6 is a flow diagram illustrating aspects of a method for handling seat (spot) cancellation in a travel item for a user in a group trip, according to some example embodiments.

FIG. 7 is an example user interface for viewing details of a listed item (listing) of travel items, according to some example embodiments.

Fig. 8 is a block diagram illustrating an example of a software architecture that may be installed on a machine, according to some example embodiments.

Fig. 9 illustrates a diagrammatic representation of machine in the form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed, according to some example embodiments.

Detailed Description

The systems and methods described herein relate to facilitating real-time (or near real-time) approval of individual members for a group appointment and payment for the appointment (e.g., residence, flight, car rental, travel, etc.) via an online travel market. This allows individuals in a group to jointly make reservations and payments on the online marketplace at the time of the reservation.

For example, an online marketplace receives a request from a first user to register a group trip that includes at least one travel item, the request including parameters for the group trip, and the group including at least one other user. The online marketplace sends a notification to other users in the community to approve inclusion in the community trip. Other users in the community may respond with authorization to be charged for the travel item based on the community's parameters. The first user (or any user in the community) may then book the travel item via the online marketplace. The online marketplace receives a request to reserve a travel item and analyzes listed items associated with the travel item and parameters related to group travel to determine whether to approve the request. For example, the online marketplace approves the request for reservation travel items based on a determination that the listed items of travel items satisfy parameters for group travel. The online marketplace automatically charges a payment device associated with the first user and a payment device associated with each other user in the community and sends a confirmation notification to each user in the community confirming the reservation of the travel item.

One technical problem with reservations and payments for corporate travel is the ordering of events for real-time approval. In the world online, a person makes payments and then must collect group payments after a fact. A host (e.g., property owner, property manager, home owner, listing manager, etc.) cannot only accept subscriptions that immediately know that all payments for the community are valid and will settle at the same time. If they assume they would like or they would not like, they may miss another subscription that may come on the same day. For example, if there is a five-person group that pays for group travel: the first four credit cards may be approved, but the fifth credit card may be rejected, and the entire reservation may be cancelled because the full payment was not received. Thus, by having an online travel marketplace that can validate multiple payment methods in real time to make the owner make a decision to accept (or not accept) a corporate payment for a reservation is an unforeseen sequence of events without having a unique technology and platform to facilitate it.

For example, typical solutions that allow for corporate payments involve either a pre-payment solution or a post-payment solution. An example of a post-payment solution is a system that attempts to facilitate collection of payment to a person after purchase. Examples are PayPal or Venmo, which allow a user to ask another person for money, who can then send the money to the user electronically, in case they have an online account. If they do not have an existing account, they need to establish such an account prior to transfer.

In the pre-pay model, a person collects money from a group prior to purchase, and may make a purchase only after collection. Examples include crowd funding websites such as Kickstarter, Tilt, and Indigogo. With this method, the person needs to know in advance the total amount required to make the purchase/reservation. As an example, a user who is organizing travel may intend that a vacation will cost $1000, and only after collecting $1000 will attempt to reserve this amount of vacation. If the aggregate is small, the organizer needs to find a way to repay the spread to the community members.

Another technical problem is to determine the credit (trust) of a particular user in a community. For example, it is determined whether the users in the community will pay the amount owed, whether the users in the community are people that other users can trust in order to stay with them in a particular residence or to engage in their particular activity, etc. Example embodiments allow an online system to verify whether a particular user is trustworthy based on verifying user identification (e.g., via government-issued identification, social network identification, payment information, etc.), verified payment credentials for the user (e.g., payment device information, verifying whether the user has money to pay for a trip, verifying whether the user has paid for a trip, etc.), based on other users' evaluations of the user, etc. For example, by verifying the user (e.g., determining whether the user is a trusted user), there may be certain requirements for qualifying the user for group travel and for group payments. A user may be authenticated by having an authenticated identification (e.g., a government-issued identification such as a driver's license, passport, etc.) with the server computing system, the user having received a favorable comment from at least one other user (e.g., an owner or listing manager, or other user), the user having a payment device or method authenticated with the server computing system, and so forth.

Yet another technical problem is to handle the cancellation of reservations by one or more users in a community for a community trip or travel item. In an online marketplace with millions of listed items of travel items with individually set cancellation policies (e.g., a first administrator of a first listed item may set a cancellation policy that is different from a second administrator of a second listed item) and millions of users who may want to set certain parameters for a group trip, there is a technical problem in determining how to satisfy the different cancellation policies of the travel items and users and ensure that travel items are not unnecessarily cancelled or the entire group trip is not cancelled. For example, if one passenger in a ten passenger group cancels, then it is listed how should the manager cancel the entire group, reserve reservations and charge the remaining passengers, and how should the manager charge for additional payments?

Another technical problem is how to manage requests from one or more users who want to change aspects of reservations for travel items or change parameters for group travel and how to resolve whether this would be acceptable to cancel a travel or other users of a group, etc.

Fig. 1 is a block diagram illustrating a networkedsystem 100, according to some example embodiments.System 100 may include one or more client devices, such asclient device 110.Client devices 110 may include, but are not limited to, mobile phones, desktop computers, laptop computers, Portable Digital Assistants (PDAs), smart phones, tablet computers, ultra-notebook computers, netbooks, laptop computers, multi-processor systems, microprocessor-based or programmable consumer electronics, game consoles, set-top boxes, computers in vehicles, or any other communication device that a user may use to accessnetworked system 100. In some embodiments,client device 110 may include a display module (not shown) for displaying information (e.g., in the form of a user interface). In other embodiments,client device 110 may include one or more of a touch screen, an accelerometer, a gyroscope, a camera, a microphone, a Global Positioning System (GPS) device, and the like. Theclient device 110 may be a device of a user for requesting and receiving reservation information, residence information, etc. associated with an individual or group tour.

One ormore users 106 may be humans, machines, or other components that interact withclient device 110. In an example embodiment, theuser 106 may not be part of thesystem 100, but may interact with thesystem 100 via theclient device 110 or other component. For example, theuser 106 may provide input (e.g., voice, touch screen input, alphanumeric input, etc.) to theclient device 110, and may transmit the input to other entities in the system 100 (e.g., the third-party server 130, theserver system 102, etc.) via thenetwork 104. In such instances, other entities insystem 100 may transmit information toclient device 110 vianetwork 104 in response to receiving input fromuser 106. In this manner,user 106 may interact with various entities insystem 100 usingclient device 110.

Thesystem 100 may also include anetwork 104. One or more portions ofnetwork 104 may be an ad hoc network, an intranet, an extranet, a Virtual Private Network (VPN), a Local Area Network (LAN), a wireless LAN (wlan), a Wide Area Network (WAN), a wireless WAN (wwan), a Metropolitan Area Network (MAN), a portion of the internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a wireless network, a WiFi network, a WiMax network, another type of network, or a combination of two or more such networks.

Theclient device 110 may be via a web client 112 (e.g., a browser, such as by Redmond, Washington)

Company developed Internet

A browser) or one or more client applications 114 access various data and applications provided by other entities in thesystem 100. Theclient device 110 may include one or more client applications 114 (also referred to as "apps"), such as, but not limited to, a web browser, a messaging application, an electronic mail (email) application, an e-commerce site application, a mapping or positioning application, a reservation application, and so forth.

In some embodiments, one or more client applications 114 may be included in a given one of theclient devices 110 and configured to provide the user interface and at least some functionality locally, with the client applications 114 being configured to communicate with other entities in the system 100 (e.g.,third party servers 130,server systems 102, etc.) as needed to obtain data and/or processing power not available locally (e.g., access to subscription information or listing information, request data, authenticate theuser 106, verify payment methods, etc.). In contrast, one or more applications 114 may not be included inclient device 110, andclient device 110 may then use its web browser to access one or more applications hosted on other entities in system 100 (e.g.,third party server 130,server system 102, etc.).

Thesystem 100 may also include one or morethird party servers 130. The one or morethird party servers 130 may include one or more third party applications 132. One or more third party applications 132 executing on the third party server(s) 130 may interact with theserver system 102 through a programming interface provided by theAPI gateway server 120 via the application programming interfaceAPI gateway server 120. For example, one or more third party applications 132 may request and utilize information from theserver system 102 via theAPI gateway server 120 to support one or more features or functions on a website hosted by the third party or an application hosted by the third party. The third-party website or application 132 may, for example, provide various functionalities supported by related functionality and data in theserver system 102.

Theserver system 102 may provide server-side functionality to one or more third-party servers 130 and/or one ormore client devices 110 via anetwork 104, such as the internet or a Wide Area Network (WAN). According to some example embodiments, thesystem 102 may be a cloud computing environment. In an example embodiment, theserver system 102 and any servers associated with theserver system 102 may be associated with a cloud-based application.

In one example, theserver system 102 provides server-side functionality for an online marketplace. The online marketplace may provide various listed items of travel items, such as residences hosted by various managers, which may be reserved by clients, such as apartments, houses, cabins, apartments or one or more rooms in a house, and the like. For example, one manager or owner of a house may list one or more rooms in their own house on an online marketplace, a second manager of the house may list the entire house on an online marketplace, a third manager may list the entire cabin on an online marketplace, etc. In one example, the listed items may be due inventory. For expired inventory (e.g., due residences), if not reserved and used before the inventory expires, the inventory is wasted and the manager cannot receive revenue. The online marketplace may also provide listings for other travel items, such as experiences (e.g., local travel), car rentals, flights, public transportation, and other transportation or activities related to travel.

Theserver system 102 may include anAPI gateway server 120, aweb server 122, and areservation system 124, which may be communicatively coupled with one ormore databases 126 or other forms of data stores.

The one ormore databases 126 can be one or more storage devices that store data related to thereservation system 124 and other systems or data. The one ormore databases 126 may also store information related tothird party servers 130, third party applications 132,client devices 110, client applications 114,users 106, and the like. The one ormore databases 126 may be implemented using any suitable database management system, such as MySQL, PostgreSQL, Microsoft SQL Server, Oracle, SAP, IBM DB2, or the like. In some embodiments, one ormore databases 126 may include cloud-based storage.

Thereservation system 124 may manage resources and provide back-end support for third-party servers 130, third-party applications 132, client applications 114, and the like, which may include cloud-based applications.Reservation system 124 may provide functionality for the online marketplace for viewing listings related to travel items (e.g., live listings, activity listings, etc.), managing listings, booking listings, and other reservation functionality, among others. Additional details regardingreservation system 124 are shown in fig. 2.

Fig. 2 is a block diagram illustrating areservation system 124 according to some example embodiments.Reservation system 124 includes a front-end server 202, aclient module 204, an administrator module 206, alist items module 208, asearch module 210, and a transaction module 212. The one ormore databases 126 include aclient store 214, anadministrator store 216, alist items store 218, aquery store 220, atransaction store 222, areservation session store 224, and acommunity travel store 226.Reservation system 124 may also include different modules and/or other modules not described herein.

Reservation system 124 may be implemented using a single computing device or a network of computing devices, including cloud-based computer implementations. The computing device may be a server class computer that includes one or more high performance computer processors and random access memory, which may run an operating system such as LINUX. The operation ofreservation system 124 may be controlled by either hardware or by any of a computer program installed in a non-transitory computer readable storage device, such as a solid state device or a magnetic storage device, and executed by a processor to perform the functions described herein.

The front-end server 202 includes program code that allows the client andmanager client devices 110 to communicate with thereservation system 124. Thefront end server 202 may utilize theAPI gateway server 120 and/or theweb server 122 shown in fig. 1. The front-end server 202 may comprise a web server hosting one or more websites accessible via hypertext transfer protocol (HTTP) such that a user agent, such as a web browser software application, may be installed on theclient device 110 and may send commands and receive data from thereservation system 124. The front-end server 202 may also utilize anAPI gateway server 120 that allows software applications installed on theclient device 110 to make calls to APIs to send commands and receive data from thereservation system 124. Thefront end server 202 also includes program code to route commands and data to other components of thereservation system 124 to perform the processes described herein and respond accordingly to theclient device 110.

Theclient module 204 includes program code that allows a client (also referred to herein as a "user" or "guest") to manage its interaction with thereservation system 124 and to execute processing logic for client-related information that may be requested by other components of thereservation system 124. Each client is represented in thereservation system 124 by a separate client object having a unique client ID and a client profile, both stored in theclient store 214.

The client profile includes several client-related attribute fields that may include a profile image and/or other identifying information, a geographic location, a client calendar, and the like. The geographic location of the client is the current location of the client (e.g., based on information provided by the client device 110) or its manually entered home address, neighborhood, city, state, or country of residence. The client location may be used to filter search criteria for expired inventory related to a particular client, or assign default language preferences. Client attributes or features are described further below.

Theclient module 204 provides code for the client to establish and modify the client profile.Reservation system 124 allows each client to communicate with multiple administrators.Reservation system 124 allows clients to exchange communications with an administrator, request transactions, and execute transactions.

The administrator module 206 includes program code that provides a user interface that allows an administrator (also referred to herein as a "host" or "owner") to manage their interaction with thereservation system 124 and to manage listed items, and to perform processing logic for administrator-related information that may be requested by other components of thereservation system 124. Each manager is represented in thereservation system 124 by a separate manager object having a unique manager ID and a manager profile, both stored in themanager store 216.

The manager profile is associated with one or more listed items owned or managed by the manager and includes a number of manager attributes including a transaction request and a calendar set of listed items for each listed item managed by the manager. Client attributes or features are described further below.

The administrator module 206 provides code for the administrator to create and modify administrator profile listings. Theuser 106 of thereservation system 124 may be both a manager and a client. In this case, theuser 106 will have profile entries in theclient store 214 and themanager store 216, and are represented by both the client object and the manager object.Reservation system 124 allows managers to exchange communications, respond to transaction requests, and conduct transactions with other managers.

Thelist items module 208 includes program code for causing an administrator to list travel items, such as due inventory, for a client to make a reservation.Listing module 208 is configured to receive a listing from the administrator that describes the provided inventory, a schedule of its availability (which includes one or more of a start date, and date, a start time, and an end time), a price, a geographic location, images and descriptions characterizing the inventory, and any other relevant information. For example, for a home reservation system, the listed items may include a type of home (e.g., house, apartment, room, sleeping space, or other), an indication of its size (e.g., square feet or number of rooms), a date the home is available, and a price (e.g., every night, week, month, etc.). Thelist items module 208 allows theuser 106 to include additional information about the inventory, such as videos, photos, and other media.

The geographic location associated with a listed item identifies the full address, block, city, and/or country of the listed item that is provided. Thelisting module 208 can also use externally available geographic map information to convert one type of location information (e.g., mailing address) into another type of location information (e.g., country, state, city, and block).

The price of the listed item is the amount the client needs to pay to complete the inventory transaction. The price may be specified as an amount per day, per week, per day, per month, and/or per season or other time interval specified by the administrator. Further, the price may include additional charges (such as a cleanup charge, a pet charge, a service charge, and a tax charge), or the listed item price may be listed separately from the additional charges. Listing item properties or characteristics is described further below.

Each listed item is represented inreservation system 124 by a listed item object that includes listed item information and a unique listed item ID, both of which are stored in listeditem store 218, as provided by the administrator. Each listed item object is also associated with a manager object for the manager providing the listed item.

Each listing object has an associated listing calendar. The listed item calendar stores the listed item availability for each time interval in a time period (each of which may be considered a separate item of expired inventory) as specified by an administrator or automatically determined (e.g., by a calendar import process). For example, the administrator may access an item-listing calendar for a listed item and manually indicate the time intervals during which the listed item is available to the client for trading, which time intervals are restricted to being unavailable to the administrator, and which time intervals are already in the trade (e.g., booked) for the client. In addition, the listed item calendar continues to store historical information regarding the availability of listed items, which identifies which past time intervals have been reserved, limited, or available by the client. In addition, the listing item calendar may include calendar rules (e.g., minimum and maximum number of lodging nights allowed by inventory, minimum or maximum number of lodging nights required for reservation, minimum or maximum number of people allowed by inventory, etc.). Information from each listed item calendar is stored in the listeditem store 218.

Thesearch module 210 includes program code configured to receive an input search query from a client and return a set of due inventory and/or listed items that match the input query. The search query is saved as a query object stored byreservation system 124 inquery store 220. The query may contain a search location, a desired start time/date, a desired duration, a desired listing type, and a desired price range, and may also include other desired attributes or characteristics of the listing. The potential client need not provide all of the parameters of the query listed above in order to receive results from thesearch module 210. Thesearch module 210 provides a set of expired inventory and/or listed items to fulfill parameters of the submitted query in response to the submitted query. The online system may also allow the client to browse through the listed items without submitting a search query, in which case the recorded viewing data will only indicate that the client has viewed a particular listed item without any other details from the submitted search query. After the client provides input selecting expired inventory/listings to more closely examine possible transactions, thesearch module 210 records selection/viewing data indicating which inventory/listings the client viewed. This information is also stored inquery repository 220.

The trading module 212 includes program code configured to enable a client to submit a contract trade request (also referred to as a formal request) to trade against expired inventory. In operation, the transaction module 212 receives a transaction request from a client to transact for an item that is due inventory (such as a particular date range for a listed item provided by a particular administrator). The transaction request may be a standardized request form sent by the client that may be modified with a response to the request by an administrator accepting or rejecting the received request form, thereby enabling agreement terms to be agreed upon between the administrator and the client. Modifications to the received request may include, for example, changing the date, price, or time/date range (and, therefore, which expired inventories were effectively traded). The standardized table may require the client to record a start time/date, a duration (or end time), or any other details that must be included to make acceptance binding without further communication.

The transaction module 212 receives the filled-in form from the client and presents the completed requested form, including the subscription parameters, to the administrator associated with the listed items. The administrator may accept the request, deny the request, or provide a proposed alternative to modifying one or more of the parameters. The administrator accepts the request (or the client accepts the proposed alternative), and the transaction module 212 then updates an acceptance status associated with the request and the expired inventory to indicate that the request was accepted. The client calendar and the listing calendar are also updated to reflect that the expired inventory has been traded within a particular time interval. Other models not specifically described herein allow the client to complete the payment and the administrator to receive the payment.

The transaction module 212 may also include code configured to enable the client to request and be approved for group travel (including group payments for group travel). This may include storing client or user parameters related to the group trip or trip item ingroup trip repository 226; accessing agroup travel repository 226 to determine parameters for a group travel; determining whether a listed item associated with the travel item satisfies a parameter for group travel; perform payment transactions for corporate travel, etc.

Thetransaction repository 222 stores requests made by clients. Each request is represented by a request object. The request includes a timestamp, a requested start time, and a requested duration or reservation end time. Since accepting a subscription by the administrator is a contractually binding agreement with the client (the administrator will provide the client with expired inventory at the specified time), all information that the administrator needs to approve this agreement is included in the request. The response of the administrator to the request consists of a value indicating acceptance or rejection and a timestamp. Other models may allow for instant subscriptions, as described below.

The transaction module 212 may also provide the administrator and the client with the ability to exchange informal transaction requests. Informal requests are not sufficiently binding to clients or managers when accepted, and in terms of content, requests that do not meet any specific requirements made byreservation system 124 for formal transaction requests may be reached from mere communication and general query changes regarding availability of inventory. The transaction module 212 may also store informal requests in thetransaction store 222 because both informal and formal requests provide useful information about the need for expired inventory.

Thesubscription session store 224 stores subscription session data for all subscription sessions performed by clients. Subscription session data may include details about a listed item that has been subscribed to as well as data about one or more other listed items that have been viewed (or seriously considered) but that the client has not subscribed to before subscribing to the listed item. For example, once a listing is reserved, the transaction module 212 may send data about the listing, transactions, view data for reservation session records, and the like, to be stored in thereservation session store 224. The transaction module 212 may utilize other modules or data stores to generate subscription session data to be stored in thesubscription session store 224.

Fig. 3 is a flow diagram illustrating aspects of amethod 300 for processing a request to register a group trip, according to some example embodiments. For illustrative purposes, themethod 300 is described with respect to thenetworked system 100 of fig. 1 and 2. It should be understood that in other embodiments, themethod 300 may be practiced with other system configurations.

In operation 302, a server computing system (e.g.,server system 102 and/or reservation system 124) receives a request to register a group trip from a computing device (e.g., client device 110) associated with a first user. The community associated with the community trip may include a plurality of users (e.g., 2, 5, 10, 25, etc.). For example, a community may include a first user and at least one second user. The group tour may include one or more travel items. For example, travel items may include residences, flights, ground traffic, travel or other activities, and the like. The request may also include one or more parameters for group travel.

For example, a two-person group (traveler a and traveler B) would like to travel together to paris. Traveler a may search for a place of temporary stay in paris via an online marketplace. For example, the online marketplace may provide a user interface via the computing device (e.g., via a local application or web-based interface on the computing device) that allows traveler A to search for listings, view listings, communicate with the host about listings, subscribe to listings, and so forth. The user interface may also provide traveler a with the ability to request group travel and group payment for travel (or travel items).

FIG. 7 illustrates anexample user interface 700 for listing items describing travel items in an online marketplace (e.g., an apartment in Paris). The example listed item shown in fig. 7 is a residence in paris. In other examples, the listed items may be for travel, local experiences, traffic, or other travel items. The listed items may include atitle 701 and a brief description 703 of the travel item. The listed items may also include photographs of the travel items, maps of areas or locations associated with the travel items, street view of the travel items, calendars of the travel items, etc., which may be viewed inarea 707. Listing items may include detailing 709,pricing information 711, and listingitem owner information 713. The listing item may also include an option to request agroup trip 715.

The user may select thegroup travel option 715, specify various parameters associated with the group travel (or travel items), and provide contact information (e.g., name, email address, phone number, address, etc.) for traveler B (or any other user that will be part of the group travel). In one example, traveler A may provide traveler B with an email address.

In one example, the parameters may include a travel date range for the travel, a maximum amount for the travel item or group travel, a maximum amount per night, a per-capita total maximum amount for the travel item, a per-capita maximum amount per night, an amount allocated per user's fee, a minimum number of rooms in a residence, a designated facility for the travel item, and so forth. For example, traveler a may specify that 1 month 15 to 1 month 30 travel, everyone up to $150 per night, two bedrooms, and that appointments will be amortized 50% for each user (e.g., traveler a amortized 50% and traveler B amortized 50%).

The computing device sends a request to a server computing system (e.g., toreservation system 124 viaAPI gateway server 120 or web server 122). In one example, the server computing system may verify whether the user (e.g., the first user) is eligible to participate in a group trip and make a group payment. For example, by verifying the user (e.g., determining whether the user is a trusted user), there may be certain requirements for qualifying the user for group travel and for group payments. A user may be authenticated by having an authenticated identification (e.g., a government issued identification such as a driver's license, passport, etc.) with the server computing system, the user having received a favorable comment from at least one other user (e.g., an owner or listing manager, or other user), the user having a payment device or method authenticated with the server computing system, etc.

As shown inoperation 304, after receiving the request to register for group travel from the computing device, the server computing system sends a notification to other users in the group specified in the request to register for group travel to approve inclusion in the group travel. For example, the server computing system may send an email or other message to a computing device associated with the user (e.g., the second user or traveler B) requesting approval for inclusion in the group trip. The notification may include parameters of the group trip or trip item and request that the user authorize transactions that fall within those parameters. The server computing system may also request that the user provide a payment device or method (e.g., credit card, debit card, money order, electronic check, or other electronic payment or other payment instrument) to be stored in the server computing system so that a charge may be made when future transactions of the group trip are made.

Inoperation 306, the server computing system receives an authorization from a computing device associated with the second user to be included in the group trip. The authorization may include information about the user, payment device information (e.g., payment device identifier and related information), and the like.

In one example, the authorization may also include a change to the parameter by the second user. In another example, the parameter may be changed separately from the authorization (e.g., the second user may authorize being included in the group trip and then change the parameter at the same time or later). For example, the second user may want to change the date, the highest amount paid, the number of rooms, etc. In this example, the server computing system will send a request to the computing device associated with the first user (or other users in the community) to approve the change(s). The first user may approve or reject the change. If the first user approves the change(s), the server computing system may send a notification to a computing device associated with the second user confirming the change to the parameter. The changes to the parameters (e.g., updated parameters) are then stored as parameters associated with the group trip described below inoperation 310.

As explained above, inoperation 308, the server computing system may verify the user on the community trip as a trusted user. If one or more of the users are already part of the online marketplace, the server computer system may authenticate the users (e.g., via username and login, or other user identifier) and have previously been authenticated by simply confirming that the users are already part of the online marketplace, and may confirm that they have provided the payment device. A notification may be sent to the computing device associated with the first user (and the computing devices associated with each of the other users in the community) that the other users in the community have been authenticated. This may be particularly useful when the first user (or other users) in the community does not know or has a good idea of other users in the community.

Inoperation 310, the server computing system stores parameters associated with the corporate travel in one or more databases 126 (e.g., in corporate travel repository 226). The server computing system may also store any user information for use in processing reservations, transactions, etc. for group travel. The server computing system may send a notification to a computing device associated with the first user that the second user has agreed to be part of the group trip. For example, the server computing system may send a message to the computing device associated with traveler a confirming that traveler B has agreed to authorize the transaction associated with the group trip.

Users in the group can now search for group travel and reserve travel items for the group travel. In one example, one user is designated as a lead and is the only user that can reserve travel items. In another example, any user may reserve travel items, or may specify that more than one user reserve travel items. Embodiments described herein allow one or more users the ability to subscribe to a subscription within parameters authorized by the community and to charge payment devices associated with the plurality of users in the community.

FIG. 4 is a flow diagram illustrating aspects of amethod 400 for processing reservations and transactions for group travel items, according to some example embodiments. For illustrative purposes, themethod 400 is described with respect to thenetworked system 100 of fig. 1 and 2. It should be understood that in other embodiments, themethod 400 may be practiced with other system configurations.

In operation 402, a server computing system receives a request for travel items for a reservation group trip. For example, a first user (or a second user or other user) associated with a group trip may search for a residence in the online marketplace and find a place within the parameters of the group trip. For example, the home listing may be located in Marie, Paris, $115 per night, with two bedrooms, five nights from 1 month 20, totaling $1,150. The first user may select the listed item (e.g., via a user interface on a computing device as explained above) to subscribe to the listed item. The computing device may send a request to a server computing system (e.g., toreservation system 124 viaAPI gateway server 120 or web server 122) to reserve a travel item (e.g., a travel item of the listed items). The request may include information associated with the listed items of the travel item, reservation details (e.g., date, amount, etc.), user information, and any other information to process the registration request.

Once the server computing system receives a request to book travel for a group item, the server computing system determines information for processing the request (e.g., travel item listing, reservation details, group travel parameters, etc.) based on the information in the request. In operation 404, the server computing system analyzes the travel items and parameters related to the group travel to determine whether to approve the request. In one example, the server computing system may analyze listed items associated with the travel items and parameters related to group travel to determine whether to approve the request. For example, the server computing system may accesslisting store 218 to determine details of listings associated with travel items, and then accessgroup travel store 226 to determine parameters of a group travel. The server computing system may then compare the parameters of the group trip to the details in the listed item to determine whether the listed item satisfies the requirements in the parameters. For example, the server computing system may compare date ranges, per-night maximum costs for everyone, total costs for reservations, locations of travel items, etc. to parameters to ensure that they each pertain to parameters for group travel.

If the listed item of the travel item does not belong to a parameter of a group travel, the server computing system will deny the request. The server computing system may then send a notification to the computing device associated with the user (and optionally computing devices associated with other users in the community) to notify the user that the reservation will not satisfy the parameters of the community trip, so that the user may then modify the reservation to satisfy the parameters or request a reservation that does belong to another listed item of the parameters for the community trip.

In operation 406, the server computing system approves the request for travel items to reserve the group travel based on determining that the listed items of travel items satisfy the parameters for the group travel. This occurs in near real-time, from the time the user sends a request to reserve travel items. For example, the user may select "confirm reservation" in a user interface of the online marketplace, and then receive a confirmation of the reserved travel item and approve the group travel almost immediately (or be denied because the parameters of the group travel are not met).

In operation 408, upon approval of the request to reserve travel items, the server computing system automatically charges the payment device of each user in the community according to parameters related to the community travel. For example, the server computing system will automatically charge the first user 50% of the total amount and charge the second user 50% of the total amount. In the above Paris example, traveler A would be charged $575 and traveler B would be charged $ 575. In this way, the subscription is paid by the group at the time of the subscription, rather than by the individuals in the group at the time of the subscription. Thus, the example embodiments described herein allow a group of people to make reservations and payments together on a travel platform at the time of the reservation. The example embodiments facilitate aggregation and approval of multiple parties (e.g., a community) of a transaction and assign members to a single subscription transaction.

To automatically charge the payment device, the server computer system may process the payment and charge the payment device using a payment processor or payment card network. For example, the server computing system may send an authorization request including transaction details (e.g., a username, payment device details (e.g., a payment device identifier, an expiration date (e.g., if a credit or debit card), a billing address, etc.) to a payment processor (e.g., to a computing device, such as a server computer associated with the payment processor), the payment processor forwards the authorization request to an issuer of the payment device to be authorized (e.g., to a computing device, such as a server computer associated with the issuer), the server computer associated with the issuer of the payment device approves or denies the transaction (e.g., based on the payment device status and whether the transaction is within certain limits, etc.), the server computer associated with the issuer of the payment device sends an authorization response message to the server computer associated with the payment processor, the authorization response message indicates whether the transaction is approved or denied. A server computer associated with the payment processor sends an authorization response to the server computer system. The server computer system may provide confirmation to the user computing device that the transaction was approved or denied. If the transaction is declined, the server computer system may request another form of payment (e.g., another payment device) to conduct the transaction.

In operation 410, the server computing system sends a confirmation notification confirming the reservation of the travel item to each computing device associated with each user in the community. The notification may include details of the trip, including the journey, residence details, owner/property owner details, and the like.

Example embodiments may work with a community of size n, where x individuals are used to how payments are apportioned. In one example, a five-person community may include two couples and one individual. Example embodiments allow couples members to agree that the couples make payments either together or only as individuals. Thus, for example, a first couple member may agree to pay a fee for both members of the couple (e.g., for example

) Each member of the second couple agrees to pay for its own portion (e.g.

And the individual agrees to pay for his/her part(s) ((

). At the time of booking, when the persons in the group book, the preset proportion based on the agreement is carried out to each part of the groupCharges (in this case 40%, 20% and 20%). In this way, when one of the parties in the community is notified of an upcoming trip, it is specified which part that party will be responsible for, and has the option of taking over the other party's responsibility (in this example, for the couple members).

In one example, the user initiating the formation of the community is designated as the only person who can complete the subscription. In another example, any member of a community may subscribe on behalf of the entire community. In yet another example, once the community members find a suitable residence, a notification is sent to each member regarding the listed items, and each member must approve the particular residence, and only after the community approval, the platform will attempt to book the reservation by charging the payment devices of each member on file.

In one example, the parameters specified by the user initiating the group trip include a date range or particular date of the trip, the highest daily dollar amount spent by each person, the location of the reservation, the number of members required to complete the group, and the like. Additional parameters may include the ability to set the portion to be paid for by each member, the number of bedrooms, or the type of bedroom (e.g., private bedroom or shared space) that each member will have access to as part of the reservation. As an example, a person initiating a group trip of two members may specify that they pay 60% while the other person pays only 40%.

In another example, a community is formed and members are designated as having a reserved right on behalf of others (e.g., designated as a lead team). The other members of the group agree to the lead to make a reservation and archive their payment devices. No additional parameters (or minimum total spending limit) are specified and the lead team has the ability to make reservations. For example, a group of five college students may want to travel together. Kim initiates the team and is designated as the lead team. Each other member in the community is notified to Kim requesting a subscription on their behalf for the five-person community and add their credit card. Kim then has the ability to complete the travel booking and will charge the other members at the time of booking with the appropriate equal share of the community.

In another example, a user initiating a community adds community members when finding a suitable residence. The members of the community are then notified to approve the particular residences selected according to their proportions. Once 100% of the community allocation is approved, the platform makes subscription reservations and charges various members. If the original travel item (e.g., property, travel, etc.) is not reserved, the payment device remains on file and the user can find another travel item (e.g., residence) to reserve and repeat the process for a group of alternate travel items.

In making the group booking, each payment member in the group is considered a member of the booking and will be able to add a rating to the travel item (e.g. residence) or communicate (e.g. via message, chat, phone, etc.) with the owner/owner (e.g. residence owner). Similarly, the host/owner's ratings will be associated with all members of the community and included in their user ratings. The information that is part of the community will also specify who is part of the community by displaying the members' profiles and various statuses, such as whether they have been approved for inclusion in the community or their payment devices have been added to the archive. When a payment device is added to the archive, the platform may perform various checks to ensure the validity of the card ("$ 0 authorization", address check, etc.). In this way, the payment device may also be in the form of an identification verification. If one member's payment device fails during the subscription, the platform can cancel the subscription and refund any payment devices that have been charged. Alternatively, the platform may provide the member with the failure of the payment device a specified time (e.g., 24 hours) for the resolution of the problem by adding an additional payment device or method, and then try again.

If the reservation or subscription is cancelled or modified in the future, payment may be returned to each party in the payment proportion, or if fees are added, additional amounts may be apportioned among the parties in the same proportion. For example, a manager of a listed item, one or more users, or both may make a cancellation or a change. FIG. 5 is a flow diagram illustrating aspects of amethod 500 for processing cancellation of a group travel item, according to some example embodiments. For illustrative purposes, themethod 500 is described with respect to thenetworked system 100 of fig. 1 and 2. It should be understood that in other embodiments, themethod 500 may be practiced with other system configurations.

In operation 502, the server computing system receives a cancellation request from a computing device associated with a user to cancel a travel item associated with a group travel. For example, as explained above, one of the users in the community may cancel a trip via the computing device using the online marketplace's user interface. The computing device may send a cancellation request to the server computing system (e.g., toreservation system 124 viaAPI gateway server 120 or web server 122). The cancellation request may include information about the travel item, the user, and other relevant information.

Inoperation 504, the server computing system analyzes a cancellation policy associated with the travel item. For example, the server computing system may analyze the listed items of the travel item to determine whether the travel item may be cancelled. For example, an online marketplace may have millions of listed items of travel items, and each travel item may have a different cancellation policy. For example, a travel item may have the following cancellation policy: if the travel item is cancelled within 30 days before the travel item start date, it is refunded in full, but if it is cancelled after 30 days, then no refund is made. Another travel item may have the following cancellation policy: if the other travel item is cancelled within 30 days of the travel item's start date, then the travel item is refunded in full; refund 50% of the fare if cancelled within 14 days before the travel item start date; and if cancelled less than 14 days before the travel item start date, no refund is made. As long as the user cancels the reservation 24 hours before the travel item start date, another travel item may have a full refund cancellation policy. Thus, the travel item may have any combination of these or other cancellation strategies. The server computer system may access listing details for travel items inlisting store 218 to determine a cancellation policy. The server computer system may then determine whether the cancellation request may be approved by determining whether information associated with the cancellation request (e.g., the date of the cancellation request, the number of days before the travel item start date, etc.) falls within the cancellation policy for the listed items of the travel item.

As shown inoperation 506, if the server computing system determines that the reservation for the travel item can be cancelled, the server computing system cancels the reservation for the travel item. Inoperation 508, the server computing system automatically refunds the charged amount to each user in the community based on the parameters for the community trip. The server computing system may automatically refund the charged amount to each user in the community using the payment processor.

In one example, prior to canceling a travel item, the server computing system may send a notification to each computing device associated with each other user in the community requesting approval from each member to cancel the travel. In this example, the server computing device can cancel the travel item only if approval is received from each computing device associated with each other user in the community. The server computing system may request that approval be given or denied within a predetermined time period (e.g., 24 hours), otherwise the travel item will be cancelled.

Inoperation 510, the server computing system sends a cancellation confirmation to each computing device associated with each user in the community.

One or more users of the group tour may also want to change reservations for one or more travel items in the group tour. For example, the user may want to change the appointment date, add additional lodging nights to the appointment, remove lodging nights from the appointment, and so on. To this end, as set forth above, a user may send a change request to a server computing system via a computing device using an online marketplace's user interface. The computing device may send a change request to a server computing system (e.g., toreservation system 124 viaAPI gateway server 120 or web server 122). The change request may include information related to the travel item, information for the change, user information, and the like.

The server computing system may send a notification to each computing device associated with each other user in the community trip that each user in the community (e.g., each paying member) is solicited approval to make changes. The server computing system may request approval or deny approval within a predetermined period of time (e.g., 24 hours), otherwise the change request will be denied. If the server computing system receives approval of the change request from other users, the server computing system charges (or refunds) each user of the group trip appropriately according to the parameters of the group trip.

In one example, a user may want to leave a community, but not have the entire community travel cancelled. For example, a first user in a group of five users may want to cancel a seat reserved for the first user in a house trip program in paris. Fig. 6 is a flow diagram illustrating aspects of amethod 600 for handling cancellation of seats of a user in a travel item of a group trip, according to some example embodiments. For illustrative purposes, themethod 600 is described with respect to thenetworked system 100 of fig. 1 and 2. It should be understood that in other embodiments, themethod 600 may be practiced with other system configurations.

In operation 602, the server computing system receives a cancellation request from a computing device associated with a user of a group trip to cancel a seat reserved only for the user's travel items. For example, as set forth above, the user may send a cancel request via the computing device using the online marketplace's user interface. The computing device may send a cancellation request to the server computing system (e.g., toreservation system 124 viaAPI gateway server 120 or web server 122).

In operation 604, the server computing system analyzes the parameters for the group trip to determine a cancellation policy for the group trip. For example, the parameters may allow an individual to cancel without canceling an entire trip, and may specify how the remaining balance is to be allocated after the individual cancels. In another example, the parameter may not allow an individual to cancel, but may specify that the entire travel item be cancelled if one individual cancels. In yet another example, the parameter may specify that each of the other users receive the notification and may approve or deny such cancellation request. In another example, the parameter may specify a minimum number of users for the travel item, and if user cancellation results in the number of users falling below the minimum, then the travel is cancelled, and so on.

In one example, the server computing system may send a notification to each computing device associated with each other user in the community trip that each user in the community (e.g., each paying member) is solicited for approval to cancel. The server computing system may request approval or deny approval for a predetermined period of time (e.g., 24 hours), otherwise the request to cancel will be denied.

If the server computing system determines that the cancellation request does not comply with the parameters for the group trip, the cancellation request will be denied. If the server computing system determines that the cancellation request is allowed based on the parameters (and optionally, approval from each of the other users), then inoperation 606 the server computing system cancels the seats reserved for the user for the travel items and inoperation 608 the charged amount is refunded to the user. In operation 610, the server computing system automatically charges the remaining balance of travel items to the other users remaining in the community according to the parameters for the community travel. As set forth above, the server computing system may utilize a payment processor to refund and/or charge the user. The server computing system may send a notification to each computing device associated with each user confirming that the first user's seat for the travel item has been cancelled.

In one example, the community that the community travels may be an open community or a closed community. For example, a closed community may be a group of users who decide to book a trip together and do not include the ability of others who the community does not know to join at any time. In one example, users A, B and C decide to book the residence of san Francisco via an online marketplace to travel together. User D, who is unknown to users A, B or C of the online marketplace, will not be able to access or join the group trip without user A, B or C explicitly inviting user D.

An open community may be an established group that will allow up to a certain number of users to join a community trip before a certain time limit. For example, a user may reserve a residence for ten people and residence payment may expire within 30 days, after which the reservation will be cancelled if payment is not received. The user may specify that the user be invited to stay in the residence, and/or any user of the online marketplace may be able to visit the community for travel and request to be added to the community. In another example, a user may reserve a trip for fifteen individuals and may specify users to invite to participate in the trip, and/or any user of the online marketplace may be able to visit a group trip and request to be added to the group. The user initiating the reservation for the travel item (or other users in the community) may specify that the user must be authenticated to join the community (e.g., via authenticated identification, favorable comments from other travelers or owners, or other means, as set forth above), a minimum number of users to make a community trip, or other parameters for a community trip.

In another example, users in a community of community travel may join a community travel or one or more travel items for different lengths of time. For example, users A, B, C and D may be part of a community traveling to the community of Nigara melon. Group travel may include ten days of residence on islands of nigalia melon. Users A, B and C may stay in the residence for a full ten days, but user D may only stay in the residence for seven days. In another example, users a and B may be held for the first five days, while users C and D may be held for the last five days, or any other combination. In this example, each user may specify their duration of stay within the travel item appointment. Each user may then be charged accordingly.

As described above, the travel items may include residences, such as houses, apartments, cabins, villages, and so forth. A group travel residence will typically have more than one bedroom since the appointment is for a group of people. In one example, the online marketplace may facilitate subdividing a residence into one or more bedrooms, such that users may each designate a particular bedroom when booking the residence for group travel.

For example, the online marketplace may store information associated with each room in thelistings store 218. The information about each room may include the size of the room (e.g., square feet or relative to other rooms (e.g., largest room, smallest room, etc.)), the facilities associated with the room (e.g., bathroom in the room, from the perspective of the room, closet, desk or other furniture, child-friendly, etc.), the number and size of the beds in the room, whether the room has its own climate control (e.g., air conditioner, heater, fan, etc.), the location of the room in the dwelling (e.g., near the kitchen, behind the house, beside the front door, on the building, below the building, on the main floor, etc.), whether there is an external access to the room, and the like. The online marketplace may also provide the user with the ability to write down an evaluation of a particular room of the home as well as an evaluation of the home itself. In this way, the user can determine which room in the home the user prefers or which room may be most appropriate for the user.

In one example, the fee classification for each user in the community may be based on the user's selection of a room to reserve. For example, user a, user B, and user C may exist in the community. The residence for group travel may be a house comprising a large master bedroom with a king size bed and an indoor bathroom, a medium size room with a full bathroom with a king size bed beside, and a medium size room with a double bed crossing the lobby from the full bathroom. The fee classification may be based on the size of the room and the facilities of the room. For example, a large master bedroom will cost more money than other rooms, a medium sized room with a large bed may cost more money than a room with a double bed, etc. The residence may be $325 per night. The cost of sorting the rooms may be as follows: the master bedroom is $150 a night, the middle room with a large bed is $100 a night, and the room with a double bed is $75 a night. In another example, the fees may be categorized by percentage. For example, a master bedroom may account for 50% of the cost, a mid-size room with a large bed may account for 30% of the cost, and a room with a double bed may account for 20% of the cost.

The cost or categorization based on the size of the rooms and facilities may be determined by the owner of the residence, the online marketplace (e.g., by scoring the size of the total score for each room and each facility, determining from data under evaluation, etc.), or the users in the community.

In one example, a user who is booking a residence may automatically have a first selection of a room. In another example, each user may have a choice of rooms based on when they respond to an authorization request to be included in a group trip. In another example, each user may select rooms based on the order of payment of each user (e.g., a user who pays first obtains a first selection, a user who pays second obtains a second selection, and so on). In yet another example, there may not be a particular order of selection of rooms.

The following examples describe various embodiments of the methods, machine-readable media, and systems (e.g., machines, devices, or other apparatus) discussed herein.

Example 1: a method, comprising:

receiving, by a server computing system from a first computing device associated with a first user, a request to register a group trip including at least one travel item, the request including parameters for the group trip, wherein a group associated with the group trip includes the first user and at least a second user;

sending, by the server computing system, a notification to a second computing device associated with the second user for approval to be included in the group trip;

receiving, by the server computing system from the second computing device, an authorization to be included in the group trip;

receiving, by a server computing system from a first computing device, a request to reserve a travel item for a group travel;

analyzing, by the server computing system, the travel item and the parameters related to the group travel to determine whether to approve the request;

approving, by the server computing system, the request to reserve the travel item for the group trip based on determining that the travel item satisfies the parameter for the group trip;

automatically charging, by the server computing system, a payment device associated with the first user and a payment device associated with the second user according to the parameters related to the group trip; and

a confirmation notification is sent by the server computing system to the first computing device and to the second computing device confirming the reservation of the travel item.

Example 2: the method according to example 1, further comprising:

receiving a cancellation request from a first computing device associated with a first user or a second computing device associated with a second user to cancel a travel item;

analyzing a cancellation policy associated with the travel item to determine whether the travel item can be cancelled;

canceling the travel item; and

the charged amount is refunded to the first user and the second user based on the parameters for the group trip.

Example 3: the method of any of the preceding examples, wherein prior to canceling the travel item, the server computing system sends a request to a computing device associated with the user that did not send the cancellation request for approval from the user that did not send the cancellation request, and the server computing system cancels the travel item only after approval is received from the computing device associated with the user that did not send the cancellation request.

Example 4: the method according to any of the preceding examples, wherein the community further comprises at least one other user, and the method further comprises:

receiving, from a second computing device associated with a second user, a cancellation request to cancel a seat reserved for a travel item for only the second user;

analyzing parameters for the group trip to determine a cancellation policy for the group trip;

determining that a cancellation policy for group travel allows the second user to cancel seats reserved for travel items for only the second user;

canceling a seat reserved for a travel item for only the second user;

refunding the charged amount to the second user; and

the first user and the at least one other user are automatically charged a remaining balance of travel items based on the parameters for the group trip.

Example 5: the method according to any of the preceding examples, wherein the parameters relating to group travel comprise at least one of the group comprising: a date range of travel, a maximum amount of travel services, a maximum amount per night, a per-person maximum total amount of travel services, a per-person maximum amount per night, a cost apportionment amount per user, a minimum number of rooms, and designated facilities for travel services.

Example 6: the method according to any of the preceding examples, further comprising:

the first user is authenticated to confirm that the first user is eligible to participate in the group trip.

Example 7: the method according to any of the preceding examples, further comprising:

parameters for the group trip are stored in one or more data stores.

Example 8: the method of any of the preceding examples, wherein the authorization from the second computing device associated with the second user to be included in the group trip includes a payment device identifier of a payment device to be used for the group trip.

Example 9: the method of any of the preceding examples, wherein the authorization from the second computing device associated with the second user to be included in the group trip includes an alteration to a parameter for the group trip, and the method further comprises:

transmitting, to a first computing device associated with a first user, a request to approve a change to a parameter; and

the change to the parameters for the group trip is stored based on receiving approval from a first computing device associated with the first user.

Example 10: the method according to any of the preceding examples, further comprising:

verifying the second user as a trusted user; and

a notification is sent to a first computing device associated with a first user that a second user has been verified.

Example 11: a server computer, comprising:

at least one processor; and

a computer-readable medium coupled with the at least one processor, the computer-readable medium comprising instructions stored thereon that are executable by the at least one processor to cause a server computer to perform operations comprising:

receiving, from a first computing device associated with a first user, a request to register a group trip including at least one travel item, the request including parameters for the group trip, wherein a group associated with the group trip includes the first user and at least a second user;

sending a notification to a second computing device associated with a second user for approval to be included in the group trip;

receiving, from the second computing device, an authorization to be included in the group trip;

receiving, from a first computing device, a request to reserve a travel item for a group travel;

analyzing the travel items and parameters related to group travel to determine whether to approve the request;

approve the request to reserve the travel item for the group trip based on determining that the travel item satisfies the parameters for the group trip;

automatically charging a payment device associated with the first user and a payment device associated with the second user according to a parameter related to group travel; and

a confirmation notification confirming the reservation of the travel item is sent to the first computing device and to the second computing device.

Example 12: the server computer of any of the preceding examples, the operations further comprising:

receiving a cancellation request from a first computing device associated with a first user or a second computing device associated with a second user to cancel a travel item;

analyzing a cancellation policy associated with the travel item to determine whether the travel item may be able to be cancelled;

canceling the travel item; and

the charged amount is refunded to the first user and the second user based on the parameters for the group trip.

Example 13: the server computer of any of the preceding examples, wherein prior to canceling the travel item, the server computer sends a request to a computing device associated with the user that did not send the cancellation request for approval from the user that did not send the cancellation request, and the server computer cancels the travel item only after approval is received from the computing device associated with the user that did not send the cancellation request.

Example 14: the server computer of any of the preceding examples, wherein the community further comprises at least one other user, and the operations further comprise:

receiving, from a second computing device associated with a second user, a cancellation request to cancel a seat reserved for a travel item for only the second user;

analyzing parameters for the group trip to determine a cancellation policy for the group trip;

determining that a cancellation policy for group travel allows the second user to cancel seats reserved for travel items for only the second user;

canceling a seat reserved for a travel item for only the second user;

refunding the charged amount to the second user; and

the first user and the at least one other user are automatically charged a remaining balance of travel items based on the parameters for the group trip.

Example 15: the server computer according to any of the preceding examples, wherein the parameters relating to the group trip comprise at least one of the group comprising: a date range of travel, a maximum amount of travel services, a maximum amount per night, a per-person maximum total amount of travel services, a per-person maximum amount per night, a cost apportionment amount per user, a minimum number of rooms, and designated facilities for travel services.

Example 16: the server computer of any of the preceding examples, the operations further comprising:

the first user is authenticated to confirm that the first user is eligible to participate in the group trip.

Example 17: the server computer of any of the preceding examples, the operations further comprising:

parameters for the group trip are stored in one or more data stores.

Example 18: the server computer according to any of the preceding examples, wherein the authorization from the second user to be included in the group trip comprises a modification to a parameter for the group trip, and the method further comprises:

transmitting, to a first computing device associated with a first user, a request to approve a change to a parameter; and

the change to the parameters for the group trip is stored based on receiving approval from the first user.

Example 19: the server computer of any of the preceding examples, the operations further comprising:

verifying the second user as a trusted user; and

a notification is sent to a first computing device associated with a first user that a second user has been verified.

Example 20: a non-transitory computer-readable medium comprising instructions stored thereon, the instructions executable by at least one processor to cause a computing device associated with a first data owner to perform operations comprising:

receiving, from a first computing device associated with a first user, a request to register a group trip including at least one travel item, the request including parameters for the group trip, wherein a group associated with the group trip includes the first user and at least a second user;

sending a notification to a second computing device associated with a second user for approval to be included in the group trip;

receiving, from the second computing device, an authorization to be included in the group trip;

receiving, from a first computing device, a request to reserve a travel item for a group travel;

analyzing the travel items and parameters related to group travel to determine whether to approve the request;

approve the request to reserve the travel item for the group trip based on determining that the travel item satisfies the parameters for the group trip;

automatically charging a payment device associated with the first user and a payment device associated with the second user according to a parameter related to group travel; and

a confirmation notification confirming the reservation of the travel item is sent to the first computing device and to the second computing device.

Fig. 8 is a block diagram 800 illustrating a software architecture 802 that may be installed on any one or more of the devices described above. For example, in various embodiments,client device 110 andserver systems 130, 102, 120, 122, and 124 may be implemented using some or all of the elements in software architecture 802. FIG. 8 is only a non-limiting example of a software architecture, and it should be appreciated that many other architectures can be implemented to facilitate the functionality described herein. In various embodiments, the software architecture 802 is implemented by hardware, such as themachine 900 of fig. 9, including aprocessor 910, amemory 930, and input/output (I/O)components 950. In this example, the software architecture 802 may be conceptualized as a stack of layers, where each layer may provide particular functionality. For example, the software architecture 802 includes layers such as an operating system 804, libraries 806, framework 808, and applications 810. Operationally, according to some embodiments, an application 810 invokes an Application Programming Interface (API) call 812 through a software stack and receives amessage 814 in response to theAPI call 812.

In various implementations, the operating system 804 manages hardware resources and provides common services. Operating system 804 includes, for example, a kernel 820,services 822, anddrivers 824. According to some embodiments, the kernel 820 acts as an abstraction layer between hardware and other software layers. For example, kernel 820 providesFor memory management, processor management (e.g., scheduling), component management, networking, and security settings, among other functionalities.Service 822 may provide other common services for other software layers. According to some embodiments, thedrivers 824 are responsible for controlling or interfacing with the underlying hardware. For example,drivers 824 may include a display driver, a camera driver, a BLUETOOTH

Or BLUETOOTH

Low power drivers, flash drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), WI-FI

Drivers, audio drivers, power management drivers, and the like.

In some embodiments, the library 806 provides a low-level public infrastructure utilized by the applications 810. The library 806 may include a system library 830 (e.g., a C-standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematical functions, and the like. In addition, the libraries 806 may includeAPI libraries 832, such as media libraries (e.g., libraries for supporting the presentation and manipulation of various media formats, such as moving picture experts group 4(MPEG4), advanced video coding (h.264 or AVC), moving picture experts group layer 3(MP3), Advanced Audio Coding (AAC), adaptive multi-rate (AMR) audio codec, joint picture experts group (JPEG or JPG), or Portable Network Graphics (PNG)); a graphics library (e.g., an OpenGL framework for rendering in two-dimensional (2D) and three-dimensional (3D) graphics content on a display); a database (e.g., SQLite to provide various related database functions); web libraries (e.g., WebKit for providing web browsing functionality), and the like. The library 806 may also include variousother libraries 834 for providing many other APIs to the application 810.

According to some embodiments, framework 808 provides a high-level public infrastructure that can be utilized by applications 810. For example, the framework 808 provides various Graphical User Interface (GUI) functions, advanced resource management, advanced location services, and the like. The framework 808 may provide various other APIs that may be utilized by the applications 810, some of which may be specific to a particular operating system 804 or platform.

In an example embodiment, the applications 810 include ahome application 850, acontacts application 852, a browser application 854, a book-viewer application 856, a positioning application 858, amedia application 860, amessaging application 862, agaming application 864, and various other applications, such as a third-party application 866. According to some embodiments, the application 810 is a program that performs functions defined in the program. Various programming languages may be employed to create one or more of the variously structured applications 810, such as an object-oriented programming language (e.g., Objective-C, Java or C + +) or a procedural programming language (e.g., C or assembly language). In a particular example, the third-party application 866 (e.g., using ANDROID by an entity other than a provider of a particular platform)^TMOr IOS^TMApplications developed by Software Development Kit (SDK) may be mobile software running on a mobile operating system, such as an IOS^TM、ANDROID^TM、

Phone or another mobile operating system. In this example, a third party application 866 may enable API calls 812 provided by the operating system 804 to facilitate the functionality described herein.

Some embodiments may specifically include atravel reservation application 867, which may be any application that requests data or other tasks performed by the systems and servers described herein (such asserver system 102,third party server 130, etc.). In some embodiments, the travel reservation application may be a standalone application for managing communications with a server system, such as thethird party server 130 or theserver system 102. In other embodiments, the functionality may be integrated with another application. Thetravel reservation application 867 may request and display various data related to the online marketplace, and may provide theuser 106 with the following capabilities: input data related to the system via voice, touch interface, keyboard, or camera device using themachine 900, communicate with the server system via the I/O component 950, and receive and store object data in thememory 930. The presentation of information and user input associated with the information may be managed by thetravel reservation application 867 using different frameworks 808, library 806 elements, or operating system 804 elements operating on themachine 900.

Fig. 9 is a block diagram illustrating components of amachine 900 capable of reading instructions from a machine-readable medium (e.g., a machine-readable storage medium) and performing any one or more of the methodologies discussed herein, in accordance with some embodiments. In particular, fig. 9 shows a diagrammatic representation of amachine 900 in the example form of a computer system within which instructions 916 (e.g., software, a program, an application 810, an applet, an app, or other executable code) for causing themachine 900 to perform any one or more of the methodologies discussed herein may be executed. In alternative embodiments, themachine 900 may operate as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, themachine 900 may operate in the capacity of aserver machine 130, 102, 120, 122, 124, 128, or the like, or a client device 90 in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. Themachine 900 may include, but is not limited to, a server computer, a client computer, a Personal Computer (PC), a tablet computer, a laptop computer, a netbook, a Personal Digital Assistant (PDA), an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web device, a network router, a network switch, a network bridge, or any machine capable of executing theinstructions 916 in a sequential or other manner that specify actions to be taken by themachine 900. Additionally, while only asingle machine 900 is illustrated, the term "machine" shall also be taken to include a collection ofmachines 900 that individually or jointly execute theinstructions 916 for performing any one or more of the methodologies discussed herein.

In various embodiments, themachine 900 includes aprocessor 910, amemory 930, and I/O components 950 that may be configured to communicate with each other via a bus 902. In an example embodiment,processor 910, such as a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Radio Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof, includes, for example, aprocessor 912 and aprocessor 914 that may executeinstructions 916. The term "processor" is intended to include amulti-core processor 910, which may include two or moreindependent processors 912, 914 (also referred to as "cores") that may simultaneously executeinstructions 916. Although fig. 9 showsmultiple processors 910, themachine 900 may include asingle processor 910 with a single core, asingle processor 910 with multiple cores (e.g., a multi-core processor 910),multiple processors 912, 914 with a single core,multiple processors 912, 914 with multiple cores, or any combination thereof.

According to some embodiments, thememory 930 includes amain memory 932, astatic memory 934, and a storage unit 936 that are accessible to theprocessor 910 via the bus 902. The storage unit 936 may include a machine-readable medium 938 on which are storedinstructions 916 embodying any one or more of the methodologies or functions discussed herein. Theinstructions 916 may also reside, completely or at least partially, within themain memory 932, within thestatic memory 934, within at least one of the processors 910 (e.g., within the processor's cache memory), or any suitable combination thereof during execution thereof by themachine 900. Accordingly, themain memory 932, thestatic memory 934, and theprocessor 910 are considered machine-readable media 938 in various embodiments.

As used herein, the term "memory" refers to a machine-readable medium 938 that is capable of storing data, either temporarily or permanently, and may be understood to include, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), cache memory, flash memory, and cache memory. While the machine-readable medium 938 is shown in an example embodiment to be a single medium, the term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that are capable of storing theinstructions 916. The term "machine-readable medium" shall also be taken to include any medium, or combination of media, that is capable of storing instructions (e.g., instructions 916) for execution by a machine (e.g., machine 900), such that theinstructions 916, when executed by one or more processors of the machine 900 (e.g., processors 910), cause themachine 900 to perform any one or more of the methodologies described herein. Thus, "machine-readable medium" refers to a single storage apparatus or device as well as a "cloud-based" storage system or storage network that includes multiple storage apparatuses or devices. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, one or more data repositories in the form of a solid-state memory (e.g., flash memory), an optical medium, a magnetic medium, other non-volatile memory (e.g., erasable programmable read-only memory (EPROM)), or any suitable combination thereof. The term "machine-readable medium" specifically excludes non-statutory signals per se.

The I/O components 950 include various components for receiving input, providing output, generating output, transmitting information, exchanging information, capturing measurements, and so forth. In general, it should be appreciated that I/O components 950 can include many other components not shown in FIG. 9. The I/O components 950 are grouped according to functionality merely to simplify the following discussion, and the grouping is in no way limiting. In various example embodiments, the I/O components 950 include output components 952 and input components 954. Output components 952 include visual components (e.g., a display, such as a Plasma Display Panel (PDP), a Light Emitting Diode (LED) display, a Liquid Crystal Display (LCD), a projector, or a Cathode Ray Tube (CRT)), acoustic components (e.g., speakers), tactile components (e.g., a vibrating motor), other signal generators, and so forth. Input components 954 include alphanumeric input components (e.g., a keyboard, a touch screen configured to receive alphanumeric input, an electro-optical keyboard, or other alphanumeric input components), point-based input components (e.g., a mouse, touchpad, trackball, joystick, motion sensor, or other pointing tool), tactile input components (e.g., physical buttons, a touch screen that provides the location and force of a touch or touch gesture, or other tactile input components), audio input components (e.g., a microphone), and so forth.

In some other example embodiments, the I/O components 950 include a biometric component 956, a motion component 958, an environmental component 960, or a location component 962 among various other components. For example, the biometric component 956 includes components for detecting expressions (e.g., hand expressions, face expressions, vocal expressions, body gestures, or eye tracking), measuring bio-signals (e.g., blood pressure, heart rate, body temperature, sweat, or brain waves), identifying a person (e.g., voice recognition, retinal recognition, facial recognition, fingerprint recognition, or electroencephalogram-based recognition), and so forth. The motion components 958 include acceleration sensor components (e.g., accelerometers), gravity sensor components, rotation sensor components (e.g., gyroscopes), and so forth. The environmental components 960 include, for example, lighting sensor components (e.g., photometer), temperature sensor components (e.g., one or more thermometers that detect ambient temperature), humidity sensor components, pressure sensor components (e.g., barometer), acoustic sensor components (e.g., one or more microphones that detect background noise), proximity sensor components (e.g., infrared sensors that detect nearby objects), gas sensor components (e.g., machine olfaction detection sensors, gas detection sensors for detecting concentrations of harmful gases for safety or for measuring pollutants in the atmosphere), or other components that may provide indications, measurements, or signals corresponding to the surrounding physical environment. The location component 962 includes a location sensor component (e.g., a Global Positioning System (GPS) receiver component), an altitude sensor component (e.g., an altimeter or barometer that detects barometric pressure from which altitude may be derived), an orientation sensor component (e.g., a magnetometer), and so forth.

Communication may be accomplished using various techniques. The I/O components 950 may include acommunications component 964 operable to couple themachine 900 to a network 980 or a device 970 via acoupling 982 and acoupling 972, respectively. For example, thecommunication component 964 includes a network interface component or another suitable device that interfaces with the network 980. In other examples,communications component 964 is included for communication via otherA wired communication component, a wireless communication component, a cellular communication component, a Near Field Communication (NFC) component, a wireless communication component, a cellular communication component, a near field communication component, a wireless communication component,

component (e.g.)

Low power consumption),

Components, and other communication components. The device 970 may be anothermachine 900 or any of a variety of peripheral devices, such as a peripheral device coupled via a Universal Serial Bus (USB).

Further, in some embodiments, thecommunication component 964 detects the identifier or includes a component operable to detect the identifier. For example, thecommunication components 964 include Radio Frequency Identification (RFID) tag reader components, NFC smart tag detection components, optical reader components (e.g., optical sensors for detecting one-dimensional barcodes, such as Universal Product Code (UPC) barcodes, multi-dimensional barcodes, such as Quick Response (QR) codes, Aztec codes, data matrices, Dataglyph, MaxiCode, PDF417, supercode, uniform commercial code reduced space symbology (UCC RSS) -2D barcodes, and other optical codes), acoustic detection components (e.g., microphones for identifying tagged audio signals), or any suitable combination thereof. Further, various information can be derived via thecommunications component 964, such as location via Internet Protocol (IP) geo-location, via

Positioning by triangulation of signals, indicating a particular position by detection

Or NFC beacon signals for location, etc.

In various example embodiments, one or more portions of the network 980 may be an ad hoc network, an intranet, an extranet, a Virtual Private Network (VPN), a,A Local Area Network (LAN), a Wireless LAN (WLAN), a Wide Area Network (WAN), a Wireless WAN (WWAN), a Metropolitan Area Network (MAN), the Internet, a portion of the Public Switched Telephone Network (PSTN), a Plain Old Telephone Service (POTS) network, a cellular telephone network, a Wireless Local Area Network (WLAN), a Wide Area Network (WAN), a WWAN), a Metropolitan Area Network (MAN), the Internet,

A network, another type of network, or a combination of two or more such networks. For example, the network 980 or a portion of the network 980 may include a wireless or cellular network, and thecoupling 982 may be a Code Division Multiple Access (CDMA) connection, a global system for mobile communications (GSM) connection, or another type of cellular or wireless coupling. In this example, thecoupling 982 may implement any of various types of data transmission techniques, such as single carrier radio transmission technology (1xRTT), evolution-data optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, enhanced data rates for GSM evolution (EDGE), third generation partnership project (3GPP) including 3G, fourth generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standards, other standards defined by various standards-setting organizations, other remote protocols, or other data transmission technologies.

In an example embodiment, theinstructions 916 are transmitted or received over the network 980 via a network interface device (e.g., a network interface component included in the communications component 964) using a transmission medium and utilizing any one of several known transmission protocols (e.g., the hypertext transfer protocol (HTTP)). Similarly, in other example embodiments, theinstructions 916 are transmitted or received to the device 970 using a transmission medium via coupling 972 (e.g., a peer-to-peer coupling). The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding or carryinginstructions 916 for execution by themachine 900, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

Further, the machine-readable medium 938 is non-transitory (in other words, does not have any transient signals) because it does not embody a propagating signal. However, labeling the machine-readable medium 938 as "non-transitory" should not be construed to mean that the medium cannot move; the medium 938 should be considered transportable from one physical location to another. Further, because the machine-readable medium 938 is tangible, the medium 938 may be considered a machine-readable device.

Throughout this specification, multiple instances may implement a component, an operation, or a structure described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in the example configurations may be implemented as a combined structure or component. Similarly, structure and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.

Although the summary of the present subject matter has been described with reference to specific example embodiments, various modifications and changes may be made to the embodiments without departing from the broader scope of the embodiments of the disclosure.

The embodiments illustrated herein are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The detailed description is, therefore, not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

As used herein, the term "or" may be interpreted in either an inclusive or exclusive sense. Furthermore, multiple instances may be provided for a resource, operation, or structure described herein as a single instance. In addition, boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are contemplated and may fall within the scope of various embodiments of the disclosure. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within the scope of the embodiments of the disclosure as represented by the claims that follow. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (20)

1. A method, comprising:

receiving, by a server computing system from a first computing device associated with a first user, a request to register a group trip including at least one travel item, the request including parameters for the group trip, wherein a group associated with the group trip includes the first user and at least a second user;

sending, by the server computing system, a notification to a second computing device associated with the second user for approval to be included in the group trip;

receiving, by the server computing system, an authorization to be included in the group trip from the second computing device;

receiving, by the server computing system from the first computing device, a request to reserve a travel item for the group trip;

analyzing, by the server computing system, the travel item and the parameter related to the group travel to determine whether to approve the request;

approving, by the server computing system, the request to reserve the travel item for the group trip based on determining that the travel item satisfies the parameter for the group trip;

automatically charging, by the server computing system, a payment device associated with the first user and a payment device associated with the second user according to the parameter related to the group trip; and

sending, by the server computing system, a confirmation notification to the first computing device and to the second computing device confirming the reservation of the travel item.

2. The method of claim 1, further comprising:

receiving a cancellation request from the first computing device associated with the first user or the second computing device associated with the second user to cancel the travel item;

analyzing a cancellation policy associated with the travel item to determine whether the travel item can be cancelled;

canceling the travel item; and

refunding the charged amount to the first user and the second user based on the parameter for the group trip.

3. The method of claim 2, wherein prior to canceling the travel item, the server computing system sends a request to a computing device associated with the user that did not send the cancellation request for approval from the user that did not send the cancellation request, and the server computing system cancels the travel item only after approval is received from the computing device associated with the user that did not send the cancellation request.

4. The method of claim 1, wherein the community further comprises at least one other user, and the method further comprises:

receiving, from the second computing device associated with the second user, a cancellation request to cancel seats reserved for the travel item only for the second user;

analyzing the parameters for the group trip to determine the cancellation policy for the group trip;

determining that the cancellation policy for the group trip allows the second user to cancel the seat reserved for the travel item for the second user only;

canceling the seat reserved for the travel item for only the second user;

refunding the charged amount to the second user; and

automatically charging the first user and the at least one other user for the remaining balance of the travel items based on the parameters for the group trip.

5. The method of claim 1, wherein the parameters related to the corporate travel comprise at least one of the group consisting of: a date range of the trip, a maximum amount of the travel service, a maximum amount per night, a per-person maximum total amount of the travel service, a per-person maximum amount per night, a cost contribution amount per user, a minimum number of rooms, and designated facilities of the travel service.

6. The method of claim 1, further comprising:

authenticating the first user to confirm that the first user is eligible to participate in a group trip.

7. The method of claim 1, further comprising:

storing the parameters for the group trip in one or more data stores.

8. The method of claim 1, wherein the authorization from the second computing device associated with the second user to be included in the group trip comprises a payment device identifier of a payment device to be used for the group trip.

9. The method of claim 1, wherein the authorization from the second computing device associated with the second user to be included in the community trip comprises an alteration to the parameters for the community trip, and the method further comprises:

sending a request to the first computing device associated with the first user to approve the change to the parameter; and

storing the change to the parameter for the group trip based on receiving approval from the first computing device associated with the first user.

10. The method of claim 1, further comprising:

verifying the second user as a trusted user; and

sending a notification to the first computing device associated with the first user that the second user has been verified.

11. A server computer, the server computer comprising:

at least one processor; and

a computer-readable medium coupled with the at least one processor, the computer-readable medium comprising instructions stored thereon that are executable by the at least one processor to cause the server computer to perform operations comprising:

receiving, from a first computing device associated with a first user, a request to register a group trip including at least one travel item, the request including parameters for the group trip, wherein a group associated with the group trip includes the first user and at least a second user;

sending a notification to a second computing device associated with the second user for approval to be included in the group trip;

receiving, from the second computing device, an authorization to be included in the group trip;

receiving, from the first computing device, a request to reserve a travel item for the group travel;

analyzing the travel items and the parameters related to the group trip to determine whether to approve the request;

approve the request to reserve the travel item for the group trip based on determining that the travel item satisfies the parameters for the group trip;

automatically charging a payment device associated with the first user and a payment device associated with the second user in accordance with the parameters related to the group trip; and

sending a confirmation notification to the first computing device and to the second computing device confirming the reservation of the travel item.

12. The server computer of claim 11, the operations further comprising:

receiving a cancellation request from the first computing device associated with the first user or the second computing device associated with the second user to cancel the travel item;

analyzing the cancellation policy associated with the travel item to determine whether the travel item can be cancelled;

canceling the travel item; and

refunding the charged amount to the first user and the second user based on the parameter for the group trip.

13. The server computer of claim 12, wherein prior to canceling the travel item, the server computer sends a request to a computing device associated with the user that did not send the cancellation request for approval from the user that did not send the cancellation request, and the server computer cancels the travel item only after approval is received from the computing device associated with the user that did not send the cancellation request.

14. The server computer of claim 11, wherein the community further comprises at least one other user, and the operations further comprise:

receiving, from the second computing device associated with the second user, a cancellation request to cancel seats reserved for the travel item only for the second user;

analyzing the parameters for the group trip to determine the cancellation policy for the group trip;

determining that the cancellation policy for the group trip allows the second user to cancel the seat reserved for the travel item for the second user only;

canceling the seat reserved for the travel item for only the second user;

refunding the charged amount to the second user; and

automatically charging the first user and the at least one other user for the remaining balance of the travel items based on the parameters for the group trip.

15. The server computer of claim 11, wherein the parameters related to the corporate travel comprise at least one of the group consisting of: a date range of the trip, a maximum amount of the travel service, a maximum amount per night, a per-person maximum total amount of the travel service, a per-person maximum amount per night, a cost contribution amount per user, a minimum number of rooms, and designated facilities of the travel service.

16. The server computer of claim 11, the operations further comprising:

authenticating the first user to confirm that the first user is eligible to participate in a group trip.

17. The server computer of claim 11, the operations further comprising:

storing the parameters for the group trip in one or more data stores.

18. The server computer of claim 11, wherein the authorization from the second user to be included in the group trip comprises a change to the parameters for the group trip, and the method further comprises:

sending a request to the first computing device associated with the first user to approve the change to the parameter; and

storing the change to the parameter for the group trip based on receiving approval from the first user.

19. The server computer of claim 11, the operations further comprising:

verifying the second user as a trusted user; and

sending a notification to the first computing device associated with the first user that the second user has been verified.

20. A non-transitory computer-readable medium comprising instructions stored thereon, the instructions executable by at least one processor to cause a computing device associated with a first data owner to perform operations comprising:

receiving, from a first computing device associated with a first user, a request to register a group trip including at least one travel item, the request including parameters for the group trip, wherein a group associated with the group trip includes the first user and at least a second user;

sending a notification to a second computing device associated with the second user for approval to be included in the group trip;

receiving, from the second computing device, an authorization to be included in the group trip;

receiving, from the first computing device, a request to reserve a travel item for the group travel;

analyzing the travel items and the parameters related to the group trip to determine whether to approve the request;

approve the request to reserve the travel item for the group trip based on determining that the travel item satisfies the parameters for the group trip;

automatically charging a payment device associated with the first user and a payment device associated with the second user in accordance with the parameters related to the group trip; and

sending a confirmation notification to the first computing device and to the second computing device confirming the reservation of the travel item.

Images