Jason Bayley - [2023] APO 25

IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Jason Bayley [2023] APO 25

Patent Application: 2016431877
Title:Method and system for preserving and processing vehicle crash data evidence

Applicant:  Jason Bayley
Delegate:  Dr N. R. Madsen – Deputy Commissioner of Patents
Decision Date:  9 May 2023
Hearing Date:  Written submissions filed 7 March 2023 and 5 April 2023

Catchwords: PATENTS – section 45 – examiner’s objection – extracting and sharing crash data from a vehicle – invention in substance directed to a mere scheme – alleged invention not a manner of manufacture – application refused

Representation: Patent attorney for the applicant: Wallington-Dummer

IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2016431877
Title:Method and system for preserving and processing vehicle crash data evidence

Applicant: Jason Bayley
Date of Decision: 9 May 2023
DECISION
The claims of the patent application, as proposed to be amended, do not define a manner of manufacture. I am unable to find patentable material in the specification.

I refuse the application.
REASONS FOR DECISION
BACKGROUND

Jason Bayley (“the applicant”) filed patent application 2016431877 on 7 December 2016 as an application under the Patent Cooperation Treaty. The application has an earliest priority date matching the date of its filing. The application entered the national phase in Australia and was subject to three examination reports. Each report has contained an objection that the application is not directed to patentable subject matter as failing the requirements for manner of manufacture. After the third examination report the applicant requested to be heard in respect of the outstanding manner of manufacture objection.
The examination of the present application is governed by the Patents Act 1990 (“the Act”) as amended by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012 (“the Raising the Bar Act”) as the application was filed after 15 April 2013. Thus, I must accept the application if satisfied on the balance of probabilities that the application complies with the Act. If I am not so satisfied, then I can refuse the application. Also, the final date for acceptance of the application was 17 November 2022. With this in mind, paragraph 13.4(1)(g) of the Patent Regulations 1991 is available to extend the time for gaining acceptance to 3 months from the date of the present decision (or longer if appropriate via subregulation 13.4(3)). Suffice to say, if an application is refused, there is no function to this time period.
The applicant was provided until 7 March 2023 to file submissions. After reviewing material on file related to the state of the art and concluding that this appeared insufficient, I provided a further period for the applicant to file submissions as to the state of the art.
SPECIFICATION
The description is short consisting of 12 pages, and begins by stating that conventionally, preserving stored vehicle crash data has required specialised knowledge and equipment. It adds at that[1]:
Vehicle telematics systems utilized by various companies have been capable of capturing and transmitting live vehicle data (data similar to that stored internally on vehicle modules following a crash event), but telematics data only includes transmission of live data through its communication network. The telematics technology is used by fleets, insurance companies or specific vehicle manufacturers, and aids in contacting a response center following a detected collision; this system then notifies the police and insurance companies about the accident. Further, there are some fleets, or insurance-based drivers who have opted to have their driving habits monitored with UBI (User-Based Insurance) telematics adapters for an insurance discount. These telematics adapters provide some meaningful data about the vehicle and driver's actions surrounding a collision, which can help insurance claims professionals assess liability and expedite claim processing.
[1] Specification at [0002]
The specification[2] then also states that privacy laws prevent adoption of these arrangements by the public, which effectively means that important crash data is not easily or economically accessible following the majority of vehicle collisions. Adding to this is the point noted by the specification that live telematic transmission of data is not considered scientifically reliable, pointing to a need for reliable crash event data that is useful as unbiassed evidence for automobile accidents. The specification[3] thus points to the need for:
…new methods and system to facilitate and enable economic preservation of crash data evidence for any motor collision. There is also a need of methods and systems that eliminate the physical presence of an expert with the required equipment at the vehicle to collect the vehicle crash data. Further, there is also a need of methods and systems to access the vehicle crash data globally.
[2] Specification at [0003]
[3] Specification at [0004]
After discussing some prior art in the field, and generally summarising embodiment of the invention in consistory clauses, the specification moves to a detailed discussion of the invention.
FIG. 1 (below) is presented primarily as an exemplary system to preserve and process crash data. It consists of an on-board diagnostic (OBD) adapter 108 that extracts vehicle crash data from a module 114 on the vehicle via an on-board diagnostic port. A Bluetooth connection may be made between the on-board diagnostic adapter and a user device such as a mobile phone 106. User device 106 (which may be any general computing device but appears most suitably a mobile smart phone) comprises programming adequate to request and receive responses for extracting vehicle crash data from the OBD port of the vehicle via the OBD adapter. This vehicle crash data includes information such as the detection of impacts, accelerations at impact, vehicle speed, brake and accelerator pedal driver inputs, activation of a vehicle airbag, and presence of an unbelted occupant[4].
[4] Specification at [0025]
At this point it is clear to me that what is being discussed by the specification as potentially enabling the operation of the invention is technology similar to a Bluetooth vehicle diagnostic code reader. I understand that diagnostic trouble code (DTC) readers are a type of device commonly used by mechanics to check engine warning light codes and also check for codes and information stored on various modules of a vehicle. For some time now and since prior to the priority date of the application, such tools have also been available to the consumer market for identifying all manner of electronically recorded issues in a vehicle and for monitoring performance. Any quick search of the internet reveals the prevalence of such inexpensive technology that may operate wirelessly as depicted in FIG. 1, or via a hardwired data transfer, from an on-board diagnostic port of a vehicle. Patent US 8750904 provided as background to the invention as discussed in the specification[5] refers to such technology and envisages operation wirelessly[6]. In their submissions for the hearing, the applicant also points to a Wikipedia[7] article that discusses on-board diagnostics parameter IDs (OBD-II PIDs) and their use since before the turn of the century as codes used to request data from a vehicle via the vehicle’s diagnostic port. The applicant notes that “for each vehicle type, there are specific OBD-II PIDs”.
[5] Specification at [0006]
[6] US 8750904 B2 at columns 7 and 8
[7] >
In response to the opportunity that I provided to the applicant to address the state of the art in relevant vehicle diagnostic tools, the applicant pointed to a number of examples noting that crash data retrieval was specifically limited to tools provided by original equipment manufacturers. For example, the applicant points to tools that retrieved crash data via a vehicle’s OBD port using a hardwired connection and some kind of hardware interface between the vehicle and a computer, one of which being a Bosch™ crash data retrieval tool[8]. I accept that such hardwired connection was common, and it appears presumably operated as such to preserve proprietary access to modules developed by certain manufacturers. However, this does not detract from the availability of wireless connectivity and software sharing over the internet that was undoubtably well-known technology at the priority date of the present application.
[8]
I also understand that well prior to the priority date of the present application, tools were available to the public that enabled Bluetooth communication from an OBD port to a mobile phone assisted by a proprietary application, for the purpose of reading basic engine light codes along with enhanced code reading from vehicle modules. An example that I am aware of is the BlueDriver OBD2 diagnostic scan tool that comprises a Bluetooth dongle that connects with a vehicle’s OBD port and communicates with an application downloadable from common application stores. It is this tool that I specifically raised with the applicant for comment. This tool was available well before the priority date of the present application and was discussed in a YouTube video itself published well before the priority date of the present application[9]. In that YouTube video it is clear that the product operates in the manner depicted and described with reference to FIG. 1 items 106, 108 and 114, with there being specific reference in the video to the retrieval on a user device of diagnostic trouble codes associated with engine warning lights, in addition to the retrieval of codes stored on system modules including the transmission, antilock braking system (abs), and airbag modules on certain cars.
[9] “BlueDriver OBD2 Diagnostic Scan Tool Review (reads ABS, Airbag, Tranny Codes)” published 27 February 2015.
While appearing to acknowledge the prevalence of tools like the BlueDriver tool on the market, the applicant suggests that tool only reports diagnostic trouble codes and does not retrieve stored crash data. However, I note that the specification makes clear that vehicle crash data includes the activation of an airbag, there being DTCs for airbag activation that appear as standard prior to the priority date[10]. Regardless, to the extent that the claimed invention may retrieve information that relates to a vehicle crash additional to deployment of an airbag, this potential difference in functionality of the BlueDriver diagnostic scan tool when compared to the present invention would appear to lie in the type of data retrieved in terms of its content, and not any physical means of retrieval and sharing of data. I will expand on this idea throughout my decision.
[10] >
The specification notes[11] that the system of FIG. 1 may also include a remote application server 102 that serves to communicate with both the user device 106 and a separate computing device 112. The remote application server receives transmitted vehicle crash data and performs processing operations that may operate through various types of standard application serves such as a Java application server, a .NET framework application server, or any other application server framework[12]. The specification also notes that the application server may be realised on user computing device 106, however if they are separate devices the application server and user device can communicate through any suitable communication means[13]. The specification also notes crash event data being in the form of hexadecimal data. The use of hexadecimal data and certain data requests in respect of airbag deployment is further discussed in the specification as follows[14]:
The first programable instruction is a customer mobile application integrated with the user-computing device 106 to extract the crash event data. The crash event data is hexadecimal data stored in memory on the vehicle module, and preservation is handled programmatically and automated through pre-determined methods. Accessing the hexadecimal data stored on the vehicle airbag module 108 (sic) requires vehicle-specific bus and PID requests; where PIDs are On-board diagnostics Parameter IDs. In one embodiment, the hex data is retrieved by capturing responses from a sequence of PID code requests unique to the vehicle (i.e. varies based on vehicle year, make, model, airbag module, etc.). Once retrieved, the hexadecimal data is then transmitted over the communication network to a remote application server 102. The hexadecimal data is then processed for interpretation by plurality of second programmable instructions into data tables and a readable report format. In one embodiment, a software "plays back" the vehicle bus responses into hardware/software in the laboratory. The present system 100 bridges the gap between the vehicle and a crash data laboratory so that the physical presence of unique manufacturer's hardware/software for interpreting crash data is not always required at the vehicle. The vehicle communication process may occur offline (non-live connection to the remote laboratory). The hex data can be transmitted over the communication network at any time.
[11] Specification at [0027]
[12] Specification at [0028]
[13] Specification at [0030]
[14] Specification at [0031]
The specification provides no further specific detail as how the wireless communication occurs between the user device, OBD adapter and vehicle module. This can be said equally for the use of Bluetooth type technology as the facilitator of data transfer noting also that there are no details of the construction of the OBD adapter whatsoever discussed in the specification. With this in mind, and also bearing in mind the standard approach to requesting codes using parameter IDs discussed in the Wikipedia article, provided by the applicant, I see no option but to take it that standard and well-known technology is applied to the present invention in the context of the described and depicted retrieval of data from vehicle modules using a user device such as mobile phone. More specifically, it appears clear to me that person skilled in the art is well aware that data relevant to an airbag and its activation, and further data relevant to a crash, is stored in vehicle modules, in a manner that enables it to be read out when desired by an appropriate read out device, in particular potentially using Bluetooth technology transmitting to a generic type of user device.
Moving forward, in its hexadecimal form, the data read out still requires interpretation, and in the absence of local instructions for interpreting this data, data can be transmitted over a network via communication link 104 for interpretation at a remote location at any time. Such data handling, in conjunction with an arrangement of FIG. 1, is most closely related to the invention that is claimed. Ultimately, the data transferred to server 102 may be accessed remotely via a further computer 112 via a web connection for analysis.
FIG. 2 (below) provides a process for extracting crash data from a vehicle module. It involves determining user type and vehicle details before seeking to use a field user (such as a mechanic) to extract crash data using a universal OBD adapter and a mobile app (the technical operation of the universal OBD adapter here clearly assumed known by the person skilled in the art). If data is not retrievable by a field user the vehicle module is either shipped to a central lab, or specialised equipment is provided. I understand this is so because universal OBD adapters do not function at all times for all vehicles. While at times difficult to follow, the process map lays out some steps that can be followed in facilitating the extraction of crash data. Fundamentally, despite some uncertainties in the exact sequence(s) of actions defining the process, it is clear that the process map lays out a set of logistical steps that involve determination of appropriate readout equipment, and steps for shipping items to facilitate data collection. This process is a principal focus of the specification and was the subject of the claims in early stages of prosecution of the present application.
FIG. 3 (below) provides an exemplary web user interface for determining whether vehicles are supported for a crash data check, while FIG. 4 (not provided) is an exemplary chain of custody tracking form for use in conjunction with the aspects of the invention. They are not the focus of any of the claims.
The specification notes[15]:
Thus, the present method and system eliminates the need for travel to every vehicle to preserve crash event data, which also serves as an environmental benefit by reducing associated vehicle emissions. Further, the present method and system allow the user to access the vehicle crash data evidence globally. Furthermore, the present method and system extract the engineering hex data information from the airbag module, by sending and receiving a series of OBD-II PIDs. Thus, the present method and system provides various advantages including but not limited to preserving the vehicle crash data evidence for any motor vehicle collision, eliminating the physical presence of specialized equipment and a trained user at the vehicle to collect the vehicle crash data evidence, enabling accessibility to vehicle crash data evidence preservation globally etc.
[15] Specification at [0037]
The remainder of the specification then includes some rather “catch all” paragraphs that indicate concepts such as:
·     A combination of hardware and software may be a general-purpose computer system with a computer program that, when loaded and executed, may control the computer system such that it carries out the methods described herein.[16]
·     A person with ordinary skills in the art will appreciate that the systems, modules, and sub-modules have been illustrated and explained to serve as examples and should not be considered limiting in any manner.[17]
·     … the systems of the aforementioned embodiments may be implemented using a wide variety of suitable processes and system modules, and are not limited to any particular computer hardware, software, middleware, firmware, microcode, and the like.[18]
[16] Specification at [0038]
[17] Specification at [0039]
[18] Specification at [0041]
With their submission for the hearing filed on 7 March 2023, the applicant filed an amendment to the claimed invention, primarily directed to the inclusion of features related to use of parameter IDs. The set of 12 claims as proposed to be amended on 7 March 2023 includes two independent claims (claims 1 and 7). Claim 1 is to a method and claim 7 is to a system for performing the same functions as those of claim 1. I provide claim 1 as proposed to be amended here in full.
A method for preserving vehicle hexadecimal event data and further processing the vehicle hexadecimal event data, the method comprising:
selecting a specific vehicle from a list of vehicles supporting internal recording of crash event data;
receiving on a user-computing device instructions from a remote application server; said instructions including preservation steps for preserving event data stored in memory on a vehicle module of a vehicle, wherein the preservation steps include a plurality of on-board diagnostics parameter IDs which correspond to the specific vehicle;
establishing wireless communication between said user-computing device and a universal on-board diagnostic device plugged into an on-board diagnostic port of the vehicle; said universal on-board diagnostic device having a wireless device;
requesting, from the on-board diagnostic port of the vehicle, vehicle crash event data preserved onto an airbag module of the vehicle, wherein request includes said on-board diagnostics parameter IDs;
receiving hexadecimal data stored on the airbag module of the vehicle by capturing responses to said on-board diagnostics parameter IDs;
transmitting the vehicle crash event data from said on-board diagnostic port of the vehicle through the universal on-board diagnostic device to the user-computing device;
transmitting the hexadecimal data from the user-computing device to the remote application server through a communication network.

