Portable mobile payment processing system and case

Abstract

A portable mobile payment device and a mobile payment processing system are disclosed. An exemplary portable mobile payment device includes a smart mobile device; a credit card reader; and a protective case surrounding the smart mobile device and the credit card reader, the protective case including a first charging port for charging the smart mobile device and a second charging port for charging the credit card reader.An exemplary mobile payment processing system includes a portable mobile payment device connected to a remote service to capture order information; presents a confirmation and tip information to a customer; and transmits payment information to a payment processor, wherein the portable mobile payment device is a smart device connected to a mobile credit card reader and running a software application on a commercially available mobile operating system.

Description

RELATED REGISTRATION

[0001] This application claims priority to U.S. Provisional Application No. 63 / 320,237, filed March 16, 2022, and U.S. Provisional Application No. 63 / 269,155, filed March 10, 2022, both of which are hereby incorporated by reference in their entirety. TECHNICAL FIELD

[0002] The present disclosure relates to an electronic solution for ordering items and paying bills cashlessly in restaurants, bars, at festivals, on airplanes, and similar retail outlets. The present disclosure also relates to a portable mobile payment case for the electronic solution that combines a smart mobile device and a credit card reader into a portable mobile payment device, allowing both the smart mobile device and the credit card reader to be easily charged by placing the portable mobile payment device into a base unit configured to receive the portable mobile payment device. The base unit can be configured with matching chargers for the smart mobile device and the credit card reader.Embodiments of the present disclosure are applicable, but not limited to, facilitating payments at restaurants, bars, food trucks, or other venues or establishments that accept mobile payments. BACKGROUND

[0003] In a restaurant or bar, customers typically receive a bill after service is complete and then present a credit card to the venue's staff (i.e., a server, bartender, etc.). The credit card is taken from the customer, run through a point-of-sale device, and returned along with a printed receipt for adding a gratuity. Some credit cards may not be EMV-compliant and are "swiped" at a terminal to read payment information, rather than being "inserted" or "tapped."

[0004] An improvement on the state of the art is for a server to bring a mobile payment terminal to the table to scan a customer's credit card, rather than bringing the credit card to a fixed payment terminal. The mobile payment terminal is usually a proprietary device separate from the mobile ordering device. Such mobile payment terminals are commercially available from various point-of-service payment providers. These mobile payment terminals may be relatively large, meaning they are too large to be carried by the server throughout the service time, or they may be proprietary, meaning that if damaged due to drops, spills, or other malfunctions and accidents typical in the restaurant industry, they cannot be repaired or replaced by the restaurant but must be replaced by the manufacturer or supplier.In some situations, a server can use a mobile card reader, a slimmed-down version of a mobile payment terminal that can capture credit card information either by integrating a credit card reader or by integrating contactless payment hardware. The mobile card reader has fewer features than a traditional mobile payment terminal but is smaller and more portable. The mobile card reader typically transmits the credit card information to a mobile ordering device, which is also used to process payments using an application linked to the mobile credit card reader.

[0005] The mobile ordering device, mobile payment terminal, and / or mobile card reader are battery-operated. Therefore, throughout service or at the end of a day, both the mobile ordering device and the mobile payment terminal (or mobile card reader) would typically need to be charged by connecting each device separately to an AC power terminal, possibly via a USB plug or other proprietary connection. Maintaining two separate devices that require individual charging presents a restaurant with numerous problems. First, a server must keep track of two devices and may not be able to immediately locate the mobile payment terminal when needed. Second, a server may forget to charge the mobile ordering device or mobile payment terminal at the end of a shift, preventing the restaurant from efficiently processing orders and / or payments.

[0006] There is therefore a need for a single mobile device that can function as both a mobile ordering device and a mobile payment terminal (including a credit card reader function), with a housing arranged so that all components can be charged quickly and easily simultaneously. Furthermore, there is a need for an improved electronic solution for ordering items and cashless payment using an improved mobile payment device that minimizes personal contact or enables convenient management of internal and external management systems. SUMMARY

[0007] For example, in one embodiment, a customer may pay the bill at a restaurant using a traditional credit card, but instead of taking the credit card to a remote POS, the payment is processed using a portable mobile payment device running an application such as the Outpay Venue app.

[0008] In another embodiment, a customer at a venue may initiate a check using a credit card but complete the check using a portable mobile payment device running an application such as the Outpay Venue App. After initiating the check but before closing it, the customer may optionally view the check information on a personal mobile device or on a venue's portable mobile payment device, such as the portable mobile payment device. This check may be completed using the customer's personal mobile device, the venue's mobile payment device, or automatically after a preset period of inactivity without requiring the customer to re-specify the payment method, for example, if the customer otherwise forgets to complete the check.The portable mobile payment device can be used at a central location at the venue or at the table and can have Wi-Fi communication capability for the secure transmission of credit card information. Alternatively, or in addition, the portable mobile payment device can have cellular capability as a communication method for secure credit card information.

[0009] In another embodiment, a customer may pay a cover charge using a portable mobile payment device running an application such as the Outpay Venue App that accesses predetermined cover charges stored in a remote service.

