Method and system for means-of-transport usage analysis

Abstract

The invention embodiment relates to methods and systems for analysing and evaluating the usage of means of transport. The disclosure describes creating a digital ticket for a user. The digital ticket comprises a unique signature, which is assigned to a provider which issues the digital ticket. The digital ticket is transferred to a mobile device of the user. A sensor, which is, for example, arranged in or on a means of transport, receives a signal from the mobile device when it is in the vicinity. The signal comprises the unique signature of the ticket. The sensor is assigned to a means of transport of the provider or of another provider and comprises a unique sensor identifier. After the sensor has received the signal, it transfers the unique signature of the sensor and the sensor identifier to a backend server, where said data on means-of-transport usage are analysed and evaluated.

Description

[0001] Method and system for transport usage analysis

[0002] BACKGROUND OF THE INVENTION

[0003] Public transport is an important backbone of daily commuter movements in most countries and contributes significantly to solving problems related to traffic congestion, air pollution, and energy efficiency. One aspect crucial for the effective operation of public transport relates to the ticketing system. Many countries offer various types of tickets, including single-journey tickets, weekly or monthly tickets, and also "country tickets" that allow cross-transit access to and use of all public transport services, or at least all public transport services of a certain type (e.g., regional trains, local public transport, etc.) in the country.

[0004] Such a country ticket represents a great convenience for users, as it consolidates ticket purchases for different modes of transport and transport companies, thus significantly improving users' mobility within a country. However, it also poses challenges regarding the fair distribution of revenue among the various transport companies.

[0005] For example, if a first transport company sells a regional ticket and a buyer uses that ticket primarily on buses or trains operated by a second transport company, an unequal distribution of costs and revenues arises. The first transport company receives the revenue from ticket sales, while the second transport company bears the passenger's transport costs. This can lead to financial imbalances between the transport companies and ultimately to inaccurate capacity utilization calculations and public transport investments.

[0006] Simple solutions for recording passenger movements already exist, such as manual ticket checking by staff or the use of scanners and turnstiles at train and bus stations. However, these solutions often involve significant costs and inconvenience. Furthermore, they often do not provide accurate and timely information on the usage patterns of regional tickets.

[0007] Another common method for capturing passenger movements is conducting surveys. However, these can be expensive, time-consuming, and often inaccurate because they rely on self-reported data and can often produce inaccurate results due to recall and response bias.

[0008] There is therefore a need for an improved system that provides accurate and timely information on ticket purchases and usage. Such a system should be able to provide statistical information about where and when tickets are purchased and used, while complying with data protection regulations. It should also be cost-effective and cause minimal inconvenience to users.

[0009] Another weakness of existing solutions is their inability to capture dynamic changes in users' travel habits. Seasonal variations, events, or infrastructure changes can cause significant shifts in public transport usage. Current passenger counting and data collection systems often cannot detect and respond to such sudden or gradual changes in real time. This can lead to inaccurate allocation of costs and revenues, thus impairing operational efficiency.

[0010] Furthermore, current solutions often cannot cover the full range of available modes of transport. Especially in urban areas, there are a variety of public transport options, including buses, trains, subways, trams, ferries, and even bike and scooter sharing services. However, many existing ticketing and tracking solutions are focused on only one or two modes of transport and therefore cannot provide complete and accurate information on passenger movements.

[0011] There is therefore a need for a comprehensive and flexible solution that enables accurate recording and allocation of regional ticket usage across all types of public transport. This system should be able to detect and account for both static and dynamic patterns in public transport usage to ensure accurate and fair distribution of costs and revenues. It should also be able to record and analyze regional ticket usage across different transport operators and regions to provide a comprehensive overview of mobility patterns within the country. SUMMARY OF THE INVENTION

[0012] The object is achieved according to the invention by methods according to claims 1 and 8 and systems according to claims 6 and 11. Embodiments and further developments are covered in the subclaims.

[0013] This patent application describes such a system that meets all these requirements while simultaneously observing user-friendliness and data protection regulations. By improving the accuracy and fairness of cost and revenue distribution between the various transport operators, this system contributes to improving the sustainability and efficiency of public transport, thus contributing to better mobility and quality of life in our cities and communities.

