TECHNICAL FIELD

[0001] Various embodiments relate to a server and a method for facilitating recommending a vehicle.

BACKGROUND

[0002] Safety and comfort may be highly important in mobility, especially for a user with a medical condition or is under medication. The medical condition may become common particularly in societies with aging populations. Various factors from environment, for example, temperature, congestion, etc., and from vehicles, for example, safety features, maintenance, etc., may affect the user’s personal comfort in the mobility. Therefore, the user may need to select a vehicle for purposes of buying, renting or booking, by considering overall conditions of the user, the environment, and the vehicle.

[0003] In this regard, the user with the medical condition may need to explicitly state whether he/she has specific needs to ensure a safe and comfortable travel. However, the medical condition may be private information which may not be confidently shared with a third party, and thus not be openly shared with an agent providing mobility service.

[0004] On the other hand, the agent providing the mobility service may need to directly ask the user about his/her medical condition to provide the safe and comfortable travel. However, such asking may cause discomfort and annoy the user.

[0005] In addition, in some instances, the user with the medical condition may often be unaware of mobility restrictions relevant to his/her medical condition. Therefore, there may have been a need for the user to manually search for the mobility restrictions relevant to his/her medical condition.

[0006] Further, recent innovations in manufacturing, for example, using micro-factories, may pave a way to affordable vehicle manufacturing based on personal mobility needs. As such, automotive manufacturers may need to know which designs are suitable for the user with the medical condition. [0007] Over the years, various technologies have been developed to recommend a vehicle to the user. For example, a vehicle recommendation system which presents options to the user from vehicle-related lifestyle to other criteria such as budget and vehicle style has been developed. In this system, however, the recommendation of the vehicle is solely based on the user’s explicit selection of preferences.

[0008] Therefore, there exists a need to provide an improved solution to mitigate at least one of the above limitations or drawbacks.

SUMMARY

[0009] According to various embodiments, a server for facilitating recommending a vehicle is provided. The server comprises: a memory for storing instructions; and a processor for executing the stored instructions and configured to: receive a request for recommending the vehicle from a user; obtain health data of the user; retrieve one or more user-vehicle matching data that matches the health data of the user, from a plurality of predetermined user-vehicle matching data; search for one or more available vehicles that match one or more vehicles associated with the retrieved one or more user-vehicle matching data; and recommend at least one of the one or more available vehicles to the user.

[0010] In some embodiments, the processor is further configured to: create the plurality of predetermined user-vehicle matching data based on aggregated health data of a plurality of users and aggregated vehicle data of a plurality of vehicles.

[0011] In some embodiments, the processor is further configured to: categorise the aggregated health data of the plurality of users into one or more mobility profiles; analyse the aggregated vehicle data of the plurality of vehicles with respect to the one or more mobility profiles; and create the plurality of predetermined user-vehicle matching data that matches each mobility profile of the one or more mobility profiles to one or more vehicle data of the aggregated vehicle data.

[0012] In some embodiments, the processor is further configured to: request the aggregated health data of the plurality of users from a health data system; obtain the aggregated health data of the plurality of users from the health data system; and translate the aggregated health data into measurable health data to categorise the aggregated health data into the one or more mobility profiles. [0013] In some embodiments, the processor is further configured to: request the aggregated vehicle data of the plurality of vehicles from a vehicle data system; obtain the aggregated vehicle data of the plurality of vehicles from the vehicle data system; and translate the aggregated vehicle data into measurable vehicle data to analyse the aggregated vehicle data.

[0014] In some embodiments, the processor is further configured to: request aggregated environmental data from an environmental data system; obtain the aggregated environmental data from the environmental data system; and create the plurality of predetermined user-vehicle matching data further based on the aggregated environmental data.

[0015] In some embodiments, the processor is further configured to: request aggregated medical advisory data from a medical advisory data system; obtain the aggregated medical advisory data from the medical advisory data system; and create the plurality of predetermined user-vehicle matching data further based on the aggregated medical advisory data.

[0016] In some embodiments, the processor is further configured to: upon the receipt of the request from the user, request the health data of the user from a health data system; and obtain the health data of the user from the health data system.

[0017] In some embodiments, the processor is further configured to: identify a mobility profile of the user based on the health data of the user and the aggregated health data of the plurality of users.

[0018] In some embodiments, the processor is further configured to: rank the one or more available vehicles based on at least one criterion; and recommend the at least one of the one or more available vehicles to the user based on the rank.

[0019] In some embodiments, the processor is further configured to: assign one of the at least one recommended vehicle to the user based on an input of the user; and adjust a control setting of the assigned vehicle based on a mobility requirement associated with the health data of the user.

[0020] In some embodiments, the processor is further configured to: where two or more users get into the assigned vehicle, adjust the control setting of the assigned vehicle, based on a seat in which each of the two or more users is sitting, and a mobility requirement associated with health data of each of the two or more users.

[0021] In some embodiments, the processor is further configured to: request telemetric data of the assigned vehicle from the assigned vehicle; obtain the telemetric data of the assigned vehicle from the assigned vehicle; and adjust the control setting of the assigned vehicle based on the telemetric data of the assigned vehicle. [0022] In some embodiments, the processor is further configured to: request environmental data from an environmental data system; obtain the environmental data from the environmental data system; and adjust the control setting of the assigned vehicle further based on the environmental data.

[0023] In some embodiments, the processor is further configured to: request medical advisory data from a medical advisory data system; obtain the medical advisory data from the medical advisory data system; and adjust the control setting of the assigned vehicle further based on the medical advisory data.

[0024] According to various embodiments, a method for facilitating recommending a vehicle is provided. The method comprises: receiving a request for recommending the vehicle from a user; obtaining health data of the user; retrieving one or more user-vehicle matching data that matches the health data of the user, from a plurality of predetermined user-vehicle matching data; searching for one or more available vehicles that match one or more vehicles associated with the retrieved one or more user-vehicle matching data; and recommending at least one of the one or more available vehicles to the user.

[0025] In some embodiments, the method further comprises: creating the plurality of predetermined user-vehicle matching data based on aggregated health data of a plurality of users and aggregated vehicle data of a plurality of vehicles.

[0026] In some embodiments, the creating the plurality of predetermined user-vehicle matching data comprises: categorising the aggregated health data of the plurality of users into one or more mobility profiles; analysing the aggregated vehicle data of the plurality of vehicles with respect to the one or more mobility profiles; and creating the plurality of predetermined user-vehicle matching data that matches each mobility profile of the one or more mobility profiles to one or more vehicle data of the aggregated vehicle data.

[0027] In some embodiments, the creating the plurality of predetermined user-vehicle matching data comprises: requesting the aggregated health data of the plurality of users from a health data system; obtaining the aggregated health data of the plurality of users from the health data system; and translating the aggregated health data into measurable health data to categorise the aggregated health data into the one or more mobility profiles.

[0028] In some embodiments, the creating the plurality of predetermined user-vehicle matching data comprises: requesting the aggregated vehicle data of the plurality of vehicles from a vehicle data system; obtaining the aggregated vehicle data of the plurality of vehicles from the vehicle data system; and translating the aggregated vehicle data into measurable vehicle data to analyse the aggregated vehicle data.

