WO2019056068A1

WO2019056068A1 - Sharing of tracked asset data

Info

Publication number: WO2019056068A1
Application number: PCT/AU2018/051038
Authority: WO
Inventors: Gary James SCOTT
Original assignee: Gwip Pty Ltd
Priority date: 2017-09-22
Filing date: 2018-09-21
Publication date: 2019-03-28

Abstract

An aspect of the invention provides a sharing system (100) for tracked asset data. The system includes a sharing engine (120) configured to receive asset data obtained from at least one asset tracking system for example tracking system (110) and/or (112). The asset data is associated to at least one tracked asset for example vehicle (102), (104), (106) (and/or 108). The sharing engine (120) includes a transformation engine (124) configured to apply at least one first transformation rule to a set of disparate attributes associated to the asset data to derive a set of standard asset data attributes, and an authorisation engine (122) configured to apply at least one authorisation rule to the asset data. The sharing (engine 120) is further configured to expose at least one subset of the asset data to at least one client according to the at least one authorisation rule. Examples of clients include ((150), 152) and/or (154).

Description

SHARING OF TRACKED ASSET DATA

FIELD OF THE INVENTION

The invention relates to a method and system for sharing tracked asset data.

BACKGROUND

Organisations have a duty of care for the safety of sub-contractors working for the organisation. While this duty of care will differ in different regulatory environments, it would generally include knowing where sub-contractors are, and making every effort to ensure they are safe. Knowing what other assets are nearby allows the closest asset operators to be contacted to assist in the event of an emergency.

Contracting organisations are able to monitor their workers via asset tracking consoles. However they will not necessarily be aware of the local risks in the operational area of the organisation to which they are contracted. Existing asset tracking systems tend to rely on having dedicated equipment associated to each tracked asset. Consuming parties attempting to track assets are often required to manage asset data from multiple sources.

It is an object of at least preferred embodiments of the present invention to address some of the aforementioned disadvantages. An additional or alternative object is to at least provide the public with a useful choice.

SUMMARY OF THE INVENTION

In accordance with an aspect of the invention, a method of sharing tracked asset data comprises receiving asset data obtained from at least one asset tracking system, the asset data associated to at least one tracked asset; applying at least one first transformation rule to a set of disparate attributes associated to the asset data to derive a set of standard asset data attributes; applying at least one authorisation rule to the asset data; and exposing at least one subset of the asset data to at least one client according to the at least one authorisation rule. The term 'comprising' as used in this specification means 'consisting at least in part of. When interpreting each statement in this specification that includes the term

'comprising', features other than that or those prefaced by the term may also be present. Related terms such as 'comprise' and 'comprises' are to be interpreted in the same manner.

In an embodiment the asset data includes at least one asset data packet, the at least one asset data packet including a score representing the current alertness of the person to which the tracked asset is associated.

In an embodiment the asset data packet includes at least one predicted future alertness score of the person to which the tracked asset is associated.

In an embodiment the asset data packet includes an alertness scale.

In an embodiment the asset data includes at least one asset data packet, the at least one asset data packet including a score representing the current level of heat stress of the person to which the tracked asset is associated. In an embodiment the asset data packet includes a heat stress scale.

In an embodiment the at least one authorisation rule is configured to expose the at least one subset of the asset data if a location associated to the at least one tracked asset is within a predefined operational area.

In an embodiment the at least one authorisation rule is configured not to expose the at least one subset of the asset data if a location associated to the at least one tracked asset is within a predefined personal use area.

In an embodiment the method further comprises receiving asset data associated to the predefined personal use area.

In an embodiment at least some of the asset data associated to the predefined personal use area is received from at least one providing party.

In an embodiment the method further comprises receiving the at least one authorisation rule from the at least one providing party.

In an embodiment the method further comprises applying at least one second transformation rule to the asset data to transform at least some of the set of standard asset data attributes associated to the asset data to a set of client-centric asset data attributes. In an embodiment the method further comprises selecting the at least one second transformation rule from a plurality of available second transformation rules based at least partly on at least one client preference.

In an embodiment the method further comprises applying at least one subscription rule to the asset data; and exposing the at least one subset of the asset data to the at least one client according to the at least one subscription rule.

In an embodiment the method further comprises selecting the at least one subscription rule from a plurality of available subscription rules based at least partly on at least one client preference. In an embodiment the asset data is received from at least one tracking system associated to the at least one tracked asset.

In an embodiment the asset data is received from a first tracking system associated to a first tracked asset and a second tracking system associated to a second tracked asset.

In an embodiment the first tracking system and/or the second tracking system is/are associated to a plurality of tracked assets.

In an embodiment the asset data is received from the at least one tracking system in response to a request to the at least one tracking system.

In an embodiment the asset data is received from the at least one tracking system via at least one push notification. In an embodiment the at least one tracking system is physically separated from the at least one tracked asset.

In an embodiment the at least one subset of the asset data is exposed to the at least one client in response to a client request.

In an embodiment the at least one subset of the asset data is exposed to the at least one client via at least one push notification.

In accordance with a further aspect of the invention, a sharing system for tracked asset data comprises a sharing engine configured to receive asset data obtained from at least one asset tracking system, the asset data associated to at least one tracked asset; the sharing engine comprising a transformation engine configured to apply at least one first transformation rule to a set of disparate attributes associated to the asset data to derive a set of standard asset data attributes, and an authorisation engine configured to apply at least one authorisation rule to the asset data; the sharing engine further configured to expose at least one subset of the asset data to at least one client according to the at least one authorisation rule.

In an embodiment the asset data packet includes an alertness scale. In an embodiment the asset data includes at least one asset data packet, the at least one asset data packet including a score representing the current level of heat stress of the person to which the tracked asset is associated.

In an embodiment the asset data packet includes a heat stress scale.

In an embodiment the at least one authorisation rule is configured not to expose the at least one subset of the asset data if a location associated to the at least one tracked asset is within a predefined personal use area. In an embodiment the system is further configured to receive asset data associated to the predefined personal use area.

In an embodiment the system is further configured to receive the at least one

authorisation rule from the at least one providing party.

In an embodiment the transformation engine is further configured to apply at least one second transformation rule to the asset data to transform at least some of the set of standard asset data attributes associated to the asset data to a set of client-centric asset data attributes. In an embodiment the transformation engine is further configured to select the at least one second transformation rule from a plurality of available second transformation rules based at least partly on at least one client preference.

In an embodiment the system further comprises a subscription engine configured to: apply at least one subscription rule to the asset data; and expose the at least one subset of the asset data to the at least one client according to the at least one subscription rule.

