GB2552771A - Content management system - Google Patents

Abstract

This application is for maintaining websites for a group of related businesses 20, such as a network of car dealerships. The group of related businesses are arranged in a hierarchical structure, and group members are assigned to a particular level within the hierarchy 70, 75, 80. They also have sub-groups 75a, b and c of certain group members 80a-g. The group members position determines which data and content it has access to 65. The member at the top of the hierarchy 70 has access to all content and provides permissions for group members lower down the hierarchy to access or edit content. It also uses a method that can control the transfer of vehicle data in different geographic locations by first determining a geographic location associated with the request for data, checking the permissions applicable to the transfer of the data, and responding to the request according to the permissions.

Description

(54) Title of the Invention: Content management system

Abstract Title: Maintaining websites for groups of related businesses by using an intelligent cascading hierarchy service (57) This application is for maintaining websites for a group of related businesses 20, such as a network of car dealerships. The group of related businesses are arranged in a hierarchical structure, and group members are assigned to a particular level within the hierarchy 70, 75, 80. They also have sub-groups 75a, b and c of certain group members 80a-g. The group member’s position determines which data and content it has access to 65. The member at the top of the hierarchy 70 has access to all content and provides permissions for group members lower down the hierarchy to access or edit content. It also uses a method that can control the transfer of vehicle data in different geographic locations by first determining a geographic location associated with the request for data, checking the permissions applicable to the transfer of the data, and responding to the request according to the permissions.

80a 80b

80c 80d

75c \

80g

Figure 2

At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy.

1/24 /

\· \

12 17

Figure 1 >10

2/24 t^·

Ο

J.

I

Figure 2 ό

CM

3/24

Figure 3

4/24

12 17

ίΖϊ ίΤ) τ·*·*ί υΊ vi ω

i_ cuo

ο.

ο ω :Ο

5/24

12 17

Figure 5

6/24 _Asssssssss«e\ &

>fcX·

Os sx

LO n*>

A δ· t $

* ^s\ $ A $ \x> $

UXJ

Ϊ*’ ^XX· £

O

X>' <«χχχ· $ V § \XXXXXXXXXXA ¥

·χχχχχχχχχχχχ«.χχχχχχχχχ\χ ^»ssssssssssssssssssssss\

I ·!-..

c\ \XXXXXXXXXXXXXXXXXXXXXXA >j.ssssssssssssssssssssss\

12 17

Ο..

«XsXXXXXXXXXXXXXXXXXXXXA •AA §* .>

$iAA

AxXXXXXXXXXXXXXXXXXXX ;^XXXXXXXXXXXXXXXXXXXXXX\ _$xxxxxx·^:

.sssssssssssssssssssssssy;

$-XXXXXXXXXXXXXXXXXXXXXX«

ο.

CSJ ^XXXXXX^· •SSSSSSSSSSSSSSSSSSSSSSSSJ.

o cc xxxxxxxxxxxx < I i 1

A Xs«!x· \x.«Ax xv>

XXXXXXXXXXXXXXXXX«

XXXXXXXXXXXXXXXXXX-XXXXX

^.XXXXXXXXXX^; :% xxxxx' S:

s

Sx •XX .

ΪΧ

V-X «*$ ·*><

XXX &

V·

AAA

LTi

Lf!

rM

XC o

'to

Lfi ν~Ί

Figure 6 «Xsssssssssv.

vssssssssssv.

7/24

Figure 7

8/24

12 17

Figure 8

9/24

12 17

Figure 9

10/24 'r'

1_ £

2? Hi £ Ά

JS δ v f.u υ o

	t·· £ <7	fU
:C Q		$ *3. .....£ c
'-w «5	I	= £
—.	Ϊ;	$ Φ
o L>	£	a| LU

c	$ ·*=ί ( 2> ®	c
Ο τ U~> £	.2 -4-x Ci
js i:	) t c	II?
O	:¾ Φ o	o
U T .......	$ LU O	u

12 17

'Xssssssssssssssssssssssssssssssssssssssssssssssssssssss'*'

tn ο

'r-i