[0029] In some embodiments, the creating the plurality of predetermined user-vehicle matching data comprises: requesting aggregated environmental data from an environmental data system; obtaining the aggregated environmental data from the environmental data system; and creating the plurality of predetermined user-vehicle matching data further based on the aggregated environmental data.

[0030] In some embodiments, the creating the plurality of predetermined user-vehicle matching data comprises: requesting aggregated medical advisory data from a medical advisory data system; obtaining the aggregated medical advisory data from the medical advisory data system; and creating the plurality of predetermined user-vehicle matching data further based on the aggregated medical advisory data.

[0031] In some embodiments, the obtaining health data of the user comprises: upon the receipt of the request from the user, requesting the health data of the user from a health data system; and obtaining the health data of the user from the health data system.

[0032] In some embodiments, the retrieving one or more user-vehicle matching data that matches the health data of the user comprises: identifying a mobility profile of the user based on the health data of the user and the aggregated health data of the plurality of users.

[0033] In some embodiments, the recommending at least one of the one or more available vehicles to the user comprises: ranking the one or more available vehicles based on at least one criterion; and recommending the at least one of the one or more available vehicles to the user based on the rank.

[0034] In some embodiments, the method further comprises: assigning one of the at least one recommended vehicle to the user based on an input of the user; and adjusting a control setting of the assigned vehicle based on a mobility requirement associated with the health data of the user.

[0035] In some embodiments, the adjusting control setting of the assigned vehicle comprises: where two or more users get into the assigned vehicle, adjusting the control setting of the assigned vehicle, based on a seat in which each of the two or more users is sitting, and a mobility requirement associated with health data of each of the two or more users.

[0036] In some embodiments, the adjusting control setting of the assigned vehicle comprises: requesting telemetric data of the assigned vehicle from the assigned vehicle; obtaining the telemetric data of the assigned vehicle from the assigned vehicle; and adjusting the control setting of the assigned vehicle based on the telemetric data of the assigned vehicle.

[0037] In some embodiments, the adjusting control setting of the assigned vehicle comprises: requesting environmental data from an environmental data system; obtaining the environmental data from the environmental data system; and adjusting the control setting of the assigned vehicle further based on the environmental data.

[0038] In some embodiments, the adjusting control setting of the assigned vehicle comprises: requesting medical advisory data from a medical advisory data system; obtaining the medical advisory data from the medical advisory data system; and adjusting the control setting of the assigned vehicle further based on the medical advisory data.

[0039] According to various embodiments, a computer program product, comprising instructions to cause the server of any one of the above embodiments to execute the steps of the method of any one of the above embodiments is provided.

[0040] According to various embodiments, a computer-readable medium having stored thereon the above computer program product is provided.

[0041] According to various embodiments, a data processing apparatus configured to perform the method of any one of the above embodiments is provided.

[0042] According to various embodiments, a computer program element comprising program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of any one of the above embodiments is provided.

[0043] According to various embodiments, a computer-readable medium comprising program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of any one of the above embodiments is provided. The computer-readable medium may include a non-transitory computer-readable medium.

BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various embodiments are described with reference to the following drawings, in which:

[0045] FIG. 1 is a block diagram illustrating a server according to various embodiments.

[0046] FIG. 2 is a block diagram illustrating a system according to various embodiments. [0047] FIG. 3 is a block diagram illustrating a system according to various embodiments.

[0048] FIG. 4 is a flow diagram illustrating a method for facilitating recommending a vehicle according to various embodiments.

[0049] FIG. 5 is a block diagram illustrating a server according to various embodiments.

[0050] FIG. 6 is an image diagram illustrating processing health data according to various embodiments.

[0051] FIG. 7 is an image diagram illustrating processing vehicle data according to various embodiments.

[0052] FIG. 8 is an image diagram illustrating generating one or more mobility profiles according to various embodiments.

[0053] FIG. 9 is a flow diagram illustrating a method for generating one or more mobility profiles according to various embodiments.

[0054] FIG. 10 is an image diagram illustrating generating user-vehicle matching data according to various embodiments.

[0055] FIG. 11 is an image diagram illustrating matching a vehicle with a user according to various embodiments.

[0056] FIG. 12 is an image diagram illustrating a relation of a user, a condition and a vehicle according to various embodiments.

[0057] FIG. 13 is a flow diagram illustrating a method for clustering a plurality of users and a plurality of vehicles according to various embodiments.

[0058] FIG. 14A is a block diagram illustrating a server and a vehicle data system according to various embodiments.

[0059] FIG. 14B is an example diagram illustrating a control setting of a vehicle according to various embodiments.

[0060] FIG. 15 is a flow diagram illustrating a method for updating predetermined user-vehicle matching data according to various embodiments.

[0061] FIG. 16 is an image diagram illustrating vehicle data with user evaluation according to various embodiments.

[0062] FIG. 17 is a flow diagram illustrating a method according to various embodiments.

[0063] FIG. 18 is an image diagram illustrating a user interface according to various embodiments.

[0064] FIG. 19 is an image diagram illustrating a user interface according to various embodiments. [0065] FIG. 20 illustrates use cases of a server according to various embodiments.

DESCRIPTION

[0066] Embodiments described below in context of the method are analogously valid for the server, and vice versa. Furthermore, it will be understood that the embodiments described below may be combined, for example, a part of one embodiment may be combined with a part of another embodiment.

[0067] It will be understood that any property described herein for a specific device may also hold for any device described herein. Furthermore, it will be understood that for any device described herein, not necessarily all the components described must be enclosed in the device, but only some (but not all) components may be enclosed.

[0068] It should be understood that the terms “on”, “over”, “top”, “bottom”, “down”, “side”, “back”, “left”, “right”, “front”, “lateral”, “side”, “up”, “down” etc., when used in the following description are used for convenience and to aid understanding of relative positions or directions, and not intended to limit the orientation of any device, structure or any part of any device or structure. In addition, the singular terms “a”, “an”, and “the” include plural references unless context clearly indicates otherwise. Similarly, the word “or” is intended to include “and” unless the context clearly indicates otherwise.

[0069] The term “coupled” (or “connected”) herein may be understood as electrically coupled or as mechanically coupled, for example attached or fixed, or just in contact without any fixation, and it will be understood that both direct coupling or indirect coupling (in other words: coupling without direct contact) may be provided.

[0070] In order that the invention may be readily understood and put into practical effect, various embodiments will now be described by way of examples and not limitations, and with reference to the figures.

[0071] FIG. 1 is a block diagram illustrating a server 100 according to various embodiments.

[0072] In some embodiments, the server 100, for example, implemented by a server computer, may include a communication interface 110, a processor 120, and a memory 130.

[0073] Throughout the description, the server 100 according to various embodiments may be referred to as a safe mobility support system (SMSS). The server 100 may provide a support to journey of a user 150 (as shown in FIG. 3) from selecting a vehicle to its actual use. The user 150 may be either a driver or a passenger who selects the vehicle for rental, booking or purchase.

