UbiPark Pty Ltd v TMA Capital Australia Pty Ltd

The 335 Patent 17 The patent application was filed on 6 August 2019 and granted on 21 January 2021. The application is a divisional application of Australian Patent Application No. 2016214965 (filed on 12 January 2016), which in turn claims priority from Australian Provisional Patent Application No. 2015900302 and Australian Innovation Patent Application No. 2015100112 (both filed on 2 February 2015). The content of those applications is incorporated by reference into the description in the 335 Patent: see [0001]. 18 As noted above, the specification of the patent states at [0002] that the invention "relates to a system, method, mobile communication device and one or more computer programs for an access control system for controlling access to a restricted area", for example a car park. 19 Background is provided at [0003] to [0008] of the patent. Relevantly for some of the issues in the proceeding, this section includes: [0003] When a driver of a vehicle wishes to park their vehicle in a parking station, a physical ticket is issued to the driver at the entry point when being granted access to the parking station. The driver can then present the ticket to a payment machine in order to pay for the time that the vehicle has been parked in the parking station. The ticket can then be presented to another ticket machine at an exit point to be allowed to leave the parking station. Such ticketing systems have numerous problems. For example, because of the design of particular vehicles and parking stations, some drivers find it difficult to collect the ticket from the ticket machine at the entry point or insert a ticket for reading with the ticket reader at the exit point without exiting the vehicle. Generally, the driver may also attempt to hold/find the ticket while driving within the parking station which can distract the driver and may result in accidents. Furthermore, if the ticket is lost by the driver, the driver is generally required to pay full fare in order to exit the parking station. Additionally, at busy parking stations, there can be an extensive queue of drivers at payment machines to pay for their respective parking. Furthermore, at busy parking stations, there can be a significant queue at the ticket issuing and reading machines due to the time spent by the driver collecting and inserting the ticket. [0004] Other problems exist for other applications where a person wishes to access a restricted area using an access control system. [0005] For example, a residential/commercial building may have an access control system for residential parking which can be activated by using a hand operated radio transmitter or a proximity card in order to open a gate, roller door or the like. As some drivers tend to attempt to locate the radio transmitter or proximity card prior to approaching the gate/door whilst driving in order to speed up the access process, the driver tends to become distracted which can lead to accidents. Furthermore, if a new user wishes to access the restricted parking area, a new hand held transmitter or proximity card may need to be ordered, particularly if the access control system is a proprietary system. [0006] In relation to building access control system, users may be required to carry an identification device, such as a proximity card or the like, which can be read by a reading device in order for an access controlled door or the like to be opened. However, a large number of users tend to store their identification device in a bag or wallet which in some instances must be removed in order to be read. This can be frustrating and time consuming for the user. Additionally, as users tend to carry a number of items when travelling through such access controlled doors, it is frustrating that a dedicated device, with no other purpose, needs to be carried with the user when attempting to access the restricted area. [0007] There is therefore a need to alleviate one or more of the above-mentioned problems or provide a commercial alternative. 20 The next section of the specification is headed "Summary" and comprises [0009]-[0031]. The first paragraph of this section reads: [0009] In one aspect there is provided a system including: a communication system; and a computer program executable by a mobile communication device associated with an entity, wherein the mobile communication device is configured to: receive one or more entry signals from the communication system when the entity approaches an entry point of a restricted area; generate and transfer, to the communication system, an entry request in response to receiving at least some of the one or more entry signals; receive, from the communication system, authorisation data indicative of the entity being granted access to enter the restricted area by an access control system; receive one or more exit signals from the communication system when the entity approaches an exit point of the restricted area; and generate and transfer, to the communication system and in response to receiving at least some of the one or more exit signals, an exit request indicative of the authorisation data in order to exit the restricted area. 21 The summary section includes the following paragraph referring to "key data", an expression that appears in claim 4: [0012] In certain embodiments, the system includes a server processing system and a data store accessible by the access control system, wherein: the server processing system is configured to: generate key data associated with the entity; transfer the key data to the mobile communication device for storage in memory; store the key data in the data store; wherein each entry and exit request generated by the mobile communication device is indicative of a key from the key data, wherein an access control processing system of the access control system queries the data store using the key to verify the validity of the entry request or exit request. 22 The summary section includes: [0014] ln certain embodiments, the communication system communicates with the mobile communication device using Bluetooth Low Energy protocol. [0015] In certain embodiments, the mobile communication device is configured to: determine a received signal strength of the one or more entry signals; and determine if the one or more entry criteria have been satisfied based at least partially upon the received signal strength of the one or more entry signals in order to generate and transfer the entry request. [0016] In certain embodiments, the mobile communication device is configured to: determine a received signal strength of the one or more exit signals; and determine if the one or more exit criteria have been satisfied based at least partially upon the received signal strength of the one or more exit signals in order to generate and transfer the exit request. … [0021] In certain embodiments, the mobile communication device is configured to automatically transfer at least one of the entry request and the exit request without user interaction. 23 The next section of the specification is headed "Brief Description of the figures" and comprises [0032]-[0047]. It is stated at [0032] that example embodiments should become apparent from the following description, and that the description is given by way of example only. Each of the figures is then identified. The figures are numbered from 1 to 15, including figures 10A to 10C and 11A to 11C. 24 The next section is headed "Detailed Description of Example Embodiments". It is reiterated at [0048] that these are examples only. This section contains a detailed description of, and discussion by reference to, Fig 3. That figure is as follows: 25 The description and discussion of Fig 3 is relevant to the construction issues. It includes: [0057] Referring to Figure 3 there is shown an example system 302 for use with an access control system 304 for a vehicular parking station. ln one form, the system 302 operates as a virtual ticketing system. The systems 302, 304 operate together to form system 300. [0058] In particular, the system 302 includes a communication system 306 associated with the vehicular parking station and a computer program 308 executable upon a mobile communication device 310. [0059] The mobile communication device 310 can be provided in the form of a processing device 100 and more specifically in the form of a smart phone, a tablet processing system or the like. In particular, the mobile communication device 310 generally includes a processor 102, memory 104, an input device 106, an output device 108, and a communication interface 112 coupled together via a bus. The input and output device 106, 108 can be provided in an integrated form such as a touch screen display. In particular embodiments, the mobile communication device 310 can include a camera device. The mobile communication device 310 is generally associated with an entity such as a user which could be a driver or a passenger of the vehicle. The computer program 308 can be provided in the form of a 'mobile app'. [0060] In use, the mobile communication device 310 could be located near the user in the vehicle, in the user's pocket, mounted within the vehicle, or the like. Preferably, the user does not need to interact with the mobile communication device 310 during use in order for communication to occur between the mobile communication device 310 and the communication system 206. Rather, the mobile communication device 310 is configured to automatically operate and communicate with the communication system without user input in order to enter and exit the restricted vehicular parking area. [0061] The access control system 304 of the vehicular parking station can be a ticket issuance system including an access control processing system 312, an entry controller 314 in the form of a ticket issuance machine at an entry point of the vehicular parking station, an exit controller 316 in the form of a ticket reading machine at the exit point of the vehicular parking station, an automated entry and exit assembly 318, 320 (e.g. an automatically controlled boom gate) at the respective entry and exit points, and a vehicular detection system 322. The access control processing system 312 can be provided in the form of processing system 100. [0062] Advantageously, the described system 302 can be retrofitted with an existing access control system 304 that currently issues physical tickets such that an entity has an option to receive authorisation data in the form of a virtual ticket to their respective mobile communication device 310. However, it is possible for the system 300 can be (sic) newly designed and installed which includes system 302. For the purposes of clarity, the entity [in] this example is a user associated with the mobile communication device 310. [0063] Referring more specifically to Figure 3, the communication system 306 is generally a local communication system that utilises wireless communication. The communication system 306 includes an entry communication system 324 including at least one entry communication device associated with the entry point of the restricted area and an exit communication system 326 including at least one exit communication device associated with the exit point of the restricted area. [0064] In a preferable form, the communication system 306 includes a plurality of entry communication devices associated with the entry point of the restricted area and a plurality of exit communication devices associated with the exit point of the restricted area. As will be described in more detail below, the use of multiple entry and exit communication devices can be advantageous to handle different mobile communication devices which have different communication characteristics (e.g. speed, communication sensitivity, etc.). [0065] More specifically, the entry communication system 324 includes a first entry communication device 334 located a short distance (i.e. 0.5 to 10 metres) prior to the ticket issuance machine 314 and the entry boom gate assembly 318 at the entry point of the parking station. Similarly, a first exit communication device 354 is located a small distance (i.e. 0.5 to 10 metres) prior to the ticket reading machine 316 and the exit boom gate assembly 320 at the exit point of the parking station. In one form, the first entry communication device 334 and the first exit communication device 354 are located inside respective bollards. The first entry and exit communication devices 334, 354 are preferably fixed devices. Preferably, the first entry communication device 334 and the first exit communication device communicate 354 use Bluetooth protocol such as Bluetooth Low Energy. The wireless signal transmitted by the first entry and exit communication devices are indicative of a unique device identity/address for the respective communication device. 26 In reference to Fig 5, which illustrates an isometric view of an example of an entry or exit communication device body, and in reference to the system depicted in Fig 3, it is stated: [0066] Referring to Figure 5 there is shown a communication device body 325 of the first entry communication device 334 or the first exit communication device 354 which has a parabolic internal shaped wall to define a directional antenna. Figures 6 to 9 [show] the communication device body assembled with a microcontroller 328 which is mounted to the rear surface of the communication device body 325. The microcontroller 328 is configured to perform various wireless communication processing. As can be seen in Figures 6 to 9, the antenna element 327 which is in electrical communication with the microcontroller 328, is located at a focus point of the parabolic shaped internal wall. The parabolic shaped wall of the communication device body 325 defines a focused transmission region, like a "hotspot", which the mobile communication device 310 is able to detect a strong increase in received signal strength compared to areas outside the focused transmission region. As shown in Figures 5 to 9, the directional antenna of the first entry and first exit communication devices 334, 354 is a parabolic antenna which advantageously focuses the transmission of the transmitted signal within a specific region whilst still capturing transmitted signals from the mobile communication device 310 over a broad region. It will be appreciated that a cover can extend between the side edges of the body 325 which is substantially flush with the external wall of the bollard, although for clarity purposes this has not been shown in Figures 5 to 9. [0067] In a preferable form, the entry communication system 324 of the communication system 306 can further include a second entry communication device 336 located within or near the ticket issuance machine 318. Furthermore, the exit communication system 326 of the communication system 306 can further include a second exit communication device 356 located within or near the ticket reading machine 316. The second entry and exit communication devices 336, 356 are preferably fixed devices. In a preferable form, the second entry and second exit communication devices 336, 356 are Bluetooth communication devices using Bluetooth Low Energy. The wireless signal transmitted by the second entry and exit communication devices 336, 356 are indicative of a unique device identity/address for the respective communication device. The second entry communication device 336 is part of or coupled to an entry point microcontroller 338, such as a Raspberry Pi microcontroller or the like, located within or near the ticket issuance machine 314. The first entry communication device 334 is also coupled, via a wired medium that extends between the bollard and the ticket issuance machine 314, to the entry point microcontroller 338. Similarly, the second exit communication device 356 is part of or coupled, via a wired medium, to an exit point microcontroller 358, such as a Raspberry Pi microcontroller or the like, located in or near the ticket reading machine 316. The first exit communication device 354 is also part of or coupled to the exit point microcontroller 358 via a wired medium that extends between the bollard and the ticket reading machine 320. [0068] The entry communication system 324 of the communication system 306 preferably further includes a third and fourth entry communication device 330, 332 provided in the form of a first entry transmitter 330 and a second entry transmitter 332. Furthermore, the exit communication system 326 of the communication system 306 further includes a third and fourth exit communication device 350, 352 provided in the form of first exit transmitter 350 and a second exit transmitter 352. The first and second entry and exit transmitters 330, 332, 350, 352 are configured to operate as beacons, each periodically transmitting a unique wireless signal which can be received by an approaching mobile communication device 310. The unique wireless signal can be indicative of a unique identity (such as a universally unique identifier) associated with the respective communication device. The unique wireless signals which can be received by an approaching mobile communication device 310 can be used by the mobile communication device 310 to determine which side of the vehicle (i.e. left or right) the approaching mobile communication device 310 is located. As will be explained in further detail below, determining whether a particular mobile communication device 310 is located on the left or right side of the vehicle 1000 can be used to distinguish between multiple mobile communication devices 310 located in the vehicle 1000 which are substantially simultaneously attempting to communicate with the communication system 306. Additionally, the received wireless signals from the transmitters 330, 332, 350, 352 can be analysed by the approaching mobile communication device 310 to assist with determining when an entry or exit request should be transmitted by the mobile communication device 310. 27 Immediately after a paragraph discussing Figures 11A to 11C, the specification states: [0071] In a general form, the mobile communication device 310 is configured to generate and transfer the entry request in response to receiving a first entry signal from the first entry communication device 334 that satisfies an entry criteria. Additionally, the mobile communication device 310 is configured to generate and transfer the exit request in response to receiving a first exit signal 354 from the first exit communication device that satisfies an exit criteria. In one form, the entry criteria and the exit criteria are based at least partially on the received signal strength of the received first entry signal and the first exit signal. [0072] In more preferable forms, the mobile communication device 310 is configured to generate and transfer the entry request in response to receiving a first entry signal from the first entry communication device 334 and a second entry signal from the second entry communication device 356 which substantially simultaneously satisfy one or more entry criteria. Similarly, in more preferable forms, the mobile communication device 310 is configured to generate and transfer the exit request in response to receiving a first exit signal from the first exit communication device 354 and a second exit signal from the second exit communication device 356 which substantially simultaneously satisfy one or more exit criteria. [0073] Due to a wide variety of locations [in] which the mobile communication device 310 can be located in a vehicle 1000 which can impact upon the received signal strength, and also the varying signal receiving characteristics of a wide variety of mobile communication devices 310, in some instances it may not be possible to predefine the entry criteria and the exit criteria solely dependent upon a predefined threshold received signal strength. Therefore, in a preferable form, the mobile communication device 310 is configured to dynamically determine an entry scale value based on the received signal strength of a plurality of third and/or fourth entry signals received from the first and second entry transmitters 330, 332 such that a predefined entry criteria can be utilised by the mobile communication device 310 to determine when to transfer the entry request using the entry scale value. Similarly, the mobile communication device 310 is configured to dynamically determine an exit scale value based on the received signal strength of a plurality of third and/or fourth exit signals received from the first and second exit transmitters 350, 352 such that a predefined exit criteria can be utilised by the mobile communication device 310 to determine when to transfer the exit request using the exit scale value. 28 I note that the expression "scale value", which appears in [0073], is used in claim 9. While that claim is not directly in issue, the above passage may nevertheless be relevant contextually. 29 The expression "key data", which is used in claim 4, is referred to in the following paragraph: [0094] Upon successful user registration to use the system 302, the server processing system 340 additionally generates key data that is associated with the user record for the user. The key data is stored in the server database 342. In addition, the key data is transferred to the mobile communication device 310 via a communication network, wherein the mobile communication device 310 stores the key data in memory. The key data includes key pairs, where each key pair includes a single use entry key and a corresponding single use exit key. The mobile communication device 310 generates the entry request to include one of the entry keys associated with the user. The access control processing system 312 queries a registered entity database 344 accessible to the access control processing system 312 to determine whether the indicated entry key is valid. The mobile communication device 310 also generates the exit request to include the corresponding exit key associated with the user. The access control processing system 312 queries the registered entity database 344 to determine whether the indicated exit key is valid. Periodically, the server processing system 340 updates the data stored in the registered entity database 344 with new key data and new user identities to enable the access control processing system 312 to verify the validity of received entry and exit requests. 30 In reference to Fig 4, which is a flowchart representing a method performed by the various components of the system described in Fig 3, it is stated: [00108] At step 415, the method 400 includes the mobile communication device 310 generating and transferring, to the second entry communication device 338, an entry request in response to one or more received entry signals satisfying one or more entry criteria. In a preferable form, the entry request is generated and transferred in an automated manner without user intervention (i.e. without the user holding the mobile communication device and without operating the mobile communication device). 31 I note that the TMA parties place emphasis on the second sentence of the above paragraph as indicating that it is only in a preferable form that the entry request is generated and transferred automatically. A similar point can be made about [00115], which concerns the step in the flowchart relating to the exit request. 32 Figure 13 is a depiction of a system for use with an access control system for a residential/commercial parking area. This figure is described at [00130]-[00134] of the specification. 33 The penultimate paragraph in the section describing the figures is relevant to the construction issues. It reads: [00141] In the examples described above, no user interaction with the mobile communication device 310 is required in order for the entry request or exit request to be generated and transferred. However, in particular variations on these examples, the mobile communication device 310 may be configured by the computer program 308 to allow the user to interact with a user interface of the computer program which is presented via the display of the mobile communication device in order to generate and transfer the entry request or exit request. In certain examples, analysis of the received signal strength of the entry and exit signals are unnecessary as the user simply interacts with the interface when they are about to enter or exit the restricted area. However, in other examples, the analysis of the received signal strength of the entry and exit signals can be used by the mobile communication device to enable a portion of the interface which is normally disabled. In particular, prior to approaching the entry or exit point of the restricted area, a portion of the interface of the computer program 308, such as a button, is disabled. The mobile communication device 310 is configured by the computer program to analyse the received signal strength as discussed above in prior examples. When the mobile communication device 310 determines that the one or more entry or exit criteria have been satisfied, the computer program 308 enables the button of the interface such that the user can then select the button to instruct the mobile communication device to generate and transfer the entry or exit request. This configuration reduces the risk that a user in a queue at the entry or exit point interacts with the computer program 308 to generate and transfer an entry or exit request which actually allows a different user located ahead in the queue to enter or exit the restricted area. 34 As noted above, the claims in issue are 1, 4, 11 and 16. Claim 1 has been set out in the Introduction to these reasons. I observe that claim 1 is to a "system" that includes two components: (1) a "communication system"; and (2) a "computer program" (eg, an app) that is executable by a "mobile communication device" (eg, a smartphone) so as to be able to configure the smartphone in a particular way, as defined by the claim. 35 Claims 4, 11 and 16 are as follows (with the addition of the numbers in square brackets): 4. The system according to any one of claims 1 to 3, wherein the system includes [4.1] a server processing system and [4.2] a data store accessible by the access control system, wherein: [4.3] the server processing system is configured to: generate key data associated with the entity; [4.4] transfer the key data to the mobile communication device [4.5] for storage in memory; and [4.6] store the key data in the data store; [4.7] wherein each entry and exit request generated by the mobile communication device is indicative of a key from the key data, [4.8] wherein an access control processing system of the access control system queries the data store using the key to verify the validity of the entry request or exit request. … 11. A computer program executable by a mobile communication device, wherein the computer program configures the mobile communication device to: receive one or more entry signals from a communication system when the user approaches an entry point of a restricted area; determine a received signal strength of the one or more entry signals; determine if one or more entry criteria have been satisfied based on the received signal strength of the one or more entry signals in order to generate and transfer an entry request; in response to the one or more entry criteria being satisfied, generate and transfer, to the communication system, the entry request after receiving the one or more entry signals; receive, from the communication system, authorisation data indicative of the user being granted access to enter the restricted area by an access control system; receive one or more exit signals from the communication system when the user approaches an exit point of the restricted area; determine a received signal strength of the one or more exit signals; determine if one or more exit criteria have been satisfied based on the received signal strength of the one or more exit signals in order to generate and transfer an exit request; and in response to the one or more exit criteria being satisfied, generate and transfer, to the communication system and after receiving the one or more exit signals, the exit request indicative of the authorisation data for processing by the access control system to enable the user to exit the restricted area. … 16. A mobile communication device configured to: receive one or more entry signals from a communication system when a user of the mobile communication device approaches an entry point of a restricted area; determine a received signal strength of the one or more entry signals; determine if one or more entry criteria have been satisfied based on the received signal strength of the one or more entry signals in order to generate and transfer an entry request; in response to the one or more entry criteria being satisfied, generate and transfer, to the communication system, the entry request after receiving the one or more entry signals; receive, from the communication system, authorisation data indicative of the user being granted access to enter the restricted area by an access control system; receive one or more exit signals from the communication system when the user approaches an exit point of the restricted area; determine a received signal strength of the one or more exit signals; determine if one or more exit criteria have been satisfied based on the received signal strength of the one or more exit signals in order to generate and transfer an exit request; and in response to the one or more exit criteria being satisfied, generate and transfer, to the communication system and after receiving the one or more exit signals, the exit request indicative of the authorisation data for processing by the access control system to enable the user to exit the restricted area. 36 Claim 4 is dependent on claim 1 and requires that the system include a "server processing system" and a "data store", where the server processing system generates "key data" that is transferred to and stored on the smartphone, and then each entry and exit request that the smartphone generates is "indicative of" a "key" from that "key data". 37 Claim 11 is an independent claim that is similarly worded to claim 1, but it is drafted by reference to a "computer program" (an app). The computer program as claimed has to have certain properties, namely that it will configure a smartphone to operate in a particular way, so as to send and receive signals and data relating to entry into and exit from a restricted area (using the same steps described in claim 1). 38 Claim 16 is also an independent claim, similarly worded to claim 1, but it is drafted by reference to the "mobile communication device" (which I refer to as a smartphone for ease of expression). The claimed smartphone must be configured to operate in a particular way, namely to send and receive signals and data as described in relation to claims 1 and 11. 39 Although not in issue, the following claims may be relevant by way of context: 2. The system according to claim 1, wherein the communication system includes at least one of: a first entry communication device including a first directional antenna to define a focused entry signal transmission region, wherein the mobile communication device is configured to generate and transfer the entry request in response to determining that at least some of the one or more entry signals satisfy the one or more entry criteria indicative of the focused entry signal transmission region; and a first exit communication device including a second directional antenna to define a focused exit signal transmission region, wherein the mobile communication device is configured to generate and transfer the exit request in response to determining that at least some of the one or more exit signals satisfy the one or more the exit criteria indicative of the focused exit signal transmission region. 3. The system according to claim 2, wherein the directional antenna of at least one of the first entry communication device and the first exit communication device is a parabolic antenna. … 9. The system according to claim 3, wherein the communication system includes at least one of: an entry transmitter configured to transmit one or more further entry signals; and an exit transmitter configured to transmit one or more further exit signals; wherein the mobile communication device is configured by the computer program to: determine an entry scale value and exit scale value based on an order of magnitude of power of one or more received further entry and exit signals respectively; and determine one or more scaled power values of the one or more received entry and exit signals using the entry scale value and the exit scale value respectively; wherein the one or more entry and the one or more exit criteria are based on a growth rate of one or more scaled power values of at least some of the one or more received entry or exit signals equaling or exceeding a growth rate threshold. 10. The system according to any one of claims 1 to 9, wherein the mobile communication device is configured to automatically transfer at least one of the entry request and the exit request without user interaction.

