Grand Performance Online Pty Limited

Case •

[2020] APO 33

•

9 July 2020

IP AUSTRALIA

AUSTRALIAN PATENT OFFICE

Grand Performance Online Pty Limited [2020] APO 33

Patent Application:                2018202759

Title:A system, method and computer program for optimising and allocating resources in a space for defined periods of time

Patent Applicant:                   Grand Performance Online Pty Limited

Delegate:  Dr V. Z. Kolev

Decision Date:  9 July 2020

Hearing Date:  14 November 2019, in Canberra; Further written submissions received on 05 December 2019 and 11 March 2020

Catchwords:  PATENTS – hearing with respect to examiner’s objection – manner of manufacture – inventive step – restaurant booking and management system – furniture re-arrangement in the restaurant space – iterative bookings re-allocation after each booking request – business innovation – the claimed invention is not a manner of manufacture – no patentable subject matter found in the specification – application refused – inventive step not decided  

Representation:  Counsel for the applicant:  Dr Anton Hughes

Patent attorney for the applicant:  Mr Joseph Seisdedos of Auctus IP

IP AUSTRALIA

AUSTRALIAN PATENT OFFICE

Patent Application:                2018202759

Title:A system, method and computer program for optimising and allocating resources in a space for defined periods of time

Patent Applicant:                   Grand Performance Online Pty Limited

Date of Decision:                   9 July 2020

DECISION

The invention claimed in any one of the claims is not a manner of manufacture. 

Furthermore, I do not consider that this finding could be overcome by an allowable amendment, therefore providing Grand Performance Online Pty Limited with an opportunity to amend will serve no useful purpose. 

I refuse the application.   

REASONS FOR DECISION

  1. Throughout this decision, unless explicitly stated otherwise, any reference to an Act or a section, subsection, etc. of an Act refers to the Patents Act 1990 (the Act), and any reference to Regulations or a specific regulation refers to the Patents Regulations 1991 (the Regulations).  In addition, any reference to “the Commissioner” refers to the Commissioner of Patents as per the Act.

    BACKGROUND

  2. The matter relates to patent application 2018202759 (the Application) in the name of Grand Performance Online Pty Limited (the Applicant).  The Application claims priority from four provisional applications 2017905188, 2017905189, 2017905190, and 2017904431.  The earliest claimed priority date is 31 October 2017.

  3. The Application was filed on 19 April 2018 along with a request for expedited examination.

  4. Examination report No. 1 was issued on 19 June 2018.  The report contains objections with respect to manner of manufacture, clarity, novelty, and inventive step.  A response to that report was filed on 30 September 2018 together with the first statement of proposed amendments, in which, under item 1, the Applicant proposed amended claims.

  5. Examination report No. 2 was issued on 05 November 2018.  The report contains objections with respect to manner of manufacture, novelty, and inventive step.  A response to that report was filed on 03 December 2018.  No amendment was proposed at that time.

  6. Examination report No. 3 was issued on 17 January 2019.  The report contains objections with respect to manner of manufacture, support under subsection 40(3), novelty, and inventive step.  As per the Commissioner’s standard practice, before being issued, the report was reviewed by the Examiner’s supervisor.  A response to that report was filed on 24 May 2019 together with the second statement of proposed amendments, in which, under item 2, the Applicant proposed a new set of amended claims.

  7. Examination report No. 4 (the Last Report) was issued on 13 June 2019.  The Last Report contains objections that the invention defined in each one of the claims:

    ·is not a manner of manufacture – paragraph 18(1)(a); and

    ·does not involve an inventive step – subparagraph 18(1)(b)(ii).

    As per the Commissioner’s standard practice, before being issued, the report was reviewed by the Supervising Examiner responsible for the examination section.

  8. On 14 June 2019, the Applicant requested to be heard.  In addition, on 18 June 2019, the Applicant filed a response to the Last Report.  No further amendment was proposed.  On 19 June 2019, in a telephone conversation with the representative of the Applicant, the Examiner informed the Applicant that he had considered the response and maintained his objections raised in the Last Report.  The Examiner also informed the Applicant that since a hearing had already been requested and a Hearing Officer would soon be assigned to look at the case, there was no need to issue a further examination report.

  9. Importantly, the present hearing is with respect to the outstanding objections, as listed above, raised in the Last Report and is based on the specification of the Application (the Specification) as proposed to be amended on 24 May 2019.

    SUBMISSIONS AND EVIDENCE

10.  On 07 November 2019, the Applicant filed “Patent Applicant’s Summary of Submissions” (the Applicant’s Summary or AS), including annexures 1 to 8.  Annexures 1 and 2, respectively, are the following documents filed in evidence:

·     A declaration by Mr Peter Petroulas dated 07 November 2019 (Petroulas-1), accompanied by “Annexure A” to “Annexure D”; and

·     A declaration by Dr Jacob Feldman dated 06 November 2019 (Feldman), accompanied by “Annexure A” to “Annexure J”.

11.  As agreed at the hearing, on 15 November 2019 (i.e. the day after the hearing), I issued correspondence “inviting further submissions from the Applicant with respect to some specific topics” which I had raised during the hearing.  In that correspondence, I also noted that:

“During the hearing, the Applicant presented some further material electronically. As agreed at the hearing, the Applicant is invited to file any of those materials (which are not confidential) as PDF files …”

12.  In response, on 05 December 2019, the Applicant filed the following documents:

·     “Patent Applicant’s Further Submissions” (the Applicant’s Further Submissions or AFS);

·     A declaration by Mr Peter Petroulas dated 05 December 2019 (Petroulas-2); and

·     A document tiled “Comparison of the Prior Art with Examples of the Claimed Invention” (the Comparison), the document being “a PDF document including screen shots of the videos and slide shows presented at the hearing”.

13.  On 11 March 2020, the Applicant filed a letter containing yet further submissions (the Brief Further Submissions or BFS).  I will explain the nature of the BFS later in this decision. 

APPLICABLE LAW

14.  On 15 April 2013, the Intellectual Property Laws Amendment (Raising the Bar) Act 2012 commenced which resulted in significant amendments to the Act and Regulations. The Application was filed on 19 April 2018, hence the amended provisions of the Act and Regulations apply to the examination of the Application and to the instant hearing.

15.  This means that if I am satisfied, on the balance of probabilities, that a ground of objection exists, I can refuse the Application.  However, I will only refuse the Application if I am also satisfied that providing the Applicant with an opportunity to amend will serve no useful purpose, for example, if I consider that any potential negative findings are not rectifiable by an allowable amendment.

THE SPECIFICATION

