[go: up one dir, main page]

WO2015032807A1 - Système et procédé d'étanchéité - Google Patents

Système et procédé d'étanchéité Download PDF

Info

Publication number
WO2015032807A1
WO2015032807A1 PCT/EP2014/068718 EP2014068718W WO2015032807A1 WO 2015032807 A1 WO2015032807 A1 WO 2015032807A1 EP 2014068718 W EP2014068718 W EP 2014068718W WO 2015032807 A1 WO2015032807 A1 WO 2015032807A1
Authority
WO
WIPO (PCT)
Prior art keywords
ticket
user
status
host server
tickets
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2014/068718
Other languages
English (en)
Inventor
Vivien RICHTER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fine Dining Experiences Ug
Original Assignee
Fine Dining Experiences Ug
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fine Dining Experiences Ug filed Critical Fine Dining Experiences Ug
Priority to US14/915,706 priority Critical patent/US20160196508A1/en
Priority to JP2016537345A priority patent/JP6309629B2/ja
Publication of WO2015032807A1 publication Critical patent/WO2015032807A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants

Definitions

  • the present disclosure relates to changing communication models between a business entity and a user. More particularly, the present disclosure relates to a system and method for purchasing a booking through a computing device.
  • a guest may email the restaurant and/or any other business entity and ask for a booking.
  • a few disadvantages of this method may include: the guest not having access to full data for bookings, the method being too time consuming and costly for the guest and/or restaurant and/or any other business entity, and/or the system may be difficult to work with and not user friendly.
  • a guest may use an online system to make a booking.
  • the guest may check an online calendar for open tables, time and/or date of availability.
  • a few disadvantages of this method may comprise: no personal contact, no transparency and/or the system may be difficult to operate.
  • An aspect of an example embodiment of the present disclosure is to provide a system and method for purchasing a booking through a computing device.
  • This system may support both the restaurateur and/or business entity and the guest by changing communication models and optimizing the process of a booking.
  • the system provides power, control, and transparency to restaurateurs and/or business entities, while still allowing guests flexibility in making bookings.
  • the system is designed to help multiple groups of people including: the best agers, the youngsters, the concierges, the locals, the businessmen, the travelers, the culinary professionals, the VIPs, and/or any other category of people.
  • Best agers may look for easy to handle solutions, for a long time in advance and/or last minute bookings. Youngsters may want last minute bookings and maybe want a system which allows them to join their parents as walk in guests. Concierges make bookings for guests including last minute bookings for walk in guests. Locals may know the restaurant, and regularly reserve 1-2 weeks in advance if possible and/or request last minute bookings. Businessmen may have a need for last minute bookings which is planned by an assistant. Travelers may request a booking a long time in advance, may request last minute bookings, and/or want to be walk in guests. Culinary professionals may include: journalists, fine dining lovers, chefs and/or restaurateurs, food scientists, and/or cookbook writers. This group may prefer bookings made a long time in advance and/or last minute bookings. VIPs may be well connected to the restaurant and may always obtain a table and/or want last minute bookings.
  • the system may provide many options for restaurants and/or business entities, including: publishing tables to prospective guest, controlling transparency, avoiding no shows, dynamical pricing, managing social guest structure, profiting from common databases, and/or saving money among others.
  • the system may additionally provide many options for guest, including: subscribing for preferred dates, organizing an interest list, receiving updates via push notifications, easy click and buy arrangements, peer to peer resale of a table, dining spontaneously, and saving time among others.
  • a computer-implemented method and system comprise storing, by a host server in a ticket database, information related to a plurality of restaurants comprising tickets corresponding to bookings at restaurants, the bookings containing time and date information, the tickets containing an available status or an unavailable status; receiving, by the host server, a request from the first user computing device to purchase a ticket with an available status, the ticket corresponding to a booking at a restaurant, the ticket containing time and date information; upon receiving a transmission of payment instructions from the first user computing device, associating, by the host server, the ticket with the first user in the ticket database and changing the status of the ticket to unavailable; transmitting, by the host server to the first user computing device, the ticket to the first user; changing, by the host server, the status of the ticket in the ticket database to an unavailable status; receiving, by the host server from the first user computing device, a request to change the status of the ticket from unavailable to available in the ticket database; changing, by the host server, the status of the ticket from unavailable
  • a method and system comprise storing, by a host server in a ticket database, information related to tickets corresponding to events at a business, the events containing time and date information, the tickets containing an available status or an unavailable status, and storing, in a customer database, profile information for users that have purchased tickets; searching, by the host server, tickets in the ticket database with the available status during a predetermined period of time; receiving, by the host server from the entity server, a list of tickets with the available status and tickets with the unavailable status; searching, by the host server in the customer database, profile information for users that did not purchase tickets during the predetermined period of time; and posting, by the host server, tickets with the available status and sending push notifications to the computing devices of users that did not purchase tickets during the predetermined period of time regarding the tickets with the available status during the predetermined period of time.
  • a method and system comprise storing, by a host server, in a ticket database, information related to a plurality of businesses comprising tickets corresponding to events at the businesses, the events containing time and date information, the tickets containing an available status or an unavailable status; receiving, by the host server from the first user computing device, a request to purchase a ticket with an available status within a timeframe determined by the first user, the ticket corresponding to an event at a business, the ticket containing time and date information; upon identifying a ticket in the ticket database with an available status for a time within the timeframe and upon receiving a transmission of payment instructions from the first user computing device, associating, by the host server, the ticket with an available status within the timeframe with the first user in the ticket database and changing the status of the ticket to unavailable; transmitting, by the host server to the first user computing device, the ticket to the first user; changing, by the host server, the status of the ticket in the ticket database to an unavailable status; receiving, by the host server from the first user
  • FIG. 1 is a diagram of a network environment for creating a booking through a computing device according to an exemplary embodiment.
  • FIG. 2 illustrates method of creating a booking through a computing device according to an exemplary embodiment.
  • FIG. 3A illustrates a user interface for creating a booking through a computing device according to an exemplary embodiment.
  • FIG. 3B illustrates a user interface for creating a booking through a computing device according to an exemplary embodiment.
  • FIG. 3C illustrates a user interface for creating a booking through a computing device according to an exemplary embodiment.
  • FIG. 3D illustrates a user interface for transferring a booking through a computing device according to an exemplary embodiment.
  • FIG. 3E illustrates a user interface for creating a booking through a computing device according to an exemplary embodiment.
  • FIG. 3F illustrates a user interface for creating a booking through a computing device according to an exemplary embodiment.
  • FIG. 3G illustrates a user interface for a user profile for booking through a computing device according to an exemplary embodiment.
  • FIG. 4 illustrates method of selling a booking through a computing device according to an exemplary embodiment.
  • FIG. 5A illustrates a user interface for selling a booking through a computing device according to an exemplary embodiment.
  • FIG. 5B illustrates a user interface for selling a booking through a computing device according to an exemplary embodiment.
  • FIG. 5C illustrates a user interface for an overview of completed bookings on a user interface of a computing device according to an exemplary embodiment.
  • FIG. 5D illustrates a user interface for a booked ticket through a computing device according to an exemplary embodiment.
  • FIG. 5E illustrates a user interface for selling a booking through a computing device according to an exemplary embodiment.
  • FIG. 6 is a diagram for a booking processes, including payment and peer-to-peer transfer, through a network environment according to an exemplary embodiment.
  • the system may provide a platform where users may purchase and/or sell tickets for bookings and/or any other events.
  • the system allows notifications to be sent to users who may be interested in receiving the tickets. Different users may receive different ticket notifications at different times based on their profile information and/or user status. The users may search for and purchase a ticket being resold by another user.
  • the system also manages all payment and credit used to purchase and/or sell the tickets.
  • the system may allow business entities to manage interest lists. For example, restaurants may see who is interested in dining at their location and can filter people. Tables can be sent to interested guests and will be addressed as a post from the restaurant. Restaurants and/or business entities may decide when it is necessary to send out a new arrangement together with the post. Depending on the price structure at the restaurant and/or business entity the system may offer various pricing options as well as different tools for a sustainable pricing model. The system may allow tickets to be exchanged between customers, which may be limited to face value only.
  • a fee may be charged for each booking and/or booking which are included in the tickets and/or added to the user's shopping bag.
  • Direct updates may be sent to guests with offers of demanded tables. Guest may be allowed to obtain tables spontaneous and last minute in the best restaurants all around the world. Guests may be able to resell their booked tickets directly with the system.
  • business entities and/or restaurants may be able to use behavioral targeting and may see their guest structure (business man, tourist, local) allowing guests feel more comfortable.
  • the business entity and/or restaurants may plan targeted marketing actions..
  • the business entity and/or restaurant may use more than one option, for example, to offer a table at a restaurant.
  • tables may have flexible prices based on different dates and/or times.
  • Business entities may create a price for the claims of every list, keep their pricing model more flexible (e.g., food costs, season, sustainability, staff, design objects etc.).
  • the business entity and/or restaurant may have the option to decide, when making processes transparent and when professionally hiding them.
  • the flexibility of system may allow the business entity and/or restaurant to address only those people, who are added to the "interest list".
  • the system may be advantageous for the business entity and/or restaurant by: allowing a user to operate a barrier-free tool; creating an easy to use system which may easily synchronize with it on the backend and other backend systems (e.g., Opentable, Seatme, Livebookings); to be offered as a white label product and integrated into other market segments; allow the restaurant and/or business entity to control and transparency as needed and wanted; create flexible pricing models; avoid "no shows” and manage utilization; allow for spontaneous reactions fitting the situation and/or the transfer of responsibility to the guest side.
  • the system may be advantageous for the guest by allowing a user to: buy tickets spontaneously; plan dining trips with the calendar; save searched interests with subscriptions; receive push notifications matching subscriptions; and/or to not get a "no" on the phone anymore when making booking.
  • Any verbs as disclosed herein can imply direct or indirect action or inaction.
  • an element when referred to as being “on,” “connected” or “coupled” to another element, it can be directly connected or coupled to the other element or intervening elements may be present.
  • an element when referred to as being “directly connected” or “directly coupled” to another element, there are no intervening elements present.
  • first, second, etc. may be used herein to describe various elements, components, regions, layers and/or sections, these elements, components, regions, layers and/or sections should not be limited by these terms. These terms are only used to distinguish one element, component, region, layer or section from another element, component, region, layer or section. Thus, a first element, component, region, layer or section discussed below could be termed a second element, component, region, layer or section without departing from the teachings of the present disclosure.
  • an application may be installed on a mobile computing device of a guest, patron, customer, and/or user.
  • the application may communicate with a server through a communication network such as a local area network, Wi-Fi, cellular network, and/or any other communication network.
  • the server may be hosted by a business establishment (e.g., a restaurant, bar, hotel, salon, airline, gas station) and/or a third party that can communicate with the business establishment and/or patron, customer, or user.
  • the server may also communicate with payment systems, such as credit card processing systems or other banking systems to process payments.
  • the "host server”, “entity server”, and/or a "host system” may be implemented interchangeably.
  • the business establishment may have a host system, which is a venue point of sale system that may communicate with a server of the business establishment and/or restaurant and/or may directly communicate with a third party, patron, customer, and/or user.
  • the host system may be configured to open a tab and/or a ticket for each table, party, customer, patron, user, or other entity submitting a request for a product or service.
  • the mobile device, one or more server, and the host system may be referred to herein as a system, which may also include other servers and databases to provide the described functionality.
  • the patron, guest, customer, and/or user may use a client computing device, such as a mobile phone, cellular phone, smartphone, personal data assistant, tablet computer, laptop computer, and/or other computing device that can connect to a communication network.
  • client computing device such as a mobile phone, cellular phone, smartphone, personal data assistant, tablet computer, laptop computer, and/or other computing device that can connect to a communication network.
  • these terms may be used interchangeably.
  • FIG. 1 illustrates a system 100 having an online marketplace configured for purchasing a booking through one or more computing devices.
  • the online marketplace can be a communication module stored on a computer readable medium and executed by a processor that transmits and receives information.
  • the online marketplace may be used by many different entities and/or users.
  • the term users may be interpreted and used interchangeably to describe restaurants, business entities, participants, guests, ticket sellers, ticket buyers, consumers and/or any other entity utilizing the system.
  • the online marketplace allows a booking of a capacity, including a reservation and/or a ticket.
  • the system allows business entities to decide whether they want to issue a reservation and/or issue a ticket as well.
  • the booking process may not require a reservation.
  • the users do not have to pay for a reservation and may provide a credit card number to hold their place at a restaurant and/or any other business entity.
  • a ticket requires payment.
  • Buying a ticket may include a reservation and/or personal user profile information. This may create a constant utilization, thereby allowing restaurants to be booked at their most efficient capacity, provide additional seating, and create higher revenue.
  • One particular type of user of the system 100 is a restaurant and/or any other business entity.
  • the online marketplace helps eliminating guest and/or users who create "no-shows."
  • the online marketplace may allow bookings to only become available after the user creates a saved account with payment data and/or user profile information.
  • the online marketplace may also control transparency for business entities. For example, the restaurant can decide where and how posts will be made official and available to the user.
  • the online marketplace may optimize processes for the restaurants and/or any other business entity.
  • the system allows for manual booking control by staff members. Additionally, staff members can post reservations and/or tickets.
  • the restaurant staff being responsible for and interacting with the reservation management system, can save many hours everyday using the online marketplace described herein.
  • the online marketplace allows for selling online reservations and/or tickets.
  • the restaurants and/or business entities may have a free choice regarding their position in the market, including: the ability to sell tickets, take reservations and walk-ins.
  • the online market-place allows for private dining sales. For example, restaurants working with bookings may use their private dining rooms for ticket sales.
  • the online marketplace may provide a group booking assistant. For example, reservations with more than six persons will be assisted by group booking functionality that can automatically guide a user through a larger group booking, such as prepared menu choices for the group, automatic payment instructions, etc.
  • the online marketplace may provide an automatic cancelation and/or transfer service.
  • the online marketplace may comprise a waitlist management system where canceled reservations may be automatically filtered and addressed to potential interested diners. Tickets can be transferred to other diners inside the software and/or application. Tickets that are "ready for transfer" may be booked by interested diners.
  • the online marketplace may provide a flexible system for different restaurant types. For example, every restaurant may establish different perspectives and styles, such as French fine dining, counter restaurants, bistro style. Every type of restaurant may use the online marketplace as a base for their reservation management. In some implementations, the online marketplace may not charge per cover fees for restaurants. The service may charge a booking fee per booking from the guest and outsources these costs for restaurant bookings or allows the restaurant to include the booking fee inside their account. When a user resells a ticket through the marketplace, the user may be refunded the cost of the ticket except for the booking fee.
  • the online marketplace may provide user analysis tools, such as tracking and tagging of the user for better knowledge of preferences and/or restrictions.
  • the online marketplace may provide integration of a restaurants widget for websites, social media platforms, mapping and navigation applications, service providers, and/or any other entity. In some implementations, only fine dining restaurants may obtain a position inside the marketplace.
  • the online marketplace may provide a marketing channel for restaurants utilizing any search engine technologies, and provide multiple restaurants inside one system and/or app.
  • the online marketplace may provide a social search engine with an update function. Locations based searching may provide a search for day and/or specific dates. The online marketplace may provide a search for a flexible time span during a day, and may save and/or update the search when for example, a subscription mode is activated. The online marketplace may provide dynamic subscriptions. For example, stream-lining subscriptions inside a newsfeed may help to manage the interest of a guest. Subscriptions may be location based on a particular day and/or time frame. Subscriptions may be location and/or date based for a period of time (e.g., Monday through Wednesday). Restaurants may see subscriptions inside their personal interest list.
  • the online marketplace may allow peer-to-peer ticket transfers. For example, purchased tickets may be transferred to other users inside the apps. Transferring a ticket may indicate a search technology for potential buyers of the tickets and send updates to stream-lined subscriptions. Saved payment data may help provide usability when guests want to pay for bookings. A user may allow checkouts with credit card and/or wallet solution.
  • the online marketplace may provide solutions to all users, including both restaurants and/or guests.
  • the online market place provides a system which can be barrier free and as well white-labeled (e.g., licensed and outsourced to Google Maps or the Michelin Guide). All restaurants may be integrated and users are kept motivated for booking using the system.
  • the system may provide the capability of using different languages and/or grant usability of the service.
  • the system may provide the capability of using of multiple-currencies for payments.
  • the online marketplace provides users a tool to save a lot of time. Ticket sales and peer-to- peer ticketing may be offered to all event organizers (e.g., food festivals, forum discussions, awards, workshops, etc.).
  • the online marketplace provides a flexible and expandable system.
  • system 100 may include one or more server(s) 102, 114.
  • the server(s) 102, 114 may be configured to communicate with one or more client computing platform(s) 128 according to a client/server architecture.
  • the users may access system 100 via client computing platform(s) 128.
  • server 102 may be associated with a restaurant or other venue that is offering a booking.
  • the server 114 may be associated with a booking host system, such as Fine Dining Experiences, which can provide the system functionality to the booking venues and the customers.
  • the client computing platform 128 can be a customer or patron that desires to purchase, sell, reserve, transfer, or search for a booking.
  • server(s) 102, 114 may be configured to execute one or more computer program modules.
  • the computer program modules may include one or more of a booking module 106, a user profile module 118, a ticket module 120, a payment module 122, and/or any other modules.
  • the booking module 106 may be configured to access and/or manage one or more bookings. Bookings may be made in numerous ways including through calling a business, emailing the business, and/or through software. The booking module 106 may manage any bookings comprising time, date, location, and service requested of a business.
  • the a user profile module 118 may be configured to access and/or manage one or more user profiles and/or user information associated with users of the system 100.
  • the one or more user profiles and/or user information may include information stored by server(s) 102, 114, one or more of the client computing platforms 128, and/or other storage locations.
  • the user profiles may include, for example, information identifying users (e.g., a username or handle, a number, an identifier, and/or other identifying information) within the virtual space, security login information (e.g., a login code or password), virtual space account information, subscription information, payment account information, relationship information (e.g., information related to relationships between users in the virtual space), usage information, demographic information associated with users, interaction history of the user with the system, information stated by users, purchase information of users, browsing history of users, a client computing platform identification associated with a user, a phone number associated with a user, and/or other information related to users.
  • security login information e.g., a login code or password
  • virtual space account information e.g., subscription information, payment account information
  • relationship information e.g., information related to relationships between users in the virtual space
  • usage information e.g., information related to relationships between users in the virtual space
  • usage information e.g., demographic information associated with users, interaction history of the user
  • a ticket module 120 may be configured to allow users to purchase tickets affiliated with the online marketplace system.
  • the user may be provided a list of available tickets based on bookings to select.
  • the booking may contain time, date, table, type of food, special requests and/or any other information.
  • the user may select a booking and purchase a ticket corresponding to the booking using a client computing platform(s) 128.
  • the client computing platform(s) 128 may comprise a mobile application and/or any other type of interface application.
  • the server(s) 102, 114 may use the ticket to search the point of sale system for the appropriate booking to display on the mobile application. Once a match is found, the ticket may be presented to the user on the mobile application for payment.
  • a payment module 122 may be configured to allow a user to make a payment directly through the client computing platform(s) 128.
  • the client computing platform(s) 128 may comprise a mobile application.
  • the mobile application may allow a user to make a payment in many different ways, including, virtual check, credit card, debit card, prepaid card and/or virtual currency.
  • user may have promotional credit in their accounts which they can user instead of paying with real currency.
  • the users may share this promotional credit with others, and/or just use it to pay for their own ticket.
  • the server(s) 102, 114, client computing platform(s) 128, and/or external resource(s) 130 may be operatively linked via one or more electronic communication links.
  • electronic communication links may be established, at least in part, via a network 126a, 126b such as the Internet and/or other networks. It will be appreciated that this is not intended to be limiting, and that the scope of this disclosure includes implementations in which server(s) 102, 114, client computing platform(s) 128, and/or external resource(s) 130 may be operatively linked via some other communication media.
  • the entity and host server(s) 102, 114 may comprise electronic storage 112, 124, one or more processors 104, 116, and/or other components.
  • the server(s) 102, 114 may include communication lines, or ports to enable the exchange of information with a network 126a, 126b and/or other computing platforms.
  • the processors 104, 116 may be configured to execute computer program modules.
  • the processors 104, 106 may be configured to execute the computer program modules via one or more of hardware, software, and/or firmware.
  • the computer program modules may include booking module 106, a user profile module 118, a link module 120, a bill splitting module 122, and/or any other computer program modules.
  • system 100 may be described in certain sections herein as including server(s) 102, 114, this is not intended to be limiting.
  • the server(s) 102, 114 may be separate and distinct from system 100, and may be provided by an entity that is separate from, for example, the entity providing system servers.
  • the functionality attributed herein to server(s) 102, 114 may be provided by system servers.
  • the server(s) 102, 114 may be incorporated on any point of sale and/or host system.
  • the host system includes a processor in communication with a memory storing data, which includes the order and the payment account data.
  • the host system can be an electronic cash register machine, which includes a credit card processing unit and cash storage.
  • the host system can include a means for wired or wireless communication over a network.
  • the means are in communication with the processor.
  • such means can be a dock, a port or an antenna.
  • the host system can be linked to a website capable of receiving orders or processing payment.
  • the host system can include a sensor for remote detection of the mobile device.
  • the processor can be a single core, dual core, a multi-core or a system-on-chip.
  • the memory can be random-access memory (RAM), virtual storage, real storage, cloud storage, flash memory or physical disk storage, such as an internal or external hard drive.
  • RAM random-access memory
  • virtual storage virtual storage
  • real storage real storage
  • cloud storage flash memory
  • physical disk storage such as an internal or external hard drive.
  • the data stored in the memory can be encrypted and stored in the memory in an encrypted state.
  • the data can be received in an encrypted state and then be decrypted, either on-the-fly or on-demand, and stored in a decrypted state in the memory.
  • a given client computing platform(s) 128 may include one or more processors configured to execute computer program modules.
  • the computer program modules may be configured to enable an expert or user associated with the given client computing platform(s) 128 to interface with system 100 and/or external resource(s) 130, and/or provide other functionality attributed herein to client computing platform(s) 128.
  • the given client computing platform(s) 128 may include one or more of a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a NetBook, a Smartphone, a gaming console, a mobile device and/or other computing platforms.
  • the mobile device may include a processor in communication with a memory, an input means, such as a keyboard, a touchscreen or a microphone, and an output means, such as a display or a speaker.
  • the mobile device can be a smartphone or a tablet computer.
  • the external resource(s) 130 may include sources of information, hosts and/or providers of virtual environments outside of system 100, external entities participating with system 100, and/or other resources. In some implementations, some or all of the functionality attributed herein to external resource(s) 130 may be provided by resources included in system 100. In some implementations, the point of sale and/or host system may be within external resource(s) 130. In some implementations, the host terminal may be located within server(s) 102, 114. A user may check-in by sending location information to a host system which includes a central processing unit (CPU) in communication with a memory and a display.
  • CPU central processing unit
  • the check-in can be wirelessly performed via direct communication with host system or via GPS, cellular network, Wi-Fi network, or a social networking service. The check-in can be performed via a wired technology as well. Upon successful check-in, the mobile device may appear as physically present in the business on the host system.
  • the server(s) 102, 114 may include electronic storage 112, 124, one or more processors 104, 116, and/or other components.
  • the server(s) 102, 114 may include communication lines, or ports to enable the exchange of information with a network 126a, 126b and/or other computing platforms. Illustration of server(s) 102, 114 in FIG. 1 is not intended to be limiting.
  • the server(s) 102, 114 may include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to server(s) 102, 114.
  • server(s) 102, 114 may be implemented by a cloud of computing platforms operating together as server(s) 102, 114.
  • Electronic storage 112, 124 may comprise electronic storage media that electronically stores information.
  • the electronic storage media of electronic storage 112, 124 may include one or both of system storage that is provided integrally (i.e., substantially non-removable) with server(s) 102, 114 and/or removable storage that is removably connectable to server(s) 102, 114 via, for example, a port (e.g., a USB port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.).
  • a port e.g., a USB port, a firewire port, etc.
  • a drive e.g., a disk drive, etc.
  • Electronic storage 112, 124 may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.), and/or other electronically readable storage media.
  • the electronic storage 112, 124 may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources).
  • Electronic storage 112, 124 may store software algorithms, information determined by processor(s) 104, 116, information received from server(s) 102, 114, information received from client computing platform(s) 128, and/or other information that enables server(s) 102, 114 to function as described herein.
  • Processor(s) 104, 116 is configured to provide information processing capabilities in server(s) 102, 114.
  • processor processor(s) 104, 116 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information.
  • processor(s) 104, 116 is shown in FIG. 1 as a single entity, this is for illustrative purposes only.
  • processor(s) 104, 116 may include a plurality of processing units. These processing units may be physically located within the same device, or processor(s) 104, 116 may represent processing functionality of a plurality of devices operating in coordination.
  • the processor(s) 104, 116 may be configured to execute modules 106, 118, 120, 122, and/or any other modules.
  • Processor(s) 104, 116 may be configured to execute modules 106, 118, 120, 122, and/or any other modules by software; hardware; firmware; some combination of software, hardware, and/or firmware; and/or other mechanisms for configuring processing capabilities on processor(s) 104, 116.
  • modules 106, 118, 120, 122, and/or any other modules are illustrated in FIG. 1 as being co-located within a single processing unit, in implementations in which processor(s) 104, 116 includes multiple processing units, one or more of modules 106, 118, 120, 122, and/or any other modules may be located remotely from the other modules.
  • the description of the functionality provided by the different modules 106, 118, 120, 122, and/or any other modules described below is for illustrative purposes, and is not intended to be limiting, as any of modules 106, 118, 120, 122, and/or any other modules may provide more or less functionality than is described.
  • modules 106, 118, 120, 122, and/or any other modules may be eliminated, and some or all of its functionality may be provided by other ones of modules 106, 118, 120, 122, and/or any other modules.
  • processor(s) 104, 116 may be configured to execute one or more additional modules that may perform some or all of the functionality attributed below to one of modules 106, 118, 120, 122, and/or any other modules.
  • FIG. 2 illustrates method 200 of creating a booking through a computing device according to the present disclosure.
  • This embodiment may incorporate any aspects of other implementations as described in the disclosure.
  • the operations of method 200 presented below are intended to be illustrative. In some embodiments, method 200 may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Some elements of this figure are described above. Thus, any repetitive detailed description thereof will hereinafter be omitted or simplified in order to avoid complication. Additionally, the order in which the operations of method 200 are illustrated in FIG. 2 and described below is not intended to be limiting.
  • method 200 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information).
  • the one or more processing devices may include one or more devices executing some or all of the operations of method 200 in response to instructions stored electronically on an electronic storage medium.
  • the one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method 200.
  • the host server(s) 114 may store in a ticket database, information related to a plurality of restaurants and/or business entities comprising tickets corresponding to bookings at restaurants and/or business entities, the bookings containing time and date information, the tickets containing an available status and/or an unavailable status.
  • the booking may include a table identification (ID) and/or any other ID.
  • the booking may comprising a table selection indicating a table identification (ID) and a time and date of dining and selection of a service (e.g., pre- ordering a type of food).
  • the table selection may be based on displaying, by the server, a list of tables present in the business establishment to the first user and allowing the first user to select a particular table.
  • the table ID may be based on a previous table selection made by the user when creating the booking.
  • the server may query the point of sale system for a list of tables present in the restaurant's database. The tables are presented to the user, who can then select which table they want to reserve.
  • the table may be preselected for the user by the wait staff.
  • the data to be queried may be stored in a database on the client electronic storage and/or the host electronic storage and/or any other storage location.
  • the host server(s) 114 may receive a location of a first user from the first user computing device.
  • the first user computing device and/or second user may be a client computing platform(s) 128.
  • determining the location of the first user may be based on a global positioning system.
  • the approximate location of the computing device may be determined via data from the GPS receiver embedded in the client computing platform(s) 128 and/or data from the cell antenna tower (or towers) via which the computing device is communicating when ordering the ticket (e.g., within 150-50 meters, or less). For example, triangulation from multiple towers can provide fairly precise location data.
  • the system may receive a GPS reading (e.g., from a user terminal, such as a computer or cell phone equipped with a GPS receiver) and cell phone location information for a user.
  • a GPS reading e.g., from a user terminal, such as a computer or cell phone equipped with a GPS receiver
  • the system may receive a GPS reading and an IP address associated with a user terminal, and use both types of information to verify the user's location.
  • the location may be based on user input.
  • the system can transmit a notification to the user indicating that the system has not been able to verify the user's location. Similarly, the system may ask the user to input a location.
  • the host server(s) 114 may search in the ticket database for tickets with an available status corresponding to the bookings at restaurants and/or business entities in the vicinity of the location.
  • tickets are ubiquitous. Some form of a ticket, for example, is often required to view or attend an event, such as a sporting event, a theatrical production, a conference, a wine tasting, and the like. Tickets may also commonly be used as a booking mechanism, e.g., to secure a place on a flight, a cruise, a bus, and the like.
  • the host server(s) 114 may display on the first user computing device, the tickets with the available status.
  • the tickets may be displayed in any form (e.g., special color and/or icon indicating an available status).
  • the host server(s) 114 may receive a request from the first user computing device to purchase a ticket with an available status, the ticket corresponding to a booking at a restaurant and/or any other business entity.
  • the ticket may contain time and date information and/or any other pertinent information related to the booking.
  • the request may be for a threshold period of time and/or during a time span. For example, a user may make a request for a booking by conducting location based searching. This may provide a search for day and/or specific dates.
  • the online marketplace may provide a search for a flexible time span during a day, and may save and/or update the search when for example, a subscription mode is activated.
  • the online marketplace may provide dynamic subscriptions.
  • stream-lining subscriptions inside a newsfeed may help to manage the interest of a guest.
  • Subscriptions may be location based on a particular day and/or time frame. Subscriptions may be location and/or date based for a period of time (e.g., Monday through Wednesday).
  • Other pertinent information may comprise: business entity name, the city of location of the business entity, a particular code referencing the booking, the number items reserved, the types of items reserved, and/or information relating to the upgrade policy.
  • the host server(s) 114 may associate the ticket with the first user in the ticket database and changing the status of the ticket to unavailable.
  • the host server(s) 114 may transmit to the first user computing device, the ticket to the first user.
  • the ticket module 120 may generate a ticket comprising the booking information.
  • the ticket may be purchased with the user's payment account data using the payment module 122.
  • the payment account data can be stored before the user checked-in, such as where user has a preexisting account in host system, or the payment account data can be stored after the check-in.
  • the payment account data may be data that allows a vendor, such the restaurant, the bar, and/or any other business establishment, to place a charge onto an account associated with a domestic or a foreign financial institution.
  • the account information may be accessed by the user profile module 118. Although typically, the account will be the account of the user of the mobile device, other accounts can be used as well. For example, a user of the mobile device may provide information of the account associated with the user's parent, a spouse, a child or a friend.
  • the payment account data can be credit card information, such as a credit card account number, a name associated with the credit card account, an expiration data and a security code.
  • the payment account data can be debit card information, such as a debit card account number, a name associated with the debit card account and a personal identification number (PIN).
  • the payment account data can be a gift card account data, such as a gift card number and a PIN.
  • the payment data can be real or virtual currency or rewards points.
  • the payment account data can be financial institution website login data or data stored on a website, such as a payment account data aggregator. In some implementations, the user may pay through a checking/savings account, debit card, credit card, and/or pre-paid card.
  • the user logs onto such website and manually inputs or imports the payment account data from the website into the software application.
  • the software application is programmed to automatically login into the website, access the payment account data and either communicate the payment account data to the host system without permanently locally storing the payment account data or import the payment account data information into the software application and then transmit the payment account data to the host system.
  • the payment account data can be stored in or accessible via the memory of the client computing platform(s) 128.
  • the user manually inputs the payment account data into a software application running on the mobile device. The user can manually input the data before or after entry into the restaurant or the bar.
  • the payment account data is stored in a NFC chip in communication with the mobile device, which includes the NFC chip.
  • a software application running on the mobile device accesses the payment account data stored on the NFC chip.
  • the software application accesses the payment account data from a payment account data aggregator.
  • the payment account data can be stored in another mobile device and the mobile device accesses another mobile device to retrieve/import the payment account data onto the mobile device.
  • the payment account data can be stored remotely for remote access, such as via a website or web accessible service.
  • the software application Upon access of the payment account data, the software application, directly or indirectly, communicates with the host system via the wireless or the wired means. If the software application is capable of directly communicating with the host system, then if the mobile device is present within a detection range of the host system, then the mobile device or the host system, either manually or automatically, detects the location/presence of the host system or the mobile device, respectively. If the software application is capable of indirect communication with the host system, such as over the Internet or cellular networks, then, upon the user's action, such as logging into a website or a service associated with the host system, the host system detects the presence of the mobile device.
  • the software application can be generic or specific to the restaurant, the bar and/or business entity.
  • the software application can be a mobile application.
  • the restaurant has a software application specific to its host system.
  • the user downloads and installs a specific software application for that host system.
  • the specific software application requires a creation of an account, which requires entry of the payment account data.
  • the payment account data can be manually entered, imported from an NFC chip or the memory or accessed via the Internet.
  • the user Upon creation of the account and visiting of the restaurant, irrespective of the placement of the order, the user runs the specific software application, which communicates with the host and allows for display of information indicating the presence of the user.
  • the host server(s) 114 may change the status of the ticket in the ticket database to an unavailable status.
  • the ticket database may be stored in the host electronic storage 124 and/or the entity electronic storage 112.
  • the tickets may be displayed in any form (e.g., special color and/or icon indicating an unavailable status).
  • the host server(s) 114 may receive from the first user computing device, a cancelation request for the ticket.
  • the first user computing device may be any client computing platform 128.
  • the host server(s) 114 receives a request to change the status of the ticket from unavailable to available in the ticket database.
  • the host server(s) 114 may store, the canceled ticket, and/or the ticket with the updated status in the ticket database.
  • the host server(s) 114 may resell the ticket to a second user computing device.
  • the host server(s) 114 receives a request from a second user computing device to purchase the ticket.
  • the host server(s) 114 associates the ticket with the second user in the ticket database and changing the status of the ticket to unavailable.
  • the system may use push notifications to facilitate the resale of tickets. More specifically, the system may utilize push notifications to quickly communicate the availability of one or more tickets to potential buyers. When tickets become available for resale, the ticket reselling system may generate data to send a push notification, on a central server.
  • the system may quickly display the data to an interested buyer, thereby facilitating the quick and efficient resale of the tickets.
  • the system may quickly display a push notification to one or more ticket holders or a vendor that may have tickets for resale.
  • the host server(s) 114 may send push notifications to a plurality of users containing information related to tickets with an available status.
  • the push notifications may consist of sending incentives comprising: points, coupons, and virtual currency.
  • the push notifications may be sent based on targeting users based on their user profile.
  • Push notifications may use a constantly- open IP connection to provide notifications from servers (e.g., notifications related to third party web applications or browser extensions) to client computing devices (e.g., smart phones used by users who have installed the web applications or browser extensions).
  • the notifications may include sounds, images, or custom text alerts, for example.
  • an active notification may include a feature to immediately alert a user, such as a sound alert, a desktop alert, a pop-up window, or animation.
  • Passive notifications in contrast, may operate in a background of a web browser for example.
  • a passive notification may include an indicator or information shown in a web browser, such as near a web application icon in the browser.
  • the first user may resell the ticket to the second user and receive a commission.
  • the first user may send a notification to the second user through using any form of communication, including email, push notification, MMS, SMS, phone call, and/or any other method.
  • the system may resell the ticket to the second user and the first user pays a commission.
  • the commission may be calculated based on a percentage of the ticket.
  • the commission may be variable. For example, the commission may be a higher fee and/or percentage the closer to the event time. In some implementations, the commission may be a fixed fee.
  • the host server(s) 114 may credit at least a portion of the payment from the first user for the ticket to the first user computing device.
  • the payment may be based on the commission and/or any other fees charged to use the system.
  • the credit may issue a direct refund to the first user's payment method.
  • the credit may be in the form of virtual currency and/or points affiliated with the first user's account and/or any other form of credit.
  • FIGS. 3A-3G illustrates a user interface 300 for purchasing a booking through a computing device according to the present disclosure.
  • This embodiment may incorporate any aspects of other implementations as described in the disclosure.
  • the operations of method 300 presented below are intended to be illustrative. In some embodiments, method 300 may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Some elements of this figure are described above. Thus, any repetitive detailed description thereof will hereinafter be omitted or simplified in order to avoid complication. Additionally, the order in which the operations of method 300 are illustrated in FIGS. 3A-3G and described below is not intended to be limiting.
  • user interface 300 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information).
  • the one or more processing devices may include one or more devices executing some or all of the operations of user interface 300 in response to instructions stored electronically on an electronic storage medium.
  • the one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of user interface 300.
  • the client computing device that displays the user interface may be a smart phone, mobile phone, personal data assistant, tablet computer, laptop computer, personal computer, or the like.
  • FIG. 3A illustrates a user interface 300A for purchasing a booking through a computing device according to the present disclosure.
  • the user is a traveler in Lima, Peru, and has experienced the city a whole day. It is 4:30 pm, and the traveler and the accompaniment are sitting in a cafe, thinking about where to dine that evening.
  • the user has heard of some really great restaurants, however, all of these restaurants are fully booked.
  • the user does not have any idea how to get a reservation.
  • the user may check their mobile phones and look for some interesting restaurants around them, however, without knowing the name of the restaurant, it would not be possible to find out if there is a table available.
  • the best and most interesting restaurants may not use online mobile apps for last minute bookings.
  • the user can search for a restaurant and/or business entity 302.
  • Field 302 allows the user to enter the name of a restaurant, bar, or other entity name.
  • the user interface contacts the host system and retrieves the request restaurant profile and provides every open table or other information requested by the user.
  • the user may choose a location-based search.
  • the location may be automatically detected by the system and/or the location may be input by the user.
  • the location may be automatically determined by any type of global positioning system (GPS) and/or any other method (i.e., cell ID, Wi-Fi, Bluetooth, inertial sensors, barometers, radio-frequency identification (RFID), near-field communication (NFC), and/or terrestrial transmitters) of determining a location from a client computing device.
  • GPS global positioning system
  • RFID radio-frequency identification
  • NFC near-field communication
  • the user may choose a destination based search.
  • the user may be able to search for restaurant near the user and/or search for restaurants at a special location, for a specific time span.
  • the system may be linked to the user's calendar, and recognize where the user will be in the future to conduct a search and/or recommendation.
  • the search may be based on dates selected for the future by the user.
  • the user may enter information such as: number of diners, a time span for the dinner, star rating of the restaurant, type of cuisine, and/or any other information related to allowing a user to choose a restaurant and/or business entity.
  • the user may search for a specific location, city, worldwide, or a location situated "near me" as well as a time within a particular timeframe (e.g., minutes, hours, days, weeks), such as by using a same day search 304 and/or a flexible days search 306.
  • the same day may comprise a timeframe in that one particular day. If no table is available that day, a user may make a request using a timeframe for that one day. The timeframe provides more flexibility for the user to obtain the table. The user may obtain a booking anywhere within that timeframe.
  • the same day search is flexible for any time the user is given within that timeframe. The flexible search may provide additional options.
  • a user may inquire to know when there is a table available in Lima during the entire week.
  • the user may receive subscription updates from the business entity (e.g., restaurant) for that week when a table is available.
  • the flexible days search creates a timeframe which can be a span of hours, days, weeks, or months.
  • the user may set a timeframe for either a particular restaurant and/or business entity in a city and/or region.
  • the same day search and the flexible days search provide the user a benefit of creating a higher probability of the user obtaining a booking and remind the user of restaurants offering additional tables the user is interested in.
  • the user may be able to search for business entities based on any particular rating the business entity has received (e.g., star rating, Michelin Guide, The Good Food Guide, Gault Millau, Forbes Travel Guide, Zagat, Yelp, etc.) Users may additionally have the ability to rate the business entities and provide their ratings to other users.
  • any particular rating the business entity has received e.g., star rating, Michelin Guide, The Good Food Guide, Gault Millau, Forbes Travel Guide, Zagat, Yelp, etc.
  • Users may additionally have the ability to rate the business entities and provide their ratings to other users.
  • the user may access user profile information 308.
  • the user may further receive push notifications 309 for released tables their favorite restaurants, for the days the user is interested to dine at the restaurant based on their user profile information.
  • the user may further save their exclusive seats online and book tables easily while they are traveling.
  • the user may experience increased flexibility and host previously purchased tickets for resale with the app.
  • the user may choose to transfer booked tickets (e.g., at face value only) and/or the system may anonymously find the a match for the user and manage the resale of the tickets, including a refund for the reseller, without a need to create a chargeback on the credit card.
  • the system may receive a commission for selling reservations and tickets as well as transferring tickets.
  • the system may charge a fee for each booking and/or booking seat which are included in the tickets and/or added to your shopping bag.
  • the system may send direct updates to their guests and offer them demanded tables.
  • the system may further utilize restaurants much more efficiently.
  • the user may additionally receive incentives. For example, the users may obtain tables spontaneous and last minute in the best restaurants all around the world. The guest may further resell their booked tickets directly with the app.
  • FIG. 3B illustrates a user interface 300B for creating a booking through a computing device according to the present disclosure.
  • the user may choose to subscribe for a time span 310 (also referred to herein as a timeframe, time slot, and span of time) and/or request a table 312 for a particular day.
  • a subscription may be an inquiry for a span of time greater than a single reservation and may last a few hours, days, weeks, or longer. For example, the user may subscribe for an entire day, a week, two weeks, and/or a month. This provides the user a greater probability of acquiring a table at a particular restaurant.
  • the user can choose a table for 2 people within a time slot of the whole day.
  • the subscription allows the user to obtain a booking at any available time within the desired timeframe.
  • a user may receive an immediate response to obtaining a booking through a subscription request (available, unavailable, check back at a later time, etc.)
  • the business entity may reply to the user at a later time (e.g., when a time slot becomes available).
  • the business entity may contact the user using any form of communication (e.g., phone call, email, SMS message, MMS message, etc.)
  • a request is an inquiry for a table on a particular day during a span of a few hours.
  • the user may request a particular time and/or a timeframe.
  • the user may additionally request a particular number of persons.
  • a user may receive an immediate response to obtaining a booking through an inquiry request (e.g., available, unavailable, check back at a later time, etc.)
  • the business entity may reply to the user at a later time (e.g., when a time slot becomes available).
  • the business entity may contact the user using any form of communication (e.g., phone call, email, SMS message, MMS message, etc.) [00109] FIG.
  • 3C illustrates a user interface 300C for creating a booking through a computing device according to the present disclosure.
  • the user may be able view inquiries (i.e., requests and subscriptions) already created and for use during the near future by the user.
  • the user may be able to access tickets and/or reservations already created by the user for use at a future date.
  • the user may view tickets available based on their search.
  • the user may view different booking options provided.
  • the user can view available seats and/or requests 314 and subscriptions 316. All requests and subscription are sent to the restaurant and/or the business entity.
  • a request may be a specific date and/or timeframe at a restaurant and/or business entity.
  • a subscription may be for a longer period of time (e.g., 3 days, a week, a month).
  • the user can see the status of different requests and/or subscriptions. For example, if the status is open, the user may view the inquiry, but might not yet be able to obtain a ticket and/or reservation.
  • the business entity may not accept reservations during a threshold period of time (e.g., more than six months in advance).
  • the user can then use the system to make a booking.
  • the user may select the available timeframe, view a seating chart to select seats, food, and/or any beverage to consume during the booking.
  • the user may submit any notes to the business entity.
  • the notes may comprise any special requests (e.g., requesting special consideration for celebrating a life event) and/or any special needs (e.g., requiring any assistance for a handicap).
  • reminders may be sent to the user.
  • the reminders may be pre- configured by the user and/or business entity.
  • the reminders may request the user to confirm the booking.
  • FIG. 3D illustrates a user interface 300D for creating a booking through a computing device according to the present disclosure.
  • the bookings may have different statuses (e.g., transferred, in transfer) that may be presented to the user.
  • the user may be able to transfer their booking to other users and/or receive bookings transferred to them.
  • the status may be displayed as transferred 318.
  • the user interface shows that a booking has been transferred from a first user to a second user and/or any other user.
  • the status may be displayed as in transfer 320.
  • the user interface shows that a booking transfer is pending from a first user to a second user.
  • users may receive requests for transfer from a first and/or second user.
  • the status may be displayed as transfer request.
  • the first user may receive a request from a second user to transfer their booking.
  • the first user may choose whether they prefer to keep their booking and/or transfer the booking to the second user.
  • FIG. 3E illustrates a user interface 300E for creating a booking through a computing device according to the present disclosure.
  • the user may be able to view details of restaurant and/or business entity 322.
  • the user may be able to view available seats, request a table, subscribe for a time span, make a call to the restaurant, view walk -in availability, and view opening hours of the restaurant.
  • the user may be provided additional information including the types of food, pictures of the food, special events, name of the chef, any food specials for the particular time frame, and/or any other information.
  • FIG. 3F illustrates a user interface 300F for purchasing a booking through a computing device according to the present disclosure.
  • the user may be able to select a payment mechanism 324 to pay for the tickets.
  • Some methods of payment may be through a checking account, savings account, credit card, debit card, pre-paid card, stored value card, gift card, virtual currency, virtual points, and/or any other payment mechanism.
  • more than one means of payment may be selected.
  • payment information may be stored in the user account and/or user profile. Payment authorization and settlement is described in further detail below with respect to FIG. 6.
  • FIG. 3G illustrates a user interface 300G for purchasing a booking through a computing device according to the present disclosure.
  • a user may create a user profile which may include the user's photo 326, the user's name 328, and/or the any information unique to the user 330. This information may provide the business entity and/or restaurant background information on the user so they may provide extra services and/or customize the experience to the user based on their profile.
  • the user profile may indicate food allergies, birthday information, food and/or wine preferences, frequency of visits to the business entity and/or restaurant, member status, and/or any other information which may make the user's experience more pleasurable.
  • the restaurant server may request this information from the host server upon establishing a booking with the user so that the booking of the user reflects the user's preferences.
  • FIG. 4 illustrates method 400 of selling a booking through a computing device according to the present disclosure.
  • This embodiment may incorporate any aspects of other implementations as described in the disclosure.
  • the operations of method 400 presented below are intended to be illustrative. In some embodiments, method 400 may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Some elements of this figure are described above. Thus, any repetitive detailed description thereof will hereinafter be omitted or simplified in order to avoid complication. Additionally, the order in which the operations of method 400 are illustrated in FIG. 4 and described below is not intended to be limiting.
  • method 400 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information).
  • the one or more processing devices may include one or more devices executing some or all of the operations of method 400 in response to instructions stored electronically on an electronic storage medium.
  • the one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method 400.
  • information related to tickets corresponding to events at a business may be stored in a ticket database by the host server(s) 114 in the ticket database.
  • Profile information for users that have purchased ticket may also be stored in a customer database.
  • the customer and/or ticket databases may be in the client electronic storage and/or the host electronic storage.
  • the business may be one or more of: a restaurant, a tour guide, a bowling alley, a movie theater, a hotel, a rail-line, and/or an airline.
  • tickets with the available status during a predetermined period of time may be searched in the ticket database.
  • the predetermined period of time maybe input by the user (e.g., search during a particular time and/or date).
  • the system may determine the predetermined period of time.
  • a list of tickets with the available status and tickets with the unavailable status may be received by the host server(s) 114 from the entity server(s) 102.
  • available and/or unavailable tickets may be displayed.
  • the available tickets may have a particular indicator (e.g., particular color, icon, etc.) which may be different than the unavailable tickets.
  • ticket cancelations during the predetermined period of time may be determined.
  • the restaurant and/or business entity may set a particular time when tickets which are canceled may not be sold for reimbursement.
  • the predetermined period of time may set individually for each restaurant and/or business entity.
  • the restaurant and/or business entity may make the predetermined period of time the same and/or different based on the user's profile information. For example, if a user is a valued customer, the restaurant and/or business entity may choose not to set a predetermined period of time for cancelations and allow the user to cancel and resell at any time.
  • a predetermined period of cancelation may be set.
  • profile information and/or location information for users that did not purchase tickets during the predetermined period of time may be searched in the customer database by the host server(s) 114.
  • the profile information may provide valuable marketing information to the restaurant and/or business entity.
  • the profile information may determine which users prefer the specific type of food offered by the restaurant and/or which users may be on the wait list for the restaurant and/or business entity.
  • the location information may indicate whether the user is in town during the time of the booking.
  • tickets with the available status and sending notifications to the users that did not purchase tickets during the predetermined period of time regarding the tickets with the available status during the predetermined period of time may be posted by the host server(s) 114 to a client computing platform(s) 128.
  • the notifications may be push notifications, MMS, SMS, e-email, phone call, and/or any other type of notification.
  • the system may determine the location of the users and send push notifications to a plurality of users which contain information related to tickets with an available status when the users are within a proximate vicinity of the business during the predetermined period of time.
  • push notifications may consist of sending incentives comprising: points, coupons, bitcoins and/or virtual currency.
  • the users may be able to pay for the services related to the tickets using points, coupons, virtual currency, bitcoins, and/or payment using real currency.
  • push notifications may be sent based on targeting users based on their user profile. For example, users with a particular preference for a type of food and/or dish.
  • a request from a first user to purchase a ticket with an available status may be received by the host server(s) 114.
  • the request to purchase the ticket may comprise: the price of the tickets, an additional booking fee and/or a commission percentage.
  • the cost of the ticket may be determined by the host server(s) 114. In some implementations, the cost may be based on the time the ticket was purchased or the type of user which purchased the ticket. In some implementations, time based purchases may comprise: early bird, last minute, and/or number of tickets purchased during a time period. In some implementations, the type of user may comprise: concierges, VIPs (e.g., those receiving special treatment due to a formal or informal status at the establishment), subscribers, foodies, business travelers, culinary professionals, and/or journalists.
  • VIPs e.g., those receiving special treatment due to a formal or informal status at the establishment
  • the ticket may be provided to the first user upon receiving payment for the ticket based on the cost of the ticket by the host server(s) 114.
  • the ticket may be provided through email, SMS messaging, MMS messaging, QR code, physical tickets may be mailed, and/or by any other means of providing tickets.
  • the status of the ticket may be changed in the ticket database to an unavailable status by the host server(s) 114.
  • the host server(s) 114 may associate the ticket with the first user in the ticket database and change the status of the ticket to unavailable.
  • the available tickets may have a particular indicator (e.g., particular color, icon, etc.) which may be different than the unavailable tickets.
  • modules or components can perform one or multiple functions.
  • Each module or component can be executed by a computer, such as a server, having a non-transitory computer-readable medium and processor.
  • a computer such as a server, having a non-transitory computer-readable medium and processor.
  • multiple computers may be necessary to implement the functionality of one module or component.
  • FIGS. 5A-5E illustrates a user interface 500 for selling a booking through a computing device according to the present disclosure. This embodiment may incorporate any aspects of other implementations as described in the disclosure.
  • the user interface 500 presented below is intended to be illustrative.
  • user interface 500 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information).
  • the one or more processing devices may include one or more devices executing some or all of the operations of user interface 500 in response to instructions stored electronically on an electronic storage medium.
  • the one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of user interface 500.
  • FIG. 5A illustrates a user interface 500A for selling a booking through a computing device according to the present disclosure.
  • the interface may provide information to the restaurant and/or business entity through different tabs which may include an interest list, may allow the entity to post a table, look at events, post events, and/or manage bookings.
  • the interface in the interest list tab may present a list of diners, who subscribed and are interested to dine in the restaurant 502.
  • the user interface may also display information collected from the location and destination based on the search 504.
  • the user interface may additionally display information collected from user profiles 506, for example, diners celebrating a special occasion.
  • the information provided in the user interface 500 allows the system to strategically market by send push notifications and/or contact users using any other method.
  • restaurant and/or business entity may order a detailed report with analysis of first region, interested diners, location and/or destination based searches for every month.
  • Information related to activities in the region of the restaurant and/or business entity may also be displayed (e.g., fairs, festivals, holidays, business people coming to town, season based analysis, and/or any other information).
  • the report may be sent to a particular user via email, MMS, SMS, and/or the report may be printed.
  • the user interface may additionally provide a means to post a table.
  • FIG. 5B illustrates a user interface 500 for selling a booking through a computing device according to the present disclosure.
  • the user interface may allow the business entity options to manage the restaurant profile 512.
  • the restaurant profile may include different information to provide the users (e.g., type of food, name of chef, specialties during a particular time frame, and/or any promotions).
  • the user interface may allow the restaurant to upload pictures 514.
  • the pictures may include types of food served by the restaurant, pictures of guests and/or pictures of the restaurant and/or business entity. Other options such as general settings, manual, sign out, and information about the service may additionally be provided.
  • FIG. 5C illustrates a user interface 500C for selling a booking through a computing device according to the present disclosure.
  • the user interface may provide functionality for managing a booking list, including bookings, published offers, and bookings in transfer. Upon selection of any booking on the user interface, the user may see additional details on that particular booking or availability at that time.
  • the user interface may set up notifications by posting streams. The system may allow a user (e.g., restaurant manager) to choose which guest on the interest list they want to send notifications.
  • the user interface may provide the restaurant with all booking information 516.
  • the user interface 500C may also show the booking list for a future time. This may provide additional options and allow the user better management capabilities.
  • the user interface may provide a method of allowing the user to alter the settings for the seating plan.
  • the seating plan may allow a user to choose the number of diners and/or receive price updates from the restaurant and/or business entity.
  • the seating plan may be connected to the cashier and/or point of sale system of the restaurant and/or business entity.
  • the system may allow a restaurant and/or business entity to determine the number of courses they want to sell and provide recommended prices for the tickets based on supply and demand.
  • FIG. 5D illustrates a user interface 500D for selling a booking (e.g., posting a ticket) through a computing device according to the present disclosure.
  • user interface may allow for selling tickets 518, viewing sold tickets, and/or checking for available and/or unavailable tickets.
  • the system may allow the restaurants to create templates in how to provide information 520.
  • the user interface may allow the system to sync the application with other booking and/or booking systems (e.g., Open Table, Seatme, Livebookings, etc.).
  • FIG. 5E illustrates a user interface 500E for selling a booking through a computing device according to the present disclosure.
  • the ticket may contain the user and/or guest name 524, the name of the restaurant and/or business entity 522, and/or a code 526 (e.g., QR code, barcode, alpha/numeric code, etc.) containing the ticket information.
  • Ticket information may include the time, date, area, number of diners, and/or any guest notes. Ticket information may be pulled from user profile information.
  • the restaurant and guest may view different ticket information for the same bookings. For example, the restaurant may be able to view additional user profile information on the ticket so that they may provide better customer service during the user's dining experience.
  • FIG. 6 is a diagram for booking processes, including payment and peer-to-peer transfer, through a network environment 600, according to an exemplary embodiment as described in FIGS. 1 and 4.
  • the system may allow the user to request a table. For example, in 601, if a first user wants to book a table at a restaurant, the user uses a client computing device to send a request over a network to the host server.
  • the host server may then deliver the request to a booking module of a server of a restaurant.
  • the restaurant server may identify and propose booking options including a reservation and/or a pre-paid ticket to the host server.
  • the host server may transmit the offers to the client computing device of first user via push-notification (e.g., dashboard message with a status of offer available).
  • a second user uses a client computing device to create a subscription for the restaurant and sends the subscription request from the client computing device of the second user to the host server.
  • the host server may create the subscription at the restaurant (e.g., by generating and storing a record for the subscription).
  • the host server may then store the subscription for the second user.
  • the client computing device of the second user is able to receive booking options for the subscribed timeframe.
  • a first user books a ticket.
  • the first user uses the client computing device to pay for the ticket and manages the payment process by a credit card.
  • the clearing company server may receive the payment data and clear the payment data.
  • the clearing company server may create a virtual and/or e-wallet record or account for the first user and store the payment information.
  • the clearing company server may transfer the payment amount to the host escrow wallet.
  • the escrow wallet may keep the booking fee and create a cash-out.
  • the host server may then transfer payment for the ticket from the escrow wallet to the restaurant e-wallet.
  • the restaurant e-wallet may create a cash-out to their bank account.
  • the client computing device of the first user may receive a report and status update from the host server that confirms the booking.
  • the host server may transmit a status update the restaurant server.
  • the host server may send a status update to the client computing device of the first user.
  • a first user may book a reservation.
  • the first user's client computing device may be used to pay for a reservation and manage the payment process by credit card and/or any other method of payment.
  • the clearing company server may verify the received payment data.
  • the clearing company server may create a virtual e-wallet record or account for the first user and store the payment information.
  • the clearing company server may transfer the booking fees to the host escrow wallet on the host server.
  • the host server can create a cash-out for the escrow wallet.
  • a report and status update are sent to the host server that the first user has confirmed a booking.
  • the host server may create a report and status update that confirms the booking.
  • the host server may transmit the status to the client computing device of the first user and the restaurant server.
  • the first user may transfer a ticket.
  • the first user may use the client computing device to change the status of a ticket inside its booking list to cancel and transfer.
  • the client computing device may transmit a status report to the host server as "in transfer.”
  • the restaurant server may receive the change of the ticket status and become informed of the transfer process.
  • the host ticket module of the host server may receive a change of status and automatically activate the search engine for a matching inquiry.
  • a second user may be matched through a search and receive a transmission of a new ticket offer from the host ticket module.
  • the first user cancels a reservation.
  • the first user may use the client computing device to change the status of a reservation inside its booking list to "cancel and transfer.”
  • the client computing device transmits a status report to the host server so that the user profile may show "in transfer.”
  • the restaurant server may receive a change of the ticket status and is informed about the cancelation.
  • the host ticket module of the host server receives a change of status and automatically activates the search engine for a matching inquiry.
  • the second user may be matched to the search and receive a new reservation offer from the host ticket module.
  • the restaurant may have other potential guests for the booking and may manually or automatically delete the offer of the first user.
  • a second user may book a transferred ticket.
  • the second user may use the client computing device to pay for a ticket and manage the payment process by a credit card and/or any other form of payment.
  • a clearing company server may clear the received payment data.
  • the clearing company server may create a virtual e-wallet record or account for the second user and store the payment information.
  • the clearing company server may transfer the payment amount to the host escrow wallet.
  • the escrow wallet may keep the booking fee and the host server can create a cash-out.
  • the host server may transfer a refund for the ticket from the escrow wallet to the first user's e-wallet.
  • the host serve r may create a report and transmit an update to the first user client computing device with a "refund successful" status.
  • the host server reports a status update to the first user client computing device with a "transferred' status.
  • the first user client computing device is able to crate a cash-out for the refund.
  • status updates of a successfully transferred ticket are transmitted to the host.
  • the host server may inform the restaurant server of the second user being the new ticket holder.
  • the host server may additionally inform the second user about the purchased ticket and successful payment.
  • the second user may receive a report and status update from the host which confirms the booking.
  • the host may update the restaurant.
  • the exemplary embodiments can relate to an apparatus for performing one or more of the functions described herein.
  • This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer.
  • a computer program may be stored in a machine (e.g.
  • ROMs read only memories
  • RAMs random access memories
  • EPROMs erasable programmable ROMs
  • EEPROMs electrically erasable programmable ROMs
  • magnetic or optical cards or any type of media suitable for storing electronic instructions, and each coupled to a bus.
  • the exemplary embodiments described herein are described as software executed on at least one server, though it is understood that embodiments can be configured in other ways and retain functionality.
  • the embodiments can be implemented on known devices such as a personal computer, a special purpose computer, cellular telephone, personal digital assistant ("PDA"), a digital camera, a digital tablet, an electronic gaming system, a programmed microprocessor or microcontroller and peripheral integrated circuit element(s), and ASIC or other integrated circuit, a digital signal processor, a hard-wired electronic or logic circuit such as a discrete element circuit, a programmable logic device such as a PLD, PLA, FPGA, PAL, or the like.
  • any device capable of implementing the processes described herein can be used to implement the systems and techniques according to this invention.
  • the various components of the technology can be located at distant portions of a distributed network and/or the Internet, or within a dedicated secure, unsecured and/or encrypted system.
  • the components of the system can be combined into one or more devices or co-located on a particular node of a distributed network, such as a telecommunications network.
  • the components of the system can be arranged at any location within a distributed network without affecting the operation of the system.
  • the components could be embedded in a dedicated machine.
  • the various links connecting the elements can be wired or wireless links, or any combination thereof, or any other known or later developed element(s) that is capable of supplying and/or communicating data to and from the connected elements.
  • module as used herein can refer to any known or later developed hardware, software, firmware, or combination thereof that is capable of performing the functionality associated with that element.
  • determine, calculate and compute, and variations thereof, as used herein are used interchangeably and include any type of methodology, process, mathematical operation or technique.
  • aspects of the present disclosure may be embodied as a system, method or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit,” “module” or “system.” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
  • the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
  • a computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
  • a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus or device.
  • a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof.
  • a computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate or transport a program for use by or in connection with an instruction execution system, apparatus or device.
  • Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
  • Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. Other types of programming languages include HTML5, Flash and other similar languages.
  • the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
  • the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
  • LAN local area network
  • WAN wide area network
  • Internet Service Provider an Internet Service Provider
  • These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
  • the computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
  • each block in the flowchart or block diagrams may represent a module, segment or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).
  • the functions noted in the block might occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