[0074] In some embodiments, the memory 130 (also referred to as a “database”) may store input data and/or output data temporarily or permanently. In some embodiments, the memory 130 may store program code which allows the server 100 to perform a method S100 (as will be described with reference to FIG. 4). In some embodiments, the program code may be embedded in a Software Development Kit (SDK). The memory 130 may include an internal memory of the server 100 and/or an external memory. The external memory may include, but is not limited to, an external storage medium, for example, a memory card, a flash drive, and a web storage.

[0075] In some embodiments, the communication interface 110 may allow one or more external systems, including, but not limited to, a health data system 200, a vehicle data system 300, and other data systems 400, to communicate with the processor 120 via a network. In some embodiments, the communication interface 110 may transmit signals to the external systems, and/or receive signals from the external systems via the network.

[0076] In some embodiments, the communication interface 110 may receive health data from the health data system 200 via the network. In some embodiments, the communication interface 110 may receive vehicle data from the vehicle data system 300 via the network. In some embodiments, the communication interface 110 may receive environmental data and/or medical advisory data from the other data systems 400 via the network.

[0077] In some embodiments, the communication interface 110 may allow one or more external devices associated with users, including, but not limited to, a device associated with the user 150, for example, a device belonging to the user 150, to communicate with the processor 120 via the network. In some embodiments, the communication interface 110 may transmit signals to the external devices, and/or receive signals from the external devices via the network.

[0078] In some embodiments, the communication interface 110 may receive a request for recommending a vehicle from the device associated with the user 150. The communication interface 110 may then send the request for recommending the vehicle to the processor 120.

[0079] In some embodiments, the processor 120 may include, but is not limited to, a microprocessor, an analogue circuit, a digital circuit, a mixed-signal circuit, a logic circuit, an integrated circuit, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), or any combination thereof. Any other kind of implementation of the respective functions, which will be described below in further detail, may also be understood as the processor 120.

[0080] In some embodiments, the processor 120 may be connectable to the communication interface 110. In some embodiments, the processor 120 may be arranged in data or signal communication with the communication interface 110 to receive the request for recommending the vehicle from the communication interface 110.

[0081] In some embodiments, the processor 120 may receive health data from the communication interface 110. In some embodiments, the processor 120 may receive vehicle data from the communication interface 110. In some embodiments, the processor 120 may receive environmental data and/or medical advisory data from the communication interface 110.

[0082] In some embodiments, after the processor 120 receives the request for recommending the vehicle, the processor 120 may obtain the health data of the user 150. In some embodiments, the processor 120 may retrieve one or more user-vehicle matching data that matches the health data of the user 150, from a plurality of predetermined user- vehicle matching data. In some embodiments, the processor 120 may search for one or more available vehicles that match one or more vehicles associated with the retrieved one or more user-vehicle matching data, and recommend at least one of the one or more available vehicles to the user 150.

[0083] FIG. 2 is a block diagram illustrating a system 1000 including a server 100 according to various embodiments. FIG. 3 is a block diagram illustrating the system 1000 including the server 100 according to various embodiments.

[0084] There may be two major phases provided by the server 100 including a creation phase (as shown in FIG. 2) and a usage phase (as shown in FIG. 3). The creation phase may create one or more mobility profiles and user-vehicle matching data, using aggregated health data obtained from a plurality of users (for example, a group of users). The usage phase may match a user 150 with a vehicle, and generate a control setting (also referred to as a “control plan”) of the vehicle.

[0085] As shown in FIGS. 2 and 3, the system 1000 may include, but is not limited to, the server 100, a health data system 200, a vehicle data system 300, and other data systems 400.

[0086] In some embodiments, the server 100 may be connected to the health data system 200 via a network. In some embodiments, the server 100 may be connected to the vehicle data system 300 via the network. In some embodiments, the server 100 may be connected to the other data systems 400 via the network. In some embodiments, the server 100 may be connected to a device associated with the user 150, for example, a device belonging to the user 150. In some embodiments, the network may include, but is not limited to, a Local Area Network (LAN), a Wide Area Network (WAN), a Global Area Network (GAN), or any combination thereof. The network may provide a wireline communication, a wireless communication, or a combination of the wireline and wireless communication between the server 100 and the health data system 200, between the server 100 and the vehicle data system 300, between the server 100 and the other data systems 400, and between the server 100 and the device associated with the user 150.

[0087] In some embodiments, the server 100, for example, implemented by a server computer, may include a device. In some embodiments, each of the health data system 200, the vehicle data system 300, and the other data systems 400 may be a system or a server, for example, implemented by a server computer, respectively. In some embodiments, each of the health data system 200, the vehicle data system 300, and the other data systems 400 may include a device respectively. Throughout the description, the term of “device” may include, but is not limited to, at least one of the following: a mobile phone, a tablet computer, a laptop computer, a desktop computer, a head-mounted display, a smart watch, a server, a workstation, and a POS terminal. [0088] In some embodiments, the health data system 200 (also referred to as a “health data system/device”) may be the system or the server, and provide heath data of an individual user or the plurality of users (for example, the group of users). In some embodiments, the health data system 200 may be owned by at least one of a government agency of health, a private health care centre, an independent aggregator of health data, and an individual user. In some embodiments, the vehicle data system 300 may be the system or the server, and contain vehicle data including static properties of vehicles and/or dynamic properties of vehicles. The vehicle data may come from at least one of a vehicle manufacturer, a vehicle selling agent, a vehicle operator, and a transport monitoring operator. In some embodiments, the other data systems 400 may include one or more systems or servers. The other data systems 400 may include, but are not limited to, an environment data system 410 and a medical advisory data system 420. In some embodiments, the environment data system 410 may include, but is not limited to, an environmental weather data provider, a weather report, and a news, and provide environmental data. In some embodiments, the medical advisory data system 420 may include, but is not limited to, one or more medical advisories, for example, a doctor, and provide medical advisory data. [0089] In some embodiments, in the creation phase, the processor 120 of the server 100 may create a plurality of user-vehicle matching data. In some embodiments, the plurality of uservehicle matching data created in the creation phase (hereinafter, also referred to as “a plurality of predetermined user-vehicle matching data”) may be used in the usage phase (as will be described with reference to FIG. 3). In some embodiments, the processor 120 of the server 100 may create the plurality of predetermined user-vehicle matching data based on aggregated health data of the plurality of users and aggregated vehicle data of a plurality of vehicles.

[0090] In some embodiments, in the creation phase, the processor 120 of the server 100 may categorise the aggregated health data of the plurality of users into one or more mobility profiles. In some embodiments, the processor 120 of the server 100 may analyse the aggregated vehicle data of the plurality of vehicles with respect to the one or more mobility profiles. In some embodiments, the processor 120 of the server 100 may create the plurality of predetermined user-vehicle matching data that matches each mobility profile of the one or more mobility profiles to one or more vehicle data of the aggregated vehicle data.

[0091] As shown in FIG. 2, in some embodiments, in the creation phase, the processor 120 of the server 100 may request the aggregated health data of the plurality of users from the health data system 200 (as shown in step (a)). Thereafter, the processor 120 of the server 100 may obtain the aggregated health data of the plurality of users from the health data system 200 (as shown in step (b)). Although not shown, in some embodiments, the processor 120 of the server 100 may translate the aggregated health data into measurable health data to categorise the aggregated health data into the one or more mobility profiles.