16.  It is worth noting that the description contains 110 pages and it is accompanied by 58 sheets of drawings.  A number of different aspects and embodiments of the invention are described with various alleged advances over the prior art, each one possibly having the potential to result in claiming a patentable invention.  While it may not be strictly necessary, for completeness in the specific circumstances of the case, I will endeavour to discuss the body of the Specification in its entirety using, wherever possible, the specific language chosen by the Applicant.

The field of the invention

17.  The Specification begins with the section titled “Technical Field”.  In my view, this section provides a concise but informative summary of the invention:

“[0001] The present invention relates to a system, method and computer program for allocating resources in a space for defined periods of time.

[0002] In one embodiment, the invention is directed to an online restaurant booking system that optimises the use of space and time, and other operational considerations of a restaurant in order to optimise desired outcomes which may include optimising capacity, ambiance, preferred seating allocation and/or additional revenue generation and/or the minimisation of costs.

[0003] Embodiments of the system are directed to the fields of online (e.g. web based) interactive systems, applications for mobile devices (‘apps’), and/or software applications that determine the optimal arrangement and deployment of bookings for a space, table, chair, stool or area using area optimising algorithms within that space and time while offering a tailored experience with multiple payment requirement permutations.” (underlining added)

The description of prior art attempts and known systems

18.  The present invention appears to be addressing the deficiencies in the prior art (see e.g. the Specification at [0046] quoted at [34] in this decision) and, as such, I will consider the prior art and its shortcomings as identified in the Specification, which discusses the prior art in the section “Background”, divided into several subsections apparently each dealing with a specific issue (or set of issues). 

Capacity

19.  The first subsection is titled “a) Capacity” and deals with the prior art attempts to optimise the seating capacity of a vanue (e.g. a restautant) based on the bookings.  It starts by explaining that “[p]revious attempts to produce software and hardware tools and devices to manage tables within a restaurant have simply automated the manual techniques and procedures developed by restaurant managers” (at [0004]), and then further elaborates on the shortcomings of the prior art:

“[0004] … Attempts in more recent times to automate the booking and allocation of tables to restaurant patrons have concentrated on attempting to capture and systematize the skill of the restaurant manager using the Internet as a communications tool and computer technology as the ‘brains’ in the table allocation process.

[0005] However, prior art solutions have attempted to directly codify, in a brute force manner, the skill of a restaurant manager. This was sought to be achieved by firstly pre-numbering all tables for identification, then using the (manual and human) skill and expertise of a restaurant manager to prepare a detailed list of all tables that can be moved together to create ‘table combinations’ to accommodate larger bookings.

[0006] Prior art software solutions are provided with a list of tables and table combinations created by the restaurant manager, from which the software utilises a brute force method to calculate all possible solutions, in the search for the allocation of a booking request.

[0007] … As such, the optimisation of the allocation of restaurant tables to bookings is only optimised to the extent that the input provided by the restaurant manager is optimal. As such, the software is not providing any ‘intelligence’, but is merely allocating tables to bookings based on the information encoded into the software (indirectly) by the restaurant manager.

[0008] Moreover, prior art software operates on the assumption that a restaurant operates with a finite set of tables, being the tables located within the restaurant. This assumption limits the manner in which the restaurant may be optimised. For example, when a table combination is created to cater for a larger booking and tables are physically pushed together to create the desired table combination, unused space is created. By definition, the restaurant space cannot be optimised as the additional space created by the joining of tables is not utilised. … However, prior art software applications have no mechanism to allow for this type of optimisation. This sub-optimal result highlights a significant inefficiency of the prior art with the manner in which table combinations occur.

[0009] In more detail, the prior art is concerned with the ‘management of restaurant tables’ using combinatorial constraint programming. However, the prior art is silent on the ‘management of a space’ through the use of space optimising algorithms.” (underlining added)

20.  According to the Specification, the “combinatorial constraint programming” is a theoretical approach explained mostly by reference to “a 2007 paper by Alfio Vidotto entitled; [sic] ‘Managing Restaurant Tables Using Constraint Programming’” (see [0011]).  It is noted that:

“[0012] … the combinatorial constraint solution detailed by Vidotto is nothing more than an encoded, computerised version of the skill and art of a restaurant manager’s predefined set of solutions from which to choose the best fit option.

[0013] Vidotto highlights the very long and not practical computational times required to find a solution using combinatorial constraint programming and offers ways that computing time may be reduced so that his proposed solution has practical application. Despite Vidotto’s attempts to make his system faster and more practical, to date, combinatorial constraint programming techniques have not been adopted by any restaurant or venue anywhere in the world to allocate tables to bookings.

[0014] Another major drawback in the application of Vidotto’s solution is the unforeseen requirement whereby the restaurant managers skill is required not only for the setting up of all possible table locations and table combinations from which a solution could be found, but, in the situation where changes are made to table sizes and table layouts, the restaurant manager as well as the skills of a mathematician and programmer are required to manually develop a new table and table combination list to maintain the system.

[0015] All prior art using combinatorial constraint programming has used the same theory, logic and approach as Vidotto and there is no evidence to suggest that the approach used by Vidotto in determining restaurant capacity has been successfully applied in industry.” (underlining added)

21.  The Specification then talks about the prior art techniques that, in contrast to the above, have been applied in practice:

“[0016] The prior art generally describes techniques that utilise static linear combinatorial priority lists. However, the use of such lists are [sic] dependent on a certain number of preconditions being met, including:

1. The manual determination of a single list of all table (numbers) and table combinations (numbers) in order of preferred priority of seating;

2. The manually determined list of all tables and table combination numbers then forms the totality of all possible solutions;

3. The list of tables and table combinations being linked to a table plan that is not to scale and makes no reference to scale or the relativity of different objects within the space it is merely used as a communication tool representing the general layout of the tables; and

4. The prioritised list of tables can also include other constraints that can be applied to tables such as the maximum and minimum booking numbers that can be allocated to a table or table combinations however, these constraints do not change the table selection and allocation process.

[0017] Once a booking is received the prior art simply scans the static linear priority list of tables to locate the highest ranking table that is able to seat the booking request and permanently allocates the booking request against the identified table or table combination.

[0018] For any subsequent bookings the prior art does not consider a table or table combination where a booking has already been allocated. This creates inefficiencies with regard to any possible optimisation as a reallocation of previous bookings would result in a more optimised solution.” (underlining added)

22.  It is then explained that:

“[0019] The use of the simplified static linear combinatorial priority list of tables and table combinations from which the system can select and allocate a booking simplifies the mathematical skills and computer programming skills required to implement the static list in software, but suffers from the disadvantages of requiring numerous manual interventions to monitor booking allocations and to manually reallocate bookings to provide a more optimised final outcome.” (underlining added)

23.  The subsection ends with a paragraph containing what appears to be a summary of the prior art issues with respect to the venue (e.g. the restaurant) capacity:

“[0020] Both the theoretical prior art of combinatorial constraint programming and the practical prior art of a static linear combinatorial priority list share the same fundamental parameters and logic. Specifically:

1. Prior art solutions define the problem as the ‘management of restaurant tables’, meaning tables already situated within a restaurant;

2. Prior art solutions require a manual determination and manual input of all tables and table combinations;

3. Prior art solutions require all tables and table combinations to be identified by predetermined table numbers;

4. Prior art solutions can only select a solution from one of the list of predetermined tables or table combinations;

5. Computerised prior art solutions rely on the expertise of a restaurant manager to determine the finite list of tables and table combinations without any cross check or analysis to determine if the list of tables and table combinations is complete or ordered correctly; and

6. Computerised prior art solutions make no attempt to use or maximise space, for example by using the additional space that is created when tables are joined.” (underlining added)

Time management

24.  The next subsection of the section “Background” is titled “b) Time Management” and it deals with the allocation of booking requests to use the venue (e.g. the restaurant) at different times during the same active business period or service period of the day (e.g. the same evening).  The subsection explains:

“[0021] While time management has been considered in the prior art as a factor in the management of tables and table combinations, prior art solutions have only considered time as one standard unit of measure for all different bookings irrespective of any further considerations such as different menus that may be offered by the restaurant and the number of courses that may be planned to be consumed by a customer. The prior art is unable to consider or discriminate between variables like different menus, different number of courses, different group sizes, different occasions or other factors that need to be understood and considered in the correct allocation of time to a booking.” (underlining added)

25.  It is then noted that the prior art does not consider a number of important points, such as:

“[0022] … the time that restaurant staff need to reset a table before it can be reused as a constraint in the optimisation of a restaurants capacity. … the time taken to reset a table for use by the next booking as varying depending the number of staff that are working on a particular service or the style of restaurant or any other variable and the complexities of that restaurant faces to reset a table.

[0023] … the importance of monitoring the times people take to consume a meal based on the parameters of menu selected, number of courses, group size, occasion or other factors and then use this information to provide recommendations or to automatically update the system for future booking duration time allocations.

[0024] … the importance of monitoring the times taken by a restaurant to reset a table and how the process of a resetting a table can be improved or reduced so that the valuable resource of time is optimised.” (underlining added)

26.  The subsection concludes that:

“[0025] The prior art does not consider time as a valuable resource from the perspective that if a booking wishes to stay longer they are reducing the available time resource and revenue potential of a restaurant.” (underlining added)

Personalisation

27.  The next subsection of the section “Background” is titled “c) Personalisation” and it deals with the prior art’s apparent inability to provide tailored or personalised experience through more specific booking requests and their allocation:

“[0026] The prior art by using tables and table combinations in the allocation of bookings undertakes the allocation of bookings in a random way or, as in the case of the static linear combinatorial priority list allocates bookings based on a ‘permanent’, first in, first allocated basis which results in a very simple process in the allocation of bookings and does not permit bookings to be prioritised or allocated based on other constraints, such as, customer status, customer time duration requirements, customer selection nor the ability to charge a customer a different amount of money for a change to the standard constraints attached to a booking.” (underlining added)

28.  According to the Specification, the prior art systems also lack the ability to:

“[0027] … allocate bookings to tables to improve the ambiance within a restaurant[.]

[0028] … rank and discriminate the relative or perceived utility or value or rank of a table, space or location within a restaurant. For example, a table with a view being of perceived higher utility and desirability, and hence value, than a table in a back corner next to a toilet.

[0029] … offer different tables, spaces, or locations within a restaurant at different prices, or with different constraints.” (underlining added)

29.  In other words:

“[0030] The prior art and systems do not recognise that a restaurant booking can represent a booking where a person wishes to tailor and personalise their entire evening so that their experience can be more bespoke and unique.”

Constraint management, yield management and revenue efficiency

30.  The next subsection of the section “Background” is titled “d) Constraint Management, Yield Management and Revenue Efficiency”.  The subsection explains that:

“[0031] Yield Management involves and requires the strategic control and allocation of capacity (in this case restaurant tables and chairs) to sell the right menu with the right number of courses to the right customer at the right time for the right duration of time for the right price. In this regard, the limitations of dynamic combinatorial constraint programming and the static linear combinatorial priority lists of the prior art are unable to control capacity in an effective manner (either computationally or in a real life situation).

[0032] As the prior art cannot effectively control capacity or the allocation of capacity, attempts at constraint management or yield management have been limited to simple manual interventions such as:

1. Static differential pricing such as offering a discount for an early booking;

2. Static differential product offerings such as a free glass of wine for an early booking;

3. Static discriminatory pricing such as a 20% discount for pre-theatre dining; and/or

4. A booking fee charged for the selection of a preferred booking time on a preferred day.

[0033] The prior art does not consider revenue efficiency as being the product of the utilisation of capacity in a space for a period of time measured in units of time including the additional tables and chairs brought into a restaurant in excess of the standard floor plan represented by the tables and table combinations by the revenue generated from that space for that period as compared to the revenue that could have been generated during that period if all sales, discounts and promotions were assumed to have been sold at their normal recommended retail price.” (underlining added)

The use of the online reservations system and diary for the creation of an Integration and Autonomous Restaurant System

31.  The last subsection of the section “Background” is titled “e) The use of the online reservations system and diary for the creation of an Integration and Autonomous Restaurant System” and deals mainly with the disadvantages of the existing online reservation systems from the point of view of the venue (e.g. the restaurant) operator.  Importantly, it is worth noting that these are not necessarily disadvantages for the operators of the online reservation systems:

“[0034] In the past, online restaurant reservation systems have been operated by third parties whose main objective is to maximise the number of reservations directed through their third party website or application. Third party systems generally create a barrier between themselves and the restaurant so that a customer’s details are added to the third party system and used by the third party to create a loyalty between the customer and the third party, as distinct to prioritising and/or supporting the activities of the restaurant and the communication between the restaurant and the customer.

[0035] In many cases third party online reservations systems compete with the marketing activities of the restaurant. …

[0036] Third party online reservations systems also convince restaurants to market special offers specifically to the data base of customers held by the third party online reservations systems, such as a 50% discount offer or a free glass of wine with a meal. These offers are designed primarily to generate more loyalty to the third party booking site and are funded by the restaurant as the third party booking system does not partake or assist in the process by reducing its normal fees and charges for such a promotion. As such, promotional activities supported by the third party websites operate specifically for the benefit of the third part [sic] online booking systems and not for the restaurant.

