AU2021102110A4

AU2021102110A4 - Horse Management Method and System

Info

Publication number: AU2021102110A4
Application number: AU2021102110A
Authority: AU
Inventors: Wade Kristopher BENNETT; Clive Richard Smith
Original assignee: Specta Tech Pty Ltd
Current assignee: Specta Technologies Pty Ltd
Priority date: 2020-07-29
Filing date: 2021-04-21
Publication date: 2021-06-03
Anticipated expiration: 2029-04-21
Also published as: WO2022020876A1

Abstract

A process for electronic horse management executed by at least one processor of a computing system, the process including the steps of: (a) receiving, by a horse management server of the system, a horse management request including: (i) horse identification data representing the identity of a horse managed by the system; (ii) user identification data representing the identity of a user of the system; and (iii) operation request data representing a horse management operation requested by the user with respect to the horse, the requested horse management operation being from the group including: (A) recording a new activity for the horse; (B) updating an existing activity recorded for the horse; and (C) obtaining an activity history representing one or more activities recorded for the horse; (b) verifying, by the horse management server, the horse management request to determine whether the requested horse management operation is performable; and (c) if the requested horse management operation is performable, performing, by the horse management server, the requested horse management operation by: (i) when the requested operation is (A) or (B): generating activity data in a database of the system to reflect the recording of the new activity for the horse, or to reflect the update to the existing activity of the horse; and (ii) when the requested operation is (C): generating activity history data from corresponding activity data stored in the database; and transmitting the generated activity history data to a user device of the user, wherein, the determination of whether the requested horse management operation is performable is based on at least one of: (a) an association of the horse with the user; (b) a user type ofthe user; and - 63 (c) when the user type is a service provider type, a corresponding service type of services provided by the user. 1/22 100 User Device 102 Horse Hr 107 Management Application o:2 C Apn ID Device 105 Data 0e ~BLE Communications Network 140 Location Detection Devices 160 Horse Management Server 110 Dataase12_ Communications _ Module 116 Horse Owner 124 127 -- _ Request Handler 114 Activity Property 126 21 _Loction Tracker Service -t 119 AuhriyProvider Entity C T :)128_ Entity System Systems Interface 118 150 1 " Service Provider Systems 130 Horse Authority Veterinarian Transport Racing Training Earner System 139 132 134 136 137 138 Fiaure 1

Description

(c) when the user type is a service provider type, a corresponding service type of services provided by the user.

1/22 100

User Device 102

Horse Hr 107 Management Application o:2 C Apn ID Device 105

Data 0e

Communications Network 140 Location Detection ~BLE Devices 160 Horse Management Server 110

Dataase12_ Communications _

Module 116 Horse Owner 124 127 -- _ Request Handler 114 Activity Property 126 21 _Loction Tracker Service -t 119 AuhriyProvider Entity C T:)128_ Entity System Systems Interface 118 150

1 " Service Provider Systems 130 Horse Authority Veterinarian Transport Racing Training Earner System 139 132 134 136 137 138

Fiaure 1

HORSEMANAGEMENTSYSTEMANDPROCESS TECHNICAL FIELD

The present invention relates to a horse management system for identifying and managing services provided for, and interactions involving, horses.

BACKGROUND

Horse management is concerned with facilitating and documenting the life of one or more equine animals (i.e., horses) with the goal of promoting their improved welfare and handling. A basic requirement of horse management is the capturing of information relevant to particular activities associated with a horse over its lifetime. The activities of interest typically include the interactions of the horse with third party entities. For example, a particular horse may engage with:

(a) medical service providers, such as Veterinarians (Vets), Dentists, Chiropractors and Surgeons, to receive medical treatments; and (b) other service providers including Farms, Farriers, Transport Companies, Sales Companies, Breakers, and Trainers.

Conventionally, horse management information is captured in a set of records that are independently held by the relevant service providers and the owners. For example, records of a medical treatment for a horse would be held by the owner and the veterinary service provider. As such, an assessment of the welfare of the horse would involve the owner presenting his or her copies of the relevant documentation to the interested parties. With respect to a thoroughbred racehorse, an individual may request that a governing body provide a history of interactions that occurred over the complete life of the horse. To comply with the request, the governing body would need to contact the owner to obtain the appropriate documentation.

The above described approach includes difficulties with:

1. Capturing & Storing Information; 2 The Format of Information; 3. Accessing Information; 4. Data Integrity;

5. Tracking.

These difficulties are described in further detail below.

1. Capturing & Storing Information

There is significant difficulty associated with capturing and maintaining all of the activity information required to manage a particular horse. As discussed above, individual entities assume the responsibility of collecting and maintaining records representing their own interactions with the horse. For example, a medical service provider maintains his or her own records of the horse's medical data. Often, these records are physical documents which are cumbersome to manage and may deteriorate over time or simply get misplaced. Steps have been taken to improve this process by:

a. electronic document conversion process by the owner; and/or b. the service providers generating electronic records that are sent to the owner for safe keeping by e-mail, for example.

However, it is still incumbent on the owner to store the documents in a secure place for later access. Further, difficulties can arise because the data storage device is lost, stolen or breaks down. Further, still, it is incumbent on the owner, to organise the information in a manner that facilitates easy access to all of the documentation about a particular horse. This ad hoc approach to data management is generally time consuming and may lead to documents being lost.

2. The Format of the Information

There has previously not been a no standardised or uniform data format for records associated with horse service providers. This creates difficulties with capturing information associated with a particular horse from different service providers. For example, the data collected and managed by existing systems in relation to medical treatments or procedures may differ in both form and contents depending on which vet provided the treatment. As a result, it is difficult to effectively manage individual horses when using only a conventional means for the electronic sharing of relevant data between particular owners and service provider entities (e.g., email).

3. Accessing Information

Conventional horse management methods generally lack accessibility and transparency with respect to the activity data maintained for particular managed horses. Specifically, in these approaches the ability to determine the welfare of a horse, via an assessment of its lifecycle activities, is reliant on the exchange of information between the owner and other parties. This approach may result in significant inconvenience to owners, and other parties with an interest in the horse, due to the cumbersome nature of maintaining and exchanging physical documents. For example, where a vet waiting for an existing medical history of the animal before being able to carry out a procedure.

4. Data Integrity

In the context of an electronic horse management system, the need for accessibility and transparency must be balanced against a desire to maintain the integrity of the electronic activity data managed by the system. Specifically, conventional management approaches utilising electronic records lack a means to control which users may generate, modify and transmit data representing activities performed on a horse based on the characteristics of the user.

Furthermore, the decentralised nature of the conventional management approaches where each service provider maintains their own horse activity data, and the lack of a means for ensuring the integrity of the data maintained, may undermine the confidence of any welfare determination produced for the horse. This problem is compounded in situations where the owner, or another interested party, does not have physical access to the horse (e.g., when the horse is stabled at a remotely located property) since they are unable validate the activities that have been alleged to be performed by the service provider, or other party, who generates the corresponding record data.

5. Traceability

Racing Australia Limited (Racing Australia), for example, provides an RFID microchip with a unique identification number for thoroughbred race horses. Each RFID microchip is inserted subcutaneously by a vet who then sends at least the following information back to Racing Australia for entry into their management system:

a. the name of the horse; b. the name of the owner; c. the details of the microchip; d. a sample of the horse's hair; and e. the horse's parentage.

The horse can then be uniquely identified by scanning the RFID microchip and accessing Racing Australia's management system.

Horses are frequently moved over the course of their life. For example, they are moved from:

a. farms to sale yards; b. sale yards to owner's farms; c. owner's farms to trainer's stables; and d. trainer's stables to racing tracks.

Current management systems do not provide accurate, up to date, location information about individual horses. It is desirable to track the location of individual horses for a number of reasons, including for disease control.

The above described technical problems are not isolated to the technology underpinning existing horse tracking system. Rather, analogous issues arise in systems that track other items of commercial importance such as feed bins, diesel tanks and LPG tanks to name but a few.

It is desired to provide a system and process for horse management that alleviates one or more difficulties of the prior art, or to at least provide a useful alternative.

SUMMARY

The Present invention provides a process for electronic horse management executed by at least one processor of a computing system, the process including the steps of: (a) receiving, by a horse management server of the system, a horse management request including: (i) horse identification data representing the identity of a horse managed by the system; (ii) user identification data representing the identity of a user of the system; and

(iii) operation request data representing a horse management operation requested by the user with respect to the horse, the requested horse management operation being from the group including: (A) recording a new activity for the horse; (B) updating an existing activity recorded for the horse; and (C) obtaining an activity history representing one or more activities recorded for the horse; (b) verifying, by the horse management server, the horse management request to determine whether the requested horse management operation is performable; and (c) if the requested horse management operation is performable, performing, by the horse management server, the requested horse management operation by: (i) when the requested operation is (A) or (B): generating activity data in a database of the system to reflect the recording of the new activity for the horse, or to reflect the update to the existing activity of the horse; and (ii) when the requested operation is (C): generating activity history data from corresponding activity data stored in the database; and transmitting the generated activity history data to a user device of the user, wherein, the determination of whether the requested horse management operation is performable is based on at least one of: (a) an association of the horse with the user; (b) a user type ofthe user; and (c) when the user type is a service provider type, a corresponding service type of services provided by the user.

Preferably the horse management server is configured to generate location data representing a geographical location of the horse at corresponding time instant. The horse management process includes the step of validating one or more activities of the performed horse management operation based on the location data.

The present invention also provides a horse management system, including: (a) at least one database storing: (i) user data representing one or more users of the system, at least some of the users being:

(A) an owner of one or more horses managed by the system; or (B) a service provider that provides services of a service type for the one or more horses; (ii) horse data representing the one or more horses, each horse having: (A) at least one associated owner user; and (B) horse identification data representing the identity of the horse; and (iii) activity data representing one or more activities each performed by an owner user or a service provider user with a corresponding one of the one or more horses; and (b) a horse management server coupled to the database, including: (i) a communications interface to receive data; (ii) at least one computer processor to execute program instructions; and (iii) a memory, coupled to the at least one computer processor, to store program instructions for execution by the at least one computer processor to automatically execute the horse management process of any one of claims 1 to 17.

Preferably, the horse data representing the one or more horses additionally includes, for each horse, location data representing current and historical locations of the horse.

The present invention also provides one or more computer-readable storage media having stored thereon instructions that, when executed by at least one processor of a computing system or device, cause the at least one processor to execute the above described process.

The present invention also provides a process for electronic horse management executed by at least one processor of a computing system, the process including the steps of: (a) receiving, by a horse management server of the system, a horse management request including: (i) horse identification data representing the identity of a horse managed by the system; and (ii) operation request data representing a horse management operation requested by the user with respect to the horse, the requested horse management operation is recording a location of the horse; (b) performing, by the horse management server, the requested horse management operation by generating location data representing a geographical location of the horse at corresponding time instant; and (c) recording the location data associated with the horse identification data in a database in communication with the at least one processor.

