A ticket booking method, device and equipment for vulnerable users

Abstract

The embodiments of this specification disclose a ticket booking method, apparatus, and device for disadvantaged users. The method includes: identifying a disadvantaged user booking a ticket and the disadvantaged user's currently available tickets; identifying non-disadvantaged users in a set of users who have booked tickets corresponding to the disadvantaged user, whose booked location is better than the currently available tickets; sending a help request to the non-disadvantaged user, requesting the non-disadvantaged user to assist the disadvantaged user by using their booked location; and if the non-disadvantaged user accepts the help request, determining that the location booked by the disadvantaged user includes a location already booked by the non-disadvantaged user.

Description

Technical Field

[0001] This specification relates to the field of Internet technology, and in particular to a ticket booking method, device, and equipment for vulnerable users. Background Art

[0002] With the development of computers and the internet, people can now book various types of tickets online. For example, they can buy travel tickets such as train and plane tickets online through railway departments, airlines, or third-party applications, and they can buy entertainment tickets such as cultural performances and sports games online through the applications of various organizers.

[0003] Typically, online ticket booking apps assign seats to users based on how early they book their tickets. In some apps, users who book early are given a degree of seat selection privileges. For example, when booking a train ticket, users can choose between a window seat and an aisle seat.

[0004] As a result, online ticket booking relies primarily on users' quickness to select the location that best suits their needs, with no preferential policies in place to target vulnerable users. Furthermore, objective factors make booking more difficult for vulnerable users. For example, elderly people generally lack internet knowledge compared to young and middle-aged adults, and people with disabilities often face greater difficulty using smart terminals to book tickets.

[0005] Based on this, a ticket booking solution for vulnerable users is needed. Summary of the Invention

[0006] One or more embodiments of this specification provide a ticket booking method, apparatus, device, and storage medium for vulnerable users, to solve the following technical problem: a ticket booking solution for vulnerable users is needed.

[0007] To solve the above technical problems, one or more embodiments of this specification are implemented as follows:

[0008] One or more embodiments of this specification provide a ticket booking method for vulnerable users, including:

[0009] Identifying vulnerable users who are ordering tickets and the currently available tickets for said vulnerable users;

[0010] Determine, from the set of ticket-booked users corresponding to the disadvantaged user, a non-disadvantaged user whose ticket-booked location is better than the currently available ticket location;

[0011] sending a help request to the non-vulnerable user, requesting the non-vulnerable user to help the vulnerable user through the location of the non-vulnerable user's booked ticket;

[0012] If the non-vulnerable user accepts the request for assistance, it is determined that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket.

[0013] One or more embodiments of this specification provide a ticket booking device for vulnerable users, including:

[0014] an identification module for identifying vulnerable users who book tickets and currently available tickets for the vulnerable users;

[0015] a first position determination module, determining, from a set of ticket-booked users corresponding to the disadvantaged user, a non-disadvantaged user whose ticket-booked location is better than the currently available ticket location;

[0016] a help request module, sending a help request to the non-vulnerable user, requesting the non-vulnerable user to help the vulnerable user through the location of the non-vulnerable user's booked ticket;

[0017] The second location determining module determines, if the non-vulnerable user accepts the help request, that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket.

[0018] One or more embodiments of this specification provide a ticket booking device for vulnerable users, including:

[0019] at least one processor; and,

[0020] a memory communicatively connected to the at least one processor; wherein,

[0021] The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0022] Identifying vulnerable users who are ordering tickets and the currently available tickets for said vulnerable users;

[0023] Determine, from the set of ticket-booked users corresponding to the disadvantaged user, a non-disadvantaged user whose ticket-booked location is better than the currently available ticket location;

[0024] sending a help request to the non-vulnerable user, requesting the non-vulnerable user to help the vulnerable user through the location of the non-vulnerable user's booked ticket;

[0025] If the non-vulnerable user accepts the request for assistance, it is determined that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket.

[0026] One or more embodiments of this specification provide a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured to:

[0027] Identifying vulnerable users who are ordering tickets and the currently available tickets for said vulnerable users;

[0028] Determine, from the set of ticket-booked users corresponding to the disadvantaged user, a non-disadvantaged user whose ticket-booked location is better than the currently available ticket location;

[0029] sending a help request to the non-vulnerable user, requesting the non-vulnerable user to help the vulnerable user through the location of the non-vulnerable user's booked ticket;