The hearing and the evidence 40 The hearing dealt with issues of liability in relation to the claim and the cross-claim (other than the question of liability for additional damages). 41 Apart from independent expert evidence, UbiPark relies on evidence from the following witnesses: (a) William Van De Camp, the Chief Technology Officer of UbiPark, who prepared affidavits dated 4 February 2022 and 22 September 2022; and (b) Tracy Piper, who prepared an affidavit dated 1 July 2022. 42 Mr Van De Camp's evidence describes how UbiPark's technology works, which is relevant to the Infringement Claim. Although presented as lay rather than expert evidence, his evidence deals with technological matters of the kind also dealt with in the expert evidence. Mr Van De Camp gave some limited oral evidence in chief (in addition to his affidavit evidence) and was cross-examined. He gave evidence in a clear and straightforward way and I generally accept his evidence. 43 Ms Piper's evidence is relevant to the Invalidity Claim. She is a general manager with over 25 years' experience across a number of different industries. In 2013, she joined together with some previous work colleagues to form a business that would create innovative technology that could solve problems for both consumers and businesses in relation to e-commerce. They initially operated under the company name, Touch To Buy Pty Ltd (Touch To Buy), and later under other corporate structures. In mid-2013, Touch To Buy identified parking as being a growth area to target using the e-commerce skills within the business. They created a business division called Blue Dot Parking to develop and market a parking-based app. Ms Piper was not required for cross-examination. 44 The TMA parties did not call any lay witnesses. 45 Each party called one independent expert witness: (a) The TMA parties called Geoffrey Sizer. Mr Sizer had prepared two affidavits (and accompanying reports) for the purposes of the interlocutory injunction hearing, but these were not relied on at the hearing. The affidavits and accompanying reports relied on at the hearing were: (i) Mr Sizer's affidavit dated 21 July 2022, annexing his report of the same date (Mr Sizer's third report); (ii) Mr Sizer's affidavit dated 15 September 2022, annexing his report of the same date (Mr Sizer's fourth report); and (iii) Mr Sizer's affidavit dated 13 October 2022, annexing his report of the same date (Mr Sizer's fifth report). (b) UbiPark called Howard Elliott. He prepared three affidavits, dated 30 June 2022, 29 September 2022 and 13 October 2022. 46 Both experts gave evidence relevant to the Infringement Claim and the Invalidity Claim. 47 The experts prepared a joint report dated 9 October 2022 and gave evidence concurrently during the hearing. Their evidence was spread over three hearing days, but occupied only part of two of those days. 48 Mr Sizer is a chartered professional engineer. He is the Chief Executive Officer and Principal Engineer of Genesys Electronics Design Pty Ltd, a position he has held since 2005. His key professional skills, as set out in his resume are: Planning and management of state-of-the-art electronic equipment and systems research and development projects from initial concept to volume manufacture, including: initial system design; regulatory compliance including medical devices; IP protection; R&D grant application, Work Breakdown Structure generation; resourcing and timescale analysis using PERT/Precedence techniques; day-to-day management of multidisciplinary teams of engineers and technical support staff; and management of subcontractors. System design of communications and control systems using computer/microcontroller-based equipment, high-speed digital electronics and radio frequency, optical fibre and copper cable bearers. Design and implementation of electronic equipment and systems from the initial design concept through to medium and large-scale production, with particular emphasis on the project planning, management and technical documentation aspects. 49 His academic qualifications are a Bachelor of Science from the University of Adelaide in Computing Science and Applied Mathematics (1977), and a Bachelor of Engineering (Electrical), with First Class Honours, from the University of Adelaide (1978). He is a member of a number of professional associations. He has extensive professional experience and is named as the principal inventor or co-inventor in a number of patents. 50 Mr Sizer gave evidence in a clear and confident manner. He made sensible concessions. His evidence was evidently intended to assist the Court. 51 Mr Elliott is a consultant and company director. The following is a summary of his professional experience and expertise as set out in his curriculum vitae: I have been involved in the IT & T industry for over 25 years. After leaving academia, I started my IT career with Digital Equipment Corporation, Tandem and Stratus Computers. In 1987, I established my own consulting practise. For the past 20+ years I have concentrated on Software Development, Systems Procurement, Project & Programme Management, Technology Consulting and Dispute Resolution & Management. My technical expertise includes telecommunications and data networks, communications (voice and data, mobile, satellite and fixed), electronic commerce, payment systems, and internet technology. I have carried many assignments, both short and long term, in a variety of industries including Financial, Government and Telecommunications. Clients include MasterCard International, Optus Communications, Telstra, Cable & Wireless (UK), Cable & Wireless (HKG), SingTel Optus, KDD, BT, DBPT, Citibank, Westpac, Commonwealth Bank and NSW Government. These assignments have typically been large infrastructure investment projects, electronic commerce projects, mergers & acquisitions and strategic & tactical marketing projects. I have assisted a number of organizations to IPO including Open Telecommunications, Clarity and Orbcomm; and acted as adviser to a number of investment banks on acquisitions and major transactions. I have a Bachelors Degree in Mathematics (Hons), Master of Mathematics, MBA, Professional Certificate in Commercial Arbitration, Advanced Certificate in Commercial Arbitration, Master of Legal Studies and ISACA CISA. In addition, I am an qualified and Arbitrator, Mediator and Expert Determiner, and, previously Chairman of the Institute of Arbitrators & Mediators Australia ICT Sub Committee. I headed up a joint committee (IAMA, ACS and PMI) and authored a paper on Dispute Resolution in the ICT industry. I also hold CISA and PMP accreditations. 52 Mr Elliott is a member of a number of professional associations. 53 Mr Elliott gave evidence in a calm, clear, articulate and considered way. As with Mr Sizer, his evidence was evidently intended to assist the Court. He too made sensible concessions. 54 One difference between the evidence of Mr Sizer and that of Mr Elliott is that Mr Sizer had access to, and reviewed, the source code for the UbiPark App, whereas Mr Elliott did not review the source code for the UbiPark App; his evidence regarding the operation of UbiPark's technology was informed by Mr Van De Camp's evidence.

Principles of construction 55 In Jupiters Ltd v Neurizon Pty Ltd [2005] FCAFC 90; 222 ALR 155, the Full Court of this Court (Hill, Finn and Gyles JJ) summarised the principles of construction as follows (at [67]): There is no real dispute between the parties as to the principles of construction to be applied in this matter although there is some difference in emphasis. It suffices for present purposes to refer to the following: (i) the proper construction of a specification is a matter of law: Décor Corporation Pty Ltd v Dart Industries Inc (1988) 13 IPR 385 at 400; (ii) a patent specification should be given a purposive, not a purely literal, construction: Flexible Steel Lacing Co v Beltreco Ltd (2000) 49 IPR 331; [2000] FCA 890 at [81] (Flexible Steel Lacing); and it is not to be read in the abstract but is to be construed in the light of the common general knowledge and the art before the priority date: Kimberley-Clark Australia Pty Ltd v Arico Trading International Pty Ltd (2001) 207 CLR 1; 177 ALR 460; 50 IPR 513; [2001] HCA 8 at [24]; (iii) the words used in a specification are to be given the meaning which the normal person skilled in the art would attach to them, having regard to his or her own general knowledge and to what is disclosed in the body of the specification: Décor Corporation Pty Ltd at 391; (iv) while the claims are to be construed in the context of the specification as a whole, it is not legitimate to narrow or expand the boundaries of monopoly as fixed by the words of a claim by adding to those words glosses drawn from other parts of the specification, although terms in the claim which are unclear may be defined by reference to the body of the specification: Kimberley-Clark v Arico at [15]; Welch Perrin & Co Pty Ltd v Worrel (1961) 106 CLR 588 at 610; Interlego AG v Toltoys Pty Ltd (1973) 130 CLR 461 at 478; the body of a specification cannot be used to change a clear claim for one subject matter into a claim for another and different subject matter: Electric & Musical Industries Ltd v Lissen Ltd [1938] 4 All ER 221 at 224-5; (1938) 56 RPC 23 at 39; (v) experts can give evidence on the meaning which those skilled in the art would give to technical or scientific terms and phrases and on unusual or special meanings to be given by skilled addressees to words which might otherwise bear their ordinary meaning: Sartas No 1 Pty Ltd v Koukourou & Partners Pty Ltd (1994) 30 IPR 479 at 485-6 (Sartas No 1 Pty Ltd); the court is to place itself in the position of some person acquainted with the surrounding circumstances as to the state of the art and manufacture at the time (Kimberley-Clark v Arico at [24]); and (vi) it is for the court, not for any witness however expert, to construe the specification; Sartas No 1 Pty Ltd at 485-6. 56 In Globaltech Corporation Pty Ltd v Australian Mud Company Pty Ltd [2019] FCAFC 162; 145 IPR 39, the Full Court set out, at [93]-[96], a number of key principles that are also relevant here. I refer to those principles without setting them out. I note also the following principles and observations. 57 In GlaxoSmithKline Consumer Healthcare Investments (Ireland) (No 2) Ltd v Generic Partners Pty Ltd [2018] FCAFC 71; 264 FCR 474 (GSK), the Full Court (Middleton, Nicholas and Burley JJ), provided the following guidance in relation to purposive construction (at [106]): More recent cases have continued to emphasise the need to read a patent specification as a whole and in light of the common general knowledge. They also confirm that a patent specification should be read in a practical and common sense way and given a "purposive" construction. This approach to construction requires the court to read the specification through the eyes of the skilled addressee with practical knowledge and experience in the field of work in which the invention was intended to be used and a proper understanding of the purpose of the invention. 58 In GSK (at [108]) the Full Court quoted with apparent approval the following passage from the judgment of Lord Hoffmann in Kirin-Amgen Inc v Hoechst Marion Roussel Ltd (2004) 64 IPR 444 at [34]: "Purposive construction" does not mean that one is extending or going beyond the definition of the technical matter for which the patentee seeks protection in the claims. The question is always what the person skilled in the art would have understood the patentee to be using the language of the claim to mean. And for this purpose, the language he has chosen is usually of critical importance. The conventions of word meaning and syntax enable us to express our meanings with great accuracy and subtlety and the skilled man will ordinarily assume that the patentee has chosen his language accordingly. As a number of judges have pointed out, the specification is a unilateral document in words of the patentee's own choosing. Furthermore, the words will usually have been chosen upon skilled advice. The specification is not a document inter rusticos for which broad allowances must be made. On the other hand, it must be recognised that the patentee is trying to describe something which, at any rate in his opinion, is new; which has not existed before and of which there may be no generally accepted definition. There will be occasions upon which it will be obvious to the skilled man that the patentee must in some respect have departed from conventional use of language or included in his description of the invention some element which he did not mean to be essential. But one would not expect that to happen very often. 59 Consistently with the above, an expert witness cannot assist the court with the meaning of an ordinary English word (or phrase) unless it has a special or unusual meaning within an area of technology: see Minnesota Mining and Manufacturing Co & Beiersdorf (Aust) Ltd [1980] HCA 9; 144 CLR 253 (Minnesota Mining) at 272 per Aickin J, with whom Barwick CJ, Stephen, Mason and Wilson JJ agreed; see also Kinabalu Investments Pty Ltd v Barron & Rawson Pty Ltd [2008] FCAFC 178 (Kinabalu) at [45] per Sundberg, Emmett and Greenwood JJ. 60 In Commissioner of Patents v Rokt Pte Ltd [2020] FCAFC 86; 277 FCR 267, Rares, Nicholas and Burley JJ explained at [73]: The role of expert evidence in construing the patent specification and the claims is limited. It is to place the Court in the position of the person acquainted with the surrounding circumstances as to the state of the art and manufacture as at the priority date … 61 To similar effect, in Flexible Steel Lacing Co v Beltreco Ltd [2000] FCA 890; 49 IPR 331, Hely J stated at [81]: [T]he construction of the specification is for the court, not for the expert. In so far as a view expressed by an expert depends upon a reading of the patent, it cannot carry the day unless the court reads the patent in the same way. 62 The above passage has been cited with approval by three Full Courts: Kinabalu at [44]-[45]; Austal Ships Sales Pty Ltd v Stena Rederi Aktiebolag [2008] FCAFC 121; 77 IPR 229 at [14]; and PAC Mining Pty Ltd v Esco Corp [2009] FCAFC 18; 80 IPR 1 at [29]. 63 In Multigate Medical Devices Pty Ltd v B Braun Melsungen AG [2016] FCAFC 21; 117 IPR 1 at [23]-[28], Bennett, Yates and Beach JJ made a series of related observations about the role of expert evidence in patent cases on issues of construction.