Landscapes

  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé et un système permettant à un serveur hôte : de stocker dans une base de données de tickets des informations relatives à une pluralité de restaurants, les tickets contenant un statut disponible ou indisponible ; d'afficher les tickets avec le statut disponible ; de recevoir une demande du premier dispositif informatique d'utilisateur d'acheter un ticket avec un statut disponible ; de recevoir, du premier dispositif informatique d'utilisateur, une demande d'annulation du ticket et de revendre le ticket à un second dispositif informatique d'utilisateur ; et de créditer le paiement du ticket au premier dispositif informatique d'utilisateur.
PCT/EP2014/068718 2013-09-03 2014-09-03 Système et procédé d'étanchéité Ceased WO2015032807A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/915,706 US20160196508A1 (en) 2013-09-03 2014-09-03 Booking system and method
JP2016537345A JP6309629B2 (ja) 2013-09-03 2014-09-03 予約システム及び方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201361873209P 2013-09-03 2013-09-03
US61/873,209 2013-09-03

Publications (1)

Publication Number Publication Date
WO2015032807A1 true WO2015032807A1 (fr) 2015-03-12

Family

ID=51492310

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/068718 Ceased WO2015032807A1 (fr) 2013-09-03 2014-09-03 Système et procédé d'étanchéité

Country Status (3)