Figure 10

11/24 s

	Ί Λ-·| \-Wk^nM*&		0 0
	| 5; ,¾ |	in	fN
0	:	cr>
0	>hn	··’ : rf
>H \	ii 'f 5 < 33 x c x :		:::1

lA

Ο <N

OS

ΓΜ5

··& 0 $-·;

\\ν^.Χ»Μ»£

SZ) fM in UK CM ’

AWM^^r

I L4i

X O |ϊ H £4:.

. «vX^vwwww;

I'll:

W> H: $ $! « C> ·?. $ φτ & $

O tn

Csl «uMvnwwi

Ns«Sfcw»w»w$ Xss%sS\\\\»wi :O1 r^· cm :

O o

cm

ΛΑ·· *

V

V.' >

s ,Sl

S \ i : .& V $ I

:\ & $ :§: :

.SSS^SSS^SW^ $ $ i >< ϊ Xn v: <

g M un o

CM in f%x CM ' §1 w zs 3 sbWsri ,,,,,.

'·»Λ:ΐι·»·*ιιί Xss'XssssxSsS^' ftl h-:s

Ra.^; 'Χν'ΛνΛ’Λ'νΛ’} &

^WkWkWkWAWk'kWk'A

	1	5 :.’	O
O ,--	:$ 0	J tri	O
00		§ 0Q	CM
CM	1	| CM

sssssssv*: $λλ w.%\ ·::

ssssssssssssss·

νΛ-λγΛίΜνΛ

.sssss-X

-: X......

·Λ > A 3 S := 3: I .<$ ω

i_ cuo i §· x $: X :<<· ; S' S^: $ $ Ϊ $ Φ cS : sx it; y

•44

12/24

330

12 17

325

310

315

320

Figure 12 &

13/24

W «λ

TS3

Ο

α.

«3 y*

Ο

Οϊ

Ο £ C Φ « <Λ ο $&

'S% ,§ ·>.

£ a>

&L ε~ <3 €£ φ

XxS •S3 <

,& 3§
S	o
«c
s> Sax

&L?

··«&

&>

££

*.%»»< *ΑΑ·Χ· *.«Χ Α-ΛΑ.ν.ν»»*

Χ'«ΧΧΧ'.Χ/ΧΧχ.«.·Α S·*» :χ.ΧΧ;*·Χ·Χ··Χ '♦ ♦'#*χ w * ν * § Λ $

-ν- S ·»«*.·$

X X Χ'Χ' ·Χ X Χ-.Χ.ΧΧ X X Λ

XX·* ♦♦•♦•U S vt*» XX Α·Α· « *s&

jfft £λ \s·· sS>

•vi<

·<£* .: $$·

«.««AAA ννν */ * *·.«· Χ',χ.χ.Χ XX

V ♦ ΛΑ Λ·.!»Λ· ι>

S, >

•ώ Βί ·χ> ά; *} -X! §> Λ' jS $

I ί£ λ* Α Α·χ· X XX X A Α· *.Χ.Χ Χ·Α Α Λ· X X XX A « & y Ο :§χ »χ ο ?S *» *&y * * * ^*.W^;<*:*****.·*;* *·*·*'*·«·*****·«'*.$* * **»Χ*νν***Λ' &

S³· s£

3$

V>

s%.

Figure 13 «I

X.XX.X X V* «

a·.«♦♦ X i a·;*.* x.x.xx xx **X'K_:x x ;*;♦ xx «·χχ a.*· .«xx x-x·:*♦:.«»xxx<* ♦*** x·;*:*♦.·» χχχ·χ>.«.«.

v*XXX X X .*'^· X X XXX Χ.·«·ΧΧΧΧ;Χ^,Χ·*'Χ'*·Χ·ΧΧ'Χ· VX XXX X

♦.«•XX χ·χ·.«» ♦ x .x x- * χ χ.χχχχ·;*;* x x x xx-.** χ·χ χχ·χ·;*.χ ♦♦ x xx .** * * sis o

« :«s

Ϊ3

G..

14/24 «