In an embodiment the subscription engine is further configured to select the at least one subscription rule from a plurality of available subscription rules based at least partly on at least one client preference. In an embodiment the asset data is received from at least one tracking system associated to the at least one tracked asset.

A computer-readable medium having stored thereon computer-executable instructions that, when executed by a processor, cause the processor to perform a method of sharing tracked asset data, the method comprising receiving asset data obtained from at least one asset tracking system, the asset data associated to at least one tracked asset;

applying at least one first transformation rule to a set of disparate attributes associated to the asset data to derive a set of standard asset data attributes; applying at least one authorisation rule to the asset data; and exposing at least one subset of the asset data to at least one client according to the at least one authorisation rule.

In an embodiment the asset data packet includes an alertness scale.

In an embodiment the asset data includes at least one asset data packet, the at least one asset data packet including a score representing the current level of heat stress of the person to which the tracked asset is associated.

In an embodiment the asset data packet includes a heat stress scale.

In an embodiment the method further comprises receiving the at least one authorisation rule from the at least one providing party. In an embodiment the method further comprises applying at least one second transformation rule to the asset data to transform at least some of the set of standard asset data attributes associated to the asset data to a set of client-centric asset data attributes. In an embodiment the method further comprises selecting the at least one second transformation rule from a plurality of available second transformation rules based at least partly on at least one client preference.

In an embodiment the method further comprises: applying at least one subscription rule to the asset data; and exposing the at least one subset of the asset data to the at least one client according to the at least one subscription rule.

In accordance with a further aspect of the invention, a sharing system for tracked asset data comprises at least one storage device; and at least one processor programmed to: receive asset data obtained from at least one asset tracking system, the asset data associated to at least one tracked asset, apply at least one first transformation rule to a set of disparate attributes associated to the asset data to derive a set of standard asset data attributes, apply at least one authorisation rule to the asset data, and expose at least one subset of the asset data to at least one client according to the at least one authorisation rule.

The invention in one aspect comprises several steps. The relation of one or more of such steps with respect to each of the others, the apparatus embodying features of construction, and combinations of elements and arrangement of parts that are adapted to affect such steps, are all exemplified in the following detailed disclosure.

This invention may also be said broadly to consist in the parts, elements and features referred to or indicated in the specification of the application, individually or collectively, and any or all combinations of any two or more said parts, elements or features, and where specific integers are mentioned herein which have known equivalents in the art to which this invention relates, such known equivalents are deemed to be incorporated herein as if individually set forth.

In addition, where features or aspects of the invention are described in terms of Markush groups, those persons skilled in the art will appreciate that the invention is also thereby described in terms of any individual member or subgroup of members of the Markush group.

As used herein, '(s)' following a noun means the plural and/or singular forms of the noun.

As used herein, the term 'and/or' means 'and' or 'or' or both. The terms 'component', 'module', 'system', 'interface', and/or the like as used in this specification in relation to a processor are generally intended to refer to a computer- related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

The term 'computer-readable medium' should be taken to include a single medium or multiple media. Examples of multiple media include a centralised or distributed database and/or associated caches. These multiple media store the one or more sets of computer executable instructions. The term 'computer readable medium' should also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor and that cause the processor to perform any one or more of the methods described above. The computer-readable medium is also capable of storing, encoding or carrying data structures used by or associated with these sets of

instructions. The term 'computer-readable medium' includes solid-state memories, optical media and magnetic media. The term 'connected to' as used in this specification in relation to data or signal transfer includes all direct or indirect types of communication, including wired and wireless, via a cellular network, via a data bus, or any other computer structure. It is envisaged that there may be intervening elements between the connected integers. Variants such as 'in communication with', 'joined to', and 'attached to' are to be interpreted in a similar manner. Related terms such as 'connecting' and 'in connection with' are to be

interpreted in the same manner.

It is intended that reference to a range of numbers disclosed herein (for example, 1 to 10) also incorporates reference to all rational numbers within that range (for example, 1, 1.1, 2, 3, 3.9, 4, 5, 6, 6.5, 7, 8, 9, and 10) and also any range of rational numbers within that range (for example, 2 to 8, 1.5 to 5.5, and 3.1 to 4.7) and, therefore, all sub-ranges of all ranges expressly disclosed herein are hereby expressly disclosed.

These are only examples of what is specifically intended and all possible combinations of numerical values between the lowest value and the highest value enumerated are to be considered to be expressly stated in this application in a similar manner. In this specification where reference has been made to patent specifications, other external documents, or other sources of information, this is generally for the purpose of providing a context for discussing the features of the invention. Unless specifically stated otherwise, reference to such external documents or such sources of information is not to be construed as an admission that such documents or such sources of information, in any jurisdiction, are prior art or form part of the common general knowledge in the art.

Although the present invention is broadly as defined above, those persons skilled in the art will appreciate that the invention is not limited thereto and that the invention also includes embodiments of which the following description gives examples.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred forms of the method and system for sharing tracked asset data will now be described by way of example only with reference to the accompanying figures in which

Figure 1 shows an example of a system for sharing tracked asset data. Figure 2 shows an example of a setup process involving a data source subscription by a consuming party from figure 1.

Figure 3 shows an example of a general setup process by a consuming party from figure 1. Figure 4 shows an example of a setup process involving loading and registering context data by a providing party from figure 1.

Figure 5 shows an example of a setup process involving registering and defining at least one data source by a providing party from figure 1.

Figure 6 shows an example of a setup process involving setting up data sharing definitions by a providing party from figure 1.

Figure 7 shows an example of a runtime process for event processing by the sharing engine of figure 1.

Figure 8 shows an example of a technique for processing an event from figure 7.

Figure 9 shows an example of a technique for processing an event for a consuming party from figure 8.

Figure 10 shows an example of a technique for processing an event for an active spatial user interface from figure 9.

Figure 11 shows an example of a process for pushing data to a client. Figure 12 shows an example of a computing device from figure 1.

DETAILED DESCRIPTION

Figure 1 shows an example of a system 100 for sharing tracked asset data. Examples of tracked assets include mobile assets such as motor vehicles, trailers, boats, ships, shipping containers, pallets, aircraft, medical equipment, computer equipment, mobile phones, wearable devices, electronic sensors and radio handsets.

Examples of tracked assets are indicated at 102, 104, 106 and 108 respectively. The tracked assets in figure 1 are each shown as vehicles for simplicity. In an embodiment the tracked assets include assets other than vehicles. In an embodiment only some of the tracked assets comprise vehicles. Individual assets are associated to at least one asset tracking system. For example vehicle 102 and vehicle 104 are associated to asset tracking system 110. Asset tracking system 110 is associated to both vehicle 102 and vehicle 104. Vehicle 106 and vehicle 108 on the other hand are associated to asset tracking system 112. Asset tracking system 112 is associated to both vehicle 106 and vehicle 108.