[0030] If the non-vulnerable user accepts the request for assistance, it is determined that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket.

[0031] The at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects:

[0032] For disadvantaged users who struggle to find suitable seats during the booking process, the system identifies seats already booked by non-disadvantaged users who have better options. If the non-disadvantaged user agrees to use their pre-booked seats to help the disadvantaged user, this problem can be solved. Mutual support among users not only solves the problem of disadvantaged users struggling to get assistance during the booking process, but also promotes the traditional virtue of helping the disadvantaged and increases the willingness of non-disadvantaged users to help, providing a thoughtful ticket booking method for disadvantaged users. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0034] Figure 1 A flowchart of a ticket booking method for vulnerable users provided in one or more embodiments of this specification;

[0035] Figure 2 A schematic diagram of nearby locations in an application scenario provided for one or more embodiments of this specification;

[0036] Figure 3 A flowchart of a ticket booking method for elderly users in an application scenario provided in one or more embodiments of this specification;

[0037] Figure 4A schematic diagram of the structure of a ticket booking device for vulnerable users provided in one or more embodiments of this specification;

[0038] Figure 5 This is a schematic structural diagram of a ticket booking device for vulnerable users provided in one or more embodiments of this specification. DETAILED DESCRIPTION

[0039] The embodiments of this specification provide a ticket booking method, apparatus, device, and storage medium for vulnerable users.

[0040] In order to help those skilled in the art better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0041] Figure 1 This is a flowchart of a ticket booking method for vulnerable users, provided in one or more embodiments of this specification. This method can be applied to various business areas, such as online ticket booking, internet finance, e-commerce, instant messaging, gaming, and official business. The process can be executed by computing devices in the corresponding fields (e.g., intelligent customer service servers or smart mobile terminals for online ticket booking). Certain input parameters or intermediate results in the process can be manually adjusted to help improve accuracy.

[0042] Figure 1 The process in may include the following steps:

[0043] S102: Identify the vulnerable user who orders the ticket and the currently available tickets for the vulnerable user.

[0044] Vulnerable users have difficulties in performing certain actions due to their own objective reasons, and are therefore in a disadvantaged position during the use of tickets after booking. For example, users such as the elderly, disabled or pregnant women are in a disadvantaged position due to their physical conditions. Of course, for some types of tickets, the basis for judging vulnerable users is not limited to the user's physical condition. For example, if a user books a travel ticket such as a train ticket or a plane ticket and carries a large amount of luggage, it will also cause difficulty in traveling. In this case, even if the user is not physically vulnerable, he or she can still be considered a vulnerable user.

[0045] The currently available tickets for vulnerable users include the tickets for which the user can currently choose a seat among the remaining tickets, as well as the tickets for which the user has already chosen a seat. If there is a seat suitable for the vulnerable user among the currently available tickets, it can be allocated to them first. Based on this, the currently available tickets for vulnerable users, as well as the reserved tickets for non-vulnerable users mentioned below, all refer to tickets that can be allocated a seat in advance, such as airplane tickets, train tickets, concert tickets, etc. For bus tickets, subway tickets, etc., the user is not allocated a corresponding seat after booking the ticket. Special seats for the elderly, the weak, the sick, the disabled, and pregnant women can be set up to help vulnerable users, which will not be elaborated here.

[0046] S104: Determine, in the set of ticket-booked users corresponding to the disadvantaged user, non-disadvantaged users whose ticket-booked positions are better than the currently available ticket positions.

