WO2018002672A1

WO2018002672A1 - Content management system

Info

Publication number: WO2018002672A1
Application number: PCT/GB2017/051950
Authority: WO
Inventors: David John Cox; David Paul DINGLE; Peter Stuart GODMAN
Original assignee: Mtk Ip Ltd
Priority date: 2016-06-30
Filing date: 2017-06-30
Publication date: 2018-01-04
Also published as: GB2555511A; GB201710575D0; GB201710576D0; GB2555512A; GB201710577D0; GB2561621A

Abstract

A security system for permitting access to data over a network, comprising: a database for storing data, the data having associated with it distribution rights; a device connectable to a network for receiving: a request from a user to access the data; and information regarding the identity of the user; a first rules engine for outputting a position of the user in a hierarchy of permissions for accessing the data; and a second rules engine for outputting access permissions in dependence on the distribution rights; wherein the security system permits the user to access the data in dependence on the outputs of both the first and second rules engines.

Description

Content management system

This invention relates to a content and data management system and corresponding method. Aspects of the present invention also relate to methods and systems for controlling website development and publication in a multi-tenant environment. Further aspects of the present invention relate to methods and systems for controlling data access. A platform for integrating the various aspects of the invention is also provided.

The traditional approach to website uniformity and content management within a group of related organisations has been to produce a website template, which each member of the group can edit to produce their own website and associated content. An example of such a group is a collection of car dealerships operating with the approval of a car manufacturer. The manufacturer may want the approved dealers to follow a particular template website design, which may include particular logos and functions relating to the manufacturer, in order to provide a consistent user experience across its dealerships. Therefore, the manufacturer may provide the dealerships with an editable template from which to create their individual websites.

Each member of the group can edit the template to produce a tailored website specific to their needs yet consistent with the overall group format, look and branding. For example, the group member may require that their website display that group member's particular contact details, or particular stock that that group member has available.

Over time, such an approach can lead to a divergence in the content and aesthetics of a related group of websites as each member of the group may edit and modify the original template in a different way. Eventually, the visual and content consistency between members of the group may be reduced. In the example of a group of car dealerships, this may lead to an adverse effect on the brand image of the dealership group.

It is an aim of certain aspects of the invention to at least alleviate these problems, and at least one aspect proposes a system and method for managing content and data that provides improved content control.

According to a first aspect of the invention, there is provided a security system for permitting access to data over a network, comprising : a database for storing data, the data having associated with it distribution rights; a device connectable to a network for receiving: a request from a user to access the data; and information regarding the identity of the user; a first rules engine (for example, iCHS) for outputting a position of the user in a hierarchy of permissions for accessing the data; and a second rules engine (for example, iDPS) for outputting access permissions in dependence on the distribution rights; wherein the security system permits the user to access the data in dependence on the outputs of both the first and second rules engines.

Preferably, the first rules engine is adapted to output access permissions in dependence on the position of the user in a hierarchy of permissions. Preferably, the security system permits the user to access the data in dependence on the access permissions output by both the first and second rules engines.

Preferably, the second rules engine outputs access permissions in dependence on the request. Preferably, the second rules engine outputs access permissions in dependence on the information regarding the identity of the user.

Preferably, the first rules engine is adapted to tag the request and/or the data with the hierarchy of permissions. Preferably, the second rules engine is adapted to tag the request and/or the data with the access permissions.

Preferably, the first rules engine is adapted to interrogate the second rules engine to request access permissions from the second rules engine. Preferably, the second rules engine is adapted to interrogate the first rules engine to request the position of the user in a hierarchy of permissions for accessing the data from the second rules engine.

Preferably, the first rules engine is adapted to interrogate the second rules engine in dependence on the request. Preferably, the second rules engine is adapted to interrogate the first rules engine in dependence on the request.

Preferably, the first rules engine is adapted to forward the request on to the second rules engine and/or vice versa.

Preferably, the first rules engine and/or the second rules engine are logically connected to the database. Preferably, rules governing operation of the first rules engine and/or the second rules engine are stored in the database.

Preferably, the position of the user in the hierarchy is allocated in dependence on at least one of: a user location ; a user language; a user business arrangement or position within a company / group structure; a user brand; a predefined user group; a relationship between the user and the data (for example, an owner); and information regarding the identity of the user.

Preferably, the access permissions are determined in dependence at least one of: where said data was created; where said data is stored; where the data is to be accessed; where the request for the data was made ; where the request for the data was received; where the owner of the data is located; whether the data is attributable to an individual; and information regarding the identity of the user.

Preferably, the hierarchy of permissions is configured to provide hierarchical inheritance of permissions so long as inheritance of a permission is not denied at a level of the hierarchy that is above the user, preferably wherein the hierarchy of permissions is a cascading hierarchy of permissions.

Preferably, access to data comprises viewing access, reproduction access, publication access and/or editing access of data.

Preferably, the hierarchy of permissions is configured to provide hierarchical inheritance of edited data, and preferably to necessitate inheritance of such edited data.