In an embodiment the tracking system(s) is/are physically separated from the tracked asset(s). For example vehicle 102 and vehicle 104 are physically separated from asset tracking system 110. Vehicle 106 and vehicle 108 are physically separated from asset tracking system 112. Data is exchanged at least partially wirelessly between the tracking system(s) and the tracked asset(s).

For simplicity, figure 1 shows two vehicles associated to each of asset tracking systems 110 and 112. In practice often there will be more than two vehicles associated to each of asset tracking systems 110 and 112. Furthermore, in practice often there will be more than two asset tracking systems forming part of system 100. However it is envisaged that a single tracked asset could be associated to a single tracking system and vice versa.

In an embodiment at least one of the vehicles and/or at least one of the tracking systems is associated to a providing party. In an embodiment a providing party is an entity that controls at least one of the vehicles and/or at least one of the tracking systems. In an embodiment a providing party is an entity that receives data from at least one of the vehicles and/or or at least one of the tracking systems.

Providing party 114 for example is associated to vehicle 102, vehicle 104 and tracking system 110. Providing party 116 for example is associated to vehicle 106, vehicle 108 and tracking system 112. In an embodiment at least one providing party includes an administrator. An

administrator includes a computing device comprising a processor, at least one memory, and computer-executable instructions stored in the at least one memory that cause the processor to perform certain functions as will be described below.

In an embodiment the computer-executable instructions include application software configured to control a processor of the administrator under the control of a human operator, for example a human administrator. In an embodiment the computer- executable instructions include application software configured to control the processor at least partly autonomously with little or no control of a human operator. Providing party 114 includes for example administrator 118. Providing party 116 includes administrator 119. References to a providing party performing an action are to be interpreted to include an administrator associated to the providing part performing the action. Tracking system 110, tracking system 112, administrator 118, and administrator 119 are shown connected to the sharing engine 120 at a single point. This representation is intended merely to simplify figure 1. In practice these components will not necessarily share a single interface, but would use different interfaces.

In an embodiment the tracked assets are configured to transmit asset data to the tracking system(s) to which the tracked assets are associated. In an embodiment the asset data is transmitted as at least one data packet and preferably a plurality of data packets.

In an embodiment at least some of the data packets include respective timestamps associated to the data packets. At least some data packets further include an operational status associated to a tracked asset. An example of an operational status is a current location. Further examples of an operational status include one or more of temperature, hours of service of the driver in the last 24 hours, current alertness level, predicted alertness level, heart rate, number of outward signs of fatigue in the last 30 minutes, current heat stress level and predicted heat stress level. The timestamp in combination with the location represents a current location of the tracked asset.

In an embodiment, a location associated to a tracked asset is a collection of attributes. These attributes include at least a latitude and longitude. In an embodiment the attributes further include one or more of an altitude, a height above ground level, a coordinate system, GPS quality (for example a number of satellites and horizontal dilution of precision).

In an embodiment a timestamp associated to a data packet includes one or more of a date, a time, an explicit time zone, an implied time zone.

In an embodiment the asset data is obtained from a device or a plurality of devices associated to the respective tracked assets 102, 104, 106, and 108. The device(s) assemble the asset data into asset data packets ready for transmission to the associated tracking systems 110 and 112. In an embodiment at least some of the data is

maintained in computer memory associated to the tracked asset(s) before transmission to the tracking system(s). In an embodiment at least one of the data packets includes a further operational status associated to a tracked asset. Examples of an operational status in addition to location include one or more of velocity, direction, engine status (off/on), odometer reading, fuel reading, time since engine off, vehicle idle time, driver seat belt status, acceleration rate, deceleration rate, 4WD engagement status, IVMS unit disconnection status, rollover status, impact status, duress status.

In an embodiment at least one of the data packets includes a score representing a current alertness of a person to which the tracked asset is associated, also referred to as a current alertness score. One example of a current alertness score is the SAFTE Alertness score. At a score of 100, no loss in performance is expected on account of sleep loss. A score above 70 represents normal or above normal levels of alertness. A score of 70 or below represents decreased levels of alertness known as fatigue impairment.

Another example of a score representing a current alertness is the CURA (Circadian User Risk Assessment) Alertness Score. A score within a 10-point scale represents a risk of alertness degradation. A score of 10 represents a low risk of alertness degradation. A decrease in the score represents an increase in the risk of alertness degradation.

In an embodiment at least one of the data packets includes a score representing a predicted future alertness score of the person to which the tracked asset is associated. In an embodiment the SAFTE Fatigue model predicts changes in cognitive effectiveness taking in to account factors such as the seasonal body-clock and seasonal light exposure based on a person's geographic location. Similarly, the CURA system predicts when changes in fatigue risk are likely to take place during the next 24 hours.

In an embodiment at least one of the data packets includes an alertness scale. The alertness scale refers to the model that defines the current and/or predicted alertness score values. In the case of the SAFTE Alertness score, the alertness scale could be "SAFTE". In the case of the CURA Alertness score, the alertness scale could be "CURA"..

In an embodiment at least one of the data packets includes a score representing a current level of heat stress of the person to which the tracked asset is associated. In an embodiment at least one of the data packets includes a heat stress scale. The heat stress scale refers to the model that defines the heat stress score values. Examples of current heat stress scales include one or more of the following : • Wet Bulb Globe Temperature (WBGT) - This score is sensitive to dry bulb, radiant and natural wet bulb temperatures, and air velocity. It can be adjusted to take into account clothing, work rate or duration of exposure.

• Effective Temperature (ET) and Corrected Effective Temperature (CET) - This score combines the effects of globe temperature (radiant and dry bulb), wet bulb and air velocity, though not under hot, humid conditions.

• Heat Stress Index (HSI) - This score is based on the physical analysis of heat exchange. The index equates the amounts of heat required to be dissipated by evaporation of sweat with the maximum possible evaporative capacity. · Predicted Four Hour Sweat Rate (P4SR) - This score represents the quantity of sweat, in litres, likely to be produced under specific thermal conditions. It takes into account the metabolic rate and to a lesser extent the clothing worn, along with dry bulb, radiant temperature, wet bulb and air velocity.

The Wet-Kata Thermometer - This score measures the cooling power of the environment. This index correlates well with body responses in hot, humid conditions, but is less meaningful in hot dry conditions and with unacclimatised people.