φ {/>

¢8

SK

3>

X

Φ <» ts ©

t 'd^-

15/24

X \ i Request is rejected j X

12 17

Denied

Request browser// mobile device for i

1111111111111111111111111111111111^ content

	f
Location and metadata from request evaluated
iCHS passes information to contracts / licencing service
/ / /	: / : / ; / : / ............................

Legally and

Approved contractually approved ^x request _Z ^z : Log of request in \ raw format

Figure 15

iCHSq sitemap s strut	ueries ervice for lure
iCHS que service fc base hierarchic sysl	;ries pod r content d on a I tagging :em f

/ iCHS delivers data to \ j angular front end for \ presentation processing / \l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l:l::/-^:

16/24

SS

A'A A' <' ·!«! ++ A A A + + A+ Τ'»»·»***!»*'** »·#*'» i S j·»*#'» Ιί·»»-*·*#»'»»'»*·!»»*» A'S T X +,A'A A ++· A'+jA W + + + Α'Χ !«!*'«· A’Α Τ + +Α A A V + Α+Α V + A A A' ·+ Τ * '* Α' <£ * ί a > &

> Μι

JR

ΑΑ Α'Λ'.* *ί>Α SS¹ * * * Α S' X A. A A A'V * XA* V X Ά ί A S Α· X A Α» S' X* *Λ A' V * A A A .«i * * i AS S' * *ix s S' X* AS ' X X A S ΑΧ X ΧΆ AS S' XX A Λ -W XX ASA * X XS A A * A Ά A' A &

χχ l·*:*: >: x >Λα:α·χχ χ +^ί : x x » « -» « X'M :4»:*. x x v* ί—χ x x a:a a: x x » < » « χ<Ί t^·

taw· •S3» ss £S sjwA is

a.

o

o y+w+

:*:aa:*-x»:« ♦ *·κ x :« **· >:x xx * »:« x :♦:♦♦:*-xx < » *:κ χ »*:*-κ«·χ·α:*α:·χ :<>♦:«» «

H SIX A * ΉΗΧΧΧ4’1!·«:

+ + + &.»:+ + *:+:.>r + + + +:+:,s< + + + + ,χ.+++ + +s$t++++·»:+ + +++: ++ +++-X ++++

A «-ΚΊΙ A A » -STM·*· A A A 4i XX +: + St XX + A A SC X ·♦ A *'StSt·*

Figure 16a $&

17/24 tO

Ό

ί.'.'

,.α

ΚΧ ,α «ί?

S3

Χ3

*.*> ίί λν Χί,ΛλΑΑΑΑΑΛ Χ

·,«.«**** ΐ·* ♦Ψί'ίίΦ,'Χί. * i.KXXXj.StS.'S ΐΚ'ϊί ίϊ'ίί'ί.Ϋ'ίΆΐ.ΑΑΑΑΑ ΑΑΑΑ XX Λ'ί.Ψ.Ή' ΐϊ * » ΐ·>>ΑΑ> ΑΆ XX X

S

0£

Figure 16b

18/24

12 17

Denied

Request is rejected /

/ Telemetry from \ ' vehicle and mobile \ combined by native i \ mobile app /

/ . . \ /Log of request in raw\ \ format

Figure 17

19/24

O .... LA ··-m iA

CM

φ

iA <A

CM

o co

Figure 18

20/24

12 17

Lf) tn

21/24

22/24

12 17

Ο ο

ο ‘55 ο

£Σ

CO εα α>

ο ε~ ω

ο xr α>

>· ο

-t—4

Figure 21

Ο

CQ ι_η r* co

23/24

LD t—I

TO g

tx to _ TO o c: o

O £L c to i~. to a*

Z2 C

TZ ° TO '43 <f> «3 TO TO Φ TO ~s O .TO TO x: <

C

JxC o „ TO £ XJ TO Ό AS to to 0) o

CL o> ™

C TO>

CO CO LU CM CO

to

TO +~<

.£ j?a>

A= y) Ό 'C

O

O £~ TO <X>

CL

X3 C +- O TO ys 03 φ TO φ ?> o 8 §« > T~ to +-» £