[0092] For example, in the creation phase, the processor 120 of the server 100 may send the request for an access to health data to the health data system 200 to access and analyse the aggregated health data of the plurality of users (as shown in step (a)). To avoid health data leakage, the request for the access to the health data may include rules and/or algorithms for analysis, so that private health data may be processed to become the aggregated health data by executing the rules and/or algorithms locally in the health data system 200. As a result, the aggregated health data may be sent to the server 100, without containing personal information (as shown in step (b)).

[0093] As shown in FIG. 2, in some embodiments, in the creation phase, the processor 120 of the server 100 may request the aggregated vehicle data of the plurality of vehicles from the vehicle data system 300 (as shown in step (c)). Thereafter, the processor 120 of the server 100 may obtain the aggregated vehicle data of the plurality of vehicles from the vehicle data system 300 (as shown in step (d)). Although not shown, in some embodiments, the processor 120 of the server 100 may translate the aggregated vehicle data into measurable vehicle data to analyse the aggregated vehicle data.

[0094] As shown in FIG. 2, in some embodiments, in the creation phase, the processor 120 of the server 100 may request aggregated environmental data from the environmental data system 410 (as shown in step (e)). Thereafter, the processor 120 of the server 100 may obtain the aggregated environmental data from the environmental data system 410 (as shown in step (f)). Although not shown, in some embodiments, the processor 120 of the server 100 may create the plurality of predetermined user-vehicle matching data further based on the aggregated environmental data.

[0095] As shown in FIG. 2, in some embodiments, in the creation phase, the processor 120 of the server 100 may request aggregated medical advisory data from the medical advisory data system 420 (as shown in step (e)). Thereafter, the processor 120 of the server 100 may obtain the aggregated medical advisory data from the medical advisory data system 420 (as shown in step (g)). Although not shown, in some embodiments, the processor 120 of the server 100 may create the plurality of predetermined user-vehicle matching data further based on the aggregated medical advisory data.

[0096] In this manner, in the creation phase, the processor 120 of the server 100, may process the aggregated health data, the aggregated vehicle data, the aggregated medical advisory data, and the aggregated environmental data, to generate the one or more mobility profiles, as well as the plurality of predetermined user-vehicle matching data.

[0097] In some embodiments, the usage phase of FIG. 3 may include two sub-phases of a pairing sub-phase and a control sub-phase.

[0098] As shown in FIG. 3, in some embodiments, in the pairing sub-phase of the usage phase, the processor 120 of the server 100 may receive a request for recommending a vehicle from the user 150. In some embodiments, the processor 120 of the server 100 may obtain health data of the user 150. In some embodiments, the processor 120 of the server 100 may retrieve one or more user-vehicle matching data that matches the health data of the user 150, from the plurality of predetermined user-vehicle matching data which is created in the creation phase. In some embodiments, the processor 120 of the server 100 may search for one or more available vehicles that match one or more vehicles associated with the retrieved one or more user- vehicle matching data, and recommend at least one of the one or more available vehicles to the user 150. [0099] As shown in FIG. 3, in some embodiments, in the pairing sub-phase of the usage phase, the user 150 may send the request for recommending the vehicle along with the user’s identity (ID) to the server 100 (as shown in step (a)). In some embodiments, upon the receipt of the request from the user 150, the processor 120 of the server 100 may request the health data of the user 150 from the health data system 200 (as shown in step (b)). For example, the processor 120 of the server 100 may provide the user ID received from the user 150 to the health data system 200, to obtain the health data of the user 150. Although not shown, in some other embodiments, the user 150 may directly provide the health data of the user 150 to the server 100, without providing the user ID. In some embodiments, the processor 120 of the server 100 may obtain the health data of the user 150 from the health data system 200 (as shown in step (c)). Although not shown, in some other embodiments, the processor 120 of the server 100 may obtain the health data of the user 150 from the user 150.

[00100] As shown in FIG. 3, in some embodiments, in the pairing sub-phase of the usage phase, the processor 120 of the server 100 may request an access to the vehicle data to the vehicle data system 300 (as shown in step (d)). In some embodiments, the processor 120 of the server 100 may receive the vehicle data from the vehicle data system (as shown in step (e)). The request for the access to the vehicle data may include a request for an access to vehicle data of available vehicles. In some embodiments, the processor 120 of the server 100 may receive the vehicle data of the available vehicles, from the vehicle data system 300 (as shown in step (e)).

[00101] Although not shown, in some embodiments, in the pairing sub-phase of the usage phase, the processor 120 of the server 100 may retrieve the one or more user-vehicle matching data that matches the health data of the user 150, from the plurality of predetermined uservehicle matching data which is created in the creation phase. In some embodiments, the processor 120 of the server 100 may search for the one or more available vehicles that match one or more vehicles associated with the retrieved one or more user- vehicle matching data. The one or more available vehicles may be found based on the vehicle data of the available vehicles received from the vehicle data system 300.

[00102] As shown in FIG. 3, in some embodiments, in the pairing sub-phase of the usage phase, the processor 120 of the server 100 may assign one of the at least one recommended vehicle to the user 150 (as shown in step (f)). In some embodiments, the processor 120 of the server 100 may inform the assignment of the vehicle to the vehicle data system 300 (as shown in step (g)). [00103] Although not shown, in some embodiments, in the pairing sub-phase of the usage phase, the processor 120 of the server 100 may identify a mobility profile of the user 150 based on the health data of the user 150 and the aggregated health data of the plurality of users.

[00104] Although not shown, in some embodiments, in the pairing sub-phase of the usage phase, the processor 120 of the server 100 may rank the one or more available vehicles based on at least one criterion, and recommend the at least one of the one or more available vehicles to the user 150 based on the rank.

[00105] As shown in FIG. 3, in some embodiments, in the control sub-phase of the usage phase, the processor 120 of the server 100 may adjust a control setting of the assigned vehicle based on a mobility requirement associated with the health data of the user 150. In some embodiments, the control sub-phase may be started when the user 150 selects the vehicle and is about to use the vehicle. While the vehicle is being used, the processor 120 of the server 100 may collect telemetric data of the vehicle which may include, but is not limited to, dynamic data from the vehicle and measurements from user monitoring devices, and environment data. The processor 120 of the server 100 may process the collected data to generate the control setting of the vehicle.

[00106] Although not shown, in some embodiments, in the control sub-phase of the usage phase, the processor 120 of the server 100 may request environmental data from the environmental data system 410 (as shown in step (h)). Thereafter, the processor 120 of the server 100 may obtain the environmental data from the environmental data system 410 (as shown in step (i)). Although not shown, in some embodiments, the processor 120 of the server 100 may adjust the control setting of the assigned vehicle further based on the environmental data.

[00107] Although not shown, in some embodiments, in the control sub-phase of the usage phase, the processor 120 of the server 100 may request medical advisory data from the medical advisory data system 420 (as shown in step (h)). Thereafter, the processor 120 of the server 100 may obtain the medical advisory data from the medical advisory data system 420 (as shown in step (j)). Although not shown, in some embodiments, the processor 120 of the server 100 may adjust the control setting of the assigned vehicle further based on the medical advisory data.