[0014] One embodiment of the invention relates to a method for analyzing and evaluating transport usage. This method comprises the step of creating a digital ticket for a user. The digital ticket comprises a unique signature assigned to a first provider that issues the digital ticket. Furthermore, according to this embodiment, a virtual service set identifier (SSID) entry is created that includes at least part of the digital signature. The digital ticket and the virtual SSID entry are transmitted to a user's mobile device. When the user is near a means of transport with a corresponding WLAN access point with the mobile device, the mobile device sends a WLAN probe request to the AP. The WLAN probe request includes the virtual SSID entry, and the AP has a unique AP identifier.The AP identifier and the virtual SSID entry are sent from the AP to a backend server, where this transport usage data is analyzed and evaluated.

[0015] An embodiment of the invention relates to a corresponding system that implements the above-mentioned method.

[0016] A further embodiment relates to a further method for analyzing and evaluating transport usage. This further method comprises creating a digital ticket for a user, wherein the digital ticket comprises a unique signature associated with a first provider that issues the digital ticket. The digital ticket is transmitted to a mobile device of the user. A sensor, which is arranged, for example, in or on a means of transport, receives a signal from the mobile device when it is nearby. The signal comprises the unique signature of the ticket. The sensor is associated with a means of transport of the provider or another provider and comprises a unique sensor identifier. After the sensor has received the signal, it transmits the sensor's unique signature and the sensor identifier to a backend server, where this transport usage data is analyzed and evaluated.

[0017] An embodiment of the invention relates to a corresponding further system which implements the above-mentioned further method.

[0018] SHORT DESCRIPTION OF THE CHARACTERS

[0019] Exemplary aspects of the invention are illustrated in the drawings. They show:

[0020] Figure 1 : a diagram showing an overview of the essential elements and the basic structure of the invention;

[0021] Figure 2: an exemplary flow chart for a method for

[0022] Implementing a sensor-based analysis method;

[0023] Figure 3: an exemplary flow chart for a method for

[0024] Implementing a WLAN analysis procedure; and

[0025] Figure 4: an exemplary flow chart for a method for

[0026] Implementing a beacon-based analytics approach.

[0027] DETAILED DESCRIPTION

[0028] Figure 1 is a diagram providing an overview of the essential elements and basic structure of the invention. As can be seen in the figure, the invention is based on a plurality of different zones. These zones are the first zone 102, the second zone 112, and the third zone 122. As indicated in Figure 1, there may be significantly more than just three zones. However, only two zones, or in certain embodiments, only one zone, may be considered.

[0029] Zones 102, 112, and 122 represent various transport associations or transport companies in which a ticket, such as the regional ticket described above, can be used. For example, zone 102 could describe the catchment area and area of ​​responsibility of the Hamburg Transport Association (HW), zone 112 could describe the catchment area and area of ​​responsibility of the Berlin Transport Company (BVG), and zone 122 could describe the catchment area and area of ​​responsibility of the Munich Transport Company (MVG). However, this assignment is only an example. The zones can also describe areas within a transport company, for example, one zone describes all means of transport in the city center, another zone describes the means of transport on the outskirts of the city, etc.A zonal division according to mode of transport is also conceivable, for example Zone 102 describes all buses, Zone 112 describes trains, Zone 122 describes car, bike, and scooter sharing, etc.

[0030] As shown in Figure 1, each zone 102, 112, and 122 is assigned a corresponding ticket server 104, 114, or 124. Users who wish to purchase a digital ticket connect their mobile device 106, for example, via the internet / mobile network, to a corresponding ticket server 104, 114, or 124, thereby initiating the purchase process for a digital ticket. In the following, the term "ticket" is used synonymously with the term "ticket." However, both terms mean the same thing.

[0031] Digital tickets are known in the art. Digital tickets, such as those used in the invention, are stored on a user's mobile device 106 and can be read and verified for authenticity and validity in various ways.

[0032] For example, such tickets may contain a QR code, a barcode, or an NFC tag that can be read by special readers or mobile device cameras. In some cases, these tickets can also be sent to an inspection device via a Bluetooth, Wi-Fi, or other data connection. These methods enable quick and reliable ticket verification without the need for a physical card.

[0033] Various techniques can be used to verify the authenticity and validity of tickets. For example, tickets can be provided with digital signatures signed with the transport companies' private keys. The control devices can then verify these signatures with the transport companies' public keys. Furthermore, the tickets can contain validity information, such as the date of issue, the period of validity, or special terms of use, which can also be verified. However, the embodiments of the present invention are not limited to a specific form of digital ticket and the verification of authenticity and validity.