o o cS c o ij '4= TO 3> '05 C £λ° θ *- CL e to _ E c £3 _.

co co lu c\i co + i_n τ—i --. / '—

.+-.

o

Sx

CL &

TO

CL «4 X5 TO TO TO TO CO

T3 jTO o

O > «3

TO ^OT > .<&

□

12 17

TO

-cr

IS TO « . to q ω ‘ O '7^ +-*

UJ _ω ’fe ¢= !” g> g §~ >

’to

TO

TO

Ct fc:

o

B TO O

£S

TO TO TO *T3 2 >v to

Ό

Ja£

O

TO o

CM ok to

TO x;

W

TO

ΊΣ3

CM-C

Figure 22

24/24

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 present invention, there is provided a method for controlling data requests in a multi-tenant platform, the method comprising: determining origin information associated with the data request; determining user information associated with the data request; and providing hierarchical information relating to said data request.

Also provided is 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.

Also provided is a method for rendering a website, the method comprising: requesting a website page; determining origin information associated with the request; determining a content hierarchy for the requested page based on the origin information; rendering the requested page in dependence on the content hierarchy.

Optionally, the hierarchical information comprises a user position within a hierarchy. Optionally, edited content is automatically applied to one or more hierarchical levels below 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 dependent on the user position within the hierarchy.

The invention may 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.

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.

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

According to another aspect of the present invention, there is provided a method of controlling the transfer of vehicle data in different geographical locations, comprising: receiving a request for data; determining geographical location information associated with said request for data; checking permissions applicable to the transfer of said requested data from said determined 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 geographical location.

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

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

Preferably, 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.

An illustrative example of this is the collecting of telemetry data from vehicles sold to a user through a dealership and bidirectional use of this data to, for example, 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 telemetry data from the vehicle that will allow it 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.

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.

For example, in a car 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 an aspect of the invention there is provided a method of configuring the settings of a vehicle, comprising: storing on a memory at least one user-profile containing one or more vehicle settings for one or more vehicles associated with the user; establishing a data connection with the engine 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.

Thus, the invention provides a method of 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 service 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.

Optionally, the user-profile may be accessible by the user of the vehicle when inside or near to the vehicle. The memory may be provided in a portable device, for example a key fob. 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.

Optionally, the one or more vehicle settings for each associated vehicle may be stored in the memory in a standard data format, and the vehicle settings for a designated vehicle translated the user-settings for the designated vehicle into a format compatible with the designated vehicle.

Optionally, the data connection may be established via the On Board Diagnostics (OBD) port of said designated vehicle, for example wherein a dongle is connected to said OBD port. Preferably, a wireless connection may be established with the OBD port, for example via the dongle.

Optionally, the vehicle user-settings may 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 I steering sensitivity. The vehicle user-settings may comprise telemetry settings and/or in-car entertainment (ICE) settings. The vehicle settings for a designated vehicle may be selected 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.

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.

According to another aspect of the present invention, there is provided a method of 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 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 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; means for determining origin information associated with a user; and means for 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.

According to another aspect of the present 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.

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 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.

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 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 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 15 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.

According to another aspect of the present invention, there is provided a method of 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 in response to the request in dependence upon said applicable permission.

According to another aspect of the present invention, there is provided a method of configuring the settings of a vehicle, comprising: storing on a memory at least one userprofile 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, further comprising 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,.

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

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

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.

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 userprofile 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 io platform to automotive manufacturers and their distribution networks as well as independent retailers, service networks and associated industry partners and endconsumers 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, iCHS 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 endconsumers. 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 endconsumers in a B-B-C context. Vehicle settings may be configured via an Intelligent Vehicle Profile Configurator (i-VPC).

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 of 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;

Figure 5 schematically illustrates 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 11 shows a logical diagram of the platform showing the iCSH and iDPS;

Figure 12 illustrates a more detailed view of the iCHS and iDPS 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 16a and 16b show sequence diagrams illustrating example sequences of events relating to posting data to the platform and accessing data stored in the platform;