[0010] In another embodiment, a customer may pay for items from a limited menu, such as at a music festival, using a portable mobile payment device running an application such as the Outpay Venue app. Due to potential connectivity issues, payment information may be stored locally and later transmitted to a remote payment processor. In this embodiment, paying a cover charge by accepting payments via the portable mobile payment device may result in the payments being immediately posted to the point-of-sale's POS system.

[0011] In another embodiment, a customer can pay for items using a name and room number, as might be used in a hotel. An application such as the Outpay Venue app, running on a portable mobile payment device, can interact with a property management system to confirm the validity of the provided name and number and enable payment processing. In this embodiment, accepting payments via the portable mobile payment device can enable immediate posting of the payments to the point-of-sale's POS system and any associated room rate database system.

[0012] In another embodiment, a customer may be given the option to join or contribute to a loyalty program of the venue or a third party, which may provide insights about the customer and provide targeted offers to the customer. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] To assist the average user in the field of the disclosed system in understanding how the system is manufactured and used, reference is made to the following drawings. Fig. 1 is a view of a portable mobile payment device according to an embodiment of the present disclosure. Fig. 2 is a rear view of a portable mobile payment device according to an embodiment of the present disclosure. Fig. 3 is a bottom view of a portable mobile payment device according to an embodiment of the present disclosure. Fig. 4 is a top view of a portable mobile payment device according to an embodiment of the present disclosure. Fig. 5 is a flowchart of an embodiment of the present disclosure involving card payments via an application executing on a portable mobile payment device. Fig. 6 is a flowchart of an embodiment of the present disclosure involving payment of bills via an application executing on a portable mobile payment device. Fig. 7 is a flowchart of an embodiment of the present disclosure that facilitates payment of cover fees. Fig. 8 is a flowchart of an embodiment of the present disclosure that enables rapid payment for items from a limited menu. Fig. 9 is a flowchart of one embodiment of the present disclosure for verifying payments of room rates. Fig. 10 is a flowchart of one embodiment of the present disclosure for enrolling in a loyalty program and generating customer insights from collected data.

[0014] Other systems, methods and computer-readable media are also discussed here. DETAILED DESCRIPTION

[0015] Embodiments of the portable mobile payment device are first described with reference to the Fig. 1 to 4 described.

[0016] Fig. 1 shows a portable mobile payment device 100 that includes both a mobile ordering device, such as a smartphone or a tablet, and a mobile credit card reader. Fig. In the arrangement shown in Figure 1, the mobile credit card reader can be positioned within a case 101 such that it is held in a recess 102 directly behind a mobile ordering device position 103, but within the case 101. With this arrangement, the mobile ordering device and the mobile credit card reader can be conjoined, allowing a server to naturally carry both devices as a single unit. The portable mobile payment device can be slim enough for the server to easily carry it in their pocket throughout their entire service / service shift.

[0017] Fig. Figure 2 shows an alternative view of the portable mobile payment device 100, in which a slot 201 is visible. The slot 201 may be configured to allow customers to insert a chip-enabled credit card for dip payments. The slot 201 may be intentionally arranged to allow only dip payments and prohibit swipe payments. The sleeve 101 may be made of an electromagnetically transparent material, which also allows customers to pay for transactions using a contactless tap-to-pay transaction, where secure credit card information can be transmitted via wireless communication through the sleeve 101 into the mobile credit card reader. This arrangement may compel customers to use contactless tap-to-pay or dip payments, which are more secure and result in lower payment fees for the venue compared to traditional swipe payments.

[0018] Fig. Figure 3 shows a bottom view of the portable mobile payment device, showing the charging ports 301 and 302 for the mobile ordering device and the mobile credit card reader, respectively. Charging both devices, i.e., the mobile ordering device and the mobile credit card reader, can be accomplished by placing the portable mobile payment device in a charging station.

[0019] Fig. 4 shows an exemplary charging receiver base 400. The charging receiver base 400 may be equipped with a receiving component or holder 401 into which the portable mobile payment device 100 may be placed or docked by the service operator. The charging receiver base 400 may include flanges 402 to enable easy docking and repeatable alignment of the portable mobile payment device 100 with charging devices 403 when the portable mobile payment device 100 is inserted into the charging receiver base 400 (note that the charging device connected to the charging port 301 in Fig. 4 is not visible).

[0020] In some embodiments, the receiving component or mount 401 and the flanges 402 can be constructed to provide mechanical guidance for swiping a portable mobile payment device. The charging receiver base 400 and the portable mobile payment device 100 can each include a pair of magnetic USB charging adapters (not shown) that conveniently route power from the charging receiver base 400 to both the mobile ordering device and the mobile credit card reader. The magnetic USB charging adapters can include a magnetically aligned disc coupling. The magnetically aligned discs can snap into place to complete the charging circuit when the coupling component of the portable mobile payment device 100 is proximate the coupling component on the charging receiver base 400.

[0021] If two magnetic USB charging adapters are mounted on each portable mobile payment device 100 in the appropriate position to connect to the USB charging adapters on the charging receiver base 400, the server can automatically place both the mobile ordering device and the mobile credit card reader into a charging state without having to work with one charging plug for the mobile ordering device and another plug for the mobile credit card reader, as in prior art systems.