• The Air Cooling Power - This score recognises workload, and clothing additionally to the environmental factors of wet and dry bulb temperatures, radiant temperature and wind velocity.

Other examples of heat stress scales include one of more of a Heat Strain Index and an Index of Thermal Stress (ITS).

In an embodiment the tracking systems 110 and 112 make data packets available to a sharing engine 120. The data packets include asset data obtained from tracked assets 102, 104, 106, and 108. The asset data is associated to at least one tracked asset. In an embodiment at least some of the data packets are maintained in computer memory associated to the tracking system(s) before transmission to the sharing engine 120.

In an embodiment the asset data in the data packets made available to the sharing engine 120 further includes driver details and/or vehicle details. In an embodiment the asset data does not include driver details, for example where the asset comprises a shipping container, a trailer or an unmanned aircraft. In an embodiment the asset data does not include vehicle details, for example where the asset comprises something other than a vehicle for example a shipping container. Examples of driver details include one or more of driver identifier, driver name, driver contact number, employer name, employer contact number. In an embodiment at least some of the driver details are maintained in at least one of the tracking systems. In an embodiment at least some of the driver details are obtained from at least one of the tracked assets.

Examples of vehicle details include one or more of vehicle ID, vehicle registration number, vehicle category, vehicle make, vehicle model, vehicle maximum loaded weight. In an embodiment at least some of the vehicle details are maintained in at least one of the tracking systems. In an embodiment at least some of the vehicle details are obtained from at least one of the tracked assets.

In an embodiment the sharing engine 120 includes one or more of an authorisation engine 122, a transformation engine 124, a subscription engine 126. The sharing engine 120 is configured to expose at least one subset of the asset data to at least one client. Examples of clients are indicated at 150, 152 and 154. In an embodiment the asset data is exposed to the client(s) in response to a client request. In an embodiment the asset data is exposed to the client(s) via push

notification(s).

In an embodiment a client includes a computing device comprising a processor, at least one memory, and computer-executable instructions stored in the at least one memory that cause the processor to perform certain functions as will be described below.

In an embodiment the computer-executable instructions include application software configured to control the processor under the control of a human operator. In an embodiment the computer-executable instructions include application software configured to control the processor at least partly autonomously with little or no control of a human operator.

In an embodiment at least one of the clients operates under direct or delegated authority from a consuming party. A consuming party is typically an organisation or individual that has registered to receive asset data from the sharing engine 120.

Consuming party 156 for example comprises an individual operating client 150.

Consuming party 158 for example comprises an organisation operating client 152 and client 154. Within the consuming party 158 there may be a human administrator for example operating client 152 and another individual operating client 154. Client 154 is configured to delegate authority for at least some tasks to client 152 operated by the administrator. Examples of delegated tasks include the creation of user accounts for people and/or systems.

The sharing engine 120 is configured to apply rules to at least partly specify at least one client to which asset data is to be provided, the subset of asset data to be provided to the specified client, and a client preference for at least one attribute or characteristic of the asset data.

In an embodiment the sharing engine 120 is configured to generate or at least compile metadata from the received asset data. Examples of metadata include a data provider associated to a providing party, a data system associated to the providing party, and whether or not data in the asset data has been manipulated. Examples of manipulated data can arise for example when a speed is estimated, or when interim data packets are dropped.

In an embodiment the authorisation engine 122 is configured to apply at least one authorisation rule to the asset data. At least one subset of the asset data is then exposed to clients of a consuming party according to the at least one authorisation rule. In an embodiment the authorisation rules control which of the asset data is exposed to the client(s).

Examples of categories of authorisation rules include time, date, shift, geographic area, attributes. The following table sets out examples of authorisation rule categories.

Authorisation rule Examples

category

Time Only include asset events recorded between 6am and

6pm on week days.

Date i Only include asset events recorded between the 16^th

September and 30^th October 2017.

Shift Only include asset events recorded when driver is on shift (plus 30 minutes either side).

Only include current alertness level when worker is on duty for the consuming party.

Geographic Area Always report asset events recorded within a

predefined operational area, for example a high risk operational area of the consuming party. Never report asset events recorded within a

predefined personal use area of the driver.

Never report asset events recorded within a

predefined operational area, for example a publicly accessible operational area .

Attributes of asset or asset Only include asset events recorded when "working for" tracking data system attribute is a specified value.

Only include asset events recorded when "job

requestor" attribute is a specified value.

Only include asset events recorded when "customer job reference" attribute begins with a specified value.

Only include asset events recorded for vehicles of category A

Only include asset events recorded for vehicle(s) of driver N

Only provide location, vehicle identifier, vehicle type and job number to client A.

Provide all attributes to client B.

In an embodiment a predefined personal use area is a geographic area that is defined for the purpose of excluding asset events triggered from within that area from being shared. An example of a personal use area is the region within 1 mile of the home of a driver. Another example is the region defined by the boundary of the town the driver lives within.

Attributes that can be specified as being withheld or provided include location, velocity, accelerometer, temperature, engine status, seatbelt status. It will be appreciated that this list is not exhaustive. In an embodiment the transformation engine 124 is configured to apply at least one transformation rule to the asset data. The transformation rule(s) is/are applied to a set of disparate attributes associated to the asset data to derive a set of standard asset data attributes.

The transformation rules are typically provided by clients of consuming parties in advance and stored in a memory associated to the sharing engine 120. The asset data is then exposed to clients of the consuming party in a form specified by the transformation rules the consuming party has provided.

One example of a transformation rule is to provide the asset data in a format consistent with a specified coordinate system. Examples of coordinate systems include GS84, EGM2008, GDA94. In an embodiment the disparate attributes include an attribute representing the coordinate system used by the tracking system, and attributes representing the geospatial co-ordinates of the asset using that coordinate system. The transformation rule derives attributes representing the geospatial co-ordinates of the asset using the standard coordinate system. Another example of a transformation rule is to provide velocity data within the asset data in a specified unit. Examples of specified units include m/s, km/h, mph. In an embodiment the disparate attributes include attributes representing a velocity distance unit, a velocity distance measure, a velocity time unit, a velocity time measure, a direction bearing unit, and a direction bearing measure. The transformation rule derives standard attributes for example attributes representing the velocity distance measure in a standard velocity distance unit, the velocity time measure in a standard velocity time unit, and the direction bearing measure in a standard direction bearing unit.

Another example of a transformation rule is to provide distance data within the asset data in a specified unit. Examples of specified units include miles, kms. Another example of a transformation rule is to provide liquid volume data within the asset data in a specified unit. Examples of specified units include litres, imperial gallons, US liquid gallons.