[00108] Although not shown, in some embodiments, in the control sub-phase of the usage phase, the processor 120 of the server 100 may request an access to telemetric data of the assigned vehicle from the vehicle data system 300. As shown in FIG. 3, in some embodiments, the processor 120 of the server 100 may receive the telemetric data from the vehicle data system (as shown in step (k)). Although not shown, in some embodiments, the processor 120 of the server 100 may adjust the control setting of the assigned vehicle based on the telemetric data of the assigned vehicle.

[00109] Although not shown, in some other embodiments, in the control sub-phase of the usage phase, the processor 120 of the server 100 may request the access to the telemetric data of the assigned vehicle from the assigned vehicle. Thereafter, the processor 120 of the server 100 may obtain the telemetric data of the assigned vehicle from the assigned vehicle. Although not shown, in some embodiments, the processor 120 of the server 100 may adjust the control setting of the assigned vehicle further based on the telemetric data of the assigned vehicle.

[00110] Although not shown, in some embodiments, in the control sub-phase of the usage phase, where two or more users get into the assigned vehicle, the processor 120 of the server 100 may adjust the control setting of the assigned vehicle, based on a seat in which each of the two or more users is sitting, and a mobility requirement associated with health data of each of the two or more users.

[00111] FIG. 4 is a flow diagram illustrating a method S100 for facilitating recommending a vehicle according to various embodiments. According to various embodiments, the method S100 for facilitating recommending the vehicle is provided.

[00112] In some embodiments, the method S100 may include a step S101 of receiving a request for recommending the vehicle from a user.

[00113] In some embodiments, the method S100 may include a step S 102 of obtaining health data of the user.

[00114] In some embodiments, the method S100 may include a step S103 of retrieving one or more user-vehicle matching data that matches the health data of the user, from a plurality of predetermined user-vehicle matching data.

[00115] In some embodiments, the method S100 may include a step S104 of searching for one or more available vehicles that match one or more vehicles associated with the retrieved one or more user- vehicle matching data.

[00116] In some embodiments, the method S100 may include a step S105 of recommending at least one of the one or more available vehicles to the user.

[00117] FIG. 5 is a block diagram illustrating a server 100 according to various embodiments. [00118] The server 100 may include a processor 120 and a memory 130. The processor 120 may include a user profiling module 121, a health data analytics module 122, a user- vehicle pairing module 123, and a planning control module 124. The memory 130 may include a user data database 131, a vehicle data database 132, and a user-vehicle pairs database 133.

[00119] In some embodiments, the user profiling module 121 may receive health data of a user 150. The user profiling module 121 may identify a mobility profile of the user 150 based on the health data of the user 150 and aggregated health data of a plurality of users. For example, the user profiling module 121 may identify the mobility profile of the user 150 by evaluating the health data of the user 150 from a list of several mobility profiles stored in the user data database 131.

[00120] In some embodiments, the user-vehicle pairing module 123 may receive the identified mobility profile of the user 150, and search for a vehicle assignment by using the user- vehicle pairs database 133.

[00121] In some embodiments, the mobility profiles may be generated by the health data analytics module 122. In some embodiments, the health data analytics module 122 may transform the aggregated health data of the plurality of users into the mobility profiles, which may be later stored in the user data database 131. In addition, the health data analytics module 122 may use data stored in the user-vehicle pairs database 133 to generate a plurality of predetermined user-vehicle matching data, which may be later stored in the user-vehicle pairs database 133. The health data analytics module 122 may analyse static vehicle data relevant to the static properties of vehicles, dynamic vehicle data relevant to dynamic properties of vehicles, and environment data, to evaluate suitability of an assigned vehicle to the user 150, which may be the basis for matching the user 150 and the vehicle.

[00122] In some embodiments, the planning control module 124 may generate a control setting of the vehicle for in-vehicle systems including navigation control based on the mobility profile of the user 150, static and dynamic properties of the vehicle, and the environment data.

[00123] In some embodiments, the plurality of predetermined user- vehicle matching data may be generated based on the mobility profiles and available vehicle information about the vehicle data. In some embodiments, the vehicle data database 132 may gather the vehicle data from various data sources, including, but not limited to, a vehicle manufacturer, a vehicle selling agent, a vehicle operator, and a transport monitoring operator, by automatic means such as API (application programming interface) connection and data uploads, or manual means such as keying in information through a user interface for the server 100. [00124] FIG. 6 is an image diagram illustrating processing health data according to various embodiments. FIG. 6 shows examples of health data 210, medical information about medical condition 220, medical information about medication 230, and measurable health data 240.

[00125] As shown in FIG. 6, the health data 210 may include personal information 212 including, but not limited to, age 212b, gender 212c, birthdate, marital status, and address. The health data 210 may further include medical records including, but not limited to, medical condition 213 (for example, loss of consciousness), status (for example, recurring, temporary, permanent, under medication), severity (for example, mild, severe), and medication 214. The health data 210 may further include a record of physical injuries, and psychological injuries.

[00126] In some embodiments, for individual health data 210 of a user 150, the health data 210 may include personal information 212 including, but not limited to, name 212a and exact address. In some embodiments, for aggregated health data 210, the name may be hidden, and a low-resolution address may be used. The health data 210 may also include medical measurements, including, but not limited to, height, weight, BMI, cholesterol level, blood pressure, and vision reading. The medication information may include the medicine, and other assessment/opinion from a medical expert.

[00127] As shown in FIG. 6, in some embodiments, the health data 210 including the medical condition 213 and the medication 214 may be split into the medical condition 220 and the medication side-effect 230. The medical condition 220 from a medical report may be mapped to related mobility restrictions. The medical condition 220 may systematize the data gathered from various sources 222 about a medical condition 223 and related mobility restrictions 224. For example, the medical condition 220 may show that “asthma” is gathered from a medical bulletin stating that a threshold of altitude has to be avoided due to thin air. Similarly, the medication 214 may be mapped to related mobility restrictions. The medication side effect 230 may standardize a list of medications 232 to a known side-effect 233 related to mobility.

[00128] As shown in FIG. 6, in some embodiments, the medical condition 220 and the medication side-effect 230 may then be transformed into the measurable health data 240. In order to transform the medical condition 220 and the medication side-effect 230 to the measurable health data 240, measurable data limits related to a medical condition may be determined by searching data sources which may include, but are not limited to, medical bulletins, laboratory tests, medical journals, public or proprietary information, information sourced from drug manufacturer or from drug labels, and medical websites. Collecting such data may be performed by various methods, including, but not limited to, OCR (optical character recognition) for document labels, searches on the Internet, data mining techniques, and text data analysis. The collected data may be used to determine corresponding measurable data, including, but not limited to, altitude 243a, space 243b, ambient light 243c, audio or sound 243d, and gait, inclination and balance 243e. As the medical condition 242 and the measurable data limits 243 may depend on user demographic profile 244, relevant information including, but not limited to, age 244a and gender 244b, may be included. The values in the measurable data limits 243 and the demographic profile 244 may be a single value indicating maximum or minimum values, or range of values.