Preferably, the data is in the form of: data associated with at least one vehicle (for example, telemetric data) ; a website; content for a website (for example, inventory / stock data, media, pods (preferably, herein also referred to as "components" or "website components", components and programs); and a report including aggregated and/or manipulated data.

Preferably, the information regarding the identity of the user comprises: a user account, preferably accessible via a process of authentication, to which user identity information is associated; and/or information regarding the type and location of a device through which the user request access the data. Preferably, the system further comprises a processor for instructing the sequence in which the first and second rules engines are interrogated, so as to determining access permissions, in dependence on the data and/or the request, and preferably the type of data requested.

Preferably, the system is configured to provide access to data to which the user is permitted in the event that the first and/or second rules engines determine insufficient access permissions for the requested data. Preferably, the device connectable to the network is adapted to receive requests from a service, module, application and/or device.

Preferably, the device connectable to the network is adapted to receive simultaneous requests from at least one service, module, application and/or device.

According to another aspect of the invention there is provided a method of rendering a website using the system as described above.

According to another aspect of the invention there is provided a method of enabling users to access and/or edit content, the method comprising : determining a user identity and/or determining origin information associated with a user; and providing hierarchical information relating to said user based on the user identity and/or origin information associated with the user thereby to enable the user to access and/or edit content in dependence on said hierarchical information.

Preferably, the user is enabled to access and/or edit content provided over a computer network, preferably over the internet.

Preferably, the hierarchical information comprises a user position within a hierarchy comprising a plurality of hierarchical nodes.

Preferably, the user position within the hierarchy is determined by at least one of: a user location ; a user language; a user business arrangement; a user brand; and a user group.

Preferably, a user is associated with one or more user languages; user business arrangements; user brands; and/or user groups.

Preferably, content edited by the user is automatically applied to content relating to one or more hierarchical nodes below the user position in the hierarchy.

Preferably, content edited by the user is restricted from being edited at one or more of the one or more hierarchical nodes below the user position in the hierarchy. Preferably, the content edited by the user requires authorisation by a hierarchical node above the user position in the hierarchy.

Preferably, the hierarchical information is used to determine a user permission associated with the user. Preferably, the user permission is a permission to edit content.

Preferably, the user permission is a permission to access content.

Preferably, a user permission is automatically applied to all users at and below the one or more hierarchical nodes the point within the hierarchy at which a user permission is applied.

Preferably, a first user permission conflicts with a second user permission provided at a node below the first user permission, the first user permission overrides the user permission.

Preferably, the user permission is assigned by a hierarchical node above the position of the user in the hierarchy.

Preferably, the method further comprising the step of authenticating and/or authorising the user identity. Preferably, the content comprises elements of a website page.

Preferably, the elements of the website page comprises components, wherein each pod comprises one or more of pod elements.

Preferably, the step of determining a user identity is performed by a processor, preferably as part of a server.

Preferably, the step of determining origin information is performed by a processor, preferably as part of a server.

Preferably, the hierarchical information is provided by a database storing the hierarchical information, preferably as part of a server.

According to another aspect of the invention , there is provided a method of rendering a website, the method comprising: requesting a website page; determining origin information associated with the request; providing a content hierarchy for the requested page based on the origin information ; and rendering the requested page in dependence on the content hierarchy.

Preferably, the step of providing a content hierarchy for the requested page based on the origin information comprises determining a position of the requested website page within a hierarchy comprising a plurality of hierarchical nodes.

Preferably, the content hierarchy is a cascading content hierarchy, and more preferably cascading up and/or down the hierarchy. Preferably, the content hierarchy comprises inherited access permissions. Preferably, the content hierarchy comprises a list of one or more components and the relative positions of the one or more components on the website page.

Preferably, the method further comprises arranging the one or more components relative to one another.

Preferably, the relative positions of the one or more components are determined by a device type of the device from which the request originates.

Preferably, the method further comprised the step of retrieving the one or more components from a pod service. Preferably, the pod retrieval occurs asynchronously.

Preferably, the website page is rendered in accordance with the content hierarchy.

Preferably, the content is accessed and edited in accordance with a method as described above and/or by means of a system as described above.

According to another aspect of the invention, there is provided a method of controlling data requests in a multi-tenant platform, the method comprising : determining origin information associated with a data request; determining user information associated with the data request; and providing hierarchical information relating to said data request.

Preferably, the origin information comprises at least one of: a request location; a request language; a requesting device type; and an identity of the user from whom the request originated.

Preferably, the method further comprising determining permissions associated with the user.

Preferably, the permissions are determined by a position in a hierarchy from which the data request originates.

Preferably, the permissions are inherited from parent nodes within the hierarchy.

Preferably, the permissions cascade within the hierarchy, and preferably both up and down the hierarchy. According to another aspect of the invention there is provided a security system for permitting access to data over a network, comprising: a database for storing data; a device connectable to a network for receiving: a request from a user to access the data; and information regarding the identity of the user; a rules engine (for example, iCHS) for outputting access permissions in dependence on a position of the user in a hierarchy of permissions for accessing the data; and wherein the security system permits the user to access the data in dependence on the output of the rules engine.

Preferably, the aforementioned system is adapted to implement the method as described above, wherein the rules engine is the first rules engine.

According to yet another aspect of the invention, there is provided a security method for permitting access to data over a network, comprising : providing a database for storing data; receiving at a device connectable to a network: a request from a user to access the data; and information regarding the identity of the user; outputting, by means of a rule engine, access permissions in dependence on a position of the user in a hierarchy of permissions for accessing the data; and permitting the user to access the data in dependence on the output of the rules engine.

According to another aspect of the invention there is provided a method of rendering a website according to the method described above.

According to a further aspect of the invention, there is provided a security method of permitting access to data over a network, comprising: providing a database for storing data, the data having associated with it distribution rights; receiving, at a device connectable to a network: a request from a user to access the data; and information regarding the identity of the user; outputting, by means of a first rules engine, a position of the user in a hierarchy of permissions for accessing the data; and outputting, by means of a second rules engine, access permissions in dependence on the distribution rights and/or the request; permitting the user to access the data in dependence on the outputs of both the first and second rules engines.

Preferably, the method includes using a system as described above.

According to another aspect of the invention, there is provided a system of rendering a website comprising : means for requesting a website page; means for determining origin information associated with the request; means for providing a content hierarchy for the requested page based on the origin information; and means for rendering the requested page in dependence on the content hierarchy.

According to another aspect of the invention, there is provided a system of rendering a website implementing the system described above.

According to another aspect of the invention, there is provided a web server adapted to implement a method as described above.

According to yet another aspect of the invention, there is provided a computer program product comprising software code adapted, when executed, to perform a method as described above.

Preferably, there is provided a system substantially as herein described and/or as illustrated in the accompanying drawings.

Preferably, there is provided a method substantially as herein described and/or as illustrated in the accompanying drawings.

According to another aspect of the invention, there is provided an authorisation system for permitting access to data over a network, comprising : a database for storing data, the data having associated with it distribution rights; a device connectable to a network for receiving: a request from a user to access the data; and information regarding the identity of the user; a rules engine for outputting access permissions in dependence on the distribution rights; wherein the authorisation system permits the user to access the data in dependence on the output of the rules engines.

Preferably, the rules engine is adapted to output access permissions in dependence on the request. Preferably, the rules engine is adapted to output access permissions in dependence on the information regarding the identity of the user. Preferably, the rules engine is adapted to tag the request and/or data with access permissions.

Preferably, the access permissions are determined in dependence on at least one of: where said data was created; where said data is stored; where the data is to be accessed; where the request for the data was made ; where the request for the data was received; where the owner of the data is located ; and whether the data is attributable to an individual.

Preferably, access to data comprises viewing access, publication access, reproduction access and/or editing access of vehicle data.

Preferably, the data is in the form of: data associated with at least one vehicle (for example, telemetric data) ; inventory / stock; commercial data; and a report including aggregated and/or manipulated data.

Preferably, the information regarding the identity of the user comprises: a user account, preferably accessible via a process of authentication, to which user identity information is associated; a vehicle identifier to which a user is associated; and/or information regarding the type and location of a device through which the user request access the data.

Preferably, the system is configured to provide access to data to which the user is permitted when the rules engine determines insufficient access permissions for the requested data.

According to another aspect of the invention, there is provided an authorisation method for permitting access to data over a network, comprising : providing a database for storing data having associated with it distribution rights; receiving at a device connectable to a network: a request from a user to access the data; and information regarding the identity of the user; outputting, by means of a rules engine (for example, iDPS), access permissions in dependence on the distribution rights; and wherein the authorisation system permits the user to access the data in dependence on the output of the rules engines.

According to another aspect of the invention, there is provided a method as described above using a system as described above.

According to another aspect of the invention, there is provided a method of controlling the transfer of vehicle data in different geographic locations, the method comprising: determining a geographic location associated with a request for data; checking permissions applicable to the transfer of said requested data from or to said determined geographic location ; and responding to said request according to said applicable permission.

Preferably, responding to said request comprises transmitting said requested data when said applicable permission permits said transfer of data from or to said determined geographic location, preferably wherein the data is transmitted from a server.

Preferably, responding to said request comprises preventing transmission of said requested data when said applicable permission does not permits transfer of data from or to said determined geographic location. Preferably, the vehicle data is tagged with metadata indicating the permissions applicable to said vehicle data.

Preferably, the geographical location information comprises information indicating the geographical location where said data was created.

Preferably, the geographical location information comprises information indicating the location where said requested data is stored.

Preferably, the geographical location information comprises information indicating the location where the request for data was received.

Preferably, the geographical location information comprises information indicating the location from which said request for data originated.

Preferably, the geographical location information comprises information indicating the location of the owner of the requested data.

Preferably, the permissions are further determined from a position within a hierarchy from which the request originates.

Preferably, the hierarchy comprises at least one of: one or more vehicle dealerships; one or more vehicle dealership groups; one or more regions; one or markets; one or more manufacturers; or a member of the public.

Preferably, the responding to said request further comprises manipulating said requested data, before transmitting said requested data, in dependence on said applicable permission.

Preferably, manipulating said requested data comprises filtering said requested data so as to remove data for which the applicable permission does not permit transmission of the requested data and/or anonymising said requested data. Preferably, the vehicle data is aggregated from a plurality of sources, and preferably from a plurality of vehicles.

Preferably, the vehicle data is aggregated by means of machine learning.

Preferably, the request for data is a request for transmission of the requested data between devices across a network.

Preferably, the authorisation system is arranged to control the transfer of vehicle data according to a method as described above.

According to another aspect of the invention, there is provided a system of controlling the transfer of vehicle data in different geographic locations, the system comprising : means for receiving a request for access to data, preferably over a network; means for determining information associated with the requested data; means for checking permissions applicable to the request; and means for providing the data in response to the request in dependence upon said applicable permission, preferably over a network.

Preferably, the means for providing the data is adapted to transmit said requested data when said applicable permission permits said transfer of data from or to said determined geographic location .

Preferably, the vehicle data is tagged with metadata indicating the permissions applicable to said vehicle data.

Preferably, the geographical location information comprises at least one of information indicating the geographical location where: said data was created; said data is stored ; the request for data was received; and where said request for data originated.

According to another aspect of the invention , there is provided a method for controlling access to data, the method comprising : receiving a request for access to data; determining information associated with the requested data; checking permissions applicable to the request; and responding to said request according to said applicable permission.

Preferably, the information relates to at least one of: the creation of the data; the location where the data was created; the location where the data is stored; the ownership of the data; and the data format.

Preferably, the permissions are determined based on the information associated with the requested data. Preferably, the permissions are determined based on at least one of: a position within a hierarchy from which the request originates; the location from which the request originates; the location where the data is stored; the data ownership; and the data format.

Preferably, the request for access to data comprises identity information associated with a user from whom the request originates and/or geographic information of the location from which the request originates. Preferably, the step of responding to the request comprises retrieving the data from a database.

Preferably, the data includes telemetry data collected from a vehicle. Preferably, the data comprises aggregated and/or anonymised data. Preferably, the request for access to the data is recorded for reference.

Preferably, the request is a request for transmission of the data across a network.

Preferably, the response comprises the transmission of data across the network.

According to another aspect of the invention, there is provided a system for controlling access to data, the system comprising: means for receiving a request for access to data; means for determining information associated with the requested data; means for checking permissions applicable to the request; and means for providing the data in response to the request in dependence upon said applicable permission.

According to another aspect of the invention , there is provided a web server adapted to implement a method as described above.

According to a further aspect of the invention there is provided a computer program comprising software code adapted when executed to perform a method as described above.

According to another aspect of the invention, there is provided a method for configuring the settings of a vehicle, comprising : storing on a memory one or more first vehicle settings configured for a user in relation to a first vehicle ; accessing a database containing vehicle parameters pertaining to a plurality of vehicles, including said first vehicle and a second vehicle; and translating one or more of said first vehicle settings into one or more corresponding second vehicle settings for said second vehicle by analysing said first vehicle settings against parameters of the first vehicle thereby to determine corresponding said one or more vehicle settings for said second vehicle based on parameters of the second vehicle.

Preferably, the method further comprises establishing a data connection with a computing device of said second vehicle, and applying said second vehicle settings to said second vehicle.

Preferably, the method further comprises accessing said computing device of said second vehicle via said established data connection .

Preferably, said computing device is connected to the engine management system (EMS) of said second vehicle.

Preferably, the method further comprises configuring one or more vehicle settings of said second vehicle by applying the second vehicle settings thereby to correspond with said one or more first vehicle settings stored on said memory

Preferably, the method further comprises storing on said memory at least one profile containing said one or more first vehicle settings, preferably wherein said memory is arranged to store multiple profiles, for example wherein each profile contains one or more vehicle settings relating to a particular vehicle.

Preferably, the method further comprises identifying the second vehicle to which second vehicle settings corresponding to the first vehicle settings are to be applied prior to accessing said database.

Preferably, said identifying further comprises receiving a request for one or more of said first vehicle settings to be applied to said second vehicle.

Preferably, the method further comprises creating a further profile containing said determined second vehicle settings, and storing said further profile on the memory so as to have it available for future use. Preferably, said profile relating to the first vehicle does not contain one or more vehicle settings configured for said user in relation to said second vehicle.

Preferably, analysing said first vehicle settings further comprises using the first vehicle parameters to standardise said first vehicle settings into values or units that can be applied to the second vehicle parameters, for example SOI units.

Preferably, the one or more vehicle settings are stored in the memory in a standard data format.

Preferably, the method further comprises translating the one or more vehicle settings for the designated vehicle into a format compatible with the designated vehicle.

Preferably, a machine learning algorithm is configured to learn said first vehicle settings configured for the user in relation to the first vehicle. In this way, the system may learn configurations and extrapolate them rather than having to incorporate a look-up of predetermined calculated positions. For example, the machine learning may be adapted to use crowd-sourced data for machine learning.

Preferably, translating one or more first vehicle settings further comprises using the machine learning algorithm to predict one or more of said corresponding second vehicle settings.

Preferably, the method further comprising receiving feedback from the (or a) user of the second vehicle to which the second vehicle settings have been applied so as to improve the translating of one or more vehicle settings.

Preferably, the feedback includes adjustments to the second vehicle settings made by the user when using the second vehicle.

Preferably, the vehicle settings include settings configured to control vehicle dynamics of the second vehicle, for example to restrict the performance of said second vehicle.

Preferably, the vehicle settings comprise telemetry settings. Preferably, the vehicle settings comprises settings relating to the gear ratio of the vehicle's engine.

Preferably, the vehicle settings comprises settings relating to the sensitivity of one or more vehicle controls, for example the throttle, steering, braking or suspension .

Preferably, the vehicle settings comprises in car entertainment (ICE) settings.

Preferably, the method further comprising selecting the vehicle settings for the second vehicle from a plurality of selectable vehicle settings available for said second vehicle, for example wherein said plurality of vehicle settings are made available by the manufacturer of said second vehicle, for example being available and/or accessible online. According to another aspect of the invention, there is provided an apparatus for configuring the settings of a vehicle, comprising : means for storing on a memory one or more first vehicle settings configured for a user in relation to a first vehicle; means for accessing a database containing vehicle parameters pertaining to a plurality of vehicles, including said first vehicle and a second vehicle; and means for translating one or more of said first vehicle settings into one or more corresponding second vehicle settings for said second vehicle by analysing said first vehicle settings against parameters of the first vehicle thereby to determine said one or more corresponding vehicle settings for said second vehicle based on parameters of the second vehicle.

According to yet a further aspect of the invention there is provided a system for configuring the settings of a vehicle, comprising : an apparatus as described above; and a database containing vehicle parameters pertaining to a plurality of vehicles, including said first vehicle.

Preferably, the system further comprising a communications interface operable to provide a data connection with a computing device of at least one of said first vehicle and second vehicle, for example via the On Board Diagnostics (OBD) port in said vehicle.

Preferably, the system further comprising a mobile computing device operable to communicate with the database and, optionally, the communications interface as herein described.

Preferably, the communications interface is a telematics unit.

According to another aspect of the invention, there is provided a device having a memory on which is stored at least one profile containing one or more vehicle settings associated with one or more vehicles associated with a user.

According to another aspect of the invention, there is provided a vehicle comprising a memory on which is stored at least one profile containing one or more vehicle settings associated with one or more vehicles associated with a user.

Content Management

According to an aspect of the present invention, there is provided a method for enabling users to access and/or edit content, the method comprising : determining a user identity; determining origin information associated with a user; and providing hierarchical information relating to said user based on the user identity and/or origin information associated with the user thereby to enable the user to access and/or edit content in dependence on said hierarchical information.

Optionally, the hierarchical information comprises a user position within a hierarchy comprising a plurality of hierarchical nodes. Optionally the user permission is dependent on the user position within the hierarchy. Optionally the user position within the hierarchy is determined by at least one of: a user location ; a user language; a user business arrangement; a user brand; and a user group.

Optionally, content edited by the user is automatically applied to content relating to one or more hierarchical nodes below the user position in the hierarchy. Optionally, content edited by the user is restricted from being edited at one or more of the one or more hierarchical nodes below the user position in the hierarchy. Optionally, the content edited by the user requires authorisation by a hierarchical node above the user position in the hierarchy.

Optionally, the hierarchical information is used to determine a user permission associated with the user. Optionally, the user permission is a permission to edit content. Optionally, the user permission is a permission to access content. Optionally, the user permission is assigned by a hierarchical node above the position of the user in the hierarchy.

Optionally, the method further comprises the step of authenticating and/or authorising the user identity. Optionally, the content comprises elements of a website page. Optionally, the elements of the website page comprise components (herein also referred to as pods), wherein each pod comprises one or more of pod elements.

According to another aspect of the present invention, there is provided a system for enabling users to access and/or edit content, the system comprising : means for determining a user identity (for example, an identifier and reader) ; means for determining origin information associated with a user (for example, a processor) ; and means for providing hierarchical information (for example, an accessible data system comprising data pertaining to the hierarchical information) relating to said user based on the user identity and/or origin information associated with the user thereby to enable the user to access and/or edit content in dependence on said hierarchical information.

By using a layered data model' approach, a 'parent' (or 'master') website may be inherited by any number of 'child' websites to ensure a degree of conformity across a network of 'child' websites, while allowing individual entities to differentiate themselves within the network while remaining within a constant framework. For example, car dealerships may be allowed to differentiate themselves while remaining within a branded framework of a car manufacturer.

Furthermore, in a network having many individual websites having shared content, certain parts of the content displayed can be more easily customised to meet the requirements of an individual website or of a group of websites that relate to a particular entity. A high degree of customisation across the websites is also provided.

Organisations or groups may sometimes wish to apply augmented intelligence to the data regarding the use and behaviour of their products post-sale. The data may comprise extremely large data sets, commonly referred to as "Big Data". This can be achieved remotely, for example by using sensors within the product that are connected to a network and transmit the data to the required organisation. These data can be useful for assessing the functioning of the particular individual product being monitored, for example in order to predict a date for servicing, or may be aggregated into a data-set for determining statistics about a whole product range.

In situations where a group of organisations are involved in the manufacture and sale of a product, such as a manufacturer and a group of dealers or a supply chain, each member of the group may have different data requirements relating to the product, or may be restricted by regulations or laws from having access to certain parts of the data. Furthermore, these regulations and laws can often vary across legal boundaries, leading to complications when a product is transported across borders.

The product end user may also be interested in sharing their data more widely or more narrowly with the group members.

The invention may therefore be particularly useful for a network of websites relating to an entity grouping such as a car manufacture and/or its dealerships, for example. In this way, a group leader, such as the manufacturer in the car dealership example, may periodically update their branding or standard template, or provide particular content relevant to their products on all the group member websites.

According to another aspect of the present invention, there is provided a method for rendering a website, the method comprising : requesting a website page; determining origin information associated with the request; providing a content hierarchy for the requested page based on the origin information ; and rendering the requested page in dependence on the content hierarchy.

Optionally, the origin information comprises at least one of: a request location; a request language; and a requesting device type.

Optionally, the step of providing a content hierarchy for the requested page based on the origin information comprises determining a position of the requested website page within a hierarchy comprising a plurality of hierarchical nodes.

Optionally, the content hierarchy comprises a list of one or more pods and the relative positions of the one or more pods on the website page. Optionally, the method further comprises arranging the one or more pods relative to one another. Optionally, the relative positions of the one or more pods are determined by a device type of the device from which the request originates. Optionally, the method further comprises the step of retrieving the one or more pods from a pod service. Optionally, the pod retrieval occurs asynchronously.

Optionally, the website page is rendered in accordance with the content hierarchy.

According to another aspect of the present invention, there is provided a system for rendering a website, comprising : means for requesting a website page (for example, a network device) ; means for determining origin information associated with the request (for example, a processor) ; means for providing a content hierarchy for the requested page based on the origin information (for example, a data system comprising data / content structured in a hierarchy) ; and means for rendering (for example, a processor for rendering websites) the requested page in dependence on the content hierarchy. According to another aspect of the present invention, there is provided a method for controlling data requests in a multi-tenant platform, the method comprising : determining origin information associated with a data request; determining user information associated with the data request; and providing hierarchical information relating to said data request.

Optionally, the method further comprises determining permissions associated with the user. Optionally, the permissions are determined by a position in a hierarchy from which the data request originates.

According to another aspect of the present invention , there is provided a system for controlling data requests in a multi-tenant platform, comprising : means for determining origin information associated with a data request; means for determining user information associated with the data request; and means for providing hierarchical information relating to said data request.

Data Permissions

According to another aspect of the present invention, there is provided a method for controlling the transfer of vehicle data in different geographic locations, the method comprising: determining a geographic location associated with a request for data; checking permissions applicable to the transfer of said requested data from said determined geographic location ; and responding to said request according to said applicable permission.

Optionally, responding to said request comprises transmitting said requested data when said applicable permission permits said transfer of data from said determined geographic location. Optionally, the vehicle data is tagged with metadata indicating the permissions applicable to said vehicle data.

Optionally, the geographical location information comprises information indicating the geographical location where said data was created. Optionally, the geographical location information comprises information indicating the location where said requested data is stored. Optionally, the geographical location information comprises information indicating the location where the request for data was received. Optionally, the geographical location information comprises information indicating the location from which said request for data originated.

Optionally, the permissions are further determined from a position within a hierarchy from which the request originates.

Optionally, the hierarchy comprises at least one of: one or more vehicle dealerships; one or more vehicle dealership groups; one or more regions; one or markets; or one or more manufacturers.

Optionally, the permissions are associated with the ownership of said requested data. Optionally, the permissions are associated with said data format.

Optionally, the method takes into account the ownership and location of the data and the location and permissions rights of the accessor to determine what data is accessible, in what form and for what use by which service.

According to another aspect of the present invention, there is provided a system for controlling the transfer of vehicle data in different geographic locations, comprising : means for determining a geographic location associated with a request for data (for example a processor for determining geographic location for data relating to the same); means for checking permissions (for example a processor for checking permissions) applicable to the transfer of said requested data from said determined geographic location; and means for responding (for example a network device) to said request according to said applicable permission.

According to another aspect of the present invention , there is provided a method for controlling access to data, the method comprising : receiving a request for access to data; determining information associated with the requested data; checking permissions applicable to the request; and responding to said request according to said applicable permission.

Optionally the information relates to at least one of: the creation of the data; the location where the data was created; the location where the data is stored; the ownership of the data; and the data format.

Optionally, the permissions are determined based on the information associated with the requested data. Optionally, the permissions are determined based on at least one of: a position within a hierarchy from which the request originates; the location from which the request originates; the location where the data is stored; the data ownership; and the data format.

Optionally, the step of responding to the request comprises retrieving the data from a database. Optionally, the data includes telemetry data collected from a vehicle. Optionally, the data comprises aggregated and/or anonymised data. Optionally, the request for access to the data is recorded for reference. Optionally, the request is a request for transmission of the data across a network. Optionally, the response comprises the transmission of data across the network.

According to another aspect of the present invention, there is provided a system for controlling access to data, the system comprising : means for receiving a request for access to data; means for determining information associated with the requested data; means for checking permissions applicable to the request; and means for providing the data (for example a network device) in response to the request in dependence upon said applicable permission.

Thus, vehicle data may be collected from vehicles sold to a user through a dealership. The use of this vehicle data may be bidirectional, for example, to update an Engine Management System (EMS) and/or Engine Control Unit (ECU) after evaluating the data and personalising the vehicle. The dealership that sold the vehicle to the user may be interested in data from the vehicle, such as telemetry data, for example, which will allow the dealer to predict when the vehicle requires a service, or if any of the vehicle parts are malfunctioning or faulty. The dealer in this case will require personal data of the user in order to identify them and their vehicle should they need contacting . A dealership group to which the dealer belongs may also require information regarding the use of the vehicle, but may be restricted in what data it is allowed access to by privacy laws and regulations. At a higher level, the manufacturer may require aggregate data about the sales and use of its products for marketing and research purposes, but may be restricted to data in an anonymised and/or aggregated form due to regulatory constraints.

Currently, the rights of group members to access the collected data are managed manually in order to achieve these aims. This can be time consuming in inefficient, slowing down the process of data collection and analysis, thereby leading to the collected data potentially becoming outdated and less useful to the group members. It can also lead to mistakes in the data permissions being assigned, potentially resulting in breaches of data protection laws and regulations.

By taking into account the location , and preferably also the ownership, of the data requested, and the applicable permission rights at that location, and optionally also the location and permissions rights of the accessor, to determine what data is accessible, the present invention provides an 'intelligent' method for controlling and recording access to and use of data across a platform, to enable a user to ensure that they comply with the extremely complex legislative controls of data in the 'connected world', which may vary across legal boundaries. Furthermore, the format of the data provided and the use of said data by particular services can be controlled.

Vehicle Configuration

A product owned or accessed by a user may have configurable user settings, allowing the user to select a set of preferences relating to their use of the product. Where a user owns or has access to multiple products of the same type, each with configurable user settings, the user may wish to have the same settings preferences applied to each of the products. This provides a common experience across the products for the user.

A modern vehicle typically has multiple different user settings that are configurable, such as radio station and satellite navigation preferences and data permissions. When a user transfers to a different vehicle, they will have to input these preferences manually in the different vehicle. This can be time consuming, and negatively impact the user experience. Furthermore, in the meantime another user, such as a family member, may alter the settings in the original vehicle to suit their own preferences, leading to the original user having to reset their preferences when returning to the original vehicle. Another example may be a commercial vehicle, such as a bus or lorry that has multiple different users, each having preferred user settings.

In particular, modern vehicles have an ever increasing complexity of vehicle features that can be configured to a user's (e.g. the driver's) preferences. Currently, the settings for each of these features have to be configured independently for every vehicle. Furthermore, manufacturers currently develop their own vehicle profile preferences from model to model and these profiles are not accessible outside the vehicle. A product owned or accessed by a user may have configurable user settings, allowing the user to select a set of preferences relating to their use of the product. Where a user owns or has access to multiple products of the same type, each with configurable user settings, the user may wish to have the same settings preferences applied to each of the products. This provides a common experience across the products for the user.

