Patent Applicant: Accenture Global Solutions Limited
[2022] APO 35
•18 May 2022
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Accenture Global Solutions Limited [2022] APO 35
Patent Application: 2019229447
Title:AUTOMATED ORDER TROUBLESHOOTING
Patent Applicant: Accenture Global Solutions Limited
Delegate:B. Norman
Decision Date: 18 May 2022
Hearing Date: Written submissions filed on 21 April 2021
Catchwords: PATENTS – standard patent – examiner’s objection – manner of manufacture – substance of the invention lies in predicting an event from historical data and taking a remediation action based on the hypothesis – all claims lack a manner of manufacture – no patentable subject matter in application – application refused.
Representation: Patent attorney for the applicant: Murray Trento & Associates Pty Ltd
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2019229447
Title:AUTOMATED ORDER TROUBLESHOOTING
Patent Applicant: Accenture Global Solutions Limited
Date of Decision: 18 May 2022
DECISION
None of the claims are for a manner of manufacture. There is no material within the application that would lead to a manner of manufacture if made the subject of a claim. The application is refused.
REASONS FOR DECISION
Background
Application 2019229447 was filed on 13 September 2019 by Accenture Global Solutions Limited (the Applicant) and, under the provisions of the Paris Convention, claims priority from US Application 16/159,428 which was filed on 12 October 2018.
A request for examination of the application was filed on 13 September 2019, along with a request for the postponement of acceptance. A request to expedite examination was filed on the 13 February 2020.
The first examination report issued on 25 February 2020 raising objections under the grounds of manner of manufacture, novelty, and inventive step. The applicant responded on 30 July 2020, proposing amendments to the claims. A second examination report issued on 26 August 2020, maintaining the manner of manufacture objection alone. The Applicant responded to this report on 24 December 2020 proposing further amendments to the claims. A third examination report was issued on 21 January 2021 maintaining the manner of manufacture objection alone.
On 24 February 2021, the applicant wrote to the Commissioner requesting to be heard in this matter. The written submissions for the hearing were filed on 21 April 2021.
Applicable Law
Because the application was filed after 15 April 2013 examination is governed by the Patents Act 1990 (the Act) as amended by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012. Accordingly, the standard of proof that applies is the balance of probabilities. 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.
Specification
My consideration is the specification as per the latest proposed amendments filed 24 December 2020.
The present invention relates to an automated order troubleshooting system. The system monitors sales-specific data to identify an operation behavioural pattern based on predefined rules. Subsequently a model based on this pattern is constructed using a pre-existing behaviour model library. Using the behaviour model, a potential event relating to an order received to be fulfilled using the sales operation is predicted, the potential event being indicative of an issue affecting the order. Accordingly, the issue affecting the order can be proactively remediated to automatically troubleshoot the order.
The specification notes that steps in the sales operation that involve logistics and supply chain activities may be particularly prone to errors and exceptions that may affect the order delivery. For example, unavailability of the product or the occurrence of an event which may cause delay or cancellation of the order.
The specification further notes that this represents a ‘technical’ problem wherein the existing infrastructure used for managing the last leg of the order may be unable to do so in an effective or an efficient manner[1].
[1] Paragraph [0004] of the Description.
It is important to distinguish that the term ‘order’ whilst used in the description with respect to computation resources and demand, is referring to a purchase request and not a list of priority or processing sequence. This is exemplified in one implementation of the invention as depicted in Figure 2B:
In the above Figure, block 200 is able to capture an order or request for a service. Block 206 uses the behaviour model to predict if an issue will arise in the captured order. Where an issue is identified, it will resolve the issue with a remediation action.
The behaviour model creation and deployment of Block 206 is described when applied to an embodiment used for the electronics and high-technology for the financial service industry and depicted in Figure 3 as reproduced blow:
In this embodiment, the invention is being used to forecast the system resources required for the kind of workload in the encountered in the financial systems industry[2]. The current order for resources is compared to the current behaviour model to predict whether the resources ordered reflect would be expected as being required by the financial industry[3]. If the invention identifies an issue or inconsistency with the ordered resources, it investigates this and provides a recommendation for a better order to remediate the issue[4]. An example of factors it can consider is depicted Figure 8 as reproduced below.
[2] Paragraph [0055] of the Description.
[3] Paragraph [0063] of the Description.
[4] Paragraph [0057] of the Description.
In this embodiment, the system can model the computational demands of a client. The resolver is then able to address the main issues that can arise. When the invention identifies that the order might not meet client’s needs, it would make recommendations as to how the order could be adjusted to address the forecasted issue.
The resolver is also able track and monitor the status of an order continuously to allow for remediation as depicted in Figure 9:
The function of Block 904 in the above figure is also described as being able to predict the effects of natural calamities or geo-political events that may affect the order.[5]
[5] Paragraph [0074] of the Description
With respect to the hardware platform the invention is to be carried out on, this is shown in Figure. 10 reproduced below:
The platform depicted above is generic and described as being such computing machines as but not limited to: internal/external server clusters, quantum computers, desktops, laptops, smartphones, tablets and wearables[6].
[6] Paragraph [0075] of the Description
Putting aside that the item numbers listed in the description don’t appear to correspond to the Figure 10 (both as filed and as proposed), the specific hardware of the platform described in the form of standard computing hardware. Storage devices are as listed as being RAM, ROM, EPROM or EEPROM[7]. Similarly, instructions are kept in either the storage device or the RAM[8]. The output and input devices described are equally standard computing devices, for example: mobile phone screens, laptop screens, keyboards, touchscreens etc[9]. The network communicator is listed as being a generic LAN adapter or a wireless adapter[10]. The specification does not describe any unique or specialised hardware being used in the platform.
[7] Paragraph [0076] of the Description
[8] Paragraph [0077] of the Description
[9] Paragraph [0078] of the Description
[10] Paragraph [0079] of the Description
The specification as proposed to be amended ends with 17 claims of which three, claims 1, 7 and 13, are independent. Claim 1 reads as follows, with integers prefixed (in bold) to identify the individual features more easily:
An Order Troubleshooting Automation (OTA) system including:
a behavior model constructor including:
(1) a pattern identifier that:
(a)monitors sales-specific data sources associated with at least one of a process, an organization, or an industry relevant for sales operations; and
(b)identifies an operation behavioral pattern from the monitored sales-specific data, based on predefined rules, the predefined rules configured based on the at least one of the process, the organization, or the industry; and
(2)a modellor to construct a behavior model capturing the operation behavioral pattern using a pre-existing behavior model library to trace a sales-to-delivery process of a sales operation from order placement to delivery thereby capturing possible points of failure in the sales-to-delivery process; and
(3) an issue predictor including:
a model deployer to:
(a)deploy the behavior model to predict a potential event relating to a failure of an order received to be fulfilled using the sales operation, based on the behavior model, wherein the potential event is indicative of an issue causing failure of the fulfillment of the order,
(b) generate a hypothesis based on historical data; and
(c) provide a recommendation based on the hypothesis to remediate the issue, and
(4) a resolver to proactively remediate the issue causing failure of the fulfillment of the order thereby automatically troubleshooting the order.
Claim 7 reads, again, with corresponding integers prefixed to identify features more easily:
A method including:
(1)(a)monitoring sales-specific data sources associated with at least one of a process, an organization, or an industry relevant for sales operations;
(b)identifying an operation behavioral pattern from the monitored sales-specific data, based on predefined rules, the predefined rules configured based on the at least one of the process, the organization, or the industry;
(2)constructing a behavior model capturing the operation behavioral pattern using a pre-existing behavior model library to trace a sales-to-delivery process of a sales operation from order placement to delivery thereby capturing possible points of failure in the sales-to-delivery process;
(3)(a)predicting a potential event relating to a failure of an order received to be fulfilled using the sales operation, based on the behavior model, wherein the potential event is indicative of an issue causing failure of the fulfillment of the order; and
(4)remediating, proactively, the issue causing failure of the fulfillment of the order thereby automatically troubleshooting the order, wherein the remediating includes:
(b) generating a hypothesis based on historical data; and
(c)providing a recommendation based on the hypothesis to remediate the issue.
Finally Claim 13 reads, again, with corresponding integers prefixed to identify features more easily:
A non-transitory computer readable medium including machine readable instructions that are executable by a processor that cause the processor to:
(1)(a)monitor sales-specific data sources associated with at least one of a process, an organization, or an industry relevant for sales operations;
(b)identify an operation behavioral pattern from the monitored sales-specific data, based on predefined rules, the predefined rules configured based on the at least one of the process, the organization, or the industry;
(2)construct a behavior model capturing the operation behavioral pattern using a pre-existing behavior model library to trace a sales-to-delivery process of a sales operation from order placement to delivery thereby capturing possible points of failure in the sales-to-delivery process;
(3)(a)predict a potential event relating to a failure of an order received to be fulfilled using the sales operation, based on the behavior model, wherein the potential event is indicative of an issue causing failure of the fulfillment of the order;
(b) generate a hypothesis based on historical data;
(c)provide a recommendation based on the hypothesis to remediate the issue; and
(4)remediate, proactively, the issue causing failure of the fulfillment of the order thereby automatically troubleshooting the order.
As can be seen above, the three independent claims would appear to define similar features, and represent the different forms in which the alleged invention is implemented. No issues regarding the construction of the claims were raised during examination.
The appended claims are directed to further defining the method of troubleshooting as claimed in the independent claims.
Claims 2, 8 & 14 define investigating previously encountered exceptions during a sales process and previously raised issues during the sales process to identify the issue causing failure of the fulfillment of the order.
Claims 3, 9 & 16 are limited in that the modellor captures a plurality of steps of the sales operation, each of the plurality of steps being identified as an issue-causing juncture in the sales operation.
Claims 4 & 11 are limited in that the modellor traces the sales operation from order placement to final delivery to predict the potential event.
Claim 5, 11,& 15 are limited in investigating the order to determine whether the order conforms with the behavioral model or not, based on the operation behavioral pattern associated with the order; generates a hypothesis for the order, when the order does not conform to the behavioral model; and incorporates the hypothesis in the behavioral model to predict the potential event.
Claims 6, 12 & 17 define generating an alert for stakeholders in the sales operation, in response to the prediction of the potential event.
Construction of the Claims
Starting with Claim 1, the system can be divided into core components which I have previously numbered above for convenience.
Integers 1.1.a and 1.1.b would appear to be defining what I would describe as a data mining feature of the system; whereby sales-specific data sources are data mined to identify behaviour patterns based on either the process itself, or the organisation/industry to which the sales-specific data relates. The specification defines the term ‘sales operation’ as products and services sold or offered: [11]
For the purposes of this disclosure, the term "sales operation" intends to cover the sales operations conducted by a service provider in a manner of selling the product and the services as well as the operation by a client in a manner of placing orders for the products and services offered by various service providers, sellers, and manufacturers.
[11] Paragraph [0024] of the Description
The example of monitoring of these sales operations is the data mining of various websites[12]:
For instance, in case the party implementing the automated order troubleshooting technique of the present disclosure is the service provider, then the process or the organization or the industry can be related to either the client that the service provider caters to or the industry or field that the service provider operates in. On the other hand, for instance, if the party implementing the automated order troubleshooting is a client, then the monitoring of the process, the organization, and the industry can be related to the industry or field that the client operates in or the standard industry-specific processes that the client would implement. The monitoring of the sales operations can be achieved, in real-time, by querying various data bases and repositories of information, online as well as offline, from which the relevant data can be retrieved. For example, social media, online web portals, and other websites that carry information regarding the process, the organization, the industry, or a combination thereof can be crawled for retrieving and monitoring the above mentioned information.
[12] Paragraph [0025] of the Description
The specification makes it clear that operation behavioural patterns are based on the sales specific data: [13]
Once the sales-specific data has been retrieved and stored, an operation behavioral pattern can be identified based on the sales-specific data. In an example, the behavioral pattern so identified can indicate, based on the sales-specific data, the current and future trends that can affect, for instance, demand and supply in the industry, and difference in the current trends from previous trends. The operation behavioral pattern can be identified using the sales-specific data based on predefined rules, the predefined rules mirroring the process, the organization, and the industry relevant for the party conducting the automated order troubleshooting. In an example, the predefined rules can be based on historically recorded cases for that ordering process in that industry, process, organization, and the like.
[13] Paragraph [0026] of the Description
This example of ‘sales specific data’ is also repeated at Paragraph [0081].
Whilst it is clear that this integer is gathering relevant data for a heuristic model, the ‘sales-specific data’ does not appear in any way technical given the examples mentioned in the specification. Instead, it would appear to be business process data pertaining to the products or services ordered.
Integer 2 takes the aforementioned data in Integer 1 to create a working model to represent the process itself, or the organisation/industry to which the sales-specific data relates, including possible failure points. I consider that this is a process of formulating a set of data relevant for analysis, using predefined structure templates from a ‘pre-existing behavior model library’.
Integer 3.a is using the model above on current order to predict a potential issue that would cause failure of the order. This issue is characterised in the specification as being an event having either a direct or indirect influence:[14]:
As part of deployment of the behavior model, any potential event relating to the order received to be fulfilled using the sales operation is predicted based on the behavior model. The potential event is indicative of an issue that can affect the order directly or indirectly. For example, a direct influence can be in the form of a real and present event, such as a natural calamity, that can affect the order fulfilment. An indirect influence can be in the form of an economic, political, or social situation brewing in a region which may affect demand or supply, in turn, potentially affecting the order. In addition, as mentioned previously, the prediction of the order being affected can be from the point of view of the service provider or of the consumer. In either case, the factors may be same or similar. As mentioned previously, the behavior model is built to trace the sales operation from order placement to final delivery to predict the potential event.
[14] Paragraph [0029] of the Description
Integer 3.b specifically is using the model to identify or hypothesise what the nature of the issue will be based on the ‘historical’ sales-specific data, and Integer 3.c is selecting the appropriate remediation action. However, the specification explains that the remediation may be in the form of simply generating an alert to stakeholders:[15]
In case an event that can potentially affect the order is predicted, automatic troubleshooting of the order is initiated and proactive remediation of the issue affecting the order is achieved. For example, in one case, a hypothesis is generated based on historical data and a recommendation for resolving the issue is provided based on the hypothesis. In addition, as part of automation of order troubleshooting, an alert can be generated for all stakeholders, such as sales team, operations team, delivery teams, and validation teams, in the sales operation, in response to the prediction of the potential event, which in turn indicates the issue affecting the order. This may allow the stakeholders to pre-emptively provide a resolution to the identified issue.
[15] Paragraph [0031] of the Description
Integer 4 defines that the aforementioned appropriate remediation act is carried out automatically.
The appended claims seek to further define this method of automated troubleshooting, specifically in which data is considered and the steps taken to determine an issue has occurred.
Claims 2, 8 & 14 define that the Integer 3 investigates previously encountered exceptions during a sales process and previously raised issues during the sales process to identify the issue causing failure of the fulfillment of the order. This is merely defining the nature of the data to be heuristically analysed.
Claims 3, 9 & 16 define that the Integer 2 captures a plurality of steps of the sales operation, each of the plurality of steps being identified as an issue-causing juncture in the sales operation. This is merely defining the nature of the data in the method.
Claims 4 & 10 define that the Integer 2 traces the sales operation from order placement to final delivery to predict the potential event. Again, this is merely defining the nature of the data.
Claims 5 & 11 & 15 define that a model augmenter determines whether an order conforms to the behavioural model of Integer 1 and generates a hypothesis when it does not. This would appear to be the main mechanism by which the invention is able to determine an issue has occurred.
Lastly, claims 6, 12 & 17 define that integer 4 now generates an alert for stakeholders in the sales operation in response to the prediction of the potential event.
Manner Of Manufacture
Section 18(1)(a) of the Act provides that an invention is a patentable invention for the purposes of a standard patent if the invention, so far as claimed in any claim, is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies
The classic statement of the law on manner of manufacture is set out in National Research Development Corporation v Commissioner of Patents [1959] HCA 67, 102 CLR 252 (NRDC) at 269:
"The right question is: 'Is this a proper subject of letters patent according to the principles which have been developed for the application of s. 6 of the Statute of Monopolies?'
The Court then went on to set out a test in terms applicable to the facts of that case:
"a process, to fall within the limits of patentability which the context of the Statute of Monopolies has supplied, must be one that offers some advantage which is material, in the sense that the process belongs to a useful art as distinct from a fine art ... that its value to the country is in the field of economic endeavour."
The Court, however, has cautioned that any attempt to state the ambit of section 6 of the Statute of Monopolies by precisely defining “manufacture” is likely to fail and, further, “to attempt to place upon the idea the fetters of an exact verbal formula...would be unsound to the point of folly” (at 277). These cautionary observations were later reinforced in D’Arcy v Myriad Genetics Inc [2015] HCA 35 (Myriad) at [23]:
“This Court in NRDC did not prescribe a well-defined pathway for the development of the concept of ‘manner of manufacture’ in its application to unimagined technologies with unimagined characteristics and implications. Rather, it authorised a case-by-case methodology.”
This case-by-case methodology must have regard to the substance of the claimed invention, not simply the literal form of the claim. As stated in Myriad at [144]:
“Whatever words have been used, the matter must be looked at as one of substance and effect must be given to the true nature of the claim.”
In Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177 (RPL), the Full Court stated at [96]:
“A claimed invention must be examined to ascertain whether it is in substance a scheme or plan or whether it can broadly be described as an improvement in computer technology. The basis for the analysis starts with the fact that a business method, or mere scheme, is not, per se, patentable. The fact that it is a scheme or business method does not exclude it from properly being the subject of letters patent, but it must be more than that. There must be more than an abstract idea; it must involve the creation of an artificial state of affairs where the computer is integral to the invention, rather than a mere tool in which the invention is performed. Where the claimed invention is to a computerised business method, the invention must lie in that computerisation. It is not a patentable invention simply to “put” a business method “into” a computer to implement the business method using the computer for its well- known and understood functions”.
In relation to computer implemented inventions, the Full Court in RPL at [99-100] reiterated a number of considerations arising from the earlier Full Court decision in Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150:
- Is the contribution to the claimed invention technical in nature?
- Does the invention solve a ‘technical’ problem within the computer or outside the computer?
- Does it result in an improvement in the functioning of the computer?
- Does the claimed method merely require generic computer implementation?
- Is the computer merely the intermediary, configured to carry out the method using a computer readable medium containing program code for performing the method, but adding nothing to the substance of the idea?
- Is the invention for a technological innovation which is patentable or for a business innovation which is not?
A detailed analysis of the relevant case law was provided by the Delegate in Aristocrat Technologies Australia Pty Limited [2016] APO 49 (ARISTOCRAT). I do not consider it necessary to reiterate the Delegate’s analysis, however I will emphasise the use of his non-exhaustive list of considerations. At [35]:
“I conclude that it is relevant to consider a range of matters. Without seeking to be exhaustive, these include:
·there must be more than an abstract idea, mere scheme or mere intellectual information;
·is the contribution of the claimed invention technical in nature;
·does the invention solve a technical problem within the computer or outside the computer;
·does the invention result in improvement in the functioning of the computer, irrespective of the data being processed;
·does the application of the method produce a practical and useful result;
·can it be broadly described as an improvement in computer technology;
·does the method merely require generic computer implementation;
·is the computer merely an intermediary or tool for performing the method while adding nothing of substance to the idea;
·is there ingenuity in the way in which the computer is utilised;
·does the invention involve steps that are foreign to the normal use of computers; and
·does the invention lie in the generation, presentation or arrangement of intellectual information.”
The Examiner’s Objection
In the third examination report the examiner maintained an objection that the claims lacked a Manner of Manufacture. To summarise the objection, the Examiner considered the invention used known functions of a standard computer to automate the process of predicting the issues for troubleshooting an order. With respect to the substance of the claimed invention, the examiner construed this as lying in a scheme of automating the process of predicting issues affecting service orders using a behaviour model. Thus, when considering the substance of the invention, the examiner considered that the computer described was merely an intermediary to the working of the claimed invention.
The Applicants Submissions
The submissions of the Applicant comprise a total of three pages, with reference to previous decisions by the office, as mentioned below, and those statements by the examiner which the Applicant disagreed with.
With respect to the substance of the claimed invention as defined, the Applicant submitted:
“In the Applicant’s respectful submission, the Examiner has incorrectly characterised the substance of the presently claimed invention and continues to assert an inappropriate requirement for the presently pending claims to be considered to comprise a manner of manufacture, namely, the requirement for a “technical improvement” in the computer technology without due consideration regarding a possible improvement in respect of “how” the computer technology is used.”
In regard to Jagwood Pty Ltd [2020] APO 38 (JAGWOOD), a recent decision by a Delegate of the Commissioner, the Applicant submitted:
“With respect to the objection detailed in the most recently issued Examination Report, the Examiner seemingly only considers the recent decision in Jagwood to the extent that the Examiner confirms that assessment of the presently pending claims was made with respect to each individual claim as a combination of features. However, the Examiner does not address the Applicant’s submission regarding paragraph [83] of the JAGWOOD decision in which the Hearing Officer concluded with respect to the JAGWOOD claims that “…it is a technical solution because the synergistic utilisation of technology overcomes the problems faced by the inventor…”.”
After submitting that the office’s decision in eBay Inc. [2020] APO (EBAY) clarified the considerations of ARISTOCRAT, the Applicant further submitted:
“The Applicant respectfully submits that the Examiner has failed to afford due weight to various features presently recited in the pending claims regarding the contribution of those various features, or combinations thereof, to the invention and in particular, to the proactive remediation of an issue causing failure of the fulfilment of an order resulting in the invention thereby automatically troubleshooting orders. The Applicant respectfully submits that the presently pending claims clearly give rise to a practical and useful result and the contribution of the combination of technical features is technical in nature thereby satisfying the two considerations that were considered satisfied in the recent EBAY decision and sufficient for the EBAY claims to comprise a manner of manufacture.”
The Applicant also submitted:
“More particularly, whilst the Examiner asserts in the Third Examination report that “…the provision of using data to deploy the behaviour model to predict a potential event relating to the failure of an order received to be fulfilled using the sales operation or to generate a hypothesis based upon historical data and provide a recommendation based upon the hypothesis to remediate the issue is considered to be implementing a business process and is not a technical solution…”, the Applicant respectfully submits that the Examiner’s characterisation in this regard is incorrect and this particular combination of features should be considered to comprise technical features that contribute to the claimed invention being “technical in nature”.”
Manner of Manufacture Considerations
To ultimately decide patentability I must determine what is the substance of the claims. Whilst it is for the decisionmaker to arrive at this determination independently, it is a worthwhile starting point to consider what was suggested as the substance of the claims during examination.
In the third examination report, the examiner characterised the substance of the claims to be (with my emphasis added):
“As stated previously, I maintain the substance of the invention merely lies in the scheme of automating the process of predicting issues affecting service orders using a behavior model (based on factors or events, for example, social, economic, or political situation that can affect the business. [para 0022, para 0029, para 0057]).”
However, the Applicants submissions with respect to the substance were not as clear:
“…the Examiner has incorrectly characterised the substance of the presently claimed invention and continues to assert an inappropriate requirement for the presently pending claims to be considered to comprise a manner of manufacture, namely, the requirement for a “technical improvement” in the computer technology without due consideration regarding a possible improvement in respect of “how” the computer technology is used.”
Whilst it is no surprise that the Applicant does not agree with the examiner’s characterisation of the claims’ substance, I could not find in their submissions any alternative offered as the specific definition of substance of the claimed invention.
Noting the brevity of the Applicant’s submissions, I also reviewed the Applicant’s response to the second examination report, where the Applicant stated:
“The Applicant respectfully disagrees and contends that the present claims (as amended) include various technical features that, in combination, provide at least technical effects of, generating a hypothesis based upon historical data, providing a recommendation based on the hypothesis to remediate the issue and proactively remediating the issue causing failure of the fulfilment of the order thereby automatically troubleshooting the order.”
Similarly in this response, the Applicant further stated:
“…the claimed invention seeks to address problems associated with existing infrastructure for managing the last aspect of an order which are unable to provide the necessary information regarding external factors that can affect the ordering decisions of a client. Problems associated with existing infrastructure clearly reside in the technical realm and are neither administrative nor business problems.”
It would appear that the Applicant was submitting at the time that the claimed invention is able to identify issues within the process that are not ordinarily detected or indicated by the existing infrastructure, remediate them, and that this should be considered to lie within the technical realm. I consider that being able to predict or identify issues not normally detectable or indicatable can lie in the technical realm, provided those issues are of a technical nature themselves.
However, I consider that the issues provided as examples in the specification are not technical issues, but general issues affecting the sales order. I would consider issues of this nature to be business issues.
In determining the substance of the claims, it is helpful to refer to the list of touchstones used by the Delegate in ARISTOCRAT.
Is the contribution to the claimed invention technical in nature?
The contribution of the claimed invention lies in predicting or identifying an event is likely to occur by comparing sales order date to the historical sales order data in the lens of a relevant model. With this event identified, the system can then propose a remediation action.
I do not consider this contribution to be technical in nature, as it is purely the analysis of business data applied to address a business problem. Whilst in implementing the invention there may be technical difficulties to overcome via a technical solution, they are neither defined in the claims nor disclosed in the specification.
Whilst the Applicant made submissions that problems could relate to an event arising from an issue in infrastructure (and thus potentially technical), this is not defined in the claims, and there are no specifics proposed as to the nature of the remedial action.
Does the application of the method produce a practical and useful result?
With respect to the Applicant’s submission that the claimed invention gives rise a practical and useful result, nothing moves on this. Whilst a “practical and useful result” was a consideration applied in both of the Office decisions of ARISTOCRAT and EBAY, I fail to see any confirmation in the case law that this is all that is needed to confer patentability. There is also an important distinction in the case of the EBAY, as the Delegate found at [41] that the practical and useful result was present along with an invention of a technical nature (my emphasis added):
“Obtaining congestion information during the course of an event is clearly a technical problem that requires a technical solution and processing that information in a manner to present it to the user in the form of a recommended route to avoid the congestion is addressing a real and physical problem that, when implemented as per the claims, does produce a practical and useful result that is not related to a business process or business rules.”
Does the invention require merely “generic computer implementation”, as distinct from steps which are “foreign” to the normal use of computers?
With respect to whether the claimed invention relies on specific software to implement the invention, when I consult the specification, I can find no examples of specific coding or algorithms, or certain hardware arrangements necessary to implement the invention. I must conclude the skilled addressee is expected to implement the steps of the claimed invention using ordinary routine programming principles, coding, and computer architecture.
Thus, I must conclude that the claimed invention only requires generic or standard computer implementation.
Is there an improvement in the functioning of the computer, irrespective of the data being processed?
I cannot ascertain any improvement in the functioning of any of the computerised apparatus used within the claim, irrespective of the data being processed. As discussed above, the computerised devices present in the claim are merely used for their standard or known abilities to process, generate, present and exchange data.
Is the computer merely an intermediary, configured to carry out the method using program code for performing the method, but adding nothing to the substance of the idea?
The specification does no more than describe the architecture of the hardware in a most general sense. I have noted the broad description that the specification provides of the hardware by reference to the architecture set out in Figure 10. I have also noted statements in the Specification[16] to the effect that the method may be implemented on any form of hardware from server clusters to wearable devices. This is a broad range of hardware platforms, and it is reasonable to conclude that the described and claimed hardware represents standard computer technology. The only mention of specific hardware components is in the context of a type of ‘sale’ to be troubleshooted (i.e., the purchase of aforementioned hardware). These factors indicate that neither the system architecture, the hardware nor the software required to achieve these outcomes form part of the invention. They point to the fact that the troubleshooting scheme using historical data of previous sales orders is simply implemented by the normal and usual instrumentality of computer hardware and software.
[16] Paragraphs [0075]-[0079] of the Description
In fact, despite its length and detail, the specification contains no integer that serves to characterise the invention by reference to the implementation of the scheme beyond the most general application of computer technology utilised in an online environment. The claims amount to instructions to carry out the sale troubleshooting scheme. The level of abstraction at which it is expressed demonstrates that it does no more than provide a list of steps to be implemented using computer technology for its well-known and understood functions. Nothing in the specification suggests otherwise. The computer is thus an intermediary.
Does the invention solve a technical problem within the computer or outside the computer?
It is not apparent that the claimed invention solves a technical problem within or without the computerised apparatus or systems concerned. Merely providing a set of steps for troubleshoot an order automatically using known or standard computing technology is not addressing any technical difficulty as such. Nothing within the claim appears to address or overcome any technical difficulties.
Conclusion
Turning to the factors above, I have found that the invention is not technical in nature in not addressing a technical problem, and employs generic or standard computer technology. The computer technology is used for its well-known and understood functions as a tool to perform the relevant method. In terms of there being a “practical and useful result”, I am of the view that the claimed invention can be characterised as providing, in the most general sense of the phrase, a “practical and useful result” in that it provides a remediation action in an automated order troubleshooting system. The fact that there might be a “practical and useful result” of some broadly labelled kind does not change my conclusion that the claimed invention is in substance directed to a mere scheme.
The substance of the claim, on the face of the specification alone, is a mere computer implemented scheme for predicting and automatically troubleshooting problems in the sales delivery process by heuristically analysing the historical sales order data to form a hypothesis. I cannot find anything technical ingenuity in this substance as the claim defines these steps in broad, high-level features. The effect of the invention is to improve the business scheme to automatically adjust a client’s order based on predicted issues due to real world events affecting the order.
Claims 7 and 13 define almost identical features to Claim 1 but in the form of either a method or software program, and thus the substance of these claims are effectively identical to that which I have identified above. Any differences have no bearing in my consideration as they pertain to matters of form.
The appended claims seek to further define this method of automated troubleshooting, specifically in which data is considered and the steps taken to determine an issue has occurred.
Thus, when I consider each of the appended claims, I consider the substance of each of these claims to be merely further details of the troubleshooting scheme. At no point does the substance of the claimed invention ever progress beyond an abstract idea or scheme.
I must conclude that the substance of the claimed invention remains a mere scheme or business method. Therefore Claims 1-17 are not for a manner of manufacture and thus are directed to unpatentable subject matter.
I conclude that the claimed invention, as a matter of substance, is not for a manner of manufacture. My analysis of the specification in this decision provides a clear picture of the nature of the subject matter described in the whole of the specification. The claims as they currently stand are simply directed towards a scheme for managing the sales process and remediating issues that may arise in provision or delivery of goods. In addition, I see no material in the application that could be made the subject of a claim so as to result in that claim being for a manner of manufacture. I therefore refuse the application.
B. Norman
Delegate of the Commissioner of Patents
0
5
0