[0022] The use of magnetic USB charging adapters can also facilitate easy charging of devices with different USB charging form factors. For example, typical mobile smart devices may utilize the USB-C charging standard, while typical mobile credit card readers may utilize the Micro-USB charging standard. By using magnetic USB adapters, the appropriate USB charging form factor for each component can be used to internally power the corresponding components within the portable mobile payment device 100. However, both components can externally use the same magnetically aligned USB charging coupler that the portable mobile payment device 100 is configured to use.Standardizing the charging hardware can simplify the design of the charging station and also allow greater flexibility of the internal components for the venue, as the portable mobile payment device can be used with 100 devices of all types.

[0023] In another embodiment, a single USB charger may be used, configured to power both the mobile ordering device and the mobile credit card reader via the single USB charger. Furthermore, one or more inductive chargers, such as Qi charging coils, may be used and configured to power the mobile ordering device and the mobile credit card reader simultaneously from the inductive chargers. In both embodiments, power circuitry may be provided within the portable mobile payment device 100 to route power from the single USB charger to the mobile ordering device and the mobile credit card reader.

[0024] Combining the mobile ordering device and the mobile credit card reader into a single device within the portable mobile payment device 100 can provide several advantages over prior art solutions. For example, since both the mobile ordering device and the mobile credit card reader can be off-the-shelf components, the venue may be able to replace, repair, or replace one or both components with off-the-shelf spare parts on its own, rather than having to replace the entire unit. This can also increase device flexibility and reduce downtime and costs if a device fails to function due to a drop, spill, or other reason.

[0025] By integrating both components into a single portable mobile payment device 100 and eliminating unnecessary components, the overall device may also be significantly smaller and more portable than state-of-the-art mobile payment terminals, while still providing mobile ordering functionality. This size reduction compared to state-of-the-art mobile payment terminals may allow a server to carry the portable mobile payment device with them, perhaps in a pocket, attached to a belt, in a holster, or other carrying device. By combining both components into a single portable mobile payment device 100, the high manufacturing costs otherwise associated with a device capable of receiving both mobile orders and credit card information may be eliminated. This reduces upfront and long-term costs.

[0026] The portable mobile payment device 100 can be constructed from various materials, including plastic or rubber. In some embodiments, the material must be permeable to wireless signals to enable mobile tap-to-pay transactions. Making the device from plastic or rubber may also provide the added benefit of providing the device with a degree of drop resistance. Plastic or rubber may also make the device flexible enough for a venue to replace either the mobile device or the mobile credit card reader without tools or other machining. This may allow it to be used in a typical restaurant or other food-service establishment.The portable mobile payment device 100 may be manufactured using typical manufacturing processes, such as injection molding, or it may be additively manufactured to provide additional customization options for venues, such as different color options or other decorative elements, without departing from the spirit of the disclosed embodiments.

[0027] In another embodiment, the charging receiver base 400 may be arranged to accommodate two, four, six, or more portable mobile payment devices. Note that Fig. 4 shows an embodiment that can accommodate four. The charging receiver base 400 can also be modular, allowing a venue to add as many portable mobile payment devices as needed to service that particular venue. The size of the charging receiver base 400 may only be limited by the number of magnetic USB charging adapters, which can be expanded by attaching additional power sources to the bottom of the charging receiver or by using USB splitter devices.

[0028] In an alternative embodiment, the portable mobile payment device 100 may charge the smart mobile device and the credit card reader via an inductive charger mounted on the back of the portable mobile payment device 100, rather than using magnetically aligned USB chargers. The portable mobile payment device 100 would include sufficient power circuitry to conduct power from the inductive charger to both the smart mobile device and the mobile credit card reader. In this embodiment, the portable mobile payment device 100 may not have openings for the dedicated charging ports for the smart mobile device or the mobile credit card reader. Such a configuration may provide additional water resistance or near-water resistance compared to the embodiment with openings for charging ports.

[0029] In an alternative embodiment, the portable mobile payment device 100 may utilize the integrated inductive charging capability of the smart mobile device to power the mobile credit card reader.

[0030] In an alternative embodiment, the USB power supply of the charging receiver base 400 may be provided not by a conventional AC mains supply, but by a car battery, a power tool battery, a generator, or an external battery pack. This provides greater flexibility at the venue and may allow charging of the portable mobile payment devices 100 at music festivals where mains power may not be readily available. Additionally or alternatively, the charging receiver base 400 may include one or more batteries. The batteries may allow operation of the charging station even when no other power source is available. The batteries may consist of one or a combination of custom battery cell arrangements, commercially available disposable batteries, or commercially available rechargeable batteries.

[0031] In some embodiments, the charging receiver base 400 may include wireless network components that can serve as a Wi-Fi hotspot or router. For example, the charging receiver base 400 may include components that enable the charging receiver base 400 to connect to the internet via cellular connections (e.g., LTE or 5G) and enable other nearby devices to connect to the internet via the charging receiver base 400. The charging receiver base 400 may selectively allow certain devices, such as the portable mobile payment devices 100, to connect to the internet, or allow all Wi-Fi-enabled devices, such as laptops or other mobile devices, to connect to the internet. In further embodiments, the charging receiver base 400 may include cryptocurrency miners or enable standalone cryptocurrency miners to connect to the internet.Such a capability could enable the charging receiver base 400 to mine cryptocurrency via the internet connection.