In a vehicle, there are multiple different user settings that are configurable, such as radio station and satellite navigation preferences and data permissions. When a user transfers to a different vehicle, they will have to input these preferences manually in the different vehicle. This can be time consuming , and negatively impact the user experience. Furthermore, in the meantime another user, such as a family member, may alter the settings in the original vehicle to suit their own preferences, leading to the original user having to reset their preferences when returning to the original vehicle. Another example may be a commercial vehicle, such as a bus or lorry that has multiple different users, each having preferred user settings.

In particular, modern vehicles have an ever increasing complexity of vehicle features that can be configured to a user's (e.g. the driver's) preferences. Currently, the settings for each of these features have to be configured independently for every vehicle. Furthermore, manufacturers currently develop their own vehicle profile preferences from model to model and these profiles are not accessible outside the vehicle. According to another aspect of the present invention, there is provided a method for configuring the settings of a vehicle, comprising : storing on a memory at least one user-profile containing one or more vehicle settings associated with one or more vehicles associated with the user; establishing a data connection with the electronic management system (EMS) of a designated vehicle selected from said one or more vehicles associated with the user; accessing the EMS of said designated vehicle via said established data connection ; and configuring one or more vehicle settings of said designated vehicle to correspond with said one or more vehicle settings contained in said user-profile associated with said designated vehicle.

Optionally, the user-profile is accessible by the user of the vehicle when inside or near to the vehicle. Optionally, the memory is provided in a portable device, for example a key fob. Optionally, the one or more vehicle settings are stored in the memory in a standard data format.

Optionally, the method further comprised translating the one or more vehicle settings for the designated vehicle into a format compatible with the designated vehicle.

Optionally, the data connection is established via an On Board Diagnostics (OBD) port of said designated vehicle, for example wherein a dongle is connected to said OBD port. Optionally, the data connection is established wirelessly, for example via the dongle.

Alternatively, the memory may be stored remotely to the vehicle, for example in the 'Cloud', but accessible by the vehicle, for example via the internet, wherein the vehicle may be configured to establish an internet connection , preferably wirelessly, in order to establish the data connection.

Optionally, the vehicle settings include settings configured to control vehicle dynamics of the designated vehicle, for example to restrict the performance of said vehicle.

The configurable settings in modern vehicles are increasingly more advanced than enabling simple seat adjustment and climate control settings, and may also include telematics, Apps and vehicles dynamics, such as the gear ratio, and throttle / steering sensitivity.

Optionally, the vehicle settings comprise telemetry settings. Optionally, the vehicle settings comprises settings relating to the gear ratio of the vehicle's engine. Optionally, the vehicle settings comprises settings relating to the sensitivity of one or more vehicle controls, including at least one of the throttle, steering, braking and suspension. Optionally, the vehicle settings comprises in car entertainment (ICE) settings. Optionally, the method further comprises selecting the vehicle settings for a designated vehicle from a plurality of selectable vehicle settings available for said designated vehicle, for example wherein said plurality of vehicle settings are made available by the manufacturer of said designated vehicle, for example being available and/or accessible online.

Optionally, the user-profiles may be accessible and configuration via an App on a portable electronic device, such as a smart phone or tablet, for example. Optionally, manufacturers may be able to broadcast available vehicle settings (or 'policies') directly from their vehicles for selection by a user and/or addition to a user-profile. Vehicle settings may be edited and/or stored in a user-profile on a user-profile management App, for example, which may be accessed via an open API. Augmented Intelligence (Al) can be used to update the engine management system (EMS), and data (such as telemetry and performance data) can be analysed to adjust or reset settings and parameters in the vehicle based on personalised information relating to the user and a deep understanding of the vehicle and its provenance.

Thus, the invention provides a method for configuring the vehicle settings on one or more vehicle, wherein a user may create, store, maintain and transmit complex profile preferences for their vehicle(s) via a user- profile. The invention thereby enables a user to create a profile with their user configuration preferences and store a set of current vehicles on their user-profile. The user-profile may be created, accessed, edited and stored online, for example.

According to another aspect of the present invention, there is provided a system for configuring the settings of a vehicle, comprising : means for storing on a memory (for example memory) at least one user- profile containing one or more vehicle settings associated with one or more vehicles associated with the user; means for establishing a data connection (for example a network or a data connection) with the electronic management system (EMS) of a designated vehicle selected from said one or more vehicles associated with the user; means for accessing (for example a network device) the EMS of said designated vehicle via said established data connection; and means for configuring (for example a processor) one or more vehicle settings of said designated vehicle to correspond with said one or more vehicle settings contained in said user-profile associated with said designated vehicle.

According to another aspect of the present invention, there is provided a device having a memory on which is stored at least one user-profile containing one or more vehicle settings associated with at least said vehicle.

According to another aspect of the present invention, there is provided a vehicle comprising a memory on which is stored at least one user-profile containing one or more vehicle settings associated with one or more vehicles associated with the user.

According to another aspect of the present invention, there is provided a system comprising a vehicle and a device having a memory on which is stored at least one user-profile containing one or more vehicle settings associated with one or more vehicles associated with the user.

Embodiments of the present invention may comprise one or more of the following features:

1 . Website, inventory management, servicing, connected car and beacon based retail systems for use in the automotive industry. These systems may provide a multi-tenant platform to automotive manufacturers and their distribution networks as well as independent retailers, service networks and associated industry partners and end-consumers in a B-B-C context. The system is preferably controlled by an Intelligent Cascading Hierarchical Permissions service (i-CHS).

The i-CHS is a location conscious hierarchical permissions service that can monitor and control all services across a complex, multi-function software platform comprising integrated web, mobile, connected car and beacon based retail customer experiences. i-CHS is an omnichannel/omnipresent service accessible by functional services to orchestrate and control geographical, linguistic, licence, legal and content based permissions across a platform. The geolocation of dealer, service partners, vehicles and drivers may all be tagged and recorded and the i-CHS can access this information in real-time to manage and control interaction across the platform.

The platform is global , multi-tenant and functionally complex. The complex platform features may include content management, inventory management, customer profile, connected car integration, beacon network integration, reporting and ecommerce. Thus, a complex, flexible, location aware and dynamic service is provided to control interaction across the platform.

The multi-tenant nature of the platform means that permissions are highly complex and hierarchical in nature. They may control interaction between customers of different legal entities on a global basis.

2. Website, inventory management, servicing, connected car and beacon based retail systems for use in the automotive industry. These systems may provide a multi-tenant platform to automotive manufacturers and their distribution networks as well as independent retailers, service networks and associated industry partners as well as end-consumers. Data from customers (OEM, dealer, vehicle owners and drivers) is pervasive across the platform. An intelligent method for controlling and recording access to and use of data across the platform is required, which is provided by an 'Augmented Intelligence' Data Permissions Service (AI-DPS) service.

AI-DPS is a location and rights conscious data permissions service that can monitor and control access to data across the platform. AI-DPS is an omnichannel/omnipresent service accessible by the iCHS which itself controls all functional services across the platform. All requests for data access sent via the iCHS may be validated and recorded via the AI-DPS. The service can take into account the ownership and location of the data and the location and permissions rights of the accessor to determine what data is accessible, in what form, and for what use by which service.

The functional data use cases and legislative controls of data in the Internet of Things (loT) and connected world are extremely complex and can vary across legal boundaries and as a result of data ownership and granting of rights. Systems require real-time intelligent, location and rights aware access to data. The AI- DPS can manage the complex, flexible and dynamic services to control data access across the platform. The end consumer may use the service to control the type and usage of data to allowed parties.

3. Website, inventory management, servicing, connected car and beacon based retail systems for use in the automotive industry. These systems may provide a multi-tenant platform to automotive manufacturers and their distribution networks as well as independent retailers, service networks and associated industry partners and end-consumers in a B-B-C context. Vehicle settings may be configured via an Intelligent Vehicle Profile Configurator (i-VPC).

As referred to herein, an i-VPC is a portable vehicle configuration service that allows users to create, store, maintain and transmit complex profile preferences for their vehicle(s) via an online profile. The service enables a user to create a profile with their user configuration preferences and store a set of current vehicles. The service translates the standard profile preferences into a format compatible with the desired target vehicles.

A driver wanting to apply their user profile to a new vehicle, for example having purchased a new vehicle, when renting a hire car or attending a track day, then they can simply connect directly to the Engine Management System (EMS) or via a compatible OBD2 connected dongle, for example, and upload their profile. The driver can edit their profiles for multiple vehicles through a mobile application or web application , for example.

Manufacturers may broadcast available configuration policies directly from their vehicles to a user profile management app, for example, via an open API. By standardising these profiles and making them portable it is possible to easily move them from vehicle to vehicle.

According to another aspect of the present invention, there is provided a platform incorporating one or more of the aspects as described herein, in combination or individually.

According to another aspect of the present invention, there is provided a computer program product comprising software code adapted when executed to perform the methods as herein described.

Preferably, the methods and systems as herein described are adapted to be implemented at least in part in software code executable on a computing device or a plurality of interconnected computing devices. The invention also provides a computer program and a computer program product for carrying out any of the methods described herein, and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

The invention also provides a signal embodying a computer program for carrying out any of the methods described herein, and/or for embodying any of the apparatus features described herein , a method for transmitting such a signal, and a product having an operating system which supports a computer program for carrying out the methods described herein and/or for embodying any of the apparatus features described herein.

The invention extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.

Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

The various aspects of the invention may be implemented in software running on various interconnected servers, and it is to be appreciated that inventive aspects of this invention may therefore reside in software running on such servers. The invention also extends to a server or a plurality of interconnecting servers running software adapted to implement the system and methods as herein described.

Further features of the invention are characterised by the appended claims.

Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure. Furthermore, any feature in a particular aspect of the invention may be provided independently and/or applied to other aspects of the invention , in any appropriate combination.

It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.

Examples of the present invention will now be described with reference to the accompanying figures, in which:

Figure 1 shows a high level overview of a content management system and its users;

Figure 2 shows an example of a hierarchical group structure;

Figure 3 shows a further example of a hierarchical group structure;

Figure 4 shows a further, detailed example of a hierarchical group structure;

Figures 5a to 5d schematically illustrate the way in which the hierarchical group structure is controlled by an Intelligent Cascading Hierarchy Service (iCHS) ;

Figure 6 shows an example database structure for user permissions;

Figure 7 illustrates a pod-based website template utilised by the iCHS

Figure 8 illustrates an alternative pod-based website template utilised by the iCHS;

Figure 9 illustrates a further pod-based website template utilised by the iCHS;

Figure 10 illustrates the structure of a single pod;

Figure 1 1 shows a logical diagram of the platform showing the iCHS and iDPS;

Figure 12 illustrates a more detailed view of the iCHS and i DPS interacting with various services;

Figure 13 shows a sequence diagram illustrating an example sequence of events which occur when a user requests to view a web page;

Figure 14 shows a sequence diagram illustrating an example sequence of events which occur when a user requests to edit data;

Figure 15 shows a flow chart illustrating an example sequence of events which occur when a third party requests data;

Figures 1 6a and 1 6b show sequence diagrams illustrating example sequences of events relating to posting data to the platform and accessing data stored in the platform;

Figure 1 7 shows a flow chart illustrating an example sequence of events which occur when data is collected from telemetry apparatus and requested by an Original Equipment Manufacturer;

Figure 18 shows an alternative example in relation to the sharing of telemetry data;

Figure 1 9 shows a further example of the Intelligent Cascading Hierarchy Service and an Augmented Intelligence Data Permissions Service being used in relation to data collection;

Figure 20 shows an exemplary request for data;

Figure 21 shows an example of data being input to a car by a user;

Figure 22 shows a further example of data being input to a car by a user;

Figure 23 shows examples of a user transferring user settings between multiple vehicles;

Figure 24 shows a process by which a user transfers user settings between vehicles;

Figure 25 shows a process by which a user transfers preset user settings between vehicles;

Figures 26a to c show feedback processes, for various scenarios, in a machine learning system for inputting data into a car; and

Figure 27 shows hierarchical permissions specific to a hierarchical group structure

System overview

Figure 1 shows a high level overview of a content and data provision and management system and its users. The content and data provision and management system is run from a central server 5. The server 5 is connected to a database 1 0. The content management system manages data relating to an organisation's, or group of organisations', content, which includes, for example, websites, inventory management, servicing, connected car and beacon based retail systems. An example of such a system is one that controls the collection and use of vehicle data. Also provided is a platform which provides the various services described above. The server 5 is connected to a network 15, such as the internet, across which it can transmit data and allow users to access and edit data and access the platform. The server 5 may be a single server, a distributed network of servers, or may exist solely or partially in "the Cloud". Likewise, the database may be partially stored in "the Cloud"

A group 20 of related businesses or an organisation, such as a network of car dealerships for example, can provide content to the server 5 to be stored on the database 10. Group members 25 may also utilise the content stored in the database 10 in the creation of their own websites and content. Computing devices 30 can be used to interface with and connect to the server 5 preferably via the network 15 to which it is connected.

The group 20 of related businesses may be arranged in a hierarchical structure, as described in relation to Figure 2, with group members assigned to a particular level within the hierarchy, and comprise sub-groups 35 of certain group members 25. A group member's position in the hierarchy may determine which data and content it has access to. Using the example of a car dealership as an illustration, the group 20 may comprise a car manufacturer and a collection of approved dealerships. The car manufacturer may sit at the top of the hierarchy, providing content and having access to all content and providing permissions for group members lower down the hierarchy to access and/or edit content. Dealerships can use the content they have access to create further content, such as websites for their business, but may be restricted in what they can use or edit by the permissions given to them at their level of the hierarchy.

Once data and content have been uploaded to the server 5 and stored on the database 10, a third party user 40 may wish to access that data or content. Users 40 are able to connect to the sever 5 by means of a network connected computing device, such as a mobile phone 45 or personal computer 50, in order to access at least a portion of the data and/or content stored upon it. There may also be data stored which cannot be accessed by that particular user, as they lack the credentials and therefore authorisation to view certain material. If a user were to seek access to the data via a mobile device, then whatever data they are authorised to view can be displayed, but in a form suitable for the size of the screen upon which an interface is displayed. The data may be identical to that presented when making the request from a computer, but presented with a different skin and therefore optimised for that particular mobile device. Data may also be uploaded from and downloaded into a device, for example a car 55. The car 55 may be directly connected to the network 15 by means of, for example, an inbuilt wireless connection, or may be connected to the network via an intermediate device 60, such as a mobile phone. Certain aspects of telemetry data gathered by a telemetry array within the car could be very useful for the group members 25 to receive, so as to understand any issues relating to the car. Promotions may also be offered at opportune moments, such as when a service or repair is required. Additionally, data generated by the group members, such as the manufacturer, may be beneficial for the car to receive, for example an update to an embedded navigation system. An Original Equipment Manufacturer (OEM) may also wish to share data with the manufacturer and any associated organisations, so as to potentially monitor sales of its products, identify issues arising around the use of its products, or ensure that their branding and logo is consistent with their latest company image. The OEM is also connected to the server via a computing device 30, and is in some examples at the top of the hierarchy.

Hierarchical group structure

