A delegate of the Commissioner of Patents has refused an application (no. 2018204629) by Amazon Technologies, Inc (Amazon) on the basis that it is not for a patent-eligible invention under Australia’s ‘manner of manufacture’ requirement: Amazon Technologies, Inc [2021] APO 7. Amazon’s claimed invention relates to the execution of processing tasks within a cloud computing system, presumably such as its own Amazon Web Services (AWS) platform. Specifically, it provides a mechanism for applications executing on ‘virtual machines’ within the cloud system to access additional resources as required during bursts of high demand.
This is yet another case in which a computer-implemented invention that appears at least superficially ‘technical’ has been found to be unpatentable because it is, as a matter of ‘substance’, in fact an ineligible business innovation, rather than a technical innovation. There are many, many, words in Amazon’s main claims, and a lot of them seem highly technical, principally because they define the operation of a process within a technical system. But does this mean that the inventive process is, itself, technical in nature? The delegate determined that it is not. He found that Amazon’s claims were directed to a scheme in which ‘business rules’ are applied for scheduling processing tasks, while the scheduler itself was performing only its ‘usual independent function’, with ‘no improved operation of the computing technology’.
In this case, I think that the delegate’s decision is a reasonable application of the law on patent-eligibility of computer-implemented inventions, as it has been interpreted by the Australian courts. It is, however, a long decision, which could not fairly be described as light reading. It is unfortunate that decision-making in this area of the law has become increasingly arcane and obtuse. So rather than picking over the delegate’s decision, dissecting the lengthy patent claims, or reviewing the Federal Court authorities, I am instead going to do my best to explain Amazon’s invention and why it failed the patent-eligibility test in my own way, as plainly as I can. And while I believe that the delegate’s decision is justified under the current law, I shall also explain why I think the law under-emphasises the technical context in which inventions such as Amazon’s are devised, and why a more nuanced approach might be more appropriate.
The Problem – Managing Varying Demand for Finite Resources
According to the description provided in the patent specification, users of a cloud computing system (such as AWS) may have a ‘baseline’ utilisation guarantee. For example, users may pay a fixed monthly fee, in exchange for which they receive a guaranteed minimum availability of resources, such as CPU processing power (i.e. the total amount of CPU time available to the user’s application over a set real time period). In such a system, if each user application is allocated a baseline utilisation equivalent to, say, one tenth of the available CPU capacity of a particular physical cloud computing device, and no application ever exceeds this baseline, then clearly ten applications can be assigned to the physical device without any application being adversely affected by any other application at any time.
However, this is not how many real-world applications behave. A large e-commerce web site, for example, requires computing resources that depend upon the number of consumers shopping at any given point in time. Such sites experience daily fluctuations, as the number of online users varies in different time zones. They may also experience bursts of particularly high demand, such as during events such as sales, or in the lead-up to Christmas or other peak shopping periods. A particularly extreme example is that of a ticketing web site, which may experience a huge spike in demand when tickets for an especially popular event initially go on-sale. We all have experience, or at least heard stories, of web sites ‘crashing’ under conditions of high demand.
One of the major selling points of cloud computing platforms is their ability to ‘scale’ under such fluctuating loads. Given the choice between owning, operating and maintaining enough hardware to accommodate peak application demand – which may stand largely idle for the majority of the time – or alternatively paying a cloud provider to host the application within its own large server farms, the cloud solution will often be more cost-effective. Cloud service providers, for their part, can aggregate resource utilisation over huge numbers of applications so as to avoid operating idle, unproductive, hardware. Baseline guarantees provide baseline income (whether or not the resources are actually used), while additional fees can be charged for above-baseline utilisation.
In doing so, however, cloud providers need to assign resources intelligently, so as to avoid (or, at least, minimise) situations in which too many applications executing on a single computing device demand high utilisation simultaneously, thus exhausting the available capacity and adversely impacting other users. To some degree, this is achieved by taking into account the statistics of resource demand when designing the cloud system, allocating applications to hardware, and scheduling work. But it is also useful to find ways to control demand, as well as modelling and predicting it.
Technical versus Non-Technical Solutions
The issue of resource allocation and scheduling in the presence of fluctuating demand is not new with cloud computing – it is at least as old as pre-digital circuit-switched telephone networks. In that case, the problem that arose was to determine how many circuits to provide, e.g. in each telephone exchange, to ensure that when a subscriber picks up their phone there will (probably) be a circuit available, so that they will most likely hear dial-tone instead of an engaged signal. In modern digital networks, an analogous problem is that of how much bandwidth and buffer memory to provide, e.g. in each router, to ensure that there is sufficient capacity to pass all traffic through, without incurring excessive delays or data loss.
Some of the solutions to these problems are technical in nature, such as flow control and traffic-shaping protocols in data networks. Others, however, are non technical. For example, per-minute charging for phone calls (increasingly a thing of the past in digitised networks where the overwhelming majority of traffic is non-voice) does not really reflect the substantially fixed costs of operating a circuit-switched telephone network. However, it does provide an incentive for subscribers to limit the duration of their phone calls, thereby freeing up resources for other customers to use.
Broadly speaking, under Australian patent law as currently interpreted by the courts, technical methods for improving the performance of networks or systems – implemented in software or otherwise – are considered patentable. However, purely business-based processes, including ‘social engineering’ of user behaviour through mechanisms such as price-signalling – even if implemented within a technical system – are not.
Viewed this way, the question becomes: which category does Amazon’s solution fall into? Is it, substantively, a technical or business process?
Amazon’s Solution – Technical Process or Business Scheme?
The solution described and claimed in Amazon’s patent specification is undoubtedly elegant and clever. The idea is simple enough (by which I do not mean to imply it is obvious, absent hindsight). An application that is operating at or below its baseline utilisation accumulates ‘resource credits’ in accordance with a ‘resource credit accumulation rate’, e.g. a specific number of resource credits may be added to the application’s balance for each fixed time period during which the baseline utilisation is not exceeded. Subsequently, when the application needs to perform additional processing that exceeds its baseline allocation, it can ‘spend’ the accumulated resource credits to obtain the required additional capacity.
This system clearly provides an incentive for developers to design applications that are generally ‘well-behaved’, in the sense that they stay below their baseline utilisation most of the time, and limit their additional demand-based processing to a level that does not exhaust the accumulated resource credits. This, in practice, constrains ‘burstiness’ and the long-term average utilisation, which doubtless assists the cloud service provider to manage its systems more efficiently.
But is the substance of this a technical process or a business process?
Certainly, it has a technical implementation, to which the many technical terms and steps in the claim attest. But the implementation is pretty trivial: its is little more than a per-application counter that ticks up when the application is operating below baseline, and ratchets back down when the application demands additional resources. All of the technical ‘complexity’ arises from describing this simple mechanism in the context of resource allocation and scheduling within a cloud computing system. And while this system is certainly complex technology, it is not part of the invention. It all already existed before the invention was devised.
So even if the resource credits system is a clever idea, it is nonetheless little more than a price-signalling scheme: applications receive a certain amount of ‘free’ above-baseline capacity in exchange for time spent at or below their baseline utilisation. It is analogous to giving a telephone subscriber a certain number of free long-distance call minutes in exchange for all the time they spend not making long-distance phone calls.
As the law is currently interpreted by the Australia courts, without further ingenuity in the technical implementation such a scheme is not patent-eligible subject matter.
The Patent Office Decision
As I have said, the Patent Office decision makes for fairly heavy reading. It is 79 paragraphs long. It gets bogged down in detail, largely due to the way in which examination of the application proceeded, the way the applicant’s case was argued, the length and level of technical content in the patent specification and claims, and the increasingly arcane and convoluted nature of the prior Federal Court and Patent Office decisions that are relied upon to guide the reasoning in these cases. It is fair to say that it frequently becomes hard to see the forest for the trees. I do not envy the hearing officers who have to write these decisions!
Whereas I have characterised the substance of the invention as a ‘price-signalling scheme’, the delegate describes it as a ‘scheme for scheduling work’. Taken literally, I do not think that is quite right – the claims do not purport to define any new method of scheduling tasks; rather, they are directed to how the scheduled tasks are ‘paid’ for (i.e. through the accumulation and consumption of resource credits). But I think the delegate is well-aware of this (see, e.g., the first sentence of paragraph [75] of the decision), and the difference in language used to characterise the invention is a result of the way the case was argued by the applicant, and the particular line of reasoning employed in the decision.
The ultimate reasons for the delegate’s finding that the application does not disclose of claim a patent-eligible ‘manner of manufacture’ are set out at paragraphs [73]-[75]:
[73] … it is apparent that on the one hand the claimed invention produces a practical and useful result in some situations, and that the claimed invention does provide a combination of new and known elements to form a working combination that had not previously been achieved. … The working combination arises only through the individual elements of the computing resource doing the job they were designed for by completing work request that have been scheduled based on a set of business rules defined around resource credits for baseline and burst performance. Any interaction between elements only arises through the way tasks are scheduled based on business rules and each individual computer resource per se is ultimately only doing what it is natively designed for.
[74] … there is no improvement to the technology that is utilised and there is no improvement in the functioning of the computing resources per se. There is no technical innovation in how tasks are scheduled; they are scheduled based on business rules only. The computer hardware and software associated with the claimed features such as the virtualisation manager and scheduler are merely performing their usual independent function, there being no improved operation of the computing technology and no device of specific character. The solution to the applicant’s problem does not arise from an improvement that is technical in nature or in the way the computing resources are utilised. The applicant’s problem of efficiently utilising fixed computing resources when their client has unpredictable demands is only solved by structuring the provision of their computing resources around what I describe as a service level agreement that includes a baseline guarantee and burst performance.
[75] In view of the above … it is reasonable to conclude that the substance of the invention, both as claimed and described, is directed to a business innovation where a level of service is provided by the applicant on the basis of a payment scheme for resource credits and a resource allocation policy in the form of the baseline guarantee and burst performance if sufficient credits have been accumulated. The business rules around the resource credits and baseline guarantee are set to ensure work requests are scheduled on the applicant’s computing resources such they are utilised most effectively. It follows that the substance of the invention as claimed in claim 1 amounts to nothing more than a scheme for scheduling work and is therefore not for a manner of manufacture.
Conclusion – Should Technical Context be Given More Weight?
The Australian law on patent-eligibility of computer-implemented invention, as it currently stands, requires a decision-maker to determine the ‘substance of the invention’, irrespective of the actual language used to define it in a patent claim. Under this approach, the substance in Amazon’s case is a form of price-signalling (or ‘work scheduling’, in the delegate’s language), which is not patent-eligible. Furthermore, there is no additional ingenuity in the technical implementation. All of the inventiveness resides in the idea of operating the resource credit scheme. When it comes to computer-implemented inventions of this type, the courts have been clear – an ineligible scheme, without some further ingenuity in the implementation, remains ineligible.
But is this how it should be? There is, it seems to me, an unstated assumption in this approach that the inventor is unconstrained by the technical environment when devising a solution to the problem at hand – which was, in this case, how to influence the behaviour of user applications so as to enable a cloud platform provider to make more efficient use of available computing resources. But, in practice, there are technical constraints on the inventor. Whatever solution is devised, it needs to be compatible with the technical systems in which it is to be implemented. The fact that, ultimately, the implementation itself might turn out to be trivial is beside the point. Indeed, a complicated scheme with a trivial implementation might well be a better, and more ingenious, solution that a simple scheme with a complicated and potentially bug-prone implementation. The inventor needs to keep all of this in mind when approaching the problem.
The current approach in Australia artificially divorces the non-technical elements of the invention from its technical implementation. This does not reflect the reality of the inventor’s task, which is to develop a solution that is not only effective, but also practical in the sense that it can be implemented within the target system. The inventor thus has both aspects in mind simultaneously when working on the problem, and does not set out to ‘invent’ specifically in relation to one or the other. The law then comes along later and says ‘sorry, but it turns out that the substance of your contribution lies entirely within the ineligible process, and not at all in its technical implementation, therefore no patent for you!’
The law on patent-eligibility of computer-implemented inventions has largely developed in recent years through a series of Full Federal Court decisions that all relate to software described as executing on entirely standard or ‘generic’ computer platforms. In this sense, there were no real technical constraints on the implementation, other than those inherent in any software development project – a fact that was generally admitted in the patent specifications.
I would argue that the law needs to develop in a more nuanced way to deal with cases in which real technical constraints are a material consideration. This does not mean ignoring the requirement to identify the ‘substance’ of the invention, which is a directive that comes down from the High Court. Rather, it means acknowledging that there is a difference between identifying the substance as ‘a price-signalling scheme’ versus ‘the implementation of a practical price-signalling scheme within the resource allocation and scheduling system of a cloud computing platform.’
Interestingly, the decision of Justice Burley in Aristocrat Technologies Australia Pty Limited v Commissioner of Patents [2020] FCA 778 (see Federal Court Finds Computer-Implemented Gaming Machine Patent-Eligible in Australia) could perhaps be interpreted in this light. In finding that Aristocrat’s claims were not directed to patent-ineligible game rules implemented on a generic computer, but rather to ‘a machine of a particular construction which implements a gaming function’, Justice Burley gave weight to specific hardware components of casino gaming machines included in the claims, and to the regulatory constraints under which such machines operate. We are currently awaiting a decision in an appeal filed by the Commissioner of Patents in that case, which was heard by a Full bench of the Federal Court on 11 November 2020. Whatever the outcome of the appeal, however, I do not expect it to have any impact on the approach taken when the particularity of the technical context is primarily provided by a software, rather than hardware, environment.
0 comments:
Post a Comment