[00129] FIG. 7 is an image diagram illustrating processing vehicle data according to various embodiments. FIG. 7 shows examples of vehicle data 310, vehicle details on rigid properties 320, and vehicle details on controllable properties 330.

[00130] As shown in FIG. 7, the vehicle data 310 may include vehicle properties including the rigid properties 312 of a vehicle and the controllable properties 313 of the vehicle. The rigid properties 312 may include, but not limited to, a wheel type, a steering type, dimensions (for example, height, weight, length, and available space), a seat configuration, safety features, an airbag, an antilock brake system, a traction control, a belt placement, an engine type (for example, an internal combustion engine, an electric vehicle, and a hybrid vehicle), and telematics capability. The controllable properties 314 may relate to systems for lighting, ventilation, cruise control, audio, and video.

[00131] As shown in FIG. 7, in some embodiments, details of rigid properties may be determined from the rigid properties 312 which may provide specifications or measurements of vehicle properties, features or parts, including, but not limited to, vehicle floor height, a door type, a leg room area, as well as dimensions of vehicle including a door, a seat, a window and available space. Similarly, details of controllable properties may be determined from the controllable properties 313, including, but not limited to, maximum and minimum values of settings for the vehicle systems which may include, but are not limited to, a lighting system, a ventilation control system, a cruise control system, an audio system, and a video system. Data sources of the rigid properties 312 and the controllable properties 313 may include, but are not limited to, a product specification of vehicles, actual measurements using 3D scanning tools, data from vehicle manufacturer or vehicle part manufacturer, and actual vehicle usage. Collecting such data may be performed by various methods, including, but not limited to, OCR for document labels, searches on the Internet, data mining techniques, and text data analysis. The collected data may be used to extract a maximum value 324 and a minimum value 325 of the rigid properties 320, and a maximum value 334 and a minimum value 335 of the controllable properties 330.

[00132] As shown in FIG. 7, in some embodiments, by using data from the rigid properties 320 and the controllable properties 330, the vehicle data 310 may be transformed into measurable properties, which may then be compared to the measurable health data 240 shown in FIG. 6. In comparing the measurable health data 240 and the controllable properties 330, the environmental data may be taken into consideration. For example, aside from the vehicle properties, vehicle location (for example, Geocode including altitude) and current inclination may be taken into consideration to check the user’s 150 tolerance with respect to altitude 243a, and balance 243e. Similarly, ambient environment may be taken into consideration to compare the light and sound settings.

[00133] FIG. 8 is an image diagram illustrating generating one or more mobility profiles 500 according to various embodiments. FIG. 8 shows an example of the mobility profiles 500 generated from health data of a plurality of users.

[00134] As shown in FIG. 8, a user 510 may include various user types, for example, including a driver 511 and a passenger 512. The user 510 may be identified as one of the driver 511 and the passenger 512 with various sub-types 520. For example, the sub-types 520 may be identified by creating hypotheses and verifying them through statistical analysis of the health data. Various clustering methods based on the health data may also be applicable in generating the user types and sub-types 520. It may be appreciated that the sub-types 520 may be further divided into more types.

[00135] In the mobility profiles 500, an illustration may be provided by applying rules, heuristics, or check points 530. These rules enumerated in check points 530 may be implemented in software codes by using object-oriented programming languages, and scripting languages including, but not limited to, C++, C, C#, Java, and Python. For example, an object, for example, a sub-type DI 521, referring to an ordinary user type may be declared with a function definition that determines an absence of any physical and medical conditions relating to mobility 531. As another example, other objects may include a sub-type D2 522 who is limited by the rigid property of the vehicles, a sub-type D3 523 who requires property adjustment in controllable properties of the vehicles, and a sub-type D4 524 who requires a combination of the sub-type D2 522 and the sub-type D3 523. For example, the sub-types D2, D3, D4 522, 523, 524 may mean that, despite the limitations, a user 510 may drive safely, as a driver 511, by considering the check points 532, 533, 534. [00136] In some embodiments, users 510, who are considered as a sub-type Pl 525 who requires a rigid property setting, a sub-type P2 526 who requires property adjustment, a subtype P3 527 who requires both the rigid property setting and the property adjustment, and/or a sub-type P4 528 who is referred to as an extraordinary user type, can only be a passenger 512. For example, the sub-type Pl 525 may be a result of having issues in the sub-type D2 522 and the sub-type D3 523 that may be unresolved, but other issues may be resolved by a vehicle which is properly selected. For example, a user 510 with minor neurological movement disorder may be considered as a driver 511, as vehicle properties such as an automatic cruise control system may be present in a selected vehicle. On the other hand, a user 510 with severe disorder may not be capable of driving despite selecting a vehicle and adjusting the vehicle properties as in the case of the sub-type P3 527. Under the passenger type 512, some issues, but not all issues, may be addressable based on the check points 535, 536, 537, 538, so that the user 510 may be safe and comfortable as a passenger 512 only.

[00137] FIG. 9 is a flow diagram illustrating a method S200 for generating one or more mobility profiles according to various embodiments. According to various embodiments, the method S200 for generating the one or more mobility profiles is provided. In some embodiments, the method S200 may be operated by a user profiling module 121 shown in FIG. 5, by using rules or a set of check points based on medical conditions. It may be appreciated that the method S200 may be implemented as logical steps in software codes.

[00138] In some embodiments, in creating rules, the medical conditions may be checked based on driving capability, including, but not limited to, sight, reach, hand, and leg control. The restrictions due to the medical or physical conditions may be compared to vehicle properties (for example, rigid properties and controllable properties). Some conditions may be critical conditions such as unconsciousness and severe hypertension which may be considered as a sub-type P4 528 who refers to an extraordinary user type shown in FIG. 8.

[00139] In some embodiments, the method S200 may include a step S201 of receiving a user ID and retrieving health data of a user based on the user ID. Alternatively, the method S200 may include a step S201 of receiving the health data of the user from the user. In the step S201, the medical conditions related to mobility considerations may be determined. Various check points 530 may be organised from steps S202, S204, S206, S208, S210, S212 and S214, so that the user is categorised into one of the sub-types 520 including DI to D4 and Pl to P4 shown in FIG. 8. [00140] FIG. 10 is an image diagram illustrating generating user-vehicle matching data 610 according to various embodiments. FIG. 10 is an example of user-vehicle matching data 610 for a user-vehicle pairs database 133 shown in FIG. 5, which is a database for storing user’s mobility profiles and known vehicles that satisfy the medical condition(s) corresponding to a user’s mobility profile.

[00141] In some embodiments, a user sub-type 611 may indicate a passenger or a driver with defined sub-type (for example, Pl, as shown in FIG. 8). Vehicle properties may be separated into rigid properties 612 and controllable properties 613. The rigid properties 612 may indicate a vehicle type 612a, a brand/model 612b, and seat assignment 612c for a passenger. The controllable properties 613 may indicate settings of vehicular systems, including, but not limited to, seat setting 613a, a distance of a user’s head from ceiling, a distance referring to ride height from rocker to the ground, or a relative distance of a user from a front dashboard 613b, an air ventilation setting that results in a specific temperature reading 613c, speed setting 613d, or other settings of audio and light systems. Although not shown, in some embodiments, the user-vehicle matching data 610 may also include additional data, for example, any critical condition pertaining to extreme environmental setting that must be avoided due to a medical condition, or any extreme condition that cannot be handled by the vehicle properties.