Figure 2 illustrates an example of a hierarchical group structure. The hierarchical structure 65 comprises a group 20 of group members, which may be considered as nodes within the hierarchical structure, arranged in layers. At the top position, or parent node, of the hierarchy sits a tenant 70 group member, which retains overall control of the hierarchy. This can be, for example, a car manufacturer or Original Equipment Manufacturer (OEM).

A second level 75 is formed from one or more nodes 75a-c. These may represent group members that are approved or at least partially under control of the tenant 70, such as approved dealerships or divisions of the tenant separated geographically.

In a similar manner, a third level of the hierarchy 80 can be formed from multiple group members 80a-g. Each of these group members may be partially controlled, or under the responsibility of, a group member in the second level 75 of the hierarchy, though they may alternatively be directly controlled by the tenant 70, such as group member 80e. Example group members in this layer may include individual local approved dealers, or local approved dealers belonging to a dealership group.

The hierarchy may have further layers depending on the overall group structure, with particular group members at a hierarchy level not necessarily being under the control or responsibility of a group member in the layer immediately above them. Using the example of a car dealership, the hierarchy is likely to contain a number of levels from highest to lowest in the hierarchy, which may for example be ordered as the Global, Regional , Market and Country branches of the manufacturer, followed by Dealer Groups, and finally the local Dealers.

Each layer of the hierarchy 65 has different permissions associated with it, allowing the group members in that layer of the hierarchy to access and edit only certain content stored in the content management system in Figure 1 . For example, a website template produced by the tenant 70 may comprise a plurality of elements that are editable only by members of a particular layer of the hierarchy.

Figure 3 illustrates a further example of a hierarchical group structure. In this example, the tenant 70 is positioned at the highest point in the hierarchy. The tenant 70 is in this example not the OEM, but is in a different position of responsibility. For example, the tenant 70 may own an umbrella car dealership, selling many different models which each have different OEMs. The nodes in this hierarchical structure are grouped together by associated permissions, which may be based on factors such as region 85, language 90, OEM associated with that node 95, and currency 1 00. Each group of associated permissions, or 'roles', may reflect different levels of content being available for editing and use by the members of that group. Furthermore, the group of associated permissions may restrict group members from editing particular elements of the content specified by the tenant 70, such as logos and/or website templates, for example. Each role can be tailored to suit the organisation of each tenant 70, for example 'Europe' 105 may only include specific countries within Europe within which that client is operating.

In the example shown, the hierarchy is divided into groups differently depending on particular dealer groups 1 1 0. Each dealer group 1 1 0 comprises one or more dealers 1 1 5. The hierarchical level immediately below the tenant 70 comprises a sole dealer 1 15 and three dealer groups 1 1 0.

A further example of a hierarchical structure is shown in Figure 4. The OEM is positioned as the tenant 70 in this embodiment, and is the original manufacturer of the goods that are to be sold. The OEM therefore has ultimate control over permission to edit the content stored on the server, for example the brand logo and brand identity associated with the OEM. The OEM manages content, including language and website templates, which is to be used in nodes lower down the hierarchical arrangement. The OEM is connected to one or more market groups 120, in this embodiment two market groups. Each market group 120 may refer to a particular geographical area, for example Europe and Asia. Each market group 120 may also additionally or alternatively refer to a particular brand under which products are being sold. The market groups 1 20 may be constrained in the permission they have to edit certain aspects of the available content by the OEM, if the OEM has decided that certain elements are necessary to ensure optimum sales in different market environments.

In this example, each market group 1 20 comprises one or more dealer groups 1 10. The dealer groups 1 1 0 are at least partially constrained in their ability to access and edit content stored on the server by the restrictions imposed by the OEM 70, and any further restrictions made by the market group 1 20. For example, a master website template may be provided by the tenant 70, comprising the tenant logo and branding along with standardised textual information. This template is editable by the market groups 120 to produce market specific website templates, with additional branding and market specific information. These market specific website templates will then be used by the dealer groups 1 1 0 to produce further templates or websites, but with the content created by the higher levels in the hierarchy unavailable for editing by them.

Each dealer group 1 1 0 manages one or more individual dealer websites 1 1 5. The dealer group 1 1 0 may impose further specific restrictions on the individual dealer websites 1 1 5, for example in relation to the dealer group brand, or in relation to the specific location of each dealership.

iCHS

Figure 5a schematically illustrates the way in which the hierarchical structure is controlled by an Intelligent Cascading Hierarchy Service 125. The Intelligent Cascading Hierarchy Service (iCHS) 125, residing in the server 5, acts to manage the permissions for each group member and user in the hierarchal structure, as well as managing the flow of data and content up and down the hierarchy. The iCHS 1 25 is a location conscious hierarchical permissions service that monitors and controls all services across the hierarchical structure.

One function of the iCHS is to cascade content updates made at higher levels of the hierarchical structure to the relevant group members at lower levels of the hierarchy. For example, a dealer group 1 1 0 and any subsidiary dealer websites 1 15 must reflect changes and updates to the brand logo made by the OEM or tenant 70, or changes to the overall website template. Local changes made by the market group may also affect the dealer group 1 1 0. Market group changes may involve details which are dependent upon the market which is being entered, for example the language of a banner heading or certain legal restrictions. As an example, consider a car purchase agreement. A change to the agreement, possibly correcting an error or closing a legal loophole, becomes relevant whenever a car from this dealership 1 15 is purchased. Therefore it is important that changes to the agreement are reflected throughout the car dealership network of nodes. The iCHS 125 cascades the changed purchase agreement through each of the hierarchical layers, ensuring that every group member/node replaces a current purchase agreement with the updated one. The updated purchase agreement may only be displayed at the 'Dealer' level when a purchase is made, but has been inherited through each layer.

A more local change, such as a particular dealership website 1 1 5 having a sale, is of less interest to the other dealerships and does not need to be necessarily reflected in the websites of the other dealerships. Changes in information at the lower level can therefore remain within that particular website, and not affect other websites unnecessarily.

A further function of the iCHS 125 is to manage the permissions to edit content within the hierarchical structure. Permissions to edit content are distributed to both individual users and to specific positions/nodes in the hierarchical structure. The iCHS 125 may be accessed by all functional services to orchestrate and control one or more different permissions, including for example geographical, linguistic, licence, legal and content based permissions. Permissions for each individual node are managed at a granular level.

Figure 5b schematically illustrates a specific example of the hierarchical structure controlled by the Intelligent Cascading Hierarchy Service 125 in the context of automotive dealers, so as to implement cascading content and content rules between a top level node (such as an OEM 70) and the ultimate output which is website for a dealer 1 1 5.

The hierarchical structure shown in Figure 5b contains logical groups and legal entities. A legal entity is a node point within the hierarchy (e.g . Dealer 1 or Dealer 2) and exist within in one or more logical groups. Permissions and content cascade from a legal entity to its children.

Rules that are applied higher in the hierarchy take precedent - they override rules set lower in the tree. For example, a rule by the EMEA logical group 1 12-1 overrides rules set by the UK logical group 1 12-2. This is important where, for example, a dealer 1 15 exists within two logical groups where rules are applicable across a (web) site map or page. Where the logical groups have conflicting permissions (for example, how a finance calculator is constrained) the rule applied by the higher node prevails. For example, for Dealer 2, a rule applied by the EMEA node prevails over a rule applied by the Spain node.

In Figure 5b, User A is attached to a logical group (the EMEA region 1 12-1 ) and can see the vehicle data for all its child markets (Spain , UK and France). User B is attached to another logical group (the USA region 1 1 2-3), and has no visibility of data outside of their logical group.

Dealers attached to logical groups associated with Spain, UK 1 12-2 and France cannot access any information outside of their groups (i.e. countries).

The logical group associated with Spain is composed exclusively of independent dealers. Shared stock has been enabled, so Dealers 1 and 2 can access each other's stock according to the rules established by the Spanish Group (and not forbidden by the EMEA group 1 12-1 , nor the OEM 70).

All dealers in the UK share the same customer database. Dealers under Group 1 1 1 0-1 , within the UK logical group 1 12-2, can request vehicle transfers between them. Dealers under Group 2 1 1 0-2, within the UK logical group 1 12-2, cannot see each other's inventory.

Content that is accessible in the hierarchy includes, for example, inventory, such as used or new vehicles, which may then be published on individual dealers' websites as part of the system. In the same way as the propagation of rules, permissions are defined based on the hierarchy. For example, a permission might include being able to manage stock, whether a finance calculator can be published, and what marketing tools are published, as well as which media is published. Permission are not only set at the highest-level so as to constrain lower levels (as in a folder structure), but the hierarchy also allows constraints based on role, membership within logical groups, entity and/or location .

The object which is being constrained is akin to a file in a folder structure (e.g. a word processing document), and exists within both physical groups (such as a market or a dealer group), but also within logical groups.

A site map is created by an OEM, versions of the site map are allocated to second level tenants (for example, Spain, UK 1 1 2-2 and France in Figure 5b), whereby elements of the site map are locked from editing in different ways for each tenant. These versions of the site map are then cascaded down the tree, with each lower level being able to edit and/or further restrict edited areas of that site map, until the most restricted version of the site map is reached at the lowest level of the tree. In effect, there is provided an automated cascading process.

Figure 5c shows an example of how a webpage is available to be altered through levels of a hierarchy (such as that in Figures 5a and b) based on the requirements of each entity type and the permissions granted at each parent level. Any number of vertical and horizontal nodes are permitted.

As shown in Figure 5c, in a first webpage template 1 17-1 the OEM has: locked a marketing element of the page 1 19-1 ; constrained the media that is available to its children 1 1 9-2; mandated a vehicle locator 1 19-3, but not its position on the page; and made a finance calculator available, but constrained some of its parameters 1 19-4. This template 1 17-1 is then propagated to the OEM's children, including a Middle East North Africa (MENA) logical group.

The logical Middle East North Africa (MENA) group further restricts template 1 17-1 to create its own template 1 1 7-2 available to its children, by: locking the position on the page of the vehicle locator and applied market rules 1 1 9-3-1 to the vehicle data which restricts the data available to its children ; applying extra rules on its finance calculator 1 19-4-1 (e.g. minimum vehicle value to be eligible for finance). The marketing element of the page 1 1 9-1 remains unchanged from template 1 1 7-1 , since this was locked by the OEM.

A national arm of the OEM, which is arranged as a child of the MENA logical group, inherits the template 1 1 7-2 and adapts this template to create its own template 1 1 7-3-1 , in which this entity has: made changes to the available media (for example to display only models available in that country) 1 1 9-2-2 ; restricted vehicles displayed in the vehicle locator to its own country and that of its nearest neighbour 1 19-3-2; and increased the deposit percentage requirement 1 1 9-4-2 within tolerances set by the MENA level.

An importer arm, which is also arranged as a child of the MENA logical group, inherits the template 1 1 7-2 and adapts this template to create its own template 1 1 7-3-2, in which the importer has: filtered the data to only display images of vehicles it imports (from the restricted MENA set) 1 1 9-2-3; applied rules to only show vehicles which have landed in the country (i.e. are not in production or in the process of being shipped) 1 1 9-3-3; and removed the finance calculator as its associated dealers do not have a finance capability 1 19-4-3.A website is generated based on the templates 1 17. Such websites are generated with data appropriate to the locale in which the website is being accessed using the browsers locale detection and/or a website is rendered based on URL switching rather than locale detection. For example, a dealer in which a country has a unique URL triggers completely different behaviour - rather than rendering elements based on a country code, the platform delivers a page which conforms to the systematic constraints enabled by each ancestor of the hierarchy tree. The browser's locale may in part adjust some elements (for example, a currency icon).

Figure 5d illustrates flow diagram of the process by which a website is generated based on website templates constrained as outlined in relation to Figures 5a to 5c.

Hierarchical permissions are specific to the hierarchical structure, as shown in Figure 6. Each node on the hierarchical structure is assigned specific permissions by the iCHS, which determine what content users at that node are allowed to edit or create. For example, a user of the tenant 70 may be allowed to add custom content, edit other existing content, replace the logo with a potentially updated version, and/or approve content provided by a lower part of the hierarchical structure. In general, the tenant 70 will have the full range of permissions available to it, with nodes further down the hierarchical structure having fewer permissions available. In this example, nodes DG1 130, DG2 135 and D3 1 40 have permission to add custom content, such as website components (herein also referred to as pods) on a website template. DG1 130 is responsible for approving D1 145 and D2 1 50 custom content. DG2 135 is responsible for approving D3 140 and D4 1 55 custom content. DG1 130 has granted D1 145 the permission to publish content directly, bypassing content approval workflow. Such permission may be granted if, for example, D1 145 is a trusted content publisher and has been in a working relationship with DG1 130 for a significant amount of time. D2 150 can publish content but it needs to be approved by DG1 130, as the working relationship with D2 1 50 may be more recent and so DG1 130 need to ensure that their content meets certain standards. Each individual user within a node in the hierarchical structure may additionally be assigned specific permissions which reflect what that individual user using a particular set of login details is allowed to edit. Within an individual dealership, a manager may have permission to edit the main header content, for example in relation to a new promotion being run, whereas a lower-level employee is not authorised to make such an offer and so does not have permission to edit the main header content directly, but may be authorised to edit stock related items. As well as editing specific content for specific parts of the hierarchical structure, user permissions may also relate to: permissions to edit an inventory; amend a page template or 'pod'; amend the permissions of another user; and/or schedule services.

Cascade and Pod-based website design

Figures 7 to 9 illustrates a pod-based website template utilised by the iCHS. The iCHS manages the cascade of content down the hierarchical structure by means of a pod-based website template.

A group member website 1 60 is assembled from a collection of website components (also referred to as pods) 1 65 arranged in a series of grids 170. The pods 165 are operable to display information to the website user from a particular source, maintaining a consistent display even when information has been changed. Some pods 1 65 may be operable to be changed following edits to websites higher in the hierarchical structure, whereas others may be limited to displaying local information which is not amended by outside sources.

Pods and groups of pods can be reused to assemble a website in different configurations depending on the device on which the website will be viewed. The pods can be grouped together into grids and sub-grids to allow for them to be rearranged for optimal viewing on a particular device, while maintaining visual or spatial coherence of related content in the pods.

Figure 7 illustrates an example of a pod arrangement for a website 1 60 suitable for viewing on a computer screen, such as a desktop or laptop display. In this example, the pods 1 65 are arranged into groups 170 and subgroups 1 75 for display in a widescreen format. Figure 8 illustrates an example of a pod arrangement for a website 1 60 for display on a tablet screen. In this example, the pods 165 contain the same content as the version of the website for display on a computer screen, but are now arranged differently on a grid for display. The groups 170 and subgroups 175 of pods 165 remain the same as the computer display version. Figure 9 illustrates an example of a pod arrangement for a website 160 for display on a mobile screen. In this example, the pods 165 contain the same content as the versions of the website for display on a computer screen and tablet screen, but are now arranged in a way to display the content optimally on a mobile screen.

The website pages of each group within the hierarchical structure are generally assembled from many individual pods. In the case of a grid layout the data to describe the grid is loaded from each layer starting at the top. Each grid is layered over the first. This means that pods can be added, edited or repositioned in any layer. If an item is locked then the data layer simply blocks later updates from subsequent layers meaning that even if an item is locked after it was edited elsewhere it will always show the locked version.

Figure 10 shows an example of the structure of a single pod 165. The content shown in the pods will be derived on a cascading hierarchical basis. To achieve this, the pods comprise a structure of one or more 'elements'180. In this example, the pod comprises three elements, wherein each element 1 80 is in the form of a text field. The pods 1 65 may also be the form of a table, diagram, photo, image, or other data representation . Each member in the hierarchical structure can potentially add their own content to an element 1 80. The content displayed in pod elements 180 will be dynamically derived based on the target website. In this example, a tenant, which may be a dealer group (or dealership) for example called Arnold Clark, sets the title and locks it. The tenant may also set a default location where they is headquartered, or a general region where the company operates. Dealerships in lower level of the hierarchy may add their own individual, possibly more specific, locations to the element. The phone number field may be left blank, allowing group members at lower levels in the hierarchy to add their own number. Local dealerships may be better placed to deal with customer calls than a business headquarters, and so can provide their own phone numbers themselves.