[0032] Fig. 5A and Fig. 5B depicts a flowchart of an embodiment of the present disclosure in which payment may be made for an existing bill created using a traditional point-of-sale system in a manner utilizing an application, such as the Outpay app, on a portable mobile payment device that combines a mobile ordering device with a credit card reader as described above. In a situation consistent with this embodiment, at step 501, a customer 1101 first attempts to complete an existing bill at a venue created using a traditional point-of-sale (POS) system. A venue employee 1105 uses a portable mobile payment device 1104 running an application, such as the Outpay app.Using the portable mobile payment device 1104, the venue staff 1105 searches for the customer's bill using a table number or other identifier in step 502. This search correlates the items ordered by the customer with their table. Using the portable mobile payment device 1104, the venue staff's request causes a request to be sent via an application programming interface (API) to a remote service, such as an outpay server 1107 or a remote POS service, in step 503. The outpay server 1107 or POS service would retrieve and return the bill information correlated with the table number or other identifier used by the venue staff 1105 in steps 504 and 505.

[0033] The invoice information would be displayed on the portable mobile payment device 1104 and presented to the customer for approval in step 506. At this point, the portable mobile payment device 1104 may also calculate possible tip amounts (e.g., 15%, 20%, 25%), and the portable mobile payment device 1104 would be presented to the customer for approval. Once the customer approves the tip amount in step 507, the invoice is updated to include the intended tip amount in step 508, and a payment processor 1106, such as Stripe, is notified of an intended payment in step 509.

[0034] At this point, the portable mobile payment device 1104 is presented to the customer so that the customer can make the payment either via a mobile wallet 1102 (such as Apple Pay or Google Pay) or via a physical credit card (step 510). A credit card reader 1103 connected to the portable mobile payment device 1104 can receive credit card information via chip / dip payment or contactless payment in step 511. The credit card information is passed to an application, such as the Outpay Venue app, running on the portable mobile payment device 1104, with the credit card information being securely sent to the payment processor 1106, such as Stripe, in step 512 via the software development kit (SDK).In step 513, the payment processor links the credit card information to the payment information and confirms, authorizes, or holds that amount on the card, effectively confirming the payment transaction against the customer's banking records. The payment processor 1106 is notified of the collectible amount for the transaction in step 514 and forwards this information via webhook to a remote service such as the Outpay API 1107 to indicate that the amount is ready to be collected. In step 515, the Outpay API 1107 or the POS service creates a request to capture the payment, which is sent back to the payment processor. The payment capture request can be made immediately upon receipt of the readiness notification or processed at a later time, such as at the end of the day, if a refund needs to be processed.

[0035] If the collection request is successful, the payment processor 1106 notifies the Outpay backend in step 516, which sends the payment to a POS server 1108, thus informing the POS of the transaction. In step 517, a receipt may be sent to the customer 1101 via an application on the portable mobile payment device 1104, such as the Outpay Venue app, and in step 518, a record of the successful payment is sent to the remote service, such as the Outpay API 1107 or the POS service. The Outpay API 1107 or the POS server applies the payment to the invoice in step 519, which is displayed on the physical graphical user interface (GUI) 1109 of the POS.

[0036] Fig. 6A and Fig. 6B depicts a flowchart of an embodiment of the present disclosure in which a customer initiates a check to order items at a restaurant or bar. In this embodiment, a customer 1101 requests to initiate a check to order items at step 601 and presents a physical credit card to venue staff 1105. Venue staff 1105 utilizes a remote service, such as the Outpay API 1107 or the POS service, to determine whether the customer already has an outstanding check and whether the check has been assigned to a particular table or venue staff 1105 at step 602. The remote service, such as the Outpay API 1107 or the POS service, queries a POS server or Outpay server 1108 to determine whether the check has been assigned to a table or venue staff at step 603.If the bill is not assigned to a table or venue staff, venue staff 1105 can make the appropriate assignment.

[0037] In step 604, venue staff 1105 then accepts payment from the customer via credit card or possibly a mobile wallet. Customer 1101 has the option of assigning a payment method to the bill using a smart device application, such as the Outpay app, and tracking the orders assigned to their bill in step 605. After the customer completes their order, they have several options to finalize the bill and select a tip amount.

[0038] In a first option, the customer may use the application, such as the Outpay app, on their smart device at step 606 without directly informing the on-site staff. In a second option, if the customer chooses not to complete the check using the application on their own smart device, they may alternatively complete the check at step 607 using a credit card reader 1103 connected to an application, such as the Outpay Venue app, running on a portable mobile payment device 1104. With this option, the customer may complete the check and assign a desired tip amount. Completing the check via the portable mobile payment device instructs the payment processor 1106 to create a payment intent for the original order amount or, in some cases, a selected pre-authorization amount at step 608.In a third possibility, the customer may forget to inform the on-site staff of their intention to complete the bill and may also forget to effectively complete the bill on their smart device using an application such as the Outpay app. In this case, in step 609, the venue staff 1105 may complete the bill with a preselected tip amount using an application such as the Outpay Venue app running on a portable mobile payment device 1104.