Another example of a transformation rule is to provide date and time data within the asset data in a specified timezone. In an embodiment the transformation rules are applied to a set of disparate attributes to derive a set of standard asset data attributes. In an embodiment the set includes one or more of location, speed, distance, volume, date, time.

In an embodiment the above examples represent a set of first transformation rules to derive a set of standard asset data attributes. In an embodiment a set of second transformation rules are applied to the asset data. The at least one second

transformation rule transforms at least some of the set of standard asset data attributes associated to the asset data to a set of client-centric asset data attributes. In this way the consuming party receives the data in the format the consuming party has specified. In an embodiment the subscription engine 126 is configured to apply at least one subscription rule to the asset data. For example if a row of data matches at least one subscription rule then that row of data is exposed to a selected client or clients according to the at least one subscription rule. Examples of categories of subscription rules include providing parties, geographic area, attributes. The following table sets out examples of the subscription rule categories.

Subscription category Examples

Providing parties Only include asset events from providing parties A, C

and T.

Geographic Area Only include asset events recorded within operational areas X and Y.

Only include asset events at an altitude of 20,000 feet or below.

Attributes of asset tracking Only include asset events for asset identifiers E, J and data system Y.

Only include asset events recorded for vehicles of category G

Only include asset events recorded for vehicles of driver M

Only include asset events whose location is based on at least 4 satellites.

Only include asset events for vehicles carrying freight load K.

In an embodiment the subscription rule(s) is/are selected from the above categories based at least partly on at least one client preference. For example a client may prefer to use miles for any asset data specifying distance. Another example is that a client may prefer to use miles per hour as the unit for velocity. Another example is that a client may prefer to use WGS84(G1674) for all geospatial references.

Figure 2 shows an example of a setup process 200 for a consuming party 114 or 116. The setup process includes making a data source subscription to the sharing engine 120. In an embodiment the consuming party client subscribes 202 to data from data providing parties such as providing party 114 or providing party 116. In an embodiment at least one of the authorisation rules is obtained from a providing party. In an embodiment the consuming party client is only able to subscribe 202 to data from providing parties that have authorised the consuming party within that providing party's authorisation rules. The request to subscribe may also specify 204 subscription rules for the consuming party. Examples of subscription rules are provided above.

In an embodiment the consuming party client specifies 204 subscription rules that apply to all clients of the consuming party. In an embodiment the consuming party client specifies 204 subscription rules that apply to a specified subset of clients of the consuming party.

In an embodiment the consuming party client specifies 204 subscription rules that exclude specified attributes from a providing party. In an embodiment the consuming party client specifies 204 subscription rules that exclude specified attributes from all providing parties. In an embodiment the consuming party client specifies 204 subscription rules that include only specified attributes from a providing party. In an embodiment the consuming party client specifies 204 subscription rules that include only specified attributes from all providing parties.

Figure 3 shows an example of a general setup process 300 for a consuming party. In an embodiment a consuming party client specifies 302 at least one transformation rule.

Examples of transformation rules are provided above.

Where the consuming party wishes to receive push delivery of asset data, a consuming party client specifies 304 at least one endpoint for push delivery. Where the consuming party wishes to augment asset data with context data that is not received from at least one tracking system, a consuming party client may load 306 context data into the sharing engine 120.

An example of context data is spatial areas of interest.

Another example of context data is the consuming party contractor identifier associated with the driver identifier used by the providing party. Another example of context data is the consuming party's manager who is accountable for the providing party when operating within the consuming party's operational area.

Another example of context data is the freight loads that a vehicle is carrying.

Where the consuming party wishes to augment asset data with context data that is not received from at least one tracking system a consuming party client may register 308 context data lookup services. Context data lookup services are instructions to the sharing engine 120 to retrieve data from an external data lookup source.

In an embodiment the external data lookup source is a web service.

In an embodiment the external data lookup source is made publicly available. In an embodiment the external data lookup source requires authentication of the sharing engine 120 as an authorised consumer.

In an embodiment the external data lookup source returns a table of data including the lookup key. In an embodiment the external data lookup source accepts the lookup key as a parameter and returns one or more corresponding context attributes. In some circumstances a consuming party comprises an organisation, or is part of an organisation. An administrator client manages 310 additional authorised client accounts within the consuming party.

In an embodiment the administrator client delegates administrator authority to the new client account within the consuming party. In an embodiment the administrator client does not delegate administrator authority to the new client account within the consuming party.

In an embodiment the consuming party manages 312 alerting rules associated to the client. Alerting rules instruct the sharing engine to send a message to one or more nominated recipients when a defined event occurs. An example of a defined event is that an asset has entered a spatial area of interest.

Another example of a defined event is that an asset has begun travelling above a specified speed within a spatial area of interest.

Figure 4 shows an example of a setup process 400 for a providing party, for example providing party 114 or providing party 116. The setup process includes loading and registering context data. The providing party loads 402 context data. Context data is described above.

An example of context data is a description of the asset associated with each asset identifier.

Another example of context data is an asset category associated to an asset identifier. Another example of context data is a driver name associated with each driver identifier.

Another example of context data is a name and telephone number of the supervisor associated with the driver identifier.

Another example of context data is the consuming party's purchase order number under which the asset is being used. The providing party registers 404 context data lookup services. Data lookup services are described above.

In an embodiment the providing party manages 406 alerting rules associated to the providing party. Alerting rules are described above.

Figure 5 shows an example of a setup process 500 for a providing party. The setup process includes registering and defining at least one data source.

The providing party registers 502 at least one data source. In an embodiment the data source includes a tracking system. In an embodiment the data source includes at least one other tracking system. In an embodiment the data source includes at least one tracked asset. In an embodiment the data source includes asset data shared by other parties. In an embodiment the data source is the subscribed data received as a consuming party.

The providing party may define 504 at least one data source authorisation rule that consistently applies to the data source registered in step 502. Data source authorisation rules defined in 504 limit access to data from this data source. In an embodiment a data source authorisation rule defined in 504 limits the consuming parties that may receive data from this data source. In an embodiment a data source authorisation rule defined in 504 limits the attributes that may be shared from this data source.

Data source data attributes are transformed 506 to standard attributes. This allows data providers who have configured a tracking system in a non-standard way to ensure that non-standard attributes from the tracking system are treated as if they were a standard attribute.

An example of data attribute transformation or mapping is where providing party 116 uses tracking system 112 attribute 'user defined field 2' to record the driver name which corresponds to sharing engine 120 standard attribute 'driver name'.

Context data is then associated 508 by specifying zero or more lookups of context data specified by the data providing party 402 and 404.