[0047] The set of booked users has corresponding determination methods for different types of vulnerable users and different types of ticketing. For example, for vulnerable users like the elderly (generally defined as those aged 60 and above, and this age can be adjusted based on actual circumstances), the corresponding user set can be selected from the group of young and middle-aged people (generally defined as those aged 18-40, and this age can also be adjusted based on actual circumstances). For vulnerable users like people with disabilities, the corresponding user set can be selected from the group of people without disabilities. If the current booking is for a travel ticket such as a train ticket, the corresponding set of booked users can include non-vulnerable users who have booked travel tickets with the same origin and destination. The available ticket location and the booked ticket location can be locations with the same flight and fare. However, in some cases (for example, if, after inquiry or based on the vulnerable user's user information, the user determines that the fare or flight corresponding to the booked ticket location is not required, or even that the user wishes to change the fare or flight), the available ticket location and the booked ticket location can also correspond to different fares or even different flights.

[0048] Similarly, when the current booking is for entertainment tickets such as concerts, the corresponding set of booked users may include users who have booked tickets for the same show, and may also include non-disadvantaged users who have booked tickets for other shows, for example, non-disadvantaged users who have booked tickets for other shows in a concert tour organized by the same artist.

[0049] A reserved seat is superior to an available seat, meaning that a reserved seat offers users higher benefits, greater convenience, and other advantages compared to an available seat. For example, if the ticket is a train sleeper, a lower berth is more convenient for getting in and out than an upper berth. If the ticket is a concert, a front seat is better than a back seat, and a seat facing the stage is better than a seat to the side.

[0050] S106: Sending a help request to the non-disadvantaged user, requesting the non-disadvantaged user to help the disadvantaged user through the location of the ticket he / she has booked.

[0051] The primary purpose and original intention of help requests is to help vulnerable users and enable mutual assistance among users. However, if this results in a reduced user experience for non-vulnerable user groups, it can easily lead to a loss.

[0052] Based on this, before sending a help request to a non-vulnerable user, an authorization query can be sent to each non-vulnerable user in advance. For example, the message content could be: When a vulnerable user books a ticket, are you willing to use your booking location to help them? Of course, since different types of ticketing correspond to different sets of non-vulnerable users, the message content can also be more closely tailored to the corresponding type. For example, if an elderly person cannot buy a train ticket with a suitable seat, are you willing to use your location to help the elderly person? If the non-vulnerable user responds with authorization, the server can send the help request to the non-vulnerable user.

[0053] Furthermore, a fatigue level is set for each non-vulnerable user who agrees to the authorization. Within a certain period of time or after each ticket booking, only a certain number of help requests will be accepted. For example, after each ticket booking, no more than three help requests will be accepted. After three help requests, no further help requests will be sent to the user, regardless of whether the user agrees or rejects. This way, even if the non-vulnerable user agrees to the authorization, help requests will not be sent to them indefinitely, ensuring a better user experience for non-vulnerable users.

[0054] For vulnerable users, a limit can also be set for the number of requests they can send. If the limit is reached and no non-vulnerable users accept the request, it's likely that the vulnerable user has other issues that are difficult to resolve with the help of non-vulnerable users alone. In this case, no more requests will be sent to other non-vulnerable users, thereby ensuring a better user experience for non-vulnerable users and preventing them from becoming fatigued by receiving such unacceptable requests. Of course, to ensure a better ticket booking experience for vulnerable users, other assistance options can be provided by contacting the ticketing company.

[0055] S108: If the non-vulnerable user accepts the help request, it is determined that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket.

[0056] Different methods of assistance can be tailored to different ticket types and vulnerable users. Non-vulnerable users can retain their existing bookings or be assigned new slots. These methods are explained in detail below. Non-vulnerable users typically sacrifice some degree of personal gain in helping vulnerable users. To address this, the non-vulnerable user who accepts the request for help can be rewarded or compensated to a certain degree. For example, this could include discounted fares, medals being awarded in public service apps, or additional time spent doing public service.

[0057] For disadvantaged users who struggle to find suitable seats during the booking process, the system identifies seats already booked by non-disadvantaged users who have better options. If the non-disadvantaged user agrees to use their pre-booked seats to help the disadvantaged user, this problem can be solved. Mutual support among users not only solves the problem of disadvantaged users struggling to get assistance during the booking process, but also promotes the traditional virtue of helping the disadvantaged and increases the willingness of non-disadvantaged users to help, providing a thoughtful ticket booking method for disadvantaged users.

[0058] based on Figure 1 This specification also provides some specific implementation plans and extension plans of the method, which will be described below.

[0059] In one or more embodiments of this specification, the reserved seat of a non-disadvantaged user can be used as the seat of a disadvantaged user. In this case, since the reserved seat of the non-disadvantaged user has been given to the disadvantaged user, the non-disadvantaged user has no seat left, and a corresponding seat needs to be allocated to the non-disadvantaged user.

[0060] If the vulnerable user's current available ticket positions include the position he / she has already occupied (for example, the vulnerable user has already booked a ticket and completed the payment, or has already reserved a position), then the position will be allocated to the non-vulnerable user as the position for which the non-vulnerable user has already booked a ticket. At this point, it is equivalent to exchanging positions between two people. If one of the parties has already issued a ticket, there is no need to exchange tickets to reduce the number of processes that need to be performed by both parties. If the vulnerable user does not currently occupy a position, other designated positions (for example, the position closest to the booked position for the non-vulnerable user in the remaining tickets) can be used as the position to be reassigned to the non-vulnerable user.

[0061] Furthermore, in the process of reallocating positions between vulnerable and non-vulnerable users, in order to further enhance the user experience of non-vulnerable users and increase their enthusiasm for accepting requests for assistance, non-vulnerable users can be screened before reallocating positions. If they meet the screening criteria, they can be reallocated with vulnerable users.

[0062] Figure 2 One or more embodiments of this specification provide a schematic diagram of nearby locations in an application scenario, using a common train seat ticket as an example. Among the users who have booked tickets near the location reassigned to the non-vulnerable user, at least some of the users are selected. For example, if the non-vulnerable user is reassigned location B2, priority is given to users who have booked tickets in seats A2 and C2 adjacent to that location. These locations are closest to each other and have the greatest impact on both parties. Of course, other nearby locations, such as B1, A1, C1, or even locations D1, D2, E1, and E2, which are farther away on the other side of the aisle, can also be selected based on actual circumstances. User features of the at least some of the users and the non-vulnerable users are collected separately. User features can be extracted by collecting corresponding user information based on different needs. By analyzing the user features of the at least some of the users and the non-vulnerable users (these two types of users can be pre-determined as non-traveling users based on factors such as the booking time and payment account, such as complete strangers who do not know each other), the affinity between the two is obtained. This affinity primarily reflects the likelihood of harmonious coexistence between the designated strangers. Generally speaking, a higher affinity indicates a greater likelihood of a positive experience for both users when they are in close proximity. When this affinity meets the preset conditions, it is assumed that the non-disadvantaged user and users near their reassigned location can maintain a positive experience. In this case, although the non-disadvantaged user has given up their more advantageous location for the disadvantaged user, the newly assigned location allows them to have a more positive experience with nearby users.

[0063] For example, user characteristics may include gender information. When using travel tickets, especially for long-distance travel, users may spend extended periods of time in their vehicles. In this situation, if the non-vulnerable user is female, especially traveling alone, they may become concerned about their safety. By analyzing gender information and finding that the user with a ticket near the newly assigned location is also female, this can increase their sense of security during their travels.

[0064] User characteristics can also include user preference characteristics. Using travel ticketing as an example, users inevitably find the journey boring. In this case, if other users with similar preferences can be assigned to the user's surrounding area, the non-disadvantaged user can have common topics to discuss, alleviating travel fatigue. In this case, historical payment information is first obtained based on the payment channels used by at least some users and non-disadvantaged users when booking tickets. This historical payment information is then analyzed to obtain corresponding preference characteristics. If two users share similar preferences (for example, if historical payment information indicates that both have purchased products endorsed by the same celebrity multiple times, indicating a strong interest in the celebrity, or if both have purchased badminton equipment, indicating a strong interest in badminton), it can be assumed that the two users are likely to have common topics to discuss during their travels, and the affinity between them meets the pre-set criteria.

[0065] In one or more embodiments of this specification, transferring a non-vulnerable user's booked ticket to a vulnerable user as described above can help the vulnerable user. However, doing so causes the non-vulnerable user to sacrifice a large amount of their own interests, which may reduce the probability that the non-vulnerable user will agree to the request for help.

[0066] Based on this, a different approach than the one above is adopted. Instead of allocating new locations to help vulnerable users, we use location sharing. This approach involves sharing the locations that non-vulnerable users have already booked with vulnerable users. In this case, the vulnerable user's booked locations also include the non-vulnerable user's already booked locations. Since the non-vulnerable user still has their booked location, the sacrifice is minimal, which increases the likelihood that they will agree to the request for assistance.

[0067] Specifically, a shared location means that the non-vulnerable user still owns the location, but the vulnerable user can also use it. Of course, since the location is a location that the non-vulnerable user has booked, the non-vulnerable user's use priority is higher than the vulnerable user's use priority during the sharing process. With the consent of both parties, the location can be shared or used by the vulnerable user. However, if the non-vulnerable user needs to use the location alone, the non-vulnerable user's use needs will be given priority.

[0068] For example, if a user books a sleeper berth on a train, and the non-disadvantaged user has already reserved a lower berth, while the vulnerable user's available tickets are all non-lower berths, the non-disadvantaged user can share the lower berth with the vulnerable user. With both parties agreeing, they can sit together in the lower berth, allowing the vulnerable user to rest without having to climb up.

[0069] Furthermore, while this approach can guarantee a user experience for non-vulnerable users, the level of assistance provided to vulnerable users is limited. Therefore, multiple non-vulnerable users are selected and each is assigned a specific helping period. Each non-vulnerable user's helping period is shorter than the entire ticket usage period, but these multiple helping periods can be combined to form the full ticket usage period. In this case, the helping periods of these multiple non-vulnerable users are simultaneously shared with the vulnerable user, allowing the vulnerable user to receive assistance from different non-vulnerable users at different times during the entire ticket usage period, thereby completing the full period of assistance.

[0070] Taking train sleeper tickets as an example, vulnerable users can share the lower berth with different non-vulnerable users at different time periods, so that they can get corresponding help throughout the entire process of using the sleeper ticket, and it will not cause too much impact on the user experience of other non-vulnerable users, thereby increasing the enthusiasm of non-vulnerable users to accept requests for help.

[0071] However, in some special time periods, it is difficult to replace different non-vulnerable users. For example, during the sleeping period, if the vulnerable user is allowed to sleep in the lower bunk in the first half of the night and the non-vulnerable user is allowed to sleep in the lower bunk in the second half of the night, this is obviously unrealistic and unreasonable. Based on this, corresponding mandatory continuous time periods are set in advance. During this mandatory continuous time period, the non-vulnerable user cannot be replaced. The location needs to be shared with the vulnerable user, or used by the vulnerable user alone. In this way, the vulnerable user can be guaranteed the right to use the shared location in some special time periods, ensuring their helped user experience.

[0072] Figure 3 Provided in one or more embodiments of this specification, a flowchart of a ticket booking method for elderly users in an application scenario. When an elderly user orders a train ticket and completes the payment, an attempt is made to allocate a suitable ticket to the elderly user (for example, a lower berth ticket for a train sleeper, a ticket near the toilet among the train seats). If the attempt is successful, the ticket booking process ends. If the attempt fails, a set of young and middle-aged users that meet the rules (for example, including the same train, the booked position is suitable for the elderly user, the user has been authorized to accept the seat change request, the young and middle-aged user has not reached fatigue, and the elderly user has not reached the inquiry limit) is determined, and then a seat change request is sent to the young and middle-aged user, and a corresponding interface is displayed on the young and middle-aged user's terminal, including buttons such as "Agree" and "Reject". If the young and middle-aged user does not provide feedback for a long time, the seat change request is considered expired and no longer processed. If the young and middle-aged user rejects the seat change request, the inquiry for the young and middle-aged user is terminated. When all eligible young and middle-aged users have rejected it, the ticket booking process ends and tickets for other positions are allocated to the elderly user. If the young or middle-aged user agrees to the seat change request, the seat change is completed and a notification is sent to both parties (for example, via push, text message, phone call, etc.).

[0073] In one or more embodiments of this specification, processes such as identification of vulnerable users and processing of assistance requests are usually performed by a server. The server can belong to the same system as the ticket generation end (for example, the railway department's ticket booking server), or the two can be relatively independent systems. When a user books a ticket through the server, the ticket booking process is implemented through data interaction between the server and the ticket generation end.

[0074] Based on the same idea, one or more embodiments of this specification also provide devices and apparatuses corresponding to the above methods, such as Figure 4 、 Figure 5 shown.

[0075] Figure 4 This is a schematic diagram of a ticket booking device for vulnerable users provided in one or more embodiments of this specification, the device comprising:

[0076] Identification module 402, identifying vulnerable users who book tickets and currently available tickets for the vulnerable users;

[0077] The first position determination module 404 determines, from the set of ticket-booked users corresponding to the disadvantaged user, non-disadvantaged users whose ticket-booked locations are better than the currently available ticket positions;

[0078] A help request module 406 sends a help request to the non-disadvantaged user to request the non-disadvantaged user to help the disadvantaged user through the location of the ticket booked by the non-disadvantaged user;

[0079] The second location determination module 408 determines that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket if the non-vulnerable user accepts the help request.

[0080] Optionally, the second location determining module 408 uses the location where the non-vulnerable user has booked a ticket as the location where the vulnerable user has booked a ticket;

[0081] If the vulnerable user has previously occupied a seat, then that seat will be used as the seat that the non-vulnerable user has booked;

[0082] Otherwise, another location is designated as the location for which the non-vulnerable user has booked a ticket.

[0083] Optionally, the second location determining module 408 shares the location where the non-vulnerable user has booked a ticket with the vulnerable user, so that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket.

[0084] Optionally, the second location determination module 408 determines the helping time periods respectively designated by the plurality of non-disadvantaged users who accept the helping request, and each helping time period is shorter than the entire usage period of the ticket;

[0085] A plurality of the helping time periods are spliced ​​together to form the full-time usage period;

[0086] In each helping period within the entire usage period, the location of the non-disadvantaged user who provided the helping period and has booked a ticket is shared with the disadvantaged user.

[0087] Optionally, it also includes:

[0088] A forced continuous period module 410 is configured to determine whether there is a set forced continuous period in the entire usage period, wherein the forced continuous period includes at least a portion of a sleep period;

[0089] If so, a single helping period that can include the mandatory continuous period is requested from the non-vulnerable user.

[0090] Optionally, it also includes:

[0091] The affinity prediction module 412 selects at least some users from among the users who have booked tickets near the occupied location if the disadvantaged user has previously occupied the location;

[0092] Otherwise, selecting at least some users from users who have booked tickets near other locations, where the other locations are used to designate locations where the non-disadvantaged users have booked tickets;

[0093] respectively collecting user characteristics of the at least some of the users and the non-vulnerable users;

[0094] According to the user characteristics, it is determined that the affinity between the at least some of the users and the non-disadvantaged users meets a preset condition.

[0095] Optionally, the user characteristics include gender information;

[0096] The affinity prediction module 412 determines, based on the gender information, that at least some of the users and the non-disadvantaged user are of the same gender.

[0097] Optionally, the affinity prediction module 412 obtains corresponding historical payment information through the payment channels used by the at least some of the users and the non-disadvantaged users when booking tickets;

[0098] Analyzing the historical payment information to obtain corresponding preference characteristics;

[0099] The affinity prediction module 412 determines, based on the preference characteristics, that the at least some of the users and the non-disadvantaged users have the same preferences.

[0100] Optionally, the identification module 402 identifies the user who currently books the train sleeper ticket as an elderly user among vulnerable users based on the user's age information;

[0101] Identifying that the current available voting position of the elderly user does not include a lower berth position;

[0102] The first location determination module 404 determines a user whose ticket is booked and whose position is in the lower berth in the set of young and middle-aged users corresponding to the elderly user.

[0103] Figure 5 A ticket booking device for vulnerable users provided in one or more embodiments of this specification includes:

[0104] at least one processor; and,

[0105] a memory communicatively connected to the at least one processor; wherein,

[0106] The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0107] Identifying vulnerable users who are ordering tickets and the currently available tickets for said vulnerable users;

[0108] Determine, from the set of ticket-booked users corresponding to the disadvantaged user, a non-disadvantaged user whose ticket-booked location is better than the currently available ticket location;

[0109] sending a help request to the non-vulnerable user, requesting the non-vulnerable user to help the vulnerable user through the location of the non-vulnerable user's booked ticket;

[0110] If the non-vulnerable user accepts the request for assistance, it is determined that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket.

[0111] Based on the same idea, one or more embodiments of this specification further provide a non-volatile computer storage medium corresponding to the above method, storing computer-executable instructions, wherein the computer-executable instructions are configured to:

[0112] Identifying vulnerable users who are ordering tickets and the currently available tickets for said vulnerable users;

[0113] Determine, from the set of ticket-booked users corresponding to the disadvantaged user, a non-disadvantaged user whose ticket-booked location is better than the currently available ticket location;

[0114] sending a help request to the non-vulnerable user, requesting the non-vulnerable user to help the vulnerable user through the location of the non-vulnerable user's booked ticket;

[0115] If the non-vulnerable user accepts the request for assistance, it is determined that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket.

[0116] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0117] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the means for implementing various functions included therein can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as both a software module implementing the method and a structure within the hardware component.