[0034] The respective ticket servers 104, 114, 124 of the different zones 102, 112, 122 do not each have to be independent ticket servers, but ticket sales can, for example, also be managed by a single server, such as the backend server. In the present invention, the digital tickets can be extended so that they have a unique signature. The unique signature of a digital ticket can contain additional information, such as the place of sale of the ticket, the issuing (transport) company, a time and / or a period of validity, etc. This information can be contained in the form of a digital code or tag that is attached to the ticket when it is sold. This unique signature can be read out and used to make a statistical statement about where the tickets are sold and subsequently used, as described in more detail below.

[0035] According to some embodiments, the unique signature may be a BLE ID (“Bluetooth Low Energy ID”) that is associated with the ticket.

[0036] As can be seen further in Figure 1, corresponding means of transport 107, 117, and 127 can be seen in the individual zones 102, 112, 122. In the example illustration in Figure 1, a bus is schematically depicted as a means of transport, but it is understood that other means of transport are also included, such as rail vehicles, ferries, car, bike, scooter sharing, etc. Furthermore, more than one means of transport can usually be found in the respective zones 102, 112, 122, even if only one means of transport 107, 117, 127 is shown as an example.

[0037] According to embodiments of the invention, the means of transport each contain a sensor 108, 118, 128 used for the invention. Elements 108, 118, and 128 are generally referred to herein as "sensors," but may take a variety of forms and, in individual embodiments, may even have more functions than a conventional sensor. In some embodiments, as described further below, the sensor itself does not need to have any sensor properties, but merely outputs a signal to trigger other available sensors (e.g., as part of mobile device 106) to perform a sensor operation.

[0038] According to some embodiments, the sensors 108, 118, 128 are mounted directly in or on the corresponding means of transport 107, 117, 127. However, according to alternative embodiments, it is not necessary for the sensors 108, 118, 128 to be mounted directly on the means of transport 107, 117, 127, but can also be mounted at other fixed locations, such as stops within the ticket's validity area. Examples include train stations, bus stops, transfer points, etc.

[0039] Possible examples of sensors include Bluetooth sensors that receive, possibly process, and forward a Bluetooth signal from a mobile device 106. Other sensors may also be used, such as Wi-Fi, NFC, etc., as described below.

[0040] According to embodiments of the invention, the sensors described above are installed in the means of transport 107, 117, 127, which register when a mobile device 106 that has stored a ticket / travel pass is nearby. According to some embodiments, a corresponding application (app) can be installed on the mobile device 106, which is active at least in the background. However, there are also embodiments that function without the active cooperation of a special app, as described in more detail below. As mentioned above, the ticket includes a unique signature (for example in the form of an assigned BLE ID), which is also referred to below as the "ticket ID." The ticket ID clearly indicates which transport association the ticket was purchased through. In some embodiments, the ticket ID includes an additional identifier that is identical for each transport association.As a simplified example (and by no means intended as a limitation), this could look like this: tickets from receive the signature "TB0001." Tickets from Bielefeld would receive the signature "TB0002," Munich would receive "TM0001," and so on.

[0041] According to embodiments, the sensor 108, 118, 128 can transmit a beacon at any time, which is received by the mobile device 106. For example, the beacon can be a BLE beacon (BLE = "Bluetooth Low Energy"). In some embodiments, the beacon can transmit a corresponding identifier as part of the beacon, which provides information about the mode of transport, the zone, the time, and / or the location. In some embodiments, this information is stored in the sensor but is not part of the beacon.

[0042] The mobile device 106 can register the sensor 108, 118, 128 via the beacon and, if necessary, receive at least one of these beacon pieces of information from the sensor, such as a transport association ID that is uniquely assigned to the corresponding transport company. For example: Berlin = VB0001; Bielefeld = VB0002; Munich = VM0001, etc. As described above, the mobile device 106 can also receive additional data from the sensor, such as a timestamp and the exact vehicle in the transport association.