In an embodiment one or more context data lookups will refer to context data loaded 402. In an embodiment one or more context data lookups will refer to context data lookup services 404. In an embodiment one or more context data lookups will refer to context data loaded 402 and one or more context data lookups will refer to context data lookup services 404.

Figure 6 shows an example of a setup process 600 by a providing party. The setup process includes setting up data sharing definitions. A list of authorised consuming parties is maintained 602. A consuming party will not receive any data from the providing party unless the consuming party is nominated in this list.

Authorisation rules for at least one of the consuming parties are specified 604. Examples of authorisation rules are provided above. In one embodiment an authorisation rule is to provide all data to this consuming party.

In one embodiment a list of authorisation rules is specified.

In one embodiment an authorisation rule grants authority to data matching specified criteria. In one embodiment an authorisation rule grants authority to all data except where the data matches specified criteria. Figure 7 shows an example of a runtime process for event processing. Event processing includes receiving asset data from tracking systems that have followed the register data source process described above with reference to figure 5.

In an embodiment at least one event is received 702 from a data source such as tracking system 110 or tracking system 112. The asset data is sent via at least one push notification and received by the sharing engine 120. In an embodiment at least one event is received 704 from a data source such as tracking system 110 or tracking system 112. The asset data is transmitted from the tracking system in response to a query or request to the tracking system from the sharing engine 120. Each event is processed 706 as will be described below. Figure 8 shows an example of a technique for processing an event 706.

Data source attributes are transformed 802 to standard attributes. In an embodiment this transformation includes transformation to the standard representation of attributes used within the sharing engine 120. In an embodiment one or more attributes from the data source do not need to be transformed because they already adhere to the standard representation of attributes used within the sharing engine 120.

In an embodiment the transformation involves applying providing party data source data attribute transformation rules specified in 506.

Providing party context data is associated 804. If 806 an event matches at least one providing party alerting rule then the providing party nominated recipients are sent 808 an alert.

In an embodiment the providing party has associated data source authorisation rules. These authorisation rules are applied 810.

Each of the nominated consuming parties 602 are then processed for this event 812. This process is further described with reference to figure 9.

Figure 9 shows an example of a process consuming party event 812 from figure 8.

An event is checked 900 to determine whether it matches authorisation rules for this consuming party 604. If not, no action is taken 902. If there is a match the attributes for this consuming party are transformed 904 from the standard internal representation used by the sharing engine 120 to the representation specified in the consuming party transformation rules 302.

In an embodiment no transformation is required because the consuming party elected to transform to the same representation as the standard internal representation used by the sharing engine 120. In an embodiment one or more attributes are transformed and one or more attributes are not transformed. Consuming party context data is associated 906 according to rules defined in 306 and 308.

Consuming party subscription rules that apply to all clients for the consuming party are applied 908 according to rules defined in 204. If 910 an event matches consuming party alerting rules then the consuming party nominated recipients are sent 912 an alert.

The event is published 914 for the consuming party.

The event is queued 916 for push delivery to the consuming party.

The active spatial UI clients associated to the consuming parties are processed 918. This process is further described with reference to figure 10.

Figure 10 shows an example of a process spatial UI client 918 from figure 9.

An event is checked 1000 to determine whether it matches subscription rules that apply to this client 204. If not, not action is taken 1002. If there is a match the event is pushed 1004 to the consuming party client. Figure 11 shows an example of the process that picks up queued events from 916 to push to a consuming party's push delivery endpoint specified in 304.

In an embodiment the process repeats while there are items in the queue for delivery.

The oldest item is picked 1100 from the queue for delivery, where there is no indicator that the consuming party has a delivery in process, or such indicator calls for retry and retry time has been reached.

An indicator is added 1102 that a consuming party has a delivery in process.

A message is prepared 1104 containing at least some of the items in the queue for the consuming party. In an embodiment, message preparation selects a subset of items based on consuming party subscription rules 204. An example of a consuming party subscription rule is to include a maximum of 20 items per message. Another example of a consuming party subscription rule is to only include the most recent queued location event per asset.

The prepared message is pushed 1106 to the consuming party's push delivery endpoint 304. If 1108 the message was sent successfully then the items are cleared 1110 from the queue, and the indicator that the consuming party has a delivery in process is removed 1112.

If the message was not sent successfully then the consuming party indicator is changed 1114 to indicate that a retry is needed. In an embodiment the retry is also scheduled.

Figure 12 shows an embodiment of a suitable computing device to implement embodiments of one or more of the systems and methods disclosed above, such as the tracking system 110, tracking system 112, sharing engine 120, client 150, client 152, and/or client 154. The computing device of Figure 12 is an example of a suitable computing device. It is not intended to suggest any limitation as to the scope of use or functionality of the operating environment.

Example computing devices include, but are not limited to, personal computers, server computers, hand-held or laptop devices, mobile devices, multiprocessor systems, consumer electronics, mini computers, mainframe computers, and distributed computing environments that include any of the above systems or devices. Examples of mobile devices include mobile phones, tablets, and Personal Digital Assistants (PDAs).

Although not required, embodiments are described in the general context of 'computer readable instructions' being executed by one or more computing devices. In an embodiment, computer readable instructions are distributed via tangible computer readable media.

In an embodiment, computer readable instructions are implemented as program modules. Examples of program modules include functions, objects, Application

Programming Interfaces (APIs), and data structures that perform particular tasks or implement particular abstract data types. Typically, the functionality of the computer readable instructions is combined or distributed as desired in various environments.

Shown in figure 12 is a system 1200 comprising a computing device 1205 configured to implement one or more embodiments described above. In an embodiment, computing device 1205 includes at least one processing unit 1210 and memory 1215. Depending on the exact configuration and type of computing device, memory 1215 is volatile (such as RAM, for example), non-volatile (such as ROM, flash memory, etc., for example) or some combination of the two.

A server 1220 is shown by a dashed line notionally grouping processing unit 1210 and memory 1215 together. In an embodiment, computing device 1205 includes additional features and/or functionality.

One example is removable and/or non-removable additional storage including, but not limited to, magnetic storage and optical storage. Such additional storage is illustrated in Figure 12 as storage 1225. In an embodiment, computer readable instructions to implement one or more embodiments provided herein are maintained in storage 1225. In an embodiment, storage 1225 stores other computer readable instructions to implement an operating system and/or an application program. Computer readable instructions are loaded into memory 1215 for execution by processing unit 1210, for example.

Memory 1215 and storage 1225 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 1205. Any such computer storage media may be part of device 1205.

