A method for acquiring travel service data in a mobile MaaS system
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA ACAD OF TRANSPORTATION SCI
- Filing Date
- 2026-03-10
- Publication Date
- 2026-07-31
AI Technical Summary
（2）出行数据是涉及用户路径轨迹数据，属于高等级隐私安全数据，现有技术对于用户信息传输中数据隐私安全保护程度不足
1、本发明在存在数据上报不快速、不及时的现象时，本发明的方法能够在移动应用中更快速、完整的上报出行数据，对整个用户出行服务可以提供更好的用户体验；
Smart Images
Figure CN122496514A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of transportation service technology, specifically a method for acquiring travel service data in a mobile MaaS system. Background Technology
[0002] With the development of mobile internet, big data, cloud computing, shared transportation, and electronic payment technologies in recent years, Mobility as a Service (MaaS) has emerged. It integrates travel services across various modes of transportation, aggregating personal travel data, vehicle attribute data, and other basic transportation data shared by different transportation service providers, bringing new opportunities for reconstructing urban individual travel chains. The MaaS system's client collects the user's current location information and reports it to the MaaS system. Based on this user information, the MaaS system provides users with relevant information services related to their travel chain.
[0003] MaaS (Mobility as a Service) systems are used to provide users with travel services. However, for MaaS clients, the common approach is to develop an application based on a mobile device to obtain real-time travel service data from the server. This approach typically suffers from high latency, poor stability, and the possibility of data omissions or expiration. Furthermore, users' environments are complex, with unstable network conditions. For example, users may experience poor network signal in tunnels or densely populated areas, or their network may malfunction, or a specific MaaS server in a particular area may fail. Therefore, users relying on this data may encounter problems such as not being able to find nearby shared bikes or missing public transportation, negatively impacting their travel experience.
[0004] Furthermore, existing MaaS technology has two shortcomings in overall system computing: (1) In some special scenarios, data reporting is slow and untimely. Faster and more complete reporting of travel data in mobile applications can provide a better user experience for the entire user travel service; (2) Travel data involves user path trajectory data, which belongs to high-level privacy and security data. Existing technologies are insufficient in protecting the privacy and security of user information during transmission.
[0005] Therefore, to address the above issues, a method for obtaining travel service data in a mobile MaaS system is needed. Summary of the Invention
[0006] The purpose of this invention is to provide a method for acquiring travel service data in a mobile MaaS system. Taking into account practical situations, this invention can conveniently and accurately locate users when their network is interrupted or their positioning is inaccurate, and protects user data privacy and security by encrypting the data.
[0007] This invention is implemented as follows: This invention provides a method for acquiring travel service data in a mobile MaaS system, which is specifically implemented according to the following steps: S1: First, install the MaaS mobile client through a smart terminal. The MaaS mobile client accesses the MaaS server via the Internet. The MaaS mobile client and the MaaS server establish a connection via the Internet, specifically through short connection requests established via HTTP or HTTPS. Between the MaaS mobile client and the MaaS server, a long connection is also established for data communication. The long connection includes general services, sending the request content of the aforementioned short connection, and also includes sending the request content of the long connection. The long connection also includes sending requests for different domains (such as www.abc.dom, www.abd.com). After receiving the data, the server processes the request content. The MaaS client sends data as follows: S1.1: The MaaS client prioritizes all requests according to their importance, specifically in two levels: the more important the request, the higher the priority; the more urgent the request, the higher the priority. The MaaS client pre-classifies each request according to the business situation. S1.2: The MaaS client calculates the size of the requested data and estimates the size of each request based on historical data experience from the MaaS server, thereby obtaining the data packet size of each request. S1.3: For short connection requests, the MaaS client establishes a connection pool and puts the connection into the idle connection pool after sending the request. When sending a request, the MaaS client first checks the connection pool for an idle connection. If an idle connection is available, it immediately uses the connection in the connection pool to send the request. If not, it will establish a new connection to send the request. S1.4: Set a threshold for the size of request data packets for all requests. Requests exceeding the threshold will not be sent using long connections to avoid consuming network bandwidth on long connections. S1.5: For the highest priority request, when sending using a short connection, if the request fails, the long connection will be used immediately to retry the request. At the same time, when sending the highest priority request, a timer will be designed. If the request does not return a result within a preset time, the long connection will be used to send the request immediately. S1.6: All requests are stored in a queue, which is sorted according to priority and the time order of the request tasks. When there are no tasks in the queue, and no available free connection can be found in the connection pool for short connections, and the packet size is within the threshold, long connections are used for data transmission.
[0008] When users encounter network problems while traveling, timely network retry is the most effective solution. However, in reality, when a user's network fails or becomes unreachable from the server, the frequency of network retry by the MaaS client can consume a certain amount of power and cause the device to overheat. Therefore, the retry strategy needs to ensure network accessibility and timeliness without consuming too much power from the user's device.
[0009] Specifically, when a user begins their trip, they report their current location information. After starting, the MaaS server sends the location area and time range it has traversed to the client. The MaaS client also reports this information promptly when network connectivity is available. Simultaneously, the server adjusts the location area and time range based on the client's reported location and time and sends it to the MaaS client. If the MaaS client experiences network issues or malfunctions, it can first attempt a network retry. If this fails, it uses this data to determine the time and location range. If the location falls within the range (referring to the server-reported location area and time range), it retryes at regular intervals. If the location is outside the range, a more passive retry strategy is adopted, such as retrying every 2, 5, or 10 minutes. If the user obtains their current location information under conditions of network congestion and compares it with the server-reported location information, and if the location falls within the range of the next traffic node or the time node, a more aggressive retry strategy is adopted, with retry frequencies increased to multiple times, such as every 1 minute, 30 seconds, or 10 seconds. Once connected to the server, location information should be reported promptly.
[0010] S2: Users plan their trip from origin to destination via the MaaS mobile app. The MaaS server plans the optimal travel route based on the input information. The MaaS server estimates the approximate time of the user at each transportation node and reports the user's actual location data to the MaaS server to dynamically adjust the planned route in real time.
[0011] S3: The MaaS server distributes a list of the optimal node servers for the user based on the platform user and server load, the user's access speed to the server, and the user's network operator information. After receiving the list of optimal node servers for the user, the MaaS client performs a speed test together with the IP list pre-resolved by Httpdns and sorts the results according to the access speed.
[0012] S4: The client simultaneously reports the local sorting results, and the MaaS server also pre-sorts and schedules the nodes accessed by subsequent users. It then parses and forwards the data to different servers to retrieve the corresponding information. The MaaS client carries specific fields in its requests for server identification and forwarding. Each request specifically includes the following fields: a unique request ID (a string of numbers, unique for each request), a long or short link field calculated and concatenated based on the user ID, timestamp, and an auto-incrementing random number, the request domain name field, the specific request path, and the specific request data. The MaaS server forwards the request to different MaaS servers based on the domain name and the request path to retrieve the corresponding data. At the same time, it returns the results to the MaaS client. The MaaS server will also return some fields in the return fields, including the unique request ID, the requested domain name and the requested path, as well as the corresponding data.
[0013] Furthermore, based on the MaaS server, the entire range of the traveling user is obtained, and the fellow travelers are also obtained. The network of the fellow travelers is obtained on the MaaS server, and it is determined which fellow travelers' online classes are available and which are out of service. Based on the user's location information, the MaaS server selects users from the traveling users in the same distance to assist the out-of-service user by uploading the location data of the out-of-service user and sending relevant data from the server to the out-of-service user's device.
[0014] Specifically, all MaaS clients connect to the MaaS server, allowing the MaaS server to obtain all users' IP information, network information, and carrier information. When a MaaS client starts up, and the MaaS client establishes a connection with the server, the MaaS server can encrypt and send the IP data of other users in the same industry to the MaaS client of that industry, thus obtaining the IP address of the other industry member, and subsequently establishing a network connection with that industry member.
[0015] Furthermore, all MaaS clients enable network listening. When a request is detected from another MaaS client, a connection is established with that client, which can then assist the user in sending requests to obtain server information, etc.
[0016] When a user has a problem connecting to the MaaS service, but can still connect to other nearby users, the MaaS client will use network protocols to probe for other nearby MaaS clients. All MaaS clients will listen for the current user's network connection. When any client initiates a connection using the MaaS protocol, the corresponding client will receive the request and assist in sending the request and obtaining data.
[0017] If a user device experiences a network outage, it can use Bluetooth to connect to a nearby MaaS client and have other MaaS clients with network access assist in sending requests and retrieving data.
[0018] Furthermore, the data between the MaaS client and the MaaS server is encrypted, specifically including: First, the MaaS server categorizes the possible peers for each stage. Each stage is a group of users. The MaaS server first obtains the user's unique identifier uid (which is a string of 128 numbers). After obtaining these UIDs, the MaaS server calculates the corresponding allocation information, which introduces a degree of randomness, thereby avoiding the exposure of all peer information and also enhancing security.
[0019] Then, on the MaaS server, a hash algorithm is used, including md5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, RIPEMD-160, Tiger, sm3, blake2, gost, etc., to uniquely encode the transportation node using a 1024-bit string. For example, shared bicycles are 1, cars are 2, trains are 3, and so on, thus obtaining a unique travel transportation code. Provincial and municipal codes are then added to the encoding to achieve nationwide uniqueness. When a MaaS client initiates a travel service, a list of encoded transportation nodes can be generated based on the transportation nodes required for its travel. Since the transportation nodes that any MaaS client will encounter during its travel are fixed, its corresponding encoded list can be obtained. Once any MaaS client connects to the MaaS server, the server generates information and sends it to the MaaS client. The specific calculations are as follows: Data = Uid + time + unique travel ID + random number (32-bit hexadecimal string) The uid is the user's unique identifier on the MaaS platform (a 128-character hexadecimal string). Furthermore, the present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the mobile terminal MaaS system travel service data acquisition method described in any one of the above-mentioned methods.
[0020] Furthermore, the present invention provides a computer-storable medium storing a computer program, wherein when the program is executed, it sequentially executes any one of the above-described methods for obtaining travel service data in a mobile MaaS system.
[0021] Compared with the prior art, the beneficial effects of the present invention are: 1. When there is a problem of slow or untimely data reporting, the method of this invention can report travel data more quickly and completely in mobile applications, which can provide a better user experience for the entire user travel service. 2. This invention ensures the data security of the MaaS client and other clients through layers of data encryption and encrypted transmission. Attached Figure Description
[0022] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.
[0023] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation
[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to describe selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0025] Please see Figure 1This invention provides a method for obtaining travel service data in a mobile MaaS system, which is specifically implemented according to the following steps: S1: First, install the MaaS mobile client through a smart terminal. The MaaS mobile client accesses the MaaS server via the Internet. The MaaS mobile client and the MaaS server establish a connection via the Internet, specifically through short connection requests established via HTTP or HTTPS. The MaaS client sends data as follows: S1.1: The MaaS client prioritizes all requests according to their importance, specifically in two levels: the more important the request, the higher the priority; the more urgent the request, the higher the priority. The MaaS client pre-classifies each request according to the business situation. S1.2: The MaaS client calculates the size of the requested data and estimates the size of each request based on historical data experience from the MaaS server, thereby obtaining the data packet size of each request. S1.3: For short connection requests, the MaaS client establishes a connection pool and puts the connection into the idle connection pool after sending the request. When sending a request, the MaaS client first checks the connection pool for an idle connection. If an idle connection is available, it immediately uses the connection in the connection pool to send the request. If not, it will establish a new connection to send the request. S1.4: Set a threshold for the size of request data packets for all requests. Requests exceeding the threshold will not be sent using long connections to avoid consuming network bandwidth on long connections. S1.5: For the highest priority request, when sending using a short connection, if the request fails, the long connection will be used immediately to retry the request. At the same time, when sending the highest priority request, a timer will be designed. If the request does not return a result within a preset time, the long connection will be used to send the request immediately. S1.6: All requests are stored in a queue, which is sorted according to priority and the time order of the request tasks. When there are no tasks in the queue, and no available free connection can be found in the connection pool for short connections, and the packet size is within the threshold, long connections are used for data transmission.
[0026] When users encounter network problems while traveling, timely network retry is the most effective solution. However, in reality, when a user's network fails or becomes unreachable from the server, the frequency of network retry by the MaaS client can consume a certain amount of power and cause the device to overheat. Therefore, the retry strategy needs to ensure network accessibility and timeliness without consuming too much power from the user's device.
[0027] Specifically, when a user begins their trip, they report their current location information. After starting, the MaaS server sends the location area and time range it has traversed to the client. The MaaS client also reports this information promptly when network connectivity is available. Simultaneously, the server adjusts the location area and time range based on the client's reported location and time and sends it to the MaaS client. If the MaaS client experiences network issues or malfunctions, it can first attempt a network retry. If this fails, it uses this data to determine the time and location range. If the location falls within the range (referring to the server-reported location area and time range), it retryes at regular intervals. If the location is outside the range, a more passive retry strategy is adopted, such as retrying every 2, 5, or 10 minutes. If the user obtains their current location information under conditions of network congestion and compares it with the server-reported location information, and if the location falls within the range of the next traffic node or the time node, a more aggressive retry strategy is adopted, with retry frequencies increased to multiple times, such as every 1 minute, 30 seconds, or 10 seconds. Once connected to the server, location information should be reported promptly.
[0028] Based on the MaaS server, the entire range of the traveling user is obtained, and the fellow travelers are also obtained. The MaaS server then obtains the network of the fellow travelers and determines which fellow travelers' online classes are available and which are experiencing problems. The MaaS server selects users from the traveling users in the same distance based on the user's location information to assist the user experiencing problems by uploading the location data of the user experiencing problems and sending relevant data from the server to the device of the user experiencing problems.
[0029] Specifically, all MaaS clients connect to the MaaS server, allowing the MaaS server to obtain all users' IP information, network information, and carrier information. When a MaaS client starts up, and the MaaS client establishes a connection with the server, the MaaS server can encrypt and send the IP data of other users in the same industry to the MaaS client of that industry, thus obtaining the IP address of the other industry member, and subsequently establishing a network connection with that industry member.
[0030] Furthermore, all MaaS clients enable network listening. When a request is detected from another MaaS client, a connection is established with that client, which can then assist the user in sending requests to obtain server information, etc.
[0031] When a user has a problem connecting to the MaaS service, but can still connect to other nearby users, the MaaS client will use network protocols to probe for other nearby MaaS clients. All MaaS clients will listen for the current user's network connection. When any client initiates a connection using the MaaS protocol, the corresponding client will receive the request and assist in sending the request and obtaining data.
[0032] If a user device experiences a network outage, it can use Bluetooth to connect to a nearby MaaS client and have other MaaS clients with network access assist in sending requests and retrieving data.
[0033] S2: Users plan their trip from origin to destination via the MaaS mobile app. The MaaS server plans the optimal travel route based on the input information. The MaaS server estimates the approximate time of the user at each transportation node and reports the user's actual location data to the MaaS server to dynamically adjust the planned route in real time.
[0034] S3: The MaaS server distributes a list of the optimal node servers for the user based on the platform user and server load, the user's access speed to the server, and the user's network operator information. After receiving the list of optimal node servers for the user, the MaaS client performs a speed test together with the IP list pre-resolved by Httpdns and sorts the results according to the access speed.
[0035] S4: The client simultaneously reports the local sorting results, and the MaaS server also pre-sorts and schedules the nodes accessed by subsequent users. The MaaS client carries specific fields in its requests for server identification and forwarding to different servers. Each request specifically includes the following fields: a unique request ID (a string of numbers, unique for each request), a long or short link field calculated and concatenated based on the user ID, timestamp, and an auto-incrementing random number, the request domain name field, the specific request path, and the specific request data. The MaaS server forwards the request to different MaaS servers based on the domain name and the request path to retrieve the corresponding data. At the same time, it returns the results to the MaaS client. The MaaS server will also return some fields in the return fields, including the unique request ID, the requested domain name and the requested path, as well as the corresponding data.
[0036] Between the MaaS mobile client and the MaaS server, a long-lived connection is also established for data communication. This long-lived connection includes general services that send the request content of the aforementioned short-lived connection, as well as the request content of the long-lived connection. The long-lived connection also includes sending requests to different domains (such as www.abc.dom, www.abd.com). After receiving the data, the server parses the request content and forwards it to different servers to obtain the corresponding data.
[0037] In this embodiment, the data between the MaaS client and the MaaS server is encrypted, specifically including: First, the MaaS server categorizes the possible peers for each stage. Each stage is a group of users. The MaaS server first obtains the user's unique identifier uid (which is a string of 128 numbers). After obtaining these UIDs, the MaaS server calculates the corresponding allocation information, which introduces a degree of randomness, thereby avoiding the exposure of all peer information and also enhancing security.
[0038] Then, on the MaaS server, a hash algorithm is used, including md5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, RIPEMD-160, Tiger, sm3, blake2, gost, etc., to uniquely encode the transportation node using a 1024-bit string. For example, shared bicycles are 1, cars are 2, trains are 3, and so on, thus obtaining a unique travel transportation code. Provincial and municipal codes are then added to the encoding to achieve nationwide uniqueness. When a MaaS client initiates a travel service, a list of encoded transportation nodes can be generated based on the transportation nodes required for its travel. Since the transportation nodes that any MaaS client will encounter during its travel are fixed, its corresponding encoded list can be obtained. In this embodiment, when any MaaS client connects to the MaaS server, the server generates information and sends it to the MaaS client. The specific calculation is as follows: Data = Uid + time + unique travel ID + random number (32-bit hexadecimal string) The uid is the user's unique identifier on the MaaS platform (a 128-character hexadecimal string). Where 'time' is the current timestamp (a 13-digit numeric string, in milliseconds); The unique travel ID, TraceID, is a 1024-character hexadecimal string, and a unique travel ID is generated for each travel.
[0039] The 32-bit hexadecimal random number string is generated using the system's random number generator. In this embodiment, the SHA-256 hash algorithm is specifically used to calculate the hash value of this data.
[0040] Hash_result = sha-256(Data); Data is a string concatenated from the above fields, and hash_result is a 256-bit hexadecimal string.
[0041] In this embodiment, the user's journey is segmented according to traffic nodes. Within each segment, the server selects a subset of users from the fellow travelers. The selection strategy is to have at least one user selected, but less than 10 users selected per segment (considering the connection frequency between each client and its corresponding fellow travelers; too many users would burden the client). Specifically, this embodiment uses the hash_result calculated above for selection.
[0042] The specific number of users selected in each stage, `select_number`, is determined from `hash_result`. The first stage uses the first two data points of `hash_result`, representing the percentage of users selected. For example, if the first two data points are 10, and there are a total of 100 selectable users in the first stage, then 10 * 100 / 100 = 10 users will be selected. Also, based on the above constraint, this data point must be greater than or equal to 1 and less than or equal to 10. For example, if the hash value is 1234567, and the first two digits are 12, assuming there are 100 users in total, then the percentage of users to be selected is 12% (according to a user-defined rule). Therefore, a total of 100 * 12% = 12 users need to be selected. In this embodiment, for all users in each stage, the users in that stage are selected by sorting and numbering them by their UIDs. 0 is the first user, 1 is the second user, and so on. The specific selection strategy is to start from the last bit of the hash_result and work backwards. For every two digits, the remainder is taken from the total number of users to be selected (e.g., 100 users above) to determine the corresponding UID number. This process continues, counting down two digits to select the next user, and so on, cycling through the 256 bits of data to select the next user's number. For example, if the hash value is 1234567, the first selected user is the 67th user (sorted by UID from smallest to largest), and the second user is the 45th user. Assuming there are 100 users, after selecting one user each time (the same user cannot be selected repeatedly), the remaining users are selected according to the hash encoding rules. If there are only 50 users in total, and 67 users are to be selected, then 67-50=17 (remainder) is used to select the 17th user.
[0043] In this embodiment, considering the network operator issues of numerous users at each stage, the present invention groups users with the same operator into one group and users with different operators into another group when selecting users in the same industry. Priority is given to users in the same operator group, while also ensuring that some users are selected from groups with different operators. Specifically, the ratio is chosen as 70% for the same operator and 30% for different operators, or 60% and 40%. If there are users with different operators, this strategy is followed; if all users are from the same operator, the selection is made from the same operator group.
[0044] In this embodiment, the selection strategy is completed by selecting the number of users (select_number) for each stage and the set of user uids selected for each stage, thus obtaining the uid set for each stage.
[0045] In this embodiment, user ID transformation hides data security.
[0046] The MaaS server sends user information, including the user's IP address and unique identifier, to the client for each stage of the journey. However, considering that sending the unique identifier directly to the client would lead to information leakage, this invention generates a one-to-one temporary unique identifier for all users each time a client makes a request. The temporary unique identifier is sent to the client, while the MaaS server binds the real user's unique identifier to each temporary unique identifier. The temporary unique identifier is used only once and is regenerated for each subsequent request. The specific generation strategy is as follows: Temp_userid=SHA-512(TraceID+Time)+SHA-512(Time+userid); The final result is a 1024-bit hexadecimal string named Temp_userid; TraceID is the unique travel ID mentioned above. TraceID is a 1024-digit numeric string. Where Time represents the current moment, a 13-digit timestamp. SHA-512 is a hash algorithm that produces a 512-bit hexadecimal string.
[0047] Using the TraceID and timestamp together to calculate the SHA-512 hash algorithm yields a 512-bit hexadecimal string.
[0048] The hash algorithm that calculates SHA-512 using the user's real unique ID and timestamp results in a 512-bit hexadecimal string.
[0049] Concatenating the data from the two hash results together yields a string of 1024, which serves as a temporary unique ID.
[0050] In this embodiment, a temporary unique ID is calculated for each user according to this algorithm. The use of `traceid` and `time` ensures that the generated temporary ID is unique at every moment. The use of `time` and `userid` ensures that each user is unique at every moment.
[0051] In this embodiment, a data encryption key is designed. When a MaaS client starts up and initiates a connection to the MaaS server to begin its process, the MaaS server needs to design data security with the client, and also needs to consider the data security of the MaaS client with other clients.
[0052] For the server portion, the server's private key data is generated by the MaaS server and used to encrypt data with the MaaS client.
[0053] The present invention is designed to use the Hash_result data generated above, the current timestamp data, and the user's Temp_userid data together to calculate SHA-512 to obtain the hash result data; Result1 = SHA-512(TraceID + Hash_result + Temp_userid + Time); This data is a 512-bit hexadecimal string.
[0054] Result2=SHA-512(TraceID+userid+Time); Then, in this embodiment, the server's private key data is generated: Server_Private_key = Result1 + Result2 + Temp_userid Result1 is a 512-bit hexadecimal string, Result2 is a 512-bit hexadecimal string, Temp_userid is a 1024-bit hexadecimal string, and the final Server_Private_key is a 2048-bit hexadecimal string.
[0055] In this embodiment, the server public key data is generated using an asymmetric encryption algorithm. In the previous embodiment, the server private key data was generated. In this embodiment, the RSA asymmetric encryption algorithm is used to generate the corresponding public key data.
[0056] Server_Publickey=RSA.CreatePair(Server_Private_key); The public key is generated by calling RSA's key pairing function. RSA.CreatePair is the public key generation interface provided by the RSA algorithm for pairing the private key with the public key.
[0057] The present invention then generates a public key Server_Publickey, which is a 2048-bit hexadecimal string of the same length as the private key.
[0058] Ultimately, this invention obtains a pair of key data, Server_Private_key and Server_Publickey, on the server.
[0059] The server uses the above algorithm to generate a pair of public and private key data for each traveler's companions.
[0060] Each MaaS client has a unique Temp_userid. Therefore, the private key data generated by the server for each MaaS client is different, and consequently, the corresponding public key data is also different.
[0061] The MaaS server sends the public key data of each MaaS client to the MaaS client.
[0062] In this embodiment, on the client side, private key data is generated for each MaaS client. For each MaaS client, the MaaS client uses its own device information, user information, and current timestamp to generate the private key data.
[0063] Result1=SHA-512(DeviceInfo+userid + Time); This data is a 512-bit hexadecimal string.
[0064] DeviceInfo contains device information, such as the device's unique ID, device name, and model number, which are concatenated into a string.
[0065] The userid is the unique user ID for each MaaS user.
[0066] Where Time is the current timestamp information.
[0067] Result2 = SHA-512(Result1 + DeviceInfo + userid + Time); This data is a 512-bit hexadecimal string.
[0068] In this embodiment, the above information is used again along with the result data to generate the hash result data again, which is also a 512-character string.
[0069] Then, in this embodiment, the client's private key data is generated: Client_Private_key = Result1+ Result2 + userid Result1 is a 512-bit hexadecimal string, Result2 is a 512-bit hexadecimal string, userid is a 1024-bit hexadecimal string, and finally Client_Private_key is a 2048-bit hexadecimal string.
[0070] In a second embodiment of the present invention, public key data is generated for each MaaS client.
[0071] This invention uses the same asymmetric encryption algorithm as the server to generate a key pair. In the first embodiment described above, this invention generates the client's private key data. In the second embodiment, this invention uses the asymmetric encryption algorithm RSA to generate the corresponding public key data, as detailed below: Client_Publickey= RSA.CreatePair(Client_Private_key); The public key is generated by calling RSA's key pairing function. RSA.CreatePair is the public key generation interface provided by the RSA algorithm for pairing the private key with the public key.
[0072] In this embodiment, a public key Client_Publickey, a 2048-bit hexadecimal string of the same length as the private key, is generated.
[0073] In this embodiment, the client ultimately obtains a pair of key data, Client_Private_key and Client_Publickey.
[0074] After the client starts, it will send the client's public key data to the MaaS server.
[0075] MaaS client -> MaaS server; Client_Publickey is sent to the server. Send to the client Server_Publickey After the exchange is completed, in this embodiment, a shared key is generated on both the client and the server.
[0076] Client-side components: KEY=RSA.Sharekey(Client_Private_key, Server_Publickey); The generated shared key, client private key, and server public key; Server components: KEY=RSA.Sharekey(Server_privatekey, Client_publickey); The generated shared key, server private key, and client public key; Ultimately, both the client and the server generate a shared key. The value of the key is calculated independently by each server, but the final generated shared key is the same.
[0077] In this embodiment, data transmission between the server and the client uses this shared secret key.
[0078] The client and server then use AES (symmetric encryption algorithm) to encrypt the data, using a shared key as the encryption key.
[0079] In this embodiment, a data encryption algorithm for fellow travelers is designed.
[0080] In the above embodiments, the encryption of data between the client and the server generates the final encryption key data.
[0081] When a user experiences network problems, they may need a companion to upload and retrieve data from the server. This data involves sensitive information such as user coordinates, thus requiring the design of an encryption algorithm.
[0082] This invention takes into account the characteristics of MaaS client travel and designs a key generation algorithm for the encryption algorithm.
[0083] The MaaS server knows in advance the travel path of the MaaS client, the node of the vehicle it is using, and its approximate location at each moment.
[0084] A MaaS client's peers are certainly other MaaS clients in its vicinity.
[0085] In this embodiment, a key generation algorithm is designed that does not require negotiation with the server, because the client may experience network failures and be unable to communicate with the server to negotiate the key.
[0086] When a MaaS client experiences a network failure, it can request the MaaS server from other MaaS clients. This request will include timestamp information, allowing the client to know the approximate time of the other MaaS client.
[0087] When a MaaS server initiates a trip with a MaaS client, the approximate latitude and longitude of the location reached at each moment is within a certain range. Based on the time information reported by other clients, the latitude and longitude range of the encrypted data at that moment can be determined.
[0088] The MaaS client uses the current latitude and longitude information, amplified for greater precision, and combines this with the unique identifier of the currently used transportation node to generate key data. The latitude and longitude amplification range can be set by referring to the actual mode of transportation used.
[0089] Result1 = SHA-512(unique vehicle node code + DeviceInfo + temp_userid + magnified longitude value); The deviceinfo contains user device information, while temp_userid is a temporary unique ID generated by the server and sent to the user.
[0090] Result2 = SHA-512(unique identifier of the vehicle node + DeviceInfo + temp_userid + magnified dimension value); Key=Result1+Result2+temp_userid; In this example, result1 is 512 bits, result2 is also 512 bits, and temp_userid is a temporary unique ID of 1024 bits. Finally, in this example, the key is 2048 bits and is the secret key data.
[0091] In this embodiment, considering the actual situation, if a user's network fails and they find that their location has deviated far from their travel path, then the MaaS client can use the latitude and longitude information at the time of departure, amplify it, and then encrypt it.
[0092] In this embodiment, the MaaS client encrypts the data.
[0093] When a MaaS client experiences a network failure, it will use the aforementioned key to encrypt the current information before sending it to a fellow MaaS client. The fellow MaaS client will then send the data to the server.
[0094] EncryptData=aes.encrypt(data, key); aes.encrypt is the encryption algorithm, and data is the original data.
[0095] The key is the secret key generated above.
[0096] Then, after receiving the encrypted key data, the MaaS client in the same industry re-encrypts it using its own key in the MaaS server protocol and sends it to the MaaS server.
[0097] It will also carry the temporary unique temp_userid data of the faulty user, as well as the time information of when the data was received by its companions.
[0098] In this embodiment, the MaaS server decrypts the data. After receiving the data from the MaaS client (fellow traveler), the MaaS server first uses the key of the MaaS (fellow traveler) protocol to decrypt the data.
[0099] After obtaining the temporary unique `temp_userid` data from the decrypted data, the server can roughly estimate the user's latitude and longitude based on the time information of the currently encrypted travel data. The server can then amplify the latitude and longitude information and use the same algorithm as the client to generate the decryption key data, thereby decrypting the original data.
[0100] If the server encounters a problem decrypting the data and cannot decrypt it, it indicates a problem with the key. In the previous setup, considering the actual situation, when the MaaS client encounters a travel problem, it will use the latitude and longitude of the travel time to calculate. At this time, the server can also try to use the latitude and longitude of the travel time to generate a new key to decrypt the data.
[0101] The same server sends data to the MaaS client using the same algorithm. The server first encrypts the data using the key generated by amplifying the latitude and longitude coordinates as described above. Then, it encrypts the data using the key agreed upon with the MaaS client. The encrypted data is then sent to the MaaS client. The MaaS client (the collaborator) decrypts the data using the negotiated key. The MaaS client (the collaborator) then sends the decrypted data to the malfunctioning MaaS client.
[0102] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations will be apparent to those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A method for acquiring travel service data in a mobile MaaS system, characterized in that: Follow these steps: S1: First, install the MaaS mobile client through a smart terminal. The MaaS mobile client accesses the MaaS server via the Internet. S2: Users plan their trip from origin to destination through the MaaS mobile app. The MaaS server then plans the optimal travel route based on the input information. S3: The MaaS server distributes a list of the best node server IPs for the user based on the platform user and server load, the user's access speed to the server, and the user's network operator information. S4: The client simultaneously reports the local sorting results, and the MaaS server also sorts and schedules the nodes for subsequent user access to the server in advance.
2. The method for acquiring travel service data in a mobile MaaS system according to claim 1, characterized in that: In step S1, a connection is established between the MaaS mobile terminal and the MaaS server via the Internet, specifically through a short connection request established via HTTP or HTTPS. A long connection is also established between the MaaS mobile client and the MaaS server for data communication. The long connection includes general services, sending the request content of the aforementioned short connection, and also sending the request content of the long connection. The long connection also includes sending different domain names. After receiving the data, the server parses the request content and forwards it to different servers to obtain the corresponding data.
3. The method for acquiring travel service data in a mobile MaaS system according to claim 1, characterized in that, In step S2, the MaaS server estimates the approximate time of the user at each traffic node and reports the data based on the user's actual location to the MaaS server to dynamically adjust the planned route in real time.
4. The method for acquiring travel service data in a mobile MaaS system according to claim 1, characterized in that: In step S3, after receiving the IP list of the optimal node server for the user from the server, the MaaS client performs a speed test together with the IP list pre-resolved by Httpdns and sorts the results according to the access speed.
5. The method for acquiring travel service data in a mobile MaaS system according to claim 1, characterized in that: In step S4, the MaaS client carries specific fields in the request for the server to identify and forward to different servers; Each request specifically includes the following fields: a unique request ID (a string of numbers, unique for each request), a long or short link field calculated and concatenated based on the user ID, timestamp, and an auto-incrementing random number, the request domain name field, the specific request path, and the specific request data. The MaaS server forwards the request to different MaaS servers based on the domain name and the request path to retrieve the corresponding data. At the same time, it returns the results to the MaaS client. The MaaS server will also return some fields in the return fields, including the unique request ID, the requested domain name and the requested path, as well as the corresponding data.
6. The method for acquiring travel service data in a mobile MaaS system according to claim 1, characterized in that: In step S1, the MaaS client sends data as follows: S1.1: The MaaS client prioritizes all requests according to their importance, specifically in two levels: the more important the request, the higher the priority; the more urgent the request, the higher the priority. The MaaS client pre-classifies each request according to the business situation. S1.2: The MaaS client calculates the size of the requested data and estimates the size of each request based on historical data experience from the MaaS server, thereby obtaining the data packet size of each request. S1.3: For short connection requests, the MaaS client establishes a connection pool and puts the connection into the idle connection pool after sending the request. When sending a request, the MaaS client first checks the connection pool for an idle connection. If an idle connection is available, it immediately uses the connection in the connection pool to send the request. If not, it will establish a new connection to send the request. S1.4: Set a threshold for the size of request data packets for all requests. Requests exceeding the threshold will not be sent using long connections to avoid consuming network bandwidth on long connections. S1.5: For the highest priority request, when sending using a short connection, if the request fails, the long connection will be used immediately to retry the request. At the same time, when sending the highest priority request, a timer will be designed. If the request does not return a result within a preset time, the long connection will be used to send the request immediately. S1.6: All requests are stored in a queue, which is sorted according to priority and the time order of the request tasks. When there are no tasks in the queue, and no available free connection can be found in the connection pool for short connections, and the packet size is within the threshold, long connections are used for data transmission.
7. A method for acquiring travel service data in a mobile MaaS system according to claim 6, characterized in that: Based on the MaaS server, the entire range of the traveling user is obtained, and the fellow travelers are also obtained. The MaaS server then obtains the network of the fellow travelers and determines which fellow travelers' online classes are available and which are experiencing problems. The MaaS server selects users from the traveling users in the same distance based on the user's location information to assist the user experiencing problems by uploading the location data of the user experiencing problems and sending relevant data from the server to the device of the user experiencing problems.
8. The method for acquiring travel service data in a mobile MaaS system according to claim 1, characterized in that: The data between the MaaS client and the MaaS server is encrypted, specifically including: First, the MaaS server categorizes the potential peers for each stage. Each stage is a group of users, and the MaaS server first obtains the unique user identifier (uid) of these users. After obtaining these uids, the MaaS server calculates the corresponding allocation information; Then, on the MaaS server, a hash algorithm is used to uniquely encode the transportation node. A 1024-bit string is used for unique encoding, and a provincial code and a city code are added to the encoding to achieve uniqueness.
9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the mobile terminal MaaS system travel service data acquisition method described in any one of the preceding descriptions.
10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the mobile terminal MaaS system travel service data acquisition method according to any one of claims 1-8.