[0043] The mobile device 106 can then send its ticket ID (i.e., the unique signature of the digital ticket) to the sensor 108, 118, 128. It is also conceivable that a copy of the entire digital ticket is sent to the sensor, but in most cases, the ticket ID is sufficient. The sensor 108, 118, 128 receives the data (i.e., the ticket ID) from the mobile device and forwards this data, along with the sensor data (e.g., transport association ID, mode of transport, zone, time, and / or precise location), to a backend server 140. The backend server 140 can use this received data to analyze and evaluate the mode of transport usage.

[0044] As described in more detail below, the mobile device 106 can send the ticket ID or ticket in various ways. One example possibility is for the mobile device 106 to send the data regularly or continuously using the "Exposure Notification Framework." Another possibility is for the mobile device 106 to send this information automatically as soon as the public transport app or an app in which the ticket is stored / managed on the mobile device 106 is open or at least active in the background.

[0045] According to further embodiments, however, the mobile device 106 does not have to send any data to the sensor, but merely receives the sensor data from the beacon and sends this data together with the ticket ID itself to the backend server 140.

[0046] In the above example, the backend server 140 can then register that a user with a ticket purchased in Hamburg (zone 102) uses a Munich public transport system 127 in zone 122. Based on this data, statistical surveys are conducted on the backend server 140 from a large number of users.

[0047] In embodiments where the mobile device 106 sends the data directly to the backend server 140 after receiving the beacon, the beacon can also be an ultrasonic tone, which is emitted, for example, by the loudspeakers of the means of transport 107, 117, 127 and can be recognized by the mobile device 106. These ultrasonic tones are inaudible to the human ear, but could still provide information about the use of the vehicle. The ultrasonic tone can, for example, transmit the transport association ID at regular intervals via modulation of the tone, which is recognized by the mobile device 106 and, as described above, sent from the mobile device 106 to the backend server 140 together with the ticket ID.

[0048] This design would minimize retrofitting costs, as no additional sensors would be required. The ultrasonic tones can also be emitted at the appropriate stops, as described above.

[0049] In alternative embodiments, the app on the mobile device 106 through which the ticket is purchased can access location data of the mobile device 106 (GPS, cell tower triangulation, known Wi-Fi networks in the area, etc.). This allows users' movements to be tracked and determine which transit services they use. In an extension of this tracking method, instead of tracking a user's exact location, the app can only be active when the user enters a predefined geographical area (e.g., a bus stop or train station). This method would still present some of the privacy concerns of full location tracking, but would be less invasive.

[0050] In yet another alternative embodiment, transportation usage analysis can be performed using the Exposure Notification Framework developed by Apple and Google. Bluetooth Low Energy (BLE) is used for decentralized contact sensing. Mobile device 106 can typically transmit randomly generated IDs via Bluetooth using the Exposure Notification Framework. When two devices are in proximity, they exchange their IDs and store this information locally.

[0051] In one embodiment, this technology can be modified as follows. Each mode of transportation can be configured to broadcast its own unique ID via an additional device to be installed. The app on the user's mobile device 106 can then capture this ID when the user enters the vehicle and send this information, along with the ticket ID, to the backend server 140 to track which modes of transportation are being used.

[0052] Additionally or alternatively, the mobile device 106 may transmit the ticket ID (instead of a randomly generated ID) via the Exposure Notification Framework, which is received and forwarded / processed by the corresponding sensor in the vehicle.

[0053] Another embodiment describes a concept that can read the data from the mobile device 106 even in cases where no corresponding app is installed or active on the mobile device 106. As in the exemplary embodiments listed above, this embodiment begins with the creation and transmission of a digital ticket to the mobile device. The digital ticket, as described above, is provided with a unique signature. This signature is associated with an issuing transport company. This signature can, for example, comprise a character string or a numeric code that is linked in a specific way to the transport company's information.

[0054] According to this embodiment, a virtual Service Set Identifier (SSID) entry is created along with the digital ticket. In WLAN technology, SSID refers to a unique name assigned to a specific wireless local area network. In most cases, the SSID is a human-readable string that can consist of up to 32 characters. It serves to distinguish different networks from one another and is visible to users when scanning for available networks.

[0055] Typically, a network's SSID is set by the network administrator. However, it can also be generated automatically by certain network components, such as wireless access points (APs) or routers. The SSID is one of the most important pieces of information a device needs to connect to a wireless network.