[0118] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0119] For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0120] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0121] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0122] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0123] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0124] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0125] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0126] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0127] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0128] This specification may be described in the general context of computer-executable instructions, such as program modules, executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media, including storage devices.

[0129] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the device, apparatus, and non-volatile computer storage medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simplified. For relevant details, refer to the descriptions of the method embodiments.

[0130] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0131] The foregoing description is merely one or more embodiments of this specification and is not intended to limit this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of one or more embodiments of this specification are intended to be within the scope of the claims of this specification.

Claims

1. A ticket booking method for vulnerable users, executed by a server, wherein the server and the ticket generating terminal belong to the same system, or the two are relatively independent systems, and the method comprises: Identifying vulnerable users who are ordering tickets and the currently available tickets for said vulnerable users; Determine, from the set of ticket-booked users corresponding to the disadvantaged user, a non-disadvantaged user whose ticket-booked location is better than the currently available ticket location; sending a help request to the non-vulnerable user, requesting the non-vulnerable user to help the vulnerable user through the location of the non-vulnerable user's booked ticket; If the non-vulnerable user accepts the help request, determining that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket, specifically comprising: using the location where the non-vulnerable user has booked a ticket as the location where the vulnerable user has booked a ticket; If the vulnerable user has previously occupied a seat, then that seat is used as the seat for which the non-vulnerable user has booked a ticket; otherwise, if the vulnerable user has not currently occupied a seat, another seat is designated as the seat for which the non-vulnerable user has booked a ticket; For non-vulnerable users, in the process of helping vulnerable users, they will sacrifice their own interests to a certain extent.