Preferably, the location data is generated based on location tracking data received from one or more location detection devices. The location detection devices include a mobile device operable by the user to: (a) scan an ID device of the horse to obtain the horse identification data; and (b) transmit, to the horse management server, location tracking data including device co-ordinate data indicating a geo-spatial position of the mobile device, and the horse identification data.

The mobile device is preferably the user device.

The present invention also provides a process for electronic goods management executed by at least one processor of a computing system, the process including the steps of: (a) receiving, by a goods management server of the system, a goods management request including: (i) good identification data representing the identity of a good managed by the system; (ii) user identification data representing the identity of a user of the system; and (iii) operation request data representing a goods management operation requested by the user with respect to the good, the requested goods management operation being from the group including: (A) recording a new activity for the good; (B) updating an existing activity recorded for the good; and (C) obtaining an activity history representing one or more activities recorded for the good; (b) verifying, by the goods management server, the goods management request to determine whether the requested goods management operation is performable; and (c) if the requested goods management operation is performable, performing, by the goods management server, the requested goods management operation by: (i) when the requested operation is (A) or (B): generating activity data in a database of the system to reflect the recording of the new activity for the good, or to reflect the update to the existing activity of the good; and (ii) when the requested operation is (C): generating activity history data from corresponding activity data stored in the database; and transmitting the generated activity history data to a user device of the user, wherein, the determination of whether the requested goods management operation is performable is based on at least one of: (a) an association of the good with the user; (b) a user type ofthe user; and (c) when the user type is a service provider type, a corresponding service type of services provided by the user.

Preferably, the goods management server is configured to generate location data representing a geographical location of the good at corresponding time instant.

The present invention also provides a goods management system, including: (a) at least one database storing: (i) user data representing one or more users of the system, at least some of the users being: (A) an owner of one or more goods managed by the system; or (B) a service provider that provides services of a service type for the one or more goods; (ii) goods data representing the one or more goods, each horse having: (A) at least one associated owner user; and (B) good identification data representing the identity of the good; and (iii) activity data representing one or more activities each performed by an owner user or a service provider user with a corresponding one of the one or more goods; and (b) a goods management server coupled to the database, including: (i) a communications interface to receive data; (ii) at least one computer processor to execute program instructions; and (iii) a memory, coupled to the at least one computer processor, to store program instructions for execution by the at least one computer processor to automatically execute the above described goods management process.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein:

Figure 1 is a block diagram of a horse management system; Figure 2 is a block diagram of a computing device of the horse management system; Figure 3 is a flow diagram of a process for managing a horse; Figure 4 is a flow diagram of a configuration step of the horse management process of Figure 3; Figure 5 is a flow diagram of a process for generating a horse management request by a user device of the horse management system; Figure 6 is a flow diagram of a operation verification step of the horse management process of Figure 3; Figure 7a is a flow diagram of a first process for performing a requested horse management operation of the management process of Figure 3; Figure 7b is a flow diagram of a second process for performing a requested horse management operation of the management process of Figure 3; Figure 8 is a flow diagram of a process for verifying activities of a requested horse management operation; Figure 9 is a flow diagram of a sub-process for generating an estimated horse location during verification of the activities of a requested horse management operation, as performed in accordance with the process of Figure 8; Figure 10 is table showing the properties of one or more location logging approaches of some embodiments of the present invention; Figure 11 is a screenshot of a horse listing user interface window of a horse management client application; Figure 12 is a screenshot of a service provider selection user interface window of a horse management client application; Figure 13 is a screenshot of a first activity selection user interface window of a horse management client application; Figure 14 is a screenshot of a second activity selection user interface window of a horse management client application; Figure 15 is a screenshot of a first new activity user interface window of the horse management client application; Figure 16 is a screenshot of a second new activity user interface window of the horse management client application; Figure 17 is a screenshot of a location history display user interface window of a horse management client application; Figure 18 is a screenshot of a graphical location tracking user interface window of a horse management client application; Figure 19 is a screenshot of a graphical location tracking user interface window of a horse management client application; Figure 20 is a screenshot of a graphical location tracking user interface window of a horse management client application; and Figure 21 is a flow diagram showing the relationship between different system entities.

DETAILED DESCRIPTION

Overview

The digital horse management system 100, as depicted in Figure 1, electronically catalogues the interactions occurring between a managed horse and one or more of the following entities:

(a) service providers (such as vets, farms, farriers, etc.); (b) the owner; (c) the trainer; and (d) racing authorities.

The system 100 has broader application than horses. For example, the system 100 electronically catalogues the interactions occurring between any goods and one or more of the following entities:

(a) service providers (such as feed bin suppliers, transport companies); (b) the owner; and (c) location owners.

However, for simplicity, the system is below described, by way of non-limiting example, with reference to horses.

The interactions between a managed horse 107, as depicted in Figure 1, and an entity are recorded in the context of corresponding "activities" for the horse. The nature of the activity depends on the entity type:

(a) a service performed on the horse 107 (i.e., for a service provider); or (b) general events involving the horse 107 (e.g., an owner or other party visiting the horse at its stabled residence).

The horse management system 100 includes a horse management server 110 that communicates with at least one user device operated by at least one of the following users 101:

(a) an owner of one or more managed horses; (b) a service provider providing services of a particular type to one or more of the managed horses; or (c) an authority (e.g., a racing authority) of an organisation to which one or more of the managed horses may belong to (e.g. Studbook Australia).

Other users may operate the system 100 including an Administrator User who may have access to particular administrative functions of the horse management system 100, as described herein below.

In the horse management system 100, a horse management application 103 executes on a user device 102 to provide functionality to the user 101 via an interactive user interface 104, where, when displayed on the device, the user interface elements allow the user to request a horse management operation. Users 101 operate the horse management application 103 via a horse management account which is obtained by registering with the system 100.

The horse management application 103 requires the user 101 to log into the system 100 with their account username and a corresponding password. Users 101 are classified according to a user type. On registration each user is assigned a user type indicating whether the user is:

(a) a horse owner ("owner user"); or (b) a service provider (service provider user").

Each horse managed by the system 100 is associated with at least one owner user, and can be associated with one or more service provider users, properties, authorities, or other users.

The horse management application 103 dynamically verifies a requested management operation of a user based on the permissions of the user to perform activities with respect to the corresponding horse 107. Specifically, the horse management application 103 provides each user 101 with a unified set of horse management operations that may be conducted for each managed horse via an interactive user interface (UI). The set of management operations made available to the user 101 are determined by the client application 103 following, authentication of the user, based on the user type.

The server component 110 of the system 100 is configured to dynamically determine a set of horse management operations that are performable by the user 101, and to tailor the functionality of the horse management application 103 according to one or more determined performable operations. The management operations are verified by consideration of the relationship between the user 101 and the particular identified horse 107 (i.e., represented as an association of the horse with the user in the system), and, when the user is a service provider for the horse, a corresponding service type of services provided by the user. For example, the owner of a horse has permission to perform operations including:

(a) viewing a history of all of the activities performed with the horse, irrespective of the activity (i.e., service) type; and (b) create activities of any other type (e.g., transportation).

By contrast, a veterinary service provider user may have permission to:

(a) record new medical service related activities, and (b) view a history of other medical service activities.

In some embodiments, the association of a horse 107 with a service provider user 101 is performed following a request by the service provider user 101, and is subject to authorisation from the corresponding owner of the horse 107. For example, a veterinarian service provider user can identify a horse (such as by scanning the identification tag affixed to the horse's collar) to retrieve horse identification data. For the veterinarian to be associated with the horse for the purpose of performing services the veterinarian operates the horse management application 103 to request to add the horse. If the owner user provides corresponding authorisation, then the service provider is associated with the horse in the system.

The horse management system 100 collects and manages location data representing the real-world geographical position of the horse 107. The location data is generated by the horse management server 110 based on corresponding location tracking data received from one or more location detection devices 160. In the described embodiments, the horse management system 100 can be configured to receive location tracking data from the location detection devices 160 automatically, and asynchronously relative to the activities of the horse 107. According to a type of horse-based asynchronous location tracking, the location detection devices 160 can include at least one satellite navigation device associated with a receiver that is fitted to the horse 107, and configured to transmit the location tracking data (referred to as global tracking). According to a type of sensing-based asynchronous location tracking, the location detection devices 160 can include one or more sensing devices configured to detect the presence of the horse 107 at a particular known location on a property of residence, as typically occurs when the horse engages in some behaviour (referred to as behavioural tracking).

The location detection devices 160 can be configured to transmit location tracking data to the horse management system 100 synchronously with an activity of the corresponding horse 107. According to a type of smart tag-based synchronous location tracking, the location tracking devices 160 can include a mobile device operable by the user to detect a horse, when the device is brought into close proximity of a smart tag of the horse (e.g., a NFC tag as described herein below). According to a type of user controlled synchronous location tracking, the location tracking devices 160 can include the user device 102 as configured to be operable by a user to manually record a location of the horse, and/or where an activity was performed. In some embodiments, the ability to manually record a location is restricted based one or more of:

(a) the user type; and (b) the corresponding activity.

The horse management system 100 is configured to utilise the location data to validate the activity data of a horse 107. The activity validation process involves:

(a) generating an estimate of the location of the horse by processing the location data; and (b) generating location mapping data to associate the estimated location of the horse with the activity data.

When the location data is generated from the asynchronously received location tracking data, the location mapping data further associates the corresponding geographical locations to an activity representing the residence of the horse at a property. For example, location data that is automatically generated by a GPS receiver of the horse 107 may produce a series of locations for the horse within a particular time interval, irrespective of whether any activities are undertaken with the horse in this interval. The system can be configured to automatically link the generated locations to an appropriate activity of a 'business/property' where the horse was residing at that time (e.g., farm, etc.). This allows a user 101 with appropriate permission (e.g., the owner or the property) to view a location history of the horse 107, indicating the position of the horse on the property at particular times.

In some embodiments, the horse management system 100 is configured to utilise the location data, and/or location mapping data, to determine instances where individual horses came into close proximity with one another. Specifically, the location mapping data is processed to cross-reference one or more locations of a first horse, within a specified time interval, with corresponding locations of one or more other horses at the property. This allows the likelihood of close-contact between particular horses, such as those residing at the same property at the same time, to be easily determined (e.g., in the event of a biohazard or disease outbreak).

Accordingly, the presented horse management system 100 constitutes an integrated 'horse passport' solution that addresses the drawbacks of conventional horse management approaches by:

(a) providing a platform for the electronic collection and maintenance of horse activity information, overcoming the inefficiencies of the largely paper-based presently utilised techniques; (b) providing a unified solution for electronic horse management via an application which dynamically verifies the ability of a user to perform management operations based on their relationship with the particular horse and the services provided by the user; (c) presenting a uniform or standard protocol for recording particular services across service providers of the same type, such that corresponding data generated by like service providers can be effectively processed; (d) promoting the efficient sharing of electronic horse management data, both between third parties entities and with the owner such as to increase transparency in the handling of horse management information; and (e) providing an improved ability to determine the welfare of the horse by allowing an entity (such as the owner) to interactively verify recorded activities with corresponding locations of the horse.

System

As shown in Figure 1, a horse management system (HMS) 100 includes a user device 102, such as a smartphone, tablet or other computing device, operated by user 101 and in communication with a horse management server 110 via a communications network 140. The system 100 includes one or more identification devices (ID devices) 105, each being physically coupled to, or inserted subcutaneously in, a respective horse 107 that is managed by the system 100. Each ID device 105 is configured to house or support one or more tags or beacons associated with the horse 107.

In one embodiment, each ID device 105 is a collar fitted to the horse, and is configured to house a near field communication (NFC) enabled tag 170, consisting of an antenna couple to an electronic memory configured to store data. In another embodiment, each ID device 105 is the RFID microchip provided by Racing Australia for the horse. For ease of description, the system 100 is generally below described by way of reference to the ID device 105 being the collar only. However, the two are to be used interchangeably.

The ID device 105 is preferably a multi functional chip that performs at least the following capabilities:

• Standard Transponder • NFC Read • Temperature

The NFC tag 170 contains encoded information representing the identity of the horse 107 (as described below), such that the encoded information is readable by a scanner 109 when the scanner 109 is placed within a vicinity of the ID device 105.The size of the memory and data transfer rate of the NFC tag 170 is dependent on the tag type. For example:

(a) a type I NFC tag stores 96 bytes of data and provides a transfer rate of106 Kbps; (b) a type IV tag can store up to 32 kB and transfer at a rate of424 Kbps.

A person skilled in the relevant art would appreciate that any suitable NFC tag 170 can be used within the system 100, and maybe chosen in accordance with the requirements of the users.

The HMS 100 includes one or more location detection devices 160 configured to transmit location tracking data to the horse management server 110. The type of the location detection devices 160 deployed is dependent on the mechanisms implemented by the HMS 100 to track the location of the managed horses. In the described embodiments, automated activity-asynchronous location tracking is performed by the use of:

(a) satellite navigation devices 162 (such as a GPS receiver unit); and/or (b) a Bluetooth low energy (BLE) Reader 164 configured to detect corresponding GPS signals and Bluetooth signals.

In such configurations, the BLE reader 164 detects a BLE Bluetooth signal produced by a corresponding BLE beacon 166, which is housed by the ID device 105 (e.g., the collar) of horse 107. Alternatively, or in addition, the location detection devices 160 can include the user device 102 (not depicted in Figure 1).

The scanner 109 is configured to communicate with the user device 102 for the purpose of transmitting horse identity information, as obtained from the NFC tag of the ID device 105. The user device 102 includes:

(a) a user interface (UI) module 104 configured to receive user input from the user 101, or from any other user of the user device 102; (b) a communications module 106 for sending and receiving data; (c) a data storage area 108; and

(d) a horse management application 103 executing on the hardware components of the user device 102 which facilitates the processes by which user 101 can perform horse management operations according to the processes described herein below.

The horse management application 103 is a specialised software application that enables communication between the user device 102 and the horse management server 110, such as a mobile application obtainable via a mobile software distribution platform (e.g. Google play store) and/or provided by a vendor of the horse management system 100. In other embodiments, the horse management application 103 is a generic web browser application that renders, onto a display of the user device 102 via UI 104, the content of one or more webpages hosted by a horse management server 110

The user device 102 communicates with the horse management server 110 via communications network 140. The communications network 140 can be a local or wide area network, or a combination of the plurality of different local or wide area some networks. The horse management server 110 includes a communications module configured to exchange data with one or more user devices over the communications network 140. The horse management server 110 receives requests from the user device 102 in relation to managing a particular horse 107. The horse management server 110 processes the requests via a request handler module 114 in order to perform the horse management functionality described herein below. The horse management server 110 is configured to transmit data to the user device 102, including UI interaction data allowing the user 101 to request a horse management operation from a group of operations that can be performed by a particular user 101, and, in some embodiments, response data in response to the request to perform the management operation on the horse 107.

Use of the horse management system 100 proceeds through the operation of a horse management account of the user 101. The horse management server 110 includes an authentication module 116 configured to authenticate the horse management account credentials of user 101, such as a username and password combination, which are used to log into the HMS 100. A successful login results in the authentication module 116 generating an authentication token permitting the user 101 to access the horse management functionality provided by the horse management system 100. Data is exchanged between the user device 102 and the horse management server 110 via a secure communications protocol, such as secure socket layer (SSL).

Although conventional horse management is performed via paper-based documentation, it is likely that some service providers may have electronic data recording systems. Below we describe is a way in which the HMS 100 could interface with these existing systems, such as to extract service provider data and 'load' this into the database.

The horse management server 110 includes an external system interface 118 configured to communicate with one or more external systems 150, such as, for example, any one of a plurality of service providers systems 130 or a horse authority system 139. The service provider systems 130 correspond to service types offered by particular service provider uses, including veterinarian systems 132, transport systems 134, racing systems 136, training systems 137 and farrier systems 138. Service providers systems may operate independently organise and manage data of a horse relative to the specific service of the users of that service provider system. The horse authority system 139 is a system of a horse authority that is responsible for allocating and maintaining identification information for each horse managed by the HMS 100. Horse authority system 139 and each respective service provider system 130 use a unique horse identifier, in the form of a serial number allocated by the horse authority, to organise data corresponding to each particular horse. For example, the veterinarian system 132 may store the medical records of a particular horse, and is accessible to a user 101 who was a service provider of veterinarian services.

External system interface 118 is configured to retrieving external data stored within one or more external databases of each system, for example in order to generate appropriate activity data in a horse management system database 120 (as described below). In the described embodiments, the exchange of data between the horse management server 110 and the external systems 150 occurs via a local network. However, this exchange may involve a wide area network, such as communications network 140.

The horse management server 110 includes a location tracker component 119 configured to receive location tracking data from the location detection devices 160, and generate corresponding location data representing the geo-spatial position of the horse 107. The location tracker 119 is configured to receive and process location co-ordinate data of a format produced by the associated location detection devices 160. For example, in embodiments where the location detection devices 160 include a GPS receiver 162, the tracker 119 is be configured to process co-ordinate values of the World Geodetic System WGS84 format as received from the receiver 162.

In described embodiments, the horse management server 110 includes the database 120, which includes:

(a) a user table 122; (b) a horse table 124; (c) one or more entity tables, including data records for each type of user: (i) owner table 127 for horse owners; (ii) property table 121 for businesses/properties where horses may reside; (iii) service provider table 128 for service providers; and (iv) authority table 129 for authorities of organisations to which managed horses may belong); and (d) an activity table 126 which is configured to store data records representing activities of the horses recorded in horse table 124.

The database tables 121, 122, 123, 124, 126, 127, 128 and 129 are accessed via a database management system (DBMS) of the horse management server 110. The DBMS uses SQL language to query the database, which is implemented as a relational database in the described embodiments. The skilled addressee will appreciate that, in other embodiments, the horse management system 100 may implement a different organisation and/or structure for the database and the corresponding database tables, to that described below.

The user table 122 stores data representing the horse management system account of user 101, including:

(a) login credentials, such as the username and encrypted password information of the user 101; (b) an identifier of the user 101; and (c) a type identifier identifying the type of the user 101 identifying the type of the user.

The combination of the user ID and type link to a corresponding entry in the entity tables 121, 127, 128, and 129.

The owner table 127 stores data representing owner users of one or more horses managed by the system 100, including:

(a) the user's first name and last name; (b) a set of associated horse IDs identifying each horse that is associated with the user; and (c) the contact details of the user (such as, for example, an email address and mobile phone number).

The service provider table 128 stores data representing service provider users of the system 100, including:

(a) the provider's name (such as the business name); (b) an individual name (e.g., an employee of the provider who performs services on behalf of the provider); (c) a set of associated horse IDs identifying each horse that is associated with the provider (i.e., the horses whom the provider is authorised to perform services for); and (d) the contact details of the provider.

Service provider table 128 entries also include a service provider type, which is a specific indicator of the service provided by the user. For example, a veterinarian service provider user is registered with a user type of 'veterinarian', while the type of a transporter is 'transporter', etc.

The property table 121 stores data representing property users that provide a residence for one or more horses managed by the system 100, including:

(a) a Business Name and a locale specific Business Number (e.g., Australian Business Number); (b) a property or business name; (c) an address ofthe property; (d) contact details for a primary contact of the property; and (e) location information for the property (such as references to Barn(s), Paddock(s), Stalls(s), etc.).

Each property table entry also includes a set of associated horse IDs identifying each horse that is associated with the property (i.e., residing at the property).

The authority table 129 stores data representing authorities of particular organisations or institutions to which one or more horses managed by the system 100 may belong, including:

(a) the authority name; an indication of one or more associated institutions governed by the authority; (b) a set of associated horse IDs identifying each horse that is associated with the authority; and (c) the contact details of the authority.

The horse table 124 stores data representing each particular horse managed by the system 100, including for horse 107:

(a) a horse identifier uniquely identifying the horse 107 (as encoded within the NFC tag 170, and/or BLE beacon 166); (b) a name of the horse 107; and (c) biological information of the horse 107, such as its breed type, and age.

Each entry in the activity table 126 represents an activity (e.g., a service) performed on or with a horse, and includes at least data representing:

(a) the user identifier of the user performing the activity; (b) the type of the user performing the activity (e.g., 'owner', 'service provider'); (c) for a service provider activity, a corresponding service type (e.g. 'Vet'); (d) the identifier of the horse; (e) a description of the activity; and (f) date time values representing the times at which the activity was recorded, and at which the activity commenced.

The activity commencement and record times may differ, allowing for a user to record an activity at a time after this activity was actually performed for the horse. In some embodiments, the HMS 100 may be configured to prevent a user from recording a new activity if the time difference between the commencement and recording times exceeds a delay threshold (i.e., in order to preserve the accuracy of activity data maintained by the system). The delay threshold may be determined based, in part, on the activity type (e.g., for veterinary service provider activities the maximum delay may be set to 6 hours, whereas for activities recordable by the owner the maximum delay may be 24 hours).

Each activity table 126 entry also records specific data that is relevant to the activity performed. For example, for an entry representing a veterinarian service activity, the specific data may include a description of the procedure(s) performed and an indication of the recovery time of the horse (if applicable). The activity table entries of service provider types may also specify a cost of performing the service in local currency.

The database 120 includes a location table 123 configured to store location data representing one or more geographical locations of the managed horses. In the described embodiments, the location table 123 stores data including:

(a) a location entry identifier; (b) co-ordinate data indicating a geo-spatial position associated with the location; (c) date time values representing the date and time at which the location was recorded; and (d) a horse ID identifying the horse that is associated with the location.

In the described embodiments of the HMS 100, the horse management server 110, is implemented as one or more computer systems 200, such as, for example, an Intel Architecture computer systems, as shown in Figure 2, and the processes executed by the system 200 are implemented as programming instructions of one or more software modules 202 stored on non-volatile (e.g., hard disk or solid-state drive) storage 204 associated with the computer system. However, it will be apparent that at least parts of these processes could alternatively be implemented as configuration data of field programmable gate arrays (FPGAs), and/or as one or more dedicated hardware components, such as application-specific integrated circuits (ASICs), for example. The user device 102 is implemented as one or more standard mobile computing devices, such as, for example, as computer systems having a 32-bit or 64-bit Advanced RISC Machine (ARM) architecture (e.g., ARMvx), which operate analogously to the standard computing system 200 depicted in Figure 2.

The system 200 includes random access memory (RAM) 206, at least one processor 208, and external interfaces 210, 212, 214, all interconnected by a bus 216. The external interfaces include universal serial bus (USB) interfaces 210, at least one of which is connected to a keyboard 218 and a pointing device such as a mouse 219, a network interface connector (NIC) 212 which connects the system 200 to a communications network, such as the Internet, and a display adapter 214, which is connected to a display device such as an LCD or LED panel display 222.

The system 200 also includes a number of standard software modules 226 to 230, including an operating system 224 such as Linux or Microsoft Windows, web server software 226 such as Apache, available at http://www.apache.org, scripting language support 228 such as PHP, available at http://www.php.net, or Microsoft ASP, and structured query language (SQL) support 230 such as MySQL, available from http://www.mysql.com, which allows data to be stored in and retrieved from an SQL database 125.

In the described embodiments, the user 122, horse 124, activity 126, entity 121, 127, 128, 129 and location 123 tables are stored within database 120, which is implemented using SQL and is accessed by a database management system (DBMS) of the workplace management server device 110. In other embodiments, the database 120 may be implemented on a separate computing device, or across multiple computing devices according to one or more techniques for the distributed processing and storage of data.

Configuration and User Registration Process

The horse management system 100 is configured to execute a horse management process 300, as shown in Figure 3. At step 302, the HMS 100 is configured for use by one or more users, such as user 101 as depicted in Figure 1. Prior to configuration, the database 120 is initialised to facilitate the horse management operations of the system 100. In some embodiments, the initialisation process involves obtaining activity data from one or more external service provider systems 150. The external system interface 118 requests the activity data for prior performed activities from each service provider system of the external systems 150. The tables of database 120 are initialised, including the creation of entity tables 121, 127, 128 and 129 for each entity type supported by the horse management system 100, and the activity table 126 is constructed for the supported user and service provider types. In the described embodiments, the supported service provider types include veterinarian, transportation, racing, training and farrier services, however the skill that receive or recognise that other embodiments are system 100 may support other service types as predetermined during this initialisation phase.

Following the setup of the horse management system described above, the invigoration process, shown in Figure 4, begins with the registration of the user 101 (i.e. at step 402). User registration is initiated by the user 101 via the operation of corresponding UI elements of the horse management application 103 executing on the user device 102. The user 101 provides user information for the creation of a corresponding horse management account with the horse management system 100. The user information includes: the name of the user 101; and email address of the user 101; and a password used access the horse management account of user 101 in conjunction with the username that uniquely identifies the account among all other users of the system 100. In some embodiments, user 101 is able to choose the username of their corresponding horse management account. In other embodiments, the username is allocated automatically by the horse management system 110 based on some combination of the use information supplied by the user 101. In some embodiments, the horse management server 110 may perform additional verification of the username and password values be allocated to the user 101 to ensure that: the username value is unique among all usernames of users that are presently registered with the HMS 100; and that the password values satisfies one or more predetermined password security criteria which specify characteristics for cryptographically secure passwords.

The user registration process involves the allocation of a user type to the user 101. The user type can be set to: 'owner', indicating that user 101 is an "owner user" who utilises the HMS 100 to manage activities for one or more horses that are owned by user 101; a service provider type indicating that user 101 is a "service provider" user who uses the system 100 manage the provision of a service to one or more horses. The user type nominated by the user 101 at the time of registration and is included within the user identification information. The service types available for nomination by user 101 other service type for which the system 100 is configured to support as determined during the initialisation phase described above.

A user registration request is transmitted from the user device 102 to the horse management server 110 requesting registration of the user 101 as specified by the included user information. The request handler 114 processes the request, verifies the supplied user information, and creates user data in the user table 122 of database 120 represent the user 101. In other embodiments, the user registration process may be performed by an administrative (or "super") user accesses the horse management server 110 via an administrator horse management account

Adding a New Horse

At step 404, a registered user 101 who is an owner user can add a horse 107 to the horse management system (i.e. register the horse 107). Owner user 101 operates the UI 104 to select the "Add New Horse" interface option and is presented with interface elements allowing the user 101 to input horse information specifying the horse 107 to be added. The specified horse information includes:

(a) a horse identify uniquely identifying the horse 107; (b) a name of the horse 107; and (c) the biological information of the horse 107.

The user device 102 transmits a request to add the specified horse 107 to the horse management server 110, the request including the horse information specified by the user 101. In some embodiments, the horse identifier can be input by an identification process by scanning the horse identifier from:

(a) the NFC tag 170, or (b) a RFID microchip that is implanted into the horse 107.

In this case, the user 101 selects the "Scan ID" UI elements in the horse management application 103 and activates the scanner 109 to obtain the encoded horse identifier from the NFC tag 170 or the RFID microchip. The horse management application 103 processes the encoded identification value and determines the horse identifier (such as its serial number) automatically. This allows the owner user 101 to add the horse to system 100 for management without needing to manually retrieve and enter the unique serial number.

The request handler 114 of the horse management server 110 processes the data associated with the request to add the new horse. The horse management server 110 extracts the horse ID value and searches the horse table 124 to determine whether a horse with the same ID value has been registered with the system 100. If no such horse has been registered with the supplied horse ID, then (at step 406) the horse management server 110 creates horse management data to facilitate the management of the horse 107. An entry in the horse table 124 is created to represent the horse 107. The horse ID is associated with the user in the appropriate entity table 121, 127, 128 and 129. In some embodiments, the horse management server 110 invokes the external system interface 118 to retrieve data from the horse authority system 139 and/or activity data from one or more service provider systems 130 in relation to the horse 107 based on the horse identifier. The horse management server 110 processes the activity information to generate activity data in the form of entries for the activity table 126 ofdatabase 120.

For example, the external system interface 118 may connect to the horse authority 139 to retrieve horse information maintained by that authority for horse 107, and to the veterinarian system 132 to retrieve medical data representing the medical history of the horse 107. Corresponding entries are then created in the horse table 124 and activity table 126 to record the retrieved veterinarian service data. In some embodiments, the horse management server 110 is configured to crosscheck horse information input by the user 101 during the addition of a new horse to the system 100 (as described above) with data retrieved from the horse authority 139. The crosschecking process can include verifying the horse identifier value and/or that the user identity data stored in the user table 122 for user 101 corresponds to the owner of the horse 107, as recorded by the horse authority system 139. On successful verification of the horse information, the horse 107 is associated with the user 101 by the generation of data representing the horse identifier value in the owner table 124.

If the user 101 is a service provider user, then at step 404 a horse that is registered with the system 100 can be added to the list of horses associated with the user 101. The association of horse 107 with service provider user 101 results in the user 101 being granted permission to:

(a) provide services for horse 107; and (b) view information in relation to services provided for horse 107 that are of the same type as the services provided by user 101.

For example, veterinary service providers can view activities, such as medical procedures, recorded by any other veterinary service provider for a horse to which they are associated). The user 101 operates the horse management application 103 by selecting the "Request Association with Horse" feature on the UI 104. The user 101 inputs the horse identifier value, either manually or by scanning the NFC tag 170 from the horse 107 using scanner 109. The request handler 114 processes the request, and if the request is valid, generates association data in the service provider table 128 entry for user 101.