[00142] FIG. 11 is an image diagram illustrating matching a vehicle with a user according to various embodiments.

[00143] In some embodiments, a user-vehicle pairing module 123 shown in FIG. 5 may search for user- vehicle matching data and available vehicles to finally recommend a vehicle. In some embodiments, a process for finding the user- vehicle matching data that matches the user profile may start by receiving a user ID or user profile. Then, the user-vehicle matching data that matches the user profile may be retrieved from a user- vehicle pairs database 133 shown in FIG. 5. A search result of finding the user-vehicle matching data that matches the user profile is shown in a user-vehicle pair result table 610. Then, the user- vehicle pairing module 123 may search for available vehicles that match the vehicle associated with the user-vehicle matching data that matches the user profile, as shown in a vehicle data result table 620. Afterwards, the user-vehicle pairing module 123 may rank the available vehicles based on evaluation criteria, or single or multiple criteria such as most frequently used, least price, and fuel consumption efficient, as shown in a rank result table 630.

[00144] In some embodiments, during a creation phase, a health data analytics module 122 shown in FIG. 5 may generate a plurality of predetermined user- vehicle matching data by using aggregated health data. The health data may be analysed to determine requirements in driving, commuting, boarding, and/or alighting. The requirements may include, but are not limited to, ambient requirements, navigation requirements, and accessibility requirements. For example, the ambient requirements may include, but are not limited to, seat adjustments (for example, back angle, and a leg room), light access, space (for example, a side window, and a roof), protection (for example, an airbag), and other requirement about noise or sound levels. The navigation requirements may include, but are not limited to, speed limit, acceleration and jerk limit, altitude, and cruise control (for example, manual/assistive/automatic). The accessibility requirements may include, but are not limited to, assistance in getting on/off vehicle (for example, step in/out height), and door open/close control. Vehicle data may also be analysed to determine specifications of vehicle systems. These systems including, but not limited to, a light control system, a seat control system, a ventilation control system, an audio control system, and a cruise control system, may be analysed to determine its possible configurations. [00145] FIG. 12 is an image diagram illustrating a relation of a user, a condition and a vehicle according to various embodiments.

[00146] As shown in FIG. 12, aggregated health data 250 (for example, personal information, medical condition, and medication) may be analysed to determine requirements in driving, commuting, boarding, and/or alighting. In addition, aggregated vehicle data 350 may be analysed to determine specifications of vehicle systems (for example, light, seat, ventilation, audio, and cruise control).

[00147] In FIG. 12, U1 to U5 represent users covered in the aggregated health data, Cl to C4 represent medical conditions identified from the users, and VI to V3 represent vehicles that can handle the medical conditions. A link between the users and the medical conditions may be derived after measurable health data 240 of FIG. 6 may be derived. Similarly, a link between the vehicles and the medical conditions may be determined after rigid properties 320 and controllable properties 330 of FIG. 7 may be derived. As the number of users may be large, the users may need to be clustered by similarity in types, by application of clustering methods (for example, U3 and U5). Similarly, vehicles that are similar but not exactly identical for the medical conditions may be clustered in at least one group (for example, VI and V2; and VI and V3).

[00148] FIG. 13 is a flow diagram illustrating a method S300 for clustering a plurality of users and a plurality of vehicles according to various embodiments. According to various embodiments, the method S300 for clustering the plurality of users and the plurality of vehicles is provided. In some embodiments, the method S300 may be operated by a health data analytics module 122 shown in FIG. 5, during a creation phase.

[00149] In some embodiments, the method S300 may include a step S301 of receiving aggregated health data and filtering the aggregated health data to include only medical conditions relevant to mobility concerns. The step S301 may further include translating the aggregated health data to mobility requirements by analysing the aggregated health data to know driving, commuting, boarding, and/or alighting constraints.

[00150] In some embodiments, in the step S301, the health data analytics module 122 may receive the aggregated health data and filter the aggregated health data to include only the medical conditions relevant to the mobility concerns. The health data analytics module 122 may transform the aggregated health data to the mobility requirements by analysing the aggregated health data to know driving, commuting, boarding and/or alighting constraints, or transform the aggregated health data to measurable health data as shown in FIG. 6.

[00151] In some embodiments, the method S300 may include a step S302 of retrieving vehicle data or receive the vehicle data from a vehicle data system 300. The step S302 may further include translating the vehicle data into a measurable property by gathering specifications of the vehicle system (for example, limit values), as shown in FIG. 7.

[00152] In some embodiments, the method S300 may include a step S3O3 of, for each model in the vehicle data, comparing the limit values of measurable properties of the vehicle and the requirements from the health data. The step S3O3 may further include, if a value is within the limit value, selecting a vehicle model and associating to a corresponding medical condition, thus creating a link between a vehicle and a medical condition as shown in FIG. 12.

[00153] In some embodiments, the method S300 may include a step S304 of reducing the number of user count by clustering (for example, by clustering U1 to U5 as shown in FIG. 12) based on common medical conditions. The step S304 may further include generating a vehicle cluster based on common connections of vehicles to the medical conditions (for example, by clustering VI to V2; and VI to V3, as shown in FIG. 12). The step S304 may further include applying priority on the medical conditions (for example, critical condition, must for driving, etc.) and determining user type (for example, driver, passenger and sub-types), as shown in FIG. 8.

[00154] FIG. 14A is a block diagram illustrating a server 100 and a vehicle data system 300 according to various embodiments according to various embodiments. FIG. 14B is an example diagram illustrating a control setting of a vehicle according to various embodiments. [00155] A planning control module 124 shown in FIG. 5 and FIG. 14A may generate the control setting of the vehicle, based on mobility requirements for driving, commuting, boarding, and/or alighting. As shown in FIG. 14B, the control setting of the vehicle may include appropriate seat assignment of a user, vehicle systems (for example, light, audio, and temperature), and/or a driving setting. In some embodiments, the planning control module 124 may be interfaced with vehicular systems, sensors, telematics and/or other monitoring devices, to monitor dynamic vehicle data and environmental data and adjust the control setting of the vehicle.

[00156] FIG. 15 is a flow diagram illustrating a method S400 for updating predetermined uservehicle matching data according to various embodiments. According to various embodiments, the method S400 for updating predetermined user-vehicle matching data by an offline evaluation method is provided. In some embodiments, the method S400 may be operated by a health data analytics module 122 shown in FIG. 5, during a usage phase.

[00157] In some embodiments, during the usage phase, the health data analytics module 122 may evaluate user-vehicle matching, using dynamic vehicle data and environment data. The health data analytics module 122 may evaluate by comparing requirements for driving, commuting, boarding, and/or alighting to the dynamic vehicle data by monitoring vehicular system settings, and outside environment data by monitoring temperature, traffic, and/or noise during travel. The evaluation of measurements may be made by offline and/or online methods. For the offline evaluation (as shown in FIG. 15), a user may be asked for subjective evaluation before and after travel. For the subjective evaluation, the user may be asked if the travel is good or not good based on the vehicle settings and other environmental conditions. It may be asked at various travel instances, either before or after travel. On the other hand, the online evaluation (as shown in FIG. 17) may use at least one device to monitor changes in the user’s body or activity, including, but not limited to, breathing, body temperature, and eye movement, resulting in objective evaluation.

