PHILLIP J. WINDLEY: "The Live Web: Building Event-Based Connections in the Cloud", 21 December 2011, COURSE TECHNOLOGY PTR, ISBN: 978-1-133-68668-2, pages: ToC,Ch01 - Ch02,Ch10, XP055258627
JAN-KENO JANSSEN: "Wo bist'n du? - Googles Geodienst Latitude", C'T 03/2011, 17 January 2011 (2011-01-17), pages 86 - 88, XP055205403, Retrieved from the Internet
WIKIPEDIA: "Mobile Web", INTERNET ARTICLE, 8 February 2016 (2016-02-08), XP055278061, Retrieved from the Internet
WIKIPEDIA: "Web application", INTERNET ARTICLE, 10 April 2016 (2016-04-10), XP055278062, Retrieved from the Internet
WIKIPEDIA: "Multitier architecture", INTERNET ARTICLE, 15 March 2016 (2016-03-15), XP055278063, Retrieved from the Internet
| Claims ] We wish to protect the idea of the RESTAURware which makes use of the RESTAURair system architect for use in Restaurants and other public or private dining places. The Restaurair system architect enable the convenient interaction between the restaurant staff and diners for the purpose described in out document. The is idea make use of components of existing technologies such as wifi, mob apps and databases.. |
1. Introduction
Mr P. Chiobvu and partners (excelsys Integration Consultancy - Zimbabwe et al) have come up with an idea that will revolutionise the way diners and restaurant operators will interact. This paper provides a highlight of the idea. The objective is to delineate a high level design and functional capabilities of the proposed mobile app. At the end, all the stakeholders should endorse the feasibility and business case as presented herein.
2. Functional objectives
The app is expected to be the most popular and widely used mobile app by restaurants throughout the world. Some of the features will include.
Dinners will be able to check-in to a restaurant of their choice.
Dinners will be able to view the menu being served at any one point in time.
Dinners will be able to see the price being charged for the meals.
Dinners will be able to place their orders from their mobile devices.
Dinners will be able to claim an available table number
Dinners will be able to place an order for a meal, drinks, water etc.
Dinners will be able to add special meal requirements like;
o I want my steak well done
o I want my spice mild, or extra hot, etc
o Diners would not need to call a waiter to order additional requirements like drinks, they would simply request via the mobile interface.
Dinners will be able to pass comments, ratings on the quality of their meals.
Dinners will be able to view available restaurants in their proximity on a listing with some directions or on map together.
Dinners will be able to search for restaurants based on the theme or type of meals they server.
Dinners would be able to place bookings in advance as well as check-in on the fly (Walk-in). Diners will be able to pay online and send show their mobile number and receipt to the restaurant front desk.
The restaurant operator herein referred to as the Operator will be able to
Add, modify or delete menus being served as well as the prices.
Operators will be able to close or open restaurant
Operators will be able to receive orders they are immediately entered by the dinners. Operators will be able to view analytics about the performance their restaurant.
Operators will be able to view comments as entered by the dinners. Design Considerations
The name of the product will be finalised at a later stage. However, the product would be architecture as follows;
3.1. Database Server
- There will be a central database server that will be architecture for high availability.
o The database will hold all the relevant information as highlighted above such as the
Restaurant identification information,
o Restaurant Maps and location details
o Menus as being served per restaurant.
o The database may be a freeware MySQL to start with and may be further upgraded to a commercial database like Oracle or SQL Server as the business picks. However,
3.2. Application Servers
o This would be the middleware server which would house the application layer of the system. The specifics of the technology to be used for coding will be finalised at a later date, however it would be recommended to use modern versatile development platforms that can seamlessly integrate with Android as well as apple based devices. o These would need to be architectured for both high [performance and high
availability, as both dinners and Operators would need to exchange information at a very rapid and reliable pace
3.3. Web Servers
o The Web Servers would be located in the DMZ and would publish all the pages to the Internet. These would also be expected to be
■ highly secure
■ of extremely high performance
■ Highly available.
Business Objectives .1. On successfully deployed, this would be the first multi operator multi-dinner solution, which would be the preferred hub and the trusted source of information for both the dinners and operators.
.2. The solution is aimed to take the market by storm.
.3. It would be the first to offer mobile based dinner-operator interface.
.4. The idea would need to be protected and registered with the relevant global intellectual property and trademark authorities.
.5. This intellectual property registration would be done through our African based partners as it is cheaper to do so.
.6. Once the patent is registered, it would then be easy to attract venture capitalists to be able to deliver and put the idea into reality. The solution would be free to the dinners and the operators would be charged a nominal annual subscription and negligible percentage per order.
The information gathered over a period of time, would be very valuable for big data and analytics opportunities in the long run.
Other forms of revenue could be through advertising via the product.
Next Patent: PILLOW