In an embodiment, computing device 1205 includes at least one communication connection 1240 that allows device 1205 to communicate with other devices. The at least one communication connection 1240 includes one or more of a modem, a Network Interface Card (NIC), an integrated network interface, a radio frequency

transmitter/receiver, an infrared port, a USB connection, or other interfaces for connecting computing device 1205 to other computing devices.

In an embodiment, the communication connection(s) 1240 facilitate a wired connection, a wireless connection, or a combination of wired and wireless connections.

Communication connection(s) 1240 transmit and/or receive communication media.

Communication media typically embodies computer readable instructions or other data in a "modulated data signal" such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" includes a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.

In an embodiment, device 1205 includes at least one input device 1245 such as keyboard, mouse, pen, voice input device, touch input device, infrared cameras, video input devices, and/or any other input device. In an embodiment, device 1205 includes at least one output device 1250 such as one or more displays, speakers, printers, and/or any other output device.

Input device(s) 1245 and output device(s) 1250 are connected to device 1205 via a wired connection, wireless connection, or any combination thereof. In an embodiment, an input device or an output device from another computing device is/are used as input device(s) 1245 or output device(s) 1250 for computing device 1205.

In an embodiment, components of computing device 1205 are connected by various interconnects, such as a bus. Such interconnects include one or more of a Peripheral Component Interconnect (PCI), such as PCI Express, a Universal Serial Bus (USB), firewire (IEEE 13104), and an optical bus structure. In an embodiment, components of computing device 1205 are interconnected by a network. For example, memory 1215 in an embodiment comprises multiple physical memory units located in different physical locations interconnected by a network.

It will be appreciated that storage devices used to store computer readable instructions may be distributed across a network. For example, in an embodiment, a computing device 1255 accessible via a network 1260 stores computer readable instructions to implement one or more embodiments provided herein. Computing device 1205 accesses computing device 1255 in an embodiment and downloads a part or all of the computer readable instructions for execution. Alternatively, computing device 1205 downloads portions of the computer readable instructions, as needed. In an embodiment, some instructions are executed at computing device 1205 and some at computing device 1255.

A client application 1285 enables a user experience and user interface. In an

embodiment, the client application 1285 is provided as a thin client application configured to run within a web browser. The client application 1285 is shown in figure 12 associated to computing device 1255. It will be appreciated that application 1285 in an embodiment is associated to computing device 1205 or another computing device.

In an embodiment the client application 1285 provides data access reporting and/or a spatial user interface for a human operator. In an embodiment the client application 1285 is configured to present asset data associated to geographic data, for example plotting representations of assets on a spatial map.

The foregoing description of the invention includes preferred forms thereof. Modifications may be made thereto without departing from the scope of the invention.

Claims

1. A method of sharing tracked asset data comprising : receiving asset data obtained from at least one asset tracking system, the asset data associated to at least one tracked asset; applying at least one first transformation rule to a set of disparate attributes associated to the asset data to derive a set of standard asset data attributes; applying at least one authorisation rule to the asset data; and exposing at least one subset of the asset data to at least one client according to the at least one authorisation rule. 2. The method of claim 1 wherein the asset data includes at least one asset data packet, the at least one asset data packet including a score representing the current alertness of the person to which the tracked asset is associated.

3. The method of claim 2 wherein the asset data packet includes at least one predicted future alertness score of the person to which the tracked asset is associated. 4. The method of claim 2 wherein the asset data packet includes an alertness scale.

5. The method of claim 1 wherein the asset data includes at least one asset data packet, the at least one asset data packet including a score representing the current level of heat stress of the person to which the tracked asset is associated.

6. The method of claim 5 wherein the asset data packet includes a heat stress scale. 7. The method of any one of the preceding claims wherein the at least one

authorisation rule is configured to expose the at least one subset of the asset data if a location associated to the at least one tracked asset is within a predefined operational area .

8. The method of any one of the preceding claims wherein the at least one

authorisation rule is configured not to expose the at least one subset of the asset data if a location associated to the at least one tracked asset is within a predefined personal use area .

9. The method of claim 8 further comprising receiving asset data associated to the predefined personal use area.

10. The method of claim 9 wherein at least some of the asset data associated to the predefined personal use area is received from at least one providing party.

11. The method of claim 1 further comprising receiving the at least one authorisation rule from the at least one providing party. 12. The method of any one of the preceding claims further comprising : applying at least one second transformation rule to the asset data to transform at least some of the set of standard asset data attributes associated to the asset data to a set of client-centric asset data attributes.

13. The method of claim 12 further comprising selecting the at least one second transformation rule from a plurality of available second transformation rules based at least partly on at least one client preference.

14. The method of any one of the preceding claims further comprising : applying at least one subscription rule to the asset data; and exposing the at least one subset of the asset data to the at least one client according to the at least one subscription rule.

15. The method of claim 14 further comprising selecting the at least one subscription rule from a plurality of available subscription rules based at least partly on at least one client preference.

16. The method of any one of the preceding claims wherein the asset data is received from at least one tracking system associated to the at least one tracked asset.

17. The method of claim 16 wherein the asset data is received from a first tracking system associated to a first tracked asset and a second tracking system associated to a second tracked asset.

18. The method of claim 17 wherein the first tracking system and/or the second tracking system is/are associated to a plurality of tracked assets.

19. The method of any one of claims 16 to 18 wherein the asset data is received from the at least one tracking system in response to a request to the at least one tracking system.

20. The method of claim 19 wherein the asset data is received from the at least one tracking system via at least one push notification.

21. The method of any one of claims 16 to 20 wherein the at least one tracking system is physically separated from the at least one tracked asset.

22. The method of any one of the preceding claims wherein the at least one subset of the asset data is exposed to the at least one client in response to a client request.

23. The method of any one of the preceding claims wherein the at least one subset of the asset data is exposed to the at least one client via at least one push notification.

24. A sharing system for tracked asset data comprising : a sharing engine configured to receive asset data obtained from at least one asset tracking system, the asset data associated to at least one tracked asset; the sharing engine comprising : a transformation engine configured to apply at least one first transformation rule to a set of disparate attributes associated to the asset data to derive a set of standard asset data attributes, and an authorisation engine configured to apply at least one authorisation rule to the asset data; the sharing engine further configured to expose at least one subset of the asset data to at least one client according to the at least one authorisation rule.

25. The system of claim 24 wherein the asset data includes at least one asset data packet, the at least one asset data packet including a score representing the current alertness of the person to which the tracked asset is associated.

26. The system of claim 25 wherein the asset data packet includes at least one predicted future alertness score of the person to which the tracked asset is associated.

27. The system of claim 25 wherein the asset data packet includes an alertness scale.