[0037] The promotional activity supported by the third party online booking systems are designed as simple, static, discrete and manual promotional activities with no intelligence or reference to the actual operating costs, capacity, capability or revenue of the restaurant and as such cannot be said to be connected to any use of yield management techniques or dynamic pricing. In other words, they are unsophisticated promotions.

[0038] Prior art online booking systems utilise a single aggregator website for all restaurants using their online booking systems so that the third party booking systems can generate additional revenue from the restaurants by:

1. Charging restaurants a fee to provide a preferential position or exposure within the third party website;

2. Providing exposure to the third party data base in return for the restaurant providing exclusive discounts to the online booking system;

3. Provide preferential exposure within the third party website if the restaurant commits exclusively to the online booking system provider;

4. Incentivises higher usage of the third party booking system if a restaurant supports bookings going through the online booking systems provider’s website; and/or

5. Charges other third parties to gain exposure to their data base (e.g. credit card companies) to further leverage the inherent value of the restaurant’s customer database.” (underlining added)

32.  According to the Specification, the prior art reservation systems have a number of additional drawbacks, i.e. they:

“[0040] … fail to create an integrated, seamless and autonomous restaurant management system interacting with the restaurant. The booking information captured … are typically confined to the name, email, telephone, the number of guests and the time/date of the booking.

[0041] … reinforce traditional table allocations and table combinations and limits the ability to autonomously manage and control capacity, as theoretical combinatorial constraint programming and the static linear combinatorial priority lists require manual intervention to become workable or optimal capacity solutions, which negates their ability to offer an integrated autonomous solution without manual reviews and intervention.

[0042] … are stand alone, with many independent and different systems with different software and hardware solutions being used to bring together a very cumbersome and ineffectively integrated solution for the optimisation and management of a restaurant. … the manual use of different, and potentially overlapping systems is inefficient and requires significant manual co-ordination. For example, pre-booked customers, walk-in customers and home delivery orders are generally handled in different manners and through different systems, yet they each impose different demands and requirements on the ability of a restaurant kitchen to process orders. If orders are not coordinated correctly and managed possible delays in preparing numerous orders create detrimental effects which could, in the long term, damage the reputation of the restaurant and may result in the demise of the restaurant.

[0043] … fail to provide an integrated manner for the offering of gift cards or the acceptance of gift cards as a form of payment to permit a streamlined and autonomous booking and payment process.

[0044] … fail to adequately apply information from Customer Relationship Management (CRM) systems in situations like the allocation of tables to customers to better tailor the customer’s booking experience or by giving priority and allocating better tables to more loyal customers or customers who could bring a better social media outcome for the restaurant.” (underlining added)

33.  This subsection, and the whole section “Background”, concludes with the statement:

“[0045] In other words, the prior art 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 that has the potential of significantly increasing 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.” (underlining added)

34.  Importantly, as I mentioned at the beginning of my discussion of the prior art:

“[0046] It is with these problems in mind that the present invention and integration has been developed.”

The invention as described

The summary of the invention

35.  The next section of the description is titled “Summary”.  In this section, the invention is described in terms of 10 different aspects.  These aspects provide (underlining added), respectively:

1. “a computing system for optimising and allocating bookings within a space for a defined period of time in a venue, comprising an optimisation and allocation module in communication with a processor and arranged to receive the at least one request and communicate with a database to determine whether other requests for spaces have been made by other users, and if so, utilise the processor to retrieve information regarding the other requests for spaces and combine the at least one request with other requests to form a pool of requests, retrieve constraint information regarding the venue including information regarding the size of the venue and the size and quantity of available furniture that may be allocated to the space in the venue, and in a structured way iteratively allocate all requests from the pool of requests utilising the restraint information to produce an optimised and/or prioritised allocation instruction set, wherein the optimised and/or prioritised allocation instruction set saved in the database and provided by a space allocation user interface to one or more users associated with the venue” (starting at [0047]);

2. “a computer enabled method for optimising the use of space in a venue, comprising the steps of: receiving at least one request to reserve a space or a table or a table combination within the venue from at least one remote user from an application residing on a remote device via the communications network, and retrieving other information and constraint information from the data base such as, the menu or menus available for a particular day and time as well as the time allocated for the menu and courses selected by group size and using that information to communicate with a user prior to accepting a request for a booking and then determining whether other requests for spaces have been made by other users, and if so, retrieve information regarding the other requests and information pertaining to those requests for spaces, tables or table combinations and combine the at least one request with other requests to form a pool of requests, and other information pertaining to those requests retrieve constraint information regarding the venue, and iteratively allocate all requests from the pool of requests utilising the restraint information to produce an optimised space, tables or table combinations allocation instruction set, wherein the optimised prioritised and re-allocated space, tables or table combinations allocation instruction set is provided to one or more users associated with the venue” (starting at [0093]);

3. “a computer optimisation system including a system in accordance with the first aspect of the invention [i.e. see item 1. above] which defines the capacity in the form of usage within a space, : [sic] a database arranged to provide historical and live data regarding the use of the resources of a restaurant, an input module arranged to receive information regarding the usable resources at any given time from the system according to the first aspect of the invention, an optimisation module in communication with a processor and arranged to receive the at least one request and communicate with the database to receive the historical and live data and the usable resource data, wherein the data is analysed utilising a yield determination algorithm to determine, data regarding the relative optimal use of the usable restaurant resources and provide relative optimal use data to the system in accordance with the first aspect of the invention” (starting at [00111]);

4. “an autonomous, integrated booking and management system” (starting at [00127]);

5. “a computer enabled method for optimising the use of tables and table combinations in a venue, comprising the steps of: receiving at least one request to reserve a table or a table combination within the venue from at least one remote user from an application residing on a remote device via the communications network, as well as retrieving other information and constraint information from the data base and using that information to communicate with a user prior to accepting a request for a booking and then determining whether other requests for tables and table combinations have been made by other users, and if so, retrieve information regarding the other requests and information pertaining to those requests for tables or table combinations and combine the at least one request with other requests to form a pool of requests, and other information pertaining to those requests retrieve constraint information regarding the venue, and iteratively allocate all requests from the pool of requests utilising the restraint information to produce an optimised table and table combination allocation instruction set, wherein the optimised prioritised and re-allocated, tables or table combinations allocation instruction set is provided to one or more users associated with the venue” (starting at [00155]);

6. “a computing system for optimising the use of space in a venue, comprising: a user interface providing module arranged to provide a user interface to at least one remote user via a communications network, a user input receiving module arranged to receive at least one request to reserve a space for a period of time within the venue from the at least one remote user via the communications network, a negotiation module in communication with a processor and arranged to receive the at least one request and communicate with a database to retrieve constraint information regarding the venue and determine whether the at least one request can be accepted, and if not, utilise the processor to retrieve information regarding the other requests for spaces and propose at least one alternative request to the user via the user interface, wherein if the at least one alternative request is accepted by the user, the at least one alternative request is saved in the database” (starting at [00159]);