[00158] In some embodiments, the method S400 may include a step S401 of retrieving uservehicle matching data to determine the user’s mobility profile, vehicle data and associated medical conditions. The step S401 may further include filtering the user-vehicle matching data with changes in the evaluation (for example, from good (G) to not good (NG), and vice versa). [00159] In some embodiments, the method S400 may include a step S402 of retrieving related dynamic vehicle data and environment data for the determined user- vehicle matching data, for example, based on user ID and/or time stamps. [00160] In some embodiments, the method S400 may include a step S403 of conducting analysis (for example, factor analysis, principal component analysis, and machine learning) to determine a root cause of the changes. For example, the step S403 is to determine if the changes in the evaluation is verifiable by finding the root cause. For example, a change in the evaluation may be said to be verifiable if there is a corresponding change in environmental readings and/or vehicle settings (for example, speed, lighting, and sound).

[00161] In some embodiments, the method S400 may include a step S404 of determining if the root cause is statistically significant. The step S404 may further include, based on the significance, deciding if the changes from G to NG or from NG to G may be validated. The step S404 may further include updating the user-vehicle matching data to a user-vehicle pairs database 133 shown in FIG. 5.

[00162] FIG. 16 is an image diagram illustrating vehicle data with user evaluation according to various embodiments. FIG. 16 shows an example of vehicle data with user evaluation 719. [00163] Although not shown, the data may be timestamped to verify travel time period of a user. Such data may also be extended to include dynamic vehicle data that may be timestamped and identifiable to the user and a vehicle used. When a change in the evaluation 719 is validated (for example, from G to NG), the vehicle data together with the dynamic vehicle data may be analysed to determine a root cause of the change, and/or anomaly in measurements (for example, wearable devices) and settings (for example, vehicle -settings) that trigger the change. [00164] FIG. 17 is a flow diagram illustrating a method S500 for updating predetermined uservehicle matching data according to various embodiments. According to various embodiments, the method S500 for updating predetermined user-vehicle matching data by an online evaluation method is provided. In some embodiments, the method S500 may be operated by a health data analytics module 122 shown in FIG. 5, during a usage phase. In this setting, measuring devices such wearable devices and sensors may be installed.

[00165] In some embodiments, the method S500 may include a step S501 of monitoring system settings based on a control setting of a vehicle, as well as the sensor readings. In some embodiments, in the step S501, the health data analytics module 122 may monitor the sensor readings and compare the system settings based on the control setting of the vehicle.

[00166] In some embodiments, the method S500 may include a step S502 of, if abnormality is detected in the sensor readings, sending alert to a server 100, for example, a planning control module 124, to adjust the control setting of relevant systems of the vehicle. [00167] In some embodiments, the method S500 may include a step S503 of detecting if the change in the control setting by the planning control module 124 resolves the abnormality. The step S503 may further include continuing revising the control setting of the vehicle, if needed. [00168] In some embodiments, the method S500 may include a step S 504 of updating the uservehicle matching data based on the system setting that resolves the abnormality.

[00169] Advantageously, the method S500 may improve comfortability and safety of the user immediately during the travel.

[00170] FIG. 18 is an image diagram illustrating a user interface according to various embodiments.

[00171] As shown in FIG. 18, in some embodiments, a user 851 may provide the user’s identification (or identity) 810, which may correspond to the user 851, to retrieve the user’s health data. After retrieving the user’s health data, a vehicle may be searched 820. A vehicle 821 may be successfully found and the vehicle’ s properties may be later displayed, for example, in the form of VI 822, V2 823 and V3 824. In some embodiments, limit values 830 of the vehicle’s properties may be scaled from 0 to 100, and provide a single panel for displaying the vehicle’s properties. The vehicle’s properties’ allowable value or a range of values from minimum values to maximum values may be represented as graphically shown as boxes 841, 843, 845. Based on the user’s health data, the control setting of each vehicle property may be selected and displayed as denoted by 842, 844 and 846. As shown in FIG. 18, the vehicle may be considered to be successfully found, since the control setting of each vehicle property may be adjusted to comply with the user’s requirements 842, 844, 846.

[00172] FIG. 19 is an image diagram illustrating a user interface according to various embodiments.

[00173] As shown in FIG. 19, in some embodiments, multiple users, for example, a first user 951, a second user 952, and a third user 953, may provide each user’s identification (or identity) 910, which may correspond to each of the first user 951, the second user 952, and the third user 953 respectively, to retrieve the multiple users’ health data. After retrieving the multiple users’ health data, a vehicle may be searched 920. A vehicle 921 may be successfully found and the vehicle’s properties may be later displayed, for example, in the form of VI 922, V2 923 and V3 924. Based on the multiple users’ health data, a control setting of the vehicle that is appropriate to the multiple users 951, 952, 953 may be displayed. In a first vehicle property V 1 922, seat incline may be set individually given that the control setting of the vehicle for the seat incline may be adjusted depending on each user’s seating. On the other hand, in a second vehicle property V2 923, the second user 952 and the third user 953 may have similar control setting, while the first user 951 may require a different control setting. This may be possible, for example, as the second user 952 and the third user 953 may be seated near or beside each other inside a vehicle area that may have the same light setting.

[00174] FIG. 20 illustrates use cases of a server 100 according to various embodiments.

[00175] According to various embodiments, some users may have mobility needs, as they may have physical or medical conditions, or be under medication. The server 100 according to various embodiments may support the user’s journey from selecting vehicles (for example, rental, book, or purchase) to actual use. The server 100 according to various embodiments may have advantages as follows:

1) As shown in (a) and (b) of FIG. 20, for a driver or a passenger, there may be no need to explicitly state the underlying physical or medical conditions, and there may be no need to know or search for travel restrictions due to the physical or medical conditions. The server 100 may be capable of automatically checking these restrictions. In some embodiments, the user may subscribe to mobility control service, for example, by inputting a user ID, vehicle information, and itinerary information. A control setting of the vehicle suitable for the user may then be output.

2) As shown in (c) of FIG. 20, for a seller or an agent of vehicles, there may be no need to directly ask the physical or medical conditions of a customer. Although the agent may optionally confirm restrictions without knowing the physical or medical conditions, the server 100 may hide the physical or medical conditions.

3) For an automotive manufacturer, the server 100 may provide a direct access to mobility needs of consumers to improve an automotive design.

[00176] While embodiments of the invention have been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced. It will be appreciated that common numerals, used in the relevant drawings, refer to components that serve a similar or the same purpose. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C,” “one or more of A, B, or C,” “at least one of A, B, and C,” “one or more of A, B, and C,” and “A, B, C, or any combination thereof’ include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C,” “one or more of A, B, or C,” “at least one of A, B, and C,” “one or more of A, B, and C,” and “A, B, C, or any combination thereof’ may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module,” “mechanism,” “element,” “device,” and the like may not be a substitute for the word “means.” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for.”