The skilled addressee 64 The "skilled addressee", or "person skilled in the relevant art" (Patents Act, s 7(2)), is a hypothetical person (or team) who has a "practical interest in the subject matter of the invention" and who "might wish to make or construct the invention": Root Quality Pty Ltd v Root Control Technologies Pty Ltd [2000] FCA 980; 49 IPR 225 at [70]-[71] per Finkelstein J. 65 Such a person was described by French CJ in AstraZeneca AB v Apotex Pty Ltd [2015] HCA 30; 257 CLR 356 at [23] as a "tool of analysis", and his Honour explained that this hypothetical person is not an "avatar" for the views of the particular expert witnesses who give evidence in a proceeding - it is a "pale shadow of a real person". 66 In this case, there is no real dispute as to the qualities of the skilled addressee. They would have knowledge about the basic operation of public, commercial and residential carparks. They would also understand information systems including networking principles, computing principles (including coding), and communication protocols (including Bluetooth, Bluetooth Low Energy, mobile, internet and Wi-Fi). It appears that both Mr Sizer and Mr Elliott have most, if not all, of these qualities.

Common general knowledge 67 The common general knowledge may be described as "the background knowledge and experience which is available to all in the trade in considering the making of new products, or the making of improvements in old": Minnesota Mining at 292 per Aickin J. The parties did not address the common general knowledge in any detail in their written submissions. In the course of the concurrent evidence session, Mr Sizer gave evidence (in response to questions posed by counsel for UbiPark) about the state of knowledge that existed as at 2 February 2015 (the priority date). I take this evidence to represent the common general knowledge as at the priority date. Mr Sizer gave the following evidence: (a) A mobile communication device (or smartphone) contains a computer as one of its component parts. It can be referred to as a computing device. The computing functionality of the device allows it to execute or run a computer program. The computing device, or a microcontroller embedded in a device, is capable of having software programmed to it, and it then executes that software. (b) As at the priority date, it was standard for smartphones and tablets to have Bluetooth receivers built in. (c) The term "application" is usually used to refer to a user-facing application that performs a particular function. An application (or app) is a computer program. (d) A smartphone consists of software, including the operating system and what are called input/output drivers that relate to the hardware drivers on the smartphone. The hardware devices are configured in their operation by the software. In other words, the hardware device has a function, but the software establishes the way that that function is used in the system. (e) The operating system (for example, on an Apple phone, iOS) is supplied with the smartphone and provides all of the basic functions and facilities to cause the smartphone to be able to host applications (or apps). Those apps are software that is generally written by a vendor to perform a particular function. A smartphone also includes functions like basic telephony, message and email, and those are inbuilt functions on the smartphone. The smartphone is supplied (eg, by Apple) with these capabilities built in, plus all of the underlying software. For example, the software that enables the Bluetooth radio receiver or transceiver to communicate using Bluetooth is built into the smartphone as supplied by the vendor. Android is analogous to iOS. (f) As one moves a smartphone away from a Bluetooth Low Energy beacon, the strength or power of the signal decreases. Under perfect conditions, the decrease would be inversely proportional to the distance squared. (g) The received signal strength indicator (RSSI) value is determined by the radio receiver hardware on the smartphone. There is an electronic circuit that accepts the signal from the antenna; that circuit will then typically generate an output voltage that is related to the radio energy signal strength. That is then converted by an analogue-to-digital converter to produce a number, and that number is known in the software. The smartphone will be able to determine the RSSI value, but that value has no meaning if the smartphone does not know the nature of the source of the signal. Accordingly, the RSSI value only has meaning after the decoding process has occurred. (h) The scale to measure signal strength (eg, RSSI) is decibels relative to a milliwatt (dBm). The signals are extremely low amounts of energy, below a microwatt. Very low levels of energy are sufficient to be able to receive and decode the signal. (i) Decoding is a product of the rules of Bluetooth signal transmission. It means that a pattern of digital bits is derived from the signal. The pattern of bits must meet certain rules in terms of being a valid Bluetooth signal. The decoding process includes an error-checking process. If the decoding process determines that the signal is not strong enough to be error free, it will reject it as a signal and it will not relay that signal to the other sections of the software. (I note that, during the course of the concurrent evidence (T161-165, 167-168, 171-172), a difference emerged between Mr Sizer and Mr Elliott over the steps covered by the word "decoding". In summary, Mr Elliott uses the word "decoding" to cover fewer steps in the process than Mr Sizer. However, little or nothing turns on that difference for present purposes. If and to the extent that it matters, I will proceed on the basis of Mr Sizer's definition of "decoding".) (j) The Universally Unique Identifier (UUID) is a unique identity that is encoded and associated with the Bluetooth transmission source (eg, a beacon). It is a numeric code that is a unique identifier that only that source will have. It is effectively equivalent to a unique name for that source.

Overview 68 The Infringement Claim has been summarised in the Introduction to these reasons. I now set out a more detailed summary of the TMA parties' contentions, in order to identify the key matters that are in issue. 69 In the further amended statement of cross-claim at [9], the TMA parties allege: From a date unknown to the Cross-claimants, UbiPark has: a. made, offered for sale, sold and/or supplied to car park owners and/or car park operators a car park access system (the UbiPark System) which, when installed, provides car park users car park entry and exit functionality in conjunction with the use of an app which can be downloaded to a car park user's mobile communication device(s) (the UbiPark App); and b. made, offered to dispose of, and disposed of, or supplied, the UbiPark App with the functionality referred to in paragraph 9.a above. 70 In its defence to cross-claim, UbiPark says that this allegation is embarrassing in that the word "system" is vague and unclear. However, under cover of that objection, it admits that it has supplied and installed equipment for car park owners and operators that can be used in the manner alleged. Further, under cover of that objection, UbiPark admits that it has supplied the UbiPark App (as amended from time to time) and that it can be used in the manner alleged. 71 The TMA parties allege that neither the UbiPark System nor the UbiPark App is a "staple commercial product". Under cover of the objection regarding "the UbiPark System", this allegation is admitted. 72 The TMA parties allege that UbiPark has at all material times had reason to believe that: (a) car park owners and/or operators would use the UbiPark System to provide the functionality that the system offered for car park access and exit in conjunction with the UbiPark App; and (b) users of the UbiPark App would use that app to access and exit car parks owned and/or operated by those persons using the UbiPark System. 73 Subject to UbiPark's objection regarding "the UbiPark System", UbiPark says that it had reason to believe that some, but not all, car park operators or owners to whom UbiPark supplied equipment would use that equipment with the UbiPark App to enable car park entry and exit using that app. UbiPark otherwise denies the allegation. 74 The TMA parties allege that UbiPark has at all material times: provided instructions for the use of the UbiPark System and UbiPark App; induced car park owners and/or operators to use the UbiPark System; and induced car park users to use the UbiPark App, to provide or implement the functionality referred earlier in the pleading. This allegation is denied. 75 The TMA parties allege that: the UbiPark System is a system that includes the features of claims 1 and 4 of the 335 Patent; the UbiPark App is a computer program executable by a mobile communication device that includes the features of claim 11; and a mobile communication device on which the UbiPark App is installed is a mobile communication device that includes the features of claim 16. 76 The TMA parties allege that: (a) UbiPark has infringed claims 1, 4 and 11 of the 335 Patent pursuant to s 13 of the Patents Act; (b) UbiPark has infringed claims 1, 4, 11 and 16 of the patent pursuant to s 117 of the Patents Act; (c) car park owners and/or operators which use the UbiPark System have infringed each of claims 1 and 4 and users of the UbiPark App on their mobile communication devices who use it as part of the UbiPark System have infringed each of claims 11 and 16, and UbiPark has: (i) authorised such infringement and has therefore infringed those claims pursuant to s 13 of the Patents Act; and/or (ii) aided, abetted, counselled or procured such infringement, or been a party to, or participated in a common design to engage in, such infringement. (d) Mr Howell has aided, abetted, counselled or procured, or been a party to, or participated in a common design to engage in, the alleged conduct of UbiPark. 77 The balance of this section of the reasons will be structured as follows. First, I will provide a broad outline of UbiPark's technology. Secondly, I will consider each set of integers in dispute. In that section, I will consider, for each set of integers, both issues of construction and the question whether the relevant integers are present in the UbiPark technology. 78 I note that, in these reasons, I generally refer to "UbiPark's technology" (or "the UbiPark technology") rather than "the UbiPark system" to make clear that the technology does not necessarily equate with "the UbiPark System" as used in the TMA parties' pleading.

Outline of UbiPark's technology 79 The outline that follows is largely based on Mr Van De Camp's affidavit evidence, supplemented to some extent by Mr Sizer's evidence. 80 In the discussion that follows, I will initially describe UbiPark's technology at car parks other than the Perth Airport car park and a trial conducted at an Adelaide car park in about 2018/2019 (the Adelaide car park trial). The technology was configured in a different way at those locations. At the end of this section, I will identify those differences.

Car parks other than Perth Airport and Adelaide car park trial 81 I note that Mr Van De Camp's first affidavit generally refers to the "UbiPark server" (singular), while his second affidavit generally refers to "UbiPark's servers" (plural). Nothing turns on this. For consistency of expression, I will refer to UbiPark's servers. 82 When a person registers an account with UbiPark, the UbiPark servers generate a unique User ID for that subscriber, and they also generate a Globally Unique Identifier (GUID) for each subscriber. The GUID is 128 bits long. When a subscriber logs into their account using the UbiPark App on their smartphone, the UbiPark servers send to that smartphone that person's User ID and their GUID. Each time the UbiPark App then sends a message to the UbiPark servers, the app also sends, as part of that message, the User ID and the GUID. The servers do not otherwise include the User ID and the GUID in messages that are sent to the user's phone. The UbiPark servers check that the GUID corresponds with the GUID that is stored on the servers for that User ID, and this provides a layer of security by authenticating the communication as being one that was sent by the subscriber. It protects against someone trying to impersonate that subscriber. 83 The car parks that use UbiPark's technology (UbiPark Car Parks) all have at least one Bluetooth beacon at each of the entry and exit lanes for the car park. If more than one Bluetooth beacon is located at the entry, those beacons are treated as a single group by the UbiPark App. The Bluetooth beacons that UbiPark uses at all car park sites are omnidirectional beacons produced by a company called BlueCats. Every Bluetooth device, including each individual BlueCats beacon, sends out a signal that includes the UUID for that specific device. UbiPark incorporates into the UbiPark App certain software modules from BlueCats that relate to the operation of its beacons. 84 The UbiPark App, which operates on a user's smartphone, constantly scans for new UUIDs that identify that a new Bluetooth signal is being received. Each time it receives a Bluetooth signal with a new UUID, the app sends that new UUID to the UbiPark servers. The UbiPark servers check each such received UUID against a database to determine whether that UUID corresponds with a Bluetooth beacon that is located at a UbiPark Car Park. If the UUID does correspond with such a car park, all details of beacons associated with that group of lanes are returned by the servers. The app will then not send network enquiries if it receives UUIDs from the associated beacons. 85 UbiPark's servers are hosted by Azure, which is Microsoft's cloud server product. The UbiPark App communicates with the servers either using a data connection using a mobile telephone connection (for example, using a 3G, 4G or 5G connection), or alternatively it can communicate with the server using Wi-Fi if the smartphone is connected to a Wi-Fi connection. Once the UbiPark App ceases being connected with any Bluetooth device (that is, it ceases to receive the UUID associated with that Bluetooth signal), it "forgets" the UUID for that device. 86 If the UbiPark servers determine that the UUID that they have received from the UbiPark App corresponds with a BlueCats beacon located at the entry for a UbiPark Car Park, the servers will also check whether the user is authorised to enter that car park. The authorisation requirements, or entry requirements, will vary for different UbiPark Car Parks. Those authorisation requirements may include the following: (a) whether the user is a current UbiPark subscriber; (b) whether the user has valid credit card details recorded; (c) whether the car park's capacity has been reached; and (d) if the car park is not open to the general public, whether the user is a member of the restricted access group for that car park. 87 If the user is authorised to enter that particular car park (for which the BlueCats beacon UUID has been received), the UbiPark servers direct the UbiPark App to display a screen that identifies the car park, and also displays the words "Please wait". The UbiPark servers tell the app the length of time that it is to display this "Please wait" message. The purposes of the "Please wait" message step include: (a) the user may simply be driving past the car park and not intending to enter it; it is undesirable for such a person to be presented with the screen allowing them to open the car park barrier, including by accidentally touching the button on their smartphone screen; if the person is just driving past, they are likely to lose their connection with the BlueCats beacon within a short time period (as the Bluetooth range is limited), and if that occurs the UbiPark server will not then send the user the barrier opening screen; and (b) if the user does wish to enter that car park, the user will require at least some time to approach the barrier and come to a stop; delaying the display of the barrier opening screen allows them the opportunity to confirm that the information that is being displayed about the identity of the car park that they are about to enter corresponds with the car park that they in fact wish to enter. 88 After the specified time has elapsed for display of the "Please wait" screen, the UbiPark App will display an entry message screen for the car park. This includes a 'button' that the user is required to press to enter the car park. If there is more than one entry lane for that car park, the entry message screen displays all of the lanes and the user is required to press the relevant lane in order to open the barrier for that lane. The following is an example of the entry message screen where there is only one entry lane: 89 The following is an example of the entry message screen where there is more than one lane: 90 If the user at any time ceases to receive the Bluetooth signal that has the UUID for the entry beacon for that car park, the UbiPark App will cease to display either the "Please wait" message or the entry message (as applicable). 91 If the user remains connected to the relevant Bluetooth signal from the BlueCats beacon (or, more precisely, the user's smartphone recently received a relevant Bluetooth signal), and the user presses the entry button for that car park on the entry message screen, a message to this effect is sent from the UbiPark App to the UbiPark servers. The UbiPark servers then check again whether the user remains authorised to enter that car park. The UbiPark servers make that further assessment in order to address a number of potential issues, including: (a) the servers check that the user has not removed their credit card details in the meantime (to prevent the user trying to cheat the system); (b) since it is possible for the user to log into their UbiPark App on more than one smartphone, the UbiPark servers check to make sure that access has not already been granted to that user (this avoids the possibility of a single user of the app admitting more than one vehicle by using two different smartphones to obtain two different car park entry messages, while only paying for one car park visit - a similar check is made for the exit from the car park); and (c) the servers check again that the car park limit has not been reached; for example, if a car park had a limit of 100 spaces, and the entry screen was sent to the UbiPark App when the car park had 99 cars inside, then if another car (the 100th car) had entered the car park before the user pressed the barrier entry button, the servers would not allow entry; the car park limit might also be one that is specific to a specific user group - for example, a particular company might only have 20 spots allocated to it. 92 If the UbiPark servers determine that the user still meets all of the entry criteria, the UbiPark servers send a direction to open to the car park barrier, and a confirmation message screen (stating "Please Proceed") appears on the user's smartphone. I note that there is a lack of clarity in some of Mr Van De Camp's affidavit evidence as to whether the direction is sent to the barrier by the UbiPark App or the UbiPark servers. Mr Van De Camp's first affidavit, at [30], states that the UbiPark App sends the direction to the barrier, but the sentence appears to be mistaken in some respects because it also states that the UbiPark App determines whether the user still meets all of the entry criteria, having previously stated (at [28]) that this is a function of the UbiPark servers. At [33(e)] of the same affidavit, in the context of exiting the car park, the affidavit states that the UbiPark servers direct the relevant barrier to open. Similarly, in the context of exiting, Mr Van De Camp's second affidavit states at [28] that the servers send a message to the barrier controller for it to open. There is unlikely to be any distinction between entry and exiting in this regard. Further, in Mr Sizer's third report at appendix A, row 12, column F, it is stated that, after the user presses the "Open Lane X" button, "the smartphone communicates to the server the request to open the boom gate before which their vehicle is located". A statement to similar effect is set out in the joint report at [51]. This suggests that it is then the servers that direct the barrier to open. In light of the evidence summarised above, I find that it is the UbiPark servers that send the direction to open to the barrier. 93 If the UbiPark servers determine that the user no longer meets all of the entry criteria, a direction will not be sent to the barrier to open, and a message will be sent to the user's app stating that entry is not being granted. Examples of such messages are set out at [30] of Mr Van De Camp's first affidavit. 94 Before describing the exit steps, it is necessary to refer to certain other matters. If a user has been granted entry to a car park, then if they open the "Access" page of the UbiPark App, the app sends a query to the UbiPark servers about the user's current status. If the UbiPark servers determine that the user has entered a car park with their vehicle, the servers send back information for the UbiPark App to display that includes the duration that the vehicle has been in the car park, the vehicle parking fees that have been incurred up until that point in time, and the name of the car park. When a user enters a car park using the UbiPark App, the servers record the User ID, car park, time of entry to that car park and the status that the user is now in that car park. While the UbiPark App is running in the foreground of the user's device and the user has the "Access" page open, the app will continue to poll the servers on a regular basis to update the duration that the vehicle has been in the car park and also the parking fees incurred up to that point in time. It also verifies that the user is still in the car park (they may have exited using the UbiPark App logged in on another device). If the user exits the UbiPark App and then restarts the app, the app needs to send another query to the UbiPark servers about the user's current status. The fact that the user has a vehicle in a parking session, and the duration of the stay and accumulated fees, are not stored by the app. 95 The "appSettings.InCarPark" data element is kept in non-persistent memory in the UbiPark App and is set to true or false based on the response received from the servers after the app sends a request to get the user's current status. The response from the servers includes a Boolean field named "inCarPark", and the "appSettings.InCarPark" data element is set directly from this response. If the user closes the UbiPark App, that data element is deleted. The data element can be true or false, and it defaults to false. The app tracks if the status has been obtained from the servers using the field "appSettings.CurrentUserStatus", which defaults to null. The UbiPark App will send a request to the servers to get the user's current status when one of the following conditions occurs: (a) the user selects the "Access" tab; (b) the app detects a beacon and does not currently have a value for "appSettings.InCarPark"; (c) every 20 seconds while the user has the UbiPark App open on the "Access" tab and beacons are being detected; or (d) the user logs in to the UbiPark App. 96 When the user goes to exit the car park, the steps are similar to the entry steps described above: (a) The UbiPark App/smartphone must detect the BlueCats beacon for the exit lanes, which occurs when the UbiPark App receives the new UUID and sends that to the UbiPark servers, which check it against their database. (b) If the UbiPark servers determine that the user is receiving the Bluetooth signal associated with the beacon for the exit of that car park, the servers then assess whether the user is authorised to exit the car park. (c) If the user is authorised to exit the car park, the UbiPark servers direct the UbiPark App to display a "Please wait" message screen for a specified time period. The UbiPark App will then display a car park exit message screen. The user can press the button on the exit message screen to enable them to exit when their vehicle is positioned in front of the barrier. (d) If there is more than one exit lane, the exit message screen displays all of the lanes and the user is required to press the relevant lane in order to open the barrier for that lane. (e) If the user remains connected to the relevant Bluetooth signal (or, more precisely, the user's smartphone recently received a relevant Bluetooth signal), and the user presses the exit button on the exit message screen, a message to this effect is sent from the UbiPark App to the UbiPark servers. The UbiPark servers will check again whether the user is authorised to leave the car park and, if they are, the servers will direct the relevant barrier to open. These checks can be similar to the checks that are described above in relation to entry - the checks can include whether credit card details are still stored, and whether the user is recorded as already having left the car park. It is only if those further authorisation steps are confirmed by the servers, by reference to information that is stored on the servers, that the servers send a message to the barrier controller for it to open. (f) The UbiPark servers will then send a further message to the UbiPark App to display that includes details about the duration of the stay and the charges that were applied. The servers also send an email with those details to the user using their nominated email address. 97 If the UbiPark App/smartphone ceases receiving the Bluetooth signal for the car park exit before the user has requested to exit, the app will cease displaying the exit message screen. 98 The data element "appSettings.InCarPark" is used by the UbiPark App to determine whether to display entry or exit lanes for that car park. If "appSettings.InCarPark" is set to "true", then when the UbiPark servers tell the UbiPark App that the user's smartphone is receiving a UUID that is associated with a specific car park (Car Park X), the app will display the buttons for the exit lanes for Car Park X. It does this by calling the function "GetAcceptableLaneType()". On the other hand, if "appSettings.InCarPark" is set to "false", the app will display the buttons for the entry lanes for Car Park X. The position for car parks with additional secure areas within the car park is more complex.

Perth Airport and Adelaide car park trial 99 The difference in the case of the Perth Airport car park and the Adelaide car park trial was as follows. Both of these car parks had more than one lane. Instead of displaying the entry message screen with multiple lanes as set out at [89] above, the UbiPark App calculated the lane in which the user's car was believed to be located (referred to in the software as the "closest lane") and displayed an entry message screen that identified that lane. An example of such a screen is shown in the left-hand image below: 100 If the user saw that the lane that was shown was correct, they pressed the button in order to open the barrier for that lane. If the user saw that the lane that was shown was incorrect - for example, it displayed a button to open Lane 1, but their car was in Lane 2 - then the user had the option of pressing the "NOT YOUR LANE?" button. If they pressed that button, the UbiPark App would display a screen with buttons for all available lanes, as shown in the right-hand image above. 101 For the Perth Airport car park and the Adelaide car park trial, the user still had to press a button displayed on their phone to open the barrier. This allowed the user to ensure that the correct lane option was being displayed for them, as well as ensuring that the barrier would only be opened when their vehicle was at the front of the queue at the relevant barrier.

Consideration 102 I will now consider each set of integers in dispute. As indicated above, for each set of integers, I will first consider construction issues and then consider whether the integers are present in UbiPark's technology. 103 As noted above, for ease of expression, I will generally use the expression "smartphone" rather than "mobile communication device". However, I am intending to refer to mobile communication devices and not only smartphones.

Integers 1.3.3 and 1.3.8 104 The first issue between the parties concerns claim 1, integers 1.3.3 and 1.3.8, which have similar wording, one concerning entry and one concerning exit. Claim 1 has been set out at [12] above. The construction issue relating to these integers is bound up with the parties' contentions as to the proper construction of integers 1.3.1/1.3.6 and 1.3.2/1.3.7. Accordingly, it is necessary to consider the construction of all of these integers. 105 I commence with the construction of integer 1.3.1. In the joint report, the experts disagreed about the meaning of the word "receive" in this integer. In summary: (a) In Mr Sizer's opinion the entry signal is received by the smartphone when it impinges on the device and influences it in a perceptible way. In the case where the entry signal is transmitted by a Bluetooth beacon and received by a Bluetooth-equipped mobile phone, the entry signal transmitted by the Bluetooth beacon is received by the phone at the time it impinges on the smartphone's Bluetooth antenna, from which it is conveyed to the phone's electronic circuits and, after processing by them, to its software. In Mr Sizer's view, the entry signal is received by the smartphone before software running on the phone attempts to decode the information contained in the entry signal. (b) In Mr Elliott's opinion, for an entry signal to be received within the meaning of claim 1 of the patent, it is necessary for a radio frequency (RF) signal to impinge on the smartphone and for the smartphone to carry out processing on that signal to determine whether it is recognised as an "entry signal". In Mr Elliott's opinion, in the context of claim 1, an "entry signal" is a specific type of message with a specific purpose. In his opinion, in order for the "signal" to be received as an "entry signal" it must have been transmitted (by a transmitter of some kind) as an "entry signal" and it must be detected and recognised as an "entry signal" and not some other kind of message. In Mr Elliott's opinion, in the context of the patent, an "entry signal" is a specific communication from a beacon; the patent refers specifically to an "entry signal" that is transmitted by an "entry transmitter" (335 Patent, [0019], [0020]) and not merely any random RF signal. 106 The difference between the experts as to integer 1.3.1 was not as to technical matters, but rather as to what aspects of the process amount to receiving an entry signal within the meaning of claim 1. 107 In relation to the construction of integer 1.3.1 (in particular, the word "receive"), the following points emerged from the concurrent evidence session: (a) In oral evidence, Mr Sizer provided an explanation of the concept of "impinge". He said that: when a radio signal is transmitted, it radiates as an electromagnetic wave, and that will propagate indefinitely at the speed of light; the signal will then impinge on various structures, including an antenna; the antenna is exposed to that signal and converts the signal from an electromagnetic wave to an electrical signal. (b) In his evidence, Mr Sizer referred to the point at which you can reliably decode a signal as being a "threshold". During oral evidence, it was put to Mr Sizer that, on his definition of "receive", it includes circumstances that serve no practical purpose for what is being described in claim 1. Mr Sizer accepted that this was the case in relation to Bluetooth signals, but maintained his view of the meaning of "receive" given the broader potential application of the patent. (c) Mr Sizer accepted in oral evidence that, on his view of "receive", the relevant smartphone could be receiving a signal from a car park beacon from a considerable distance away. It was suggested that this was a practical reason why his definition was not to be preferred, given that claim 1 refers to "[receiving] one or more entry signals … when the entity approaches an entry point of a restricted area". Mr Sizer accepted that signals could be received (on his definition) when you are not approaching the car park, but maintained his position on the meaning of "receive". (d) During oral evidence, it was put to Mr Sizer that, on his interpretation of the word "receive", the smartphone is passive. It was put to him that, on this interpretation, a computer program was not configuring the smartphone to do anything (noting that claim 1 refers to "a computer program … wherein the mobile communication device is configured to ..."). Mr Sizer said that he did not read into claim 1 that the software is required to configure the smartphone. (e) Mr Sizer accepted during oral evidence that there is a practical need for the smartphone to be able to identify a signal as being an entry signal for the claim to be able to work. He also agreed that there is a need to decode the signal to be able to verify that the signal is from a relevant beacon at a car park (whether it is a UUID or some other form of communication protocol). It was put to him that a meaning of "receive" that includes decoding fits better with the language of claim 1. Mr Sizer did not agree with this. He explained that "the process of receiving and processing [a] signal takes into account a number of steps that occur prior to the point where the decoding and identification of that signal is made and that the phone must be configured to perform those additional reception steps". (f) Mr Elliott explained his view regarding integer 1.3.1 as follows during oral evidence: … In order for an entry signal to be recognised as an entry signal, you need [there] to be a very high level in the protocol stack, the L2 cap level, but in order to get there[,] processing has to be carried out and various layers, the protocol, the syntax, the semantics of each layer will need to be conformed to in order to get there, in order for it to be recognised as an entry signal. (g) Mr Elliott's view in relation to integer 1.3.1 was informed by the presence of the words "entry signal", which he considered to be a specific form of signal. Putting the words "entry signal" to one side, Mr Elliott accepted that it is fair to say that, when the smartphone's electronics detect the presence of an RF signal, but it has not yet been determined that it conforms to the protocol and it has not yet progressed through the layers of the protocol stack, the device has received the RF signal. However, Mr Elliott maintained his position in relation to integer 1.3.1 in view of the presence of the words "entry signal". (h) Mr Elliott accepted during oral evidence that "entry signal" does not have any technical meaning and it is a phrase peculiar to claim 1. He agreed that it must be a signal that has the characteristics that allow it to perform the function in the steps in claim 1. Nevertheless, he maintained his view that, for the purposes of integer 1.3.1, it would need to be recognised as an entry signal. In other words, it would need to conform to or contain a set of values or format or some other mechanism that allows it to be recognised as an entry signal. 108 In my view, the correct construction of "receive one or more entry signals" in integer 1.3.1 is that the entry signal (eg, a Bluetooth signal from a beacon) is received by the smartphone when it impinges on the device and influences it in a perceptible way. In other words, I accept Mr Sizer's interpretation of these words. This accords with the ordinary meaning of the word "receive", read in context. It also accords with how the technology on a smartphone, for the receipt of signals, works. The signal is received at the time that it impinges on the smartphone's radio antenna, which is before it is decoded or identified. In my view, Mr Elliott's interpretation places too much weight on the words "entry signal". While it is true that the signal that is sent needs to have characteristics such that it constitutes an entry signal for the purposes of claim 1, it does not follow that the smartphone needs to recognise the signal as such for the entry signal to have been received. The same meaning applies to "receive one or more exit signals" in integer 1.3.6. 109 Integer 1.3.2 reads: "determine a received signal strength of the one or more entry signals". It is common ground between the experts that this integer encompasses (at least) a smartphone measuring the strength of an entry or exit signal that has been received (eg, measuring the RSSI of a Bluetooth signal). The difference between the experts is whether the integer also encompasses the ability to correctly decode a Bluetooth signal. In summary: (a) In Mr Sizer's opinion, the integer also encompasses the ability of a smartphone to correctly decode the signal, thereby determining that the strength of a received signal is at or above a threshold value for the smartphone to be able to correctly decode it. (b) In Mr Elliott's opinion, if the signal strength was determined using the fact that the message was able to be decoded, then, at best the answer would be a Boolean value only, that value being equivalent to "yes, there is sufficient signal strength to decode this packet" and hence determine the type of packet in the context of the protocol and what the content of that packet might be (subject to other conditions such as bit error rates). In his opinion, in the context of claim 1, the words "determine a received signal strength" are qualified by "of the one or more entry signals" or "of the one or more exit signals". In his opinion, claim 1 is silent on how the signal strength would be used to "determine if one or more entry [or exit] criteria have been satisfied based on the received signal strength" (integer 1.3.3). In his view: a system could be imagined where a Boolean indicator as to whether a signal strength threshold has been achieved (as distinct from the magnitude of the signal strength) was used as part of an entry criteria; for example, an entry/exit criteria is that the smartphone has received (in the sense of detected, correctly decoded and recognised) a valid entry/exit signal constructed and transmitted specifically for this purpose; this implies that, as well as other necessary conditions (for example, low bit error rate) being satisfied, sufficient signal strength was present to enable the smartphone to decode the message according to the protocol. However, in Mr Elliott's opinion, in the context of the 335 Patent, "signal strength" is inferred to be a numerical value, not a Boolean measure. The patent uses this value to determine other values such as scaled power values (see [0026] and [0074], [0077] and [000126]), which are clearly numeric. 110 The following points relating to the construction integer 1.3.2 emerged from the concurrent evidence session: (a) It was put to Mr Sizer that, on his definition of "receive" and his approach to integers 1.3.1 and 1.3.2, there was a step missing in claim 1, namely identifying that the signal is an entry signal by decoding it. Mr Sizer responded that claim 1 did not address the issue of decoding, but he accepted that "you would need to be able to identify that signal as an entry signal in order to enable the functions of the rest of the claim to operate". (b) Mr Sizer accepted during oral evidence that the patent does not explicitly link "determin[ing] a received signal strength" with working out whether the smartphone can decode the signal. (c) During oral evidence, Mr Sizer accepted that various factors (such as differences in the sensitivities of receivers, the physical environment around the phone, whether or not there is a line of sight), in practical terms, could translate to quite different distances for two different individuals, in terms of how far away they may be when their smartphone can decode the signal. He said that the threshold at which the smartphone can decode the signal is not a precise measure of distance, but an approximation. (d) Having been taken to [0060] and [00141] of the 335 Patent, Mr Sizer accepted the proposition that a large part of the patent is dedicated to explaining how you can achieve the automatic timing of the opening of the barrier. (e) Having been taken to [0063] and [0064], Mr Sizer accepted that the 335 Patent describes methods of increasing complexity. Mr Sizer said that "the increasingly sophisticated methods are trying to increase the level of probability of … a mobile communication device being able to determine that it is in fact located before the barrier and, therefore, is the vehicle that should be allowed to enter the car park". 111 I will defer considering the correct construction of integer 1.3.2 until after I have discussed the evidence relating to integer 1.3.3. I will then consider the correct construction of these two integers together. 112 Integer 1.3.3 is worded as follows: "determine if one or more entry criteria have been satisfied based on the received signal strength of the one or more entry signals in order to generate and transfer an entry request". The experts stated at [27] of the joint report (as clarified during oral evidence at T182) that they agreed that, if an entry criteria is the receipt of an entry signal, then the entry criteria makes use of the received signal strength of the entry signal "in some way". However, beyond this, the experts disagreed as to the meaning of integer 1.3.3. In summary: (a) In Mr Sizer's opinion, the integer means that the received signal strength of the entry signal is a criterion used to determine whether the user is within a prescribed range of locations relative to the entry point, and is receiving entry signals for that entry point; more than one entry signal may be present for that entry point, with the entry criteria taking into account the signal strength of them in combination; for example, the signal strength of transmission from two radio transmitters associated with the entry point may need to be above prescribed levels in order to satisfy the entry criteria; if the signal strength criterion and perhaps other criteria are satisfied for the entry point, the smartphone determines that an entry request may be generated for transference to another device; as described for integer 1.3.2, in order to correctly receive and identify the Bluetooth Low Energy signal, the received signal strength must satisfy the criterion that it is at least strong enough to allow digital packets to be decoded. (b) In Mr Elliott's opinion, the words "based on" in integer 1.3.3 require a much more direct connection between the entry criteria and the value of the received signal strength; in other words, the signal strength needs to be included as one of the criteria (T182). Although Mr Elliott subsequently agreed with the proposition "[p]rovided that the criterion is based in some way on the received signal strength, that's enough" (T183), I do not consider this to represent the substance of his evidence, which is more accurately reflected at T182. 113 In my view, on their proper construction: (a) integer 1.3.2 encompasses measuring the strength of an entry signal that has been received (eg, measuring the RSSI of a Bluetooth signal); it does not also encompass the ability of a smartphone to correctly decode a received signal (thereby determining that the strength of the signal is at or above a threshold value for the smartphone to be able to correctly decode it); and (b) integer 1.3.3 requires a comparison to be made between one or more entry criteria and the received signal strength that the smartphone measures for the entry signal, or some calculation to be undertaken based on that measured value; it is not sufficient that the smartphone merely uses the received signal strength in some way to determine whether a condition of entry to the car park is satisfied. 114 I consider that the construction of these integers set out above accords with the ordinary meaning of the words used in the integers, having regard to their context. The ordinary meaning of the words "determine a received signal strength of the one or more entry signals" is measuring the strength of the signal. The words do not naturally convey the ability to correctly decode the signal and thus indirectly determine that the signal strength is sufficient to enable correct decoding. Further, the ordinary meaning of the words "determine if one or more entry criteria have been satisfied based on the received signal strength …" is that set out above. The words do not naturally convey merely using the received signal strength in some way to determine whether a condition of entry to the car park is satisfied. Further, the construction of these integers set out above is consistent with, and furthers, the purpose of the invention, which is generally directed to determining when the user's car is in the correct position for the entry barrier to open. Measuring the strength of an entry signal (eg, the RSSI value in the case of a Bluetooth signal) assists in achieving this objective. On the other hand, determining that the entry signal is able to be correctly decoded (which indicates that the signal is strong enough to be correctly decoded) provides only limited assistance in meeting that objective. As Mr Sizer accepted, various factors, in practical terms, could translate to quite different distances for two different individuals, in terms of how far away they may be when their smartphone can decode the signal. 115 The construction that I have adopted in relation to integers 1.3.2 and 1.3.3 involves an acceptance of UbiPark's position. While the construction that I have adopted does not correspond with the views of either expert, it is not necessary that I accept the opinions of one or other expert, or even both experts. For the reasons given above, I consider that the construction set out above is to be preferred to the views of the experts, to the extent that they expressed a different construction. 116 The same construction applies to integers 1.3.7 and 1.3.8 (in relation to exit). 117 I turn now to consider whether integers 1.3.3 and 1.3.8 are present in UbiPark's technology. For this purpose, it is necessary to refer to some further aspects of UbiPark's technology. 118 In his second affidavit, Mr Van De Camp gave evidence regarding a calculation performed by the UbiPark technology to determine the "closest lane" (in other words, the lane in which the car is located). He stated: 12. The BlueCats SDK module within the UbiPark App provides the received signal strength for each Bluetooth signal that the user's smartphone receives. This signal strength value is then used by a function called TrySetAverageRSSI that performs calculations using the signal strength value that are used later to determine the closest lane. 13. The UbiPark App also runs a function called 'UpdateLanes' to perform calculations based on the received signal strength value for Bluetooth signals that the servers inform the app are from relevant Bluetooth beacons (that is, beacons installed by UbiPark) in order to calculate which lane is the closest to the user's smartphone. 14. For each car park that UbiPark has been implemented for, other than the implementation for Perth Airport (and Adelaide car park trial), the calculations performed by TrySetAverageRSSI and UpdateLanes are performed on the App but stored only on the UbiPark servers, and are not used to select a specific lane for the UbiPark App to display, where there are multiple lanes. For each such implementation, the UbiPark App displays all available entry or exit lanes, as applicable, in a group, and not the lane calculated to be the closest lane. For some car parks the 'group' consists of a single lane where there is only a single entry barrier, or a single exit barrier. There has also not been any work done at any car parks, other than the Perth Airport car park, and a trial that was conducted at a car park in Adelaide in about 2018/19, to determine whether the beacon set up used at a specific car park would enable an accurate calculation of the closest lane. … 16. For the Perth Airport implementation (and Adelaide car park trial), the TrySetAverageRSSI and UpdateLane calculations were used by the UbiPark App to calculate the barrier/lane that was closest to the user's phone, and the UbiPark server would send that user's phone a configuration setting that instructed the UbiPark App to display a page that only included a button to open that lane. … (Emphasis added.) 119 In Mr Sizer's fifth report, he provided a description of certain calculations performed by the UbiPark App that relate to the Bluetooth signal strength, in response to Mr Van De Camp's second affidavit. Mr Sizer stated at [8.2.10] of that report: In summary, with reference to the source code snippet depicted in paragraph 8.2.7 above, in order for method Update Lanes() to find a Closestlane which leads to the user's screen progressing from the MoveCloser view which displays 'please wait', to the ClosestlaneFound view which displays the lane selection button(s), the following conditions must be satisfied: 1. entry signals from one or more beacon(s) associated with a lane must be received with signal strength sufficient for their message(s) to be correctly decoded, and 2. of those beacon(s), at least one beacon must have an RSSI value of less than 0 (UpdateLanes() line 777), and 3. of those beacon(s), at least one must have detectionSecs greater than or equal to MinDetectionSecs (UpdateLanes() line 807), and 4. of those beacon(s), at least one must have either RSSI greater to or equal to minRSSI (UpdateLanes() line 811 ); or detectionSecs greater to or equal to MaxDetectionSecs (UpdateLanes() line 813). 120 The evidence includes a five-page document that sets out the way in which UbiPark configures groups of lanes in respect of several car parks (exhibit A5) (the Lane Configuration document). The document was tendered during Mr Van De Camp's evidence in chief. Mr Van De Camp said during oral evidence in chief that the document shows screenshots from the website that UbiPark uses to configure the UbiPark servers. In relation to this document, Mr Van De Camp gave the following evidence, which I accept: (a) One of the fields in the Lane Configuration document is "Detection Type". Mr Van De Camp explained that this can be one of two values: "All" or "Closest". If the Detection Type is set to "All", whenever a user uses the UbiPark App to enter or exit a car park, all lanes within the group will be displayed. If the Detection Type is set to "Closest", the UbiPark App will only display a screen with the closest lane. For the Barangaroo Reserve car park, for example, this field was set to "All". The same applied to all car parks other than the Perth Airport car park and the Adelaide car park trial. For those car parks, the field was set to "Closest". (b) Another field in the Lane Configuration Document is "Min RSSI". This field was left blank in the screenshots for all of the car parks in the document. The effect of this is that the field defaults to zero. The UbiPark technology tests whether the numerical value of the RSSI, being the strength of the signal from the beacon, is equal to or greater than the Min RSSI. The RSSI is calculated on a logarithmic scale from -100 to zero. The number -100 is the lowest value. Zero is the highest value. A value closer to zero represents a stronger signal. In practice, the RSSI value will always be less than zero. It follows that, in practice, this test will never be passed. The UbiPark App then proceeds to the steps relating to "Min Detection Secs" and "Max Detection Secs", which are also fields in the Lane Configuration document. The field "Min Detection Secs" represents the duration in seconds that the UbiPark App will wait before displaying a lane selection screen. The field "Max Detection Secs" sets the maximum amount of time in seconds that the UbiPark App will wait before displaying a lane selection screen. Its purpose is to prevent the user having to wait indefinitely for the lane selection screen to appear. If the Min RSSI test is failed, then, after the Max Detection Secs, the appropriate entry message or exit message screen will be displayed. In other words, failure of the Min RSSI test does not stop the process continuing. (c) Mr Van De Camp confirmed during cross-examination that the TrySetAverageRSSI and UpdateLanes calculations are performed by the UbiPark App in all locations. He said that, if the Detection Type is set to "Closest" (i.e. the Perth Airport car park and the Adelaide car park trial configuration), the UbiPark technology makes use of that calculation; if the Detection Type is set to "All" (i.e., the configuration for the other car parks), the calculation is "essentially insignificant" because the UbiPark App displays an entry message screen consisting of all lanes (where there are multiple lanes) or one lane (where there is only one lane). Mr Van De Camp gave evidence during cross-examination that the UpdateLanes calculation includes a test that asks whether the RSSI value is less than zero. The following exchange took place between senior counsel for the TMA parties and Mr Van De Camp: And there must be an RSSI value which is a numerical value less than zero in order for the app to proceed further from that point; correct?---Yes. If there is no RSSI value which is a numerical value less than zero, it won't proceed further and you won't ultimately get a lane selection button displayed; correct?---Correct. So in that sense, the determination of an RSSI value that's a numerical value that's less than zero is a necessary condition in order for a lane selection button to be displayed to the user; that's right, isn't it?---Yes. (d) I note that the evidence in the above passage is consistent with the evidence in Mr Sizer's fifth report set out at [119] above. 121 In the joint report, the experts agreed that the UbiPark technology makes use of the received signal strength of entry/exit signals from Bluetooth beacons, in determining whether a user is permitted to enter/exit the car park. However, the experts were unable to agree about where the determination (of whether the entry criteria are satisfied) occurs, that is, whether the determination is performed by the smartphone or the UbiPark servers. In summary: (a) In Mr Sizer's opinion, the smartphone included in the UbiPark technology determines that an entry criterion has been satisfied by determining that the strength of a signal received by the smartphone from a Bluetooth beacon associated with the car park entry meets or exceeds the level required to allow the smartphone to correctly decode that signal. Additionally, the smartphone determines that an entry criterion has been satisfied by determining that the strength of a signal received from a Bluetooth beacon associated with the car park entry satisfies requirements that allow the smartphone to determine the "closest lane". (b) In Mr Elliott's opinion, the UbiPark App receives messages transmitted by the Bluetooth beacons; these can be considered as "entry signals" (or "exit signals"); the UbiPark App forwards those entry signals (or exit signals) to the UbiPark servers; in order to accomplish this, from a technical perspective, the UbiPark App must decode the received signal to determine that it is an entry signal (or exit signal); further, as set out in Mr Van De Camp's first affidavit, the UbiPark App "forgets the UUID"; Mr Van De Camp's affidavits do not disclose the purpose of the stored UUIDs, but it can be inferred that the UbiPark App most likely processes the signals it receives in some way; it can be inferred that there was sufficient signal strength to allow signals to be decoded. In Mr Elliott's opinion, the UbiPark App carries out some calculations based on signal strength, but it is not clear whether this refers to: (i) the magnitude of the signal strength of the signal received from the transmitting beacon; or (ii) the measured power value contained within the signal. In Mr Elliott's opinion, the UbiPark servers carry out some processing on one or more of the entry signals to determine whether that user was authorised to enter (or exit) the restricted area; the detail of this processing is not disclosed in Mr Van De Camp's affidavits, but Mr Van De Camp's second affidavit provides some examples of the authorisation tests that may be carried out; subsequent to this processing, the UbiPark servers then send to the UbiPark App a message that enables the UbiPark App to display a screen asking the user to select which gate they wish to enter; if the user wishes to enter the restricted area, they then select the barrier, which causes another message to be sent to the UbiPark servers; further authorisation checks are then carried out by the servers and, if successful, the UbiPark servers direct the barrier to open. In light of the above, in Mr Elliott's opinion, the UbiPark App acts primarily as a conduit between the Bluetooth beacons, the user and the UbiPark servers; Mr Elliott could not find anything in Mr Van De Camp's affidavits that said or suggested that the UbiPark App determines if one or more entry criteria had been satisfied. 122 The following points emerged during the concurrent evidence session: (a) During oral evidence, Mr Sizer summarised his view as to the two ways in which the received signal strength has a role to play. He said: … there are two ways in which signal strength come[s] into play in determining entry or exit[.] [T]he one that we've already discussed in great detail is [that] … the signal strength is sufficiently high that the phone can decode it and identify it as an entry signal, so that's an absolute criteria[.] [I]f that's not satisfied, then the vehicle simply won't be able to progress through to enter the carpark. There is also another way in which [the] receive[d] signal strength is used in discussion of determining the closest lane in the UbiPark system where the signal strength must meet certain criteria before the user is presented with the open lane button. So, in summary, I'm referring to the use for signal strength in both of those manners. (b) Mr Elliott accepted that he had not been asked to, and had not, reviewed the source code. He was therefore unable to agree or disagree with some of Mr Sizer's opinions. (c) Mr Elliott accepted that the decoding of the signal from the Bluetooth beacon happens on the smartphone. Mr Elliott accepted that this is one basis on which the UbiPark technology includes a smartphone that is configured to determine if one or more entry criteria have been satisfied. However, he qualified that by saying that he did not accept that the UbiPark technology includes the smartphone. (d) Mr Sizer gave the following evidence as to whether the UbiPark App "acts primarily as a conduit": … my understanding is that the UbiPark app acts in its own right to make decisions. It's not simply a conduit that sends information to the server, and then the server responds with decisions based on that information. The app itself is using that information to make decisions locally. In particular, in relation to the progression of events that lead to the display of the entry lane selection screen done locally by the app. The information is conveyed to the server, but the server does not direct the app on how to act. 123 The effect of the above evidence may be summarised as follows: (a) For all car parks, it is a necessary part of the process that the UbiPark App is able to correctly decode a signal received from a Bluetooth beacon located at a UbiPark Car Park. This is implicit in the fact that, as set out in the outline of UbiPark's technology, the UbiPark App constantly scans for new UUIDs that identify that a new Bluetooth signal is being received; and, each time the app receives a Bluetooth signal with a new UUID, it sends that new UUID to the UbiPark servers. (b) For all car parks, the UbiPark App carries out a "closest lane" calculation based on the RSSI values of the signals that have been received from the Bluetooth beacons at the car park; it is an implicit prerequisite to this calculation that the smartphone has received at least one signal for which there is an RSSI value (which, in practice, will always be less than zero); if the "closest lane" calculation cannot be performed, the process will not continue. (c) Where the Detection Type is set to "Closest" (that is, the configuration for the Perth Airport car park and the Adelaide car park trial), the closest lane (as so calculated) will be displayed on the entry message screen. Where the Detection Type is set to "All" (i.e. all other car parks), the entry message screen will display all entry lanes for the car park; in this situation, the calculation of the closest lane referred to in (b) above has no practical role beyond allowing the process to continue. (d) The Min RSSI field is blank for all car parks and defaults to zero. The UbiPark technology (I will assume, the UbiPark App) performs a test of whether the measured value of the RSSI is equal to or greater than the Min RSSI. In practice, the measured RSSI value will always be less than zero, therefore this test will never be passed. However, this does not stop the process from continuing. This is because the entry message screen will be displayed after the number of seconds set for Min Detection Secs (usually only a few seconds). (e) It follows from (d), that the UbiPark technology, as implemented in practice, does not involve a comparison between a predetermined minimum RSSI value (eg, -70 dBm) and the measured RSSI value to determine whether the measured value exceeds the stipulated minimum. 124 In my view, there is some difficulty in seeing how the elements of integer 1.3.3 are present in the UbiPark technology. 125 In considering this issue, I will proceed on the basis that it is not necessary for the "computer program" (here, the UbiPark App) to configure the smartphone to do the things referred to in integers 1.3.1, 1.3.2 and 1.3.3. I will proceed on this basis because this raises an issue of construction that was not the subject of complete argument at the hearing. 126 Putting that issue to one side, I am satisfied that integers 1.3.1 and 1.3.2 are present in UbiPark's technology. The smartphone is configured to receive one or more entry signals etc. (integer 1.3.1) and to determine a received signal strength of the one or more entry signals (integer 1.3.2). However, I am not satisfied that the smartphone is configured to "determine if one or more entry criteria have been satisfied based on the received signal strength of the one or more entry signals in order to generate and transfer an entry request" (integer 1.3.3). This would be the case if, for example, the Min RSSI field was set to a predetermined negative number and the process involved checking whether the measured RSSI was greater than that number. However, for all car parks, that field is left blank and defaults to zero. This means that the minimum RSSI test that is carried out will never be passed. Further, that test has no practical consequence as the entry message screen will be displayed after the time set for "Min Detection Secs" (usually, a few seconds) has elapsed. 127 The TMA parties contend that, when using the UbiPark App, the user's smartphone will only display the entry message screen if the following conditions are satisfied: (a) entry signals from one or more beacons associated with a lane are received with signal strength sufficient for their message to be correctly decoded; (b) of those beacons, at least one beacon must have an RSSI value of less than zero; (c) of those beacons, at least one must have "detectionSecs" greater than or equal to the parameter "Min Detection Secs"; and (d) of those beacons, at least one must have either RSSI greater than or equal to the parameter "Min RSSI" or "detectionSecs" greater than or equal to the parameter "Max Detection Secs". 128 The TMA parties contend that each of (a) and (b) and, depending on how the system is configured, (d) above, is an entry criterion the satisfaction of which is based on the received signal strength of the entry signal. 129 In relation to (a) above, this contention fails in light of the construction I have adopted, above, in relation to integers 1.3.2 and 1.3.3. The ability of the smartphone to correctly decode the entry signal (while a necessary step in the process used by UbiPark's technology) does not constitute determining the received signal strength of the entry signal; nor does it involve determining if one or more entry criteria have been satisfied based on the received signal strength. 130 In relation to (b), while it is necessary for there to be a value for RSSI that is less than zero for the "closest lane" calculation to be carried out, and that calculation must be performed for the process to continue, it is artificial to regard the existence of a value for RSSI that is less than zero as an entry criterion. In substance, the UbiPark App is using the RSSI value (or values) to calculate which lane is the closest lane. While this test cannot be performed unless there is an RSSI value (which, if it exists, will always be less than zero), the existence of a value for RSSI is merely a prerequisite to the conduct of a calculation directed to determination of the closest lane. Putting this another way, the calculation uses the RSSI value as a closest lane criterion rather than as an entry criterion. 131 Paragraph (d) above has two alternative parameters. In relation to the first alternative, while the "Min RSSI" test could theoretically constitute a determination of whether one or more entry criteria have been satisfied "based on the received signal strength" (for the reasons set out above), in practice the "Min RSSI" field is left blank for all car parks and defaults to zero. It therefore does not operate as such a test. In relation to the second alternative in (d), I am not satisfied that the "Max Detection Secs" test involves a determination "based on the received signal strength" of the one or more entry signals. The test essentially involves the passing of a period of time (usually, a few seconds). It is not concerned with the received signal strength (albeit that a signal needs to have been recently received and decoded). 132 For these reasons, I am not satisfied that integer 1.3.3 is present in the UbiPark technology. It follows that integer 1.3.8 is also not present in UbiPark's technology.