[0056] In addition to the actual SSID, which primarily consists of the network name, a Wi-Fi network typically also contains other information used in conjunction with the SSID. This includes the network's security settings (such as WPA2 or WPA3), the network key (also called the password), and in some cases, additional data such as the network channel and frequency band.

[0057] The SSID entry according to the invention can be generated such that it includes (for example, as part of its character string) at least part of the digital signature. To create the virtual SSID entry, only part of this digital signature can be taken and converted into a specific format suitable for use as an SSID. This could be done, for example, by applying a specific coding or encryption to the part of the digital signature, or by using a specific algorithm that converts the signature into an SSID entry.

[0058] The digital ticket and the SSID entry can then be transmitted to the user's mobile device 106. The virtual SSID can be implemented in the mobile device 106 in several ways. One possibility would be to integrate the SSID into a mobile application used to manage the digital tickets. The application can be programmed to recognize the SSID and integrate it into the mobile device's operating system so that the device can or wants to use the SSID to connect to the WLAN access points (APs) of the means of transport 107, 117, 127. Another possible implementation would be to use a service or API of the operating system of the mobile device 106 that allows the creation and management of SSID entries. This can be done, for example, via a special "SSID management" function of the operating system that is called by the mobile application.

[0059] While using the means of transport, the mobile device 106 can send the WLAN probe request (e.g., in response to a beacon) to the WLAN access point assigned to the means of transport. This probe request contains, among other things, the virtual SSI D entry. In other words, the mobile device 106 receives a WLAN beacon from a WLAN AP and initiates a query as to whether it can or should connect to the AP's WLAN. As part of this process, the mobile device 106 sends a list of WLAN networks already known to it in the form of SSIDs to the AP. The virtual SSI D entry, which was created by the ticket server 104 and contains the ticket IP, is then also located under the list of SSIDs.

[0060] In some embodiments, the WLAN AP can detect all virtual SSID entries from a received SSID list and store only those SSID entries created as part of the process described above, discarding the other SSID entries that belong to actual WLAN networks. In a case where multiple virtual SSID entries are received from a mobile device 106, the WLAN AP can retain only those SSID entries that have a valid timestamp, and expired ticket IDs are deleted.

[0061] In alternative embodiments, the mobile device can also be configured to automatically delete expired ticket IDs or expired SSID entries from the SSID list so that they are no longer transmitted to the WLAN AP.

[0062] The WLAN AP can have a unique AP identifier. The unique AP identifier and the SSI D entry are transmitted from the AP to the backend server 140.

[0063] By knowing both the location of ticket sales (through the digital signature on the ticket) and the location of use (e.g., through the AP and its identifier), the system can provide a detailed overview of user behavior. This enables a fairer distribution of revenue and costs between the various transport operators.

[0064] Figure 2 shows an exemplary flowchart for a method for implementing a sensor-based analysis method. The details described above apply to the process in Figure 2. The flowchart includes the ticket server 104, the mobile device 106, a sensor 108, and the backend server 140. The flowchart describes a time axis running from top to bottom, shows the flow of various data between the individual units in the form of arrows, and shows the respective processing steps of the units in boxes along the vertical time axes.

[0065] The method described in Figure 2 begins with step S1, in which a request is sent from the mobile device 106 to the ticket server 104. The request can be a ticket request for purchasing a ticket. This step can include further substeps, which, for example, include payment details and, if applicable, further personal data such as address, date of birth, etc., which, however, will not be described further here.

[0066] In step S2, the ticket server 104 creates the digital ticket according to the details of the ticket request from step S1. As already described, the ticket has a unique signature, which will be referred to below as the ticket ID. As already mentioned, the ticket ID or the unique signature can be a BLE ID assigned to the ticket. Together with the ticket ID, the created ticket is transmitted to the mobile device 106 in step S3. As an optional step S4, the ticket ID and, if applicable, information concerning the ticket server 104 can be transmitted to the backend server 140.

[0067] After the mobile device 106 has received the digital ticket, the user of the mobile device 106 is authorized to use the contracted (ride) services. In step S5, the mobile device 106 approaches a sensor 108 and can receive a beacon emitted by the sensor 108. Alternatively, the beacon is not emitted by the sensor 108 itself, but by a beacon transmitter 208. The beacon can include the data, as already described herein, or can simply be a beacon for triggering further actions in the mobile device. It should be noted that this step can be optional, and the mobile device 106 can also regularly emit the corresponding information on its own, as already described, e.g., within the framework of the Exposure Notification Framework or via the app installed on the mobile device 106.