2. The method of claim 1, wherein determining the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket, specifically comprising: The location where the non-vulnerable user has booked a ticket is shared with the vulnerable user, so that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket.

3. The method according to claim 2, wherein the step of sharing the location of the non-vulnerable user's booked ticket with the vulnerable user comprises: Determining helping time periods respectively designated by a plurality of the non-disadvantaged users who accept the helping request, wherein each helping time period is shorter than the entire usage period of the ticket; A plurality of the helping time periods are spliced ​​together to form the full-time usage period; In each helping period within the entire usage period, the location of the non-disadvantaged user who provided the helping period and has booked a ticket is shared with the disadvantaged user.

4. The method according to claim 3, wherein before the plurality of assisting time periods are combined to form the full-time usage time period, the method further comprises: determining whether there is a set forced continuous period in the entire usage period, wherein the forced continuous period includes at least a portion of a sleep period; If so, a single helping period that can include the mandatory continuous period is requested from the non-vulnerable user.

5. The method of claim 1, wherein before using the location where the non-vulnerable user has booked a ticket as the location where the vulnerable user has booked a ticket, the method further comprises: If the vulnerable user has previously occupied a position, selecting at least some users from among the users who have booked tickets near the occupied position; Otherwise, selecting at least some users from users who have booked tickets near other locations, where the other locations are used to designate locations where the non-disadvantaged users have booked tickets; respectively collecting user characteristics of the at least some of the users and the non-vulnerable users; According to the user characteristics, it is determined that the affinity between the at least some of the users and the non-disadvantaged users meets a preset condition.