Correspondingly, a pod may be tailored to the visitor's geographical location and showing relevant inventory or contact details for the nearest dealer. Geographical bounds can be set to particular regions allowing the user to be shown relevant information, or redirected entirely to a locally specific site. The user's current geographical position may be based on the users IP. The iCHS can determine which region they are in, and automatically redirect to the relevant region site. Each region will only show stock for dealers within that region based on the structure defined in the hierarchy.

Individual parts of a pod can be pinned, for example a regional promotion could be pinned to appear as the first item within a pod while still being editable for translation purposes. Locking of parts of a pod is also possible, preventing them from being edited by a user without sufficient permissions to do so, while still each individual element to be reordered. Many websites also use a 'hero slider', which is a specific pod conventionally positioned at the top of a page that allows for the creation of multiple slides that rotate in order. The layered data allows for the creation of content at the global or regional level, which then distributed to levels lower on the hierarchical structure. It is also possible to add additional frames, and reorder them at lower levels.

Each of the tenant (e.g. Arnold Clark) and two dealerships in the example shown can have their own website. The pod is placed on the website, and when each website loads each of the tenant and dealerships will all get their own tailored cascading content for that pod. Examples of the pod data structures are shown below. The pod output for the tenant shows what is displayed on the tenant website when the page containing the pod is rendered. The dealer group name 'Arnold Clark' is displayed in the first element, and the general location of 'Scotland' is displayed in the second element. A telephone number has not been provided, so the third element remains blank. The pod outputs for the dealer websites, despite being formed from the same pod itself, are different depending on the individual dealerships. Dealer 1 is situated in Edinburgh, whereas Dealer 2 is situated in Glasgow. However, the dealer group, or owner of the dealership's name, Arnold Clark, is displayed in all of the websites and cannot be amended by the dealership websites. Overall control of the pod is therefore retained by the tenant.

An example of the pod output for the tenant is provided:

"Pod":