In some embodiments, the validity of the association request is dependent on the horse management server 110 obtaining authorisation to associate the horse 107 with the user 101. Authorisation involves the generation of authorisation data, including, for example: a prompt for the registered owner of the horse to confirm the association by; and an authentication token or one time authorization code (OTAC). Authorisation is achieved by the transmission of the token or code from the user device of the owner to the horse management server 110. In some embodiments, the authorisation data is an authorisation message of a predetermined form, such as a SMS message.

Requesting a Horse Management Operation

With reference to Figure 3, at step 304 the horse management server 110 receives identification data indicating the particular horse for which the user is to manage. The identification data includes, at least:

(a) an identifier of the managed horse 107; and (b) an identifier of a user 101 of the system.

Figure 5 illustrates a process 500 by which the user device 102 is configured to generate a horse management request representing a request of the user 101 to perform a management operation on a horse 107.

The horse management request includes:

(a) horse identification data representing the identity of a horse managed by the system; (b) user identification data representing the identity of a user of the system; and (c) operation request data representing a requested horse management operation for the horse.

Horse identification data is generated by the application 103 to indicate the particular horse that is to be the subject of the management operation. At step 502, the horse 107 can be selected from a list of known horses associated with the user 101. The application 103 is configured to receive an indication of the user's associated horses, including corresponding horse identifiers. The data indicating the associated horses may be retrieved from a local memory of the user device 102 (i.e., data buffer 108), or received from the horse management server 110 (e.g., during the process of logging into the horse management account of user 101).

The list of associated horses for user 101 is displayed on a UI of the user device 102, allowing the user 101 to interact with one or more interactive UI elements to select the horse 107 for management. Figure 11 is a screenshot of an exemplary horse listing window 1100 rendered on the graphical user interface of the user device 102 by the application 103. In the example window 1100 shown, the individual horses associated with user 101 include:

(a) "Black Ink", represented by list item 1102; (b) "Explobo", represented by list item 1104; and (c) "Explobo 18", represented by list item 1106.

Horse list items 1102, 1004, 1106 are configured to show the name of the horse, the current location of the horse, and an indication of one or more activities most recently performed for the horse. The list items displayed in window 1100 can be filtered by a search function, or similar. For example, search field 1105 allows user 101 to search for list items representing associated horses based on the horse name. The user 101 manipulates the device display to select a list item forthe horse forwhich a management operation is to be requested. Following the selection of the graphical listing item representing horse 107 from the listing, the corresponding horse identifier is then extracted from the associated horse data for horse 107.

As an alternative to selecting horse 107 from a graphical listing, at step 503 the user 101 operates the user device 102 to read the NFC tag 170 (or alternatively the RFID microchip). The scanner 109 reads the NFC tag data representing the encoded information on the NFC tag 170 and transmits this data to application 103. The horse management application 103 processes the NFC tag data to determine the encoded horse information with respect to horse 107, including the horse identifier. If the horse is recognised by the horse management application 103 as being from the list of known horses associated with the user 101, the corresponding horse listing is displayed onto UI 104 allowing user 101 to confirm the selection of horse 107 for management.