6. The method according to claim 5, wherein the user characteristics include gender information; The determining, based on the user characteristics, that the affinity between the at least some of the users and the non-disadvantaged user meets a preset condition specifically includes: According to the gender information, it is determined that the at least some of the users and the non-vulnerable user are of the same gender.

7. The method according to claim 5, wherein collecting user characteristics of at least some of the users and the non-vulnerable users separately comprises: Obtaining corresponding historical payment information through the payment channels used by at least some of the users and the non-vulnerable users when booking tickets; Analyzing the historical payment information to obtain corresponding preference characteristics; The determining, based on the user characteristics, that the affinity between the at least some of the users and the non-disadvantaged user meets a preset condition specifically includes: According to the preference characteristics, it is determined that the at least some of the users and the non-disadvantaged users have the same preferences.

8. The method according to claim 1, wherein the step of identifying the vulnerable user who is booking a ticket and the currently available tickets for the vulnerable user comprises: According to the age information of the user who currently books the train sleeper ticket, identifying the user as an elderly user among vulnerable users; Identifying that the current available voting position of the elderly user does not include a lower berth position; The step of determining, from the set of ticket-booked users corresponding to the disadvantaged user, a non-disadvantaged user whose ticket-booked location is better than the currently available ticket location, specifically includes: In the set of young and middle-aged users corresponding to the elderly user, a user whose ticket is booked in a lower berth is determined.