Figure 17 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 19 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 example of data being input to a car by a user;

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

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

Figure 23 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 10. 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 io 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 100. 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 110. Each dealer group 110 comprises one or more dealers 115. The hierarchical level immediately below the tenant 70 comprises a sole dealer 115 and three dealer groups 110.

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 120 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 120 comprises one or more dealer groups 110. The dealer groups 110 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 120. 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 110 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 110 manages one or more individual dealer websites 115. The dealer group 110 may impose further specific restrictions on the individual dealer websites 115, for example in relation to the dealer group brand, or in relation to the specific location of each dealership.

iCHS

Figure 5 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 125 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 110 and any subsidiary dealer websites 115 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 110. 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 115 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 115 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.

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 140 have permission to add custom content, such as pods on a website template. DG1 130 is responsible for approving D1 145 and D2 150 custom content. DG2 135 is responsible for approving D3 140 and D4 155 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 150 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 podbased website template.

A group member website 160 is assembled from a collection of pods 165 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 165 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 160 suitable for viewing on a computer screen, such as a desktop or laptop display. In this example, the pods 165 are arranged into groups 170 and subgroups 175 for display in a widescreen format. Figure 8 illustrates an example of a pod arrangement for a website 160 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 180 is in the form of a text field. The pods 165 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 180. 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 }

] }

T

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: 0131 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: 0141 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 ‘ID’, 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 ID’. 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 ID’. 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 ‘iDPS’) 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 11 shows a logical diagram of the platform showing the iCSH 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 195, a dealer website 200, a content management system 205, or a service booking 210. The data for each of these frontend 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 215 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 11 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 215 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 11. 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 iCHS 125 and iDPS 295 interacting with various services. In this example, the services are: a rendering service 310, 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 iCSH 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 to view 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, an Augmented Intelligence Data Permissions service (AI-DPS or iDPS) 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 16a 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 iDPS 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 17 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 18. 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 sits between the database on which the collected data is stored and the iCHS 125. 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 110 and individual dealer 115, 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 iDPS 295, and only data which the recipient is entitled to receive gets transmitted to that recipient.

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 20. 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 21 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 io 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 22 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 415 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.

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 23. 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 ‘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 ID’. 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.

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 (22)

CLAIMS:

1. 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 said determined geographic location; and responding to said request according to said applicable permission.

2. A method according to claim 1, wherein responding to said request comprises transmitting said requested data when said applicable permission permits said transfer of data from said determined geographic location.

3. A method according to claim 1 or 2, wherein the vehicle data is tagged with metadata indicating the permissions applicable to said vehicle data.

4. A method according to any preceding claim, wherein the geographical location information comprises information indicating the geographical location where said data was created.

5. A method according to any preceding claim, wherein the geographical location information comprises information indicating the location where said requested data is stored.

6. A method according to any preceding claim, wherein the geographical location information comprises information indicating the location where the request for data was received.

7. A method according to any preceding claim, wherein the geographical location information comprises information indicating the location from which said request for data originated.

8. A method according to any preceding claim, wherein the permissions are further determined from a position within a hierarchy from which the request originates.

9. A method according to claim 8, 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; or one or more manufacturers.

10. 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.

11. A method according to claim 10, 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.

12. A method according to claim 10 or 11, wherein the permissions are determined based on the information associated with the requested data.

13. A method according to any of claims 10 to 12, 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.

14. A method according to any of claims 10 to 13, wherein the step of responding to the request comprises retrieving the data from a database.

15. A method according to any of claims 10 to 14, wherein the data includes telemetry data collected from a vehicle.

16. A method according to any of claims 10 to 15, wherein the data comprises aggregated and/or anonymised data.

17. A method according to any of claims 10 to 16, wherein the request for access to the data is recorded for reference.

18. A method according to any of claims 10 to 17, wherein the request is a request for transmission of the data across a network.

19. A method according to claim 18, wherein the response comprises the transmission of data across the network.

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

5 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.

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

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

Intellectual

Property

Office

Application No: GB1611518.0 Examiner: Dr Fraser Stewart