[0039] In all cases, upon completion of the invoice, payment data is sent to a payment processor 1106, which updates the payment information and obtains appropriate confirmation from the customer's bank in step 610. Before the invoice is completed, the payment processor may communicate with a remote service such as the Outpay API 1107 or the POS service in step 611 to automatically create a pre-authorization amount or increment pre-authorization amounts without requiring the credit card again.

[0040] When the invoice is initiated, the remote service, such as the Outpay API 1107 or the POS service, posts a new invoice in step 612 and creates a new invoice linked to the payment intent in the POS server 1108 in step 613. When the invoice is completed, a request to capture the payment information is transmitted to the payment processor 1106 in step 614. The payment processor 1106 captures the potentially numerous pre-authorization amounts as a single payment in step 615 and notifies the remote service, such as the Outpay API 1107 or the POS service, of the successful payment transaction in step 616. At this point, the remote service, such as the Outpay API 1107 or the POS service, posts the payment in step 617, causes the POS server 1108 to apply the payment to the invoice in step 618, and indicates via a GUI 1109 at the physical POS that the invoice has been completed.In step 619, the payment processor may also cause a receipt to be sent to the customer 1101 via SMS, email, or other means from an application, such as the Outpay app, running on the portable mobile payment device 1104.

[0041] Fig. 7A and Fig. 7B illustrate an embodiment of the present disclosure used to facilitate the payment of cover charges or other similar entry fees that may be charged when customers enter a bar, club, or other establishment. In this embodiment, customer 1101 wishes to pay a cover charge in step 701. Venue staff 1105 pre-selects cover charges and amounts in step 702, possibly interacting with a remote service such as Outpay API 1107 or a POS service, which itself interacts with a POS server 1108 in step 703 to determine a menu of possible cover charges or other entry items. Venue staff 1105 verifies the charge data, i.e., the number of guests wishing to pay the cover charge in one transaction, in step 704 and initiates a transaction via payment processor 1106.The payment processor 1106 creates a payment intent in step 705 after receiving transaction information from the portable mobile payment device 1104 running an application such as the Outpay Venue app. The customer 1101 has the option of presenting a credit card or a mobile wallet 1102 such as Apple Pay or Google Pay for payment in step 706.

[0042] Using the portable mobile payment device 1104, the venue staff 1105 captures payment method data in step 707 and sends the payment method data to the payment processor, which links the payment intent to the payment information and confirms the payment with the customer's bank in step 708. In step 709, the payment processor 1106 reports the captureable amount to a remote service, such as the Outpay API 1107 or the POS service. The remote service, such as the Outpay API 1107 or the POS service, sends a capture request to the payment processor 1106 in step 710, which captures the payment and returns a success notification to the remote service, such as the Outpay API 1107 or the POS service, in step 711.The remote service, such as the Outpay API 1107 or the POS service, sends the invoice with the payment in step 712 to the POS server 1108, which creates an invoice associated with the payment in step 713 and indicates that it has been completed. The customer 1101 is also notified of the successful transaction by receiving a payment confirmation via email or SMS and is admitted to the venue in step 714.

[0043] In this embodiment, cover charge processing can be significantly accelerated compared to credit card processing in prior art solutions because invoices are opened, paid, and closed instantly, and cover charge amounts are preloaded into the portable mobile payment device 1104 running an application such as the Outpay Venue app. Payment processing also skips the tip amount and confirmation step, further accelerating payment processing.

[0044] Fig. 8A and Fig. 8B illustrate an embodiment of the present disclosure to enable the rapid ordering of items from a limited menu, such as items from a food or beverage vendor at a music festival, golf course, airline, bottle service, side cart, bar cart, cocktail bar, or food truck. In this embodiment, the customer 1101 wishes to place an order in step 801. In step 802, venue staff 1105 pre-selects items from a limited menu. This may be from a list of menu items available via a remote service such as the Outpay API 1107 or the POS service of a POS server 1108 on which menus are stored. The venue staff confirms the customer's selection and initiates a transaction with the payment processor 1106 in step 803.In this embodiment, the payment can be linked to ordered items and not to an existing invoice.

[0045] The payment processor 1106 creates a payment intent in step 804 after receiving a notification from a card reader 1103 connected to an application such as the Outpay Venue app running on the portable mobile payment device 1104. The venue staff 1105 captures the customer's card information in step 805, possibly through a mobile wallet 1102 such as Apple Pay or Google Pay, or by swiping a physical credit card from the card reader 1103 connected to the portable mobile payment device 1104 running an app such as the Outpay Venue app. The card reader 1103 receives payment method data in step 806. In step 807, the customer 1101 has the option to add a tip via the portable mobile payment device 1104 running an app such as the Outpay Venue app.