7. “a computing system for optimising the use of space in a venue, comprising a user interface providing module arranged to provide a user interface to at least one remote user via a communications network, a user input receiving module arranged to receive at least one request to reserve a space within the venue from the at least one remote user via the communications network, an optimisation module in communication with a processor and arranged to receive the at least one request and communicate with a database to determine whether other requests for spaces have been made by other users, and if so, utilise the processor to retrieve information regarding the other requests for spaces and combine the at least one request with other requests to form a pool of requests, retrieve constraint information regarding the venue, and iteratively allocate all requests from the pool of requests utilising the restraint information to produce an optimised space allocation instruction set, wherein the optimised space allocation instruction set is saved in the database and provided by a space allocation user interface to one or more users associated with the venue” (starting at [00166]);

8. “a computer enabled method for optimising the use of space in a venue, comprising the steps of receiving at least one request to reserve a space within the venue from the at least one remote user via the communications network, determining whether other requests for spaces have been made by other users, and if so, retrieve information regarding the other requests for spaces and combine the at least one request with other requests to form a pool of requests, retrieve constraint information regarding the venue, and iteratively allocate all requests from the pool of requests utilising the restraint information to produce an optimised space allocation instruction set, wherein the optimised space allocation instruction set is provided to one or more users associated with the venue” (at [00173]);

9. “a computer system for optimising the use of a restaurant, comprising: a database arranged to provide historical and live data regarding the use of the resources of a restaurant, a input module arranged to receive information regarding the actual usable resources at any given time, an optimisation module in communication with a processor and arranged to receive the at least one request and communicate with the database to receive the historical and live data and the actual usable resource data, wherein the data is analysed utilising a yield determination algorithm to determine the relative optimal use of the usable restaurant resource. The optimisation module may provide information regarding one or more parameters that may be optimised to increase the yield of the restaurant” (starting at [00174]); and

10. “a computing system for optimising the use of space in a venue across a defined period of time, comprising a user interface providing module arranged to provide a user interface to at least one remote user via a communications network, a user input receiving module arranged to receive at least one request to reserve a space within the venue from the at least one remote user via the communications network, the user further providing a period of time for which the space in the venue is to be utilised, an optimisation module in communication with a processor and arranged to receive the at least one request and communicate with a database to determine whether other requests for spaces have been made by other users, and if so, utilise the processor to retrieve information regarding the other requests for spaces and combine the at least one request with other requests to form a pool of requests, retrieve constraint information regarding the venue including the periods of time for which the requests for space are associated with, and iteratively allocate all requests from the pool of requests utilising the time restraint information to produce an optimised space allocation instruction set, wherein the optimised space allocation instruction set is saved in the database and provided by a space allocation user interface to one or more users associated with the venue” (starting at [00178]).

36.  The language used in this section suggests the presence of a number of, somewhat overlapping, consistory statements, however I note that some additional explanations with respect to the functionality of the provided systems and methods are also included.  In light of my discussion of the detailed description of the invention below, I do not consider it necessary to discuss these additional explanations.

The detailed description of the invention

37.  The section “Summary” is followed by the statement that:

“[00183] Further features of the present invention are more fully described in the following description of several non-limiting embodiments thereof. This description is included solely for the purposes of exemplifying the present invention. It should not be understood as a restriction on the broad summary, disclosure or description of the invention as set out above.” (underlining added)

The preferred embodiments

38.  Having briefly described the drawings, the Specification explains, in functional terms, the preferred embodiments.  The important features of the invention appear to be discussed in the section “Detailed Description of Preferred Embodiments” which starts by stating that:

“[00194] The present invention relates generally to a computing system, method, computer program and data signal for managing a space. In one embodiment…, the invention is directed to a computing system, computer enabled method, program and data signal which includes codified methodologies and algorithms arranged to optimise the space, prioritise seating, and improve the ambiance of the venue, wherein the venue is, in one specific embodiment, a restaurant.” (underlining added)

39.  The section further explains that the system comprises: “a user interface providing module” that provides “a user interface to at least one remote user [to make a booking request] via a communications network”; “a user input receiving module” to receive the booking request “to reserve a space within the venue from the at least one remote user via the communications network” (see [00195]); and “an optimisation module” that receives the request and communicates with a database “to determine whether other requests for spaces have been made by other remote users” (see [00196]), wherein the optimisation module “retrieve[s] information regarding the other requests for spaces and combines the at least one request with other requests to form a pool of requests, retrieve[s] constraint information regarding the venue, and iteratively allocate[s] all requests from the pool of requests utilising the constraint information to produce an optimised space allocation instruction set” (see [00197], underlining added).  In addition:

“[00198] Embodiments of the present invention use ‘volumetric’ algorithms to optimise capacity and revenue within a multi-venue restaurant environment that includes fine dining, casual dining, cafes and cabaret shows and includes a methodology and algorithm which overcomes the practical constraints evident in prior art theoretical concepts which are based on combinatorial constraint programming that, while theoretically workable, are not practical, as they are not computationally efficient and therefore are not workable in the ‘real world’.

[00199] 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’ 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 combination from a predetermined list of tables and table combinations.

[00200] By defining the problem as the ‘optimisation of the use of a space’ and using volumetric algorithms to solve the allocation problem of diners to tables, the embodiment provides an autonomous system which operates across the entire experience of the customer, from the time a booking is requested, to the personalisation of that experience, all the way until the service has been completed and the bill paid.

[00201] By defining the problem as the ‘optimisation of the use of a space’ embodiments of the invention provide a different view of the restaurant problem, in that, in optimising a restaurant, there are more considerations than the allocation of people or booking requests to predefined table combinations but how to best use the space which includes the creation and development of algorithms and techniques to allocate people to tables that may focus on other aspects such as the ambiance within the restaurant, the allocation of a person to their preferred location or table, the distance between tables, offering different menus to different areas within a restaurant, extending meal period times by offering different menus to achieve the individual requirements and strategies of different venues and restaurants.” (underlining added)

40.  In the sections that follow, namely: “Space Management and Table Simulator/Configurator”, “The Computing System”, “Constraint information/Space Information”, “Optimisation module/Algorithm”, “The Iterative Allocation Process”, and “User Interface”, the description discusses several more specific aspects of the invention.  Since the nature of the invention and the prior art problems being addressed by it are already apparent from my discussion of the Specification so far, I do not consider that I need to go into excessive amount of detail with respect to these sections of the description.  Nonetheless, I will refer to the most revealing parts and summarise my findings.