[0068] After the mobile device 106 receives the beacon, it sends the ticket ID, i.e., the unique signature of the purchased ticket, to the sensor 108 in response. The sensor 108 can then, in step S7, send the ticket ID together with a sensor ID and possibly further data, such as a time stamp, location, etc., to the backend server 140 for further evaluation.

[0069] Finally, a corresponding analysis of the passenger behavior can be carried out on the backend server 140 in step S8.

[0070] Figure 3 shows an exemplary flowchart for a method for implementing a WLAN-based analysis method. The details already described above apply to the process in Figure 3. The flowchart includes the ticket server 104, the mobile device 106, a WLAN access point 308, and the backend server 140. Similar to Figure 2, the flowchart in Figure 3 describes a time axis running from top to bottom, shows the flow of various data between the individual units in the form of arrows, and shows the respective processing steps of the units in boxes along the vertical time axes.

[0071] The method described in Figure 3 begins with step S31, in which a request is sent from the mobile device 106 to the ticket server 104. The request can be a ticket request for purchasing a ticket. This step can include further substeps, which, for example, include payment details and, if applicable, additional personal data such as address, date of birth, etc., which, however, will not be described further here.

[0072] In step S32, the ticket server 104 creates the digital ticket according to the details of the ticket request from step S31. Additionally, in step S33, the ticket server 104 creates a virtual SSID entry. As described in detail above, the virtual SSID entry includes at least part of the ticket ID, for example, as part of its character string. This SSID entry is sent along with the ticket to the mobile device 106 in step S34, completing the purchase process.

[0073] After the mobile device 106 receives the ticket and the SSID entry with the ticket ID in step S34, the mobile device implements the SSID entry in step S35. Not shown in Figure 3, but also part of the process, is the storage of the ticket on the mobile device 106. In an optional further step S36, the ticket server 104 sends the ticket ID and / or the virtual SSID entry to the backend server 140. This step is not absolutely necessary, however, since the backend server 140 can recognize the ticket issuer by assigning a characteristic signature as part of the ticket ID even without the exact ticket ID.

[0074] If the mobile device 106 is located near a means of transport 107, 117, 127, or near the WLAN AP 308, it can receive a WLAN beacon from the WLAN AP 308 in step S37. This WLAN beacon is typically a simple beacon that is emitted by WLAN APs to draw attention to themselves and to indicate to other WLAN devices that a possible WLAN connection is available.

[0075] In response to receiving the beacon, the mobile device 106 sends a so-called WLAN probe request to the WLAN AP 308 in step S38. This WLAN probe request includes a (SSID) list of known WLAN networks to which the mobile device 106 has connected in the past and includes the virtual SSID entry containing the ticket ID or at least part of the ticket ID. The WLAN AP 308 recognizes this virtual SSID entry and forwards it, along with further information regarding the means of transport used, to the backend server 140 in step S39. In some embodiments, the WLAN AP can recognize all virtual SSID entries from a received SSID list and store only those SSID entries created as part of the process described above, discarding the other SSID entries that belong to actual WLAN networks.In a case where multiple virtual SSID entries are received from a mobile device 106, the WLAN AP can only retain those SSID entries that have a valid timestamp and expired ticket IDs are deleted.

[0076] In alternative embodiments, the mobile device can also be configured to automatically delete expired ticket IDs or expired SSID entries from the SSID list so that they are no longer transmitted to the WLAN AP.

[0077] Finally, a corresponding analysis of the passenger behavior can be carried out on the backend server 140 in step S310.

[0078] Figure 4 shows an exemplary flowchart for a method for implementing a beacon-based analysis method. The details already described above apply to the flow of Figure 4. The flowchart includes the ticket server 104, the mobile device 106, a beacon transmitter 408, and the backend server 140. Similar to Figures 2 or 3, the flowchart in Figure 4 describes a time axis running from top to bottom, shows the flow of various data between the individual units in the form of arrows, and shows the respective processing steps of the units in boxes along the vertical time axes.

[0079] The method described in Figure 4 begins with step S41, in which a request is sent from the mobile device 106 to the ticket server 104. The request can be a ticket request for purchasing a ticket. This step can include further substeps, which, for example, include payment details and, if applicable, further personal data such as address, date of birth, etc., which, however, will not be described further here.