The claimed invention is relatively straight forward to construe, and I do not see any immediate issues of allowability of these new amendments in accordance with s102 of the Act, although I do not need to conclusively decide on this in view of the outcome of my decision. The claim is directed to a method that preserves and shares hexadecimal format data present in an airbag module. A first step in the claim is to check whether a vehicle in question supports internal recording of crash event data. Consistent with the specification I take it as a given in the art that some vehicles support recording of data relating to a crash event and airbag deployment, and some don’t, and the present invention is directed to vehicles that support such recording.
After a selection of a specific vehicle is made, a user computing device such as a mobile phone receives info (such as an “app”) from a remote server. This info includes instructions for preserving data stored on the vehicle module of the vehicle and involves on-board diagnostics parameter IDs which on the applicant’s own admission, are a standardised way of requesting vehicle fault/incident information. After receiving the info, a universal on-board diagnostic (OBD) adapter plugged into the relevant port on the vehicle and the OBD adapter may then communicate with the user computing device via a wireless connection (such as Bluetooth) in order for relevant data to be transferred from the vehicle to the user computing device. The transfer of data happens on the basis of a request from the on-board diagnostics port for data stored on the airbag module with use of the diagnostics parameter IDs. Finally, the hexadecimal data transferred to the user device from the universal on-board diagnostic device is transmitted from the user computing device to the remote application server.
Fundamentally the invention is directed to a determination from a list that a certain vehicle records data and following this the downloading of an instructions so that a mobile phone or similar can interact with an OBD device to retrieve the data. At this level the invention appears to generally follow the normal technical operation of OBD devices in retrieving vehicle codes and returning them to a user device. Such function of code retrieval is normally performed by a mechanic however as I noted earlier, products have been widely available on the market for performing such function without the help of a mechanic well before the priority date. Explicitly specific to this invention is the retrieval and analysis of certain hexadecimal data related to airbag operation, and the transmittal of hexadecimal vehicle crash data to a remote server following retrieval.
While the invention has been found inventive in examination, I find myself doubting inventiveness of the claimed features including the retrieval, and further sharing of specific data in view of my understanding of the art. However, given my findings under the ground of manner of manufacture I need not investigate this issue any further.
The dependent claims are directed towards features such as: processing vehicle crash data at the remote server; vehicle crash data being stored in a memory integrated with the airbag module; guiding the user to process data through a web user interface; accessing vehicle crash data through a web user interface; and converting the vehicle crash data into a readable report format. These features require no further analysis at this point.
MANNER OF MANUFACTURE LAW
In National Research Development Corporation v Commissioner of Patents[19], the High Court provided a statement of the law regarding manner of manufacture. At page 275:
“… 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”.
[19] [1959] HCA 67 (“NRDC”)
The High Court though was not laying down a precise formulation that can be applied unthinkingly. In D’Arcy v Myriad Genetics Inc[20] it was said:
“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.”
[20] [2015] HCA 35 (“Myriad”) at [23]
That case-by-case approach must have regard to the substance of the claimed invention, not simply the form of the claim. The point was made succinctly in the Myriad case by Gageler and Nettle JJ[21]:
“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.”
[21] Myriad at [144]
Thus, the assessment as to patentable subject matter in this context requires a consideration of the substance of the invention. To further guide the determination of patentable subject matter in the context of computer implemented inventions, a range of principles have been developed. The principles of law that apply to the present matter are themselves substantially uncontroversial, noting however that on a case-by-case basis at times they can be difficult to apply. These principles were usefully summarised and generally accepted by Robertson J in Rokt Pte Ltd v Commissioner of Patents[22] as follows:
[22] [2018] FCA 1988 (“Rokt 1”) at [189]
“17.1 The Court must decide, as matter of substance not form, whether the claimed invention is the proper subject-matter for a patent: RPL Central at [99]; Research Affiliates at [106], [117].
17.2       This requires consideration of both the claims of the Application and the invention described in the body of the specification: RPL Central at [114].
17.3       The assessment is not done mechanically. There are no precise guidelines or mathematical formula. It is ‘a question of understanding what has been the work of, the output of, and the result of, human ingenuity’ and then applying the developed principles: Research Affiliates at [116]. See further RPL Central at [112]:
Recognising that the claims are to a method and system comprising a combination of integers, it is necessary to understand where the inventiveness or ingenuity is said to lie ...
17.4       One well-settled principle is that a distinction exists between a technological innovation and a business innovation. A technological innovation is patentable. A business innovation is not: Research Affiliates at [94]; RPL Central at [100]. Consequently, a business method or scheme is not, per se, a proper subject for letters patent: RPL Central at [96]. Nor are abstract ideas, mere intellectual information or mere directions for use patentable: Research Affiliates at [101]; RPL Central at [100].
17.5       A computerised business method or scheme can, in some cases, be patentable. However, ‘[w]here the claimed invention is to a computerised business method, the invention must lie in that computerisation’: RPL Central at [96] (emphasis added). This requires ‘some ingenuity in the way in which the computer is used’: RPL Central at [104]. It is not a patentable invention ‘to simply “put” a business method “into” a computer to implement the business method using the computer for its well-known and understood functions’: RPL Central at [96]. In other words, if the ingenuity lies in the business method or scheme alone, the invention will not be patentable despite the computer-implementation.
17.6       Thus, 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: RPL Central at [96]. Contrary to [the applicant’s submissions at [49]], this is a binary distinction: the invention is either an unpatentable scheme or plan, or it is a patentable improvement in computer technology. In conducting the analysis, it is useful to:
17.6.1      ascertain whether the contribution to the claimed invention is technical in nature: RPL Central at [99], Research Affiliates at [114];
17.6.2      consider whether the invention solves a ‘technical’ problem within the computer or outside the computer: RPL Central at [99], Research Affiliates at [103];
17.6.3      consider whether the invention results in an improvement in the functioning of the computer, irrespective of the data being processed: RPL Central at [99], Research Affiliates at [118];
17.6.4      consider whether the invention requires merely ‘generic computer implementation’, as distinct from steps which are ‘foreign’ to the normal use of computers: RPL Central at [99], [102]; Research Affiliates at [101]; and
17.6.5      consider whether the computer is merely the intermediary, configured to carry out the method using program code for performing the method, but adding nothing to the substance of the idea: RPL Central at [99].”
The Full Federal Court decision in Commissionerof Patents v RoktPte Ltd[23] confirmed and applied these principles.
[23] [2020] FCAFC 86 (“Rokt 2”)
As also noted by the delegate in CareFusion 303, Inc[24] it is further necessary to have an eye to the state of the art in determining patentability. Such focus appears somewhat necessary to gaining an understanding of the locus of ingenuity. On this the observation was made in Myriad[25] that:
“This appeal, however, collapses the anterior and subsequent questions – ‘Is there an invention?’ and ‘Is there a patentable invention?’ – into one inquiry. That inquiry requires a definition of the allegedly patentable invention. That definition depends upon the construction of the impugned claims read in the light of the specification as a whole and the relevant prior art. The prior art in this case was reflected in expert evidence at trial and set out in the scientific primer agreed between the parties and summarised later in these reasons.”
[24] [2023] APO 17 at [54] and [55]
[25] Myriad at [12]
This approach remains relevant in view of subsequent Court decisions. In Commissioner of Patents v Aristocrat Technologies Pty Limited[26], it was found that a game implemented on an electronic gaming machine was not patentable. After first identifying the claimed invention as involving a mere game which was unpatentable, the Full Court asked whether the claimed invention was a computer-implemented invention before determining that for the claims to be patentable, there needed to be “an advance in computer technology”.
[26] [2021] FCAFC 202 (“Aristocrat ’21”)
On appeal to the High Court, in Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents[27] the Court was evenly split, and via s3(2)(a) of the Judiciary Act1903 affirmed the Aristocrat ’21 decision, while appearing to confirm that an advance in computer technology is not a useful test for patentability. Additionally, the High Court confirmed the decisions of the Full Federal Court in RPL Central[28], Research Affiliates[29], Encompass Corporation Pty Ltd v InfoTrack Pty Ltd[30], and Rokt 2 were correct. The High Court[31] also discussed the idea that an “adaptation or alteration of, or an addition to, technology otherwise well-known in the common general knowledge to accommodate the exigencies of a new idea or plan or game” would give rise to patentable subject matter. Such an idea appears consistent with the principles articulated in Rokt 1 which seek patentability residing in, for example, more than merely generic computer implementation; generally being steps which are foreign to the normal use of computers and where the computer is more than merely the intermediary, adding substance to the idea.
[27] [2022] HCA 29 (“Aristocrat ’22”)
[28] [2015] FCAFC 177 (“RPL Central”)
[29] [2014] FCAFC 150 (“Research Affiliates”)
[30] [2019] FCAFC 161 (“Encompass”)
[31] Aristocrat ’22 at [77]
EXAMINER’S OBJECTION
In the third examination report, the examiner included the following as the primary basis of their objection (noting the objection was directed to claims that included some different features):
“…the claimed invention, as a matter of substance, relates to a method and system for obtaining and analysing vehicle crash information from a vehicle; and that this is not patentable subject matter.
The Applicant has mentioned that 'claims directed at a technical aspect of a technical solution to a technical problem' will be suitable subject matter for a patent. That is correct; however, it is necessary to assess the claimed invention as a matter of substance over form. In particular, the mere presence of technical features in a claim does not necessarily mean that the claimed invention actually constitutes a technical solution to a technical problem.
It is mentioned that the collection of data in an environment where an airbag may have been deployed is a practical problem. However, the manner in which the data collection takes place is entirely generic, and relies solely on using well-known data collection systems for their routine functionality - for instance, establishing wireless communication to an on-board diagnostic device which may store vehicle crash data. The act of obtaining data from a device which exists solely to record data cannot reasonably be considered a technical solution to a problem.
I maintain that the substance of the invention relates not to any technical aspect of what is being performed, but rather with the non-technical details which characterise the scheme (e.g. the selection of a vehicle from a list; the analysis of crash data to diagnose whether or not an airbag was deployed; and the way in which the vehicle crash data is formatted); and that this does not constitute subject matter suitable for a patent.”
APPLICANT’S SUBMISSIONS
The applicant’s primary submissions are very brief. They are substantively as follows:
“Amended claim 1 (and amended claim 7) clarifies the technical features of: (1) detecting the vehicle type of a vehicle; (2) receiving on a user-computing device from the server OBD-II PIDs specific for the detected vehicle type; (3) sending to the airbag module of the vehicle the OBD-II PIDs via the universal on-board diagnostic device of the vehicle; and (4) receiving on the user computing device from the airbag module hexadecimal data by capturing responses to the OBDII PIDs.
The above technical features clarify that the technical solution is to allow for obtaining crash event data by plugging a universal device into the vehicle without having to provide a specific device for the vehicle. By contrast, the device of D1 (US 2013/0006469 A1 (GREEN WILLIAM BLEASE et al.) 3 January 2013) does not provide the ability to detect the vehicle type and receive from a remote server OBD-II PIDs specific for the detected vehicle type. This is because the device of D1 aims to independently detect various relevant data, for example, by using movement sensors, position sensors, etc.
The technical solution of the present invention allows simply plugging in a universal device to any vehicle, detecting the vehicle type of the vehicle, and receiving the required OBD-II PIDs, specifically for receiving hexadecimal data stored on the airbag module of the vehicle. This solution is useful when the universal onboard diagnostic device is plugged in after a traffic accident has occurred and for a short period of time, such that a single device can be used for obtaining the crash event data of any vehicle.”
I interpret this argument to be fundamentally proposing that there are technical features present in the claims that provide for a different means to data collection than that in prior art document D1. The applicant discusses the plugging in of a universal device to any vehicle and using OBD-II PIDs received from a server to retrieve data stored on the airbag module. They argue that this technical solution is useful such that a single device can be used for obtaining crash data from any vehicle.
Further addressing a subset of the state of the art which involved hardwired connection to OBD ports using a laptop device, in their latest submissions the applicant notes:
“These EDR Tools essentially retrieve accident data by using a laptop computer instead of a handheld device and a server. Consequently, a unique piece of software needs to be further installed every few months to keep up with vehicle support for the solutions listed above. In addition, there is no ability to monitor or control vehicle scan or data in the event that there is no server present in the data retrieval system. That is to say, the claimed invention has benefits over the identified state of the art as at the priority date.”
While there may be benefits of the present invention over certain aspects of the state of the art, it is important for me to consider the computer technology that existed at the priority date of the present invention, and whether any aspect of the substance of the present invention lies in the implementation of a method within certain computer technology.
CONSIDERATION
Generally speaking, the invention clearly involves the operation of features in a technical or physical context. Instructions are delivered from a server, and data is transferred from a vehicle module to a vehicle port and adapter, and to a mobile user device via for example, a Bluetooth connection using an adapter plugged into the port. The applicant, in their submissions, points to relevant technical features in this context.
While I do question how, on proper construction of the claim, a feature of “detecting” the vehicle type of a vehicle is present (as opposed to merely selecting from a list), this does not change the fact that the applicant is pointing to functionality in the claimed invention that involves the receipt of PID instructions from a remote server at a user computing device, the querying of a vehicle via an OBD port for data from the airbag module, and the receipt of requested data at the user computing device. Within this operation I clearly see the well-known and standard function of using OBD-II PIDs to request data from vehicle modules that I have discussed earlier in this decision. Such data is retrieved at a vehicle diagnostic port and routinely sent to a user device. No complexities, challenges or details of this physical exercise are provided by the specification as I have fully summarised above. More specifically, the specification provides no detail as to the universal on-board diagnostic device and its wireless function strongly suggesting this aspect of the invention is not part of the invention as a matter of substance.
The invention thus clearly involves the use of computer devices for well-known and well understood purposes, and the general manner in which the specification discusses such technology supports this position. However, it is clear that there is more to fully considering whether a claim is for a manner of manufacture than merely this point as has been articulated clearly in the Full Federal Court decisions that I have discussed above. In the context of the applicant’s submissions, I will seek to address a range of relevant factors.
Is the invention technical in nature? Does the invention solve a technical problem within or outside a computer?
Each of the inventions in Aristocrat ’21, RPL Central, Research Affiliates, Rokt 2 and Encompass as a matter of form, include the operation of a solution with technical elements. Aristocrat ’21 uses an electronic gaming machine with a suite of physical features; RPL Central, Rokt 2 and Encompass each involve a series computers/servers processing, sharing, and displaying data; and Research Affiliates involves a single computer processing and displaying data. Clearly, the presence of technical features in something that may be artificially labelled a “technical solution” is not itself sufficient to confer patentability. In deciding whether an invention is patentably technical as a matter of substance, it is often helpful to ask whether an invention solves a technical problem, be that within a computer or outside of a computer.
The problems that are sought to be addressed by the present application are first discussed as follows[32]:
…new methods and system to facilitate and enable economic preservation of crash data evidence for any motor collision. There is also a need of methods and systems that eliminate the physical presence of an expert with the required equipment at the vehicle to collect the vehicle crash data. Further, there is also a need of methods and systems to access the vehicle crash data globally.
before the specification also notes[33]:
Thus, the present method and system eliminates the need for travel to every vehicle to preserve crash event data, which also serves as an environmental benefit by reducing associated vehicle emissions. Further, the present method and system allow the user to access the vehicle crash data evidence globally. Furthermore, the present method and system extract the engineering hex data information from the airbag module, by sending and receiving a series of OBD-II PIDs. Thus, the present method and system provides various advantages including but not limited to preserving the vehicle crash data evidence for any motor vehicle collision, eliminating the physical presence of specialized equipment and a trained user at the vehicle to collect the vehicle crash data evidence, enabling accessibility to vehicle crash data evidence preservation globally etc.
[32] Specification at [0004]
[33] Specification at [0037]