9. A ticket booking device for vulnerable users, applied to a server, the server and the ticket generating terminal belonging to the same system, or the two being relatively independent systems, comprising: an identification module for identifying vulnerable users who book tickets and currently available tickets for the vulnerable users; a first position determination module, determining, from a set of ticket-booked users corresponding to the disadvantaged user, a non-disadvantaged user whose ticket-booked location is better than the currently available ticket location; a help request module, sending a help request to the non-vulnerable user, requesting the non-vulnerable user to help the vulnerable user through the location of the non-vulnerable user's booked ticket; a second location determination module, if the non-vulnerable user accepts the help request, determining that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket, specifically comprising: using the location where the non-vulnerable user has booked a ticket as the location where the vulnerable user has booked a ticket; If the vulnerable user has previously occupied a seat, then that seat is used as the seat for which the non-vulnerable user has booked a ticket; otherwise, if the vulnerable user has not currently occupied a seat, another seat is designated as the seat for which the non-vulnerable user has booked a ticket; For non-vulnerable users, in the process of helping vulnerable users, they will sacrifice their own interests to a certain extent.

10. The apparatus according to claim 9, wherein the second location determining module shares the location where the non-vulnerable user has booked a ticket with the vulnerable user, so that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket.

11. The apparatus according to claim 10, wherein the second location determination module determines the helping time periods respectively designated by the plurality of non-disadvantaged users who accept the helping request, wherein each helping time period is shorter than the entire usage period of the ticket; A plurality of the helping time periods are spliced ​​together to form the full-time usage period; In each helping period within the entire usage period, the location of the non-disadvantaged user who provided the helping period and has booked a ticket is shared with the disadvantaged user.