[0080] In step S42, the ticket server 104 creates the digital ticket according to the details of the ticket request from step S41. As already described, the ticket has a unique signature, which will be referred to below as the ticket ID. The created ticket is transmitted together with the ticket ID to the mobile device 106 in step S43. As an optional step S44, the ticket ID and, if applicable, information concerning the ticket server 104 can be transmitted to the backend server 140. After the mobile device 106 has received the digital ticket, the user of the mobile device 106 is authorized to use the contracted (transport) services. In step S45, the mobile device 106 approaches a beacon transmitter 408 and receives a beacon transmitted by the beacon transmitter 408. Alternatively, the beacon is not transmitted by the sensor 108 itself, but by a beacon transmitter 208.In one embodiment, the beacon is a BLE beacon that is sent to the mobile device via Bluetooth. In an alternative embodiment, the beacon is an ultrasonic tone, and the beacon transmitter 408 can be a simple loudspeaker that transmits the ultrasonic beacon at regular intervals, as described above. The beacon signal of the embodiments according to Figure 4 includes a unique beacon ID that identifies at least the traffic operation or zone (see Figure 1).

[0081] After the mobile device 106 receives the beacon, it responsively sends the ticket ID, i.e., the unique signature of the acquired ticket, and the received beacon ID to the backend server 140 in step S46.

[0082] The mobile device 106 may optionally send additional data, such as timestamp, location, etc., to the backend server 140 for further evaluation.

[0083] Finally, a corresponding analysis of the passenger behavior can be carried out on the backend server 140 in step S47.

[0084] The essential difference between the embodiments according to Figure 4 and the embodiments according to Figure 2 concerns the unit that ultimately sends the data to the backend server 140.

[0085] Embodiments of the invention may be implemented on a variety of different hardware platforms, including, but not limited to, computers, mobile devices, laptops, microcontrollers, and server systems. The hardware used to perform the methods and processes described herein may be configured and implemented in various ways, depending on specific requirements and constraints.

[0086] The backend server 112 and ticket server 114 used in this invention may be a single server or a distributed server comprising multiple networked servers or computers. The server may be equipped with standard processors found in commercially available computers or may utilize specially configured processors optimized for specific functions. The server may also utilize a variety of storage media, including, but not limited to, hard disks, solid-state drives (SSDs), and network storage devices. It may utilize various operating systems such as Windows, Linux, UNIX, or specific server operating systems. Furthermore, the server may access other systems and data through various network connections, including LAN, WAN, or cloud-based connections.

[0087] The server hardware can be housed in a standard or custom-built server chassis and operated in a local or cloud-based data center. It can include high-availability and redundancy features to ensure service continuity.

[0088] The mobile devices used in this invention can be smartphones, tablets, wearables, portable computers, or other portable devices connected to the Internet via a wireless connection, such as cellular, Wi-Fi, or Bluetooth. Various operating systems can be used, such as Android, iOS, Windows, or other mobile operating systems.

[0089] Mobile devices may be equipped with a variety of hardware components, including, but not limited to, one or more processors, storage devices (such as RAM and flash memory), sensors (such as GPS, accelerometer, gyroscope, Bluetooth), a camera, a touchscreen, and various communication interfaces.

[0090] The mobile hardware may also include specific features to enhance security and privacy, such as cryptographic chips, secure elements, fingerprint sensors, or facial recognition systems. It may also include specific features to enhance user experience, such as haptic feedback, speech recognition, or augmented reality capabilities.

[0091] The data communication between the devices, servers and devices involved, including the mobile device, can be based on different technologies and use different communication protocols.

[0092] Data communication can occur over a wireless network, such as Wi-Fi, cellular (GSM, Edge, 3G, LTE, 4G, 5G, etc.), Bluetooth, or similar. Communication can also occur over a wired network, such as Ethernet, DSL, or similar. In either case, communication can involve a direct connection between devices or an indirect connection via one or more network nodes. Data communication can use various communication protocols, including, but not limited to, TCP / IP, HTTP, HTTPS, FTP, SMTP, MQTT, and others. It can also use various data exchange formats, such as XML, JSON, CSV, or similar. Data communication can include various security mechanisms to ensure the integrity and confidentiality of the data. This can include the use of encryption techniques, such as SSL / TLS, IPsec, or similar.It may also include the use of authentication and authorization mechanisms, such as passwords, digital certificates, tokens, or similar. Data communication may also include various error handling mechanisms to ensure the robustness and reliability of the communication. This may include the use of retry mechanisms, timeout settings, confirmation messages, and the like.