To gather these ideas together, the specification poses addressing problems such as:
·     More economic preservation of crash data for motor vehicle collisions
·     Elimination of physical presence/travel of an expert with required equipment
·     Improved access to vehicle crash data globally
None of these problems relate to an identifiable technical issue with the relevant technology itself. They point to the desire to preserve crash data in a way that avoids the travel of a person to a site which may be achieved by providing global access to relevant data. Similarly, none of these problems relate to any identifiable technical issue outside of a computer. Each of these problems simply point to a desire for a better way to manage the obtaining and sharing of crash data such that untrained users can access the data, and to provide the data such that it is available to remote experts. Consistent with my construction of the claim and understanding of the state of the art, this is achieved using well-known technology that receives remote instructions in order to obtain particular airbag module data in a well-known manner, so as to then send that data to a remote server location such that it is retrievable by an expert. The problems solved as a matter of substance by the claimed invention are thus fundamentally administrative or even logistical. The ingenuitive solution, as a matter of substance, is directed to from where particular instructions are received, who implements the instructions to retrieve certain data, and where the retrieved data is sent thereby providing global access. The invention of claim 1 solves no technical problem.
Turning to the applicant’s submissions, the argument is made that the present invention differs from document D1 (which was cited by the examiner in their report merely as indicative of the state of the art) as there is no ability in D1 to receive instructions specific to a vehicle from a remote server. The claimed invention is directed towards the use of a “universal” device for data retrieval as opposed to the device of D1 that plugs into a cigarette lighter socket of a vehicle and carries its own sensors and programming instructions. It is clear that, in contrast to document D1, the claimed invention allows for obtaining crash event data by plugging a device into the supported vehicle without having to provide a specific device for the vehicle or a device that has preloaded programming instructions.
The problem with the approach of the applicant is that they seek to determine patentability of the invention having only regard to an isolated piece of prior art, which itself overlooks the well-known and well-understood computer technology that was available at the priority date for the retrieval of relevant data from vehicles. This is an inappropriate way to approach the question of patentability. The applicant’s own submissions point to the standard operation of OBD-II PIDs that are used to retrieve codes through vehicle OBD ports. On-board diagnostic devices, and wireless device capability for communication with programable user devices such as mobile phones were widely in use at the priority date. The invention is thus not in relation to solving any technical problem with respect to on-board diagnostic devices and technology of this type.
The technical operation of a universal device plugged into a vehicle port for retrieving diagnostic trouble codes for engines (“engine light codes”) and for retrieving codes from vehicle modules is not where the substance of the present invention lies. The specification is entirely silent on any relevant detail aside from the use of OBD-II PIDs themselves. Instead, the invention lies in a selection of the specific vehicle from a list of vehicles and remote receipt of instructions for retrieving hexadecimal data stored in an airbag module, and the sending of said hexadecimal data to a remote location, all using well-known and well-understood computer technology. Such an invention solves logistical or administrative problems that do not lie in a technical issue that can be identified within or outside of any piece or pieces of technology.
Does the invention result in an improvement in the functioning of the computer, irrespective of the data being processed? Does the invention require merely ‘generic computer implementation’, as distinct from steps which are ‘foreign’ to the normal use of computers?
Consistent with my discussion as to the problems solved by the invention of claim 1, I consider that there is clearly no improvement to the functioning of the relevant computer technology. The invention as a matter of substance relates to the transmission of certain data to and from certain locations and not to a better functioning piece or pieces of technology. Again, the normal uncharacterised function of wireless technology in the context of on-board diagnostic device operation is applied to the present invention. Data is merely selected, received, requested, and transmitted using well-known and well understood, wireless computer devices. While, as pointed out by the Full Court in Aristocrat ’21, it may not be useful to label the technology involving the plugging in of an OBD adapter as “generic”[34] (at least to the extent that the function and implementation in Research Affiliates, RPL Central, Encompass and Rokt 2 is clearly described in the most generic of terms including “computers”, “processors”, “systems”, “servers”, “engines”, “remote databases” and the like) and proceed on this basis alone, there are no steps in claim 1 that are foreign to the normal use of computer technology. The specification itself suggests as much by describing the implementation of data retrieval using a wireless OBD adapter from a vehicle in a manner that assumes the ability of the person skilled in the art to procure and construct such an adapter and perform the steps (see for example my discussion above at [7]-[12]). This is further supported by the standard nature of the use of OBD-II PIDs to obtain codes.
[34] See Aristocrat ’21 at [35]
In contrast to the other relevant Full Federal Court decisions, the claimed invention in Aristocrat ’21 involves a somewhat specifically described computer device (an electronic gaming machine). Similarly, regarding the use of certain identifiable elements of technology in an invention, the Federal Court judgement in Repipe Pty Ltd v Commissioner of Patents[35] discusses an invention where GPS and geofencing technology is incorporated into the claimed invention to facilitate functions of device tracking, location-based alerting, and data stamping. Recognising His Honour’s use of the term “generic”, I note in Repipe[36] McKerracher J commented on amended claims involving such geo-locating technology:
“There is a category of amendments which relates to the addition of two claims or features concerning GPS tracking, for example, claim 4 in the 943 Patent. But the hardware sought to be added is entirely generic and the functions to be performed are functions of computer technology as it presently exists. All that is disclosed is a scheme. For example, the amended claims disclose the use of GPS technology to gather location data to be used for cross-referencing and geofencing. The fact that the existing GPS technology may be put to use in a new scheme is not sufficient to constitute patentable subject matter. The generic technology is used in the same way it is normally used, albeit that it is applied in a new scheme. In this regard, the decision of the Court (Rares, Nicholas and Burley JJ) in Rokt (at [85]) is apposite:
The reference to using the computer for its ‘well-known and understood functions’ involved consideration of computers having regard to their basic and well-known functions. This did not require, and should not be taken to encourage, a review of the common general knowledge beyond the use of the common general knowledge, to the extent necessary, to construe the specification.”
[35] (No 3) [2021] FCA 31 (“Repipe”)
[36] Repipe at [67]
What I draw from this is that it is appropriate to view the computer technology of present claim 1 (being inclusive of the universal OBD device/adapter) as the use of said technology for its “well-known and understood functions”. While the present specification makes no explicit reference to the “well-known and understood” nature of universal on-board diagnostic devices with wireless capability, all I have done in arriving at my conclusion is bring an understanding of the state of the art, guided by the generic nature of the disclosure of the specification, necessary to construe the specification (which lacks any focus on the technical nature of the on-board diagnostic adapter and its interaction with the vehicle and user device) for the purpose of characterising the invention. Myriad makes clear that the characterisation of the invention depends upon the construction of the claims read in the light of the specification as a whole and the relevant prior art, which in that case was set out in an agreed scientific primer. I cannot ignore the well-known and well understood function of OBD devices in my construction of the present invention.
Turning again to FIG. 1 and the associated description of the invention it is clear to me that the specification poses no challenge that has been overcome by inventor in use of the relevant on-board diagnostic technology. The operation of such devices is not the focus of the specification or the claims, and instead the operation is described in terms of basic computerised steps involving data transfer and wireless operation, the specific instructions used to retrieve information themselves being admitted by the applicant as well-known.
Is the computer merely the intermediary, configured to carry out the method using program code for performing the method, but adding nothing to the substance of the idea?
The technology used to perform the method involved in the claimed invention is best depicted in FIG. 1. I have already discussed this figure to the extent that clearly involved are generic computers in the form of a laboratory computer, application server and a user device that function as information transmitters and receivers. The user device simply interacts with the OBD adapter in well-known ways, and the OBD adapter retrieves data from the vehicle in well-known ways. The invention thus presents similarities to the nature of the architecture used to perform the claimed invention in the Rokt matter. Fig. 3 of the relevant specification (provided below) was considered by the Full Court in Rokt 2[37]:
“The specification does no more than describe the architecture of the hardware in a most general sense. We have noted the broad description that the specification provides of the hardware by reference to the architecture set out in figure 3. We have also noted the statements at page 25 to the effect that the method may be implemented on any form of suitable server computer capable of communicating with consumer devices (such as smart phones) using typical web server hardware. The Background to the Invention recites the prior use of digital advertising systems whereby online consumers’ reactions to content are targeted by reference to their online interactions and personal attributes. 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 marketing scheme that involves the use of the engagement offer is simply implemented by the instrumentality of computer hardware and software. It is true to say that the specification on its face represents a solution to the marketing problem caused by insufficient engagement with targeted online advertising, but these factors suggest that the scheme whereby that is achieved does not involve the use of computer technology other than as a vehicle to implement the scheme.”
[37] Rokt 2 at [110]
I similarly consider the present technology as merely the vehicle or “intermediary” for the scheme of the present invention. The technology is described in the specification in the most general of senses. Any form of suitable computer technology may be used, and it is clear to me that data being wirelessly retrievable by OBD devices at OBD ports does not form part of the invention. I see the present invention as a scheme for data gathering and sharing that is simply implemented by computer technology in the context of a motor vehicle. More specifically I consider that the claimed invention can be characterised as a mere scheme comprising the steps of: selecting a compliant vehicle; a user receiving instructions remotely for retrieving data stored in a vehicle airbag module using standard and well-known technology such as a mobile phone; using standard and well-known technology to request and receive wirelessly a data transfer via an OBD port of a vehicle; the data being “crash data” in hexadecimal format stored in the airbag module of a vehicle; and sending the hexadecimal data from the user to a remote location using standard and well-known technology.
I conclude that independent claim 1 and similarly, claim 7 is not for a manner of manufacture. I have already discussed the specification in detail and note that aside from the very general discussion of the relevant technology, much focus is placed on logistical steps (FIG. 2) and the appearance of certain information presented to users (FIGs 3 and 4), these being clearly unpatentable. The dependent claims themselves add features of processing vehicle crash data at the remote server; vehicle crash data being stored in a memory integrated with the airbag module; guiding the user to process data through a web user interface; accessing vehicle crash data through a web user interface; and converting the vehicle crash data into a readable report format. These features either simply add more elements of the mere schematic steps such as processing data remotely, guiding a user through an interface and creating a report, or simply relate to further uses of well-known technology for well-known purposes, being storage of data and access of information through the web. I do not see any patentable subject matter in the remainder of the specification.
CONCLUSION
I agree with the examiner regarding the necessity of the objection to the claims. I see no patentable subject matter in the specification.
Consequently, it is appropriate that I refuse the application.
Dr N. R. Madsen
Deputy Commissioner of Patents