41.  Importantly, described is “a system and method for optimising the use of a space by optimising the table layout and seating capacity of a space, restaurant or venue without utilising dynamic combinatorial constraint programming or the industry adopted, and practically applied approach of static linear combinatorial constraints” (at [00203], underlining added).  This is achieved by “a software application embodied in a system and deployed as a method that allows a user to create a plan of the space to scale, wherein all objects that are relevant to the space, such as furniture, can be allocated and placed within the space” (at [00204], underlining added).

42.  By utilising “a list of all available furniture and other relevant objects, and the quantities of the furniture and objects, including their dimensions” (see [00205]) as well as “further information which can be utilised to determine the ‘best’ table to use within the space as selected from a pool of tables” (see [00206]) the system/method is “capable of eliminating unused space within a venue or restaurant when tables are required to be joined to form a larger table to cater for a larger booking size” (see [00207]) and also “allows additional furniture to be brought within the space to cater for larger bookings where additional space becomes available that can accommodate the additional table or tables” (see [00208]).  In addition, “the algorithm permits the allocation or reallocation of bookings within a space or restaurant so that regular customers or booking categories are given better tables, location or seats as compared to non-regular customers” (at [00211]).

43.  Because “[t]he outcome of the algorithm is, in part, a floorplan of the space that clearly shows to the restaurant manager the table allocation and arrangement, as well as which tables are readily available in the restaurant and which are in storage” (see [00213], underlining added), “[t]he algorithm allows restaurants and venues to run booking simulations to determine the best orientation, spacing and layout of tables and furniture within a restaurant or a venue to determine the best solution based on the restaurants requirements so to assist in the restaurant planning process such as determining what size tables to buy, how many tables to buy, how many chairs to buy and other physical decisions within the restaurant” (at [00215], underlining added).

44.  This allows “controlling, allocating, forecasting and optimising capacity to improve revenue efficiencies by using yield management algorithms to optimise restaurant-related outcomes and efficiencies” (at [00216], underlining added).

45.  I find it important to note that “the algorithm optimises ambiance and customer satisfaction by allocating the best tables to the confirmed bookings. This is important when a space or a restaurant is not full as optimisation of the floor space may not achieve the best outcome for the restaurant as the provision of the best space for a booking may result in a patron being happier and possibly spending more than if they were seated in a worse space” (see [00212], underlining added).  In other words, the “optimisation of the floor space” is not always the desired outcome of the algorithm, since:

“[00218] … the system seeks to manage the entire guest experience from time of booking with the ability to handle pre-orders, pre-payments, part-payments, invitations to booking guests to pre-order and prepay, amendments to bookings, personalisation and tailoring of booking requests, automatic seating allocations and self-seating directions, automatic ordering at a table, pre-order, automatic printing of orders in the kitchen, taking of home delivery orders and automatic printing of home delivery orders into the kitchen, the management of a la carte and home delivery orders in the kitchen and estimation of cooking times and when the food will be ready, the issuing of gift certificates and the redemption of the gift certificates as payment or part-payment for an order, the simplification and processing of final payments through a point of sale system and integrated Customer Relationship Management (CRM), accounting, reporting, budgeting and forecasting.” (underlining added)

The computing system

46.  The computing system, on which the coded algorithms of the invention run, is illustrated on figure 1 which is reproduced below.  The reference numerals correspond to the following elements: 100 – a computing system suitable for use with the present invention; 102 – a processor; 104 – read only memory (ROM); 106 – random access memory (RAM); 108 – disc drives; 110 – remote or connected mobile devices  (such as computers, smartphones or tablets and the like); 112 – disc drives; 114 – one or more communications link(s); 116 – a database; 118 – a suitable operating system.

47.  As it is conventional in such a generic computing architecture:

“[00222] The computing system 100 includes instructions that may be installed in ROM 104, RAM 106 or disc drives 112 and may be executed by the processor 102. There may be provided a plurality of communication links 114 which may variously connect to one or more user devices 110, such as computers, smartphones or tablets, wherein the one or more user devices have a user interface for interacting with user by collecting and displaying data or information using the conventional means provided by such devices. At least one of a plurality of communications link 114 may be connected to an external computing network through a telecommunications network.

[00223] … the database may reside on any suitable storage device, which may encompass solid state drives, hard disc drives, optical drives or magnetic tape drives. The database 116 may reside on a single physical storage device or may be spread across multiple storage devices, either locally or remotely.”

48.  Generic requirements are also imposed on the “suitable” operating system,

“[00224] … which may also reside on a storage device or in the ROM of the server 100. The operating system is arranged to interact with the database 116 and with one or more computer programs to cause the server to carry out the steps, functions and/or procedures in accordance with the embodiments of the invention described herein.”

49.  A user of the system “interacts with the user interface 110, and may be a first user (also referred to as the ‘remote user’ [e.g. a customer]) requesting to use a space in a venue … [or] a second user (referred to as the ‘entity user’ [e.g. a venue operator or employee]), who is associated with the venue and utilizes the optimised space allocation instruction set provided by the optimisation module to enable the use of the space by the first user” (see [00226]).  Further, “[t]he user interface 110 may be a program or website accessed on a computer or mobile device via a communication network, such as the Internet. Alternatively, the user interface 110 may be a widget arranged on a website that may be accessed by a user using a computer or mobile device via a communication network such as the Internet. The user interface 110 may also be provided as a mobile application or ‘app’ present on the user device, such as a tablet or smart phone” (see [00225]).

50.  It is envisaged that the computer system is capable of “processing the [booking] request [from the customer] and undertaking all subsequent steps in an autonomous manner … [or that] the entity user may use one of the user interfaces 110 provided to one or more devices to receive, input, or modify information in order to provide further input to the computer system 100, so that the computing system may process the request and provide instructions to the entity” (see [00228]).

51.  The operation of the system is schematically illustrated on figure 2a, reproduced below.  It appears that, on this figure, the system described in the Specification is referred to as “ResButler”.

52.  The description explains:

“[00230] Turning to FIG. 2a, there is shown a flow chart of the processes undertaken by the computer system 200 to determine the optimal allocation of a user request to use a space. Firstly, a user makes a request 202 which is collected by the user interface 204 on a device. The input receiving module 206 receives a request from the user interface 204, where the at least one user may be a customer making the request.

[00231] Alternatively, the at least one user may also be a service providing user (a second user or entity user), who is associated with the venue and may provide information to the user interface 204 on behalf of another remote user. For example, the service providing entity user, who may be employed by the venue, may take a booking over the phone on behalf of a remote user. As would be readily understood by the skilled addressee, multiple user interfaces may be contemplated depending on whether the use [sic] is an ‘outside’ user such as a remote user or an entity user, such as an employee.