[0093] The exact configuration and implementation of data communication may vary depending on the specific requirements and constraints of the application and is not limited to the examples above.

Claims

CLAIMS 1 . Method for analyzing and evaluating transport usage, comprising: Creating a digital ticket for a user, the digital ticket comprising a unique signature associated with a first provider, the digital ticket being created by the first provider; Creating a virtual Service Set Identifier (SSID) entry that includes at least part of the digital signature; Transferring the digital ticket and the virtual SSID entry to a user’s mobile device; Receiving, at a WLAN access point (AP), a WLAN probe request from the mobile device, wherein: the WLAN probe request comprises the virtual SSID entry, and the AP is associated with a means of transport of the first provider or a second provider and comprises a unique AP identifier, Transmitting the AP identifier and the virtual SSID entry from the AP to a backend server; and Evaluating transport usage using the data transmitted to the backend server.

2. The method of claim 1, wherein the virtual SSID entry further comprises a timestamp and information about the validity period of the ticket.

3. Method according to claim 1 or 2, wherein the AP is arranged in a means of transport or a stopping point within the validity area of the ticket.

4. Method according to one of claims 1 to 3, wherein the evaluation of the means of transport usage results in a statistical evaluation of the use of digital tickets in one or more transport associations.

5. The method according to any one of claims 1 to 4, wherein the mobile device outputs the virtual SSID entry based only on predetermined location information.

6. A system for analyzing and evaluating transport usage, the system comprising: a mobile device; a backend server with a computing unit, the computing unit being configured to evaluate transport usage using received data; a ticket server configured to: Creating a digital ticket for a user, wherein the digital ticket includes a unique signature associated with a first provider, Creating a virtual Service Set Identifier (SSID) entry that includes at least part of the digital signature, and Transmitting the digital ticket and the virtual SSID entry to the user’s mobile device, a Wi-Fi access point (AP) configured to: Receiving a WLAN probe request from the mobile device, and Transmitting the AP identifier and the virtual SSID entry from the AP to the backend server, wherein the WLAN probe request includes the virtual SSID entry, and the AP is associated with a transport provider and includes a unique AP identifier.

7. The system of claim 6, wherein the virtual SSID entry further comprises a timestamp and information about the validity period of the ticket.

8. Methods for analyzing and evaluating transport usage, comprising: Creating a digital ticket for a user, the digital ticket comprising a unique signature associated with a first provider, the digital ticket being created by the first provider; Transferring the digital ticket to the user’s mobile device; Receiving, at a sensor, a signal from the mobile device, wherein: the signal comprises the unique signature of the ticket, and the sensor is associated with a means of transport of the first provider or a second provider and comprises a unique sensor identifier, Transferring the sensor’s unique signature and sensor identifier to a backend server; and Evaluate transport usage using the data received on the backend server.

9. The method of claim 8, wherein the mobile phone transmits the unique signature of the digital ticket in response to a trigger.

10. The method according to claim 8 or 9, wherein the trigger is at least one of an acoustic trigger in the ultrasonic range and a Bluetooth Low Energy (BLE) beacon, and wherein the trigger is arranged in a means of transport or a stopping point within the validity area of the ticket.

11. Method according to one of claims 8 to 10, wherein the unique signature is a BLE ID and wherein the BLE ID is permanently sent via an Exposure Notification Framework and / or wherein the BLE ID is sent when an application is active on the mobile device via which the ticket is managed.

12. A system for analyzing and evaluating transport usage, the system comprising: a mobile device; a backend server with a computing unit, the computing unit being configured to evaluate transport usage using received data; a ticket server configured to: Creating a digital ticket for a user, the digital ticket comprising a unique signature associated with a first provider, and Transferring the digital ticket to the user’s mobile device, and a sensor associated with a means of transport of the first provider or a second provider and comprising a unique sensor identifier, the sensor being configured to: Receiving a signal from the mobile device, and Transferring the unique signature of the digital ticket and the sensor identifier to the backend server.

Images