28. The system of claim 24 wherein the asset data includes at least one asset data packet, the at least one asset data packet including a score representing the current level of heat stress of the person to which the tracked asset is associated.

29. The system of claim 28 wherein the asset data packet includes a heat stress scale.

30. The system of any one of claims 24 to 29 wherein the at least one authorisation rule is configured to expose the at least one subset of the asset data if a location associated to the at least one tracked asset is within a predefined operational area.

31. The system of any one of claims 24 to 30 wherein the at least one authorisation rule is configured not to expose the at least one subset of the asset data if a location associated to the at least one tracked asset is within a predefined personal use area.

32. The system of claim 31 further configured to receive asset data associated to the predefined personal use area.

33. The system of claim 32 wherein at least some of the asset data associated to the predefined personal use area is received from at least one providing party.

34. The system of claim 24 further configured to receive the at least one authorisation rule from the at least one providing party.

35. The system of any one of claims 24 to 34 wherein the transformation engine is further configured to apply at least one second transformation rule to the asset data to transform at least some of the set of standard asset data attributes associated to the asset data to a set of client-centric asset data attributes.

36. The system of claim 35 wherein the transformation engine is further configured to select the at least one second transformation rule from a plurality of available second transformation rules based at least partly on at least one client preference. 37. The system of any one of claims 24 to 36 further comprising a subscription engine configured to: apply at least one subscription rule to the asset data; and expose the at least one subset of the asset data to the at least one client according to the at least one subscription rule. 38. The system of claim 37 wherein the subscription engine is further configured to select the at least one subscription rule from a plurality of available subscription rules based at least partly on at least one client preference.

39. The system of any one of claims 24 to 38 wherein the asset data is received from at least one tracking system associated to the at least one tracked asset.

40. The system of claim 39 wherein the asset data is received from a first tracking system associated to a first tracked asset and a second tracking system associated to a second tracked asset.

41. The system of claim 40 wherein the first tracking system and/or the second tracking system is/are associated to a plurality of tracked assets.

42. The system of any one of claims 39 to 41 wherein the asset data is received from the at least one tracking system in response to a request to the at least one tracking system.

43. The system of claim 42 wherein the asset data is received from the at least one tracking system via at least one push notification.

44. The system of any one of claims 39 to 43 wherein the at least one tracking system is physically separated from the at least one tracked asset.

45. The system of any one of claims 24 to 44 wherein the at least one subset of the asset data is exposed to the at least one client in response to a client request. 46. The system of any one of claims 24 to 45 wherein the at least one subset of the asset data is exposed to the at least one client via at least one push notification.

47. A computer-readable medium having stored thereon computer-executable instructions that, when executed by a processor, cause the processor to perform a method of sharing tracked asset data, the method comprising : receiving asset data obtained from at least one asset tracking system, the asset data associated to at least one tracked asset; applying at least one first transformation rule to a set of disparate attributes associated to the asset data to derive a set of standard asset data attributes; applying at least one authorisation rule to the asset data; and exposing at least one subset of the asset data to at least one client according to the at least one authorisation rule.

48. The computer-readable medium of claim 47 wherein the asset data includes at least one asset data packet, the at least one asset data packet including a score representing the current alertness of the person to which the tracked asset is associated.

49. The computer-readable medium of claim 48 wherein the asset data packet includes at least one predicted future alertness score of the person to which the tracked asset is associated.

50. The computer-readable medium of claim 48 wherein the asset data packet includes an alertness scale.

51. The computer-readable medium of claim 47 wherein the asset data includes at least one asset data packet, the at least one asset data packet including a score representing the current level of heat stress of the person to which the tracked asset is associated. 52. The computer-readable medium of claim 51 wherein the asset data packet includes a heat stress scale.

53. The computer-readable medium of any one of claims 47 to 52 wherein the at least one authorisation rule is configured to expose the at least one subset of the asset data if a location associated to the at least one tracked asset is within a predefined operational area .

54. The computer-readable medium of any one of claims 47 to 53 wherein the at least one authorisation rule is configured not to expose the at least one subset of the asset data if a location associated to the at least one tracked asset is within a predefined personal use area. 55. The computer-readable medium of claim 54, the method further comprising receiving asset data associated to the predefined personal use area.

56. The computer-readable medium of claim 55 wherein at least some of the asset data associated to the predefined personal use area is received from at least one providing party. 57. The computer-readable medium of claim 47, the method further comprising receiving the at least one authorisation rule from the at least one providing party.

58. The computer-readable medium of any one of claims 47 to 57, the method further comprising : applying at least one second transformation rule to the asset data to transform at least some of the set of standard asset data attributes associated to the asset data to a set of client-centric asset data attributes.

59. The computer-readable medium of claim 58, the method further comprising selecting the at least one second transformation rule from a plurality of available second transformation rules based at least partly on at least one client preference.

60. The computer-readable medium of any one of claims 47 to 59, the method further comprising : applying at least one subscription rule to the asset data; and exposing the at least one subset of the asset data to the at least one client according to the at least one subscription rule.

61. The computer-readable medium of claim 60, the method further comprising selecting the at least one subscription rule from a plurality of available subscription rules based at least partly on at least one client preference.

62. The computer-readable medium of any one of claims 47 to 61 wherein the asset data is received from at least one tracking system associated to the at least one tracked asset. 63. The computer-readable medium of claim 62 wherein the asset data is received from a first tracking system associated to a first tracked asset and a second tracking system associated to a second tracked asset.

64. The computer-readable medium of claim 63 wherein the first tracking system and/or the second tracking system is/are associated to a plurality of tracked assets. 65. The computer-readable medium of any one of claims 62 to 64 wherein the asset data is received from the at least one tracking system in response to a request to the at least one tracking system.

65. The computer-readable medium of claim 65 wherein the asset data is received from the at least one tracking system via at least one push notification. 66. The computer-readable medium of any one of claims 62 to 66 wherein the at least one tracking system is physically separated from the at least one tracked asset.

67. The computer-readable medium of any one of claims 47 to 66 wherein the at least one subset of the asset data is exposed to the at least one client in response to a client request.

68. The computer-readable medium of any one of claims 47 to 67 wherein the at least one subset of the asset data is exposed to the at least one client via at least one push notification.

70. A sharing system for tracked asset data comprising : at least one storage device; and at least one processor programmed to: receive asset data obtained from at least one asset tracking system, the asset data associated to at least one tracked asset, apply at least one first transformation rule to a set of disparate attributes associated to the asset data to derive a set of standard asset data attributes, apply at least one authorisation rule to the asset data, and expose at least one subset of the asset data to at least one client according to the at least one authorisation rule.