[0046] If the venue has a mobile connection, the payment and possible tip information is immediately transmitted to the payment processor 1106, which updates the payment method based on the type of credit card transaction and sends a confirmation to the bank in step 808. If the connection at the venue is limited, the credit card and order information may be stored in step 809 until the connection to the portable mobile payment device 1104 is restored to transmit the payment information to the payment processor 1106. When the payment processor 1106 receives payment information, it reports the collectable amount to a remote service such as the Outpay API 1107 or the POS service in step 810, which sends a request to collect the payment to the payment processor 1106 in step 811.In this embodiment, an invoice can be created and the payment processed when the Outpay Venue app receives a notification of a collectible amount. The payment processor 1106 captures the payment and returns a success message in step 812, which triggers a receipt via email or SMS to the customer and a notification to the remote service, such as the Outpay API 1107 or the POS service, that an invoice can be posted with the payment. In step 813, the POS server 1108 creates the invoice associated with the payment and visually indicates on the POS GUI 1109 that the invoice has been completed.

[0047] This embodiment represents an improvement over traditional payment solutions for admission fees or cover charges, where venue staff 1105 must create an invoice for each transaction, navigate through the POS GUI elements to the admission fees, send amounts to an invoice, navigate to a payment section of a POS GUI 1109, select the fee type, enter the fee amount, select a tip (or, for cover charges, typically skip a tip), process the payment, finalize an invoice, issue a card, and optionally provide a receipt to the customer. In the present embodiment, venue staff 1105 can simply select the amount of the admission fees and collect the payment, optionally providing a receipt to the customer.The Outpay Venue app can automatically handle other aspects of the transaction without requiring further interaction from Venue 1105 staff, freeing Venue 1105 staff to process additional transactions.

[0048] Fig. 9A and Fig. 9B illustrate an embodiment of the present disclosure to facilitate payment of room rates, such as by a guest at a hotel, and link a property management service (PMS) 1110 with the at-table point of sale using an application, such as the Outpay Venue app, running on a portable mobile payment device 1104. In this embodiment, at step 901, a customer 1101 wishes to settle a bill for a room at a hotel or similar establishment and, at step 902, provides their room number and name to venue staff 1105. At step 903, venue staff 1105 searches the bill by table, bill number, or other identifier.

[0049] Venue staff 1105 may use a portable mobile payment device 1104 running an application such as the Outpay Venue App. The application checks a remote service, such as the Outpay API 1107 or the POS service, in step 904 to obtain invoice numbers. The remote service, such as the Outpay API 1107 or the POS service, queries the POS server 1108 for invoice information in step 905. Venue staff 1105 may then use the portable mobile payment device 1104 running an app such as the Outpay Venue App to query the room number provided by the customer in step 906. The application queries a remote service, such as the Outpay API 1107 or the POS service, in step 907 to determine whether the displayed room number is associated with a current and valid room reservation.

[0050] The remote service, such as the Outpay API 1107 or the POS service, can interface with the PMS 1110 to determine the current and valid status of the room number and its connection to the name provided by the customer in step 908. Once the room number and name are confirmed, the application on the portable mobile payment device 1104 can present an invoice to the customer for approval in step 909. The customer can approve the invoice items and specify an appropriate gratuity in step 910 and, if necessary, provide a signature for verification in step 911. The application on the portable mobile payment device 1104 can transmit the payment information and signature verification to a remote service, such as the Outpay API 1107, PMS 1110, and / or POS API, in step 912.In this way, a charge can be added to the guest bill via the PMS API in step 913, which could include a signature confirmation. Similarly, a payment confirmation with a payment type indicating that the payment was charged as a room charge can be provided to the POS API.

[0051] Additionally or alternatively, the customer 1101 may wish to add a new room rate to an existing bill or statement without paying or completing the transaction. In such embodiments, venue staff 1105 may query the bill by table, bill number, or other identifier using the portable mobile payment device 1104 connected to the remote service. The remote service, such as the Outpay API 1107 or the POS service, may interface with the PMS 1110 to confirm the room number and bill information as described above. In this case, the new room rate may be added to the confirmed bill information. Unlike the previous embodiment, the remote service, such as the Outpay API 1107 or the POS service, may leave the bill open for additional room rates without presenting it to the customer 1101 for payment.

[0052] In both embodiments, one or more modifiers or comments can be added to an amount, which can be forwarded to an appropriate department or system for further processing. For example, a food item bill can be modified with one or more special requests (e.g., extra tomatoes or no peanut sauce) and forwarded to a kitchen for fulfillment. This sample charge can also be forwarded to the inventory management system to update inventory (e.g., to record that an extra tomato was used) or to trigger automatic replenishment.

[0053] Returning to payment processing: In step 914, the remote service, such as the Outpay API 1107 or the POS service, posts the payment as a room charge with a receipt and signature. The POS server 1108 will, in turn, apply the payment to the transaction in step 915 and indicate on the physical POS GUI 1109 that the bill has been completed. A receipt for the transaction can also be sent to the customer via email, SMS, or other means.

