This Single Patent May Deliver A Huge Blow To A Dozen Startup Companies
On December 12th, 2013 while most of the US were focusing on holidays, the US patent office released a patent application filed on June 12th, 2013 by Apple. It appears to be just a small patent application but is actually a huge treasure trove of embodiments and presents a very detailed path Apple will take in retail payments. The patent application directly covers a unique system whereby a user of an iOS device could not only be presented with options of local restaurants but also the actual wait times and seating availability in real time. The patent goes on to explain remote and in restaurant ordering systems that allow customers and wait-staff to place and modify orders. Finally there is a payment option that would allow for pre or post payments of the order.
I have been presenting the case that Apple is moving slowly and steady into retail and online payments for quite a few years, it did not make me popular with startups that were told they were “disruptive”. I have advised many companies (that had the fortitude to listen) as far back as 2008. I now count about 270 patents directly and indirectly based on the payments solutions Apple is building. My most famous public postulation was the move to fingerprint scanner technology later called TouchID. TouchID represents the first significant building block in the direction of an end to end retail payments system. The device first needs to be reasonably secured.
An iOS Table Reservation, Ordering And Payment System
The patent presents a system that is highly integrated with iOS and has dozens of features for the consumer and the merchant. The system in its most basic form allows the iOS user to find local restaurants by any number of criteria and to consult in realtime if there is an open table. The system will then allow for an instant booking and reservation. The system will also allow pre ordering from a menu along with prepayment. There is far more to the aspects of this system then I can cover in a single posting, but there are dozens of interesting aspects one can find hidden in plain sight.
Direct iBeacons Use Cases
This patent is one of the first to show a deep use of iBeacons in the most expanded use case including of course Bluetooth LE but also as I have presented before but also “Wi-Fi, or other network capable of short range wireless communication”, one can read this as NFC (Near Field Communications). As the technology premise of iBeacons expands, we will see optics and magnetics also included in this list. The use of iBeacons will be foundational to some of Apple’s retail payment plans.
Early Warning System: Apple May Make Your Business Redundant!
There is absolutely no doubt that Apple is moving vigorously into retail payments with TouchID, iBeacons, iCloud Keychains, Passbook and finally the iWallet. This will come as a default in future iOS releases and will be so easy to use and work with every single merchant, you and I will soon forget the dozens of systems that are currently trying to garner your attention.
Companies that have followed my advice have a number of ways to be complimentary to what Apple will be doing. This movement by Apple will render redundant and perhaps irrelevant quite a number of products. The timing of this patent may indicate an iOS release in the next 6-8 months. If this is the case it will have a huge impact on potential IPOs and the stock of existing public companies.
This single Apple patent application should serve as an early warning system to dozens of startups and legacy companies including:
- Open Table
- and many others.
About 95% of Apple hardware patents become part of future Apple products. About 75% of Apple software patents become a part of future Apple products. These are very high odds Apple will apply many of the embodiments presented in this landmark patent application.
This is a very deep read and I cannot cover all of the really large implications it presents to the companies I mentioned above specifically. There are also some very non obvious directions that Apple has presented here. At this point I cannot go into the details but will cover this in future postings. I do suggest that anyone interested read my thesis why on July19th, 2013 Apple acquired Locationary the largest collection of location experts in the world.
I also suggest that anyone that has products in the payments space or is hoping to present products in the payments space take time and consult people with empirical praxis about how Apple retail payments will work. It is abundantly clear that with this patent application, at the very least any restaurant POS system and payment system will by directly affected.
Finally, this patent is unusual in that there is a single inventor, long time Apple engineer Sarin S. Mehta. We will be seeing much more from this really creative inventor:
SYSTEMS AND METHODS FOR PROCESSING ORDERS AND RESERVATIONS USING AN ELECTRONIC DEVICE
Disclosed herein are systems, methods, and non-transitory computer-readable storage media for processing reservations at restaurants. A system is described that includes maintaining a wait list for customers waiting to use a physical resource, such as a table at the restaurant. Wait times for customers on the wait list can be dynamically updated depending on the items that are ordered by seated customers.
 Restaurants have traditionally used similar techniques for processing customer requests. For example, customer requests to order food generally are communicated to a waiter, who in turn communicates the order to the kitchen staff. Once the kitchen staff has created the dish, the waiter delivers the food to the table for the customer to enjoy. Similarly, restaurant reservations are created by calling the restaurant and speaking to hostess. If a customer arrives at the restaurant without first making a reservation and no tables are available, the hostess places the customer on a waiting list. The hostess can combine the phone reservation requests with the walk-in requests in a single wait list and satisfy the requests in a particular order. The hostess or the waiter can also handle to-go orders over the phone or in person by taking the order, communicating the order to the kitchen, and delivering the food to the customer once the order has been made.
 Traditional techniques, however, do have their shortcomings. For instance, ordering is completely dependent on the waiter’s availability. A busy waitress may not get around to a customer who is ready to order for five or ten minutes. This idle time is magnified if the waitress is busy and unable to provide menus to the customer for five or ten minutes after the customer has been seated. Other shortcomings include the management of the wait list. During periods of high activity, a hostess may have problems managing the wait list given the number of reservation requests over the phone and in person. Thus, there is a need for improved techniques for processing restaurant orders and reservations.
 Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.
 Disclosed are systems, methods, and non-transitory computer-readable storage media for making reservations and maintaining a wait list for a resource at a point of interest. A point of interest can be restaurants, movie theaters, museums, auto repair services, or any other point of interest where customers wait for the right to temporarily use a resource. The resource can be physical, such as a table or booth at a restaurant. Each restaurant can include a wait list having entries, where each entry is associated with a customer waiting to use a table at the restaurant. Each entry can include a wait time that estimates the amount of time the customer has to wait before a table will be available for the customer. The wait time for a customer can be recalculated as the customer waits depending on the actions of the customers that are currently using the resource, such as sitting at a table. For example, a seated customer ordering one item is likely to spend less time at the table than a seated customer ordering four items. Thus the number of items ordered, or even more specifically the actual items ordered at a table, can be used to refine the wait time of entries in the wait list. Changes to the wait time or requests for a reservation can be communicated to the restaurant through a portable electronic device operated by a customer.
 Once a customer is granted the right to temporarily use a resource of the point of interest, the customer can order one or more items from the point of interest. In one embodiment, a customer can communicate orders for items by using a portable electronic device. In some examples, the portable electronic device can be used to review a menu, receive information associated with the point of interest, place an order, and be billed for an order. In other examples, the portable electronic device can also transmit personal information or a personal profile of the operator of the portable electronic device to the restaurant so that the restaurant can personalize the menu or provide recommendations for items to order. In one example, the personalized menu can be configured to remove items from the menu that contain substances that the customer is allergic to.
 In one embodiment, a system is described that is capable of providing recommendations for restaurants in response to a search query for a particular restaurant type, cuisine, ethnicity, price point, rating, or a combination of a few of these factors. The recommendations provided to the customer can be based on the wait time for the next available table at the restaurant. For example, the recommendations can contain only restaurants with a table available within a predetermined period of time. As another example, the recommendations can contain only restaurants capable of providing the customer with a table within a period of time after the customer arrives at the restaurant. These examples can take into consideration the wait list at the restaurants and the distance between the customer and the restaurant when recommending restaurants. In another embodiment, a customer can request to eat at a specified restaurant. A determination can be made whether a table will be available for the customer when the customer arrives or shortly after the customer arrives at the specified restaurant, presuming that the customer is about to head to the restaurant. If the wait list for the specified restaurant does not allow the customer to be seated when arriving at the restaurant or in some other manner is not acceptable to the customer, other similar restaurants that are able to meet the customer’s criteria for wait time can be found and presented to the customer. The other restaurants may be similar according to the cuisine type, price point, ethnicity, rating, or other factors.
 FIG. 5 illustrates an exemplary ordering system. System 500, which can be implemented within a restaurant or other point of interest, includes processor 510, wireless access point 520, portable device 530, and physical resource 540. Wireless access point 520 is configured to provide a wireless communications channel between processor 510 and portable devices such as portable device 530. Wireless access point 520 can be a Wi-Fi, Bluetooth, or other network capable of short range wireless communication. In one system implementation, a single wireless access point can be configured to receive and process communications from portable devices in the restaurant and transmit the information to processor 510. The range of the single wireless access point can cover the entire restaurant or point of interest so that customers or restaurant staff within the restaurant or point of interest can transmit information to and receive information from the processor through their personal devices. This can allow restaurant staff or customers to look at the menu, receive special offers, place orders, and pay the bill through a personal device. In another system implementation, multiple wireless access points can be included in the system. Each wireless access point can have a range that covers a single physical resource (e.g., table). In one example, there is a one-to-one mapping between physical resources and wireless access points. Thus, each wireless access point can communicate with devices within the vicinity of the physical resource and also communicate with the processor. The processor can determine the customer sending the communication by tracking the source of a communication to a specific wireless access point that is associated with a specific table. Here, wireless access point 520 is associated with physical resource 540. Wireless access point 520 is configured to communicate with devices within range 525 of physical resource 540.
 After transmitting an order, but before receiving the bill, the client receives the items ordered and consumes the items. A bill can be transmitted to the client at 855. Once the client has finished consumption of items ordered, the client can pay the bill at 860. In one example, the bill can be paid by handing payment (in the form of cash or credit) to the waitress. In another example, the client can use the client device to pay the bill by transmitting payment information such as a credit card number or bank account number to the server. The server can in turn receive the payment information and submit a request with the client’s financial institution for payment. Once payment has been paid, the server can provide updates, if necessary, to the anticipated meal duration chart and/or the estimated consumption period database at 865. The updates can be to revise and refine the database or chart based on statistics generated from serving the client. For example, the actual meal duration can be analyzed to refine the anticipated meal duration. Statistics of several meals can be used to refined the consumption period database. The actual meal duration can be calculated from when the party sits down at the physical resource, when the menu request is received at 815, or some other point in time. The actual meal duration can end when the bill is paid or when the client leaves the physical resource.
Also Read 10 companies that are already using BLE Beacons Technology
Brian Roemmele, is a mobile payments expert and an avid blogger at Quora. His profile can be found at http://www.quora.com/Brian-Roemmele. Brian is an Apple enthusiast and has deep interests in writing about new technology in payments.
Latest posts by Brian (see all)