Integers 1.3.4 and 1.3.9 133 In relation to integer 1.3.4, the experts agreed in the joint report (as clarified in oral evidence at T203) that, insofar as the integer refers to what happens if the entry criteria are satisfied, it means that the entry request is transferred to the communication system by the smartphone subject to the one or more entry criteria being satisfied. However, beyond this, the experts disagreed as to the construction of integer 1.3.4. In summary: (a) In Mr Sizer's opinion, the integer means that, when the smartphone determines that an entry request may be generated for transference to another device, based on satisfaction of the entry criteria, the smartphone generates an entry request and transfers it to the communication system for transference to other elements of the system. Mr Sizer considers that "in response to" encompasses a sequence of events, not the final event in a sequence of events. (b) In Mr Elliott's opinion, as set out in his second affidavit, the integer requires that the entry request be generated and transferred "in response to" one or more entry criteria being satisfied, with the words "in response to" having their ordinary English meaning. 134 The following points emerged during the concurrent evidence session: (a) Mr Elliott was taken to various parts of the specification of the 335 Patent, including [0009] and [0021], and accepted that there are embodiments of the invention where the smartphone is configured so that the generation and transfer of the entry request requires some form of user interaction. He accepted that this included the user being presented with a button that they would press following which the entry request would be transferred. Mr Sizer agreed with this. (b) In reference to [00104] of the specification, which refers to Figure 4, Mr Elliott accepted that, in simple terms, this indicated that user intervention is allowed, but it is preferred that this does not occur. Mr Sizer agreed with this. (c) Mr Elliott was taken to claim 10 of the 335 Patent. He accepted that this confirmed that there is a more specific embodiment of the invention where user intervention is not required in order for the process to proceed. He accepted that the presence of claim 10, as a dependent claim, confirms that there are other embodiments within claim 1 where user interaction may be required in order for the process to proceed, and that this may include the user being required to press a button following which the entry request will be transferred. Mr Elliott accepted that the language of integer 1.3.4 ("in response to the one or more entry criteria being satisfied, generate and transfer … the entry request") allows for that type of embodiment. Mr Sizer agreed with this. (d) In reference to Figure 4, Mr Sizer noted that the language refers to the transfer of an access request, as distinct from the barrier opening automatically. He said he would not accept that the transfer of an access request necessarily leads to automatic opening of the barrier, because there might be authorisation checks and other actions could possibly occur. 135 In my view, for the reasons that follow, on its proper construction, integer 1.3.4 means that, if and when the one or more entry criteria referred to in integer 1.3.3 have been satisfied, the smartphone sends an entry request for the barrier to be opened. I do not accept the contention of the TMA parties that integer 1.3.4 is satisfied both in circumstances where the entry request is transferred automatically (that is, without any user interaction with their smartphone) and in circumstances where there is user interaction with their smartphone (for example, a user tapping on a button on the smartphone's screen). 136 The words "in response to" in integer 1.3.4 are used in their ordinary sense. It is not suggested that they have a technical meaning, or that they have a special or unusual meaning in the area of technology that is the subject of the 335 Patent. 137 The words are to be read in context. The context includes parts of the specification that suggest that the invention is not limited to an automated system: see [0021] (set out at [22] above), [0060] (set out at [25] above), [00108] (set out at [30] above) and [00141] (set out at [33] above). However, it should also be noted that the focus of the specification generally is on methods for analysing the strength of the signal from the entry/exit beacon or beacons in order to determine when to send the entry/exit request to open the barrier, without the need for the user to interact with their smartphone. The context also includes claim 10, which has been set out at [39] above. This is a dependent claim that adds an integer or requirement that the smartphone is configured "to automatically transfer at least one of the entry request and the exit request without user interaction". The clear implication is that claims 1 to 9 are not limited to the automatic transfer of an entry request and exit request; otherwise, claim 10 would add nothing. This strongly suggests that some form of user interaction is within the scope of claims 1 to 9. 138 Reading the words in context, and notwithstanding the strong contra-indicators referred to above, including claim 10, I am unable to see how the words "in response to" can bear the meaning proposed by the TMA parties. To my mind, the words "in response to" in integer 1.3.4 requite a direct relationship between: (a) satisfaction of the one or more entry criteria referred to in integer 1.3.3; and (b) the generation and transfer of the entry request. For example, where there is a sequence of steps (A, B and C) and each step in the sequence is required to occur before an event (D) happens, the event (D) happens "in response to" the last step in the sequence (C) or the whole series of steps in the sequence (A, B and C); the event (D) does not happen "in response to" the penultimate step in the sequence (B). In this example, satisfaction of step B will not necessarily lead to the event (D) happening. If step C does not also occur, the event (D) will not happen. Applying the logic of that example here, in circumstances where an entry request will only be transferred if (a) there is satisfaction of the one or more entry criteria referred to in integer 1.3.3 and (b) the user presses a button on the screen of their smartphone, the entry request is generated and transferred "in response to" the user pressing the button on their smartphone; it is not generated and transferred "in response to" satisfaction of the one or more entry criteria. If the criteria are satisfied, but the user does not press the button, the entry request will not be generated and transferred. 139 I acknowledge that this construction appears to produce redundancy in respect of claim 10 (in relation to redundancy, see Davies v Lazer Safe Pty Ltd [2019] FCAFC 65 at [65]-[66] per Greenwood, White and Burley JJ). However, in my opinion, the matters referred to in the preceding paragraph are so strong that they outweigh that consideration. Further, I acknowledge that this construction is inconsistent with the views of the experts as set out above. While I have had regard to their views, ultimately the issue of construction is for the Court to determine. 140 For these reasons, I consider that integer 1.3.4 has the construction set out in the first sentence of [135] above. The same construction applies to the corresponding words in integer 1.3.9. 141 I turn now to consider whether integers 1.3.4 and 1.3.9 are present in the UbiPark technology. 142 The experts disagreed in the joint report as to whether the UbiPark technology includes a smartphone that is configured to, "in response to the one or more entry criteria being satisfied, generate and transfer, to the communication system, the entry request". In summary: (a) In Mr Sizer's opinion, in order for the UbiPark technology to grant the user entry to the car park, an entry signal transmitted by the system's Bluetooth entry beacon must be received by the smartphone with sufficient strength for the smartphone to be able to decode the digital information contained in that signal, and identify it as being an entry signal; the smartphone must then determine the "closest lane" based on the measured strength of the received entry signal(s); the smartphone then presents the screen containing the "Open Lane X" button(s) to the user, and the user presses the button for the lane via which they wish to enter the car park, following which the entry request is sent by the smartphone to the servers. Mr Sizer considers the entry request to be generated and transferred "in response to" this sequence of events. (b) In Mr Elliott's opinion, the UbiPark App sends the entry request (to the servers) "in response to" the user pressing the button on their screen; it does not send that entry request "in response to" any assessment of signal strength; this includes what Mr Sizer considers amounts to a determination of received signal strength, namely the decoding of a signal from an entry beacon. 143 The following points emerged during the concurrent evidence session as to whether integer 1.3.4 is present in UbiPark's technology: (a) Mr Elliott initially reiterated his view that it is the pressing of the button that generates the entry request. However, he then accepted that "in that scenario, the entry request is generated and transferred in response to the one or more entry criteria being satisfied". Mr Sizer agreed with this. (b) Proceeding on the basis of Mr Sizer's understanding of determining the received signal strength (i.e. decoding the entry signal), it was put to Mr Sizer that the smartphone might decode the signal and present the lane option button (i.e. the entry message screen), and the user might never press the button. Mr Sizer accepted that this was possible and, in such a case, no entry request would be sent. He accepted that, in that scenario, although the criterion (the signal being received) is satisfied, an entry request is not sent. 144 In my view, integer 1.3.4 is not present in the UbiPark technology. 145 In considering this issue, I proceed on the basis that the request to enter that is sent by the UbiPark App to the UbiPark servers constitutes an "entry request". As set out above, the UbiPark App sends a request to enter to the UbiPark servers, and the UbiPark servers then perform another check to see if the user remains authorised to enter and, if so, send a direction to open to the barrier. It might be suggested that the entry request is the direction that is sent by the UbiPark servers to the barrier. However, both experts proceeded on the basis that the request to enter that is sent by the UbiPark App to the UbiPark servers constitutes an "entry request". I will proceed on the same basis. 146 It is clear from the outline of Ubi Park's technology (set out above) that, in all cases, the user must press a button on the entry message screen before an entry request is sent by the UbiPark App to the UbiPark servers. If the user does not press the button, the entry request is not sent. In these circumstances, the entry request is sent "in response to" the user pressing the button; it is not sent "in response to" the one or more entry criteria referred to in integer 1.3.3 being satisfied. This conclusion follows largely, if not wholly, from my conclusion on the construction issue regarding integer 1.3.4. 147 For these reasons, integer 1.3.4 is not present in the UbiPark technology. It follows that the corresponding part of integer 1.3.9 is also not present in UbiPark's technology

Integers 1.3.5 and 1.3.9 148 Integers 1.3.5 and 1.3.9 read: [1.3.5] receive, from the communication system, authorisation data indicative of the entity being granted access to enter the restricted area by an access control system; … [1.3.9] in response to the one or more exit criteria being satisfied, generate and transfer, to the communication system the exit request indicative of the authorisation data in order to exit the restricted area. 149 In Mr Sizer's fourth report at [11.4.4] he set out two possible interpretations of the words "indicative of the entity being granted access to enter the restricted area by an access control system" (when considered in isolation from the remainder of claim 1): (a) The first interpretation is that the authorisation data is indicative of the fact that the access control system has granted the entity access to the restricted area. In other words, the authorisation data is a sign that the entity has been permitted entry to the restricted area. (b) The second interpretation is that the authorisation data is indicative of the entity, by being related to the entity in some way. In other words, the authorisation data is a sign that the entity exists, or perhaps of who they are. 150 It appears that Mr Sizer considered there to be an ambiguity in integer 1.3.5. The possible ambiguity is whether the authorisation data needs to be indicative of: (a) the entity (the user) being granted access to enter the restricted area (the first interpretation); or (b) the entity (the user) (the second interpretation). 151 In the joint report, the experts agreed that the first interpretation is a valid interpretation of integer 1.3.5, in that it allows for the provision of a "virtual ticket" as described in the 335 Patent's specification at [0062]. The experts disagreed as to whether the second interpretation is a valid interpretation for the purposes of integer 1.3.5. In summary: (a) In Mr Sizer's opinion, the second interpretation is a valid interpretation, but the first interpretation is the preferable interpretation in that it allows for the provision of a "virtual ticket". (b) In Mr Elliott's opinion, if claim 1 is read in the context of the specification, "authorisation data" refers to data that is specific to a particular parking session. Hence, Mr Elliott does not consider the second interpretation to be an available interpretation in the context of claim 1. 152 I note for completeness that, during the concurrent evidence session, Mr Sizer accepted that there was nothing in claim 1 that required the unique information about the smartphone to be communicated to the communication system. He said that his inference from reading the specification and deducing what would be required for a practical system to operate to fulfil the role of a virtual ticket, is that unique information about the smartphone would need to be conveyed by the smartphone to the communication system. Mr Sizer accepted that a practical system could operate if the authorisation data itself had that uniqueness. 153 In my view, the first interpretation should be accepted and the second interpretation rejected. The first interpretation accords with the ordinary meaning of the words, read in context, while the second interpretation does not. Accordingly, properly construed, the words "indicative of the entity being granted access to enter the restricted area by an access control system" in integer 1.3.5 mean that the authorisation data is indicative of the fact that the access control system has granted the entity access to the restricted area. I note that the authorisation data is indicative of the entity "being granted access", as distinct from having prior approval to enter the car park. 154 I turn now to the construction of the words "indicative of the authorisation data" in integer 1.3.9. In the joint report, the experts agreed that an exit request is "indicative of the authorisation data" if the exit request corresponds in some way with the authorisation data received by the smartphone from the communication system during entry; this does not require the exit request to contain the "authorisation data" or elements of it, but does not preclude it from doing so. 155 In my view, on their proper construction, the words "indicative of the authorisation data" in integer 1.3.9 mean that the exit request corresponds in some way with the authorisation data received by the smartphone from the communication system during entry (that is, the authorisation data that is indicative of the entity being granted access to enter the restricted area). I accept the experts' interpretation. It accords with the ordinary meaning of the words, read in context. 156 I turn now to consider whether integer 1.3.5 is present in UbiPark's technology. 157 In the joint report, the experts agreed that the UbiPark technology includes "authorisation data" that enables the technology to determine whether the particular user has been granted access to a restricted area. The experts also agreed that the smartphone receives "authorisation data" from the UbiPark servers. The experts were, however, unable to agree about the exact form of the "authorisation data" in the UbiPark technology. In summary: (a) In Mr Sizer's opinion, the "inCarPark" data element sent from the UbiPark servers to the user's smartphone and stored on their smartphone, by data element assignment, as "appSettings.InCarPark", constitutes "authorisation data" that tells the smartphone that the user's vehicle is in the car park. Further, "appSettings.InCarPark" is indicative of who the user is, because it is stored on their smartphone and only their smartphone. This gives the "appSettings.InCarPark" data element meaning beyond viewing it as a simple binary flag. The message that contains this data element also contains the user's identity, and information about the car park, which can also be considered as part of the "authorisation data". (b) Mr Elliott stated in the joint report that there was insufficient information in Mr Van De Camp's affidavits to enable Mr Elliott to form a reasonable opinion on the exact format and content of "authorisation data" in the context of the UbiPark technology. 158 The following points emerged during the concurrent evidence session: (a) In relation to the statement in the joint report that the experts agreed that the smartphone receives "authorisation data" from the UbiPark servers, Mr Sizer said that the Boolean data (i.e. the setting true or false in "appSettings.InCarPark") is one of the elements of this authorisation data. He said there are other elements, but the Boolean flag is the clear indication of authorisation of entry. (b) Mr Elliott accepted that: in relation to the entry procedure, the UbiPark technology knows the identity of the entity because there have been communications between the system and the entity that include the User ID; upon the entity being granted access to the car park, the "appSettings.InCarPark" data element is sent from the servers to the user's smartphone and then stored on the phone; this indicates, by inference, that the entity has been granted access to the car park; and the sending of that data element, in the context of the UbiPark technology, is sufficient to constitute the sending of "authorisation data" to the smartphone for the purposes of integer 1.3.5. 159 In my view, integer 1.3.5 is present in the UbiPark technology. As set out at [95] above, the "appSettings.InCarPark" data element is kept in non-persistent memory in the UbiPark App and is set to true or false based on the response received from the servers after the app sends a request to get the user's current status. The UbiPark App will send a request to the servers to get the user's current status when (among other things) the app detects a beacon and does not currently have a value for "appSettings.InCarPark". It will also send a request every 20 seconds while the user has the UbiPark App open on the "Access" tab and beacons are being detected. The response from the UbiPark servers includes a Boolean field (true or false) and the "appSettings.InCarPark" data element is set directly from this response. I consider that the response from the UbiPark servers constitutes "authorisation data indicative of the entity being granted access to enter the restricted area". While the response is merely a Boolean field and does not contain information that is specific to the user or the parking session, it is sent in response to a request from the user's smartphone for the user's current status (i.e. whether or not they are in the car park). In this context, I consider that the information constitutes authorisation data indicative of the user having been granted access to enter the car park. In some senses, it functions as a virtual ticket for that user; it indicates that they have been granted access to enter the car park. 160 In relation to integer 1.3.9, I have already concluded, above, that part of this integer ("in response to the one or more exit criteria being satisfied, generate and transfer … the exit request") is not present in UbiPark's technology. The issue now to be considered is whether, in any event, another part of the integer (that the exit request is "indicative of the authorisation data", that is, the authorisation data referred to in integer 1.3.5) is present in UbiPark's technology. 161 The experts were unable to agree about whether the exit request in the UbiPark technology is "indicative of the authorisation data". In summary: (a) In Mr Sizer's opinion, the exit request is "indicative of the authorisation data", in the form of the "appSettings.InCarPark" data element, because the exit request will not be generated by the user's smartphone unless the "appSettings.InCarPark" data element assumes the value "true". The sending of the exit request by the smartphone indicates that "appSettings.InCarPark" is true, and accordingly, the exit request is indicative of the authorisation data. Additionally, the exit request includes the "appSettings.InCarPark" data element. (b) Mr Elliott was not provided with sufficient information to determine the content of the "exit request" and therefore offered no opinion on whether the "exit request" was "indicative of the authorisation data". 162 Consistently with the approach taken at [145] above in relation to the entry request, I will proceed on the basis that the request to exit that is sent by the UbiPark App to the UbiPark servers constitutes an "exit request" for the purposes of integer 1.3.9. 163 In my view, the exit request sent by the UbiPark App to the UbiPark servers is "indicative of the authorisation data" within the meaning of integer 1.3.9. Although the exit request does not contain data that is specific to the user or the parking session, the exit request will not be sent unless the "appSettings.InCarPark" data element has the value "true". In these circumstances, in my opinion, the exit request is indicative of (corresponds in some way with) the authorisation data (namely, the Boolean information previously provided by the UbiPark servers to the UbiPark App). It is not necessary for the entry request to contain the authorisation data or elements of it. 164 In summary, I consider that integer 1.3.5 and the relevant part of integer 1.3.9 (that the exit request is "indicative of the authorisation data") are present in UbiPark's technology.

Conclusion in relation to claim 1 165 It follows from my conclusions in relation to integers 1.3.3/1.3.8 and 1.3.4/1.3.9 that UbiPark's technology does not infringe claim 1 of the 335 Patent.

Claim 4 166 In light of my conclusion in relation to claim 1, it is unnecessary to determine the issues relating to claim 4, which is dependent on claim 1.

Claim 11 167 Claim 11, which is an independent claim, is framed in terms of a "computer program" as distinct from a "system". Unlike claim 1, it does not refer to the entity being a user which is associated with a vehicle for parking within a vehicular parking area. Claim 11 provides that the "computer program configures the mobile communication device" to do various things. Subject to these matters, and some presently immaterial additional words in the last integer, the wording of the integers of claim 11 is substantially the same as claim 1. 168 In these circumstances, the consideration, above, of integers 1.3.3/1.3.8, 1.3.4/1.3.9 and 1.3.5/1.3.9 is equally applicable to the corresponding integers in claim 11. 169 Accordingly, for the same reasons, I conclude that UbiPark's technology does not infringe claim 11.

Claim 16 170 Claim 16, which is an independent claim, is framed in terms of a "mobile communication device" as distinct from a "system". Unlike claim 1, it does not refer to the entity being a user which is associated with a vehicle for parking within a vehicular parking area. Unlike claims 1 and 11, it does not refer to a "computer program". Rather, it is framed in terms of a mobile communication device that is configured to do various things. Subject to these matters, and some presently immaterial additional words in the last integer, the wording of the integers in claim 16 is substantially the same as claim 1. 171 In these circumstances, the consideration, earlier in these reasons, of integers 1.3.3/1.3.8, 1.3.4/1.3.9 and 1.3.5/1.3.9 is equally applicable to the corresponding integers in claim 16. 172 I therefore conclude, for the same reasons, that UbiPark's technology does not infringe claim 16.

Conclusion 173 It follows from the above that the Infringement Claim is to be dismissed. 174 In these circumstances, it is unnecessary to resolve certain issues of pleading and proof raised by UbiPark in paragraphs 46-49 of UbiPark's closing submissions. I note that those paragraphs were responded to in a note handed up by senior counsel for the TMA parties during closing submissions.

The Australian Consumer Law Claim 175 It follows from the dismissal of the Infringement Claim that the Australian Consumer Law Claim is also to be dismissed. A necessary element of that claim is infringement of the 335 Patent.

The Unjustified Threats Claim 176 Sections 128 and 129 of the Patents Act provide: 128 Application for relief from unjustified threats (1) Where a person, by means of circulars, advertisements or otherwise, threatens a person with infringement proceedings, or other similar proceedings, a person aggrieved may apply to a prescribed court, or to another court having jurisdiction to hear and determine the application, for: (a) a declaration that the threats are unjustifiable; and (b) an injunction against the continuance of the threats; and (c) the recovery of any damages sustained by the applicant as a result of the threats. (1A) The court may include an additional amount in an assessment of damages sustained by the applicant as a result of the unjustifiable threats, if the court considers it appropriate to do so having regard to: (a) the flagrancy of the threats; and (b) the need to deter similar threats; and (c) the conduct of the person who made the threats, being conduct that occurred after the person made the threats; and (d) any benefit shown to have accrued to the person who made the threats because of the threats; and (e) all other relevant matters. (2) Subsection (1) applies whether or not the person who made the threats is entitled to, or interested in, the patent or a patent application. 129 Court's power to grant relief if threats related to a standard patent or standard patent application If an application under section 128 for relief relates to threats made in respect of a standard patent or an application for a standard patent, the court may grant the applicant the relief applied for unless the respondent satisfies the court that the acts about which the threats were made infringed, or would infringe: (a) a claim that is not shown by the applicant to be invalid; or (b) rights under section 57 in respect of a claim that is not shown by the applicant to be a claim that would be invalid if the patent had been granted. 177 I will deal separately with the claim against TMA Capital and the claims against TMA Technology and Zipby.

Claim against TMA Capital 178 UbiPark alleges that TMA Capital threatened UbiPark with infringement proceedings in respect of the 335 Patent, referring to a letter dated 4 November 2021 from Benjamin & Khoury (lawyers acting for TMA Capital) to UbiPark (tab 4 of exhibit A1) (the Letter of Demand to UbiPark). This allegation is admitted. 179 UbiPark also alleges that TMA Capital threatened UbiPark's customers with infringement proceedings in respect of the 335 Patent, referring to letters dated 4 November 2021 from Benjamin & Khoury to each of International Parking Group Pty Ltd, Parking Investments & Developments Pty Ltd, Perth Airport Pty Ltd, Point Parking Pty Ltd, Victorian Comprehensive Cancer Centre Ltd and Peter MacCallum Cancer Centre (the Letters of Demand to Customers). This allegation is admitted. Four of these letters are in evidence (tabs 5 to 8 of exhibit A1). 180 UbiPark alleges that the threats of infringement proceedings related to the supply by UbiPark of its parking technology platform to car park operators in Australia. This is admitted. 181 UbiPark alleges that UbiPark is a "person aggrieved" within the meaning of s 128 of the Patents Act. This is admitted. 182 UbiPark alleges that TMA Capital's threats of infringement proceedings in respect of the 335 Patent were and are "unjustifiable" within the meaning of ss 128 and 129 of the Patents Act. The TMA parties deny this allegation and rely on the grounds set out in their cross-claim. It follows from my dismissal of the Infringement Claim that TMA Capital has not made out its defence (see s 129). 183 Accordingly, UbiPark has established that TMA Capital made unjustifiable threats of patent infringement proceedings within the meaning of ss 128 and 129 of the Patents Act. 184 Subject to any further submissions the parties may wish to make, it would appear to be appropriate to grant the declaratory and injunctive relief sought by UbiPark against TMA Capital in the further amended originating application, namely: (a) a declaration pursuant to s 128(1)(a) of the Patents Act and s 21 of the Federal Court of Australia Act 1976 (Cth), that each of the threats of patent infringement proceedings made by TMA Capital against UbiPark in respect of the 335 Patent was unjustifiable; and (b) an injunction pursuant to s 128(1)(b) of the Patents Act to prevent TMA Capital from making further threats of patent infringement proceedings in respect of the 335 Patent against UbiPark in respect of UbiPark's products and services. 185 The issue of damages will need to be dealt with at a subsequent hearing, unless it can be resolved.

Claim against TMA Technology and Zipby 186 In relation to TMA Technology and Zipby, Ubipark alleges in [10A] of the further amended statement of claim that each of them: engaged in a common design with TMA Capital in making the allegations of patent infringement; procured or induced or aided and abetted TMA Capital to make those allegations; or was knowingly concerned in or party to TMA Capital making those allegations. On this basis, it is alleged that each of TMA Technology and Zipby is a joint tortfeasor in respect of TMA Capital's liability pursuant to s 128 of the Patents Act. This allegation is denied. 187 The conduct relied on in support of this allegation is primarily the sending of the Letters of Demand to Customers, but also, to a lesser extent, the sending of the Letter of Demand to UbiPark. 188 It is necessary to clarify a matter relating to the companies referred to in those letters and the entities that have been joined as the respondents to UbiPark's claim. In summary, although the letters refer to "TMA Tech Pty Ltd" or "TMA Tech", it is common ground that it was intended to refer to TMA Technology (Australia) Pty Ltd (which is the second respondent to UbiPark's claim) (T34-36). I will proceed on that basis. 189 It should be noted that, while the Letter of Demand to UbiPark was expressed in terms that it was sent on behalf of TMA Capital, TMA Tech Pty Ltd (to be read as TMA Technology) and Zipby, the Letters of Demand to Customers were expressed in terms that they were sent on behalf of TMA Capital alone. However, the Letters of Demand to Customers did refer, in the subject line, to TMA Capital, "TMA Tech" (to be read as TMA Technology) and Zipby. 190 UbiPark's submissions in support of the "joint tortfeasorship" claim can be summarised as follows: (a) Section 128 establishes a statutory tort, providing as it does for an action for damages to be brought. For there to be joint tortfeasorship there must be a "concurrence in the act or acts causing damage, not merely a coincidence of separate acts which by their conjoined effect cause damage": see The "Koursk" [1924] P 140 at 159-160, quoted with approval in Thompson v Australian Capital Television Pty Ltd [1996] HCA 38; 186 CLR 574 at 580; see also JR Consulting & Drafting Pty Ltd v Cummings [2016] FCAFC 20; 116 IPR 440 at [334]. (b) The relevant threats were made in the Letters of Demand to Customers. (c) The Letter of Demand to UbiPark was sent on behalf of all the TMA parties, and TMA Technology and Zipby both advance their cross-claim against UbiPark, which demonstrates their direct interest in the Letters of Demand to Customers. (d) TMA Technology and Zipby had a common design with TMA Capital to dissuade those customers (to whom letters of demand were sent) from dealing with UbiPark, an outcome that they now seek to achieve more broadly through their cross-claim. (e) TMA Technology and Zipby also have a common directorship with TMA Capital. TMA Capital and Zipby have a common shareholder. All companies were represented together at all times. All three companies are engaged in the conduct of a business that offers carpark access systems, including through the supply of an app (the Zipby App). (f) The above facts provide a sufficient factual basis on which to draw an inference of common design. In circumstances where none of the TMA Parties chose to lead evidence, that inference may be more safely drawn: Jones v Dunkel [1959] HCA 8; 101 CLR 298 and Blatch v Archer (1774) 1 Cowp 63; 98 ER 969. 191 For the reasons that follow, I am not satisfied that TMA Technology and Zipby were joint tortfeasors in respect of TMA Capital's liability pursuant to s 128 of the Patents Act. 192 In relation to the Letters of Demand to Customers, these letters were expressed as being sent on behalf of TMA Capital alone; they were not expressed as being sent on behalf of TMA Technology or Zipby. The reference in the subject-line to "TMA Tech" (which I will treat as a reference to TMA Technology) and Zipby is insufficient to indicate that the letters were being sent on behalf of TMA Technology and Zipby. In these circumstances, the relevant conduct (the sending of the letters) was not carried out by TMA Technology and Zipby. The fact that the companies were part of the same corporate group, and stood to benefit from the letters, is insufficient to link TMA Technology and Zipby with the sending of the letters. 193 If and to the extent that UbiPark relies on the Letter of Demand to UbiPark, while this letter was sent on behalf of TMA Technology and Zipby (in addition to TMA Capital), it is necessary to have regard to the text of the letter. The letter states that TMA Capital is the patentee of the 335 Patent and sets out certain claims of the patent (paragraphs 1 to 5). The letter alleges that UbiPark has infringed the patent (paragraphs 8 to 13). In paragraph 14, the letter alleges that UbiPark has engaged in misleading or deceptive conduct contrary to s 18 of the Australian Consumer Law. In paragraph 15, the letter: refers to "TMA Tech" (which I will treat as a reference to TMA Technology) and Zipby; states that they provide products and services to persons in respect of access control technology as embodied in the patent; and alleges that they have suffered loss as a result of UbiPark's conduct in contravention of s 18 of the Australian Consumer Law. The letter then foreshadows proceedings on behalf of TMA Technology and Zipby against UbiPark, pursuant to ss 236 and 237 of the Australian Consumer Law, seeking damages and other relief, such as an injunction. The balance of the letter sets out a demand that UbiPark do certain things, failing which proceedings will be commenced. Having regard to these matters, I consider that TMA Technology and Zipby were threatening UbiPark with proceedings under the Australian Consumer Law; they were not threatening patent infringement proceedings. In these circumstances, TMA Technology and Zipby did not engage in the relevant conduct (threatening patent infringement proceedings) by the sending of this letter. 194 For these reasons, the joint tortfeasorship claim against TMA Technology and Zipby is to be dismissed.

The Invalidity Claim 195 I will now consider the three grounds of invalidity pressed by UbiPark.

Manner of manufacture issue 196 UbiPark contends that the claimed invention, considered as a matter of substance, is in each case to an unpatentable method, implemented using generic computers (including a smartphone); no technical contribution or improvement is made in respect of the operation of the smartphone, or to the "communication system" with which the smartphone communicates. 197 The applicable principles can be summarised as follows. Section 18(1)(a) of the Patents Act requires that a patentable invention be a "manner of manufacture within the meaning of section 6 of the Statute of Monopolies". The High Court in National Research Development Corporation v Commissioner of Patents [1959] HCA 67; 102 CLR 252 (NRDC) at 269 explained that this enquiry is not one that is based on the meaning of the word "manufacture" as such, but rather the "right question" is whether the claim is to a "proper subject of letters patent according to the principles which have been developed for the application" of section 6. See also D'Arcy v Myriad Genetics Inc [2015] HCA 35; 258 CLR 334 at [18]; Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29; 274 CLR 115 (Aristocrat) at [21] per Kiefel CJ, Gageler and Keane JJ, and [114] per Gordon, Edelman and Steward JJ. 198 The High Court in Aristocrat recently considered the patentability of a computer-implemented invention (in that case, an electronic gaming machine, which functioned as a computer). While the Court split 3:3 on the result, all six judges affirmed the correctness of a series of Full Court decisions dealing with computer-implemented inventions (see [22]-[29] per Kiefel CJ, Gageler and Keane JJ, at [121]-[124] per Gordon, Edelman and Steward JJ), including Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150; 227 FCR 378 (Research Affiliates); Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177; 238 FCR 27 (RPL); and Encompass Corporation Pty Ltd v Infotrack Pty Ltd [2019] FCAFC 161; 372 ALR 646 (Encompass). 199 Both pluralities in Aristocrat expressed the following principles for assessing whether a claimed invention involves a manner of manufacture: (a) in considering whether there is patentable subject matter, the court should focus on the substance of what is claimed, and not the form, and accordingly there is a need to first characterise the invention (at [73], [101]-[103]); (b) schemes and plans that are not inherently patentable and which are merely implemented on a generic computer do not become patentable as a result (at [22], [24], [75]-[77], [121]-[122]); and (c) patentable subject matter may result where there is something more than mere implementation, which may include an improvement in the operation of the computer (at [25], [27], [77], [122]). 200 Of relevance for present purposes, in Aristocrat, Kiefel CJ, Gageler and Keane JJ stated: 24 The practical implementation of a discovery of an abstract truth about nature, or a strategy devised for the conduct of business, or a set of rules devised for a game - whatever the level of originality of the discovery or exhibited in the devising - is not patentable subject matter if the mode of implementation is not itself patentable. The distinction is "between mere intellectual information and a method that affect[s] the operation of an apparatus in a physical form". So, in Grant v Commissioner of Patents, it was held that a method for protecting assets from unsecured judgment creditors was not patentable. The method comprised establishing a trust, giving money to the trust, borrowing said money from the trust and the trustee securing the loan by taking a charge for the money over the asset. The Full Court (Heerey, Kiefel and Bennett JJ) concluded that the claimed method was "at best an abstract, intangible situation"; it had no physical consequence for process or product. 25 Of course, a claimed invention which serves a "mechanical purpose that has useful results" is not unpatentable "merely because the purpose is in the carrying on of a branch of business". In relation to computers and computer-related technology, it has been held in decisions of the Federal Court that a claimed invention will be a proper subject of letters patent if it has some "concrete, tangible, physical, or observable effect", as distinct from "an abstract, intangible situation" or "a mere scheme, an abstract idea [or] mere intellectual information". It has been held that an artificial state of affairs may also be created if the invention can broadly be described as an "improvement in computer technology", where the computer is integral to the invention, rather than a mere tool in which the invention is performed. … (Footnotes omitted; emphasis added.) 201 Also of relevance for this case are the principles stated by Gordon, Edelman and Steward JJ in the following passage: 120 … it is not enough that the scheme involves the use of a machine to manipulate abstract ideas. Where the manner of manufacture relies upon some change in state or information in a machine, then that change must produce an artificial state of affairs and a useful result. … 121 Numerous examples can be given where the proper characterisation of the claim is one that merely involves the use of a machine to manipulate an abstract idea rather than involving the implementation of the idea on a machine to produce an artificial state of affairs and a useful result. An idea that uses a computer, but does not generate some artificial state of affairs, remains no more than an idea. … 122 Although there was no artificial state of affairs created in any of these cases, and the results in all of these cases are plainly correct, some of the statements explaining the results in these and other cases must be read in the context of what was being decided. For instance, one expression of the characterisation question in some of the cases was whether the implementation of the scheme could be described as "an improvement in computer technology". A better way of expressing the point in such cases, consistent with the ultimate single question of whether there is a manner of manufacture within s 6 of the Statute of Monopolies, would be to ask whether, properly characterised, the subject matter that is alleged to be patentable is: (i) an abstract idea which is manipulated on a computer; or (ii) an abstract idea which is implemented on a computer to produce an artificial state of affairs and a useful result. The artificial state of affairs and useful result may be a physical change in something, but it need not be. The artificial state of affairs may be an improvement in computer technology, but it need not be. It is enough that the artificial state of affairs and useful result are created by "the way in which the method is carried out in the computer". (Footnotes omitted; emphasis added.) 202 UbiPark submits, in summary: (a) Claim 1 is to a "system" that comprises: (1) a "communication system"; and (2) a "computer program" that is executable by a mobile communication device (or smartphone). (b) The "mobile communication device" that is configured by the computer program must be able to execute or run the computer program, and it is therefore a type of computer. (c) All of the steps in claim 1 involve communicating messages, that is, information. And in relation to such steps, the claim itself is to a "computer program" that will configure a standard computer (a smartphone or a tablet) to send and receive those messages. (d) Claim 1 is in substance a claim to a 'kit'. The first part of the kit is a "communication system", with no specification at all as to what that system must comprise, other than that it must be capable of sending entry/exit signals and receiving entry/exit requests in some unspecified way. There can be no suggestion that that involves any technical contribution when the system is entirely unspecified as to its components. The second part of the kit is the "computer program". The computer program does not interact with the "communication system". There is no working interrelationship between those two components. As such, claim 1 is to a "mere collocation" of integers, which is not patentable subject matter - the claim must instead be to parts that "make up a new thing": Firebelt Pty Ltd v Brambles Australia Ltd [2002] HCA 21; 188 ALR 280 at [21] per Gleeson CJ, McHugh, Gummow, Hayne and Callinan JJ. As the High Court explained in Minnesota Mining at 266, the interaction between the integers of the claim is "the essential requirement". See also Smith & Nephew Pty Ltd v Wake Forest University Health Sciences [2009] FCAFC 142; 82 IPR 467 at [21], quoting Re Klaber's Patent (1906) 23 RPC 461 at 469. (e) Claim 1 also does not produce any artificially created state of affairs. First, the nature of the "communication system" is not specified, and the computer program is just a set of instructions. Secondly, the set of instructions comprising the computer program does not "grant access to the user", as the TMA parties submitted in opening submissions. A smartphone that has been configured by the computer program must be capable of sending and receiving the specified information, but this does not address any actual opening of any barrier. (f) Claim 4, dependent on claim 1, does not contribute an artificial effect - it only requires there to be a server that is configured to transfer additional data ("key data"). (g) Claim 11 is a claim to a computer program having certain features. A computer program is not patentable subject matter. It cannot be anything more than a set of instructions. It has no physical existence per se, and does not involve an artificially created state of affairs. (h) Claim 16 is a claim to a mobile communication device (or smartphone) that has been configured in a particular way. This is a claim to a type of computer that has certain software (an app) loaded onto it. That software does not result in any improvement to the smartphone. In substance, it is a claim to the set of instructions or scheme that is loaded on a generic smartphone by reason of the app stored on the phone. As a matter of substance, the claim is to the software that is configuring the phone. For this claim also, no entry to a carpark results. The claim is not to a method - it is to a physical phone that is capable of operating in a particular way. 203 In my view, the invention as claimed does involve a manner of manufacture. 204 It is necessary to start by characterising the invention. In substance, the claims are directed to a communications system, computer program and smartphone configured to determine signal strengths of entry signals and exit signals to control a user's entry into and exit from a restricted area, in conjunction with the use of authorisation data. 205 While at one level the claims comprise a series of instructions to be executed by a computer, the invention as claimed does have some "concrete, tangible, physical, or observable effect" (Aristocrat at [25]), namely the opening of the entry barrier and the exit barrier. While this is not explicitly stated in claims 1, 11 and 16, it flows from the references to generating and transferring an entry request and exit request, read in the context of the specification as a whole. Similarly, and for the same reasons, the invention as claimed constitutes an abstract idea that is "implemented on a computer to produce an artificial state of affairs and a useful result" (Aristocrat at [122]). The artificial state of affairs is the opening of the entry barrier and exit barrier. The useful result is that the user associated with a vehicle is granted entry into, and exit from, a restricted area. 206 Insofar as UbiPark submits that claim 1 is, in substance, a claim to a 'kit' comprising a communication system and a computer program, with no working interrelationship between those two components, I do not accept that submission. Claim 1 is, in substance, to a system comprising those components, with an interrelationship between them. This is expressed in integers 1.3.1, 1.3.4, 1.3.5, 1.3.6 and 1.3.9, all of which refer to the communication system in the context of the computer program/smartphone. Claims 11 and 16 contain comparable integers, which similarly express an interrelationship between the computer program/smartphone and the communication system. 207 The authorities on which UbiPark relies, in which it was held that particular computer-implemented schemes were not patentable subject matter, are distinguishable. Unlike this case, those cases were concerned with mere schemes or abstract ideas implemented on computers, which were not otherwise tied to the doing of any physical thing or the creation of any physical or tangible result. In the present case, a useful physical or tangible result is achieved, aside from the fact of the use of computers to implement the invention. 208 I therefore reject this ground of invalidity.

Inventive step issue 209 UbiPark contends that claims 1, 4, 11 and 16 lack an inventive step on the basis that: (a) the idea of using an app to gain access to a car park was known or trivial; alternatively, the idea of using an app for off-street parking was common general knowledge; and the solution in claims 1, 11 and 16 was obvious; (b) these contentions are fortified by Stankovski, which UbiPark contends is a 'plus one' document for the purposes of s 7(3) of the Patents Act; (c) these contentions are also fortified by the Blue Dot Brochure, which UbiPark contends is a 'plus one' document for the purposes of s 7(3) of the Patents Act. 210 Although UbiPark previously relied on United States Patent Publication No. 2009/0325539 (Malik) as a 'plus one' document, UbiPark indicated in closing oral submissions that it did not press Malik as a 'plus one' document (T377).

Applicable principles 211 The applicable principles can be summarised as follows. Section 7(2) of the Patents Act, in the form provided by the parties in the joint list of authorities (namely, as at 26 August 2021) relevantly provides: (2) For the purposes of this Act, an invention is to be taken to involve an inventive step when compared with the prior art base unless the invention would have been obvious to a person skilled in the relevant art in the light of the common general knowledge as it existed (whether in or out of the patent area) before the priority date of the relevant claim, whether that knowledge is considered separately or together with the information mentioned in subsection (3). (3) The information for the purposes of subsection (2) is: (a) any single piece of prior art information; or (b) a combination of any 2 or more pieces of prior art information that the skilled person mentioned in subsection (2) could, before the priority date of the relevant claim, be reasonably expected to have combined. 212 One approach for assessing whether a claimed invention is obvious is to consider whether the notional skilled person would directly be led as a matter of course to try a particular approach in the expectation that it may well produce a useful result: Aktiebolaget Hässle v Alphapharm Pty Ltd [2002] HCA 59; 212 CLR 411 at [53]. This test is referred to as the "modified Cripps question". The test can be useful, but is not always appropriate to apply in every case: Generic Health Pty Ltd v Bayer Pharma Aktiengesellschaft [2014] FCAFC 73; 222 FCR 336 at [71]. 213 In Lockwood Security Products Pty Ltd v Doric Products Pty Ltd (No 2) [2007] HCA 21; 235 CLR 173, the High Court considered the issue of lack of inventive step in relation to a door lock. The Court did not use the modified Cripps question, and said that the issue of obviousness involved a question of fact that was once a "jury question" (at [51]), saying further that there must be at least a "scintilla of invention" or "some difficulty overcome, some barrier crossed" or something "beyond the skill of the calling" (at [52]). See also Merck Sharp & Dohme Corp v Wyeth LLC (No 3) [2020] FCA 1477; 155 IPR 1 at [249]-[250].

Evidence 214 In the present case, Ms Piper's (unchallenged) affidavit evidence includes evidence to the following effect (noting, in particular, the references to "off-street parking", which are of particular relevance for present purposes; this is to be distinguished from "on-street parking", which does not involve the opening of a barrier or boom gate): (a) by March 2012, Roads and Maritime Services (RMS) in NSW had guidelines for "phone parking", where a motorist used their mobile phone to pay for parking, and the system recorded details of when they parked and how long they parked for; (b) in March 2014, Blue Dot Parking commenced a six-month trial of its phone parking app in the City of Canada Bay, a council in Sydney; the trial was successful, and the Blue Dot Parking app was introduced to additional sites within that council area during 2014; (c) during May 2014, Blue Dot Parking wrote to every council in Australia to promote the Blue Dot Parking app and its then existing functionality, which was for on-street parking; (d) by May 2014, five councils had sought tenders for the provision of an app-based parking product, and Blue Dot Parking had submitted tenders; (e) around June 2014, Blue Dot Parking applied for, and won, a grant from Innovate NSW to support its development of an off-street phone parking product; (f) in September 2014, Blue Dot Parking promoted its app parking product, which related to both on-street and off-street parking, at the Parking Australia Convention and Exhibition in Brisbane; (g) by December 2014, at least eight companies with app-based parking products had been approved by RMS; (h) in December 2014, Brisbane City Council released a tender for the supply of a phone-based software solution for on-street and off-street parking, which was to extend the capabilities of their existing on-street mobile parking system; (i) in late 2014, Ms Piper was involved in promoting Blue Dot Parking's off-street parking mobile phone product to other councils. 215 While Ms Piper's evidence, which I accept, establishes certain factual matters, it is not suggested that Ms Piper stands in the position of the skilled addressee, as described at [66] above. 216 Mr Elliott was asked to consider whether and, if so, how a smartphone application might be used to allow a person to access, and exit, a controlled car park, approaching the matter as at February 2015. The task is set out in Mr Elliott's first affidavit at [13]-[16]. His response to those instructions is set out at [17]-[89] of that affidavit (the Elliott Solution). He then discussed Stankovski, at [90]-[96]. This did not lead him to modify his solution. Mr Elliott dealt with the Blue Dot Brochure later in his first affidavit (at [161]-[163]). This part of the affidavit was written after Mr Elliott had been shown the 335 Patent. He did not suggest that this document would have led him to modify his solution. 217 In the joint report, the experts agreed that the Elliott Solution did not have all of the features of claims 1, 11 and 16 of the 335 Patent. The experts agreed that integers 1.3.5 and 1.3.9 (relating to "authorisation data") were not present in the Elliott Solution. In the joint report, in relation to this aspect, the experts expressed the following views, in summary: (a) In Mr Sizer's opinion the role of "authorisation data" as described in claim 1 in relation to entry and exit requests is a significant aspect of the invention, and is required to allow the invention to effectively address the problems described in the 335 Patent's specification [0003] to [0006]; and to allow the invention to be configured in a way that replaces paper tickets, as described in the specification in [0057] and [0062]. (b) Mr Elliott expressed the opinion that, while he did not suggest, in the Elliott Solution, that the smartphone should be provided with information that confirms that the user has been granted access to the carpark, this is a basic user-friendly design option for the app. 218 During the concurrent evidence session, Mr Elliott confirmed that he did not suggest, in the Elliott Solution, the features set out in [96] of the joint report (i.e. integers 1.3.5 and 1.3.9) and, in particular, a feature of providing information that is stored on the smartphone that confirms that the user has been granted access to the car park. He accepted that he referred to this as a basic, user-friendly design option only after he had seen the 335 Patent. Mr Elliott agreed with Mr Sizer's evidence that the role of authorisation data as described in claim 1 is a "significant" aspect of the invention. Mr Elliott gave evidence that he gave a considerable amount of thought to the solution that he put forward, and that it involved an iterative process over a period of time. 219 In relation to claim 4, in the joint report, the experts agreed that the Elliott Solution did not have all the features of that claim. The experts agreed that the use of key data was not disclosed in the Elliott Solution. The experts agreed that this feature was significant. In the concurrent evidence session, Mr Elliott confirmed that he agreed with Mr Sizer that the features that deal with key data as described in claim 4 are significant.

Consideration 220 The first issue I will address is whether, as submitted by the TMA parties, Mr Elliott's evidence proceeds from an invalid starting point. 221 UbiPark submits that: (a) before the priority date, the basic operation of a carpark was well known, including that it could have restricted entry and exit using barriers or boom gates, and could use a ticketing system; (b) it was also common general knowledge before February 2015 that mobile phone apps could be used for a wide variety of purposes, which included facilitating and paying for car parking sessions; that was, in particular, the common knowledge of those with a relevant interest in operating, or supplying technology for use in, carparks; and (c) a relevant goal that existed at that time was for a person to use an app on their phone to facilitate entry to and exit from a carpark, and how to do so with a minimum of user interaction. 222 In the alternative, UbiPark relies on the common general knowledge combined with one of the 'plus one' documents, namely Stankovski or the Blue Dot Brochure. 223 The TMA parties accept that, as at the priority date, the basic operation of a carpark was well-known, including that it could have restricted entry and exit using barriers or boom gates and could use a ticketing system. However, the TMA parties do not accept that the evidence establishes that: (a) it was common general knowledge before February 2015 that mobile phone apps could be used for facilitating and paying for car parking sessions in off-street car parks; or (b) a relevant goal that existed at the priority date was for a person to use an app on their phone to facilitate entry to and exit from a carpark, and how to do so with a minimum of user interaction. 224 The TMA parties submit that, unless it is established that the relevant problem forms part of the common general knowledge, or that knowledge of the problem is s 7(3) information, then such knowledge or information will not be attributed to the person skilled in the art for the purposes of assessing obviousness: AstraZeneca AB v Apotex Pty Ltd [2014] FCAFC 99; 226 FCR 324 at [201]-[203] (relating to an earlier form of the legislation). 225 There does not appear to be any issue that Stankovski and the Blue Dot Brochure are each prior art information for the purposes of s 7(3). I will proceed on that basis. 226 I am satisfied that it was, at least, part of the common general knowledge combined with either Stankovski or the Blue Dot Brochure, that an app could be used for off-street parking. Each of those documents discloses the use of an app for off-street parking. In these circumstances, I do not accept the submission that Mr Elliott's evidence proceeds from an invalid starting point. 227 The next issue I will address is whether the invention as claimed in claims 1, 4, 11 and 16 is obvious, in light of the common general knowledge alone, or the common general knowledge combined with Stankovski or the Blue Dot Brochure. The approach taken by UbiPark to establishing obviousness was to rely on the evidence of Mr Elliott in response to the task that he was instructed to address. However, the Elliott Solution does not have all the features of the relevant claims. In particular, it does not disclose the receipt, from the communication system, of "authorisation data indicative of the entity being granted access to enter the restricted area" (integer 1.3.5 and corresponding integers in claims 11 and 16). Nor does it disclose the generation and transfer of an "exit request indicative of the authorisation data" (integer 1.3.9 and corresponding integers in claims 11 and 16). As set out above, the experts agreed that these aspects of the invention as claimed were "significant". 228 Mr Elliott considered Stankovski in the section of his first affidavit immediately after that in which he set out his solution, but Mr Elliott did not suggest any modifications to his solution on the basis of that article. Mr Elliott did not refer to the Blue Dot Brochure in this section of his affidavit material; he only received the brochure after having reviewed the 335 Patent, and does not suggest that it would have caused him to modify his solution. 229 UbiPark submits that: the inclusion of some form of authorisation data was plainly encompassed by the Elliott Solution; there are two main options to address issues of authorisation - store relevant information on the smartphone or store relevant information on the servers; it was not material which of the two basic options was adopted; both are obvious. The difficulty with these submissions is that, as set out above, the experts agreed that the Elliott Solution did not include integers 1.3.5 and 1.3.9 and that those integers are significant. While the Elliott Solution did refer to functionality including "identifying whether the user is authorised to enter and/or exit the car park" (at [19(d)]), that is not the same as the features described in integers 1.3.5 and 1.3.9, which involve authorisation data indicating that the user has been granted access to enter the car park, and an exit request that is indicative of that authorisation data. This functions, in a sense, as a virtual parking ticket. 230 In light of the above, I am not satisfied that the invention as claimed is obvious. Accordingly, this ground of invalidity is not made out.

Utility issue 231 UbiPark contends that claims 1, 4, 11 and 16 lack utility on the basis that they include subject-matter that does not address any of the problems identified in the patent. 232 The applicable principles may be shortly stated as follows. If an invention "so far as claimed in any claim" is not useful, it is invalid and liable to be revoked: Patents Act, s 18(1)(c) and s 138(3)(b). If the claimed invention does what it is intended by the patentee to do and the end obtained is itself useful, the invention is useful within the meaning of s 18(1)(c): Ranbaxy Australia Pty Ltd v Warner-Lambert Co LLC [2008] FCAFC 82; 77 IPR 449 at [141] per Emmett, Weinberg and Bennett JJ; see also Rehm Pty Ltd v Websters Security Systems (International) Pty Ltd (1988) 81 ALR 79 at 96 per Gummow J. 233 While it is established that all that is within the scope of a claim must be useful, that proposition is tempered by the consideration that the specification and claims should not "be construed in a way that any sensible person would appreciate would lead to unworkability when by construction it could be given a more limited meaning": ESCO Corp v Ronneby Road Pty Ltd [2018] FCAFC 46; 131 IPR 1 at [235], citing Welch Perrin Co Pty Ltd v Worrel [1961] HCA 91; 106 CLR 588 at 602. 234 In the joint report, the experts agreed that claim 1 includes systems that have practical operation. They also agreed that systems that have no practical operation could be imagined within the scope of claim 1. It was also stated in the joint report at [118] that, in Mr Elliott's view, a system could be imagined where no checks were made to determine whether the entity (the user) was permitted to enter the restricted area; this would not amount to a practical system where the objective included "parking within a restricted area". 235 The following points emerged during the concurrent evidence session: (a) Mr Elliott accepted that he would not actually go out and make a system that had no practical operation. (b) In reference to the example given by Mr Elliott in the joint report (where no checks are made to determine whether the entity is permitted to enter the restricted area), it was put to Mr Elliott that the language of the claim indicates that a check of some kind must be conducted to confirm that the entity is authorised to enter the restricted area. Mr Elliott did not accept this. (c) Mr Sizer gave evidence that, implicit in the operation of the system is that there is something done to authorise entry, but the claim does not say how or where that is done; having regard to the fact that the claim refers to a system and an access control system, and reading the claim in conjunction with the specification, it becomes clear that there is an authorisation process, albeit the claim does not describe what the authorisation process is. Mr Elliott agreed with this. (d) In relation to [118] of the joint report, Mr Elliott said that, if a check of payment is made before exit, then the system has a practical operation. (e) Mr Sizer accepted that claim 1 does not necessarily require a check that a particular user is authorised to enter the car park. (f) Mr Sizer accepted that, for embodiments of claim 1 to be suitable for use in a public car park, it would be necessary to incorporate into claim 1 a mechanism by which the person parking ultimately pays for their parking. Mr Sizer accepted that, in the context of a car park in a residential or commercial building, there would need to be an additional requirement within claim 1 to check that the person who possesses the smartphone (and, by inference, that person) is an authorised person to park there. 236 UbiPark submits that: [0003] to [0006] of the 335 Patent set out a number of potential problems that the claimed invention is to address or alleviate (see [0007]); those problems include difficulties with collecting or losing a ticket in the context of a paid carpark, the need to queue to pay for parking, and the difficulty of having to locate or access a transmitter or card to open a barrier or door; the asserted claims are claimed in broad, general terms; notably, they do not include the following limitations: (a) any requirement for payment; (b) any requirement for any check as to identification/authorisation for entry into the carpark; or (c) on the TMA parties' construction, any requirement that the barrier be opened without the need for user input. 237 In my view, on the basis of the construction that I have given to integers 1.3.4/1.3.9 (see [135]-[140] above), the invention as claimed in claims 1, 4, 11 and 16 has utility. On that construction, the invention as claimed involves an entry request and an exit request being generated and transferred "in response to" the one or more entry or exit criteria being satisfied, that is, without user intervention. This addresses at least one of the problems identified at [0003]-[0006] of the specification, namely the difficulty of having to locate or access a transmitter or card to open a barrier or door. It follows from my acceptance of UbiPark's construction of integers 1.3.4/1.3.9 that I do not accept its submission that the invention as claimed lacks utility. 238 Accordingly, this ground of invalidity is not made out. 239 It follows that the Invalidity Claim is to be dismissed.

Conclusion 240 For these reasons, I have reached the conclusions summarised at [16] above. I certify that the preceding two hundred and forty (240) numbered paragraphs are a true copy of the Reasons for Judgment of the Honourable Justice Moshinsky.

SCHEDULE OF PARTIES VID 674 of 2021 Cross-Claimants Second Cross-Claimant: TMA TECHNOLOGY (AUSTRALIA) PTY LIMITED Third Cross-Claimant: ZIPBY PTY LTD Cross-Respondents Second Cross-Respondent: MOSSTYN HOWELL