Grand Performance Online Pty Limited
[2023] APO 20
•17 April 2023
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Grand Performance Online Pty Limited [2023] APO 20
Patent Application: 2021201766
Title:Autonomous and integrated system, method and computer program for dynamic optimisation and allocation of resources for defined spaces and time periods
Patent Applicant: Grand Performance Online Pty Limited
Delegate: Dr W.E. Guinea
Decision Date: 17 April 2023
Hearing Date: 21 September 2022, by videoconference
Catchwords: PATENTS – standard patent application – Examiner objections – manner of manufacture – substance of the invention resides in a logistical or business scheme for the arrangement of objects – all claims lack a manner of manufacture – no patentable subject matter in application – application refused
Representation: Patent attorney for the applicant: Guy Tucker of Spruson & Ferguson
Also attending: Peter Petroulas of Grand Performance Online Pty Limited
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2021201766
Title:Autonomous and integrated system, method and computer program for dynamic optimisation and allocation of resources for defined spaces and time periods
Patent Applicant: Grand Performance Online Pty Limited
Date of Decision: 17 April 2023
DECISION
None of the claims are for a manner of manufacture. There is no material within the application that would lead to a manner of manufacture if made the subject of a claim. I refuse the application.
REASONS FOR DECISION
Background
Patent application 2021201766 (the “application”) was filed on 22 March 2021 in the name of Grand Performance Online Pty Limited (the “Applicant”). The application is a divisional to 2018360619 (the “parent”) and thereby has an earliest priority date of 31 October 2017.
Examination of the application was requested on 6 May 2021, and amendments and submissions in anticipation of examination were also filed on the same day. The first of five adverse examination reports issued on 20 May 2021, with the second examination report issuing on 9 July 2021, the third examination report issuing on 17 November 2021, the fourth report issuing on 22 December 2021 and the fifth report on 24 February 2022. All these reports objected to the claims as not being for a manner of manufacture, and this remains the only objection outstanding on the application.
Four responses to the examination reports were filed, the first three of these accompanied by proposed amendments. These were filed on: 17 June 2021 (the “First Response”), 5 November 2021 (the “Second Response”), 17 December 2021 (the “Third Response”) and 14 February 2022 (the “Fourth Response”).
On 23 March 2022, the Applicant wrote to the Commissioner requesting to be heard in relation to the outstanding objection. This request explicitly asked for an oral hearing. A hearing notice issued on 27 May 2022 advising the Applicant of the date for the hearing. The Applicant filed a written summary of submissions (the “written submissions”) on 14 September 2022 and the oral hearing was held on 21 September 2022.
I note that a series of amendments were proposed during the course of examination. This decision is written with respect to the specification as proposed to be amended.
The Invention as Described
The application may be broadly understood by reference to paragraph [0001]:
“The present invention relates to a system, method and computer program for the dynamic optimisation and allocation of resources for defined spaces and time periods.”
However, most of the rather lengthy (171 page) specification deals with optimisation of space and other resources in the context of a restaurant booking system. The repetitive prolixity of the specification has not assisted its analysis and has contributed somewhat to the length of this decision. It is perhaps helpful to begin with the specification’s rather extensive discussion of the prior art in the “Background” section extending from [0003] to [00128]. Here the specification discusses the history and shortcomings regarding booking systems in the restaurant industry, as indicated at [0003]:
“To better understand the inventive concepts and embodiments of the invention described herein, an abridged history and (sic) of the restaurant industry and known booking systems is described below, to assist in highlighting the technical advantages of the claimed invention. In particular, the functional limitations and inherent technical difficulties required to overcome the limitations of the known art are described below. The known prior art demonstrates the lack of any effective and workable technical solution to the fundamentally technical problems inherent in the optimisation, personalisation and integration of the many aspects of managing a modern restaurant, particularly with regard to automated booking, ordering and automated aspects of service in a restaurant.”
There is then a discussion of manual methods for managing restaurants with some historical discussion of the development of modern restaurants. The manual methods discussed include:
i.the numbering of tables for identification purposes;
ii.denoting joined tables to create a larger table by using a plus sign between the tables so joined e.g. joining tables 1, 2 and 3 would be denoted by “1+2+3”;
iii.the allocation of a booking to “tables” or “table combinations;” and
iv.the use of telephones to book tables.
Some issues or difficulties with some of these, and manual methods per se, were discussed, which I will briefly elaborate on below.
The notion of tables or table combinations was observed to improve efficiency as it allowed flexibility in use of the space via the use of smaller tables and then joining these together for large bookings as needed. The restaurant would not need many different sizes of tables or chairs as appropriate table sizes for bookings could be created from a standardised set of smaller tables and chairs.
10. However, tables or table combinations are observed not to be without their problems. The fact that tables can be joined together results in wasted space as represented by the gaps between the tables that may not make optimal use of the floor space depending on various occasions. The example provided is the comparison between using tables of two on Valentine’s Day (which is likely optimal for that occasion) as opposed to using family sized tables on Mother’s Day. This means that additional tables in some form might be kept on hand to ensure optimal use of space for various occasions. These could include folding or trestle tables or table bases that could accommodate different sized tabletops to minimise storage requirements. The use of some form of furniture storage for additional tables was known, though it was observed that given the increase in the costs of rental space, the use of dedicated furniture storerooms has become rare.
11. It was noted that “booking” of tables was facilitated by telephones, prior to which bookings were comparatively rare. Nevertheless, only so much information could be manually collected over the phone for a booking, comprising, for example, the name, number of people, time, phone number and any special requests. There would still be a need for manual intervention by a manager to review bookings and determine whether more bookings could be taken and which table(s) to allocate to the bookings. This manual review may involve reviewing and understanding a plethora of factors using the knowledge and experience of the manager to achieve desired restaurant outcomes in line with the restaurant’s strategy. This may involve the manager reviewing the bookings and:
· determining which customers to allocate the best tables to;
· allocating better seats to regular customers;
· allocating tables based on a special occasion;
· allocating similar types of bookings to one area of the restaurant;
· allocating bookings with similar finishing times near each other;
· allocating tables based on specific customer requirements or special needs;
· booking size;
· special requests;
· previous knowledge of requests; and
· knowledge of the restaurant and its desired outcomes.
12. In undertaking the above the manager needs to be aware of the spatial constraints of the restaurant, including for example, certain characterises of the tables, such as privacy, view etc. and which tables can be moved. The manager may also keep in mind staffing levels so that table allocations provide for efficient staffing, for example splitting bookings over different areas to even out workloads, consolidating bookings into a smaller area when short staffed or placing VIPs in areas where staff are experienced. Knowledge from the booking allocation process could be used by the manager to brief staff at the start of a service regarding customer requests or anything else they should know to create an optimal customer experience. As noted at [0021]:
“…the manual allocation of a booking request to a table was, in an ideal setting, a deliberate process that took into account information, skill and knowledge far beyond the simple information collected by the reservations staff over the telephone to achieve the desired outcome for a restaurant based on its strategy.”
13. The end result of this process may be described as a booking allocation that is optimised with respect to a restaurant strategy. The manager may provide notes to staff regarding what times/sizes of bookings could still be accepted in future. This can lead to further bookings and a reiteration of the allocation process by the manager, potentially multiple times, in order to have an optimised table/booking allocation. The process could also be undertaken again once all booking requests were known.
14. The specification provides an overview of some of the shortcomings of known manual booking and optimisation methods at [0026] to [0029]:
“[0026] How often a restaurant manager would apply their skill and knowledge or how much time was allowed for the abovementioned allocation considerations how effectively they were implemented, and whether they were applied consistently, even within a single service, is difficult to quantify, for the simple reason that such considerations were not codified per se but were taught or passed on from one person to another in the same manner as most other skills were traditionally taught. There is no formal course or specific text that teaches what specific factors that one must consider in the booking allocation process, how to assess those factors and then how to prioritise or weigh those factors in making the booking allocation decision. Lastly, as this booking allocation process was undertaken by different persons for different restaurants or different people within the same restaurant, their personal preferences and experiences, including their underlying ability to reallocate bookings in the most efficient manner, etc., meant that no two persons would necessarily provide the same set of allocations. As such, it is highly unlikely that any restaurant applied any of the above considerations efficiently, effectively and without exception.
[0027] Notwithstanding the lack of consistency in application of these concepts and considerations, the manual allocation of bookings to a ‘table’ or ‘table combination’, if done correctly, is a sophisticated process that takes into account the needs of the customer, the spatial constraints of the restaurants and the resources of the restaurant. Therefore, at its best, a table allocation process as practiced by a skilled, knowledgeable and motivated restaurant manager represented the manual (albeit imperfect) ‘solving’ of a very sophisticated multi-variate problem that comprised qualitative variables, spatial and other quantitative variables and resource variables. It is fundamentally a technical problem as it requires the solving of a problem, which is not strictly a mathematical problem per se, but rather is a logic problem that requires a multi-step algorithm that takes into account many separate and sometimes conflicting requirements.
[0028] Even with the best of intentions and a high level of skill and knowledge, it was difficult for a restaurant manager to allocate bookings in an optimal manner, even for a smaller restaurant, as the different considerations, permutations and potential table combinations are impossible to properly consider, irrespective of the experience levels, training, skill or wisdom of the restaurant manager within a reasonable period of time. It is widely understood and acknowledged that the profit margins in restaurants are quite small (generally profit margins are less than 5%) so there is very limited time that any restaurant could afford in additional wages for the restaurant manager or another person could spend undertaking this booking allocation process. As such, this manual process was not only applied inconsistently but would have rarely been optimised.
[0029] With the expansion of the hospitality industry and with no formal training available as to how to allocate bookings to tables these skills continue to be underdeveloped and rarely applied, except perhaps in some fine dining restaurants.” (emphasis added)
15. After dealing with manual booking/allocation methods, the specification moves onto known computer implemented booking methods. It is observed that with uptake of the internet, businesses were looking to remove manual processes. In this regard several online restaurant booking systems are listed, such as OpenTable. Despite such systems being around for twenty years, it is observed that:
“…the underlying process which all restaurant booking companies use in their software for the collection of booking information and the allocation of booking requests to tables is substantively identical with no significant or substantial improvements having been made in the last 20 years.” (specification at [0031])
16. The difficulties or problems with these online booking systems are discussed from [0033] to [0088]. In summary, these are:
·booking allocations to tables are fixed, based on manual or automatic prioritisation of tables/table combinations, e.g. first in, first seated to smallest best fit table/table combination;
·each collects a similar quantum and type of information;
·each uses collected information in a similar way in allocation of a booking to table(s);
·each collects identical information as per manual bookings made by phone;
·only allow for a fixed number of tables in the allocation solution pool, i.e. are unable to add or remove tables during the allocation process;
·require manual input of tables and table combinations in the restaurant to form the total number of tables in a solution pool, including:
omanually determined total number of tables placed in the restaurant;
omanually determined list of all tables and table combinations in order of allocation priority;
oprioritised list of tables and table combinations with the maximum and minimum booking numbers that can be allocated to each table/table combination;
·there is no check or control process regarding the appropriateness of the tables in the solution pool;
·require manual intervention due to fixed bookings;
·do not take account of spatial characteristics in allocating bookings, e.g. window tables, tables with a view;
·cannot sell, offer, or re-arrange previously allocated tables to a customer;
·cannot withhold certain tables/table combinations/areas for sale with confirmed availability;
·cannot automatically receive and act on customer requests, customer history, customer priority or other details as part of the allocation process;
·do not allow a customer to personalise their booking/experience e.g. select a certain table, request a certain waiter, arrange for further services experiences, such as flowers, entertainment, special meals etc.;
·cannot properly account for time as a variable resource as part of the booking allocation e.g. there is no account of/variation for the time needed to reset tables, time differentials that may occur for different menus, different courses, different group sizes or the time taken to consume a meal based on menus, group sizes etc.;
·cannot offer dynamic pricing or products, for example cannot offer pricing based on a table with a view having greater value than one without i.e. perceived table value;
·cannot control table availability based on menu or other constraints, thereby preventing the application of yield (revenue) management in the booking allocation process (at [00125] “yield management” is stated as “…the strategic control of inventory to sell the right product to the right customer at the right time for the right price”); and
·cannot offer complete/seamless integration between different restaurant systems e.g. discount and promotional apps, electronic menus, point of sale systems, customer relationship management systems.
17. Because of at least some of these shortcomings, the online booking systems are said to be inflexible and inefficient, as they do not allow for optimised booking/table allocation without the manual process undertaken by managers described previously. Indeed, it is suggested that online systems require more manual intervention as each booking is immediately allocated, thereby necessitating more frequent manual intervention to achieve optimised booking/table allocation.
18. Some further difficulties with the prior art online systems are noted at [0085] and [0086]:
“[0085] The multiplicity of systems offered by the prior art and the numerous manual interventions required teaches away from the use of a single central system from which all other restaurant systems can logically be integrated into to form a complete, integrated and autonomous restaurant system. This is despite the obvious benefits of an integrated and autonomous restaurant booking allocation process and an integrated and autonomous solutions to increase the revenue of a restaurant, the better meeting of customers' requirements, reducing costs, forecasting demand, adjusting operating constraints, developing resource requirements and staff requirements, providing additional services such as tailoring a customer's experience, home delivery and gift cards.
[0086] To put it another way, as the prior art has not been able to improve the table allocation process many companies providing on-line restaurant reservations have stated that there is no better way to allocate booking requests to tables than the processes already available. Further, many of the companies have abandoned trying to improve the booking allocation process and are now focusing on additional features to their systems. To give a racing car analogy of what is happening with many online booking system providers; they have abandoned trying to make their racing car go faster as they do not know how to do it, and are now focusing on features such as adding metallic paint, tinted windows, mag wheels, rear spoilers, which, if anything merely add to the manual processes of maintaining the car without any additional benefits to the speed of the racing car. That is differentiation by appearance than differentiation by performance of the core characteristic. Specifically, most, if not all, online restaurant booking systems now offer (sic) are ‘integrated’ CRM [Customer Relationship Management] system. However, these CRM systems do not and cannot be linked and form part of the table allocation process. An example of the inefficiency of this prior art is that while many of the prior art CRM's record a customers' favourite table, none of the prior art systems can use this information in the booking allocation process to allocate a loyal customer to their favourite table.”
19. A discussion of prior art approaches attempting to deal with the static nature of computer implemented systems follows at [0087] to [00128]. This discussion focuses on two particular items of prior art, namely:
· Vidotto, Alfio (2007) “Managing Restaurant Tables Using Constraint Programming” [Doctoral thesis, National University of Ireland] (“Vidotto”); and
· Bossert, J.M., (2009), Yield Management of Configurable Restaurants (US 2009/0292566 A1) (“Bossert”). I note that Bossert was cited during examination of the application.
20. Both Vidotto and Bossert are said to use constraint programming (“CP”) in addressing the dynamic booking allocation problem. At [0092] to [0097] the specification suggests that the prior art represents CP as being the only known solution to the dynamic booking allocation problem, perhaps not least due to the bold heading preceding paragraph [0092]: “Constraint programming as the only solution to the dynamic booking allocation problem”. The specification goes on to elaborate on this point, as I will delve into further below.
21. The use of CP in Vidotto is discussed in paragraphs [0093] and [0094] as follows:
“From a technical perspective, Vidotto only describes the use of the known mathematical formula and technique of ‘constraint programming.’
Based on the above, it is clear that Vidotto's work is solely based on and revolves around the use of tables and table combinations as the solution or domains within a CSP [Constraint Satisfaction Problem] to define and solve the restaurant table management problem.”
22. Similarly, the use of CP in Bossert is discussed at [0096]:
“Bossert not only acknowledged the existence of the theoretical art of ‘constraint programming’ for the dynamic allocation of bookings to tables in his cited art in paragraph [0047] of his patent application, but also acknowledged within that paragraph his use of the prior art of constraint programming as the solution for the capacity determination and the allocation of booking requests to tables. Specifically, at paragraph [0047] Bossert states:
‘Methods to perform the calculations of capacity module 60 exist in the prior art. For example, mathematical and logical constraints can be used to describe the seating capacity of a restaurant whose tables may be reconfigured and constraint programming solution procedures can determine or at least estimate whether the restaurant has sufficient capacity to accept a set of table reservation requests’. [underlining and bolding added]”
23. Finally, at [0097], the specification concludes:
“Form (sic) the above it is clear that Vidotto and Bossert disclose ‘constraint Programming’ as the only known system and mathematical approach that can solve the problem of dynamically allocating booking requests to restaurant tables.”
24. However, it is not clear to me how Vidotto or Bossert support the conclusion that CP was necessarily the only known or possible solution to the dynamic booking allocation problem. It is quite clear that both Vidotto and Bossert make use of CP, but there is nothing, in my opinion, in the passages cited from either document to suggest that these support the notion that CP is the only conceivable way or the only known way to solve the dynamic table allocation optimisation problem. The fact Vidotto and Bossert use CP does not necessarily exclude the possibility of other methods or approaches. Notably [0047] from Bossert, as quoted at [0096] of the specification, quite clearly indicates that CP is merely an example of a known way to solve the allocation problem. I also note that the specification has not suggested that Vidotto or Bossert comprise the universe of prior art in this area, and indeed such a contention would be incredible.
25. It is stated that Vidotto sought to create a dynamic booking allocation process. This was said to be achieved by unseating all previous booking allocations when a new booking is received and then the current pool of booking requests is used to determine an optimal table allocation solution. Despite this the specification suggests that Vidotto is inadequate:
“However, the proposed solution put forward by Vidotto is incapable of the ‘optimisation of the (dynamic) allocation process’. The best Vidotto’s proposed solution can achieve is to maximise the number of bookings taken on the manually pre-determined pool of table and table combinations that form the total pool of solutions from which a table allocation can be made.” (specification at [0090])
26. This highlights to me, the fact that both Vidotto and Bossert were seeking to solve a dynamic table allocation problem, even if Bossert was doing this with yield in mind. This is of rather narrower ambit than the invention as generally described, which, as discussed further below, seeks to provide an optimised strategy or outcome for a restaurant/venue in view of a wide variety of relevant constraints or factors that impact on that outcome/strategy, in undertaking table allocation. Whilst the invention as claimed does not necessarily require optimisation in view of a strategy or outcome (but allows for that), it still allows for the input of a very wide range of constraints that goes beyond the table allocation of Vidotto and Bossert. That is, the present invention, both as claimed and described appears to be solving a different problem to the one addressed in Vidotto and Bossert.
27. Before continuing, it is worth noting that here I have discussed the invention as described by reference to restaurants/venues, as the issues with the prior art are discussed entirely with respect to allocating bookings to tables in the context of restaurants. I observe that the invention as claimed, at least, is in no way limited to restaurant table allocation issues. Rather the claimed invention applies generally to any requests associated with any objects that need to be allocated in any area at a defined time according to those requests, request constraints and the dimensional constraints of the objects.
28. There then follows some discussion of CP and some of its problems, with reference to Vidotto, at [0098] to [00116]. This begins at [0098] with a very general definition of CP based on an extract from Vidotto:
“In Chapter 3, page 27, Vidotto introduces his specific view of constraint programming where he states:
‘A constraint program represents the problem as a Constraint Satisfaction, problem (CSP), and then solves the CSP with a combination of constraint propagation and search (typically backtracking search)’
‘In CP terms, representing a problem means selecting a set of decision variables, each with a domain of values, and a set of constraints over these variables that restricts the values that subsets of variables can take’. [underlining added]”
29. At [00102] it is stated that:
“By definition, the constraint satisfaction problem is one where all possible solutions are determined from a fixed list of tables and then values and constraints are set so that when a new variable (booking request) is received a new search can be undertaken to find the best a pre-defined and developed solution.”
30. A distinction is suggested between “constraint programming” and “constraint information” at [0099] to [00101]:
“It is noted that ‘constraint programming’ refers to the construction of a specific type of mathematical formula. While ‘constraint programming’ uses ‘constraints’ or ‘constraint information’ to classify or filter the variables within the ‘constraint program’, the use of constraint information in order to determine a solution does not imply that any mathematical or logical program that utilise constraint information is an example of ‘constraint programming’. ‘Constraint programming’ refers to a specific and particular type of mathematical ‘process and formula’ to be used to solve the problem and not to the use of individual constraints within any formula or any mathematical equation.
In other words, the reference to ‘constraint programming’ in the prior art is a very specific term of art in the field of mathematics and computer science. Vidotto's work is based on the use of CSPs to define and solve the restaurant table management problem.
The term ‘constraint information’, in contrast, is not a term of art in the context of mathematics or computer science. The term ‘constraint information’ is to be ascribed a plain meaning to those skilled in the art, namely those who work and operate restaurants or analogous enterprises where physical space needs to be managed in some manner. The use of the term ‘constraint information’ is intended to include information that defines the physical characteristics and limitations of the space (which may be broadly characterised as the ‘resources’ available, and also the desired outcome with reference to the restaurant's strategy or the customer experience (e.g. a VIP customer wishes to dine at a particular table)). These disparate yet interrelated pieces of information form a collection broadly referred to as the ‘constraint information’. This is a very different concept from the mathematical and computer science concept of ‘constraint programming’.”
31. The specification outlines a number of problems that it considers exist with the approach of Vidotto and CP more generally. These are discussed at [00105] to [00116] and include:
· table allocation is restricted to a pool of defined solutions (“domains”). The CP is said to merely be a search mechanism arranged to find a solution from a predetermined pool of solutions and is said to suffer from the same limitations of other systems;
· there is no ability to add or remove tables so as to provide for a “truly optimised solution”, for example as part of what I understand to be “yield management”;
· there is no account of floor space in the optimisation;
· does not eliminate the need for a restaurant manager – the manager would be required to deal with changes in the size or number of tables;
· there are no checks to ensure all appropriate solutions have been included (although I note it is not clear what is meant by “appropriate solutions” here – it may simply relate to optimisation of other matters as discussed in the specification e.g. selling tables based on their perceived value), as part of “yield management”;
· needs to be manually defined for each restaurant and be manually updated to include any changes in the number and sizes of tables – this requires significant time and expertise to do so;
· is not practical as a restaurant manager, a mathematician and a computer programmer are needed to “…develop, define and maintain the system”;
· only represents a small number of the information/variables that a restaurant manager takes into account in allocating bookings, for example there is no taking account of a customer relationship management database that could be used to personalise the booking by, for example, providing a window table;
· using scheduling programming along with constraint programming is said to be computationally inefficient; and
· using constraint programming is said to be computationally inefficient.
32. Specific issues with Bossert are discussed at [00117] to [00121]. Bossert’s approach is said to have similar difficulties as outlined with regard to Vidotto. Specific issues with Bossert are said to be:
· is further removed from the way in which restaurants actually allocate tables and resources;
· “is more dependent on estimations, approximations, and mathematical complexities, in attempting to overcome the mathematical complexities and definitional problems of the chosen method of ‘constraint programming’ as a technique for solving the allocation problem”;
· has additional costs associated with the creation of tailored solutions for each restaurant;
· does not provide any detail on how the numerous constraints and variables can be incorporated into the CSP; and
· does not address yield management in a meaningful way – this is characterised at [00128] as follows:
“The yield management disclosure of Bossert has no practical utility, nor is it an enabling disclosure, as it does not adhere to yield management principles, it does not properly apply yield management principles and it does not describe a workable solution. It is, at best, a mere ‘paper anticipation’ for a set of ideas, not a workable embodiment that utilises yield management terminology.”
33. After this lengthy but seemingly narrow survey of the prior art, a summary of the invention is provided at [00128a] to [00336]. This begins with the statement at [00128a] that “It is an object of the present invention to substantially overcome or at least ameliorate one or more disadvantages of existing arrangements.” A series of consistory statements, as well as paragraphs explaining advantages of the invention, follow at [00128b] to [00336]. Paragraphs [00128b] and [00128c] are congruent with independent claims 1 and 13 respectively and said to respectively reflect first and second aspects of the invention.
34. Besides these two aspects, the summary goes on to identify a plethora of “aspects” and “embodiments” of the invention via the consistory statements. The aspects appear to cover, at various points as I understand it, both the invention as a whole and variations thereof. The “embodiments” appear to relate to further details of how the invention may be implemented. Nineteen aspects are identified, most by number, although confusingly there are two first and two second aspects and one aspect is not referred to by number at all. By my count no less than 143 different “embodiments” are identified, some with their own further sub-embodiments.
35. The expansive and repetitive nature of the summary, like most of the specification, makes it difficult to summarise the same. Nevertheless, it may be reasonably said that the heart of the invention as claimed is given in the first two aspects outlined at [00128b] and [00128c], while the other aspects and embodiments listed in the summary appear to specify variations to the invention as claimed or described. For understanding and convenience I will commence with the consistory statements as these respectively reflect claims 1 and 13. The second aspect of [00128c]/claim 13 is directed to the autonomous allocation per se, rather than the method of the first aspect of [00128b]/claim 1. Other than this, this second aspect does not differ in material respects from the first aspect. Consequently, I will not discuss the second aspect in detail here.
36. The first aspect is probably best expressed simply by the words from [00128b]. However, I have provided it below with some structure to assist in understanding and readability. Given the nominally general applicability of the first aspect, I have also added relevant but non-limiting examples (i.e. I have not attempted in all cases to list everything that could fall within the scope of the feature, where appropriate, based on the invention being applied to a restaurant in brackets and italics, as this assists in providing a practical understanding of the effect of the invention. This is particularly so as the thrust of the entire specification is with regard to a restaurant or venue. Having said that the first aspect hereby follows:
a method for autonomous allocation of representations of objects (tables) at a defined time within at least one representation of an area (restaurant floor plan),
the representation of the area comprising attributes including dimensions constraints (dimensions and shape of the restaurant floor etc.),
wherein one or more allocation processes result in placement of the representations of the objects within the representation of the area for a defined time in accordance with requests received (booking requests for a certain time having a certain number of people means a certain size/number of tables to accommodate those bookings are represented in the restaurant floor plan),
the method comprising the steps of:
receiving a request signal comprising a request and request constraints (receive a booking for a certain time with a certain number of people),
wherein the request is for allocation of at least one object at a defined time (a table or tables for the booking time),wherein the object comprises a shape, dimensions and associated attributes (table size and shape), and is associated with representations of objects that are utilised, added, removed, reorganised within at least one representation of the area (tables, chairs etc.);
determining from data in a volumetric area and time database whether other requests for allocation of at least one object have been stored for the area at the defined time and, upon that determination, retrieving data from the database regarding the other requests (look up a booking data base that specifies the time and volumetric requirements (e.g. table space) of bookings to see if other bookings, requiring tables etc., have been made at the relevant time for the restaurant, and if so retrieve data regarding those bookings);
combining the request with the other requests to form a new pool of requests (combine the received booking with previously made bookings to form a new list of bookings);
ranking the requests within the new pool of requests by both requestor information and the request constraints from the data in the database using categories to generate a new pool of ranked requests (rank the new list of bookings based on e.g. the person who made each booking and the number of people in the booking, as outlined in the booking database, using some form of category (e.g. VIP status) to make the ranking, to generate a new ranked list of bookings);
iteratively allocating, using a dynamic decision tree allocation process, the request and other requests for the object(s) to the area at the defined time using the categories and/or thresholds, wherein the rankings and the thresholds are changeable during the dynamic decision tree allocation process (repetitively allocating each booking to particular table(s) in the restaurant at the defined time based on some form of category or threshold (e.g.VIP status),where the rankings and thresholds can change during the allocation process, using a dynamic decision tree process);
selecting, for each request, a next request in the new pool of ranked requests, and for the selected next request, retrieving constraint information from the database for use in the dynamic decision tree allocation process (selecting for each booking the next booking from the new ranked list of bookings and retrieving constraint information of the next booking (e.g. the number of people in the booking) for use in the iterative allocation using a dynamic decision tree process);
wherein the constraint information includes information regarding the shape and dimensions of the representations of the objects and the dimensions of the representation of the area including the dimensions of any constraints within the area, including any associated attributes between each of the representations of the objects comprising quantitative and qualitative relationships between each of the representations of the objects to each other and within the representation of the area (the constraint information includes data on the shape and size of the tables and the dimensions of the restaurant floor plan including any constraints such as, for example, internal walls, the constraint information also comprising associated attributes between the tables, including quantitative and qualitative relationships between the tables and within the restaurant floor plan (e.g. the relative sizes of the tables, whether they can be joined or split to form larger/smaller tables, their shapes etc. shown within the restaurant floor plan);
utilising object constraint information including dimensions, object and area quantitative and qualitative attributes and request constraint information to select the representation of the object with a shape, physical size dimensions and associated attributes capable of being allocated within the representation of the area to satisfy the request through a selection of a location in the representation of the area for the request (table constraint information including the size of the tables, quantitative and qualitative attributes of the tables and the restaurant floor plan and booking constraints, such as the number of people, booking time, requests etc., are used to select the representation of the table(s) with a shape, size and associated attributes that is/are capable of being allocated within the restaurant floor plan to meet the booking via a selection of a location in the restaurant floor plan for the booking);
when the representation of the object is placed within the representation of the area, allocating the request to the representation of the object within the representation of the area (when the representation of the table is placed within the restaurant floor plan, allocating the booking to the representation of the table within the restaurant floor plan);
iterating the allocation processing of requests until the representations of objects have been allocated within the representation of the area such that all the requests in the new pool of ranked requests have either been allocated, or attempted to be allocated, to the representations of objects within the representation of the area at the defined time (repeating the allocation processing of bookings until representations of tables have been allocated with the restaurant floor plan such that all the bookings in the new list of ranked bookings have either been allocated, or attempted to be allocated, to the representations of the tables within the restaurant floor plan at the defined time);
wherein if all the requests in the new pool of ranked requests are allocated, producing a new allocation instruction set utilising the allocated requests (if all the bookings in the new list of ranked bookings are allocated, producing a new allocation instruction set utilising the allocated bookings);
wherein, if the allocation process does not result in the allocation of the representations of objects to accommodate the request within the representation of the area, the request becomes a conflicting request in the new pool of ranked requests and the method further comprises (if the allocation process does not result in the allocation of the representations of the tables to accommodate the booking within the resultant floorplan, the booking becomes a conflicting booking in the new list of ranked bookings and the method further comprises) :
unallocating one or more previously allocated requests from the new pool of ranked requests (unallocating one or more previously allocated bookings from the new list of ranked bookings),
iteratively continuing the allocation process commencing with the conflicting request in the new pool of ranked requests until allocation of all of the requests in the new pool of ranked requests has completed, and producing a new allocation instruction set utilising the allocated requests (repeatedly continuing the allocation process beginning with the conflicting booking in the new list of ranked bookings until all of the bookings in the new list of ranked bookings have been allocated, and producing a new allocating instruction set utilising the allocated bookings);
wherein, if the allocation process has completed such that, all the requests within the new pool of ranked requests have been allocated except the request, or an alternate request to the request has been allocated or the request is cancelled or expired, the method further comprises (if the allocation process finishes such that all bookings in the new list of ranked bookings have been allocated except the booking, or an alternate booking to the booking has been allocated or the booking is cancelled or expired, the method further comprises):
removing the request from the new pool of ranked requests, and producing an allocation instruction set utilising the new pool of ranked requests without the request, utilising the allocation instruction set to create the dynamic representation of the area representative of the allocated representations of the objects in the representation of the area, and the allocation of the requests to each of the allocated representations of objects (removing the booking from the new list of ranked bookings, and producing an allocation instruction set utilising the new list of ranked bookings without the booking, utilising the allocation instruction set to create the dynamic restaurant floor plan representative of the allocated representations of the tables in the restaurant floor plan, and the allocation of the bookings to each of the allocated representations of the tables;
saving the allocation instruction set in the database; and
transforming the allocation instruction set to provide instructions for the real-time or future-time visual display of a multi-dimensional image comprising the representation of the area showing the shapes, relative sizes, positioning and attributes of the representations of the objects within the representation of the area at the defined time (transforming the allocation instruction set to provide instructions for the real-time or future-time visual display of a multi-dimensional image comprising the restaurant floor plan showing the shapes, relative sizes, positioning and attributes of the representations of the tables within the restaurant floor plan at the defined time).
37. The stated advantages and effect of the invention, in the context of restaurant bookings, is suggested at [00157] to [00160] and [00190]:
“[00157] Firstly, with regards to tables our claimed invention uses its spatial knowledge of the restaurant premises to create tables as required by the bookings received. As such, it can add or remove tables from a restaurant's standard floor plan. From that perspective our first dimension can be said to be the restaurant floor plan (length and width) properly dimensioned and to scale with all objects in correct relativity. Then secondly, time is used as the other dimension to turn our two dimensional floor plan from a single flat plane to a volumetric cube by introducing time as the other axis.
[00158] The claimed invention utilises, in contrast, a decision tree logic structure which seeks to find a ‘pathway’ to a solution that it creates that not only optimises the allocation of bookings to tables, but also seeks to optimise the placement of tables. In effect, the claimed invention optimises the number and placement of tables for the number of bookings, rather than simply trying to allocate bookings to a predetermined fixed number of tables and table combinations which have no spatial relationship to each other.
[00159] In addition, the decision tree is dynamic, in that the decision tree does not merely provide a series of ‘yes/no’ gates, but rather, if as a consequence of the constraint information, a sub-optimal solution is provided, the claimed invention is able to iterate with varied conditions, in an attempt to create an optimised solution for the restaurant and the client
[00160] Fourthly, as a corollary, the claimed invention does not require the input of tables and table combinations, as the starting premise for the claimed invention is not a predetermined number and/or layout of tables and table combinations. Rather, the claimed invention, upon receiving relevant constraint information, is tasked with not only allocating a booking to a table, but also allocating a table to an appropriate location in the space to achieve both qualitative and quantitative outcomes:
1.The claimed invention provides dynamic allocation of bookings, which may be optimised for a mixture of both quantitative and qualitative outcomes. This is achieved by the use of ‘spatial awareness’ algorithms. Examples of the quantitative and qualitative outcomes include:
i.Quantitative Outcomes include:
a) Optimising one restaurant space before another restaurant space;
b) Optimising the whole restaurant and different spaces at the same time; and
c) Allocation of a booking to a specific table.
ii.Qualitative Outcomes include:
a) Allocating bookings to the ‘best’ tables;
b) Leaving an empty table between bookings when the restaurant is not full to give bookings greater privacy; and
c) The allocation of a SVIP [Super Very Important Person] to their preferred table.
2.Moreover, as the algorithm has knowledge of the space and the furniture within the space, bookings can be allocated in a completely autonomous manner. In the description, it is clearly shown the underlying feature of ‘spatial awareness’ allows completely autonomous restaurant management system from the time of the online restaurant booking request until the time a person leaves the restaurant other than the physical aspects of cooking the food, delivering the food and beverages to the table and cleaning and resetting a table.
3.The restaurant may also selectively choose the level of automation they wish to use within their restaurant. Hence the claimed invention can cater for anything from a casual cafe to a three Michelin star restaurant so no limitations or barriers exist in its industry applicability.
4.As the claimed invention has knowledge of the space, the invention can be utilised to optimise for almost any relevant desired outcome, whether it be revenue optimisation, cost minimisation or maximisation of the customer experience.”
…
“[00190] The claimed invention defines a properly constructed ‘three dimensional volumetric relationship’ using the floor plan (two dimensions) and time (as the third dimension). As such, there are no requirements to use scheduling software techniques to incorporate time within the claimed invention.”
38. It is probably worthwhile here to summarise the nature of the invention as claimed, noting that this is reflected in the two aspects provided at paragraphs [00128b] and [00128c] of the specification. The invention as claimed, may be broadly understood as a way to autonomously and iteratively allocate objects at a defined time in a virtual space that contextually represents an area, where the objects are used to achieve/facilitate requests associated with the objects in the virtual space at the defined time. The manner of allocation provides for ranking of requests using various dynamic attributes or categories, and the use of constraints including relationships between the objects and the virtual space and for allocation of the requests to arrangements of objects based on those rankings and constraints. The process of allocation is iterative, is based on the use of decision trees, and involves deallocating requests to try and satisfy all requests or removing a conflicting request from the allocation process where there are unallocated requests. The virtual space is displayed with the relevant representation of the objects as they should appear at the defined time as a result of the allocation process. It is apparent that the allocation process allows, effectively, for the use of virtually any attribute, in addition to dimension constraints, so as to have an allocation process that is able to achieve desired outcomes or objectives (see [00160] as quoted above), although I note that the actual achievement of such outcomes or objectives does not appear in, or is necessarily a result of, the claims as such – much depends on the precise nature of the constraints.
39. As noted, the remainder of the summary/consistory statements from [00129] to [00336] cover a variety of aspects or embodiments beyond the claimed invention discussed above. These paragraphs read like a laundry list of factors, methodologies or functionalities that are simply performed using technically non-descript computing technology i.e. using standard computing abilities or techniques. While, as noted, the invention is not necessarily limited to use in a restaurant, the further aspects/embodiments largely cover a multiplicity of factors, methodologies or functionalities that account for virtually anything that could specifically feed into achieving the desired strategy or optimisation of a restaurant; that is the discussion of the further aspects, methodologies and functionalities is largely limited to restaurants. However, I note that the apparent intention is for the invention to apply more broadly to “venues” in general. Although made in connection with discussion of preferred embodiment, this is perhaps highlighted by [00371]:
Therefore, for the avoidance of doubt, in the embodiment described, the term ‘booking requestor’ is a broader term for a person or entity interacting with the embodiment to make a booking request. Once a booking request is allocated, the booking requestor becomes a ‘customer’, ‘patron’ or ‘diner’ of the venue. In the example embodiment, the term ‘restaurant’ is utilised as a proxy for the term ‘venue’, insofar as a restaurant is a practical example of a venue. The terms ‘space’, ‘sub-space’ and ‘section’ refer to specific delineated areas of the venue. The term ‘allocated portion’ refers to the specific area within the venue that is allocated to the booking requestor. In the ‘real world’ example embodiment described herein, the ‘allocated portion’ may be a table, a series of tables, a seat (such as a chair or a barstool) or may simply be a physical space, devoid of specific furniture. Therefore, where reference is made to customer being allocated a table, table combination, a seat, etc., the reader is to interpret this reference as a specific example of a booking requestor being allocated an ‘allocated portion’.
40. Whilst a plethora of factors, methodologies and functionalities are given at [00129] to [00336], I consider that these can be summarised as follows:
· customisation/input of the restaurant floor plan to scale, including the spaces, subsections, tables, chairs etc. therein;
· generating or inputting various parameters, constraints or information (including in some instances, how these are inputted or generated) that affect or impact how the restaurant operates or how a restaurant service is delivered, such as:
o customisation/input/restriction of menus based on space, subspace, class, day, meal period, group size, occasion, request, dates, service etc.;
o restricting/offering certain booking times, durations, sizes or seating periods based on constraints, such as the menu, courses per menu, day, group size, occasion or service time e.g. breakfast, lunch or dinner, peak times etc.;
o the time needed to prepare and reset a certain space or tables;
o different seating periods allowed at certain times;
o events held by the restaurant;
o table numbers or table position numbers;
o object or furniture information or constraints, including by each space, subspace, section etc., for example which types of tables and table tops are interchangeable, numbers and sizes of tables and chairs, fixed or removable furniture, what objects can be moved, re-arranged or added to or removed, the sizes of each space, subspace, section; the relative location of tables and table combinations etc.;
o seating priorities for booking in different spaces or subsections etc.;
o the space between tables for different bookings by subsection or class;
o different space, subspace or section constraints, including subdivision of spaces etc. into subspaces with their own constraints, so that iterative allocation and prioritisation of each subspace or section in a venue can be optimised independently or with other subspaces;
o information on third party services that may be requested as part of the booking e.g. the services of florists, entertainers may be selected and booked as part of the booking request;
o time and/or date constraints regarding when a space, section, class, table etc. is available;
o creating rankings or classes associated with spaces, subspaces, sections, tables (see figure 5t at annex A to this decision for an example of table rankings) etc. with potentially different services, service levels, menus etc. or prioritisation being provided based on the rankings or classes, for example so that VIPs get better tables (see figure 5u at annex A to this decision for an example of customer ranking rules);
o locations, sections, subspaces etc. are allocated a dynamic identifier so that all tables are sequentially numbered consistently irrespective of table reconfigurations; and
o matching booking requestor information with venue constraints to offer the booking requestor possible options in view of their requirements and plans to add or remove objects to personalise their experience;
· allocating or iteratively allocating bookings/requests based on various methodologies, factors or constraints, for example:
o using customer information to allocate online bookings;
o the time and/or space available for allocation in a venue;
o to the requested table(s);
o to tables using constraint information to create a particular ambiance in a space e.g. based on a customer’s social media profile or upgrading to better tables when these are not predicted to be required;
o in order of largest number of seats required for a seating period;
o allocating or reallocating tables based on constraints/ranking of the booking requestor relative to other requestors or such that ranking of the requestor determines allocation, e.g. reallocating a previously booked table to someone if their rank exceeds that of the person who currently holds the table booking;
o reallocating bookings based on qualitative booking constraints including: the occasion, menu or courses selected, products selected and date of the booking;
o if reallocation is required, reallocating in descending booking size or a size metric;
o ranking booking requests by a difficulty metric;
o based on booking size and whether they fall across or not a sub-service period in a service period;
o reallocating bookings to optimise use or other outcomes, for example to optimise bookings in one or more spaces, grouping bookings of similar size together, minimising unused table time, minimising table movements in a service period, to facilitate reuse tables for later bookings;
o allocating a potentially conflicting booking to the smallest fitting table regardless of availability and reallocating a previously allocated booking if a booking conflict arises;
o use of customer information and third-party databases to rank booking requests, for example use of CRM information (e.g. customer membership level, VIP status etc.) from internal or external databases to allocate bookings to higher ranked, more regular or potentially beneficial customers;
o allowing a user to select a preferred table, booking time, duration and payment of an additional amount;
o filtering available products so that they are only shown to certain customers, e.g. based on a customer ranking; and
o menu information, including number of courses and the times that menus are offered;
· booking requests/options include:
o the ability to personalise their booking request with, for example, a personal waiter, flowers, menus, entertainment etc., with the system potentially able to automatically place orders with the restaurant and/or third-party suppliers to facilitate the personalisation;
o different algorithms being used for bookings before and during a service, with no new tables being brought into an area while the service is in progress;
o dynamically varying options offered to a customer, such as menu or booking size, to optimise revenue or allowing the input of further restraint information to allow a user to accept those further restraints or alter their request;
o allowing a user to search and book/pay for two different available spaces in a venue or two different venues, e.g. the bar and a dining area or a theatre and a restaurant;
o searching a restaurant’s availability by menu, courses, group size, tables with guaranteed allocation or system specials to fill difficult times;
o allowing a user or remote user to select an item from a menu to be consumed during use of a space, section, class, table etc.;
o based on including the provision of products, for example the number of courses from a menu, a menu item, a beverage, third party items like flowers or combinations thereof; products may have certain attributes or associations, such as with a specific service period, booking time, day, group size, level of service, class of tables etc.;
o determining table availability based on qualified product information;
o a pre-payment decision tree to determine if pre-payment is required based on, for example the time or day of the week or menu;
o proposing an alternative booking request based on past alternative request data, potentially based on the frequency of acceptance of the alternative request, with incentives to accept the alternative and/or proposing alternatives until the request is abandoned;
o allowing a booking requestor to determine the seating position of their guests;
o allowing a booking requestor to invite guests to pre order and prepay for selections; and
o where a venue has one or more spaces, determining if a booking request can be categorised into one or more categories;
provision of a pricing grid for different plans and possible personalisations;
allowing a user to enter further restraint information in response to restraint information provided by the user, with acceptance of the additional restraint information or altering of the request;
provision of an app showing an allocated table location/number within the restaurant, which may provide for self-seating functions that can direct a user to a table;
the use of historical performance data or simulations to improve the performance of spaces, sections etc. or to optimise restaurant layout;
allow for the optimisation of constraints, iterative allocation of bookings, definition of spaces, subspaces, classes etc. in the restaurant, the offering of different menus in different times/occasions, allocation of SVIPs to preferred table and table ratings;
an optimised allocation instruction set is saved in the database and provided as a diagrammatic representation within a detailed representation of the floor plan – new tables, spaces etc. may be highlighted; in one embodiment the saved allocation set changes dynamically over time, so that the table allocation representation shows the floor plan on a user interface as it would appear at any point in time;
adjusting pre-payments received by a restaurant so as to maximise commitment to a booking, including having pre-payment requirements tailored to the user’s booking request;
calculating and collecting information regarding the duration times of customers and associating these with relevant constraint information. The constraint information can include menu, menu courses, time of booking, day of booking, occasion, and group size;
comparing system scenarios with manual interventions to determine which provides a better outcome, for example when using a CRM or customer social media profile or regarding restaurant capacity;
providing additional information, such as forecasted weather and future events to predict demand for a space, subspace, section etc., and using this to adjust options offered, e.g. menus;
using previous utilisation patterns and other constraints to forecast demand, revenue and autonomously adjust capacity and constraints, to predict probable desired outcomes, potentially using AI, or calculate resources needed;
dynamically varying constraints or factors, for example product costs or other pricing based on time, promotions, booking duration, space, section etc.;
accessing, performing or using the functionalities, the methodologies etc. via remote devices or other interfaces for example a restaurant management page;
· performing the functionalities, the methodologies etc. generally with a view to optimising an outcome, efficiency strategy, revenue or yield of the restaurant whilst also potentially meeting customer needs or personalisiations, for example:
o offering promotions for unbooked periods that allow for consumption of a one course menu or using yield management algorithms using capacity generated by space and time calculations, calculating revenue yield, restaurant utilisation etc.; and
ovarying offerings to booking requestors based on the revenue/desired outcome that can be achieved at certain times;
performing the functionalities, the methodologies etc. autonomously, for example communicating a need for extra furniture or other items or via an integrated booking and management system that connects to other systems, such as rostering systems, POS, kitchen interfaces, home delivery systems; and
comparing information from other restaurants.
41. The detailed description of the preferred embodiments extends from [00361] to [00815] ([00337] to [00360] essentially list the drawings and provide a brief description of each of these). It is worthwhile reproducing [00366] to [00369] from these paragraphs as they outline what are said to be the advantages of the invention as described:
“[00366] Embodiments of the present invention use a knowledge of the dimensions of the space and what the Applicant has dubbed a ‘volumetric’ algorithm to optimise capacity and revenue within a single venue or a multi-venue restaurant environment that can include diverse operations such as fine dining, casual dining, cafes and cabaret shows. The system has an encoded algorithm which avoids the inherent constraints in prior art solutions. All known prior art solutions are based on allocating booking requests to a set list of tables and table combinations using simple look-up formulas. In a static allocation model, allocation consists simply of finding the first available and suitable table in the set list. In so called ‘dynamic’ solutions, combinatorial constraint programming is used to allocate each booking request to a table or table combination. Combinatorial constraint programming, while theoretically possible, is not practical, as it is not computationally efficient and therefore is not workable in the ‘real world’.
[00367] In broad terms, one primary difference between the embodiments described herein and prior art is that the embodiment defines the problem to be solved as the ‘optimisation of the use of a space’ using both quantitative and qualitative constraints as compared to the prior art, that has defined the problem as the ‘management of tables’ with prior art algorithms relying on the selection of the best fit table or table combinations from a predetermined list of tables and table combinations to which a previous booking has not been allocated.
[00368] By defining the problem as the ‘optimisation of the use of a space’ and using volumetric algorithms with quantitative and qualitative constraints to solve the allocation problem of finding the optimal table or seating location for each booking requestor, the embodiment provides an autonomous system which not only allocates booking requests in a much more optimal manner (since it can ‘weigh’ and optimise for a series of complex desired outcomes) but also operates across the entire experience of the booking requestor, from the time a booking is requested, to the personalisation of the experience at the venue, until the service has been completed and the bill paid. In the proceeding description of an embodiment, for the ease of reference, the complex set of desired outcomes that a venue wishes to deliver to a booking requestor (customer) will be referred to, in short form, as the ‘utility’ derived by the customer from the booking.
[00369] By defining the problem as the ‘optimisation of the use of a space’ embodiments of the invention provide a fundamentally different conceptualisation of the problem to be addressed, in that, in optimising a restaurant, there are many more considerations than the random allocation of booking requests to predefined tables and table combinations. To provide a specific example, a well-run restaurant, if it is to maximise yield and grow customer loyalty, has to determine how to best use the space available, which includes the ability to allocate booking requests to tables in a manner that takes into account other aspects of the dining experience, such as the ambiance within the restaurant, the allocation of a person to their preferred location or table, the distance between tables (which impacts on desirable qualities during the dining experience such as privacy), the ability of the restaurant to offer different menus at different times and at different prices to the same or different areas within a restaurant, allowing diners to extend meal period times without causing strain on available resources or conflicts with other bookings, offering different menus, offering personalisation to achieve the individual requirements and strategies of different venues and restaurants in a way that also better meets customers' requirements and demands. As such, the ‘volumetric’ algorithm described and defined hereinbelow is unique in that the algorithm utilises quantitative and qualitative criteria to provide an integrated and autonomous restaurant management system.”
42. The discussion from [00361] to [00482] largely reflects, and indeed in parts appears to merely repeat, the summary of the various aspects outlined above, albeit with some further details and further various options at some points. There are, for example, subheadings for “Space Management and the Optimisation of Outcomes”, “Customer Relationship Management”, “Dynamic Floor Plans”, “Menus, Courses, Duration Times and Group Sizes (Variable Products)”, “Variable Pricing”, “Booking Request Personalisation”, “Yield Management”, “Self-Seating, Pre-orders, Venue Orders and Point of Sale Systems”, “Function Diary Integrated with the restaurant Diary”, “Dashboard for the Reservations System and Diary”, “Rostering and Scheduling System”, “Purchasing System”, “Booking two Venues at the Same Time”, “Restaurant Table simulator and Table Configurator”, “Home Delivery, Take-away Order and Pick-up”, “Gift Certificates”, “Alternate Options”, “Marketing and Promotion”, “Customer Interaction”, “Table and Table Combination Categories” and “Table and Table Combination Threshold”. I did not see anything here, however, that otherwise materially reveals more about the invention described than as summarised above, particularly in terms of the technical means used to achieve the various outcomes, functions and aims of the invention as described.
43. There then follows, at [00483] to [00495], under the subheading “The Computer System” a discussion of a computer system “…for use with an embodiment of the present invention” (at [00484]). Given the plethora of embodiments this wording is rather curious, however it does seem that the computer system discussed, probably not least due to its generic nature, is generally capable of achieving any of the embodiments described. The computing system 100 is discussed with reference to figure 2a, which is reproduced below.
44. The computing system 100 comprises a processor 102, a read only memory (ROM) 104, random access memory (RAM) 106, input/output devices 108, for example a disk drive, connected devices 110, such as computers, smartphones, laptops etc., communication links 114, such as the internet including to cloud computing services 120. The computing system 100 may also comprise a database 116 stored on storage device 112. Unsurprisingly the computing system 100 also comprises an operating system 118. This is said to interact with the database 116 and with one or more computer programs to carry out embodiments of the invention as described. In particular, the computing system 100 can be used by booking requestors to make a booking request using connected devices 110, with instructions potentially being sent to the restaurant/venue/entity concerned.
45. Figure 2b, reproduced below, illustrates in more detail the architecture of a computer system implementing an embodiment of the invention as per what I understand to be the “ResButler” system.
46. The ResButler system 2048 comprises a back end existing within cloud computing environment 2046. The cloud computing environment 2046 includes: a security database 2040; an allocation system 2042; a system web server 2056; venue databases 2058 and venue web server 2074. The allocation system 2042 in turn comprises modules 2044, with each module comprising specific allocation algorithms.
47. A venue can access the ResButler system 2048 via system web server 2056. Remote access to a dashboard 2052 and POS 2054 is provided to device 2050 by the ResButler system 2048. Booking requests can be made via conventional computing system 2060, mobile device 2066, or onsite kiosk device 2070 (which may also be a mobile/tablet device). Conventional computing system 2060 can access a venue website 2062, comprising a booking widget 2064, to make booking requests. Mobile device 2066 can use an app 2068 to access the ResButler system 2048 and request a booking. Similarly, onsite kiosk device 2070 allows onsite booking requests or self-seating for walk in customers via a kiosk app 2072.
48. More details of how the invention described, in the form of the “ResButler”, is carried out in computing systems commences at [00496], under the subheadings “The Computing Method” and “Space Information and Constraints”. The discussion proceeds by way of figure 2c, which is reproduced below.
49. Figure 2c illustrates a flow chart undertaken by computer system 200 in carrying out “…the optimal allocation of a user request to use a space” ([00496]). I take the computer system to be commensurate with the systems/architecture outlined on figures 2a and 2b. I note that some of the arrows on the flow chart do not seem to reflect the process as outlined in the specification, but this does not appear to be material to understanding the way the invention described works.
50. The flow chart begins with a user (potentially a customer) making a request 202, this either being taken by an interface of a ResButler web portal 204, or via a third-party booking system 211 which sends the request to a ResButler Email Parser 213.
51. From either the ResButler web portal 204 or the ResButler Email Parser 213, the user request 202 is then routed to an input receiving module 206 of the ResButler interface. The input receiving module 206 turns the user request 202 into a string of data which is then sent to the ResButler Optimisation Algorithms (i.e. optimisation module) 208. The ResButler Optimisation Algorithms 208 is in communication with a ResButler Restaurant Database 212. The ResButler Restaurant Database 212 may have stored the string of request date prior to processing by the ResButler Optimisation Algorithms 208, and otherwise comprises information on the user request or previous requests.
52. The ResButler Restaurant Database 212 may also comprise other data. Broadly speaking, these, as discussed within [00496] to [00535], include constraints and other information/data of the venue and the booking requestor of the types as discussed earlier this decision (for example the ranking/status of a booking requestor, space or subspace information, table dimensions etc.) and that may be used as part of the optimisation process. I see no need to go into or list the plethora of such constraints again.
53. A variety of other potential steps or processes are apparent from figure 2c. These include External Web Data 215, ResButler Applications 217, ResButler Processes 219 and External Systems 221. Further detail on these is provided on figures 2e and 2f, which are reproduced at annex B to this decision. These allow for the input of further constraints or variables that can be used in the allocation process (e.g. the weather 266 or social media 268) or provide for extra functionality (e.g. kitchen printing app 226 or Home Delivery App/Widget 236).
54. As observed at [00506], “The algorithm includes a number of steps to determine the optimal use of the space – the steps of the algorithm are described in more detail later”. This appears to begin, at [00536] to [00552] under the subheading “Optimisation module/Algorithms”, with reference again to figure 2c. The ResButler Optimisation Algorithms 208 are said to use the processor 210 to query the ResButler Restaurant Database 212 to see if other booking requests for spaces have been made by other requestors. These requests are then retrieved by the ResButler Optimisation Algorithms 208 and combined with the user request 202 into a pool of requests. Venue constraint information is also retrieved by the ResButler Optimisation Algorithms 208 from the ResButler Restaurant Database 212. Those constraints can be edited by venue operators using restaurant interface 218.
55. At the risk of being somewhat repetitive, the general way in which optimisation occurs is perhaps best expressed at [00537]:
“The optimisation module 208 uses the processor 210 to iteratively allocate all requests from the pool of requests utilising the venue constraint information and the requestor constraint information. All requests in the pool of requests are allocated to produce an optimised space allocation instruction set 214, in accordance with the venue and requestor constraint information. That is, with each new request, all previous allocations that have been determined become past optimised space allocation instruction sets. The past sets are saved in the database 212. With a new request, all previously accepted requests in the pool of requests are iteratively re-allocated to produce a new optimised space allocation instruction set that includes the current request.” (labels bolded; I note there is a difference in nomenclature between the specification and figure 2c, e.g. optimisation module 208 as opposed to ResButler Optimisation Algorithms 208, however these differences are not material)
56. As discussed at [00505] to [00507], the ResButler Optimisation Algorithms 208 may also undertake an iterative allocation of user requests 202 so as to optimise the use of spaces/subspaces in the venue, individually or in combination, using the user request information and constraint information from the ResButler Restaurant Database 212 (note an example of a venue floor plan comprising different spaces and subspaces is outlined with reference to figure 4e at annex C to this decision).
57. As indicated at [00538] and [00539]:
“…The space allocation user interface 216 displays at least one optimised space allocation instruction set 214 to one or more operators associated with the restaurant 218. The optimised space allocation instruction set may be represented on the user interface of the restaurant 218 as an interactive digital scaled-map representing the position of specific objects, such as tables, and the arrangements and combinations of those objects within the space. The interactive digital scaled-map may be modified by one or more users associated with the venue. Alternatively, the optimised space allocation instruction set may be generated as an image, Gantt chart, documented instructions or any other manner of representation that illustrates to an user the optimised arrangement of objects in a space.
The allocation module 208 may also include a predicative module 220 that allocates booking requests at least in part on the historical data stored in the database 212. The predicative module 220 utilises the processor 210 to predict an optimised space allocation instruction set based on past data using regression analysis techniques or any other mathematical algorithms which identify relationships between past dependant and independent variables and match them to current variable data to extrapolate an optimised space allocation instruction set to accommodate the at (sic) booking request.” (labels bolded; again the differences in nomenclature are not material)
58. A rather general outline of how a booking request may proceed in line with the invention described is provided by figure 3, which is reproduced below. Whilst rather general, figure 3 does not necessarily demonstrate the broadest form of the invention described. It does however provide a convenient overview of many of the core aspects of how the invention as described works. Figure 3 is largely self-explanatory, so I have not provided any extensive discussion of this figure. Suffice to state as per [00574], which discusses figure 3:
Firstly, these statements clearly confirm my earlier view that Bossert and Vidotto were solving a different problem to the one solved by the application. This reinforces the view that comparisons between these items of prior art and the claimed invention, in terms of technical limitations, is fraught at best.
Secondly, due to the lack of details that go to providing an objective understanding of the alleged technical superiority of the claimed invention (i.e. efficiency and computational tractability), as discussed above, I do not consider that the “re-working” of the problem in the manner suggested by the Applicant in any way necessarily leads to solving a technical problem within or without the computer. Because of this, and because of the nature of the invention described, it seems to me that the problem that the claimed invention is solving with respect to the prior art is the very fact that the prior art does not factor in all the relevant constraints that one should take into account in seeking to allocate requests to objects. Merely adding or providing for these constraints may make for a better allocation process and is thereby better in a logistical or business sense but does not result in the claim solving a technical problem. Similar can be said for doing so without meeting any exigencies to provide for the operation of the claimed method.
Thirdly, it is not clear to me, even assuming for arguments sake only, that the Applicant’s assertions concerning the computational tractability of Vidotto and Bossert are correct, that there was or is a technical issue that has in fact been solved by re-defining the problem in the manner suggested by the Applicant or in the claimed invention per se. As asserted by the Applicant, Bossert and Vidotto were seeking to solve different problems to the present invention. The Applicant appears to be assuming that, even if Bossert and Vidotto were to attempt to create a rather more thorough allocation process that takes into account all the relevant constraints (similar as for the claimed invention) or sought to re-define the problem in the same way as alleged by the Applicant, that Bossert and Vidotto would simply persist with means said to be ineffective by the Applicant for this purpose, when it seems prima facie reasonable to believe that there are other means available in the art and known to the PSA that would be better suited and liable to be tried. This seems rather unlikely to me, given that techniques to handle multi-dimensional data were well known before the priority date. I do note the Applicant’s submissions at various points in the Exam Responses and the written and oral submissions about the long felt need in the art and problems in the art, the alleged ongoing failure to address these and the suggestion that benchmarking against the prior art is unnecessary to highlight a technical effect, however the lack of any objectively discernible technical effect or improvement in the claim undermines these submissions. As noted, I remain unconvinced that the Applicant has actually overcome any of the difficulties concerned using technical means.
In the written submissions at [54], the Applicant was at some pains to distinguish the claimed invention from F45 Training Pty Ltd v Body Fit Training Company Pty Ltd (No 2) [2022] FCA 96; 403 ALR 269 (“F45”) in terms of there being a technical solution to a technical problem:
“In the Fifth Examiner’s Report, the Examiner makes a reference to the ‘F45 decision’ F45 Training Pty Ltd v Body Fit Training Company Pty Ltd (No 2) [2022] FCA 96. The ‘F45 Decision’ relates to a relatively basic invention in which pre-prepared information program files are communicated to a studio computer to enable the exercise stations to be configured as well as communicated over a network to provide directions to users for performing exercises. Whereas, the pending claims of the Application relate to a technical solution to a technical problem, of which multiple technical examples have been provided in the Second Response and the Third Response. In addition, the pending claims of the Application provide detailed technical steps including, for example, how to generate and modify a pool of requests, the iterative allocation of the requests using a dynamic decision tree allocation process as well as the use of constraint information in the dynamic decision tree allocation process. Further, the claims of the Application define the technical steps taken to determine how the allocation process proceeds in the event that the allocations are not fulfilled as well as the technical transformation of the data (i.e. the allocation instruction set) to provide instructions for the real-time or future-time visual display of a multi-dimensional image comprising the representation of the area showing the shapes, relative sizes, positioning and attributes of the representations of the objects within the representation of the area at the defined time.”
At the hearing, Mr Tucker further distinguished the claimed invention from F45 on the following basis:
“So the F45 claims were very, there's nothing dynamic about them that it was they just sent instructions of how to set up an area for training, there's there's no feedback loop, there's no decisions being made. It was just someone requests information and it gets sent over the over the Internet. There were no detailed technical steps. You know, we have in our claims, we have all these technical steps of, you know, how to generate and modify a pool of requests. Got the iterative allocation of those requests using a dynamic decision tree allocation process. And also the constraint information that's part of that process. And so the technical steps define, you know, how the allocation process proceeds in the event of something happening, such as not being able to find the result in the allocation of all the objects, or realising that one one of the requests hasn't been allocated and each time that you…these requests come in the actual allocation instruction set would change, and you'd get a display at different times, so each time a new request would come in, the display would change again. So it's not just a static piece of data being sent over a network to a computer. It’s constantly changing based on as each request comes in, and that's that's very different to the F45 invention.”
The problem with these submissions for the Applicant is that I do not consider that there are any technical effects or steps in the claim that distinguish the claimed invention from F45 that lead to a technical solution to a technical problem. Differences in terms of iterating the allocation of requests simply reflects the steps of the scheme for allocating objects as discussed above, and having the allocation updated and displayed in real time merely makes use of the well-known properties of computers to process and display data in real time. Obviously, the claim here is different to those in F45, but as noted, those differences do not assist the Applicant in terms of establishing patentability.
In summary, I do not consider that the claimed invention solves a technical problem either within or without the computer.
Is there an improvement in the functioning of the computer, irrespective of the data being processed?
I cannot ascertain any improvement in the functioning of any of the computerised features used within the claim, irrespective of the data being processed. As discussed above, the computerised features present in the claim are merely used for their standard or known abilities to process, display and store data. Any improvement, to the extent one can be identified, appears to reside in the fact that the claimed invention can take into account any and all relevant constraints that might impact the effective allocation of requests to objects in a physical representation of a space.
In summary I consider that there is no improvement in the functioning of the computerised features utilised in the claim.
To the extent the Applicant has made submissions relevant to this consideration, I am of the view that these have been addressed elsewhere in the context of the other considerations. Other than this, I do note some arguments made by the Applicant concerning IBM which I am of the view are relevant to this consideration and should be discussed here. In this regard, at the hearing, Mr Tucker attempted to draw parallels between the present invention and IBM:
“Although it’s not a mathematical algorithm, it’s the software process that actually improves how a computer is able to allocate representations of objects at a defined time and a representation of an area on the screen. So, there are similarities there between the IBM case and this case in terms of the internal effect in a computer and manner of manufacture.”
In response to my suggestions that the computer is merely being used to display data, as opposed to the case in IBM which led to an improved way to display data per se, Mr Tucker stated that:
“Yeah, it’s not just a display of what's being put on the screen that's the invention. It's how, that is the information is being displayed on the screen and you could...you know it, you know, it's different levels of granularity in terms of of the effects inside the computer. You’ve got the the, the very lower level of, you know, how how do you physically display something on the screen as in IBM with the curve. But also you've got the slightly higher level granularity at computer level, which is still an internal workings of the computer about how the software can actually process data and have it allocated in a particular space or in an area those objects at a defined time.”
The difficulty for the Applicant is that it is quite clear that the Applicant, self-admittedly, has not developed a new or better way of the computer displaying data per se, but rather the alleged benefit or improvement comes from the content of the data to be displayed on the computer. Hence if there is any effect or benefit, it has nothing to do with how display of the data is done, but in how that data is otherwise processed or created to allocate objects prior to its display. The parallels to IBM are non-existent. The processing of the data resulting in the allocation of objects may, of course, potentially provide for a patentable effect, but as discussed previously I do not consider there to be anything patentable in this.
Does the invention require merely “generic computer implementation”, as distinct from steps which are “foreign” to the normal use of computers?
For reasons as discussed above, it is quite clear that all the computerised features of the claimed invention are being used in a generic sense in that use is merely made of the well-known functions and abilities of the same, or of techniques that are well known to be used in processing data in a computerised system. There is nothing in the use of any of the computerised features which is foreign to the normal use of computers.
To the extent the Applicant has made submissions relevant to this consideration, I am of the view that these have been addressed elsewhere in the context of the other considerations. Other than this, I do note, however, that the Applicant provided some submissions relevant to this consideration at pages 33 to 34 of the First Response that I consider should be addressed here:
“Firstly, by definition, ‘using a computer for its well-known and understood functions’ cannot refer to a problem that no one has been able to solve for the previous 16 years using a computer.
Secondly, the existence of a long-felt need that has not been able to be solved using a computer, by different people from different backgrounds and different skills and expertise cannot subsequently be a problem solved by ‘using a computer for its well-known and understood functions (sic).
Alternatively stated, if the solution was through ‘using a computer for its well-known and understood functions’ then there could not be an outstanding long-felt need.
As such, for the solution to remain unsolved, it could only be because whatever the system architecture, software, algorithms, steps, methods and processes that were disclosed by a claimed invention were things that could not have been well-known and understood functions of a computer.
Alternatively stated, the creation of a specific and defined system architecture (framework) with specific algorithms, steps, processes and methods that are completely different to the failed solutions of the prior art to solve a technical problem concerning the limitations of using a computer whether it is solved by changing the hardware or the operation of the hardware or by creating a different system architecture or developing different software to solve the problem by brute force or working around the problem must be an improvement in the computer and not the use of a computer for its well-known and understood functions.
The technical problems that the prior art could not solve are detailed below however include the problems of the prior art related to data and allocation fragmentation, caching and computational efficiency (tractability) and the drawing of dynamic real-time and future-time floor plans…
…The long-felt need for a system and method that could solve the dynamic allocation of booking requests has to relate to steps that that (sic) a computer would not be normally used to perform as no one knew or understood the systems architecture or framework required. Also, no one knew or understood the type of algorithms required or the sequence of steps, processes and methods, as such, the mathematical and logical steps in light of an outstanding long-felt need, it is correct to say under these circumstances that ‘a computer would not normally be used to perform such steps’.
While the applicant readily accepts that the claimed invention utilises a generic computer, the system architecture proposed and the software proposed are certainly not steps that a computer could have taken without the claimed invention as it is these steps that have expanded the functionality of the computer and its well-known and understood functions as they were previously known.”
Some of these are simply rhetorical arguments which do not engage with the meaning of the expression in question as intended by the Courts. The fact that there may be unsolved problems or a long-felt need does not mean that the application has necessarily solved these issues or done so in a way that comprises some technical improvement or does anything other than simply making use of the well-known abilities of computers. The First Response certainly lists many more items of prior art, for example on pages thirteen to eighteen, however the discussion of these and the invention is again at a level that makes it difficult to objectively assess whether the claimed invention is necessarily solving any technical problem or using steps foreign to the normal use of computers. As observed earlier, no objective technical effects or benefits are apparent that meet the exigencies of the logistical method defined in the claim.
I also note the rather more specific reference to other issues, beyond those discussed above, said to exist in the prior art, such as fragmentation, caching and the drawing of dynamic real-time and future-time floor plans. Fragmentation does not appear at all in the specification, while “caching” only appears once, at [00116] as an issue discussed in a passage cited from Vidotto. There is otherwise literally nothing in the application that addresses caching issues whatsoever, either explicitly or implicitly. Whether and how the claimed invention solves any issues concerning caching is entirely mystifying given the lack of any details in the invention claimed or described that would necessarily be understood as providing for such an effect.
As best understood, from pages 5 and 6 of the First Response, and from the specification, fragmentation simply occurs as a result of a first come first seated booking methodology whereby the failure to re-seat previous bookings means later bookings are unable to be accommodated – such a problem does not appear to be technical in nature. The solution whereby the claim iteratively re-allocates bookings to do so is, as discussed above, simply a logistic improvement – it is simply akin to restacking your books on shelves when you receive new books until they all fit in. Similarly, while there is some discussion of dynamic real time or future time floor plans, there is absolutely no discussion of any technical issues that have been addressed to provide for these – it is simply the case that the claimed invention makes use of the well-known abilities of computers to process and display data.
In terms of knowing the steps concerned, it is no answer to questions of patentability to state that you have discovered a better method or process not previously known leading thereby necessarily to steps not normally performed by a computer. This argument is, to my mind, confounding questions of novelty and inventive step with manner of manufacture. Simply expanding the functionality of the computer to make it do something it has not done before (as opposed to doing something that allows the computer to do something it could not do before) does not necessarily lead to patentability (which by coincidence is remarkably similar to the words at [48] of BaVelPay S.L.U (B-67506527) [2022] APO 78); see also Rokt at [98]. It is of no consequence, in terms of manner of manufacture, how novel and inventive a claim may be.
Is the computer merely an intermediary, configured to carry out the method using program code for performing the method, but adding nothing to the substance of the idea?
For reasons as discussed above the computerised features are specified at only a generic level to merely facilitate the storage and processing of constraint data so as to enable the autonomous allocation of objects in view of requests in the manner defined in the claim. That is, they are merely an intermediary facilitating the storage, access and processing of data within the claim and add nothing of substance to the same.
To the extent the Applicant has made submissions relevant to this consideration, I am of the view that these have been addressed elsewhere in the context of the other considerations. I do note, however that some submissions relevant to this consideration were provided at page 30 of the First Response:
“…while the Applicant readily accepts that computer processing speeds have increased threefold between the period 2007 and 2017 as detailed by the Examiner it is not this threefold increase in processing speed that makes the claimed invention work but the ingenuity in the way the technical problems associated with the dynamic allocation of bookings were solved, again, indicating that the implementation of the scheme is doing something more.”
Notably, I have not hitherto discussed the increase of processing power over time. However, I am unable to agree with the suggestion that the alleged benefits have nothing to do with the increase in processing power. This is due to the simple fact that, for reasons discussed above, there is a lack of detail in the claim that would allow me to objectively perceive any of the technical effects and benefits as asserted by the Applicant, irrespective of anything to do with processing power.
What is the substance of the invention in claim 1 and is this patentable?
On weighing up the above considerations, these all suggest that the substance does not reside in any technical features present in the claim, nor in any working interrelationship between these or others features that provide for a patentable effect. Rather, the substance of the claimed invention resides in a method for the autonomous allocation of objects to an area at a defined time that are subject to requests, with the allocation of the objects being undertaken iteratively, when new requests are received, subject to dimensional constraints of the objects and the area and request constraints, thereby enabling, at least, efficient allocation of the objects at the defined time or according to a desired outcome or strategy.
The Applicant identified the substance in the written submissions at [53] by reference to the Second Response:
“An assessment of the manner of manufacture of the claims of the Second Response (at page 3) under the heading ‘Specific manner of manufacture pointers’ and this assessment was not addressed in any Examiner’s report until the Fifth (and final) Examiner’s Report in which the Examiner commented on the stated substance of invention as follows:
‘The substance of the invention is in the use of an iterative process using three-dimensional data to allocate objects at a defined time to an area. That is, the process is effectively restarted every time a new request comes in. By “wiping the slate clean”, i.e. by following the technical steps outlined in the claims using the three-dimensional (area and time) data and constraints, the process more efficiently allocates, where possible, objects at a defined time to locations in the area.’
The reference to ‘wiping the slate clean’ refers to the feature of the unallocating of one or more previously allocated requests from the new pool of ranked requests where the allocation process did not previously result in the allocation of the representations of objects to accommodate the request within the representation area.”
I note that the passage from page three of the Second Response identifying the substance was repeated at page 97 of the Fourth Response. Mr Tucker also pointed to the above passage from the Second Response when I asked about what he considered to be substance of the invention at the hearing.
I did not take the substance as identified by the Applicant as being materially different from the substance I have identified above. I note that the use of three-dimensional data is implicit in the substance as I have identified above.
The remaining question now is whether the substance falls within the bounds of patentable subject matter as established by authority. I consider that it does not. The substance clearly amounts to what I consider to be merely a scheme for iteratively allocating objects to an area at a certain time subject to dimensional constraints of the objects and the area and request constraints associated with those objects. No technical benefit or effect is achieved as a consequence of performing the claimed invention. The fact that this may allow for efficient or optimised allocation of the objects in some manner in an area at a defined time according to the constraints concerned does not change the characterisation of the claim – this is nothing more than a logistic or business scheme. Indeed, schemes for the arrangement of objects, no matter how useful, have long been held unpatentable; see for example W.’s Application (1914) 31 RPC 141 at 142 to 143 and Re ESP’s Application (1944) 62 RPC 87, both cited with approval in Grant at [16], and see also more recently F45 at [49] to [52].
It is apparent that the Applicant disagrees with this characterisation. This much is clear at [45] and elsewhere in the written submissions and as expressed by Mr Tucker at the hearing, in that the claim is said by the Applicant to allegedly solve computational tractability problems that existed in the prior art. However, as discussed above, I remain unconvinced that the claim necessarily resolves the computational tractability issues said to exist in the prior art. In particular, the generality of the computerised technology used, in terms of hardware, software and architecture, the application to any field of arranging any objects in any area subject to effectively any constraints relevant to that field as to be ascertained by the relevant PSA, with technical details of implementation left up to the PSA, elevate the substance to nothing more than the logistic or business scheme I have identified above. For similar reasons it is not clear to me that the reframing of the problem to be solved in the way suggested by the Applicant necessarily resolves the issues of the prior art via technical means, as opposed to simply approaching the issues in allocating objects differently so as to arrive at a more efficient allocation of the objects in an area at a defined time.
Is Independent Claim 13 for a Manner of Manufacture?
Claim 13 defines “An autonomous allocation of representations of objects at a defined time within at least one representation of an area…” in virtually identical terms as for claim 1. Other than being couched as being to the allocation of representations of objects per se, I am unable to ascertain any material difference, in terms of substance, between claim 1 and claim 13. I did not take the Applicant as suggesting that claim 13 is materially different in substance to claim 1. Consequently, claim 13 is not for manner of manufacture for similar reasons as given with regard to claim 1.
Are Any of the Dependent Claims for a Manner of Manufacture?
I have also considered each of the dependent claims. These comprise additional features that amount to adding additional business rules or further logistical steps to the scheme as defined in the independent claims, or other dependent claims, whilst otherwise making use of standard computer technology as follows:
· claims 2 and 14: the objects are tables, and these are represented in the representation of the area;
· claims 3 and 15: the allocation process includes the quantitative and qualitative criteria during the allocation process;
· claims 4 and 16: the request signal is sent by a requestor, with a graphical display of representations of the objects in the representation of the area sent to the requestor to show the area to which their request is allocated;
· claims 5 and 17: representation of the area is for display in one or more area plan windows that comprise at least one of a sub-space and a section, the section comprises a subset of the space or sub-space and the allocation process comprises allocation of a request in at least one of sub-space and a section depicted by one or more area plan windows;
· claims 6 and 18: depicting a time axis on a dynamic user interface, where a time icon is moveable between a first time and a future time on the time axis for changing the dynamic user interface from a display of a first-time area plan to a display of a future time area plan;
· claims 7 and 19: the visual display comprises a Gantt chart;
· claims 8 and 20: storing difficulty metrics and ordering booking requests based at least on one ranking rule, the ranking rule based upon difficulty including a party size constraint and peak time metrics;
· claims 9 and 21: the object is a table, and the area is a floorplan, and further including at least one allocation rule for clustering one or more smaller party sizes around one or more larger party sizes;
· claims 10 and 22: transmitting the request signal from a remote device, receiving an allocation response of a table allocation at the remote device when the allocation process has completed such that all requests in the pool have been allocated except if the response is an unallocated request;
· claims 11 and 23: when one or more previously allocated requests are unallocated from the new pool of ranked requests, advising the requestor that their request could not be allocated; and
· claims 12 and 24: when one or more previously allocated requests are unallocated from the new pool of ranked requests, advising the requestor of an alternate allocation of the object in the representation of the area at a defined time.
I do not see anything in the additional features provided by claims 2 to 12 and 14 to 24 that materially varies the substance of the independent claims. These are simply additional rules or procedural steps specifying how the logistical scheme proceeds or simply involve the transmission of certain data or information when certain conditions are met. These do not provide for any material advantage that would confer patentability. It follows that none of the dependent claims are for a manner of manufacture.
Is there anything within the Application that provides for a Manner of Manufacture?
In addition to there being no patentable material in the claims, my perusal of the application does not reveal anything that, as a matter of substance, extends beyond the invention discussed above, either for the invention as claimed or as described. I conclude that there is nothing in the application, beyond that already considered, that could be claimed to result in a manner of manufacture. Because of this I consider that refusal of the application is appropriate.
Putative Issues under Support, s40(2)(a) and Utility
At the hearing I expressed the view that the claimed invention may suffer from issues concerning support, clear enough and complete enough disclosure and utility.
As is perhaps apparent from the discussion above concerning manner of manufacture, my misgivings regarding support and s40(2)(a) stem from the fact that the claimed invention applies to any area of human endeavour where anything needs to be arranged in an area subject to dimensional constraints as well as any other constraints relevant to arranging the objects subject to requests. In line with my observations above at [155], this leaves much to be discovered, determined, or worked out by the relevant PSA in each art, including navigating any computational tractability issues, before any practical software product can be created. Mr Tucker’s suggestions at the hearing that the relevant PSA would simply know the constraints appears to me to be an optimistic take on a task that in many, if not all arts to which the claim applies, would seem to require a not immodest research project to make the invention work. Even if the constraints could be easily identified, it is reasonable to believe that performing the invention with these in view is liable to incur undue effort and experimentation in at least some fields. The breadth of the claim and the lack of details of implementation lend an inherent air of implausibility regarding there being only routine effort or experimentation required to implement the invention across its entire scope.
With respect to utility, I note that the claims do not necessarily require or result in any form of optimisation, in line with a desired strategy or otherwise. It appears reasonably apparent, in my view, that the promised benefit of the application relates to actually providing an arrangement of objects that leads to optimisation in view of a desired strategy. Hence the fact that the claims do not necessarily achieve such optimisation appears indicative that they do not meet the promised benefit and thereby fail for want of utility.
Consequently, I have grave concerns regarding the claimed invention’s compliance with support, s40(2)(a) and utility, to the extent that, even if I found the claims to be for a manner of manufacture, I would remit the application for further examination of these issues alone. However, as I consider it appropriate to refuse the application for want of manner of manufacture, it is unnecessary to consider these issues any further and I observe that I am not making any formal determinations on support, s40(2)(a) or utility.
Conclusion
None of the claims are for a manner of manufacture. In addition, I see no material in the application that could be made the subject of a claim so as to result in that claim being for a manner of manufacture. I therefore refuse the application.
Dr W.E. Guinea
Delegate of the Commissioner of Patents
Annex A – Example Table and Customer Rankings
581 – table showing characteristics used to calculate table ranking
583 – Table showing relative values given to each characteristic
587 – customer ranking based on rules/attributes
589
– customer ranking based on numerical rankings
Annex B – ResButler Further Functions and Processes
Figure 2e demonstrates further potential options for the ResButler Web Portal 204, ResButler Applications 217 and ResButler Processes 219. These are largely self-explanatory from the figure; however I note that the respective ResButler Processes 219 can obtain relevant information (e.g. supplier information) from a database 256.
Figure 2f demonstrates further potential options for the External Web Data 215 and External Systems 221. Again, these are largely self-explanatory.
Annex C – Venue Spaces and Subspaces
What is meant by venue spaces, subspaces, areas, subareas etc. is best understood by reference to figure 4e. This is reproduced below.
Figure 4e provides a floor plan 401 of a venue 470 that is best understood as a restaurant. The venue 470 includes two spaces: bar 472 and main dining room 474. The main dining room 474 includes three subspaces: the atrium subspace 476, the front room subspace 478 and the colonnade subspace 480. The atrium subspace 476 is itself divided into sections 482, 484, 486, 494, while front room subspace 478 is divided into sections 490, 492. These sections represent areas where objects and tables can be rearranged, whilst the fact that colonnade subspace 480 comprises no sections indicates that all tables in that subspace are fixed.
The figure also demonstrates some constraint information. These include table numbers and class information. For example, in figure 4e standard class is denoted by 481, 483 and 496, premium class by 479 and 498, and luxury class by 477 and 499.
Annex D – Details of Process of “Claimed” Invention 276
Annex E – Details of Prior Art Process 223
Description of elements from figure 2h, where further information beyond the figure is provided from [00556] and [00557]:
3c/2004 User/user interfaces: “Restaurant Booking Widget, Booking Form”.
3d/2006 User requirements used in the booking allocation: “Date, time, meal period, pax”.
3e/2008: Strategic Control of Capacity, Product and Services for Booking Allocations: “Capacity and Max Group Size by booking time interval for a standard time duration”.
4a/2020 Restaurant Set-up Rules: “Open/closed; Meal periods; Floor Plan (not to scale); Seat block-outs; Rooms, Areas, Bars; Tables and table combinations prioritised list; Standard booking time duration”.
4b/2022 Promotional Offers: “Discount by time interval”.
Description of elements from figure 2i, where further information beyond the figure is provided from [00556] and [00557]:
3g/2012 Allocation of Booking Request: “Use of a prioritised list of tables and table combinations to allocate bookings. Prior Art process finishes with this step.”
3h/2014 Dashboard: “Static Floor Plan”
Annex F – Dynamic Booking Allocation Examples – Figures 5a to 5e
Annex G – Optimisation Flowcharts – Figures 6c and 6e
Annex H – Further Details of User Interface
706 – space allocation user interface module
732 – expansion button
734 – optimised space allocation instruction set
736 -subspace allocation interface module
738 – PDR allocation interface module
704 – booking details
708 – diary module
710 – graphical diary module
732 – expansion button
712 – alternative form of graphical diary module
714 – customer walk ins list
716 – red colouring
718 – green colouring
720 – orange colouring
732 – expansion button
722 – urgent message module
724 – email
726 – SMS
732 – expansion button
728 – email module
730 – home delivery orders module
700 – user interface
728 – email module
732 – expansion button
740 – window pop out (on expansion)
700 – user interface
701 – revenue yield
702 – restaurant summary and revenue module
703 – seat utilisation
715 – efficiency
742 – new restaurant summary and revenue window (by clicking on button “Rev & Util” (not shown))
700 – user interface
744 – new reservation window (by clicking on user booking 704)
746 – seating allocation plan for user booking 704
748 – run sheet showing timing of guest experience for booking 704
750 – patron contact details for booking 704
752 – function details for booking 704
754 – payment status of booking 704
756 – log of actions regarding booking 704
806 – booking reference details for booking 704
745 – function window
747 – optimised space allocation instruction set
748 - run sheet showing timing of guest experience for booking 704
750 – patron contact details for booking 704
752 – function details for booking 704
754 – payment status of booking 704
756 – log of actions regarding booking 704
793 – function confirmed button
806 – booking reference details for booking 704
758 – new reservation window (by clicking on booking 704)
760 – seating or guest allocation
762 – guest list of patrons
764 – menus selected by patrons
766 – restaurant butler request
768 – CRM module (inferred, not actually given in the specification)
770 – payment status of booking 704
806 – booking reference details for booking 704
Annex I – Further details of User Interface 800
800 – user interface
838 – entrée course
840 – main course
842 – side dishes
844 – patrons/total guests
846 – add to cart button
800 – user interface (but would appear to more correctly be part of user interface module 808)
801 – print/email/create event on social media (inferred – is not mentioned in specification)
844 - patrons/total guests
800 – user interface (but would appear to more correctly be part of user interface module 808)
800 - user interface
814 - payment details
816 – booking requestor history details
Annex J – Pre-Payment Example
212 – pre-payment constraints
Items from flow chart are self-explanatory. The arrow at “1” continues to figure 8j.
Figure 8j continues on from figure 8i at “1”. It appears that one of either 862 on figure 8i or 864 on figure 8j is redundant. Otherwise, the figure is self-explanatory.
Annex K – System Constraint Example
Items from flow chart are self-explanatory. At item 901 it is determined whether the booking request 902 comprises a PDR request 904. If not, the process continues to 906.
903 – example of a limited a la carte menu.
920 – rules/constraints guiding menu decision process.
905 – user input interface for different menus/courses.
922 – menu rules for different menus 924, 926 etc.
Input screens for time allocated to different courses for a la carte menu.
User interface grouping booking requests based on seating periods for a service.
Annex L – Booking Widget Process Flow
Annex M – Self Seating App
Items are largely self-explanatory from the figure. 1102 denotes a remote computing system (e.g. cloud). 1132 denotes the self-seating app/kiosk generally.
Items are largely self-explanatory from the figure. 1134 denotes the venue database. 1142, 1146 and 1150 indicate display on the respective devices 1140, 1144, 1148.
Annex N – Example Product and Table Constraints
1230 – user interface (inferred, not actually mentioned in specification)
1236 – product name
1240 – example screen listing of a “leaf” product
1248 – prices
1250 – specific price
1232 – information items
1236 – product name
1236 – product name
1236 – product name
1246 – price adjustment table
1248 – prices
1250 – specific price
1252 – percentage adjustment of price
1254 – round up price option
1256 – round to nearest dollar option
1242 – leaf of product tree representing a specific table
1244 – description
1258 – venue (inferred, not actually mentioned in the specification)
1260 – specific price
1244 – description
ANNEX O – The Claims
0