[00232] The user input receiving module 206 transforms the data of the at least one user’s request into at least one string of request data and then communicates the request data to the optimisation module 208 [although a direct communication of the request data does not appear illustrated on figure 2a] via a telecommunications network. The request data includes all or part of the at least one user’s request as collected by the user interface 204. That is, the at least one user’s request may include a request for a time period during which the space in a venue will be used, the number of people who will be using the space, the contact details of the at least one user making the request, the reason or occasion for the use of the space, and whether there any special requirements to be made known for the use of the space. The skilled addressee will appreciate that the user input receiving module 206 may receive any data or information that is set out by the user interface. That is, the user interface 204 may be arranged to collect any type of data provided by the remote user or entity user.

[00233] The at least one string of the request data is then received by the optimisation module 208. The optimisation module 208 communicates with the database 212, where the database contains stored data relating to the request or any previously made requests. In an embodiment, the database 212 stores the at least one string of request data prior to processing by the optimisation module 208. The stored data may also include any ancillary information (information not directly related to the request) collected by the user interface and the user input receiving module. For example, the stored data may include at least one other request to use the space which have been made by at least one other user.

[00234] The stored data may also include past data, such as request data from requests made in the past, the details of the past use of the space, or the amount of money spent during the use of the space. The computer system 200 may provide the remote user with an option to open a user account or log into a previously opened account, which may be accessed by the user by means of a unique username and password as set by the user. The account may be accessed by any mobile device connected to the Internet or a local network in communication with the computer system 200. This enables the user to provide additional information to the user input receiving module 206 which is stored in the database in association with that particular user, such as personal, financial, or other types of user information.

[00235] The computer system as described provides a real time service to the user in processing their request. However, by providing the user with an account associates the user account with the request and allows the user to access the request where they may complete the request or modify the details of the request at any time after the request has been made.”

The user interface

53.  The section “User Interface” starts with the statement:

“One embodiment of the computer system includes a user interface providing module arranged to provide a user interface to at least one remote user via a communications network. The computer system may also include a user interface directed to one or more users associated with the venue.”

54.  It is worth noting that while the user interface provided by the computing system to the remote users (i.e. customers) and the users associated with the venue (i.e. venue operators or employees) is described in considerable detail including example screen illustrations, this is nonetheless done solely from the point of view of its ability to facilitate the described functionality of the system/method.  

The “constraint information”

55.  The description also explains that the database contains “constraint information” which is utilised by the algorithms.  The “constraint information” includes (underlining added):

·“information relating to the space available for allocation within the venue”, i.e. “relating to the venue itself, such as the spatial constraints of the space of the venue, the ingresses and egresses of the venue, and the facilities available in the venue” (see [00236]);

·“sub-space constraint information” that “includes information regarding a sub-space within the venue” (see [00237]), such as “the physical dimensions of the sub-space, the shape or arrangement of the subspace within the whole space of the venue, and the maximum and minimum number of users able to be accommodated in the sub-space, the amount or type of furniture that may be accommodated within the sub-space” (see [00238]), since “[a]s would be readily appreciated by the skilled addressee, a venue may have any number of subspaces within the physical limits of the venue” (see [00253]);

·“object constraint information regarding at least one object arranged to be allocated to a space or sub-space” (see [00241]), where “the objects may include tables and chairs for dining … the objects may include square, rectangular, circular, elliptical or irregular shaped tables … the objects may also include singular chairs or stools or shared seating such as benches” (see [00242]), and where “the object constraint information may include the type of object (for example, whether the object is a table or chair), the shape of the object, the physical dimensions of the object, information regarding the ability of the object to interface with other objects (e.g. whether the object can be joined or arranged proximate to other similar objects), and a rating value that describes the relative quality of an object (for example, the comfort rating of one type of chair compared to other types of chairs)”, and “may also include the dimensions of the object when arranged in a ‘compressed’ or ‘folded’ state when the object is in a storage configuration” (see [00243]);

The four PCT applications are:

1. PCT/AU2018/051168;

2. PCT/AU2018/051169;

3. PCT/AU2018/051170; and

4. PCT/AU2018/051171.

It is requested that the Hearing Officer take the findings of the above-mentioned PCT applications into consideration when reaching a determination.”

176. Indeed, the Australian Patent Office, in its capacity of an International Preliminary Examining Authority, issued International Preliminary Report on Patentability (Chapter II of the Patent Cooperation Treaty) with respect to all four of the above listed international applications.  However, I must note that the opinion of the Authorised Officer (i.e. the International Examiner) who issued the above international reports on cases “correspond[ing] to the same family” is no more persuasive than the opinion of the Examiner who issued the four adverse examination reports with respect to the instant Application.

177. In addition, while the four international reports are “clear” with respect to novelty, inventive step, and industrial applicability, importantly, in “Box No. VIII Certain observations on the international application”, all four international reports contain the following text (underlining added):

“The following observations on the clarity of the claims, description, and drawings or on the question whether the claims are fully supported by the description, are made:

A search was performed because a meaningful search was considered possible following the PCT search and examination guidelines, however we consider the material claimed to be excluded subject matter under the rules of the PCT.”

178. I regard the above observation as a strong indication that the International Examiner did not consider that any one of the four international applications contains patentable subject matter.  In other words, if I am to follow the Applicant’s request to “take the findings of the above-mentioned PCT applications into consideration when reaching a determination”, this could only result in reaffirming my position that the present invention is not a manner of manufacture.

INVENTIVE STEP UNDER SUBPARAGRAPH 18(1)(b)(ii)

179. The test for obviousness was developed in Wellcome Foundation Ltd v VR Laboratories (Aust) Pty Ltd [1981] HCA 12; (1981) 148 CLR 262 (Wellcome Foundation):

“The test is whether the hypothetical addressee faced with the same problem would have taken as a matter of routine whatever steps might have led from the prior art to the invention, whether they be the steps of the inventor or not.” (at [45], underlining added)

180. In considering the question of what constitutes “a matter of routine”, in Aktiebolaget Hassle v Alphapharm Pty Ltd [2002] HCA 59; (2002) 212 CLR 411; (2002) 194 ALR 485; (2002) 77 ALJR 398, it was stated at [53]:

“That way of approaching the matter has an affinity with the reformulation of the ‘Cripps question’ by Graham J in Olin Mathieson Chemical Corporation v Biorex Laboratories Ltd. This Court had been referred to Olin in the argument in Wellcome Foundation. Graham J had posed the question:

‘Would the notional research group at the relevant date, in all the circumstances, which include a knowledge of all the relevant prior art and of the facts of the nature and success of chlorpromazine, directly be led as a matter of course to try the -CF3 substitution in the “2” position in place of the -Cl atom in chlorpromazine or in any other body which, apart from the -CF3 substitution, has the other characteristics of the formula of claim 1, in the expectation that it might well produce a useful alternative to or better drug than chlorpromazine or a body useful for any other purpose?’ (emphasis added)