[0054] Alternatively or additionally, venue staff 1105 may utilize an existing application on the physical POS GUI 1109 to interact with the PMS 1110. In such embodiments, the functionality described above with respect to the remote service, such as the Outpay Venue App 1107 or the POS service, may be achieved via pre-established connections between the physical POS GUI 1109 and the PMS 1110. Furthermore, venue staff 1105 may interact directly with the PMS 1110 using a client application connected to the PMS 1110, thus providing maximum customization capabilities using a native application.

[0055] In further embodiments, each venue employee 1105 may be assigned a unique identification number (e.g., PIN), which the Outpay Venue app running on the portable mobile payment device 1104 may require before the venue employee 1105 enters a charge or other action (e.g., initiating an invoice, collecting a payment, etc.) with respect to a customer. In this way, a charge or any action may be associated with a specific employee login account to act as the designated employee or responsible party, which may facilitate subsequent processing, such as distributing tips, filtering actions by employee, auditing, etc. Fig.Figure 10 illustrates an embodiment of the present disclosure in which a customer can opt into a venue's or business's loyalty program during any part of the transaction. This aspect of the present disclosure can be layered onto other embodiments described in the above specification.

[0056] In this embodiment, in step 1001, the customer 1101 is given the opportunity to enroll in a loyalty program using their phone number, email address, and / or credit card information. The remote service, such as the Outpay API 1107 or the POS service, may send customer information, such as applicable credit card information, timestamps, transaction amounts, ordered transaction items, menu item data, name, email, phone number, location, IP addresses, device data, and / or other information, to a loyalty program provider 1111 in step 1002. In step 1003, the loyalty provider 1111, which may be located on or off-site at the venue 1113, receives the customer information and may enroll the customer in a potential loyalty program, add points or frequent purchaser information, and generate potential discounts or other offers for the customer based on the received customer information.In step 1004, the venue 1113 or the building itself may also receive all or part of the customer information for enrollment in its own marketing programs. In step 1005, the customer information may also be sent to a credit card company 1112, an airline, a hotel, a restaurant, a ride-sharing service, a bank, or an application such as Outpay to enable enrollment in the respective company's loyalty program.

[0057] All customer information, along with loyalty data from loyalty provider 1111, potential credit card network data, and property-level data, can be fed into appropriate data analytics programs at step 1006 to gain insights into likely or potential purchasing habits. Customer insights can include generating dynamic menu options for customers 1101 based on past orders, ratings, reviews, venues, and customer behavior. Customer insights can identify valuable customers by card, loyalty level, or account information and provide information about these customers to venue staff 1105 using a portable mobile payment device 1104 running an application such as the Outpay Venue app.

[0058] These insights may also be provided to the credit card company 1112, the venue 1113, or another recipient to send targeted offers and other marketing materials in the form of targeted offers to the customer 1101 in step 1007. Targeted offers may include discounts or free rides with a ride-sharing service, free or discounted items such as drinks or food, free marketing items or exclusive access to events or spaces, badges, points, or non-interchangeable tokens. Targeted offers may be customized by advertisers or venues 1113 to include customized menus, video or static ads, billboards, etc.based on past spending behavior known to mobile apps such as Outpay, enrollment and / or status in loyalty programs, and / or card spending based on past credit card transactions and behavior. In another embodiment, customer data may be exchanged with, from, and between customer information databases maintained by venue 1113, credit card company 1112, the credit bureau, and / or Outpay itself to provide further insight into customer purchasing habits.

[0059] In the embodiments described above, the use of the portable mobile payment device 1104 represents a further improvement over prior art solutions, as it enables multiple payment and ordering transactions on a single instance of a traditional POS terminal, or possibly without a traditional POS terminal at all if all transactions are processed via the Outpay API 1107 in the cloud.

[0060] The disclosed embodiments may provide users (i.e., venue managers interested in receiving payments from customers) with greater flexibility in connecting traditional POS and PMS systems 1110. Existing POS services are often tied to a specific PMS or have limited interoperability with third-party services or systems, requiring users to compromise on functionality and / or usability. For example, many existing POS and PMS systems are often problematic, unintuitive, or cumbersome. Some don't even offer the hardware for tabletop use or interoperability with electronic payment processing systems.

[0061] As explained above with reference to the figures, the disclosed embodiments can thus provide hardware and software solutions that combine previously incompatible POS and PMS combinations with user-friendly tableside workflows. In the prior art, the POS and PMS systems were tightly coupled through proprietary solutions from vendors, such as Oracle Simphony POS or Oracle OPERA PMS. These proprietary systems enabled controlled information exchange from the POS to the PMS, such as the transmission of room rates. This integration and lack of extensibility forces venues to use potentially problematic, unintuitive, bulky, and / or nonexistent tableside mobile payment device hardware, or may require the manual storage of receipts for later data entry.In contrast, the disclosed embodiments may provide an interaction layer located between a proprietary POS of one vendor (Oracle's Simphony POS) and a proprietary PMS of another vendor (Stripe's Payments PMS), enabling the two proprietary systems to be used together in a single location.