Country Link
US (1) US20160196508A1 (fr)
JP (1) JP6309629B2 (fr)
WO (1) WO2015032807A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017065996A1 (fr) * 2015-10-13 2017-04-20 Mastercard International Incorporated Systèmes et procédés pour déterminer la capacité actuellement disponible pour un fournisseur de services
US12456103B1 (en) * 2024-04-30 2025-10-28 Deal Engine Inc. High-throughput, low-latency transaction processing

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160189069A1 (en) * 2014-12-30 2016-06-30 E-Gatematrix, Llc Creating pre-order catalogs based on real-time inventories and carrier-related data
CA2984634C (fr) * 2015-05-06 2019-12-24 Bleachr Llc Transfert de billet pour un evenement de marche secondaire fiable : procede et appareil
US9860205B2 (en) * 2015-05-08 2018-01-02 Facebook, Inc. Managing for-sale group postings
US10057365B1 (en) * 2015-06-24 2018-08-21 Amazon Technologies, Inc. Asynchronous provision of resource status data
JP6670269B2 (ja) * 2017-04-21 2020-03-18 三井住友トラストクラブ株式会社 キャンセル座席の即時補充システム
WO2019014437A1 (fr) * 2017-07-12 2019-01-17 Somar Concepts Architecture, système et procédé permettant à des utilisateurs de commander des articles à livrer pendant des événements de voyage
US11842224B1 (en) 2017-09-01 2023-12-12 Amazon Technologies, Inc. Synchronous and asynchronous responses to data requests from remote devices
US12045744B2 (en) 2017-10-31 2024-07-23 Grand Performance Online Pty Ltd Autonomous and integrated system, method and computer program for dynamic optimization and allocation of resources for defined spaces and time periods
AU2018202759A1 (en) 2017-10-31 2019-05-16 Grand Performance Online Pty Limited A system, method and computer program for optimising and allocating resources in a space for defined periods of time
KR102147989B1 (ko) * 2017-11-30 2020-08-25 주식회사 카카오 예매 정보 및 티켓의 공유를 위한 방법 및 장치
US11308438B2 (en) 2018-07-12 2022-04-19 Rafael Ramos System and method for user to order items for delivery during travel event
JP2019079499A (ja) * 2018-08-14 2019-05-23 Ｌｉｎｅ株式会社 情報処理プログラム、情報処理方法および情報処理端末
JP7159689B2 (ja) * 2018-08-20 2022-10-25 富士通株式会社 決済装置、決済方法及びプログラム
AU2020200611A1 (en) * 2019-04-29 2020-11-12 Grand Performance Online Pty Ltd A computer-enabled method, system and computer program for managing the exchange between third parties of service contracts for the provision of a restaurant booking or other analogous service
US20210264481A1 (en) * 2020-02-26 2021-08-26 Airbnb, Inc. Auto-listing an accommodation of a subscription living user
US11783388B2 (en) 2020-02-26 2023-10-10 Airbnb, Inc. Detecting user preferences of subscription living users
KR20220022367A (ko) * 2020-08-18 2022-02-25 주식회사 픽넘버 Sns를 이용한 예약 및 결제 시스템 및 그 방법
ES2930549A1 (es) * 2022-06-15 2022-12-15 Jaen Ona Kevin Andres Procedimiento de reserva

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3315884B2 (ja) * 1996-12-27 2002-08-19 株式会社日立製作所 空港内総合ｉｃカードシステム
JP2002015192A (ja) * 2000-06-29 2002-01-18 Best Reserve:Kk 取引対象評価方法、取引対象評価システム、取引対象評価装置及び記録媒体、並びにホテル評価方法、ホテル評価装置、ホテル評価システム及び記録媒体、並びにホテル予約受付方法、ホテル予約受付システム、ホテル予約受付装置及び記録媒体
US7225148B2 (en) * 2003-07-25 2007-05-29 Peter Kassan E-commerce shopping cart
US8668146B1 (en) * 2006-05-25 2014-03-11 Sean I. Mcghie Rewards program with payment artifact permitting conversion/transfer of non-negotiable credits to entity independent funds
MX2010001492A (es) * 2007-08-07 2010-11-09 Ticketmaster L L C Sistemas y metodos para facilitar la asignacion de recursos en un entorno de red.
US20090254844A1 (en) * 2008-04-04 2009-10-08 George Davidson Method and system for managing event reservations and resource dispatching
WO2010145014A1 (fr) * 2009-06-16 2010-12-23 Boulton Ltd William Système de réservation en ligne
US20120291109A1 (en) * 2009-12-28 2012-11-15 Nec Corporation User information utilization system, device, method, and program
US20130013350A1 (en) * 2011-07-08 2013-01-10 Opentable, Inc. Offer based restaurant reservations
US20130090959A1 (en) * 2011-10-06 2013-04-11 Seatme, Inc. Restaurant management and reservation systems and methods

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
EPO: "Mitteilung des Europäischen Patentamts vom 1. Oktober 2007 über Geschäftsmethoden = Notice from the European Patent Office dated 1 October 2007 concerning business methods = Communiqué de l'Office européen des brevets,en date du 1er octobre 2007, concernant les méthodes dans le domaine des activités", JOURNAL OFFICIEL DE L'OFFICE EUROPEEN DES BREVETS.OFFICIAL JOURNAL OF THE EUROPEAN PATENT OFFICE.AMTSBLATTT DES EUROPAEISCHEN PATENTAMTS, OEB, MUNCHEN, DE, vol. 30, no. 11, 1 November 2007 (2007-11-01), pages 592 - 593, XP007905525, ISSN: 0170-9291 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017065996A1 (fr) * 2015-10-13 2017-04-20 Mastercard International Incorporated Systèmes et procédés pour déterminer la capacité actuellement disponible pour un fournisseur de services
US12456103B1 (en) * 2024-04-30 2025-10-28 Deal Engine Inc. High-throughput, low-latency transaction processing