That approach should be accepted.” (original emphasis, reference(s) omitted)

181. In Lockwood Security Products Pty Ltd v Doric Products Pty Ltd (No 2) [2007] HCA 21; (2007) 235 ALR 202; 81 ALJR 1070, it was stated:

“In Alphapharm, this Court reiterated that ‘obvious’ means ‘very plain’, as stated by the English Court of Appeal in General Tire & Rubber Co v Firestone Tyre and Rubber Co Ltd. The majority in Alphapharm also confirmed that the question of whether an invention is obvious is a question of fact, that is, it is what was once a ‘jury question’. Broadly speaking, the question is not a question of what is obvious to a court. As well as being a question of fact, the question of determining whether a patent involves an inventive step is also ‘one of degree and often it is by no means easy’, because ingenuity is relative, depending as it does on relevant states of common general knowledge …

Further, as recognised in Beecham Group Ltd’s (Amoxycillin) Application, as a basic premise, obviousness and inventiveness are antitheses and the question is always ‘is the step taken over the prior art an “obvious step” or “an inventive step”’? An inventive step is often an issue ‘borne out by the evidence of the experts’. There is no distinction between obviousness and a lack of inventive step. A ‘scintilla of invention’ remains sufficient in Australian law to support the validity of a patent. In R D Werner Lockhart J stated that there must be ‘some difficulty overcome, some barrier crossed’. This is consonant with older authorities in the United Kingdom which recognised that some inventiveness was required to distinguish patentable advances over the prior art from advances which ‘any fool’ could devise. It also accords with the requirement in the United States that for an invention to be ‘non-obvious’ it must be ‘beyond the skill of the calling’.” (at [51]-[52], underlining added, reference(s) omitted)

182. It is important to note that obviousness is a question of fact that is to be established by evidence. 

The Examiner’s objection  

183. The Last Report contains the following objection with respect to inventive step:

“The invention defined in claims 1 - 43 does not involve an inventive step in the light of D1.

D1 discloses a method that manages a reservation yield in a manner accounting for and utilizing the option to dynamically reconfigure resources. In one embodiment, a reservation request to be seated in a restaurant is received, wherein the request is associated with a requested seating constraint. The reservation request is transferred to a restaurant capacity calculation module, wherein the restaurant capacity calculation module is further associated with a data facility including data relating to restaurant capacity and configuration. A calculation is performed within a capacity calculation module to determine if sufficient capacity exists at the restaurant to accommodate the reservation request. A statistical calculation is performed within a yield management calculation module, wherein the statistical calculation includes analysis of alternate physical arrangements of the restaurant’s physical infrastructure to select a set of possible target physical arrangements. See Abstract, Table 5; Figs. 1-8 and the related description.

The claimed invention differs from the cited art in that D1 does not take into consideration the dimensions of furniture items.

However D1 does disclose making use of table configurations and table capacity while making the bookings. Furthermore, D1 discloses the analysis of restaurant’s physical infrastructure to target physical arrangement.

I consider that this difference constitutes no more than a mere workshop improvement. It is an arrangement that any competent worker in the art would be expected to make directly and without difficulty and by routine steps alone.”

Is the claimed invention obvious?

184. As I emphasised above, obviousness is a question of fact that is to be established by evidence.  During the process of examination however, the examiners are very seldom in possession of any evidence.  Instead, in assessing inventive step, they rely (as in the present case) on their technical expertise as per Commissioner of Patents v Emperor Sports Pty Ltd [2006] FCAFC 26, where the Full Court stated at [24]:

“The Commissioner is an administrative decision-maker equipped with technical expertise. Subject to the rules of natural justice both common law and statutory (see e.g. s 101(2)), he or she is entitled to make use of that expertise, and draw inferences that may be rationally drawn from technical knowledge, including how skilled persons of various descriptions may act in their respective occupations …”

In contrast, to support its view that the claimed invention is not obvious, the Applicant provides evidence from the listed inventor, Mr Petroulas, as well as from an independent expert, Dr Feldman. 

185. In addition, I must note that despite the frequent references to the claimed invention, it appears that a substantial part of the Applicant’s arguments on inventive step are based on features and functionality that are not easily identifiable at least in claim 1.

186. In light of the above comments, the decision on obviousness may not be straightforward and would likely require a comprehensive in-depth analysis of the available evidence on the matter and the Examiner’s position.  On the other hand, it appears to me that the inventive step objection in the Last Report is not as detailed as the manner of manufacture objection, which creates the impression that the Examiner regarded the inventive step issues as somewhat a lesser hurdle to the acceptance of the Application in comparison to the seriousness of the issues with respect to manner of manufacture.  Importantly, I must note that my earlier analysis and conclusions on manner of manufacture indeed suggest that any conclusive decision on obviousness would be inconsequential and superfluous, as it will not affect the final outcome and the consequences of my decision.

187. In these specific circumstances, given my decision that the claimed invention is not a manner of manufacture and, more importantly, that this deficiency cannot be overcome by an allowable amendment, I can see no real benefit to the Applicant or the general public in conclusively deciding on the question of obviousness.   

CONCLUSION

188. The Applicant’s Summary concludes with the following submission (underlining added):

“277. For the reasons given above, the Patent Applicant seeks the following relief:

a. Acceptance of the Application; or in the alternative

b. A finding that the Application, as a whole, contains patentable subject matter, and that the Application be remitted to examination so that the Applicant may have an opportunity to amend the Application to comply with all requirements under the Act.”

189. I have established that the invention claimed in any one of the claims is not a manner of manufacture, hence I cannot direct that the Application be accepted.  Based on the disclosure of the Specification, I have also established that my negative finding with respect to manner of manufacture cannot be rectified by an allowable amendment.  In other words, I have not found “that the Application, as a whole, contains patentable subject matter”. 

190. In addition, I note that the Applicant was provided sufficient opportunities to present its case in its written submissions before the hearing, oral submissions during the hearing, and further focused written submissions after the hearing. 

191. In the circumstances of the case, having regard to the public interest, I consider that it is appropriate to refuse the Application, regardless of whether the claimed invention is obvious or not.

Dr V. Z. Kolev
Delegate of the Commissioner of Patents

Actions
Download as PDF Download as Word Document
Cases Citing This Decision

0

Cases Cited

9

Statutory Material Cited

0

Wellcome Foundation Ltd v VR Laboratories (Aust) Pty Ltd [1981] HCA 12
Network Ten Pty Ltd v TCN Channel Nine Pty Ltd [2004] HCA 14
Aktiebolaget Hassle v Alphapharm Pty Ltd [2002] HCA 59