{

"Id": 1 ,

"Elements": [

{

"Id": 1 ,

"Content": {

"Value": "Arnold Clark"

}

} .

{

"Id": 2,

"Content": {

"Value": "Scotland"

}

}.

{

"Id": 3,

"Content": null }

An example of the pod output for Dealer 1 is provided: "Pod":

{

"Id": 1 ,

"Elements": [

{

"Id": 1 ,

"Content": {

"Value": "Arnold Clark"

}

},

{

"Id": 2,

"Content": {

"Value": "Edinburgh"

}

"Id": 3,

"Content": {

"Value": "01 31 123 4567"

}

} An example of the pod output for Dealer 2 is provided: "Pod":

{

"Id": 1 ,

"Elements": [

{

"Id": 1 ,

"Content": {

"Value": "Arnold Clark"

}

},

{

"Id": 2,

"Content": {

"Value": "Glasgow"

}

} .

{

"Id": 3,

"Content": {

"Value": "01 41 123 4567"

}

} Multiple websites for a single group can use the same database. Content is stored in collections, so that it may be shared between the websites of different group members within the group, while the 'pages', 'sitemap' and other site specific data can be stored in separate collections. The layering of data and content in the hierarchical structure through the iCHS can be implemented though a single access class. All data can therefore be accessed in a consistent way. Every item of data in the system has a key, which can include information such as an 'I D', 'owner' and 'language'. When loading an individual data item, the system creates a list of 'owners' and 'languages' from the hierarchy. The system loads all items that match the given id and one of the Owners and languages. The result may be one or more items, which are then ordered according owner and grouped by language. Each layer of data is then read and condensed in to a single object.

The content is provided with a site map, comprising a list of data. Each item of data can be marked with a hierarchical tag comprising an 'ID', 'name' 'page ID' and 'parent I D'. Each layer of data is loaded from the top to the bottom and items with a matching 'ID' can override values from the previous layer. The hierarchical structure can then be built from the items in the sitemap, using the 'ID' and 'parent I D'. When a page is requested the sitemap is used to locate the 'page ID'. This may be done by processing the Uniform Resource Locator (URL), and reviewing keywords embedded within. The first item referred to in the URL is the index page, so the system will look for children of the 'index' with a matching 'name' for first item in the URL. When one is found, the next item in the URL is compared to its children and so on until no match is found or all elements have been matched.

The number or layers to be read and the order of precedence of the layers can be controlled. Therefore when the system is informed that only the bottom layer is needed, the order can be reversed and selection limited to a single item. By way of example, as the page 'definition' is a single item of data, it doesn't have overridden values internally, and the system can ignore layers that have been superseded. This means that any layer within the system can alter the basic layout of a page but unnecessary data isn't loaded. The system doesn't need to know that 'a dealer' edited the page, or a group. Only that the last and most recent page is returned.

While any websites or groups referred to may be subject to restrictions placed upon them by any groups higher in the hierarchical structure, data added or changed in groups lower in the hierarchical structure may still be of interest and be reflected in groups higher in the hierarchical structure. Therefore data is arranged to cascade 'upstream', from the lower levels of the hierarchical structure to the higher levels. For example, the number of products sold will be initially input into an individual dealer website. This sales data may be of interest to a number of groups higher up the hierarchical structure, for inventory and feedback purposes. The dealer website may also wish to know any services due for those products, so that they may offer to perform those services. However some groups higher up the hierarchical structure may not be interested in, or be entitled to, more specific information in relation to each vehicle. Data privacy concerns are likely to present themselves if every group associated with a product being sold was allowed unrestricted, granular access to the private use of that product.

Therefore groups higher up the hierarchical structure may only receive select or aggregated data from groups lower down the hierarchical structure. As a user of each node of the hierarchical structure may not have identical permissions to view the data provided to them, a further permissions system is required. The Augmented Intelligence Data Permissions Service ('AI-DPS' or 1DPS') is a location and rights conscious data permissions service. The AI-DPS is a service accessed by the iCHS, which controls access to all functional services across the hierarchical structure. All requests for data access are sent via the iCHS, and validated and recorded by the AI-DPS. The AI-DPS takes into account the ownership and location of the data, and the location and permissions rights of the accessor. The AI-DPS then determines what data is accessible, in what form, and for what use by which service.

Figure 1 1 shows a logical diagram of the platform showing the iCHS and iDPS in context. This diagram also illustrates the interaction between various services and modules provided as part of the platform, and the way in which they interact with each other and the iCHS and iDPS. During use of this system, customers, dealers, third parties and connected vehicles will interact with the platform via a number of front- end services. These front-end services include, at least, a dealer locator 185, vehicle management 190, a used vehicle locator 1 95, a dealer website 200, a content management system 205, or a service booking 21 0. The data for each of these front-end services is provided through a central application programming interface 215 (API) linked to a number of other, more specific, APIs. In this embodiment the central API 21 5 is provided using Tyk™. The central API 215 is operable to collate data from one or more specific APIs, before the providing the data to one or more of the front-end services.

The more specific APIs may be APIs in relation to: licencing 220, permissions management 225, site building 230, notification management 235, translation management 240, dealers 245, media management 250 (including photographs, videos and library images), stock ingest 255, stock export 260, point of sale (POS) creators 265, vehicle identification number (VIN) decoders 270, transactions 275, customers 280, service schedules 285, and/or reporting 290.

It is necessary to ensure that a user accessing data through a front-end service from a specific API has the appropriate permissions to receive that data. The central API is therefore connected to the iCHS 125. The iCHS 125 monitors the data being requested, and will permit access to certain data based on the appropriate positions. The iCHS 125 accesses the AI-DPS 295 to validate and record the request for data access. The collection of permitted and/or processed data is then rendered onto a website to view. Data requested from a database is also subject to an authentication process, and an image management process to ensure that any images provided will render correctly. The approved and processed data from the database is then passed to the central API 215 to distribute accordingly.

The arrangement of Figure 1 1 also allows for integrations with third parties. Third parties are not automatically entitled any data they request. Therefore any data which is passed to a third party website, for example in relation to the number of products sold, has to be permitted by the iCHS 125 and then validated and recorded by the AI-DPS 295. The data, even once approved, may then be subjected to an aggregation or anonymisation process so as to protect individual privacy before it is transmitted to a third party website.

A vehicle configuration service 300 interacts with the platform via the central API 21 5 to enable the porting of user settings between vehicles to be managed by the iCHS 125. Furthermore, a connected car API 305 allows telemetry data collected from a user vehicle to be managed by the iCHS and iDPS.

More detailed views of some of the services present in the platform are provided at the bottom of Figure 1 1 . These views illustrate various modules within the services, as well as details of their connectivity with other services present in the platform.

Figure 12 illustrates a more detailed view of the interaction between iCHS 125 and iDPS 295 and how they interact with other various services. In this example, the services are: a rendering service 31 0, for generating websites from content and pod data; a pod service 315, containing content and pod data for generating websites; a translation service 320, for translating websites based on the location of the user requesting the website ; a connected car service 325, which collects telemetry data relating to the use of a car by a user; and a reporting service 330, for accessing collected telemetry data.

Hierarchical data is managed by the iCHS 125, which is connected to a database 335 containing the data and content that it manages. Different services interact with the iCHS 125 to obtain information relating to the hierarchy that it manages. This can involve requesting details of the hierarchical structure itself, or accessing content stored in the database 335 based on the hierarchical information. In particular, as shown in Figure 12, the "getHierarchies" function call is passed to the iCHS from the iDPS and other services to obtain hierarchical information, and the iCHS and other services obtain permissions from the iDPS via a "getPermissions" function call to the iDPS.

Data permissions are managed by the iDPS 295 (also herein referred to as the AI-DPS), which is connected to the iCHS 125 and at least some of the services that interact with the platform. The iDPS 295 controls access to collected user data relating to group products. For example, telemetry data from a car collected by a connected car service 325 may have certain data permissions applied to it by the iDPS 295 before storage in order to comply with regulatory or legal constraints. When a group member attempts to access the data through the platform, the iDPS 295 will determine whether or not that group member has permission to access the data based on the group member position in the hierarchy, as determined by the iCHS 125, and other group member data, such as geographical location or other origin information. Figure 13 shows a sequence diagram illustrating an example sequence of events which occur when a third party user requests data to view on a web page.

Initially, the user makes a request for a specific page from a website via a 'presentation' logic. If that requested page is protected, or the view is otherwise restricted, then authorisation and authentication may be required to view the page. For example, the third party user may have to supply login details and a password in order to access a particular part of the website. Authentication of the third party user is performed by an authentication module, and authorisation will be performed by a permissions service.

Once authorisation and authentication, if required, have been performed, the presentation logic requests the requested website page from a rendering service. The rendering service then issues a request to the iCHS for the content hierarchy of the requested website page. The content hierarchy comprises a list of pods required for constructing the requested website page, along with details of their arrangement. The content hierarchy is determined by the iCHS based on the position of the requested website page in the hierarchical structure.

The rendering service uses the content hierarchy to obtain the required pods from a pods service. A request for the required pods is sent by the rendering service to the pods service, indicating the required pods and the position of the requested website page within the hierarchical structure. The pod is provided via a pod service and dynamically populated with data according to the position in the hierarchical structure of the target website on which the pod is to be displayed. The pod service generates the required pods from content stored in a database. The content request may be asynchronous, wherein each request is placed in a queue and then processed in the order received.

Once the pods are correctly populated with hierarchical content, they are returned to the rendering service, where they are assembled so as to be presented on a web page. The complete page construct is then transmitted to the third party user who requested the data.

Figure 14 shows a sequence diagram illustrating an example sequence of events which occur when a user requests to edit data. A user belonging to a group member/node in the hierarchical structure makes a request via presentation logic to edit content stored on the content management system. This may be, for example, a request to edit a pod that forms a part of a website page.

To determine whether the particular user has permission to edit content, an authentication and/or authorisation step is usually required. The authentication and/or authorisation may take the form of requesting a username and password before any further access is granted. These functions are performed by an authentication module and a permissions service respectively.

Once the user has been authorised to edit content by the permissions service, the presentation logic issues a request to a rendering service for the page that the user wishes to edit. At this point, the rendering service issues a request to the iCHS for the content hierarchy and permissions hierarchy of the requested website page. The content hierarchy comprises a list of pods required for constructing the requested website page, along with details of their arrangement. The content hierarchy is determined by the iCHS based on the position of the requested website page in the hierarchical structure. The permissions hierarchy provides a list of which nodes in the hierarchical structure have permission to edit which pods or pod elements.

The rendering service uses the content hierarchy to obtain the required pods from a pods service. A request for the required pods is sent by the rendering service to the pods service, indicating the required pods and the position of the requested website page within the hierarchical structure. The pod is brought from a pod service and dynamically populated with data according to the position in the hierarchical structure of the target website on which the pod is to be displayed. The pod service generates the required pods from content stored in a database. The content request may be asynchronous, wherein each request is placed in a queue and then processed in the order received.

Once the pods are correctly populated with hierarchical content, they are returned to the rendering service, where they are assembled so as to be presented on a web page. The complete page construct is then transmitted to the user wishing to edit the page. The rendering service may present the pod as it is to appear to a third party user. The user then proceeds to edit the requested page as desired. Depending on both the hierarchical permissions and the specific user permissions of the user determined by the iCHS, certain pods or pod elements may be unavailable to the user for editing.

The edited pod content is returned to the rendering service after the user has made the intended changes. The rendering service then requests the required pod for editing from the pods service, which checks for any pod constraints with the iCHS. If the requested pod edits are consistent with the pod constraints supplied by the iCHS, then an edited pod instance is returned to rendering service, which then presents an edited version of the website page to the user as it would appear to a third party.

Figure 15 shows a flow chart illustrating an example sequence of events which occur when a third party requests data for viewing on a web page. Initially, a request is made for a particular set of data. The location of the request is evaluated, as described above, so that the data may be tailored to the visitor's geographical location , possibly showing relevant inventory or contact details for the nearest dealer. Other metadata, for example the language preferences of the user, may also be evaluated so that the website may be offered in a language which the user understands. Having received the information associated with the request, the iCHS then passes this information to a contracts and/or licencing service which ensures that the user is permitted to receive the data they are requesting. Each request is then logged by the contracts and/or licencing service. If the user is found not to be permitted to receive that data, then their request is rejected and the data is withheld. However if the user making the request is found to be permitted to receive that data, then the iCHS queries the sitemap service for the structure of that data. The iCHS then queries the pod service to provide the correct content within the pod, based on the hierarchical tagging system as described above. The data is then delivered to the front-end service from which it is being requested. The front-end service may be coded in an angular structural framework, which can make front-end development more efficient.

Data collection (and iDPS)

In addition to controlling the cascade of content down the hierarchical structure when creating website pages, the iCHS also controls the flow of data up through the hierarchical structure. The data flowing up the hierarchy may, for example, originate as telemetry data collected from telemetry apparatus in the group products. Such data would be useful for indicating the performance and use of the product in question, for example to determine when it needs servicing, or if it is being used in a way that invalidates its warranty. Due to differing data protection regulations in different jurisdictions, different group members within the hierarchical structure may only be entitled to access certain parts of the collected, and the entitlement to access various parts of the data may vary as the product is moved from jurisdiction to jurisdiction.

Furthermore, different group members at different levels of the hierarchy may only be interested in certain parts of the collected data. For example, an OEM may only require aggregate data relating to the statistics of their products, while an individual dealer may require specific data relating to a particular product in order to monitor the product health.

While the iCHS controls the flow of the collected data up through the hierarchy, the Augmented Intelligence Data Permissions service (AI-DPS or iDPS), residing in the server 5, controls access to the data based on multiple factors including the position of a requesting party within the hierarchical structure, the ownership and location of the data, and permission rights of the requesting party. The iDPS is a location and rights conscious data permissions service that monitors and controls access to data across the platform. It is an omnichannel/omnipresent service accessed by the iCHS, which itself controls all functional services across the platform. All requests for data access are sent via the iCHS and are validated and recorded by the iDPS.

Figure 1 6a shows a sequence diagram illustrating example sequences of events relating to posting data to the platform and accessing data stored in the platform.

In this example, a user communicates a request to post user data to the platform via a vehicle dongle or mobile device. The vehicle dongle or mobile device issues an API request to the connected car API . The connected car API authorises and authenticates the user request using an authentication service and a permissions service. Upon receipt of authentication and authorisation confirmations, the connected car API transmits the user data to the iDPS along with an indication that the data permission structure is required. The iDPS requests the organisational hierarchy from the iCHS that corresponds to the organisation to which the user data will be distributed. The iCHS returns the organisational hierarchy, which the iDPS then uses to tag the incoming data with metadata indicating who has permission to access that data. The data, along with the metadata it has been tagged with, is then stored in a database via a data gateway.

In Figure 16b, a group member requests a report containing data stored in the platform. The group member issues a request for the report via presentation logic. The request is authenticated via an authentication service, and authorised via a permissions service. Once the presentation logic receives conformation that the request has been authorised and authenticated, it issues a request for the required report pages to a rendering service. The rendering service communicates with the iCHS to determine the content and permissions hierarchy of the requested data. Based on this information, which can include the hierarchical and geographic position of the requesting group member, the report data is requested from the iDPS. Using this information, the i DPS checks that the requesting group member has permission to access the data, before obtaining the data from the database via a data gateway. The data is then passed to the rendering service, where the requested report is constructed from it and transmitted to the requesting group member.

Figure 1 7 shows a flow chart illustrating an example sequence of events which occur when data is collected from telemetry apparatus in a product and requested by an OEM. A product, for example a car, may be provided with an in-built telemetry array which is operable to collect and record data regarding the use of the car. The data recorded may be, for example, in relation to distance covered by the car, speed and direction of travel , gear settings, diagnostic and safety checks, road surface, service requests, fuel consumption , and/or brake activation. For additional data gathering, the telemetry apparatus may be paired with a mobile phone app, which records further data regarding the use of the car.

The data collected from both the telemetry apparatus and the mobile phone app is then generalised to a standard data model and stored. By generalising the data to a standard data model analysis may be more effectively carried out, and the data can be more easily compared to other data gathered from other cars. The data is then requested by the OEM, or potentially other third parties, as information about a product sold is very likely to be of interest to third parties. If, for example, a diagnostic check reveals that a repair is required, then such a repair may be advertised to the owner of the car. Similarly, if a large number of breakdowns are reported for a certain model, then the model assembly can be examined to locate and fix the source of the error causing the breakdowns.

As described earlier, the OEM or other third party may not be entitled to such specific information in relation to each vehicle, due to data protection regulations and laws. The iCHS therefore passes the request for data to the AI-DPS, which may act like a contracts and/or licencing service. As before, if the third party is found not to be permitted to receive that data, then their request is rejected and the data is withheld. However if the user making the request is found to be permitted to receive that data, then the iCHS compiles the permitted data set for the third party. The data is then delivered to the requester through an export service and/or the front-end service.

An alternative view in relation to the sharing of telemetry data is shown in Figure 1 8. In this embodiment, car telemetry data and data collected by a user mobile device 340 is sent to a regional storage database 345 via a network. The data is tagged with metadata relating to the location of the product at the time the data is captured, the identity of the user and product from which the data is captured.

The iCHS 125 determines the hierarchy relating to the collected data, for example the dealer - dealer group - tenant chain, while the iDPS 295 determines the permissions of each node in the hierarchy to access the data.

The iDPS 295 logically sits between the database on which the collected data is stored and the iCHS 1 25. When data is requested from the regional storage database by a third party 350, via the iCHS 125, a number of factors in relation to the requesting party are assessed. The hierarchical permission of the requesting third party 350 determine the type of data available to them, such as whether explicit, aggregated or anonymised data are available. The metadata with which the collected data is tagged also determine whether the requesting third party 350 can have access. If it is determined that the requesting third party 350 has access to the data, then the data is supplied to the requesting party. Otherwise it is withheld from them. A further example of the iCHS and iDPS being used in relation to data collection is provided on Figure 19, and is regarding a test drive of a car. An agent 355, likely an employee of a car dealership, requests a test drive of a car. Personal data of the agent 355, for example their location, may be collected via the agent's mobile phone 360 and sent to the iCHS 125. Such information may be useful for a dealership to identify the location of all their agents and/or cars at any given time. Telemetry data may also be received from the car 365 itself, as described above, and sent to the iCHS 125. The OEM70, dealer group 1 1 0 and individual dealer 1 1 5, may all want to share the information gathered by the iCHS 125 for their own reasons as described above. The iCHS 125 therefore checks the permissions of each of the potential data recipients with the i DPS 295, and only data which the recipient is entitled to receive gets transmitted to that recipient. iDPS permits data aggregation and data filtering in a way that allows users within logical and entities (or commercial groups) to have access to data if, or to the extent, that it does not infringe the rights of third parties associated with that data.

Data that has been captured by a vehicle, geocoded and transmitted to the iDPS system is persisted in a data processing engine that applies rules via a tagging mechanism to allow portions of that data to be made accessible to myriad logical and physical entities, such as an OEM, a brand, an importer of vehicles, a vehicle dealer group or franchise and/or a member of the general population.

The iDPS system aggregates data from a plurality of sources, analytical data and then anonymises and/or aggregates the data based on machine-learnt algorithms that apply a set of rules that protect the data sensitivity for the ultimate owner (or subject) of that data (e.g. the driver).

Furthermore, the iDPS platform maintains data border controls, thus if a user grants permission for their data to be accessed by third parties, such as an OEM, the system will not allow the data to be accessed by that OEM if the request is made outside of the borders from where the data was collected and/or persisted if legislation or commercial concerns do not allow it.

In one example, data is stored in document-based data storage in the JSON format, for example as follows:

{

tripID :2017001 ,

vin: 1 G6AF5SX6D0125409

latitude: 55.946255,

longitude: -3.201 587,

time : 1495629471 ,

sensors : {speed : 42, rpm : 3500, fuel : 30, oilPressure : 30, frTyre : 0, fITyre : 0, rrTyre : 0, rlTyre:0},dtc : {Cylinder2Misfire:1 },

odometer :35300

}

The data represented in JSON above is, for example, a vehicle sensor reading captured at a specific time and place. The information stored is owned by the driver, as such, the iDPS system gives the driver access to their vehicle data. However, individual or aggregated data is also useful to other entities. The iDPS system provides access to this data either by direct permission (i.e. the driver elects to share part or all of the data with a group or individual) or by obfuscation (anonymisation) where the details within the data are detached (disassociated) from the individual (and/or vehicle) and aggregated to the point that it would be impossible to associate the data with a specific individual and/or vehicle.

For example, an OEM might be interested in the most common faults on a specific vehicle model in a particular market, such as cylinder misfires. The number of reported cylinder misfires on a particular vehicle model (as identified by the VIN number) is aggregated by an OEM requesting such information from the iDPS and presented to the OEM. However, the OEMs competition should not be able to see this information . Accordingly, data access permission for cylinder misfires for that model is restricted to only the OEM of that model.

The automotive industry might be interested in all cylinder misfires across all vehicles in a given market, to evaluate its own performance against its competition. In this case, aggregated data can be presented to all OEMs. Accessing the data indicating the source location of the data (in terms of where the data was collected) may also be restricted by law. The iDPS system is configured only to present aggregated data to entities who are legally and/or commercially entitled to access such data. The iDPS our system automatically finds correlations and applies data protection rules before presenting data.

Figure 20 shows an exemplary request for data via the iDPS platform. At a first step 122-1 , a query is created to interrogate the data within iDPS; this query is for a request of the top ten faults associated with four-wheeled vehicle in environments where the temperature was over 40^SC.

The permission of the source of the data request is considered by iDPS at a next step 122-2. If the entity from which the request originated has sufficient permission to access such data, then they are granted access to the data (which may first be manipulated in accordance with permissions, for example obfuscated) at a following step 122-3. If not, then the request is denied.

Next, the filtered output of data is aggregated by iDPS in accordance with the request, so by fault code frequency 122-4. Further analysis of access is considered by iDPS at a next step as to whether the market location of the source of the request is permitted to access the data 122-5. In addition, iDPS assesses compliance with data transfer rules based on the location of the data (both where collected and persisted) 122-6. If the request and requester satisfy the rules associated with the data, the iDPS system outputs the data, albeit stripped of all data that does not conform to the rules associated with the data 122-7. In a final step, the data is sent to the requester 122-8.

Vehicle profile configurator ('user preferences')

As well as data being received from a car, a user may wish to input data as well, as shown in Figure 21 . Such data may include personal information sent as part of a request to alter a setting on the vehicle. Such settings may relate to personal preferences of a user as set up on their car at home, which can be imported into any other car which they choose to drive. These personal preferences may include engine output, gear ratio, steering sensitivity, pre-set radio stations, driver seat position and rake, steering wheel position, gear change settings (for an automatic car), the position of a choke valve, positioning of internal and external mirrors, active headlights and/or favourite destinations saved in a navigation system, as well any other Engine Control Unit (ECU) or Engine Management System (EMS) settings.

The settings are managed through an Intelligent Vehicle Profile Configurator (i-VPC) 300. The i-VPC 300 is a portable configuration service that allows users to create, store, maintain and transmit complex profile preferences for their vehicles via an online profile. The i-VPC 300 enables a user to create a profile with their user preferences and store a current set of vehicles to which the user would like the settings to apply. The profile is stored in a database managed by the iCHS 125, with permissions to access the profile determined by the iDPS 295. The i-VPC 300 translates the user profile preferences into formats compatible with the user associated vehicles stored with the profile.

When a user enters a vehicle 365 identified in the profile, their presence in the vehicle 365 is indicted via a device, such as a mobile sensor, which issues a request to the iCHS 125 to alter the setting in the vehicle to match the user profile associated with the identified user. The iCHS 125 checks the user permissions with the iDPS 295, which indicates to a regional database 370 on which the user preferences are stored that it can send the required data to the user vehicle 365.

Figure 22 illustrates an example of a user configuring a vehicle user profile for use in the i-VPC 300. The user 375 accesses their profile options via an application on a device 380, such as a mobile phone. The application has options to change the user preferences 385, save different user profiles 390 and manage user profile versions, such as versions over time. The data entered by the user into the application is transmitted to an MT platform 400, where it is stored in a generic format for future reference.

When a saved profile is requested for application to a vehicle 405, a translation management system 410 determines the vehicle 405 type and then translates the generic user settings into the specific format required for that vehicle 405. These are transmitted to the vehicle 405 to implement the desired user preferences.

Figure 23 illustrates examples of the i-VPC 300 in use. When the user profile is requested for application to a new vehicle 415, such as a hire car, track day vehicle by a user device 420, an MT translation management system 410 maps the user profile in the generic format to a vehicle specific API. This translated profile is then pushed onto the vehicle 415, for example by wireless transmission to the requesting device or to a control module within the vehicle, where the user preferences are implemented. In this way, a vehicle agnostic driving experience can be created for the user.

Furthermore, a user may edit the settings in a vehicle 41 5 manually while in use, then copy the resulting setup to a new user profile. The user selects to copy the current, manually configured settings to a new user profile via an application on a user device 420. The vehicle specific configuration, in the language of the vehicle API , is transmitted to the MT translation management system 410, which translates the specific settings for that vehicle into generic settings. These are then saved on a database (not shown) as a new user profile for use in multiple vehicles.

The i-VPC is configured to translate vehicle settings from one OEM brand to another, instead of or in addition to associating saved settings to specific vehicles. i-VPC is available to allow fleet companies to manage their inventory, and push information to drivers (for example, via an infotainment system).

Setting up a vehicle (including seat positions, favourite radio stations, etc.) is a feature in most "high end" vehicles and is typically managed by a vehicle key fob. i-VPS allows settings to be stored remotely in a network (e.g. in a cloud network) and then transmitted back to the vehicle based on an external device such as a mobile phone.

Once the settings for one vehicle, as input by a user, have been stored i-VPS uses machine learning algorithms to "translate" those settings to any other vehicle (to the extent that such a translation is possible), including vehicles made by other manufacturers. Thus, for example, a driver can apply seat positioning in one vehicle and be confident that any other vehicle the driver enters can be configured to feel the same without having to adjust the seat manually for that vehicle ; this is achieved by understanding the build and mechanics of myriad vehicles and extrapolating preferences to apply these other vehicles. For example, a seat position is defined in i-VPS relative to distance from the foot well, distance to the steering wheel and/or ceiling of the vehicle; this definition is used to determine a value associated with seat position in one vehicle (e.g. a seat being in a setting that is equal to it being 30cm from the steering wheel) and translated to another vehicle (likewise, a seat being in a setting that is equal to it being 30cm from the steering wheel). i-VPC is agnostic to the type of vehicle.

Figure 24 shows a flow diagram of the process by which i-VPC configures different vehicles. In a first step in this example, a given driver has access to multiple vehicles 450-1 , in a first vehicle the driver adjusts the settings of "Vehicle 1 "; this, for example, is in relation to: seat position(s) ; wing mirror angle(s); throttle sensitivity; suspension adjustment; headlight angle(s) ; and more ambient settings such as map orientation on the navigation screen, temperature and media settings.

The driver's settings in Vehicle 1 are saved at a next step 450-2 to the Cloud (by means of the vehicle communicating with the Cloud, for example via a mobile device connected to the internet and to the vehicle) so as to allow the settings to be persisted. The configuration used in Vehicle 1 may be one of several that the driver wishes to retain (for example, a first set of settings for urban driving, another for track days, a third for touring, etc.).

In a next stage 450-3, the driver enters another vehicle (Vehicle "n"); this could be another vehicle by the same brand or a completely different make or model of vehicle. The driver selects a particular set of setting (e.g. urban driving) that has previously been configured 450-4.

i-VPC uses data within the persisted configuration and analyses the parameters of the unconfigured vehicle to translate (for example using pre-determined matches/translations, or by machine learning) the same settings from the original vehicle 450-5. For example, in the example of seat position , i-VPC analyses the distance between the seat, foot well and steering wheel, the seat angle and moves the position of the seat in the new vehicle to approximate (or exactly reflect) the driving position of the original vehicle in the unconfigured vehicle. In another example, in the case of media volume, the system translates a particular volume setting in Vehicle 1 (e.g. "volume level 1 1 ") into a setting in dB; the dB setting is then translated into a volume setting level another vehicle, which might be "volume level 26").

If the driver identifies that the translation of a vehicle setting from one vehicle to another is inaccurate, the driver has the option of providing such feedback. By means of a machine learning process the correct translation of the setting is identified and this correction is persisted throughout the system. i-VPC will ensure that the adjusted configuration applies to the new vehicle and "learn" from the adjustment made to improve accuracy for other drivers and/or vehicles. In a next step a determination is made as to whether or not the translated parameter (e.g. seat position) is (or is close enough) to the original configuration 450-6. If no feedback is provided by the user (or another user in the same or an analogous situation) then the translation is deemed accurate (or acceptable) 450-7. If, however, the user adjusts a translated configuration parameter, this is communicated to i-VPC and saved to the cloud (e.g. via a mobile device) at step 450-8; from this adjustment i-VPC learns - via machine learning - to correct the adjustment 450-9. As part of the machine learning process, i-VPC uses thresholds before correcting a translation to account for adjustments by users that are circumstantial or whimsical in nature.

Figures 26 outline in more detail various responses by iVPS depending on the response by a user - or lack thereof - to a configuration parameter translation.

i-VPC is configured to use settings or configurations of one vehicle and apply them to different vehicles with machine learning enabling the users of the system to hone the algorithms to improve accuracy. The application of this system is not restricted to privately-owned vehicles, it can be applied to fleet, hire and track-day vehicles.

High Net Worth individuals who enjoy high performance vehicles often take their cars on track days. To get the best performance from these vehicles it is often advisable to "set them up" to make the most of the vehicle. Access to the engineering teams who get the best out these vehicles is often difficult.

However, i-VPC allows engineering teams to share a vehicle set-up with owners of high-performance cars, and equally to extrapolate set-ups created by these engineering teams to other similar high performance vehicles, which can improve a track-day experience. Figure 25 shows a flow diagram of this particular aspect of i-VPC, in which a Formula One (F1 ) team sets up a vehicle (for example, a Ferrari) for a certain circuit in a first step 460-1 to configure a setting for that vehicle and circuit. The settings are saved and made available to users (for example, via a subscription platform for users who own similar vehicles) at a next step 460-2.

In a further stage of the process, a driver enters a high-performance vehicle (Vehicle B), either a vehicle of the kind to which the settings were generated 460-3, or another high-performance vehicle. A user that is given access to the settings (a profile) can then obtain the settings and apply the exact settings (if, for example, they own the same Ferrari as the settings) or extrapolated settings (if, for example, they own a McLaren or similar) in a next step 460-4.

If the vehicle settings relate to a vehicle that is different to Vehicle B, then i-VPC uses a machine learning process to extrapolate the vehicle settings to Vehicle B 460-5 to enable the user to drive the circuit with the settings that have been professionally configured 460-6.

Figures 26a to c show use of a machine learning process to assist translation of settings from one vehicle to another based on user feedback.

In more detail , Figure 26a shows a scenario in which a user decides not to provide feedback following translation of configuration parameters; in this case, i-VPC uses the parameters as provided by the user for that vehicle.

Figure 26b shows a scenario in which a user shares both a configuration and a fine tuning (adjustment of a parameter). In this example, once a user has set up a configuration, this is saved to i-VPC as a particular preference for this driver and the particular vehicle 470-1 , which is learnt by the i-VPC system 470-2. When the same driver enters another vehicle and selects the configuration as established in step 470-1 , i-VPC translates and implements the settings established in step 470-1 to the new vehicle in a next step, for example by means of machine learning to predict configurations for the new vehicle based on previously learned settings 470-3. The feedback can be sourced from a plurality of users, thereby to have a crowd- sourced pool of data from which to train and improve machine learning for extrapolating vehicle settings.

The driver may make a fine adjustment and sends such adjustments to i-VPC 470-4 in response to the translation. i-VPC then adds the fine tuning to the machine learning algorithm so as to improve future translations and configuration extrapolation for this user and/or vehicle (and a wider set of users and/or vehicles) 470-5.

Figure 26c shows a scenario in which i-VPC sets up a vehicle correctly using the machine learning process, and the user makes fine changes, but due to a fleeting/temporal factor these changes are not added into the i-VPC machine learning algorithm 480. Further example

The content and data management and provision system may additionally or alternatively be implemented using a layered data model. The layered approach allows for content to be pushed down from a global, national or regional level to all dealers or dealer groups within an organisation. Conversely, it allows for dealer inventory and other specific information to be drawn up to the regional, national or global level for use in a UVL. In some embodiments, the layered data model takes the form of a hierarchical structure, as described above.

The layering consists of a plurality of layers, including, for example, global, regional, market, country, dealer group, and dealer. Content may only be displayed at the level of the dealer website, but is inherited through each layer.

In the context of a dealer group, each dealer may have their own website, where some content is provided from a dealer group layer. A dealer may be able to edit some unlocked content, as well as add additional content, but the certain element s of the website will be locked. The group layer can also add content that is pre-populated, but with placeholders for dealer details. For example, a group adds a page, such as terms and conditions, which need to be substantially the same across all dealers in the group, but which will also have the correct dealer name in the appropriate places. The group would add the page in the group layer, and simply edit the page using the content management system, only needing to place a dealer name placeholder within the content. Then when the page is viewed via a dealer site, the dealer name placeholder will automatically be replaced.

Furthermore, a website may be in multiple languages. When edited at a global level, each change made in a particular default language can be translated and inherited by the other languages. This can be repeated for edits made in each layer, allowing a region based site, such as an UVL, to be built and translated at a global level, but where each region or market or other lower layer can then add their own content and fine tune the translation in line with local variations, without the need to build a completely new site each time. A region can also have one or more languages, where one is set to default. For example, the Americas could have US English and Spanish . Both would inherit content from the Global default language (English), and Global US English. US English could be defined as the default so that the Spanish language would also inherit from Regional US English as well as global US English, Global English and Global Spanish.

Arbitrary layers may be created for groups of dealers that do not necessarily for dealer groups. For example, a "zero-emissions" group may be set up to manage content for selected dealers. Dealers may therefore belong to several groupings, and inherit content from all of them.

Websites accessed by a user can be tailored to the user's geographical location, for example by showing the relevant inventory for that region. Geographic bounds can be set for a region, allowing a user to be redirected to a locally specific site. This can be based on the user's IP. The system will determine which region the user is in and automatically redirect the user to the relevant region site. Each region will show stock for dealers within that region based on a structure defined in the hierarchy/layered data model .

The layers are managed through a database structure, which gives access to users using a role based system.

An example database structure for user permissions is shown in Figure 27. Users of the system are given access to perform actions using a role based system of User Groups. For example, a high level manager can be granted 'Managerial Permissions' to edit the Tenant website, and create changes which are reflected in a number of websites lower in the hierarchy. However a salesperson at a particular dealership can be granted 'Sales Permissions', and make localised changes only. User Groups are granted access to individual permissions. User Groups are then assigned to each User. A user may have more than one User Group. Each User Group within the system may also have a level. This determines the relative rank of each user allowing lower level users to be edited by higher level users. When creating a user, it may only be possible to assign the new user to a lower level User Group. Furthermore, access to content editing may be restricted by user language, allowing, for example, a user to only edit regional data in a particular language for translation purposes, so that they can be assigned a language when created or edited.

Alongside the standard permissions each user may be granted access to any number of layers within the layered data model. This could be a single dealer website, or alternatively this could include an entire dealer group or even a Tenant website. When creating or editing a user, it is possible to assign access to any entity that the current user has access to. A user may also be granted access to any entity without the need to access all dependant connected websites. Simply having access to edit content of a certain website in the layered data model does not mean that the same user is able to edit all of the lower levels from that position in the hierarchy.

The layered data model can be implemented through a single access class, meaning that all the data is accessed in a single way. Every item of data in the system has a key comprising an "id", "owner" and "language". When loading an individual data item, the system creates a list of "owners" and "languages" from the layered data model/hierarchy. The system can then load all items that match the given id and one of the owners and languages. The result may be one or more items, which are then ordered on a website page according to owner and grouped by language. Each layer of data can then be read and condensed into a single object. The number of layers to be read and the order of precedence of the layers can be controlled. This means that, for example, when the system knows that only the bottom layer is needed, the layer order can be reversed and the layer selection limited to only one item.

For example, the page definition can include items of data which don't have overridden values. The system can therefore ignore layers that have been superseded. This means that any layer within the system can alter the basic layout of the page, but that unnecessary data is not loaded. The system does not need to know that a dealer or group edited a page, only that the last layer is returned.

The content derived from the layered data model can be based on a pod structure, as described above. An ability to pin items allows for pages to be fixed within the navigation structure while also allowing the page details to be edited.

A page within the system can be assembled from many different items of data. In the case of a grid layout, the data to describe the grid can be loaded from each layer, starting from the top. Each grid is layered over the first. This means that pods can be added, edited or repositioned within any layer. If an item is locked, then the data layer can block later updates from subsequent layers, meaning that even if an item is locked after it was edited elsewhere, it will still show the locked version. Similarly, pinning in the case of list based components prevents the order being changed.

Relating to navigation of each website, content is provided with a site map, comprising a list of data. Each item of data can be marked with a hierarchical tag comprising an 'ID', 'name' 'page ID' and 'parent ID'. Each layer of data is loaded from the top to the bottom and items with a matching 'I D' can override values from the previous layer. The hierarchical structure can then be built from the items in the sitemap, using the 'ID' and 'parent ID'. When a page is requested the sitemap is used to locate the 'page I D'. This may be done by processing the Uniform Resource Locator (URL), and reviewing keywords embedded within. The first item referred to in the URL is the index page, so the system will look for children of the 'index' with a matching 'name' for first item in the URL. When one is found, the next item in the URL is compared to its children and so on until no match is found or all elements have been matched.

Data layering allows for website pages to be created with diverse content that can be inherited by lower layers. Locking and pinning are used to allow for additional content control. The layering also allows for content to be translated and reordered, as well as for additional content to be added. Furthermore, the layering allows for inventory related content to be created at a higher level and distributed to individual sites. This could, for example, be a search pod, a main search page or even complex inventory pods such as in inventory summary. The hierarchy also allows for inventory to be drawn up from individual dealers to allow for a unified search for geographically localised sites.

All vehicles, whatever their source, can be processed into a single database. Using a unified data structure allows a single solution for a search, irrespective of client or website type. During the import process, vehicles are given a region name which is generated from the hierarchy. This allows the search to be performed using the region ID. For each group website it is possible to get the individual dealer IDs from the hierarchy/layered data model for a group and search them all.

It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

Claims

CLAIMS:

1 . A security system for permitting access to data over a network, comprising :

a database for storing data, the data having associated with it distribution rights;

a device connectable to a network for receiving:

a request from a user to access the data; and

information regarding the identity of the user;

a first rules engine for outputting a position of the user in a hierarchy of permissions for accessing the data; and

a second rules engine for outputting access permissions in dependence on the distribution rights;

wherein the security system permits the user to access the data in dependence on the outputs of both the first and second rules engines.

2. A system according to Claim 1 , wherein the first rules engine is adapted to output access permissions in dependence on the position of the user in a hierarchy of permissions.

3. A system according to Claim 2, wherein the security system permits the user to access the data in dependence on the access permissions output by both the first and second rules engines.

4. A system according to any preceding claim, wherein the second rules engine outputs access permissions in dependence on the request.

5. A system according to any preceding claim, wherein the second rules engine outputs access permissions in dependence on the information regarding the identity of the user.

6. A system according to any preceding claim, wherein the first rules engine is adapted to tag the request and/or the data with the hierarchy of permissions.

7. A system according to any preceding claim, wherein the second rules engine is adapted to tag the request and/or the data with the access permissions.

8. A system according to any of the preceding claims, wherein the first rules engine is adapted to interrogate the second rules engine to request access permissions from the second rules engine.

9. A system according to any of the preceding claims, wherein the second rules engine is adapted to interrogate the first rules engine to request the position of the user in a hierarchy of permissions for accessing the data from the second rules engine.

1 0. A system according to any of the preceding claims, wherein the first rules engine is adapted to interrogate the second rules engine in dependence on the request.

1 1 . A system according to any of the preceding claims, wherein the second rules engine is adapted to interrogate the first rules engine in dependence on the request.

12. A system according to any of the preceding claims, wherein the first rules engine is adapted to forward the request on to the second rules engine and/or vice versa.

13. A system according to any of the preceding claims, wherein the first rules engine and/or the second rules engine are logically connected to the database.

14. A system according to any of the preceding claims, wherein rules governing operation of the first rules engine and/or the second rules engine are stored in the database.

15. A system according to any preceding claim, wherein the position of the user in the hierarchy is allocated in dependence on at least one of: a user location ; a user language; a user business arrangement or position within a company / group structure; a user brand; a predefined user group; a relationship between the user and the data (for example, an owner); and information regarding the identity of the user.

1 6. A system according to any preceding claim, wherein the access permissions are determined in dependence at least one of: where said data was created ; where said data is stored; where the data is to be accessed; where the request for the data was made ; where the request for the data was received; where the owner of the data is located; whether the data is attributable to an individual ; and information regarding the identity of the user.

1 7. A system according to any preceding claim, wherein the hierarchy of permissions is configured to provide hierarchical inheritance of permissions so long as inheritance of a permission is not denied at a level of the hierarchy that is above the user, preferably wherein the hierarchy of permissions is a cascading hierarchy of permissions.

1 8. A system according to any preceding claim, wherein access to data comprises viewing access, reproduction access, publication access and/or editing access of data.

1 9. A system according to Claim 18, wherein the hierarchy of permissions is configured to provide hierarchical inheritance of edited data, and preferably to necessitate inheritance of such edited data.

20. A system according to any preceding claim, wherein the data is in the form of: data associated with at least one vehicle (for example, telemetric data); a website; content for a website (for example, inventory / stock data, media, pods, components and programs); and a report including aggregated and/or manipulated data.

21 . A system according to any preceding claim, wherein the information regarding the identity of the user comprises: a user account, preferably accessible via a process of authentication, to which user identity information is associated; and/or information regarding the type and location of a device through which the user request access the data.

22. A system according to any preceding claim, further comprising a processor for instructing the sequence in which the first and second rules engines are interrogated, so as to determining access permissions, in dependence on the data and/or the request, and preferably the type of data requested.

23. A system according to any preceding claim, wherein the system is configured to provide access to data to which the user is permitted in the event that the first and/or second rules engines determine insufficient access permissions for the requested data.

24. A system according to any preceding claim, wherein the device connectable to the network is adapted to receive requests from a service, module, application and/or device.

25. A system according to any preceding claim, wherein the device connectable to the network is adapted to receive simultaneous requests from at least one service, module, application and/or device.

26. A method of rendering a website using the system of Claims 1 to 25.

27. A method of enabling users to access and/or edit content, the method comprising:

determining a user identity and/or determining origin information associated with a user; and providing hierarchical information relating to said user based on the user identity and/or origin information associated with the user thereby to enable the user to access and/or edit content in dependence on said hierarchical information.

28. A method according to claim 27, wherein the user is enabled to access and/or edit content provided over a computer network, preferably over the internet.

29. A method according to claim 27 or 28, wherein the hierarchical information comprises a user position within a hierarchy comprising a plurality of hierarchical nodes.

30. A method according to claim 29 wherein the user position within the hierarchy is determined by at least one of: a user location; a user language; a user business arrangement; a user brand; and a user group.

31 . A method according to claim 30, wherein a user is associated with one or more user languages; user business arrangements; user brands; and/or user groups.

32. A method according to any of Claims 27 to 31 , wherein content edited by the user is automatically applied to content relating to one or more hierarchical nodes below the user position in the hierarchy.

33. A method according to claim 32, wherein content edited by the user is restricted from being edited at one or more of the one or more hierarchical nodes below the user position in the hierarchy.

34. A method according to any of claims 27 to 33, wherein the content edited by the user requires authorisation by a hierarchical node above the user position in the hierarchy.

35. A method according to any of claims 27 to 34, wherein the hierarchical information is used to determine a user permission associated with the user.

36. A method according to claim 35, wherein the user permission is a permission to edit content.

37. A method according to claim 35 or 36, wherein the user permission is a permission to access content.

38. A method according to any of claims 35 to 37, wherein a user permission is automatically applied to all users at and below the one or more hierarchical nodes the point within the hierarchy at which a user permission is applied.

39. A method according to claims 38, wherein, when a first user permission conflicts with a second user permission provided at a node below the first user permission, the first user permission overrides the user permission.

40. A method according to any of claims 35 to 39, wherein the user permission is assigned by a hierarchical node above the position of the user in the hierarchy.

41 . A method according to any of claims 27 to 40, further comprising the step of authenticating and/or authorising the user identity.

42. A method according to any of claims 27 to 41 , wherein the content comprises elements of a website page.

43. A method according to claim 42, wherein the elements of the website page comprises components, wherein each pod comprises one or more of pod elements.

44. A method according to any of claims 27 to 43, wherein the step of determining a user identity is performed by a processor, preferably as part of a server.

45. A method according to any of claims 27 to 44, wherein the step of determining origin information is performed by a processor, preferably as part of a server.

46. A method according to any of claims 27 to 45, wherein the hierarchical information is provided by a database storing the hierarchical information, preferably as part of a server.

47. A method of rendering a website, the method comprising:

requesting a website page;

determining origin information associated with the request;

providing a content hierarchy for the requested page based on the origin information ; and rendering the requested page in dependence on the content hierarchy.

48. A method according to claim 47, wherein the step of providing a content hierarchy for the requested page based on the origin information comprises determining a position of the requested website page within a hierarchy comprising a plurality of hierarchical nodes.

49. A method according to claim 47 or 48, wherein the content hierarchy is a cascading content hierarchy, preferably cascading up and/or down the hierarchy.

50. A method according to claim 47 or 48, wherein the content hierarchy comprises inherited access permissions.

51 . A method according to any of claims 48 to 50, wherein the content hierarchy comprises a list of one or more components and the relative positions of the one or more components on the website page.

52. A method according to claim 51 , further comprising arranging the one or more components relative to one another.

53. A method according to claims 51 or 52, wherein the relative positions of the one or more components are determined by a device type of the device from which the request originates.

54. A method according to claims 51 to 53, further comprising the step of retrieving the one or more components from a pod service.

55. A method according to Claim 54, wherein the pod retrieval occurs asynchronously.

56. A method according to any of claims 47 to 55, wherein the website page is rendered in accordance with the content hierarchy.

57. A method according to any of Claims 47 to 56, wherein the content is accessed and edited in accordance with a method according to any of Claims 26 to 46 and/or by means of a system according to any of Claims 1 to 25.

58. A method of controlling data requests in a multi-tenant platform, the method comprising:

determining origin information associated with a data request;

determining user information associated with the data request; and providing hierarchical information relating to said data request.

59. A method according to any of claims 26 to 58, wherein the origin information comprises at least one of: a request location; a request language; a requesting device type; and an identity of the user from whom the request originated.

60. A method according to claim 58 or 59, further comprising determining permissions associated with the user.

61 . A method according to claim 60, wherein the permissions are determined by a position in a hierarchy from which the data request originates.

62. A method according to claim 61 , wherein the permissions are inherited from parent nodes within the hierarchy.

63. A method according to claim 62, wherein the permissions cascade within the hierarchy, and preferably both up and down the hierarchy.

64. A security system for permitting access to data over a network, comprising :

a database for storing data;

a device connectable to a network for receiving:

a request from a user to access the data; and

information regarding the identity of the user;

a rules engine for outputting access permissions in dependence on a position of the user in a hierarchy of permissions for accessing the data; and

wherein the security system permits the user to access the data in dependence on the output of the rules engine.

65. A system according to Claim 64 adapted to implement the method of any of Claims 26 to 63, wherein the rules engine is the first rules engine.

66. A security method for permitting access to data over a network, comprising:

providing a database for storing data;

receiving at a device connectable to a network:

a request from a user to access the data; and

information regarding the identity of the user;

outputting , by means of a rule engine, access permissions in dependence on a position of the user in a hierarchy of permissions for accessing the data; and

permitting the user to access the data in dependence on the output of the rules engine.

67. A method of rendering a website according to the method of Claim 66.

68. A security method of permitting access to data over a network, comprising :

providing a database for storing data, the data having associated with it distribution rights; receiving, at a device connectable to a network:

a request from a user to access the data; and

information regarding the identity of the user;

outputting , by means of a first rules engine, a position of the user in a hierarchy of permissions for accessing the data; and

outputting , by means of a second rules engine, access permissions in dependence on the distribution rights and/or the request; permitting the user to access the data in dependence on the outputs of both the first and second rules engines.

69. A method according to Claim 68 using a system according to any of Claims 2 to 25.

70. A system for rendering a website comprising:

means for requesting a website page;

means for determining origin information associated with the request;

means for providing a content hierarchy for the requested page based on the origin information; and

means for rendering the requested page in dependence on the content hierarchy.

71 . A system for rendering a website implementing the system of any of Claim 1 to 25.

72. A web server adapted to implement the method of any of Claims 26 to 63, 66 to 68 and/or 69.

73. A computer program product comprising software code adapted, when executed, to perform the method of any of Claims 26 to 63, 66 to 68 and/or 69.

74. A system substantially as herein described and/or as illustrated in the accompanying drawings.

75. A method substantially as herein described and/or as illustrated in the accompanying drawings.

76. An authorisation system for permitting access to data over a network, comprising:

a device connectable to a network for receiving:

a request from a user to access the data; and

information regarding the identity of the user;

a rules engine for outputting access permissions in dependence on the distribution rights; wherein the authorisation system permits the user to access the data in dependence on the output of the rules engines.

77. A system according to Claim 76, wherein the rules engine is adapted to output access permissions in dependence on the request.

78. A system according to Claim 76 or 77, wherein the rules engine is adapted to output access permissions in dependence on the information regarding the identity of the user.

79. A system according to any of claims 76 to 78, wherein the rules engine is adapted to tag the request and/or data with access permissions.

80. A system according to any of claims 76 to 79, wherein the access permissions are determined in dependence on at least one of: where said data was created; where said data is stored; where the data is to be accessed; where the request for the data was made; where the request for the data was received; where the owner of the data is located; and whether the data is attributable to an individual.

81 . A system according to any of claims 76 to 80, wherein access to data comprises viewing access, publication access, reproduction access and/or editing access of vehicle data.

82. A system according to any of claims 76 to 81 , wherein the data is in the form of: data associated with at least one vehicle (for example, telemetric data); inventory / stock; commercial data; and a report including aggregated and/or manipulated data.

83. A system according to any of claims 76 to 82, wherein the information regarding the identity of the user comprises: a user account, preferably accessible via a process of authentication, to which user identity information is associated; a vehicle identifier to which a user is associated; and/or information regarding the type and location of a device through which the user request access the data.

84. A system according to any of claims 76 to 83, wherein the system is configured to provide access to data to which the user is permitted when the rules engine determines insufficient access permissions for the requested data.

85. An authorisation method for permitting access to data over a network, comprising:

providing a database for storing data having associated with it distribution rights;

receiving at a device connectable to a network:

a request from a user to access the data; and

information regarding the identity of the user;

outputting , by means of a rules engine, access permissions in dependence on the distribution rights; and

wherein the authorisation system permits the user to access the data in dependence on the output of the rules engines.

86. A method according to Claim 85 using the system of any of Claims 77 to 84.

87. A method of controlling the transfer of vehicle data in different geographic locations, the method comprising :

determining a geographic location associated with a request for data;

checking permissions applicable to the transfer of said requested data from or to said determined geographic location ; and

responding to said request according to said applicable permission.

88. A method according to claim 87, wherein responding to said request comprises transmitting said requested data when said applicable permission permits said transfer of data from or to said determined geographic location, preferably wherein the data is transmitted from a server.

89. A method according to Claim 87 or 88, wherein responding to said request comprises preventing transmission of said requested data when said applicable permission does not permits transfer of data from or to said determined geographic location.

90. A method according to any of claims 87 to 89, wherein the vehicle data is tagged with metadata indicating the permissions applicable to said vehicle data.

91 . A method according to any of claims 87 to 90, wherein the geographical location information comprises information indicating the geographical location where said data was created.

92. A method according to any of claims 87 to 91 , wherein the geographical location information comprises information indicating the location where said requested data is stored.

93. A method according to any of claims 87 to 91 , wherein the geographical location information comprises information indicating the location where the request for data was received.

94. A method according to any of claims 87 to 93, wherein the geographical location information comprises information indicating the location from which said request for data originated.

95. A method according to any of claims 87 to 94, wherein the geographical location information comprises information indicating the location of the owner of the requested data.

96. A method according to any of claims 87 to 95, wherein the permissions are further determined from a position within a hierarchy from which the request originates.

97. A method according to claim 96, wherein the hierarchy comprises at least one of: one or more vehicle dealerships; one or more vehicle dealership groups; one or more regions; one or markets; one or more manufacturers; or a member of the public.

98. A method according to any of claims 87 to 97, wherein the responding to said request further comprises manipulating said requested data, before transmitting said requested data, in dependence on said applicable permission.

99. A method according to Claim 98, wherein manipulating said requested data comprises filtering said requested data so as to remove data for which the applicable permission does not permit transmission of the requested data and/or anonymising said requested data.

1 00. A method according to any of Claims 87 to 99, wherein the vehicle data is aggregated from a plurality of sources, and preferably from a plurality of vehicles.

1 01 . A method according to Claim 1 00, wherein the vehicle data is aggregated by means of machine learning.

1 02. A method according to any of Claims 87 to 1 01 , wherein the request for data is a request for transmission of the requested data between devices across a network.

1 03. An authorisation system according to any of Claims 76 to 84 arranged to control the transfer of vehicle data according to the method of any of Claim 85 to 1 02.

1 04. A system for controlling the transfer of vehicle data in different geographic locations, the system comprising :

means for receiving a request for access to data, preferably over a network;

means for determining information associated with the requested data;

means for checking permissions applicable to the request; and

means for providing the data in response to the request in dependence upon said applicable permission, preferably over a network.

1 05. A system according to Claim 1 04, wherein the means for providing the data is adapted to transmit said requested data when said applicable permission permits said transfer of data from or to said determined geographic location .

1 06. A system according to Claim 104 or 1 05 wherein the vehicle data is tagged with metadata indicating the permissions applicable to said vehicle data.

1 07. A system according to any of Claims 1 04 to 1 06, wherein the geographical location information comprises at least one of information indicating the geographical location where : said data was created; said data is stored; the request for data was received ; and where said request for data originated.

1 08. A method for controlling access to data, the method comprising :

receiving a request for access to data;

determining information associated with the requested data; checking permissions applicable to the request; and

responding to said request according to said applicable permission.

1 09. A method according to claim 108, wherein the information relates to at least one of: the creation of the data; the location where the data was created; the location where the data is stored; the ownership of the data; and the data format.

1 1 0. A method according to claim 108 or 109, wherein the permissions are determined based on the information associated with the requested data.

1 1 1 . A method according to any of claims 108 to 1 10, wherein the permissions are determined based on at least one of: a position within a hierarchy from which the request originates; the location from which the request originates; the location where the data is stored; the data ownership; and the data format.

1 1 2. A method according to any of claims 1 08 to 1 1 1 , wherein the request for access to data comprises identity information associated with a user from whom the request originates and/or geographic information of the location from which the request originates.

1 1 3. A method according to any of claims 108 to 1 12, wherein the step of responding to the request comprises retrieving the data from a database.

1 1 4. A method according to any of claims 108 to 1 13, wherein the data includes telemetry data collected from a vehicle.

1 1 5. A method according to any of claims 1 08 to 1 14, wherein the data comprises aggregated and/or anonymised data.

1 1 6. A method according to any of claims 1 08 to 1 1 5, wherein the request for access to the data is recorded for reference.

1 1 7. A method according to any of claims 108 to 1 1 6, wherein the request is a request for transmission of the data across a network.

1 1 8. A method according to claim 1 17, wherein the response comprises the transmission of data across the network.

1 1 9. A system for controlling access to data, the system comprising :

means for receiving a request for access to data;

means for determining information associated with the requested data;

means for checking permissions applicable to the request; and

means for providing the data in response to the request in dependence upon said applicable permission.

120. A web server adapted to implement the method of any of Claims 85 to 1 06 and/or the method of any of Claims 1 08 to 1 18.

121 . A computer program comprising software code adapted when executed to perform the method of any of Claims 85 to 1 02 and/or the method of any of Claims 108 to 1 1 8.

122. A method substantially as herein described and/or as illustrated in the accompanying drawings.

123. A system substantially as herein described and/or as illustrated in the accompanying drawings.

124. A method for configuring the settings of a vehicle, comprising :

storing on a memory one or more first vehicle settings configured for a user in relation to a first vehicle;

accessing a database containing vehicle parameters pertaining to a plurality of vehicles, including said first vehicle and a second vehicle; and

translating one or more of said first vehicle settings into one or more corresponding second vehicle settings for said second vehicle by analysing said first vehicle settings against parameters of the first vehicle thereby to determine corresponding said one or more vehicle settings for said second vehicle based on parameters of the second vehicle.

125. The method of Claim 124, further comprising establishing a data connection with a computing device of said second vehicle, and applying said second vehicle settings to said second vehicle.

126. The method of Claim 125, further comprising accessing said computing device of said second vehicle via said established data connection.

127. The method of Claim 125 or 126, wherein said computing device is connected to the engine management system (EMS) of said second vehicle.

128. The method of any of claims 124 to 127, further comprising configuring one or more vehicle settings of said second vehicle by applying the second vehicle settings thereby to correspond with said one or more first vehicle settings stored on said memory

129. The method of any of claims 124 to 128, further comprising storing on said memory at least one profile containing said one or more first vehicle settings, preferably wherein said memory is arranged to store multiple profiles, for example wherein each profile contains one or more vehicle settings relating to a particular vehicle.

130. The method any of claims 1 24 to 129, further comprising identifying the second vehicle to which second vehicle settings corresponding to the first vehicle settings are to be applied prior to accessing said database.

131 . The method any of claims 1 24 to 130, wherein said identifying further comprises receiving a request for one or more of said first vehicle settings to be applied to said second vehicle.

132. The method of any of claims 124 to 131 , further comprising creating a further profile containing said determined second vehicle settings, and storing said further profile on the memory so as to have it available for future use.

133. The method of any of claims 124 to 132, wherein said profile relating to the first vehicle does not contain one or more vehicle settings configured for said user in relation to said second vehicle.

134. The method of any of claims 124 to 133, wherein analysing said first vehicle settings further comprises using the first vehicle parameters to standardise said first vehicle settings into values or units that can be applied to the second vehicle parameters, for example SOI units.

135. A method according to any of claims 124 to 134, wherein the one or more vehicle settings are stored in the memory in a standard data format.

136. A method according to any of claims 124 to 135, further comprising translating the one or more vehicle settings for the designated vehicle into a format compatible with the designated vehicle.

137. The method of any of claims 124 to 136, wherein a machine learning algorithm is configured to learn said first vehicle settings configured for the user in relation to the first vehicle.

138. The method of Claim 137, wherein translating one or more first vehicle settings further comprises using the machine learning algorithm to predict one or more of said corresponding second vehicle settings.

139. The method of any of claims 124 to 138, further comprising receiving feedback from the (or a) user of the second vehicle to which the second vehicle settings have been applied so as to improve the translating of one or more vehicle settings.

140. The method of Claim 139, wherein the feedback includes adjustments to the second vehicle settings made by the user when using the second vehicle.

141 . A method according to any of claims 124 to 140, wherein the vehicle settings include settings configured to control vehicle dynamics of the second vehicle, for example to restrict the performance of said second vehicle.

142. A method according to any of claims 124 to 141 , wherein the vehicle settings comprise telemetry settings.

143. A method according to any of claims 124 to 142, wherein the vehicle settings comprises settings relating to the gear ratio of the vehicle's engine.

144. A method according to any of claims 124 to 142, wherein the vehicle settings comprises settings relating to the sensitivity of one or more vehicle controls, for example the throttle, steering, braking or suspension.

145. A method according to any of claims 124 to 144, wherein the vehicle settings comprises in car entertainment (ICE) settings.

146. A method according to any of claims 124 to 145, further comprising selecting the vehicle settings for the second vehicle from a plurality of selectable vehicle settings available for said second vehicle, for example wherein said plurality of vehicle settings are made available by the manufacturer of said second vehicle, for example being available and/or accessible online.

147. An apparatus for configuring the settings of a vehicle, comprising :

means for storing on a memory one or more first vehicle settings configured for a user in relation to a first vehicle ;

means for accessing a database containing vehicle parameters pertaining to a plurality of vehicles, including said first vehicle and a second vehicle ; and

means for translating one or more of said first vehicle settings into one or more corresponding second vehicle settings for said second vehicle by analysing said first vehicle settings against parameters of the first vehicle thereby to determine said one or more corresponding vehicle settings for said second vehicle based on parameters of the second vehicle.

148. A system for configuring the settings of a vehicle, comprising:

an apparatus according to Claim 147; and

a database containing vehicle parameters pertaining to a plurality of vehicles, including said first vehicle.

149. The system of Claim 148, further comprising a communications interface operable to provide a data connection with a computing device of at least one of said first vehicle and second vehicle, for example via the On Board Diagnostics (OBD) port in said vehicle.

1 50. The system of Claim 148 or 149, further comprising a mobile computing device operable to communicate with the database and, optionally, the communications interface of Claim 149.

1 51 . The system of Claim 149 or 150, wherein the communications interface is a telematics unit.

1 52. A device having a memory on which is stored at least one profile containing one or more vehicle settings associated with one or more vehicles associated with a user.

1 53. A vehicle comprising a memory on which is stored at least one profile containing one or more vehicle settings associated with one or more vehicles associated with a user.

1 54. A system for rendering a website by means of the system of any of Claims 1 to 25.

1 55. The system of Claim 70 adapted to render a website by means of the system of any of Claim 1 to 25.