[0062] Furthermore, the interaction layer may enable new or enhanced intermediate hardware and processing capabilities on and through a portable mobile payment device 1104 that were previously unavailable with proprietary POS and PMS systems. For example, the interaction layer, together with the disclosed embodiments, eliminates or significantly reduces manual processes that venue staff 1105 and customers 1101 had to go through when using prior art systems (e.g., printing an invoice, receiving a credit card from a customer for payment, authorizing a payment using the credit card, printing a receipt, receiving a signature and / or a tip from the customer, etc.). The interaction layer may also communicate with either the POS server 1108 or the PMS 1110 to retrieve customer information for various use cases (e.g.,(Searching / confirming rooms, creating room rates, using hotel discounts, collecting or using loyalty points, etc.) Such reductions significantly reduce the complexity of personal transactions, resulting in an improved user experience and faster service.

[0063] Although the present disclosure has been shown and described with reference to particular embodiments, it should be understood that the present disclosure may be practiced in other environments without modification. The foregoing description is for illustrative purposes; it is neither exhaustive nor limited to the precise forms or embodiments disclosed. Modifications and adaptations will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed embodiments. Although aspects of the disclosed embodiments are described as being stored in memory, one skilled in the art will recognize that these aspects may also be stored on other types of computer-readable media, such as secondary storage devices such as hard disks or CD-ROMs, or other forms of RAM or ROM, USB media, DVD, Blu-ray, or other optical drive media.

[0064] Computer programs based on the written description and the disclosed methods are within the competence of a skilled developer. Various programs or program modules can be created using any techniques known to those skilled in the art or developed in conjunction with existing software. For example, program sections or program modules can be created in or using the .NET Framework, .NET Compact Framework (and related languages ​​such as Visual Basic, C, etc.), Java, C++, Objective-C, HTML, HTML / AJAX combinations, XML, or HTML with embedded Java applets.

[0065] Although example embodiments have been described herein, the scope of all embodiments having equivalent elements, modifications, omissions, combinations (e.g., of aspects of different embodiments), adaptations, and / or alterations will be apparent to those skilled in the art based on the present disclosure. The limitations in the claims are to be interpreted broadly based on the language used in the claims and are not to be limited to the examples described in the present specification or during the prosecution of the application. The examples are to be understood as non-exclusive. Furthermore, the steps of the disclosed methods may be changed in any manner, including by rearranging the steps and / or inserting or deleting steps.Therefore, it is intended that the specification and examples be considered as illustrative only, with a true scope and spirit being indicated by the following claims and the full scope of their equivalents. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] US Application No. 63 / 320,237

[0001] US Application No. 63 / 269,155

[0001]

Claims

[1] Portable mobile payment device comprising: a smart mobile device; a credit card reader; and a protective case that surrounds the smart mobile device and the credit card reader, where: the protective case has a first charging port for charging the smart mobile device and a second charging port for charging the credit card reader. [2] A portable mobile payment device according to claim 1, wherein the charging ports are provided by magnetically aligned USB charging adapters. [3] A portable mobile payment device according to claim 1, wherein the intelligent mobile device is a smartphone. [4] The portable mobile payment device of claim 1, wherein the intelligent mobile device is a tablet. [5] A portable mobile payment device according to claim 1, wherein a user can replace the smart mobile device or the credit card reader separately. [6] A portable mobile payment device according to claim 1, wherein the credit card reader does not allow payments by swiping the credit card. [7] Portable mobile payment device comprising: a smart mobile device; a credit card reader; and a protective case that surrounds the smart mobile device and the credit card reader, where: the protective case has an inductive charger that supplies power to the smart mobile device and the credit card reader. [8] Mobile payment system, where: a customer presents payment information to a portable mobile payment device, the portable mobile payment device is connected to a remote service to capture order information, the portable mobile payment device presents confirmation and tip information to the customer and the portable mobile payment device transmits payment information to a payment processor, where the portable mobile payment device: is a smart device connected to a mobile credit card reader, and runs a software application on a commercially available mobile operating system. [9] The system of claim 8, wherein the payment information comprises information relating to a physical credit card. [10] The system of claim 8, wherein the payment information comprises information from a mobile wallet. [11] System according to claim 8, wherein the payment information includes a room number and a name, the portable mobile payment device is connected to a property management system and The property management system checks whether the room number and name are valid and up to date. [12] The system of claim 8, wherein payment information is stored locally for transmission to a payment processor at a time well after the time of the order. [13] The system of claim 8, wherein: an invoice is started for the customer, an incremental pre-authorization occurs when the customer orders items, and the customer can track ordered items via a smart device. [14] The system of claim 8, wherein: the portable mobile payment device is also used to accept item orders from customers. [15] The system of claim 13, wherein the bill is completed by a customer via their smart device. [16] The system of claim 13, wherein the bill is completed via a portable mobile payment device. [17] The system of claim 13, wherein the bill is closed after a period of inactivity. [18] System according to claim 8, wherein Customer information is shared with a loyalty program, customer insights are generated based on customer purchase information related to the loyalty program, and Targeted offers are made to the customer based on customer insights. [19] System for mobile payment processing of cover fees, where: a cover fee amount is pre-determined and stored on a remote server, a customer provides payment information to pay the cover fee, the payment information is received via a portable mobile payment device and transmitted to a payment processor.

Images