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.