Also Published As

Publication number Publication date
JP2016532972A (ja) 2016-10-20
US20160196508A1 (en) 2016-07-07
JP6309629B2 (ja) 2018-04-11

Similar Documents

Publication Publication Date Title
US20160196508A1 (en) Booking system and method
US12079768B1 (en) Systems and methods for managing airport lounges
US20220374849A1 (en) Graphical user interface for making payment to selected place on map or selected place in list
US12475499B2 (en) Automatic order generation using trained model
US20200387887A1 (en) Selected place on maps associated uniform resource locator (URL) or selected place associated merchant account based payment transactions, connections, offers, order, deals, reservation and call-to-actions
US11361298B2 (en) Shared mobile payments
US20170293950A1 (en) System and method for user selected arranging of transport
US9558516B2 (en) Social mobile shopping system
US20140330654A1 (en) Payment of restaurant bills
US20180046944A1 (en) Travel Management System
US10319024B2 (en) Collaborative geolocation shopping
US20150242889A1 (en) Systems and methods for event purchase and upgrade options based on user parameters
US20140142992A1 (en) Trip Planning and Budgeting
JP2022110048A (ja) 分散システムを構造化するためのアプリケーションプログラミングインタフェース
US10332168B2 (en) Line position bidding
US20240303617A1 (en) Social media marketplace
US20120284063A1 (en) System and method for providing a travel ecosystem with sharing of social travel preferences
US20150379486A1 (en) Systems and methods for automatic routine payments
US11341553B1 (en) Method and systems for a product list server
US20180174074A1 (en) System and method for making reservations for bottle and vip service at a venue
US20210224697A1 (en) Systems, methods, and storage media for decreasing business-to-consumer wait times
US20150294240A1 (en) Systems and method for implementing tour event comparison

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14759155

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2016537345

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14915706

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14759155

Country of ref document: EP

Kind code of ref document: A1