Commonwealth Scientific and Industrial Research Organisation
[2024] APO 2
•23 January 2024
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Commonwealth Scientific and Industrial Research Organisation [2024] APO 2
Patent Application: 2021282508
Title:Object monitoring system
Patent Applicant: Commonwealth Scientific and Industrial Research Organisation
Delegate: Tim Gillett
Decision Date: 23 January 2024
Hearing Date: Written submissions filed on 29 September 2023
Catchwords: PATENTS – section 45 – examiner’s objection – novelty – inventive step – manner of manufacture – tag – object monitoring – bytecode – snippet – Bluetooth – not novel – not a manner of manufacture – application remitted for further examination
Representation: Patent attorney for the applicant: Davies Collison Cave Pty Ltd
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2021282508
Title:Object monitoring system
Patent Applicant: Commonwealth Scientific and Industrial Research Organisation
Date of Decision: 23 January 2024
DECISION
Claim 1 is not novel and does not involve an inventive step. Claim 1 is not directed to a manner of manufacture.
The Applicant is hereby provided with an opportunity to respond and attempt to gain acceptance. Under Regulation 13.4(1)(g) the final date for acceptance is extended to three (3) months from the date of this decision.
REASONS FOR DECISION
Background
Patent application 2021252508 (‘the present application’) was filed on 9 December 2021 in the name of Commonwealth Scientific and Industrial Research Organisation (‘the Applicant’). It is the third application in a string of related applications commencing from ‘grandparent’ 2019213347. ‘Grandparent’ 2019213347 is the national phase entry of PCT/AU2019/050142 and was granted on 2 January 2020.
Three examination reports have been issued for the present application. Each report objected that the claims are either not novel or not inventive. Additionally, reports two and three objected that the claims are not for a manner of manufacture. Other objections have been raised during examination but are no longer outstanding.
Amendments to the specification have been proposed on 28 March 2023 and 5 June 2023 (dated 2 June 2023). No objection has been taken to these amendments during examination and I cannot see any reason for which they would not be allowable. All further references to the specification will be to that as proposed to be amended on 5 June 2023.
The applicant requested to be heard on 10 July 2023 and was subsequently asked to provide submissions by 2 October 2023. Submissions were filed on 29 September 2023.
The examination of the present application is governed by the Patents Act 1990 (‘the Act’) as amended by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012 (‘the Raising the Bar Act’) as the application was filed after 15 April 2013. Thus, the standard of proof that applies in the present case is the balance of probabilities (subsection 49(1)). I must accept the application if satisfied on the balance of probabilities that the application complies with the Act. If I am not so satisfied, then I can refuse the application.
Description
The specification is titled ‘Object monitoring system’ and notes in paragraph [0001]:
The present invention relates to a system and method for monitoring objects, and in one particular example, to a system and method for monitoring objects based on an object context to ensure compliance with associated rules.
The invention is discussed in the context of occupational health and safety with rules about operation, handling, usage, or maintenance of objects being discussed. The specification notes that these rules can vary across the range of objects, locations, and governing organisations making it difficult for people, particularly visitors and casual workers to comply.
In relation to prior art systems, the specification notes the following in paragraph [0007]:
Current approaches to compliance monitoring typically involve education and training programs, used in conjunction with oversight, such as regular monitoring of worker activities by a supervisor. However, these approaches are not always successful.
Several prior art documents including US2017/046945 and US 9,824,571 are discussed. They disclose automated systems which identify non-compliance with a standard. The specification notes that these solutions are limited to specific scenarios only and/or are complex/expensive.
10. The object monitoring system of the specification is discussed at a high level with the object to be tracked (101), electronic tag (110), location beacon (160; labelled 360 in Figure 1), client device (120), and a repository (130) mentioned and shown in Figure 1 which I have included below.
11. The specification describes how entities interact with each other. For example, paragraph [0082] describes the following in relation to Figure 2 which I have included next to Figure 1 above:
In one example, at step 200, the client device 120 is used to upload object rules from the repository 130 to the tag 110. This is performed based on an object type of the respective object 101 with which the tag 110 is associated, so that the tag 110 is populated with object rules appropriate to the respective object 101. Thus, the rules uploaded to the tag 110 will be different for objects 101 that are to be treated differently, so that, for example, the rules uploaded to a tag associated with a hydrogen gas bottle, may differ to those uploaded to a tag associated with an oxygen gas bottle. It will be noted that the rules may also be specific to a particular context, so that for example, different rules may apply in different facilities, depending on differences in rules for the different facilities.
12. I understand that object rules are uploaded to each tag based on the object to which it is associated. Many example object rules are provided but a non-exhaustive list could relate to object location, temperature, elapsed time, and proximity to other object types.
13. The specification moves on to introduce ‘tag context’. For example, in paragraph [0084] with reference to Figure 2 (shown above):
In use, at step 210, the tag 110 determines context data at least partially indicative of a current tag context. The context data can be of a range of different forms and may be obtained from a number of different sources. For example, the context data could correspond to one or more sensed parameters, such as a temperature, humidity, pressure, or the like. In one example, however, the context data is at least partially based on messages received by the tag 110 from one or more external devices, and in particular location messages broadcast by the location beacons 110[sic], allowing the tag processing device to determine a tag location.
14. Trigger events are introduced which are essentially the intersection of the object rules and tag context, i.e. triggering an event based on the outcome of assessing tag context against the object rules. The specification emphasises that tags can perform this assessment independently. Paragraph [0093] sums this up neatly:
In another broad form, once object rules are stored on the tag 110, the tag 110 can monitor context data to determine a tag 110 context, utilising this information together with the object rules in order to identify trigger events. Once a trigger event has been identified, an action associated with that trigger event can be initiated.
15. An embodiment of the tag 310 is shown in Figure 6 which I have reproduced below.
16. The tag is described in general terms. Whilst it is not mentioned, item 600 seems to be an integrated circuit including processing device 601, memory 602, and transceiver 603. Item 606 is a power supply. Items 611-625 are various input/output devices. There is not a lot of detail about construction of the tag, however, the person skilled in the art would almost certainly be familiar with this type of device.
17. The specification moves on to a discussion of the rules engine with its operation generally characterised in Figure 7 which is reproduced below. This process takes a ‘rules document’ and transforms that to tag specific instructions which are uploaded to the relevant tag.
18. The specification notes that the system generates bytecode with the following mentioned in paragraph [0161]:
It will be appreciated that the rules engine can also be configured to generate object rule code, in the form of snippets of byte code, which can be executed by tag processing devices 601 allowing the tag processing device 601 to implement the object rule, and in particular assess whether a trigger event has occurred, and if so, what action is required.
19. A single example of the rules is given in paragraph [0159] as follows:
At step 725, the rules engine generates the rules by converting the logic expressions into a trigger event and an action. In this regard, assuming the logic expressions are specified in terms of an "If … then …" statement, the "If" clause can be used to define trigger events with the "then" clause being used to identify the actions. For example, this can lead to rules of the form:
IF DISTANCE(GasBottle-H2, GasBottle-O2) < 5m THEN ANNOUNCE(A Hydrogen gas bottle and an Oxygen gas bottle must not be stored within 5 metres of each other”)
20. No examples are provided for what a snippet of bytecode is nor how they are assembled to create code for a tag.
21. The specification discusses referencing tags with an identifier comprising categories and briefly notes how that minimises data use. This is discussed in paragraph [0104] as follows:
In one preferred example, the object identifier includes a first identifier indicative of an object category and a second identifier indicative of an object sub-category, which allows a wide range of object types to be defined using a minimal number of bytes. This in turn allows the object identifier to be broadcast as part of a message packet header, allowing object types to be identified from packet headers, without requiring a packet payload to be analysed. This reduces computational requirements, allowing tags and other hardware to only analyse the content of relevant data packets, and also enables the transfer of information to be achieved without requiring devices to undergo Bluetooth pairing.
22. The specification addresses power consumption of the tag in various ways. This is summed up in paragraph [0189] as follows:
Accordingly, the above described system enables low power cheap tags to be used to
perform real-time in situ compliance checking and actioning by utilising a low power localisation engine and augmenting this with a compliance rule set specific to an object. The tag is in essence self-aware in that it knows what object it is attached to and thus is able to use the subset of compliance rule(s) that correspond to the object. Additionally, the device advertises properties of the object it is attached to so that tags associated with other objects can assess their rules in relation to the object.
23. While the specification is largely directed to a monitoring system in an occupational health and safety environment, the following is stated in paragraph [0190]:
The system can be used broadly for regulation technology applications in that it can notify when a breach of compliance policy occurs such as an object, including people, being in a restricted area, or relative to another certain type of object, plus the many other variations based on policy documents. However, numerous applications of general condition checking exist, such as providing notifications when immunodeficiency patients in an hospital are in too close of proximity, livestock venturing into restricted areas (i.e. outside of the designated paddocks), location-based sensor/kill switch if they enter an area they are not allowed in, staff who do not have qualification for using specific equipment or access to specific rooms.
Claims
24. The application contains 18 claims with claims 1, 3 and 18 being independent. I have included a copy in Annex 1.
25. Claim 1 is directed to “An object monitoring system for monitoring objects”. The words following ‘for’ are essentially redundant in that they follow a direct limitation that the system monitors objects.
26. In terms of the word ‘object’, I consider that this has a plain meaning which should be used. Taken from the Macquarie Dictionary that is:
1. something that may be perceived by the senses, especially by sight or touch; a visible or tangible thing.
27. “the system including a tag associated with a respective object in use” defines that there are tags. I note that the claim uses the word ‘associated’ rather than ‘attached’. ‘Associated’ is not limited to physical proximity. For example, a key remains associated to the lock it opens despite being removed from it. I will not discuss this issue further because it has not been raised during examination, and as will be seen, does not significantly impact my decision.
28. The claim follows with a series of items that are ‘included’ and is thus non-exhaustive.
29. The first of these is the tag memory “a tag memory configured to store object rules, wherein the object rules are stored in the tag memory as a plurality of executable byte code snippets, each snippet corresponding to a respective object rule”. I note the phrase “executable byte code snippets”. There is no dictionary definition setup for these words, nor, as I understand it, could they be said to have a plain meaning. As such I will consider a technical meaning.
30. Wikipedia has a page devoted to ‘Bytecode’. Whilst Wikipedia is by no means an authoritative source, in this context it is useful. The introductory paragraph reads as follows:
Bytecode (also called portable code or p-code[citation needed]) is a form of instruction set designed for efficient execution by a software interpreter. Unlike human-readable source code, bytecodes are compact numeric codes, constants, and references (normally numeric addresses) that encode the result of compiler parsing and performing semantic analysis of things like type, scope, and nesting depths of program objects.[1]
[1] as of 3 November 2023
31. This is consistent with my understanding of the term as being code for an interpreted language. It is neither machine code nor source code but something in between.
32. Coming to ‘executable’, I have trouble with this term. On one hand it could be said that only machine code is executable. This clearly cannot be how the term would be read noting that bytecode is not machine code and thus executable bytecode would not exist. Coming again to Wikipedia, there is a page devoted to ‘Executable’:
In computing, executable code, an executable file, or an executable program, sometimes simply referred to as an executable or binary, causes a computer "to perform indicated tasks according to encoded instructions", as opposed to a data file that must be interpreted (parsed) by a program to be meaningful.
The exact interpretation depends upon the use. "Instructions" is traditionally taken to mean machine code instructions for a physical CPU. In some contexts, a file containing scripting instructions (such as bytecode) may also be considered executable.[2]
[2] as of 7 November 2023
33. This definition seems appropriate, the bytecode is executable as opposed to simply data. That is, the object rules are written as a program which can be run rather than a database entry storing values. This is consistent with the specification which at [0132] states:
…The logic expressions are then used to generate the object rules by converting the logic expressions into a trigger event and an action, before uploading these to the tag. For example, the logic expressions are often specified within a rules text in terms of "If… then…" statements…
34. Finally coming to ‘snippet’, Wikipedia again has a page ‘Snippet (programming)’ which provides the following:
Snippet is a programming term for a small region of re-usable source code, machine code, or text. Ordinarily, these are formally defined operative units to incorporate into larger programming modules. Snippet management is a feature of some text editors, program source code editors, IDEs, and related software. It allows the user to avoid repetitive typing in the course of routine edit operations.[3]
[3] as of 22 October 2023
35. With these interpretations, as a phrase ‘executable bytecode snippets’ should be understood to mean ‘a reusable portion of interpreted program code’.
36. The claim follows with a tag transceiver, tag processing device, defining the use of object rules, determining a trigger, and actioning the trigger which are clear enough in themselves and do not require discussion.
37. Finally, the claim defines that the tag is a first tag and that it determines the context of a second tag and subsequently the ‘mutual context’. Again, I do not think this requires a great deal of discussion, a tag with rules relating to the proximity, or other contextual information of other tags will need to be aware of other tags to determine if the object rules have been breached.
The examiner’s objection and applicant’s submissions: Novelty
38. There are two outstanding objections which were raised in the third examination report dated 3 July 2023. Objection 5 is that claims 1-18 do not define a manner of manufacture and objection 6 is that claims 1-18 are not novel and/or inventive. I will initially focus on the novelty objection.
39. Rather than repeat the objection and submissions, I think it is fair to say that contention is focussed on whether D1 teaches the use of “executable bytecode snippets” or not.
40. In relation to “executable bytecode snippets” the third report states:
It is considered that D1 discloses object rules stored in tag memory as a plurality of executable bytecode snippets, which are executed to identify a trigger event ([0821] - [0823]: universal logic as depicted in pseudocode is considered to comprise an object rule code snippet; [2679] - [2680]: object rules/expectations may be programmed using interpreted languages, including Perl and Java; [1791], [1794]: BIRD includes an interpreter that translates usage expectation code into machine language. This is considered to be an implementation of rules that are executed as byte code; [2901], [2906]: execution of expectations can trigger an action).
41. The applicant has responded with:
Specifically, in the previous Examination Report, the Examiner stated, it is considered that D1 discloses object rules stored in tag memory as a plurality of executable byte code snippets, which are executed to identify a trigger event.
In this regard, the Examiner refers to "universal logic as depicted in pseudocode is considered to comprise an object rule code snippet" and also that "object rules/expectations may be programmed using interpreted languages, including Perl and Java", and finally that "BIRD includes an interpreter that translates usage expectation code into machine language".
Thus, it appears from the above that the Examiner is equating usage expectations expressed as interpreted languages as being equivalent to the object rules.
However, interpreted languages, as admitted in D1, need an interpreter in order to be executable, and hence are not executable code. Thus, D1 does not explicitly or implicitly disclose "executable byte code snippets", such as machine language, being stored in a tag memory, and hence the claim is novel.
Furthermore, as the Examiner notes, D1 states "BIRD includes an interpreter that translates usage expectation code into machine language". The Interpreter (562) forms part of the BIRD OS shown in Figure 5I, and such an interpreter would not be required if the code snippets were executable.
Novelty legal principles
42. Section 18(1)(b)(i) of the Act states:
Patentable inventions for the purposes of a standard patent
(1)Subject to subsection (2), an invention is a patentable invention for the purposes of a standard patent if the invention, so far as claimed in any claim:
(a)is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies; and
(b)when compared with the prior art base as it existed before the priority date of that claim:
(i)is novel; and
(ii)involves an inventive step; and
(iii)is useful; and
(iv)was not secretly used in the patent area before the priority date of that claim by, or on behalf of, or with the authority of, the patentee or nominated person or the patentee's or nominated person's predecessor in title to the invention.
43. It is well established that the law for Novelty is the “reverse infringement test” being set out in Meyers Taylor Pty Ltd v Vicarr Industries Ltd (1977) CLR 288 at page 235; 13 ALR 605 at page 611, where Aickin J stated:
The basic test for anticipation or want of novelty is the same as that for infringement and generally one can properly ask oneself whether the alleged anticipation would, if the patent were valid, constitute an infringement.
Considerations
44. Looking at US2016/0110975 A1 (IMAGISTAR LLC) 21 April 2016 (“D1”). This document is plainly part of the prior art base as set out in the definitions and this has not been disputed. There also appears to be little dispute that D1 discloses much of claim 1. For clarity I will summarise the document and identify some of the apparently uncontentious features before moving on to disputed ones.
45. D1 is directed toward an intelligent object tracking system with the following background provided in paragraph [0005]:
More particularly, the present disclosure pertains to attaching local sensor(s) to a portable item, object, device, or container, or embedding local sensor(s) in a portable item, object, device, or container. The sensors(s) have suitable associated intelligent processing which is substantially collocated with the portable item, object, device, or container. The sensor(s) and intelligent processing are configured to determine a likelihood that the item, object, device, or container is lost, misplaced, misappropriated, wandering, or stolen, or otherwise in a context or use not appropriate for the item, object, device, or container.
46. I note that this broad category is subtly different to the preferred embodiment of the present invention which is directed toward occupational health and safety compliance. Notably the claimed invention is directed toward tracking ‘objects’ though so this difference is unimportant. As appears uncontentious D1 discloses:
o an object monitoring system ([0004])
o a tag (figure.2A item 200)
o tag memory (figure.2A item 206 and figure.4D)
o a tag transceiver (figure 2A item 240)
o a tag processing device (figure 2A item 204)
o context data in the form of sensor data (figure 2A item 210)
o object rules (figure 4B – referred to as “usage expectation”)
o a trigger event and action ([0212], referred to as an alert or notification)
o a second tag and mutual context ([2779], see discussion of teams)
47. I will move on to the disclosure of “a plurality of executable byte code snippets”. My earlier claim construction of these words is that they mean ‘a reusable portion of interpreted program code.’ Each aspect of that feature is disclosed in D1 as follows.
48. D1 discloses interpreted program code in [1854]:
The BIRD (200) operating system (550) may have a program loader, code loader, program or code translator or interpreter, intermediate code translator or interpretation, and/or memory management modules, all associated with the loading and management of system software which can be run by the BIRD (200). In an embodiment, the program-loading/program-management elements may enable the BIRD (200) to load third-party programs as well.
49. Further, supplemental usage expectations are exemplified to be in a conditional statement format in paragraph [2001]:
Not shown in FIG. 6C are conditional elements, which may be considered as implicit. Thus, the supplemental usage expectations (600.S) may be understood as expressing:
if [the condition indicated in the usage expectation] = true
then item_state is extant/normal;
else
item_state is anomalous.
50. I have noted that [1998-2000] disclose the use of data values in addition to logical statements and conditional statements. However, I do not consider that this results in non-program code. Merely program code which uses data values too.
51. Additionally, [1996] discloses:
FIG. 6C presents a list of exemplary supplemental usage expectations (600.S) which may be appropriate for various items (100). Some of the exemplary supplemental usage expectations (600.S) shown in FIG. 6A may duplicate or overlap the functionality of the default BIRD logic (500) and default framework for usage expectations (1000). Some of the exemplary supplemental usage expectations (600.S) may extend or override the default BIRD logic (500) and default framework for usage expectations (1000).
52. Noting the phrase “which may be appropriate for various items” it is clear that the disclosed exemplary supplemental usage expectations are reuseable portions as discussed above.
53. For these reasons I consider that D1 discloses reusable portions of interpreted program code and thus discloses a “tag memory configured to store object rules, wherein the object rules are stored in the tag memory as a plurality of executable byte code snippets, each snippet corresponding to a respective object rule;”
54. Noting that D1 discloses all features of claim 1 and would thus infringe present claim 1, it follows that claim 1 is not novel in light of D1.
55. Moving on to claim 3, without going into detail I note that the claim does not define the plurality of bytecode snippets which were the contentious aspect of claim 1. Further, claim 3 defines a repository of information which claim 1 does not. It would thus seem that claim 3 is not unified with claim 1, however, I do not intend to make any findings in this respect.
56. Similar comments can be made in relation to claim 18 which adds a location beacon instead of the repository.
57. Having determined that claim 1 is not novel and that claims 3 and 18 are directed to different material, I do not think it necessary to make any further determinations in relation to any other claims. At this point I will turn to the other objection.
The examiner’s objection and applicant’s submissions: Manner of Manufacture
58. Objection 5 is that claims 1-18 do not define a manner of manufacture. The examiner has noted that the substance of the invention lies in an administrative scheme for managing objects and stated the following:
As discussed in earlier reports, the specification is solely directed to addressing administrative problems relating to inefficiencies and the ineffectiveness of existing approaches to managing compliance with business rules.
These administrative problems are addressed through the combination of claimed features, which amounts to the use of known computing techniques and technology to automate an administrative scheme for managing objects. It is maintained that the substance of the invention lies in this administrative scheme. Any advantage resulting from the claimed invention is limited to improved administration, such as more efficient management of objects to improve compliance with a set of business rules.
59. In relation to this objection the applicant submitted:
It is submitted the subject matter of the claim is a manner of manufacture.
As discussed above, the feature of object rules stored in the tag memory as a plurality of executable byte code snippets, and their subsequent execution to identify a trigger event, is a technical solution to a technical problem.
Specifically, the use of executable code snippets is technical in nature and addresses the technical issue of power supply, processing and memory limitations in portable devices, and for this reason alone should be deemed patentable.
60. There are further submissions in relation to previous objections and a discussion of how the considerations summarised in Aristocrat Technologies Australia Pty Limited [2016] APO 49 (‘Aristocrat ‘16’) at [35] apply which I have considered.
Manner of manufacture legal principles
61. Section 18(1)(a) of the Patents Act 1990 states:
(1) Subject to subsection (2), an invention is a patentable invention for the purposes of a standard patent if the invention, so far as claimed in any claim:
(a)is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies;
62. The broad principles to consider regarding manner of manufacture have been set out in National Research Development Corporation v Commissioner of Patents [1959] HCA 67 (‘NRDC’). At [14]:
The right question is: “Is this a proper subject of letters patent according to the principles which have been developed for the application of s. 6 of the Statute of Monopolies?”
63. Further guidance was provided in D'Arcy v Myriad Genetics Inc [2015] HCA 35 (‘Myriad’) to look for the substance of the invention. This is reflected in [87] & [88] by the majority and repeated by the minority at [144] quite succinctly:
Whatever words have been used, the matter must be looked at as one of substance and effect must be given to the true nature of the claim.
64. Aristocrat ‘16 summarised considerations appearing in Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150 (‘Research Affiliates’), and Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177 (‘RPL’) at [35] as follows:
I conclude that it is relevant to consider a range of matters. Without seeking to be exhaustive, these include:
othere must be more than an abstract idea, mere scheme or mere intellectual information;
ois the contribution of the claimed invention technical in nature;
odoes the invention solve a technical problem within the computer or outside the computer;
odoes the invention result in improvement in the functioning of the computer, irrespective of the data being processed;
odoes the application of the method produce a practical and useful result;
ocan it be broadly described as an improvement in computer technology;
odoes the method merely require generic computer implementation;
ois the computer merely an intermediary or tool for performing the method while adding nothing of substance to the idea;
ois there ingenuity in the way in which the computer is utilised;
odoes the invention involve steps that are foreign to the normal use of computers; and
odoes the invention lie in the generation, presentation or arrangement of intellectual information.
65. These seem to summarise a well-tested approach to assess patentability for computer implemented inventions. I note that later Full Court decisions including Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2019] FCAFC 161 (‘Encompass’), and Repipe Pty Ltd v Commissioner of Patents [2021] FCAFC 223 (‘Repipe’) have not diverted from this approach in any meaningful way.
66. In relation to Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29 (17 August 2022) (‘Aristocrat ‘22’), since there was no majority decision the outcome was determined according to s22(a) of the Judiciary Act 1903 (Cth) with the principles established by the Full Court left undisturbed.
Considerations
67. It is clear to me that there are administrative aspects to the invention defined in claim 1. Without going into detail, the invention takes a set of rules and applies them to a business operation using devices that are plainly well known to the person skilled in the art.
68. The applicant’s rebuttal suggests that there are technical aspects to the invention and identifies the executable code snippets which provide reduced memory storage and processing requirements. I accept that these are technical, as is the tag itself. However, as noted in Myriad, this is of no effect unless those features are the substance of the invention.
69. Looking closely at this issue, the applicant has asserted that “The storing of object rules in this manner reduces memory storage and processing requirements, and hence is technical in nature.” However, it is plain to me that this is not always true. Firstly, computer code length has almost no bearing on execution time. This is easily demonstrated by considering sorting algorithms with many very short programs being highly inefficient. Further, whilst the length of the code could conceivably be important and technical, as presently drafted there is no sense that the snippet is notably small in any important way. Regardless, the claim is not defined by any specific length of code and as such this is not a technical contribution of the claimed invention.
70. Based on the specification I consider that there is more to this issue beyond what has been claimed. In relation to the length, paragraph [0104] suggests communications can be made in a Bluetooth Low Energy header and as such avoid the need to pair devices. I will note here that although the specification has not addressed it, my understanding is that a significant size limitation exists in this regard, up to 29 Bytes of data if I have understood correctly. That is, not just small, but very small.
71. I have included a portion of the microchipdeveloper reference below which explains the Advertising Channel Protocol Data Unit and thus the maximum data size in an unpaired system. [4]
[4] as at 5 January 2024
72. The arrangement around pairing strikes me as potentially technical because of the way Bluetooth operates in the described system. For example, Bluetooth being a master-slave connection, where 3 tags need to communicate there should be two pairs registered in each tag; 6 in total. With 4 devices this becomes 12. At scale, thousands of pairs could be required to operate the system. Removing the need to pair overcomes this issue whilst presenting another, a significant limitation on data transfer. From my understanding it is not generic in art to operate a Bluetooth system such as this one without pairing devices.
73. I will mention that it seems plain that tag-tag interactions are intended to be completed without pairing. It is not so clear whether tags are programmed without pairing and thus whether the length of the bytecode snippets has any bearing on this issue or not.
74. To briefly touch on some of the matters in Aristocrat ’16, as it stands, claim 1 does not appear to solve a technical problem and it operates on well-known computer hardware. There might be more than an abstract idea and some level of ingenuity in determining how to operate a tracking system over Bluetooth without pairing. However, the claim is not yet limited to this arrangement. The claim does relate to an administrative scheme, but just as I have said that the technical issues in claim 1 are not the substance of the invention, I am cautious that neither is the scheme. I note that schemes for tracking items with tags appear to be very well known.
75. At the level of the claim as it stands, it appears that the substance of the invention, if there is one is a non-technical scheme to track objects. However, I consider that this issue could be resolved via amendment if appropriate technical material from the specification is introduced.
76. I also note that the specification has addressed power consumption briefly. This too could conceivably be technical content. However, I am not convinced that the specification has identified any real solution to that issue, particularly noting my earlier comments about efficiency. That is, whilst efficient code will lead to reduced power consumption, there is no teaching of how to produce efficient code.
77. There is also some discussion of listening and transmitting intervals such that the tags can be optimised to save power. Again, there is little detail about this issue, and it is likely that existing tags perform this type of function already.
Conclusion
78. The invention defined in claim 1 is not novel in the light of US2016/0110975 A1 (IMAGISTAR LLC) 21 April 2016.
79. As currently drafted claim 1 is not for a manner of manufacture.
80. Some questions remain about the nature of the invention as described and as such what the substance of the invention could become. Some areas which could be explored further include:
· How does using Bluetooth low Energy impact the system?
· Are there limitations imposed by operating the system without pairing?
· Are the tags ever paired?
· Is non-paired operation of a Bluetooth system generic in the art?
81. I believe the most useful course is to permit the applicant an opportunity to amend the claims and remit the application for further examination. As per Regulation 13.4(1)(g) the final date for acceptance will be 3 months from the date of this decision. To avoid any doubt, I do not see a reason to invoke 13.4(3) and as such I have not.
Tim Gillett
Delegate of the Commissioner of Patents
THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:
An object monitoring system for monitoring objects, the system including a tag associated with a respective object in use, wherein the tag includes:
a) a tag memory configured to store object rules, wherein the object rules are stored in the tag memory as a plurality of executable byte code snippets, each snippet corresponding to a respective object rule;
b) a tag transceiver configured to transmit or receive messages;
c) a tag processing device configured to:
i)determine context data at least partially indicative of a tag context by at least one of:
(1) a received message, including at least one of:
(a)a broadcast message from another tag;
(b)a client device message from a client device;
(2) sensor data from at least one sensor;
(3) user input commands; and
(4) using stored context data;
ii)use the object rules and the context data to identify a trigger event, at least in part by executing the byte code snippets;
iii)determine an action associated with the trigger event; and,
iv) cause the action to be performed; and, wherein the tag is a first tag that:
determines a second tag context using a broadcast message transmitted by a second tag associated with a second object;
determines a mutual context using the second tag context and the tag context; and, identifies the trigger event if the mutual context breaches mutual context restrictions.
A system according to claim 1, wherein the system includes:
a) a repository storing object rules for a plurality of object types; and,
b) a client device that communicates with the tag and the repository, and wherein in use object rules are uploaded from the repository to the tag using the client device based on an object type of the respective object.
An object monitoring system including:
a) a repository storing object rules for a plurality of object types;
b) a tag associated with a respective object in use, the tag including:
i)a tag memory configured to store object rules;
ii)a tag transceiver configured to transmit or receive messages; and,
iii)a tag processing device; and,
c) a client device that communicates with the tag and the repository, and wherein in use:
i)object rules are uploaded from the repository to the tag using the client device based on an object type of the respective object; and,
ii)the tag processing device is configured to:
(1) determine context data at least partially indicative of a current tag context;
(2) use the object rules and the context data to identify a trigger event;
(3) determine an action associated with the trigger event; and,
(4) cause the action to be performed.
A system according to claim 3, wherein the system includes a plurality of location beacons, each location beacon being configured to generate a location broadcast message indicative of a beacon location and wherein the tag processing device is configured to determine context data in accordance with at least one location broadcast message received via the tag transceiver from at least one of the plurality of location beacons.
A system according to any one of the claims 2 to 4, wherein the object rules are uploaded to the tag via one or more of the plurality of location beacons.
A system according to any one of the claims 2 to 5, wherein the client device includes at least one of:
a) one or more computer systems;
b) one or more smart phones;
c) one or more tablets; and,
d) one or more mobile computing devices.
A system according to any one of the claims 1 to 6, wherein the tag memory is configured to store stored context data.
A system according to any one of the claims 1 to 7, wherein the object rules are stored in the tag memory as code, and wherein the tag processing device is configured to execute the code to identify if a trigger event has occurred.
A system according to any one of the claims 1 to 8, wherein the tag includes an object identifier indicative of at least an object type of the associated objected.
10)A system according to any one of the claims 1 to 9, wherein the tag periodically transmits a broadcast message indicative of at least one of:
a) an object type identifier;
b) a tag location;
c) measured parameters; and,
d) context data.
11)A system according to any one of the claims 1 to 10, wherein the tag:
a) compares the tag location to location restrictions defined in the object rules for the respective object; and,
b) identifies a trigger event if the tag location breaches the location restrictions.
12)A system according to any one of the claims 1 to 11, wherein a first tag:
a) determines a proximity of a second object using a broadcast message transmitted by a second tag associated with the second object;
b) compares the proximity to proximity restrictions for the first and second objects defined in the object rules for the first object; and,
c) identifies a trigger event if the proximity breaches the proximity restrictions.
13)A system according to any one of the claims 1 to 12, wherein a client device:
a) determines a selected object type in accordance with user input commands; and,
b) generates a notification indicative of the tag location when a tag broadcast message having an object identifier of the selected object type is received.
14)A system according to any one of the claims 1 to 13, wherein the tag:
a) uses sensor data from at least one sensor to determine a measured parameter value; and,
b) identifies a trigger event if the measured parameter value breaches parameter value restrictions.
15)A system according to any one of the claims 1 to 14, wherein the action includes at least one of:
a) using a tag output device to at least one of:
i)at least partially control equipment;
ii)at least partially control the object; and,
iii)generate a notification; and,
b) transferring an action message to a client device, the client device being responsive to the action message to at least one of:
i)generate a notification;
ii)perform an action;
iii)forward the action message to a defined destination; and,
iv)cause an event log to be updated.
16)A system according to any one of the claims 1 to 15, wherein the tag includes an output device including at least one of:
a) an audio output;
b) a light source; and,
c) a signal generator.
17)A system according to any one of the claims 1 to 16, wherein the tag:
a) repeatedly transmits broadcast messages separated by a transmission interval; and,
b) repeatedly listens for a message over a listening interval greater than the transmission interval.
18)A method for use in an object monitoring system, the object monitoring system including a tag associated with a respective object in use, wherein the tag includes:
a) a tag memory configured to store object rules;
b) a tag transceiver configured to transmit or receive messages; and,
c) a tag processing device, the method including, in the tag processing device:
i)determining context data at least partially indicative of a tag context by at least one of:
(1) determining a tag location in accordance with at least one location broadcast message received via the tag transceiver from at least one of a plurality of location beacons; and,
(2) using stored context data;
ii)using the object rules and the context data to identify a trigger event;
iii)determining an action associated with the trigger event; and,
iv) causing the action to be performed; and, wherein the tag is a first tag that:
determines a second tag context using a broadcast message transmitted by a second tag associated with a second object;
determines a mutual context using the second tag context and a first tag context; and, identifies a trigger event if the mutual context breaches the mutual context restrictions.
0
7
0