12. The apparatus of claim 11, further comprising: A forced continuous period module is configured to determine whether there is a set forced continuous period in the entire usage period, wherein the forced continuous period includes at least a portion of the sleep period; If so, a single helping period that can include the mandatory continuous period is requested from the non-vulnerable user.

13. The apparatus of claim 9, further comprising: an affinity prediction module, if the disadvantaged user has previously occupied a position, selecting at least some users from among users who have booked tickets near the occupied position; Otherwise, selecting at least some users from users who have booked tickets near other locations, where the other locations are used to designate locations where the non-disadvantaged users have booked tickets; respectively collecting user characteristics of the at least some of the users and the non-vulnerable users; According to the user characteristics, it is determined that the affinity between the at least some of the users and the non-disadvantaged users meets a preset condition.

14. The apparatus according to claim 13, wherein the user characteristics include gender information; The affinity prediction module determines, based on the gender information, that the at least some of the users and the non-disadvantaged user are of the same gender.

15. The apparatus according to claim 13, wherein the affinity prediction module obtains corresponding historical payment information through the payment channels used by the at least some of the users and the non-disadvantaged users when booking tickets; Analyzing the historical payment information to obtain corresponding preference characteristics; The affinity prediction module determines, based on the preference characteristics, that the at least some of the users and the non-disadvantaged users have the same preferences.

16. The device according to claim 9, wherein the identification module identifies the user who currently books a train sleeper ticket as an elderly user among vulnerable users based on the user's age information; Identifying that the current available voting position of the elderly user does not include a lower berth position; The first position determination module determines a user whose ticket is booked and whose position is in the lower berth in the set of young and middle-aged users corresponding to the elderly user.

17. A ticket booking device for vulnerable users, applied to a server, the server and the ticket generating terminal belonging to the same system, or the two being relatively independent systems, comprising: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: Identifying vulnerable users who are ordering tickets and the currently available tickets for said vulnerable users; Determine, from the set of ticket-booked users corresponding to the disadvantaged user, a non-disadvantaged user whose ticket-booked location is better than the currently available ticket location; sending a help request to the non-vulnerable user, requesting the non-vulnerable user to help the vulnerable user through the location of the non-vulnerable user's booked ticket; If the non-vulnerable user accepts the request for assistance, determining that the location where the vulnerable user has booked a ticket includes the location where the non-vulnerable user has booked a ticket, specifically comprising: using the location where the non-vulnerable user has booked a ticket as the location where the vulnerable user has booked a ticket; if the vulnerable user has previously occupied a location, using that location as the location where the non-vulnerable user has booked a ticket; otherwise, if the vulnerable user has not currently occupied a location, designating another location as the location where the non-vulnerable user has booked a ticket; For non-vulnerable users, in the process of helping vulnerable users, they will sacrifice their own interests to a certain extent.

Images