At step 504, the horse management application 103 generates the horse identification data representing the selected horse 107 for management, and corresponding user identification data representing user 101. The user identification data uniquely identifies the user 101 among all registered users of the HMS 100, and includes: an indication of a user identifier; and an indication of a user type of the user. In the described embodiments, the user ID data also includes authentication data in the form of a token to allow the server 110 to verify that the request to manage the horse 107 originated from user 101. The horse and user ID data are integrated into a single message that provides the information necessary to request the management of the horse 107.

With reference to Figure 5, at step 506 the user 101 selects a requested horse management operation for the horse 107. The horse management application 103 is configured to present a list of management operations to the user 101 for the horse 107 via UI 104 of the user device 102. In the described embodiments, the horse management application presents user 101 with a unified set of horse management operations that may be conducted for each managed horse of the system 100. In the described embodiments, the horse management operation requested by user 101 may be, but is not necessarily limited to, an operation from the group of:

(a) recording a new activity for the horse 107; (b) updating an existing activity recorded for the horse 107; and (c) obtaining an activity history representing one or more activities recorded for the horse 107.

Figures 12 to 14 are screenshots of exemplary management operation windows rendered on the graphical user interface of the user device 102 by the application 103 for a user 101 who is a service provider managing horse 107. With reference to the example of Figure 11, consider the selection of horse 107 as "Black Ink" by user 101. The user 101 interacts with the elements of service provider selection window 1200, as shown in Figure 12, to determine the requested management operation as (a) recording a new activity for horse 107 (i.e. via the "Add Activity" tab). As the user 101 is a service provider, window 1200 dynamically presents service type categories to user 101 allowing the user to specify the service type via corresponding interaction elements (e.g., "Farm" 1202, Vet" 1204, "Farrier" 1206, "Dentist" 1208, "Branding" 1210, "Chiro"

1212 and "Transport" 1214) for the new activity. Figure 13 and 14 show exemplary windows 1300 and 1400 for the selection of a new activity in accordance with the management operation (a), for the Vet and Farrier service providers. Activities selectable for the "Vet" service provider include:

(a) medically assessing the horse 1302; (b) microchipping the horse 1304; (c) performing a surgery on the horse 1310; and (d) performing an x-ray scan for the horse 1316.

Activity categories, such as "Pregnancy", "Treatment" and "Vaccination", have corresponding interaction elements 1308, 1312, 1314 that, when activated, allow user 101 to select a more specific activity in relation to the category from a subsequently presented window (not shown).

As shown in Figure 14, the new activities of a Farrier service provider that may be selected, for management operation (a), include:

(a) assessing the horse 1402; (b) shoeing the horse 1404; (c) performing specialist work on the horse 1408; (d) providing treatment to the horse 1410; and (e) trimming the horse 1412.

The application 103 also provides an "Other" activity 1306 1406 for either service provider type allowing the user 101 to perform a custom new activity for horse 107.

On selecting the activity associated with the selected managed operation, application 103 presents the user 101 with an appropriate activity information window. The nature of the information window is dependent on the management operation. For example, for operations (a) and (b) the information window includes interface elements operable to allow the user 101 to input new information required to create the new activity entry, or select an existing entry to update and input modification information required to modify that selected activity. In some embodiments, for operation (b) the application 103 obtains existing activity data from local memory of the application. In other embodiments, the application 103 requests an activity data list of the existing activities for horse 107 from the horse management server 110. The application 103 presents corresponding received activity entries to the user 101 for the appropriate activity type. The user 101 can subsequently select an existing entry from the received activity entries to update.

Figures 15 and 16 show exemplary new activity user interface window of the horse management client application 103 for activities representing checking a horse 107 into ("Arrive Horse" window 1500) and out of ("Depart Horse" window 1600) a property respectively. In the described embodiments, user 101 specifies whether the horse 107 to be checked into the property is a "known" horse (i.e., a horse that has been previously associated with the property) or a "new" horse, via elements 1502, 1504. If the horse 107 is a new horse, then the check in activity may involve the user 101 providing details of the horse 107, including an indication of the owner, an indication of the horse identifier, and biological information of the horse. In some embodiments, checking out a horse 107 involves the user 101 providing a condition report via text field 1602 describing the condition of horse 107 on checkout. The user 101 may upload one or more photographs (via element 1604) to support the condition report text entered into field 1602.

The application 103 is configured to generate operation request data representing the operation specified by the interactions of user 101 with the application interface, as discussed above. Specifically, in the described embodiments the operation request data includes:

(a) an operation identifier indicating the requested management operation (e.g., one of operations (a) to (c) above; and (b) one or more operation parameters that specify the activity information associated with the requested operation. For example, for a request to perform operation (a) on horse 107, the parameters may include the type of the activity to be recorded, and corresponding activity record data (e.g., the activity information specified by the user that is to be stored by the system).

With reference to Figure 5, at step 508 the application 103 combines the operation request data with the horse ID data, and with the user ID data, to generate management request data representing the request of user 101 to perform the chosen horse management operation on horse 107 (i.e., for the example discussed above, to add a new activity for horse "Black Ink", where the activity to be added is a Vet or Farrier activity). The application 103 transmits the management request data to the horse management server 110, which is received at step 304 depicted in Figure 1.

Performing the Requested Management Operation

With reference to Figure 3, following the receipt of the management request data from the user device 102, the horse management server 110 verifies the horse management request to determine whether the requested horse management operation is performable (i.e., at step 306).

As shown in Figure 6, at step 602 the verification of the request commences with the request handler 114 processing the management request data to extract:

(a) user ID information, including the user type, identifier and authentication token; and (b) horse ID information, including the horse identifier of the horse 107 requested to be managed.

At step 604, the server 110 verifies the existence of an association between horse 107 and the user101by:

(a) determining the appropriate entity table (e.g., owner 127, property 121, service provider 128, or authority 129) for user 101, based on the extracted user type data; (b) retrieving the data record for user 101 from the appropriate entity table; and (c) comparing the extracted horse identifier with the set of identifiers of the data record for the user 101.

An association between user 101 and horse 107 exists if the horse identifier appears in the data record.

If the association of user 101 to horse 107 is verified (i.e., exists), then at step 606 the request handler 114 generates data representing the group of management operations that are performable by user 101 with respect to horse 107. The determination of which of the operations available by system 100 (i.e., (a) to (c) above) are performable by user 101 for horse 107 based on at least one of:

(a) an association of the horse with the user; (b) a user type ofthe user; and (c) when the user type is a service provider type, a corresponding service type of services provided by the user.

In the described embodiments, the request handler 114 determines whether a requested management operation is performable based on a set of permissions. The permissions are user specific, and are stored within a permission matrix, table or similar data structure in the server 110. In the described embodiments, the HMS 100 is configured to restrict the operations performable by user 101 on particular horses based on whether the user is an owner of the horse, or, if they are a service provider, the type of services provided in relation to the activity type of the requested activity.

For example, for a user 101 who is a veterinarian, the horse management application 103 presents functionality to perform veterinarian activities on horse 107, or to view the existing veterinarian activity records, or other related records (such as those of trainers, dentists, etc.) of horse 107.

By contrast, for a user 101 who is an owner of horse 107, the horse management application 103 presents UI functions allowing the user to view any activities performed with horse 107 by any service provider (or other) user registered with the horse management system 100. Additionally, in some embodiments, the owner user is also able to record new activities for horse 107 being activities that are not exclusive to any particular service provider.

In some embodiments, the request handler 114 determines whether the requested operation is performable based on the one or more parameters of the operation request. For example, when the requested operation is (b) updating an existing activity recorded for the horse, the operation request parameters specify an activity to update from corresponding existing activities of the horse. The request handler 114 can be configured to restrict the permissions of user 101 to only allow updates to existing activities which, for example, were originally recorded by the user 101 (i.e., such that only a service provider who performed a particular service for the horse is given permission to later update the data record of that service).

In the described embodiments, an activity recorded for a horse 107 cannot be deleted or removed. This prevents data tampering, and promotes transparency in the interactions of entities with the horses (i.e., such that the activity history for any given horse managed by the HMS 100 acts as a true 'digital passport'). In other embodiments, the request handler 114 can be configured to allow particular users (such as the owner) to perform management operations that delete or remove activities. Deletion or removal may be conditional, for example as subject to authorisation from the corresponding creator user of the activity (e.g. a service provider, or other user).

With reference to Figure 3, at step 308 if the requested horse management operation is performable (i.e., according to step 306), the horse management server 110 performs the requested operation. Figures 7a and 7b illustrate the process of performing a horse management operation requested by user 101 in respect of horse 107.

At step 702, the horse management server 110 receives the management request data which is processed by the request handler 114 to extract, from the operation data:

(a) an indication of the operation requested (e.g., (a) to (c) above); and (b) the corresponding operation request parameters.

The operation parameters may include the type of the activity to be recorded (e.g., "Vet->Treatment"), and corresponding activity record data (e.g., information describing the medical treatment on the horse). At steps 703a, 703b, the request handler module 114 processes the operation data to execute the requested (performable) management operation. Execution of the requested management operation by the request handler 114 involves generating, updating and/or retrieving activity data from database 120 of the system to reflect the activity of the horse.

With reference to Figure 7a, at step 703a, when the requested operation is (a) recording a new activity for the horse, or (b) updating an existing activity recorded for the horse, executing the operation includes: generating activity data in database 120 to reflect the recording of the new activity for the horse, orto reflect the update to the existing activity of the horse. Specifically, for operation (a) a new activity data record is created in activity table 126 with the activity record fields being populated based on information of the operation request parameters. For operation (b), request handler 114 identifies an existing activity record in table 126 corresponding to the activity to be updated/modified, and updates the record entry fields according to generated activity update data representing information of the operation request parameters.

With reference to Figure 7b, at step 703b, when the requested operation is (c) obtaining an activity history for the horse, executing the operation includes:

(a) generating activity history data from corresponding activity data stored in the database 120; and (b) transmitting the generated activity history data to user device 102 of the user 101.

The activity history data is generated by the request handler 114 based on information of the operation request parameters. For example, the request parameters may include:

(a) an activity type (e.g. medical treatments); (b) a corresponding user type, and/or identifier (e.g., a user ID to specify all activities performed by the individual corresponding to the user ID, or "service provider - veterinarian" as the user type to specify all activities by veterinarian service providers); and (c) a history time interval specifying the date time range of the activities to be included in the activity history.

The request handler 114 retrieves the activity data from the database 120 (i.e., at step 705), and generates the activity history data by collating the extracted activity data records (i.e., at step 707)

In some embodiments, following execution of the (performable) requested operation, at step 708 the request handler 114 validates one or more activities of the performed operation based on location data maintained by database 120 (as discussed below).

At step 710, the horse management server 110 generates horse management operation response data to indicate the result of the request made by user 101 with respect to horse 107. The request handler 114 generates response data based on at least one of: the updated activity data; and the generated activity history data. For example, when the requested operation is (a) or (b) above, the response data may include an indication that the activity data stored by the system 100 for horse 107 has been augmented by the recording of a new activity, or the updating of an existing activity, respectively.

When the requested operation is (c) above obtaining an activity history for the horse, the management operation response data includes the activity history data generated by the request handler 114 at step 707. In some embodiments, where the horse management request is not performable (as determined by verification step 306), the response data may also include a notification that the requested management operation could not be performed and a corresponding description of one or more reasons why the verification at step 306 was unsuccessful.

At step 712, the request handler 114 passes the horse management operation response data to the communications module 112 for transmission to the user device 102. The user device 102 is configured to process the response data and display appropriate operation response elements on the UI 104 (e.g., in the case of operation (c), to present a list of activities representing the history data for horse 107).

Location Tracking and Activity Validation Processes

With reference to Figures 7a and 7b, at step 708 the request handler 114 utilises location data representing one or more geographical locations of the horse 107 at one or more corresponding time instants. The location tracker 119 of horse management server 110 is configured to generate the data based on location tracking data received from one or more location detection devices 160, as described above. The location tracking data includes:

(a) horse co-ordinate data indicating an estimated geo-spatial position of the horse; and (b) the identifier of the horse.

The location tracker 119 is configured to log the location of horse 107 by generating entries in the location table 123 of database. Horse location logging is performed according to one or more approaches which may be categorised as:

(a) automated activity-asynchronous location tracking; or (b) manual activity-synchronous location tracking.

Automated activity-asynchronous location tracking

In automated activity-asynchronous location tracking, location detection devices 160 are configured to automatically transmit the location tracking data to the horse management server 110 asynchronously relative to the activities of the horse to which a requested management operation relates. These approaches include:

(i) GPS tracking; and (ii) sensing-based tracking.

In GPS Tracking, at least one satellite navigation device (e.g. GPS unit 162) is fitted to the horse 107 (i.e., via collar ID device 105) to generate the location tracking data. Under this approach, the location of the horse 107 is determined fully automatically by the server 110, with a location update for the horse being generated consistency and predictably according to a pre-determined tracking period (e.g., set to once every 6 hours in the described embodiments).

In Sensing-based Tracking, one or more sensing devices are deployed within a physical area inhabited by the horse 107, in order to automatically produce a location update for the horse 107 when the horse encounters the sensor. Sensing-based tracking results in the ad-hoc generation of location data based on steps including:

(A) detecting the presence of the horse in the proximity of a sensing device; (B) determining horse identification data of the detected horse; and (C) transmitting, to the horse management server 110, location tracking data including device co-ordinate data indicating a geo-spatial position of the device, and the horse identification data.

In the described embodiments, sensing-based tracking is implemented by the use of BLE beacon 166 fitted to the horse 107 (i.e., via collar ID device 105). The BLE beacon 166 contains encoded information representing the identity of the horse 107 (as described above for the NFC Tag 170), and is configured to generate Bluetooth signals that are detected by at least one corresponding location detector in the form of a BLE reader 164. When the horse 107 moves within the detection range of the BLE reader 164, the BLE reader 164 obtains the horse identification data (e.g., a horse ID value) by reading the corresponding data embedded on the BLE beacon 166 (in a similar process as for the reading of NFC Tag 170, as discussed above).

Multiple BLE readers may be deployed around the areas of a property (e.g., a farm or paddock) in which horse 107 resides, where the specific areas of deployment can be chosen to correspond to areas that the horse must visit during their residence. For example, in some implementations a single sensing device 160 may be deployed at a water trough, or at another location that horse 107 is known to visit regularly.

Manual activity-synchronous location tracking

In manual location tracking, location detection devices 160 transmit the location tracking data to the horse management server 110 in response to a manual operation initiated by the user 101 (referred to as "logging" the horse location). This may occur synchronously with requesting a management operation in relation to an activity performed with the horse by the user 101 (e.g., the user 101 may log the location of horse 107 when recording a treatment performed for the horse). These approaches include: Smart-tag logging; and user application logging.

In Smart-tag logging, the location detection devices include a mobile device operable by the user 101 to:

(a) scan an ID tag 105 of the horse 107 to obtain the horse identification data; and (b) transmit, to the horse management server 110, location tracking data including device co-ordinate data indicating a geo-spatial position of the mobile device, and the horse identification data.

In the described embodiments, the mobile device used to perform the smart-tag logging is the user device 102. The user 101 operates the application 103 to initiate the location logging event. The scanner 109 is activated to detect the NFC tag 170 attached to the neck collar 105 (or alternatively the RFID microchip) to obtain the horse identifier. Application 103 accesses the location services functionality of the device 102 to obtain the device location when the NFC read operation is activated. The device location is then transmitted to the server 110, with identifier of horse 107, as the location tracking data.

Thus, the location of the horse can be logged each time the horse is moved from a trainer's stables to a race track, for example.

In user application logging, the location detection devices include the user device 102 which is configured to be operable, by the user 101, to manually prompt an update of the location of horse 107. The user 101 operates the application 103 to initiate the location logging event by selecting the horse that they which to view or update from a corresponding list. The horses for which a user 101 may prompt an update are determined by the corresponding permissions (i.e., as based on the user type and association with each managed horse).

In some embodiments, the user application location update is executed as a management operation (v) recording a new location for the horse 107, as requested by the user 101 similarly to the operations described above. Alternatively, or additionally, the user application location update can be initiated by the user 101 scanning the ID tag 170 of the horse 107 using the user device 102.

On verification that the user 101 is authorised to perform a manual location update, the application 103 obtains location co-ordinate data indicating a geo-spatial position of the horse. The location co-ordinate data may be supplied by the user 101 (e.g., via the selection of a point on a map rendered on UI 104, or entry of specific co-ordinate values), or obtained from the location services functionality of the device 102 (i.e., in the case where the user 101 indicates thatthe horse 107 is located at the user's "Current Location").

With reference to Figure 10, table 1000 illustrates the above described location logging approaches of the described embodiments of HMS 100. The skilled addressee will appreciate the flexibility of the HMS 100 in allowing forthe use of different combinations of the location tracking approaches described herein depending on the requirements of the users (e.g., with respect to detection ranges, whether or not fully autonomous tracking is needed for each horse, etc.).

As discussed above, the request handler 114 utilises the location data to validate one or more activities associated with the operation performed at step 708. Figure 8 illustrates a process 800 forvalidating an activity of a performed operation, as requested by the user 101 for horse 107. At step 802, location tracking data is received from one or more of the location tracking devices 160, where the location tracker 119 generates the location data from the received data, as described above.

Given location data stored in database 120, in the described embodiments validating an activity involves resolving a location to the activity by:

(a) processing the location data to generate an estimate of the location of the horse for the activity of the requested management operation (i.e., at step 804); and (b) generating location mapping data to associate the estimated location of the horse with the activity data of the corresponding activity.

The validation of the activity will require the association of a particular location with that activity. But location values can come into the system at any time (asynchronous approaches) - below described is a way to map a location to the activity based on the location data that is already in the table.

Figure 9 illustrates the process of generating a horse location estimate for an activity specified by particular activity data. Consider activity a occurring (i.e. commencing) at a time ta as recorded in activity table 126. Location table 123 includes N location data entries L = [L1 ,L 2 , .. .,LN] each representing a geospatial location I = [,..generated from tracking data received at times [t,t ... ,tN]. Location data entries L are referred to as "directly determined" locations, since they represent exact locations obtained from the tracking data supplied by location detection devices 160.

To determine the geospatial location E representing the estimated location of horse 107 at time ta, Location tracker 119 filters the directly determined location data entries based on: the horse ID data of the entry; and the corresponding date time value. The horse ID value is extracted from the activity data by the location tracker 119. Location tracker 119 is also configured to define a location candidate time interval [tstart,ten] in which the received time t, of a location entry L, must fall within in order for the corresponding co-ordinates 1, of that entry to be considered as a candidate location Icana (i.e., at step 902). In the described embodiments, the start and end times of the location candidate time interval [tstart,ten] are determined dynamically based on the activity type, the activity commencement time ta (i.e., such that ta E [tstartten] ) and such as to capture a minimum number of location entries in the candidate set.

At step 904, the location tracker 119 filters location data entries L to identify candidate location data that both relates to the horse of interest (e.g., horse 107) and which was created within the candidate time interval. That is, an estimated horse location E for horse 107 at activity commencement time ta is produced based on M location candidates Lgana [ana ana...an]eachdescribing a tracked location of the horse 107 within the candidate time interval[tstart,ten].

At steps 906 and 908, the M location candidates ofLcandare processed according to a location estimation method. In the described embodiments, the location estimation method is a temporal matching strategy in which the estimated location value E is taken as the candidate location value that has a received time closest to the activity time ta, among all candidates.

In some embodiments, the location estimation method involves determining a predicted location of the horse at the activity time ta based on the co-ordinates and corresponding received date time values of the candidate location data. For example, the location tracker 119 may assign a weighting to each candidate location based on the time difference between the received location data time value and the activity commencement time ta. Individual co-ordinates of the estimated location C are then generated based on a consideration of the weighted components of each candidate location.

With reference to Figure 8, at step 806 the estimated location iis linked to the activity of the horse 107 by the generation of location mapping data. In the described embodiments, the location mapping data specifies a new entry in the location table 123 for estimated location a, which is referred to as a "mapped location" entry (indicating that it is based on an estimated value rather than a value received "directly" from a location device). Corresponding activity table 126 entry is updated to link to the newly created mapped location entry (i.e., by the recording of the location identifier for the mapped location entry).

In some embodiments of the HMS 100, the generated location mapping data further associates the estimated location of the horse to an activity representing the residence of the horse at a property. For example, on determination of the estimated location ,

the location tracker 119 can be configured to record the estimated location value in a residence entry of the activity table 126, indicating the residence of the horse 107 at a business/property (e.g., a stables or paddock as recorded within property table 121). The residence activity may be separate from the activity being validated, and can be for example an activity representing the arrival of the horse 107 at the business/property. This allows the HMS 100 to constantly and automatically track the locations occupied by the horse 107 on a particular property as part of the activity data.

In embodiments where the location tracker 119 is configured to track the locations occupied by the horse 107 on a particular property, as described above, the group of horse management operations may further include: (iv) determining the close contacts of the horse. In such embodiments, performing the horse management operation at (c) further includes, when the requested operation is (iv) determining the close contacts of the horse: generating contact data indicating instances of close proximity interaction between individual horses by processing the location data to cross-reference one or more locations of the horse, within a specified time interval, to corresponding locations of one or more other horses at the property.

The contact data can be expressed as a list, table, or similar data structure, configured to an indication of each individual horse involved in a close contact instance (e.g., via a 'contacts' field which lists the horse ID values of two corresponding horses). The contact data entry references the corresponding property at which the contact between the animals was recorded, and a date time value indicating the time and date of the contact. In some embodiments, the determination of a close contact between horse 107 and other horse 107a involves the processing of the location data associated with 107, 107a to determine, or estimate, whether a measure of the distance between the horses during that specified time interval. If the determined, or estimated, distance value is below a threshold value then the location tracker 119 records an instance of close contact as a contact data entry.

The user 101 can request to view the recorded close contact data, by providing an indication of either the horses 107, 107a, etc. or a property at which particular horses resided. For example, when rendered on the UI 104, the close contact data may provide the user 101 with an indication of: the horses involved in the contact; the locations of each horse; the distance between each during the contact; the date and time of the contact; and the property at which it occurred. This can be utilised, for example, to determine the risk of transmission of a disease between horses in the event of an outbreak.

In the described embodiments of the HMS 100, the horse management server 110 is configured to allow a user 101 to view the location history of one or more managed horses. The user 101 may request to (vi) obtain a location history representing one or more geographical locations recorded for the horse 107, in accordance with the management operation request processes described above. Given that the operation is performable for user 101 with respect to horse 107, performing operation (vi) includes: generating location history data from the corresponding location data; and transmitting the generated location history data to the user device. The location history data is generated by the location tracker 119 via an index to location table 123 to extract the location data entries corresponding to the horse 107 (i.e., via the appropriate horse ID value). The location data entries returned by the indexing operation are processed to extract location history information for presenting to the user 101. The location data entries are collated and transmitted to the user device 102 in a predetermined form for display on UI 104.

Figure 15 shows an exemplary location history display user interface window 1700 for displaying location history information of one or more horse residing at a property managed by the system 100, including a series of location list items 1701 each showing: the date time value of the location record 1702; horse identification information (e.g., name and/or horse ID) for the horse logged 1704; and the location logging method used to produce the data 1706.

In some embodiments, the collated location data entries are included as part of generated operation response data that is transmitted from server 110 to the user device, at step 310. The operation response data may include interactive user interface elements that, when displayed on the user device 102, are operable to allow the user 101 to interactively verify recorded activities with corresponding locations of the horse 107 For example, Figure 16 shows an exemplary graphical location tracking user interface window "Latest Locations" 1800, in which logged locations of the horse 107 are depicted graphically in association with activities representing the residence of the horse 107 at a stables property. In this example, the depiction is a geographical map illustrating the position of the horse 107 at within the bounds of the property over a particular time interval. This provides the user 101 with an improved ability to determine the welfare of the horse 107.

In other embodiments, the horse management operations also include requesting a list of all horses that have been within a specified area within a specified time period. These parameters could be modified by a user so as to vary the period of time and/or the size of the area. The area could be defined by a radius around the user device 12, for example, or by a location input by the user. As an alternative to a list of horses, a graphical location tracking user interface window with a map of the relevant area could be generated with indicia showing the location of the relevant horses.

In other embodiments, the horse management operations also include requesting a list of horses that have a common medical condition. When this option is selected, the user device generates the interface (not shown) that enables the user to input the desired medical condition. On receipt of this data, the user device generates the graphical location tracking user interface window 2000 shown in Figure 19 that shows the location of horses that presented with symptoms of XYX-19. As an alternative to a list of horses, a map of the relevant area could be generated with indicia showing the location of the relevant horses.

In use, the system 100 can be used to track horses 107 that have been in a specified area at a specified time and date. This data is important for assisting in controlling an outbreak of a disease. For example, the system can generate a window 3000 shown in Figure 20 showing all horses 107 that have been present in an area from the time of an outbreak of a disease in that same area.

With reference to Figure 21, the service providers include one or more of the following:

a. Vets; b. Farriers; c. Dentists; d. Transport drivers; e. Educators; and f. Trainers.

To maintain data integrity, the service providers need to be licensed and/or registered with the system.

Facilities include:

a. Farms; b. Studs; c. Racing stables; d. Sale yards; e. Clinics; and f. Race tracks.

Governing bodies, State and Commonwealth Departments determine rules / regulations and guidelines.

Technology:

a. Phone APP is role based on Service Provider / Coupled to scanner for MC reading; b. Phone APP feeds Cloud Application; c. Monitor Events; d. Monitor Map Search Analysis of horse located within the MAP view; e. General Lifecycle of a thoroughbred.

Goods Management

As above mentioned, the technical problems associated with the underlying technology for tracking horses is not restricted to horses. Rather, similar technical problems exist in the underlying infrastructure for tracking goods, such as, for example, diesel tanks, LPG gas tanks, feed bins, etc.

The above described digital horse management system 100 is also suitable for use in managing tracing of such goods. For example, the system 100 is capable of performing the following analogous processes in respect of goods management:

1. Configuration and User Registration Process 300 shown in Figure 3; 2. Requesting a goods management operation, in accordance with the process 500 shown in Figure 5; 3. Performing the Requested Management Operation, in accordance with the process 600 shown in Figure 6; and 4. Location Tracking and Activity Validation Processes.

For example, the present invention includes a process for electronic goods management executed by at least one processor 208 of a computing system 100, the process including the steps of:

(a) receiving, by a goods management server 110 of the system 100, a goods management request including: (i) good identification data representing the identity of a good managed by the system 100; (ii) user identification data representing the identity of a user of the system 100; and (iii) operation request data representing a goods management operation requested by the user 101with respect to the good 107, the requested goods management operation being from the group including: (A) recording a new activity for the good; (B) updating an existing activity recorded for the good; and (C) obtaining an activity history representing one or more activities recorded for the good 107; (b) verifying, by the goods management server 110, the goods management request to determine whether the requested goods management operation is performable; and (c) if the requested goods management operation is performable, performing, by the goods management server 110, the requested goods management operation by: (i) when the requested operation is (A) or (B): generating activity data in a database 120 of the system 100 to reflect the recording of the new activity for the good, or to reflect the update to the existing activity of the good 107; and (ii) when the requested operation is (C): generating activity history data from corresponding activity data stored in the database 120; and transmitting the generated activity history data to a user device 102 of the user 107, wherein, the determination of whether the requested goods management operation is performable is based on at least one of: (a) an association of the good 107 with the user 101; (b) a user type ofthe user 101; and (c) when the user type is a service provider type, a corresponding service type of services provided by the user 101.

Similarly, the invention provides a process for electronic management of goods executed by at least one processor of a computing system, the process including the steps of: (a) receiving, by a goods management server 110 of the system 100, a goods management request including: (i) good identification data representing the identity of a good managed by the system 100; and (ii) operation request data representing a goods management operation requested by the user 101 with respect to the good 107, the requested goods management operation is recording a location of the good 107; (b) performing, by the goods management server 110, the requested goods management operation by generating location data representing a geographical location of the good 107 at corresponding time instant; and (c) recording the location data associated with the good identification data in a database 120 in communication with the at least one processor

Again, this is analogous to the above described processes for the horses.

Throughout this specification, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

The reference to any prior art in this specification is not, and should not be taken as, an acknowledgment or any form of suggestion that the prior art forms part of the common general knowledge.

LIST OF PARTS

100 Digital horse management system; Digital goods management system 101 Users 102 User device 103 Horse management application; goods management application 104 User interface 105 Identification device 107 Managed horse; managed good 108 Data storage area 109 Scanner 110 Horse management server; goods management server 114 Request handler module 116 Authentication module 118 External system interface 119 Location tracker component 120 Database 121 Property table 122 User table 124 Horse table; goods table 125 SQL database 126 Horse activity table; good activity table 127 Owner table 128 Service provider table 129 Authority table 130 Service provider system 132 Veterinarian system 134 Transport system 136 Racing system 137 Training system 138 Farrier system 139 Horse authority system; goods authority system 140 Communications network 150 External system 160 Location detection device 162 Satellite navigation device

164 Bluetooth low energy (BLE) reader 166 BLE beacon 170 Near field communication enabled tag 200 Computer system 202 Software module 204 Non-volatile storage 206 Random access memory 208 Processor 210 USB interface 212 Network interface connector 214 Display adapter 216 Bus 218 Keyboard 219 Mouse 222 Display panel 224 Operating system 226 Web server 228 Scripting language support 230 Structured query language support 1100 Window 1102 Horse list item; Good list item 1104 Horse list item; Good list item 1105 Search field 1106 Horse list item; Good list item 1200 Window 1202 Farm 1204 Vet 1206 Farrier 1208 Dentist 1210 Branding 1212 Chiro 1214 Transport 1300, 1400,1500,1600 Window 1302, 1304,1310,1316 Activity 1308, 1312,1314 Interaction element 1402, 1404, 1408 to 1412 Activity 1306, 1406 Other activity

1502, 1504 Element 1602 Text field 1604 Element 1700, 1800,2000 Window 1702 Location record 1704 Horse logged; good logged 1706 Data

Claims

1. A process for electronic horse management executed by at least one processor of a computing system, the process including the steps of: (a) receiving, by a horse management server of the system, a horse management request including: (i) horse identification data representing the identity of a horse managed by the system; (ii) user identification data representing the identity of a user of the system; and (iii) operation request data representing a horse management operation requested by the user with respect to the horse, the requested horse management operation being from the group including: (A) recording a new activity for the horse; (B) updating an existing activity recorded for the horse; and (C) obtaining an activity history representing one or more activities recorded for the horse; (b) verifying, by the horse management server, the horse management request to determine whether the requested horse management operation is performable; and (c) if the requested horse management operation is performable, performing, by the horse management server, the requested horse management operation by: (i) when the requested operation is (A) or (B): generating activity data in a database of the system to reflect the recording of the new activity for the horse, or to reflect the update to the existing activity of the horse; and (ii) when the requested operation is (C): generating activity history data from corresponding activity data stored in the database; and transmitting the generated activity history data to a user device of the user, wherein, the determination of whether the requested horse management operation is performable is based on at least one of: (a) an association of the horse with the user; (b) a user type ofthe user; and (c) when the user type is a service provider type, a corresponding service type of services provided by the user.

2. The horse management process of claim 1, wherein the horse management server is configured to generate location data representing a geographical location of the horse at corresponding time instant.

3. The horse management process of claim 2, including the step of validating one or more activities of the performed horse management operation based on the location data.

4. The horse management process of claim 3, wherein validating the one or more activities includes: (a) processing the location data to generate an estimate of the location of the horse for the activity of the requested management operation; and (b) generating location mapping data to associate the estimated location of the horse with the activity data of the corresponding activity.

5. The horse management process of any one of claims 2 to 4, wherein the location data is generated based on location tracking data received from one or more location detection devices.

6. The horse management process of claim 5, wherein the location detection devices are configured to automatically transmit the location tracking data to the horse management server asynchronously relative to the activities of the horse.

7. The horse management process of claim 6, wherein the location detection devices include at least one satellite navigation device coupled to the horse, the device being configured to generate the location tracking data which includes: (a) horse co-ordinate data indicating an estimated geo-spatial position of the horse; and (b) the identifier of the horse.

8. The horse management process of any one of claims 5 to 7, wherein the location detection devices include one or more sensing devices each configured to: (a) detect the presence of the horse in the proximity of the device; (b) determine horse identification data of the detected horse; and (c) transmit, to the horse management server, location tracking data including device co-ordinate data indicating a geo-spatial position of the device, and the horse identification data.

9. The horse management process of any one of claims 6 to 8, wherein generating an estimate of the location of the horse for the corresponding activity includes: (a) determining a predicted location of the horse at a time of the activity based on the one or more geographical locations and corresponding date time values of the location data.

10. The horse management process of any one of claims 6 to 9, wherein the generated location mapping data further associates the estimated location of the horse to an activity representing the residence of the horse at a property.

11. The horse management process of claim 10, wherein the requested horse management operation is from a group further including: (D) determining the close contacts of the horse, and wherein performing the horse management operation further includes, when the requested operation is determining the close contacts of the horse (D): generating contact data indicating instances of close proximity interaction between individual horses by processing the location data to cross-reference one or more locations of the horse, within a specified time interval, to corresponding locations of one or more other horses at the property.

12. The horse management process of claim 5, wherein the location detection devices include a mobile device operable by the user to: scan an ID device of the horse to obtain the horse identification data; and transmit, to the horse management server, location tracking data including device co-ordinate data indicating a geo-spatial position of the mobile device, and the horse identification data.

13. The horse management process of claim 12, wherein the mobile device is the user device.

14. The horse management process of any one of claims 4 to 13, wherein the requested horse management operation is from a group further including: (E) recording a location for the horse, and wherein performing the horse management operation further includes, when the requested operation is (E): generating location data to reflect the location of the horse.

15. The horse management process of any one of claims 4 to 14, wherein the requested horse management operation is from a group further including: (F) obtaining a location history representing one or more geographical locations recorded for the horse, and wherein performing the horse management operation further includes, when the requested operation is (F): generating location history data from the corresponding location data; and transmitting the generated location history data to the user device.

16. The horse management process of any one of claims 4 to 15, including: (a) generating, by the horse management server, horse management operation response data based on at least one of: the updated activity data; and the generated activity history data; and (b) transmitting, the horse management operation response data, to the user device.

17. The horse management process of claim 16, wherein the generated operation response data includes interactive user interface elements that, when displayed on the user device, are operable to allow the userto interactively verify recorded activities with corresponding locations of the horse, providing an improved ability to determine the welfare of the horse.

18. The horse management process of any one of claims 4 to 17, wherein the requested horse management operation is from a group further including: (G) display map of a horses present at a geographical location, and wherein performing the horse management operation further includes, when the requested operation is (G): receiving data representing a geographical location; generating data representing geographical location and indicia representing horses whose location is close range to the geographical location; and transmitting the data representing geographical location and indicia representing horses to the user device.

19. The horse management process of claim 18, also including the step of: (a) receiving data representing a time and/or date, wherein the step of generating data representing geographical location and indicia representing horses whose location is close range to the geographical location, includes horses present at the location at a corresponding time and/or date.

20. A horse management system, including: (a) at least one database storing: (i) user data representing one or more users of the system, at least some of the users being: (A) an owner of one or more horses managed by the system; or (B) a service provider that provides services of a service type for the one or more horses; (ii) horse data representing the one or more horses, each horse having: (A) at least one associated owner user; and (B) horse identification data representing the identity of the horse; and (iii) activity data representing one or more activities each performed by an owner user or a service provider user with a corresponding one of the one or more horses; and (b) a horse management server coupled to the database, including: (i) a communications interface to receive data; (ii) at least one computer processor to execute program instructions; and (iii) a memory, coupled to the at least one computer processor, to store program instructions for execution by the at least one computer processor to automatically execute the horse management process of any one of claims 1 to 17.

21. The system claimed of claim 20, the horse data representing the one or more horses additionally includes, for each horse, location data representing current and historical locations of the horse.

22. One or more computer-readable storage media having stored thereon instructions that, when executed by at least one processor of a computing system or device, cause the at least one processor to execute the process of any one of claims 1 to 19.

23. A process for electronic horse management executed by at least one processor of a computing system, the process including the steps of: (a) receiving, by a horse management server of the system, a horse management request including: (i) horse identification data representing the identity of a horse managed by the system; and (ii) operation request data representing a horse management operation requested by the user with respect to the horse, the requested horse management operation is recording a location of the horse; (b) performing, by the horse management server, the requested horse management operation by generating location data representing a geographical location of the horse at corresponding time instant; and (c) recording the location data associated with the horse identification data in a database in communication with the at least one processor.

24. The process of claim 23, wherein the location data is generated based on location tracking data received from one or more location detection devices.

25. The process of claim 24, wherein the location detection devices include a mobile device operable by the user to: (a) scan an ID device of the horse to obtain the horse identification data; and (b) transmit, to the horse management server, location tracking data including device co-ordinate data indicating a geo-spatial position of the mobile device, and the horse identification data.

26. The process of claim 25, wherein the mobile device is the user device.

27. A process for electronic management of goods executed by at least one processor of a computing system, the process including the steps of: (a) receiving, by a goods management server of the system, a goods management request including: (i) good identification data representing the identity of a good managed by the system; and (ii) operation request data representing a goods management operation requested by the user with respect to the good, the requested goods management operation is recording a location of the good; (b) performing, by the goods management server, the requested goods management operation by generating location data representing a geographical location of the good at corresponding time instant; and (c) recording the location data associated with the good identification data in a database in communication with the at least one processor.

28. The process of claim 27, wherein the location data is generated based on location tracking data received from one or more location detection devices.

29. The process of claim 28, wherein the location detection devices include a mobile device operable by the user to: (a) scan an ID device of the good to obtain the good identification data; and (b) transmit, to the goods management server, location tracking data including device co-ordinate data indicating a geo-spatial position of the mobile device, and the good identification data.

30. The process of claim 29, wherein the mobile device is the user device.

31. A process for electronic goods management executed by at least one processor of a computing system, the process including the steps of: (a) receiving, by a goods management server of the system, a goods management request including: (i) good identification data representing the identity of a good managed by the system; (ii) user identification data representing the identity of a user of the system; and (iii) operation request data representing a goods management operation requested by the user with respect to the good, the requested goods management operation being from the group including: (A) recording a new activity for the good; (B) updating an existing activity recorded for the good; and (C) obtaining an activity history representing one or more activities recorded for the good; (b) verifying, by the goods management server, the goods management request to determine whether the requested goods management operation is performable; and (c) if the requested goods management operation is performable, performing, by the goods management server, the requested goods management operation by:

(i) when the requested operation is (A) or (B): generating activity data in a database of the system to reflect the recording of the new activity for the good, or to reflect the update to the existing activity of the good; and (ii) when the requested operation is (C): generating activity history data from corresponding activity data stored in the database; and transmitting the generated activity history data to a user device of the user, wherein, the determination of whether the requested goods management operation is performable is based on at least one of: (a) an association of the good with the user; (b) a user type ofthe user; and (c) when the user type is a service provider type, a corresponding service type of services provided by the user.

32. The process of claim 31, wherein the goods management server is configured to generate location data representing a geographical location of the good at corresponding time instant.

33. The process of claim 32, including the step of validating one or more activities of the performed goods management operation based on the location data.

34. The process of claim 33, wherein validating the one or more activities includes: (a) processing the location data to generate an estimate of the location of the good for the activity of the requested management operation; and (b) generating location mapping data to associate the estimated location of the good with the activity data of the corresponding activity.

35. The process of any one of claims 33 to 34, wherein the location data is generated based on location tracking data received from one or more location detection devices.

36. The process of claim 35, wherein the location detection devices are configured to automatically transmit the location tracking data to the goods management server asynchronously relative to the activities of the good.

37. The process of claim 36, wherein the location detection devices include at least one satellite navigation device coupled to the good, the device being configured to generate the location tracking data which includes: (a) good co-ordinate data indicating an estimated geo-spatial position of the good; and (b) the identifier of the good.

38. The process of any one of claims 35 to 37, wherein the location detection devices include one or more sensing devices each configured to: (a) detect the presence of the good in the proximity of the device; (b) determine good identification data of the detected good; and (c) transmit, to the goods management server, location tracking data including device co-ordinate data indicating a geo-spatial position of the device, and the good identification data.

40. The process of any one of claims 36 to 38, wherein generating an estimate of the location of the good for the corresponding activity includes: (a) determining a predicted location of the good at a time of the activity based on the one or more geographical locations and corresponding date time values of the location data.

41. The process of claim 35, wherein the location detection devices include a mobile device operable by the user to: scan an ID device of the good to obtain the good identification data; and transmit, to the goods management server, location tracking data including device co-ordinate data indicating a geo-spatial position of the mobile device, and the good identification data.

42. The process of claim 41 wherein the mobile device is the user device.

44. The process of any one of claims 34 to 42, wherein the requested horse management operation is from a group further including: (E) recording a location for the good, and wherein performing the goods management operation further includes, when the requested operation is (E): generating location data to reflect the location of the good.

45. The process of any one of claims 34 to 44, wherein the requested goods management operation is from a group further including: (F) obtaining a location history representing one or more geographical locations recorded for the good, and wherein performing the goods management operation further includes, when the requested operation is (F): generating location history data from the corresponding location data; and transmitting the generated location history data to the user device.

46. The process of any one of claims 34 to 45, including: (a) generating, by the goods management server, goods management operation response data based on at least one of: the updated activity data; and the generated activity history data; and (b) transmitting, the goods management operation response data, to the user device.

47. The process of claim 46, wherein the generated operation response data includes interactive user interface elements that, when displayed on the user device, are operable to allow the user to interactively verify recorded activities with corresponding locations of the good.

48. The process of any one of claims 34 to 47, wherein the requested horse management operation is from a group further including: (G) display map of a goods present at a geographical location, and wherein performing the goods management operation further includes, when the requested operation is (G): receiving data representing a geographical location; generating data representing geographical location and indicia representing goods whose location is close range to the geographical location; and transmitting the data representing geographical location and indicia representing goods to the user device.

49. The process of claim 48, also including the step of: (a) receiving data representing a time and/or date, wherein the step of generating data representing geographical location and indicia representing goods whose location is close range to the geographical location, includes goods present at the location at a corresponding time and/or date.

44. A goods management system, including: (a) at least one database storing: (i) user data representing one or more users of the system, at least some of the users being: (A) an owner of one or more goods managed by the system; or (B) a service provider that provides services of a service type for the one or more goods; (ii) goods data representing the one or more goods, each horse having: (A) at least one associated owner user; and (B) good identification data representing the identity of the good; and (iii) activity data representing one or more activities each performed by an owner user or a service provider user with a corresponding one of the one or more goods; and (b) a goods management server coupled to the database, including: (i) a communications interface to receive data; (ii) at least one computer processor to execute program instructions; and (iii) a memory, coupled to the at least one computer processor, to store program instructions for execution by the at least one computer processor to automatically execute the goods management process of any one of claims 29 to 43.

45. The system claimed of claim 44, the goods data representing the one or more goods additionally includes, for each good, location data representing current and historical locations of the good.

46. One or more computer-readable storage media having stored thereon instructions that, when executed by at least one processor of a computing system or device, cause the at least one processor to execute the process of any one of claims 29 to 43.