CN110472803B

CN110472803B - Vehicle riding code issuing authority configuration method, device and server

Info

Publication number: CN110472803B
Application number: CN201810438991.XA
Authority: CN
Inventors: 吴文勤
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2018-05-09
Filing date: 2018-05-09
Publication date: 2023-07-18
Anticipated expiration: 2038-05-09
Also published as: CN110472803A

Abstract

The disclosure provides a vehicle riding code issuing authority configuration method, a device and a server. The method comprises the following steps: acquiring user attribute data and historical payment data of a user riding a vehicle; acquiring user risk data based on the user attribute data and the historical payment data; and configuring the vehicle riding code issuing authority based on the user risk data. The embodiment of the disclosure improves the safety of the vehicle riding code distribution.

Description

Vehicle riding code issuing authority configuration method, device and server

Technical Field

The present disclosure relates to the field of computers, and in particular, to a vehicle riding code issuing authority configuration method, device, server and computer program medium.

Background

Riding codes are put into operation in the traffic field at present. Compared with the traditional bus card swiping and taking subway, bus and other transportation means, the bus code technology does not need a physical bus card. The user only needs to use the mobile phone to request a two-dimension code on line as a riding code before riding the vehicle, and swipes the two-dimension code on the mobile phone like a bus card and pays for the fee when riding the vehicle, so that the effect of freely riding the vehicle like the bus card is achieved, and the trouble of carrying the bus card and the like is avoided.

However, since the wireless network environment in a subway or the like is not good, the ride is not always requested when the online request of the ride is required in the subway or the like. Thus, an off-line ride code issuing technique has emerged. The user requests to issue an offline certificate to the mobile phone of the user in advance in a place with good network environment. When the user needs to take a vehicle such as a subway and the like and the network signal is not good at the moment, the offline certificate in the mobile phone temporarily issues a riding code for the user, and the server is reported again when the network environment where the mobile phone of the user is positioned is good, so that payment is completed. Or the user requests to issue a plurality of offline riding codes to be pre-stored in the mobile phone in a place with good network environment in advance. When the user needs to take the vehicles such as subway and the like and the network signal is not good at the moment, the offline taking code pre-stored in the mobile phone is used, and the server is reported again when the network environment where the mobile phone of the user is positioned is good, so that payment is completed.

However, this off-line dispensing technique of the ride code increases the unsafe performance by paying after the user network environment is improved. Some users may pay later and sit in a vehicle while they are on a white-and-white basis.

Disclosure of Invention

It is an object of the present disclosure to improve the security of vehicle ride code issuance.

According to a first aspect of an embodiment of the present disclosure, a vehicle riding code issuing authority configuration method is disclosed, including:

acquiring user attribute data and historical payment data of a user riding a vehicle;

acquiring user risk data based on the user attribute data and the historical payment data;

and configuring the vehicle riding code issuing authority based on the user risk data.

According to a second aspect of the embodiments of the present disclosure, there is disclosed a vehicle riding code issuing authority configuration apparatus, including:

the attribute and payment data acquisition unit is used for acquiring user attribute data and historical payment data of a user riding a vehicle;

a user risk data obtaining unit, configured to obtain user risk data based on the user attribute data and the historical payment data;

and the issuing authority configuration unit is used for configuring the vehicle riding code issuing authority based on the user risk data.

According to a third aspect of embodiments of the present disclosure, a server is disclosed, comprising:

a memory storing computer readable instructions;

a processor reads the computer readable instructions stored in the memory to perform the method described above.

According to a fourth aspect of embodiments of the present disclosure, a computer program medium is disclosed, having stored thereon computer readable instructions, which when executed by a processor of a computer, cause the computer to perform the method as described above.

In the embodiment of the present disclosure, before the ride code is issued to the user, the ride code issuing authority is configured. And obtaining user risk data based on the user attribute data and the historical payment data. Then, based on the user risk data, vehicle ride code issuing authority is configured. Thus, the user attribute is different, the user risk data is affected by the difference of the behavior of the user when the user takes the traffic tool to pay before, and the user taking code issuing authority is determined. Therefore, for some users with relatively high risk (such as frequent subway sitting and no payment), the riding codes cannot be issued to the users, and the security of the riding code issuing is improved.

Other features and advantages of the present disclosure will be apparent from the following detailed description, or may be learned in part by the practice of the disclosure.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The above and other objects, features and advantages of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings.

Fig. 1 illustrates a framework diagram of an environment in which a vehicle ride code issuing authority configuration method according to an exemplary embodiment of the present disclosure is applied.

Fig. 2A-2F, fig. 3A-3H, fig. 4A-4H illustrate a mobile phone interface and a usage state diagram in a specific application scenario in which an exemplary embodiment of the present disclosure is applied to a ride code, wherein fig. 2A-2F illustrate a mobile phone interface and a usage state diagram in a scenario in which a ride code is requested online, fig. 3A-3H illustrate a mobile phone interface and a usage state diagram in a scenario in which a ride code is issued offline using an offline certificate, and fig. 4A-4H illustrate a mobile phone interface and a usage state diagram in a scenario in which an offline ride code is pulled.

Fig. 5 illustrates a flowchart of a vehicle ride code issuing authority configuration method according to an example embodiment of the present disclosure.

Fig. 6A-6E illustrate a flow chart of a vehicle ride code issuing authority configuration method according to other example embodiments of the present disclosure.

FIG. 7 illustrates a specific flow diagram for obtaining user risk data based on the user attribute data and the historical payment data in accordance with an example embodiment of the present disclosure.

Fig. 8 illustrates a flowchart of a vehicle ride code issuing authority configuration method according to another example embodiment of the present disclosure.

Fig. 9 shows a flowchart of a vehicle ride code issuing authority configuration method according to another exemplary embodiment of the present disclosure.

Fig. 10 shows a block diagram of a vehicle ride code issuing authority configuration apparatus according to an example embodiment of the present disclosure.

Fig. 11 shows a block diagram of a vehicle ride code issuing authority configuration apparatus according to another exemplary embodiment of the present disclosure.

Fig. 12 illustrates one example of a statistical distribution of user risk data for all users acquiring a vehicle ride code according to one example embodiment of the present disclosure.

Fig. 13 shows a block diagram of a server according to an example embodiment of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments may be embodied in many forms and should not be construed as limited to the examples set forth herein; rather, these example embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art. The drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus a repetitive description thereof will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments. In the following description, numerous specific details are provided to give a thorough understanding of example embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the aspects of the disclosure may be practiced without one or more of the specific details, or with other methods, components, steps, etc. In other instances, well-known structures, methods, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.

Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software or in one or more hardware modules or integrated circuits or in different networks and/or processor devices and/or microcontroller devices.

Fig. 1 illustrates a framework diagram of an environment in which a vehicle ride code issuing authority configuration method according to an exemplary embodiment of the present disclosure is applied. The user terminal 2 communicates with the server 1 in an online environment to acquire a ride code (typically, a two-dimensional code) for a ride vehicle. When a user rides the vehicle, the acquired riding code is scanned at the position of the code scanner 3 of the vehicle, so that the vehicle can be ridden.

In addition, because the wireless network environment in the places such as subways is not good, the car taking code can not always be requested when the car taking code needs to be requested on line in the places such as subways. Thus, the user can request the server 1 to issue an offline certificate to the user terminal 2 in advance with the user terminal 2 in a place where the network environment is good. When the user needs to take a vehicle such as a subway and the network signal is bad, the off-line certificate in the user terminal 2 temporarily issues a riding code for the user. The user can ride the vehicle by scanning the ride code at the position of the code scanner 3 of the vehicle. And reporting the network environment of the user terminal 2 to the server when the network environment becomes good, and completing payment.

Alternatively, the user may request the server 1 to issue a plurality of offline riding codes pre-stored in the mobile phone by using the user terminal 2 in advance at a place where the network environment is good. When the user needs to take a vehicle such as a subway and the like and the network signal is not good at the moment, the user can take the vehicle by using the off-line taking code pre-stored in the mobile phone and scanning the code at the position of the code scanner 3 of the vehicle. And waiting until the network environment where the mobile phone of the user is positioned is good, reporting to the server, and completing payment.

The user terminal 2 in fig. 1 may be a mobile phone, a PDA, a smart watch, a bracelet, a wireless netbook, or other various terminals, as long as the obtained riding code can be displayed and the code can be scanned at the position of the code scanner 3 of the vehicle. The specific form of the user terminal 2 is not limited.

The server 1 in fig. 1 may be a server composed of one computer, may be a cluster server composed of a plurality of computers together, may be a virtual server occupying only a part of one computer, or may be a virtual cluster server occupying a part or all of each of the plurality of computers. Particularly in cloud environments, virtual cluster servers are commonly used.

The vehicle ride code may be a two-dimensional code, but may also take the form of a bar code or other code. If the riding code is a two-dimensional code, the code scanner 3 in fig. 1 is a two-dimensional code scanner. If the ride code is a bar code, the scanner 3 in FIG. 1 is a bar code scanner. The position of the code scanner 3 varies depending on the kind of the vehicle. For example, in the case of a subway, the code scanners 3 may be provided at both sides of an entrance of the subway. In the case of buses, the code scanner 3 can be held by a ticket seller or can be fixed at a railing at a bus gate.

In the following, with reference to fig. 2A-2F, fig. 3A-3H, and fig. 4A-4H, a specific process of requesting the ride code online, issuing the ride code offline using the offline certificate, pulling and using the offline ride code in actual application will be briefly described in conjunction with a specific application scenario of the ride code.

As shown in fig. 2A, the user may first open a letter in the user terminal, initiate a "discovery" function in the letter, and the user terminal displays an interface as shown in fig. 2A. The user selects "applet" on the interface.

As shown in FIG. 2B, after the user selects "applet," the interface of FIG. 2B appears. The user selects "Tengming riding code" on the interface.

FIG. 2C illustrates the interface of FIG. 2C after the user selects "Tencel ride". Three options "get online ride code", "request to issue offline certificates", "pull multiple offline ride codes online" exist on the interface.

The "get online ride code" is used for users to get online ride codes to ride vehicles in the case that the network environment of the vehicles is good.

The request to issue the offline certificate is used for a user to request to issue the offline certificate when the user is in an online environment in advance under the condition that the network environment of the vehicle is not good, and then the offline certificate on the user terminal can issue a riding code for the user in the offline environment, so that the user can ride the vehicle. When the network environment is good, the user terminal reports the issued riding code to the server for payment.

The method comprises the step of pulling a plurality of offline riding codes online, wherein the offline riding codes are used for pulling a plurality of offline riding codes from a server in advance when a user is in an online environment under the condition that the network environment of a vehicle is not good. The vehicle can then be ridden with the pulled offline ride in an offline environment. When the network environment is good, the user terminal reports the issued riding code to the server for payment.

When the user selects "acquire online ride code" on fig. 2C, an interface as shown in fig. 2D appears. The interface displays the ride code issued by the server on-line.

As shown in fig. 2E, the user sweeps the ride code displayed on the interface against the code scanner 3 at the entrance of the vehicle, which means that the ride vehicle is started. When the user gets off or out of the vehicle, the ride code is swept against the code scanner 3 at the exit of the vehicle, at which point an interface appears on the user terminal as shown in fig. 2F, which displays "the X element has been automatically deducted from the associated account". The association of the payment account and the riding code application is performed when the user registers the riding code application, and the registration process is not repeated.

Fig. 2D-2F illustrate a user interface and usage status when a user requests a ride code online and uses the ride vehicle in a situation where the network environment of the vehicle is good. If the network environment of the vehicle is not good, the user may repeat the above-described processes of fig. 2A-2C in an online environment in advance, but select "acquire online riding code" instead of "request issuing offline certificate" in fig. 2C.

When the user selects "request to issue offline credentials," according to embodiments of the present disclosure, if the user's credit is bad, there may be an interface as shown in fig. 3A, on which "no play, your credit is now insufficient to issue offline credentials for you.

In addition, according to embodiments of the present disclosure, if the user's credit is acceptable, an interface may appear as shown in fig. 3B, on which "an offline certificate has been issued for you, the effective duration is X hours, and the ride code X times may be generated within the effective duration".

Then, if the user wants to ride the vehicle for the effective period of time, and the network environment of the vehicle is not good, and the offline generation of the ride code is required, the user may repeat the process of fig. 2A-2B described above, when an interface such as that of fig. 3C is present. This interface differs from the interface of fig. 2C in that it replaces the "request to issue an offline certificate" with the "use offline certificate to issue a passcode" option, because the offline certificate is already issued at this time.

The user selects "use offline certificate to issue a riding code" on the interface shown in fig. 3C, and if the number of times the user uses the offline certificate to issue the riding code within the effective duration does not exceed the number of times limit displayed on the interface of fig. 3B, the interface shown in fig. 3D appears, and the offline certificate stored on the user terminal is the riding code issued offline by the user.

As shown in fig. 3E, the user sweeps the ride code displayed on the interface against the code scanner 3 at the entrance of the vehicle, which means that the ride vehicle is started. When the user gets off or out of the vehicle, the ride code is swept against the code scanner 3 at the exit of the vehicle, which means that the user stops riding the vehicle, but payment cannot be made because the user terminal is off-line. But the server will save the cost information and the ride code.

The user terminal periodically and automatically detects the on/off state of the user terminal. When the user terminal is detected to be in the online state, the user terminal displays an interface shown in fig. 3F to prompt the user whether the terminal is in the online state or not for riding payment.

After the user selects "confirm" in fig. 3F, an interface shown in fig. 3G appears in which the user is prompted to enter a payment password, which is the password of the account associated with the ride code application.

After the user inputs the payment password, the user terminal reports the password to the server. When the server accords the password with the password reserved during user registration, the user terminal deducts fees from the account of the user, and the user terminal displays a 'successful payment' page shown in fig. 3H.

In addition, if the network environment of the vehicle is not good, the user may repeat the above-described processes in fig. 2A to 2C in an online environment in advance, in addition to the above-described manner of issuing the ride code to the user by the offline certificate, but instead of selecting "acquire online ride codes" in fig. 2C, "pull a plurality of offline ride codes online" is selected.

When the user selects "pull multiple offline ride codes online", according to embodiments of the present disclosure, if the user's credit is bad, an interface as shown in fig. 4A may appear, on which "dumb, your credit is now insufficient to pull the ride codes for you".

In addition, according to embodiments of the present disclosure, if the user's credit is acceptable, an interface as shown in FIG. 4B may appear on which "X offline ride codes have been issued for you according to your credit status".

Next, if the user wants to ride the vehicle, and the network environment of the vehicle is poor, the user may repeat the process of fig. 2A-2B described above when the offline generation of ride codes is required, at which point an interface such as that of fig. 4C appears. This interface differs from the interface of fig. 2C in that it replaces the "pull multiple offline ride codes online" with the "use issued offline ride code" option, because the offline ride code has been pulled at this time.

The user selects "use issued offline ride code" on the interface shown in fig. 4C, and appears on the interface shown in fig. 4D, where one of the issued offline ride codes is displayed.

As shown in fig. 4E, the user sweeps the ride code displayed on the interface against the code scanner 3 at the entrance of the vehicle, which means that the ride vehicle is started. When the user gets off or out of the vehicle, the ride code is swept against the code scanner 3 at the exit of the vehicle, which means that the user stops riding the vehicle, but payment cannot be made because the user terminal is off-line. But the server will save the cost information and the ride code.

The user terminal periodically and automatically detects the on/off state of the user terminal. When the user terminal is detected to be in an on-line state, the user terminal displays an interface shown in fig. 4F to prompt the user whether the terminal is in the on-line state or not for riding payment.

After the user selects "confirm" in fig. 4F, an interface shown in fig. 4G appears in which the user is prompted to enter a payment password, which is the password of the account associated with the ride code application.

After the user inputs the payment password, the user terminal reports the password to the server. When the server matches the password with the password reserved during user registration, the user terminal deducts fees from the user's account, and the user terminal displays a "successful payment" page shown in fig. 4H.

It should be noted that the interfaces of fig. 2A-2F, 3A-3H, and 4A-4H are merely exemplary of an interface in an application scenario, and are merely provided to facilitate the subsequent description and understanding of the application scenario of the embodiments of the present disclosure. These interfaces may be redesigned and changed, all of which fall within the framework of the present disclosure.

According to one embodiment of the present disclosure, as shown in fig. 5, there is provided a vehicle ride code issuing authority configuration method.

Here, the vehicle refers to a public vehicle in which a vehicle, a ship, a subway, a train, an airplane, or the like can be taken by a person. The ride code is an electronic code stored in the user terminal by the user for riding the vehicle, and is a credential for riding the vehicle by the user and is also a credential for settlement of the fee. As previously described, the ride code may be a two-dimensional code, a bar code, or the like. The ride code issuing authority refers to whether or not to permit the user to be issued with the ride code, and restrictions when issuing the ride code. The vehicle riding code issuing authority configuration method of the embodiment of the disclosure is executed by a server, and aims to configure the riding code issuing authority for a user.

When the user selects "request to issue an offline certificate" on the interface of fig. 2C as described above, the server will determine whether to issue an offline certificate for the user in combination with the vehicle riding code issuing authority configured for the user, and if so, how long the validity period is, allow several riding codes to be generated offline for the user within the validity period, so as to determine whether to display the interface of fig. 3A or fig. 3B to the user.

When the user selects "pull multiple offline ride codes online" on the interface of fig. 2C as described above, the server will combine the vehicle ride code issuing authority configured for the user to determine whether to pull the offline ride code for the user, and if so, pull several to determine whether to display the interface of fig. 4A or fig. 4B to the user.

The above-described vehicle ride code issuing authority configuration method may be executed in response to receiving a request for an offline certificate by the user or a request for pulling an offline ride code by the user, that is, after the user selects "request for issuing an offline certificate" or "pull a plurality of offline ride codes online" on the interface of fig. 2C as described above, but may also be executed in advance, for example, periodically (for example, once every morning, 8:00 a day), and the authority configured as a result of the execution is stored in the server and updated periodically. When the user selects "request to issue an offline certificate" or "pull multiple offline ride codes online" on the interface of fig. 2C as described above, only the authority of the stored configuration needs to be searched for control of ride code issue. This has the advantage that the inefficiency caused by the fact that the user starts to determine the authority of issuing the ride code after receiving the request of the user for the offline certificate or the request of the user for pulling the offline ride code is avoided.

The vehicle riding code issuing authority configuration method according to one embodiment of the present disclosure includes:

step 510, acquiring user attribute data and historical payment data of a user riding a vehicle;

step 520, obtaining user risk data based on the user attribute data and the historical payment data;

and step 530, configuring the vehicle riding code issuing authority based on the user risk data.

These steps are described in detail below.

In step 510, user attribute data and historical payment data for the user's ride in the vehicle are obtained.

The user attribute data refers to data indicating attributes of the user. Attributes of the user such as the user's age, work, deposit of the associated account, credit record of the associated account bank. The attributes of the user are relatively stable and do not change as the behavior of the ride vehicle changes. For example, the user is 42 years old, the job is a general manager, 80 ten thousand yuan of deposit is made on the associated account, and no bad credit records are made on the bank of the associated account. These together constitute user attribute data for the user.

The historical payment data for the user riding the vehicle is data indicating the payment situation when the user terminal is on-line again when historically riding the vehicle using the ride code, in particular using an off-line ride code (e.g. a ride code generated by an off-line certificate or an off-line ride code pre-fetched when on-line). For example, a user historically has used an offline ride vehicle 5 times, 2 of which were not paid after being on-line again, such historical payment data for the ride vehicle may have adverse effects in subsequently configuring the user with the ride code issuing authority.

In one embodiment, a portion of the user attribute data may be filled out and reported to the server when the user registers the ride code application. For example, the age, work of the user may be required to be filled in at the time of user registration. Thus, one way to obtain user attribute data may be to look up directly from the user registration information database of the server. The embodiment has the advantages of simplicity, easiness and time saving for searching the user attribute data.

In addition, some of the user attribute data may be that the user is registered without being filled in, e.g., deposit of the user's associated account, credit record of the associated account bank. For this portion of user attribute data, one way to obtain the user attribute data may be to query other servers based on the user registration information in the user registration information database. For example, the account number of the associated account is information that the user needs to fill in the report when registering, so that a request can be sent to the corresponding bank server according to the account number of the associated account found from the user registration information database, and deposit of the associated account of the user, credit record of the bank of the associated account, and the like are queried.

In one embodiment, user attribute data may be crawled from information that a user registers with various websites of the Internet. The information left by the user may be registered on various websites on the internet by crawling the internet according to the name of the user filled in when the user registers. The internet crawling method has the advantages that the burden of filling in various detailed information when the user registers is reduced, and information filled in when some users are not necessarily willing to register can be crawled in some cases.

In one embodiment, the user attribute data may also be queried from a third party server.

Since the detailed information (e.g., start point, destination, fee, whether to pay) of the riding vehicle each time the riding code is used is stored in the server after the user registers the riding code application, the history payment data of the riding vehicle can be directly obtained from the server.

In step 520, user risk data is obtained based on the user attribute data and the historical payment data.

The user risk data is data indicating a risk that the user may not pay after issuing an offline ride code (including ride codes generated using offline certificates and offline ride codes pulled in advance) for the user. It may be embodied in the form of a score, a rank, or a textual description. In the following embodiments, examples are given primarily in the form of scores, but it will be understood by those skilled in the art that user risk data embodied in ratings or textual descriptions are also possible, and are within the spirit and scope of the present disclosure.

In one embodiment, step 520 may include:

setting a basic score;

Determining user attribute addition and subtraction points based on the user attribute data;

determining a history payment addition and subtraction score based on the history payment data;

and determining a user risk score based on the basic score, the user attribute add-subtract score and the history payment add-subtract score as the user risk data.

The base score is a score set for all users as a base. In one embodiment, the base score is the same for all users, e.g., set to 10 points.

In one embodiment, various user attribute data and add-subtract score correspondence tables may be preset and stored. Based on the user attribute data, determining the user attribute add-subtract score can be performed by searching a corresponding relation table of the user attribute data and the add-subtract score.

For example, for the user attribute of user age, an example of a table of correspondence between user attribute data and add-subtract scores is as follows:

age of user	Add-subtract division
		1-10	+10
11-20	+5
		21-50	0
51-70	+5
		71 or more	+10

Table 1 example of a table of correspondence between user ages and addition and subtraction points

If the user is too young, for example 1-10 years old, such a user is at a high risk and therefore has a high risk score because there is not much concept on payment and the mobile phone application is not necessarily familiar, which is likely to be the case when the mobile phone is on-line again, not in accordance with the prompt. If the user is too old, for example, 71 or more, the old people are confused or unfamiliar with the operation of the mobile phone, and a situation that the mobile phone is not paid according to the prompt when the mobile phone is on line again easily occurs, so that the risk of the user is also relatively high, and the risk score of the user is increased. In contrast, adults between 21 and 50 years old are more economically viable, and cell phones are generally more skilled to operate, with a greatly improved probability of paying, and may not have an increased risk score for their users.

For the user attribute of the user occupation, an example of a table of correspondence between user attribute data and add-subtract points is as follows:

user occupation	Add-subtract division
		No occupations	+30
Civil engineering	+10
		Individual industry and commercial tenant	+5
Public officer	-5
		Enterprise staff	-5
General manager	-10
		……	……

Table 2 example of a table of user occupations and add-subtract points correspondence

If the user does not have proper occupation, the life source of the user is likely to be not guaranteed, and in such a case, the user can easily use the off-line riding code and then pay no fee when online. The risk of such users is relatively large and thus their user risk score may be increased. In contrast, if the user is a general manager, it is not generally intended to pay no fee for such a small amount of the ride fee, considering that the economical condition thereof is good and that losing credit easily causes adverse social effects thereon. Such users are at relatively little risk and may therefore have a reduced user risk score.

For the user attribute of deposit of the associated account, an example of a user attribute data and add-subtract score correspondence table is as follows:

associated accountDeposit of (2)	Add-subtract division
		100 ten thousand or more	0
50-100 ten thousand	+2
		20-50 ten thousand	+5
5-20 ten thousand	+8
		Less than 5 ten thousand	+10

Table 3 example of a table of deposit and add-subtract correspondence for associated accounts

Generally, the more deposits an associated account has, the better its repayment capacity is represented. For users with high deposits in the associated account, the probability of not paying online by using the offline ride code is smaller, and the risk is smaller, so that the risk score of the users is not increased too much. For users with low deposits in the associated account, who are not paying online using the offline ride code, the risk ratio is greater, and thus may need to have their user risk score raised.

For the user attribute of the credit record of the associated account bank, an example of a correspondence table between user attribute data and add-subtract score is as follows:

credit records associated with account banks	Add-subtract division
		Excellent (excellent)	0
Good grade (good)	+2
		In (a)	+10
Difference of difference	+30

Table 4 Credit records and Account Bank correspondence table example

Typically, poor user credit records for an associated account bank indicate that they have a history of non-reimbursement before, which indicates either that the user's economic status may fluctuate or be poor, or that the user has a habit of not repayment. For such users, who have a greater probability of not paying online using offline ride codes, the risk ratio is greater, and thus may need to have their user risk score raised. The user credit of the associated account bank is recorded, which either indicates that the user's economic status and repayment habits are good. For such users, who use offline ride codes to pay less online, there is less risk and thus there may be less need to increase their user risk score.

In one embodiment, various user history payment data and add-subtract score correspondence tables may be preset and stored. Based on the history payment data, determining the history payment addition and subtraction points can be performed by searching a corresponding relation table of the history payment data and the addition and subtraction points.

In one embodiment, the historical payment data for the user's ride vehicle may include the number of times the user has historically used the offline ride code (including the ride code issued by the offline certificate and the offline ride code pre-pulled online), and the number of times the user has not paid online after having used the offline ride code to ride the vehicle.

If a user historically uses an offline ride code to ride a vehicle many times, it has a high degree of adhesion to the offline ride code usage, and it is generally more likely to pay online after using the offline ride code, given that a lack of payment in the preamble may have an impact on subsequent rides. If a user historically uses an offline ride code to ride a vehicle rarely, his adherence to the offline ride code use is low. Since the ride is less, it is less concerned that the preamble pay less may have an impact on the subsequent ride. Such users theoretically have less probability of not paying online after using offline ride codes.

The historical use of offline ride codes by users has resulted in a greater number of online unpaid times after riding the vehicle, indicating that the users may have such habits, or that the economic abilities of the users fluctuate. Thus, the user is currently using the offline ride code to ride the vehicle with a greater probability of not paying online. The number of online unpaid times after the user historically uses the offline riding code to ride the vehicle is small, which indicates that the payment habit and economic condition of the user are not too much. Thus, the user is less likely to pay online after riding the vehicle using the offline ride code.

For example, for the number of times a user historically uses an offline ride code to ride a vehicle, an example of the historical payment data and add-subtract score correspondence table is as follows:

table 5 example of a table of the number of times the user historically used the offline ride code to ride the vehicle versus the add-subtract score

For the number of online unpaid times after the user historically uses the offline ride code to ride the vehicle, an example of the historical payment data and add-subtract score correspondence table is as follows:

TABLE 6 example of on-line unpaid times and add-subtract score correspondence table for user historically used offline ride code to ride a vehicle

In addition, in one embodiment, the historical payment data may be used instead of the two indexes of the number of times the user uses the offline ride code to ride the vehicle and the number of times the user uses the offline ride code to ride the vehicle to pay online. The number of online unpaid times after using the user history to ride the vehicle with the offline ride code is equal to the number of online unpaid times after using the user history to ride the vehicle with the offline ride code divided by the number of times the user history to ride the vehicle with the offline ride code. For example, a user historically uses an offline ride code to ride a vehicle 20 times, 6 times after online without payment, then the duty cycle is 6/20=30%.

The higher the duty cycle, the higher the probability that the user will not pay online after riding the vehicle using the offline ride code, and the greater the risk ratio, and thus the user risk score may need to be increased. The lower the duty cycle, the lower the probability that the user will not pay online after riding the vehicle using the offline ride code, and the less risk, and thus may be less likely to require an increase in his user risk score.

In one embodiment, the table of correspondence between the duty ratio and the addition and subtraction can be preset and stored. Based on the history payment data, determining the history payment addition and subtraction points can be performed by searching the corresponding relation table of the duty ratio and the addition and subtraction points.

For the duty ratio, an example of the history payment data and addition and subtraction correspondence relation table is as follows:

table 7 example of a table of the number of times the user historically uses the offline ride code to ride the vehicle versus the add-subtract score

The embodiment has the advantages that the index of the number of times of online unpaid after the user uses the offline riding code to ride the vehicle is used, the index of the number of times of offline riding code to ride the vehicle and the index of the number of times of online unpaid after the user uses the offline riding code to ride the vehicle are replaced, the calculation simplicity is improved, and the authority configuration processing efficiency is improved.

It will be appreciated by those skilled in the art that while the above examples of the number of times the user has historically used the offline ride code to ride the vehicle, the number of times the user has historically used the offline ride code to ride the vehicle and the number of times the user has not paid online to ride the vehicle are all counted from the time the user has registered the ride code application, in practice the above examples of the number of times the user has historically used the offline ride code to ride the vehicle, the number of times the user has historically used the offline ride code to ride the vehicle and the number of times the user has not paid online to ride the vehicle may also be counted within a predetermined period of time from the current time point. For example, the number of times the user uses the offline take-up code to take the vehicle one month before the current time point, the number of times the user uses the offline take-up code to take the vehicle and then does not pay online, and the number of times the user uses the offline take-up code to take the vehicle and does not pay online are counted.

Then, based on the basic score, the user attribute add-subtract score and the history payment add-subtract score, the user risk score can be determined as the user risk data. For example, the base score for a user is 10 points. The age of the user was 25 years, plus 0 points. The occupation of the user is an individual business merchant, and the score is 5. The deposit of the user associated account is 55 ten thousand plus 2 points. The credit record of the user's associated account bank is good, plus 2 points. The number of times the user historically used the offline ride code to ride the vehicle was 30 times plus 5 points. The number of online unpaid times after the user historically used the offline ride code to ride the vehicle was 6 times plus 30 points. The user risk score is 10+0+5+2+2+5+30=54.

In another embodiment, as shown in FIG. 7, step 520 includes:

step 5201, determining a first score based on the user attribute data;

step 5202, determining a second score based on the historical payment data;

and 5203, obtaining user risk data based on the first score and the second score.

The embodiment does not firstly give a basic score to the user, adds and subtracts the score to the user according to the user attribute data and the historical payment data, directly determines the score corresponding to the user attribute data and the score corresponding to the historical payment data, and then determines the comprehensive score according to the two scores to serve as the user risk data. The embodiment has the advantages that the user attribute data and the historical payment data are respectively scored and then integrated, so that the objectivity of obtaining the user risk data is improved, and the processing efficiency of obtaining the user risk data is improved.

In step 5201, the first score is determined based on the user attribute data, and may be performed by searching a preset table of correspondence between the user attribute data and the first score.

For example, for the user attribute user age, an example of a table of user attribute data versus first score correspondence is as follows:

age of user	First score
		1-10	10
11-20	5
		21-50	0
51-70	5
		71 or more	10

TABLE 8 user age and first score correspondence table example

For this user attribute of the user occupation, an example of a table of user attribute data versus first score correspondence is as follows:

user occupation	First score
		No occupations	10
Civil engineering	7
		Individual industry and commercial tenant	5
Public officer	2
		Enterprise staff	2
General manager	0
		……	……

TABLE 9 user occupation and first score correspondence table example

For the user attribute of deposit of the associated account, an example of a table of user attribute data versus first score correspondence is as follows:

deposit of associated accounts	First score
		100 ten thousand or more	0
50-100 ten thousand	2
		20-50 ten thousand	5
5-20 ten thousand	8
		Less than 5 ten thousand	10

Table 10 deposit and first score correspondence table example of associated accounts

For this user attribute, the credit record of the associated account bank, an example of a table of user attribute data versus first score correspondence is as follows:

Credit records associated with account banks	First score
		Excellent (excellent)	0
Good grade (good)	5
		In (a)	8
Difference of difference	10

Table 11 Credit records associated with Account Bank and first score correspondence table example

In step 5202, the second score is determined based on the historical payment data by searching a preset corresponding relation table between the historical payment data and the second score.

For example, for a number of times a user historically uses an offline ride code to ride a vehicle, an example of the historical payment data versus second score table is as follows:

table 12 example of a relationship between the number of times the user has historically used the offline ride code to ride the vehicle and the second score

For the number of online unpaid times after a user historically uses an offline ride code to ride a vehicle, an example of the historical payment data versus second score table is as follows:

table 13 example of a table of the correspondence between the number of online unpaid times and the add-subtract score after the user has historically used the offline ride code to ride the vehicle

In one embodiment, in step 5203, obtaining user risk data based on the first score and the second score may be performed by calculating a sum of each first score determined based on each user attribute data, each second score determined based on each historical payment data.

In another embodiment, in step 5203, obtaining user risk data based on the first score and the second score may be performed by calculating an average of each first score determined based on each user attribute data, each second score determined based on each historical payment data.

In another embodiment, in step 5203, obtaining the user risk data based on the first score and the second score may be performed by calculating a weighted average of each first score determined based on each user attribute data and each second score determined based on each historical tie data, wherein the weight of each first score and each second score is predetermined. The advantages of this embodiment are: the user attribute data, the history payment data, are not equally important. For example, the credit record of the associated account bank in the user attribute data is much more important than the user's age and occupation. The number of online unpaid times after the user history in the history payment data uses the offline ride code to ride the vehicle is much more important than the number of offline ride code times the user history uses the offline ride code to ride the vehicle. And respectively endowing the attribute data and the historical payment data of each item of user with corresponding weights, so that the objectivity and the correctness of the obtained user risk data can be improved.

Assume that m items of user attribute data are provided, wherein the 1 st, 2 nd, … … i … … th item of user attribute data are a respectively ₁ ,a ₂ ,……，a _i ,……，a _m The corresponding weights are alpha respectively ₁ ,α ₂ ,……，α _i ,……，α _m The method comprises the steps of carrying out a first treatment on the surface of the There are n historical payment data, wherein the 1,2, … … i … …, n user attribute data are b ₁ ,b ₂ ,……，b _i ,……，b _n The corresponding weights are respectively beta ₁ ,β ₂ ,……，β _i ,……，β _n . The user risk score c as user risk data is:

c＝α ₁ a ₁ +α ₂ a ₂ +…+α _i a _i +α _m a _m +β ₁ b ₁ +β ₂ b ₂ +……+β _i b _i +……+β _n b _n 。

for example, the age of the user is 25 years, the corresponding first score is 0 score, and the age corresponds to a weight of 0.1. The occupation of the user is an individual business merchant, the corresponding first score is 5 points, and the weight corresponding to the occupation is 0.1. The deposit of the user-associated account is 55 ten thousand, the corresponding first score is 2 points, and the weight of the deposit of the user-associated account is 0.1. The credit record of the user's associated account bank is good, the corresponding first score is 5 points, and the corresponding weight of the credit record of the user's associated account bank is 0.2. The number of times the user has historically used the offline ride code to ride the vehicle is 30 times, the corresponding second score is 2 points, and the weight corresponding to the number of times the user has historically used the offline ride code to ride the vehicle is 0.1. The number of online unpaid times after the user history uses the offline ride code to ride the vehicle is 6, the corresponding second score is 8, and the weight corresponding to the number of online unpaid times after the user history uses the offline ride code to ride the vehicle is 0.4. The user risk score for the user is:

c＝0×0.1+5×0.1+2×0.1+5×0.2+2×0.1+8×0.4＝0+0.5+0.2+1+0.2+3.2＝5.1

In step 530, vehicle ride code issuing rights are configured based on the user risk data.

The ride code issuing authority refers to whether or not to permit the user to be issued with the ride code, and restrictions when issuing the ride code. In one embodiment, it comprises one or more of the following:

an indication of whether or not the user is allowed to issue an offline certificate;

the effective duration of the offline certificate;

the offline certificate is used by the user terminal to generate a maximum number of vehicle ride codes;

an indication of whether an off-line ride code is allowed to be issued to an on-line user;

the maximum number of offline ride codes issued to online users.

The indication of whether to permit the user to issue the offline certificate does not directly indicate whether to permit the user to issue the riding code under the offline condition, but does not issue the offline certificate, and the user cannot obtain the riding code under the offline condition through the offline certificate, which is equivalent to indirectly not permitting the user to issue the riding code under the offline condition. In addition, the validity duration of the offline certificate, and the maximum number of times the offline certificate is used by the user terminal to generate the vehicle ride code are all limitations of the offline certificate issuing the ride code to the user. Whether to allow the online user to issue an offline riding code or not refers to whether to allow the user to pre-pull a plurality of offline riding codes when online and store the offline riding codes in the user terminal. The maximum number of offline ride codes issued to online users is a limitation on the issuance of ride codes.

In one embodiment, in step 530, the vehicle riding code issuing authority is configured based on the user risk data by searching a preset corresponding relationship table of the user risk data and the riding code issuing authority. The following is an example of a preset correspondence table between user risk data and riding code issuing authority.

Table 14 user risk data and riding code issuing authority correspondence relation expression example

For example, when the user risk score is 5.1, an indication of whether the off-line certificate is allowed to be issued to the user is found to be "yes"; the effective duration of the offline certificate is 1 hour; the offline certificate is used by the user terminal to generate a vehicle ride code a maximum number of 1 time; an indication of whether the off-line ride code is allowed to be issued to the on-line user is yes; the maximum number of offline ride codes issued to online users is 1. The user's vehicle ride code issuing authority is configured as above.

While the above examples illustrate five types of ride code issuing authority that simultaneously configure for the user whether the user is permitted to issue an offline certificate, the validity period of the offline certificate, the maximum number of times the offline certificate is used by the user terminal to generate a vehicle ride code, whether the user is permitted to issue an offline ride code, the maximum number of offline ride codes issued to the user who is online, those skilled in the art will appreciate that only one of them may be configured for the user, or several of them may be configured for the user. When more than one sort of riding code issuing authority is configured for the user, the more than one sort of riding code issuing authority may be placed in the riding code issuing authority list.

While the above example has been described in which the riding code issuing authority is statically configured according to the pre-generated user risk data and riding code issuing authority correspondence table, in another embodiment, the riding code issuing authority may be dynamically configured according to the analysis result of the real-time big data. Specifically, in one embodiment, step 530 includes: the vehicle ride code issuing authority is configured according to a statistical distribution of user risk data of users using the vehicle ride code.

In one embodiment, configuring the vehicle ride code issuance authority according to the statistical distribution of user risk data of users using the vehicle ride code includes:

acquiring statistical distribution of user risk data of users of the vehicle riding codes;

the method comprises the steps of obtaining the number ratio of people corresponding to each gear of a vehicle riding code issuing authority;

determining a corresponding relation table of each gear and a corresponding user risk data interval according to the number ratio of the people in each gear and the statistical distribution of the user risk data of the users of the vehicle riding codes;

and configuring the vehicle riding code issuing authority of the user according to the corresponding relation table of each gear and the corresponding user risk data interval and the user risk data of the user.

Since steps 510-520 are performed for each user of the registered ride code application, user risk data for all users who have acquired the vehicle offline ride code and all registered ride code applications are available. According to each user risk data and the corresponding number of people, a statistical distribution map of the user risk data of the user who acquires the vehicle riding code can be depicted, as shown in fig. 12. In fig. 12, the horizontal axis represents a user risk score as user risk data, between 0 and 10 points; the vertical axis represents the number of people for each user risk score. The area enclosed by the horizontal axis under the curve represents the total number of users.

The number of people corresponding to each gear of the vehicle taking code issuing authority may be predetermined, for example, the number of people corresponding to each gear of the desired vehicle taking code issuing authority may be as follows:

table 15 table of correspondence between gear positions and desired number of persons for issuing authority of vehicle riding code

Then, according to the number of people in each gear and the statistical distribution of the user risk data of the users of the vehicle riding codes, the user risk data distribution corresponding to each gear can be determined.

For example, the last gear in table 15 is the gear with the greatest risk of the user, and the expected number of people in the gear is 5%, so that a vertical line is found on the statistical distribution curve of the user risk data, so that in the area surrounded by the statistical distribution curve and the horizontal axis, the subarea divided on the right side of the vertical line occupies 5% of the area surrounded by the whole statistical distribution curve and the horizontal axis, and the intersection point of the vertical line and the horizontal axis is 9.1, which indicates that the user risk score of 9.1-10 points can be made to be the user risk score interval corresponding to the last gear in table 15. In this way, the user risk score intervals corresponding to the other respective gear positions in table 15 can be found in turn in fig. 12. And finally, determining a user risk score interval corresponding to each gear as follows:

table 16 table of the interval correspondence between each gear of the vehicle ride code issuing authority and the user risk score determined by big data analysis

And then, according to the corresponding relation table of each gear and the corresponding user risk data interval and the user risk data of the user, the vehicle riding code issuing authority of the user can be configured. For example, the user risk score 4 of the user, the table look-up indicates that the indication of whether the off-line certificate is allowed to be issued to the user is "yes", the effective duration of the off-line certificate is 1 day, the maximum number of times the off-line certificate is used by the user terminal to generate the vehicle ride code is 5 times, the indication of whether the off-line ride code is allowed to be issued to the online user is "yes", and the maximum number of off-line ride codes issued to the online user is 3.

The dynamic configuration of the riding code issuing authority according to the big data analysis result has the advantages that: compared with the embodiment of statically configuring the riding code issuing authority, the real-time variation of crowd habit and preference can be fully considered, so that the riding code issuing authority is more objectively configured. For example, for a period of time just after the start of an offline ride, the user risk score may be generally high due to the general unfamiliarity of the business, resulting in many people forgetting to pay online after riding in the vehicle. In this case, according to the fixed correspondence table between the user risk data and the riding code issuing authority, many people may not use the offline riding code, and the popularization of the offline riding code is not facilitated, so that the riding code issuing authority of the vehicle needs to be properly relaxed. After the offline ride code is enabled for a long period of time, people's awareness of payment is enhanced, and the risk score of the user is reduced, which may be when the vehicle ride code is properly tightened to issue rights. The method for dynamically configuring the riding code issuing authority according to the big data analysis result enables the configured riding code issuing authority to be more objective, and can overcome the defect that the riding code issuing authority is configured according to the fixed corresponding relation table of the user risk data and the riding code issuing authority, and if the corresponding relation table is not configured well, correction is not easy to obtain in practice.

As shown in fig. 6A, in the case where the vehicle ride code issuing authority includes an indication of whether or not the issuing of the offline certificate to the user is permitted, the method further includes: step 540, in response to the request for issuing the offline certificate, determining whether to issue the offline certificate according to the indication of whether to allow the user to issue the offline certificate.

Referring back to fig. 2C, when the user selects "request for issuing an offline certificate" on the interface of fig. 2C, the user terminal transmits an offline certificate issue request to the server, and since an indication of whether or not the offline certificate is permitted to be issued to the user has been obtained in step 530, it is possible to decide whether or not to issue an offline certificate to the user based on the indication.

If it is decided not to issue an offline certificate to the user, the user terminal displays the interface shown in fig. 3A, which displays "inexhaustible, your credit is now insufficient to issue an offline certificate for you".

If it is decided to issue the offline certificate to the user, the offline certificate is issued to the user terminal, the user terminal displays the interface shown in fig. 3B, and the interface displays "the offline certificate has been issued for you, the effective duration is X hours, and the riding code X times can be generated in the effective duration".

As shown in fig. 6B, in the case where the vehicle ride code issuing authority includes a valid duration of an offline certificate, the issuing further includes: and step 541, issuing an offline certificate of the effective duration according to the effective duration in response to an offline certificate issuing request of the user.

Referring back to fig. 2C, when the user selects "request for issuing an offline certificate" on the interface of fig. 2C, the user terminal transmits an offline certificate issue request to the server, and issues an offline certificate of a valid duration to the user since the valid duration of the offline certificate has been obtained in step 530. The user terminal notifies the effective duration on the interface of fig. 3B.

As shown in fig. 6C, in the case where the vehicle ride code issuing authority includes a maximum number of times that an offline certificate is used by the user terminal to generate a vehicle ride code, the method further includes: step 542, in response to the request for issuing the offline certificate of the user, issuing the offline certificate which can be used by the user terminal for the maximum number of times according to the maximum number of times.

Referring back to fig. 2C, when the user selects "request for issuing an offline certificate" on the interface of fig. 2C, the user terminal transmits an offline certificate issue request to the server, and the offline certificate with the maximum number of times is issued to the user since the maximum number of times the offline certificate has been obtained for use by the user terminal to generate a vehicle ride code in step 530. The user terminal informs the user terminal of the maximum number of times the offline certificate is used by the user terminal to generate a vehicle ride code on the interface of fig. 3B.

In one embodiment, in case the user terminal has requested and stored an offline certificate, the method further comprises:

receiving a request of a user for issuing a riding code to an offline certificate in an offline state, and judging whether the request time of the request is within the effective duration of the offline certificate;

if the number of times the offline certificate is used by the user terminal to generate the vehicle ride code exceeds the maximum number of times, determining whether the offline certificate has been issued since the offline certificate was issued within the valid period of time;

if not, issuing a riding code by using the offline certificate;

displaying the riding code.

Referring back to fig. 3C, when the user needs to ride the vehicle in an offline environment, and thus needs to use the offline certificate issuing ride code, "use the offline certificate issuing ride code" is selected on the interface of fig. 3C. The user terminal receives a request of a user for issuing a riding code to the offline certificate in an offline state. Since the user terminal has stored the valid duration of the offline certificate, it can be determined whether the time at which the request was received falls within the valid duration. For example, the server issues an offline certificate to the user terminal in 2018, 3 and 2 days 18:04:06, the effective duration is 1 day, and when the user requests to issue a riding code using the offline certificate in 2018, 3 and 3 days 17:04:05, the time for receiving the request falls within the effective duration.

Then, if it falls within the valid period, it is determined whether the number of times the offline certificate was used by the user terminal to generate the vehicle ride code exceeds the maximum number of times since the offline certificate was issued. For example, the server issues an offline certificate to the user terminal in 2 nd 3 th month 18:04:06, the effective duration is 1 day, the maximum number of times is 3 times, the user requests to issue a riding code using the offline certificate once in 3 rd month 7:58:42, and requests to issue a riding code using the offline certificate again in 17:04:05 3 rd month 3 nd month 2018, at this time, it should be considered that the number of times 2 of using the offline certificate by the user terminal to generate a riding code of a vehicle does not exceed the maximum number of times 3, and the riding code can be generated and displayed using the offline certificate.

Fig. 3D is an example of a displayed ride code.

As shown in fig. 3E, the user sweeps the ride code displayed on the interface against the code scanner 3 at the entrance of the vehicle, and the code scanner 3 transmits the ride code to the server, and starts charging corresponding to the ride code. When the user gets off or goes out from the vehicle, the riding code is scanned against the code scanner 3 at the exit of the vehicle, the code scanner 3 sends the riding code to the server, and charging corresponding to the riding code is finished. Although the server has performed charging corresponding to the ride code, the mobile terminal cannot be charged since the user terminal is in an offline state. Thus, in one embodiment, the method further comprises:

Detecting whether a user terminal is in an online state;

if the payment information is in the online state, prompting the user to input the payment information;

transmitting the payment information to a server;

and receiving charging response information of the server.

In one embodiment, the user terminal may periodically and automatically detect whether the user terminal is online, for example, once every 1 second. When the user terminal is detected to be in an online state, prompting the user to input payment information. In one embodiment, the payment information includes a user agreement to the payment and an account password. As shown in fig. 3F, the interface prompts the user "whether the terminal is currently on-line or not to pay for a ride". The user selects "confirm". An interface, as shown in fig. 3G, then appears in which the user is prompted to enter a payment password, which is the password of the account associated with the ride code application.

Then, the user terminal may send the payment information (the user agrees to pay, the account password) to the server, and after the server finishes the fee deduction, the user terminal receives the charging response information of the server. If the user's payment password matches the pre-stored password, payment can be completed and the billing response information includes a payment success message. The user terminal may then display "payment successful" to the user, as shown in fig. 3H.

As shown in fig. 6D, in the case where the vehicle ride code issuance authority includes an indication of whether the vehicle ride code issuance authority includes an off-line ride code permitted to be issued to an on-line user, the method further includes: and step 543, in response to the offline riding code issuing request of the online user, determining whether to issue the offline riding code to the user according to the indication of whether to allow the online user to issue the offline riding code.

Referring back to fig. 2C, after the user selects "pull a plurality of offline ride codes online" on the interface of fig. 2C, the user terminal transmits an offline ride code issuance request to the server, and since an indication of whether to allow the offline ride code to be issued to the online user has been obtained in step 530, it is possible to decide whether to issue the offline ride code to the online user according to the indication.

If it is decided not to issue an offline ride code to the user, the user terminal displays the interface shown in fig. 4A, which displays "don't care, your credit is now insufficient to pull an offline ride code for you.

If it is decided to issue the offline ride code to the user, the offline ride code is issued to the user terminal, and the user terminal displays the interface shown in fig. 4B, which displays "X offline ride codes have been issued for you according to your credit.

As shown in fig. 6E, in the case where the vehicle ride code issuing authority includes the maximum number of offline ride codes issued to online users, the method further includes: step 544, in response to the online user's offline ride code issuing request, issuing an offline ride code to the user according to the maximum number.

Referring back to fig. 2C, after the user selects "pull multiple offline ride codes online" on the interface of fig. 2C, the user terminal sends an offline ride code issue request to the server, which issues the maximum number of offline ride codes to the user since the maximum number has been obtained in step 530.

In one embodiment, in case the user terminal has pulled and stored the offline ride code, the method further comprises:

receiving a request of a user for an offline riding code in an offline state, and judging whether the offline riding code stored in a user terminal is used up or not;

if not, selecting an off-line riding code from the unused off-line riding codes;

displaying the selected offline ride code.

Referring back to fig. 4C, when the user needs to ride the vehicle in an offline environment and thus needs to use the issued offline ride code, "use the issued offline ride code" is selected on the interface of fig. 4C. And the user terminal receives a request of the user for the offline riding code in an offline state and judges whether the offline riding code stored in the user terminal is used up or not. If not, the offline ride code cannot be issued to the user. If not, an off-line ride code is selected from the unused off-line ride codes. The selection may be performed in a random manner or in a sequential order of their storage locations in the user terminal. The selected offline ride code is then displayed, as shown in fig. 4D.

As shown in fig. 4E, the user sweeps the ride code displayed on the interface against the code scanner 3 at the entrance of the vehicle, and the code scanner 3 transmits the ride code to the server, and starts charging corresponding to the ride code. When the user gets off or goes out from the vehicle, the riding code is scanned against the code scanner 3 at the exit of the vehicle, the code scanner 3 sends the riding code to the server, and charging corresponding to the riding code is finished. Although the server has performed charging corresponding to the ride code, the mobile terminal cannot be charged since the user terminal is in an offline state. Thus, in one embodiment, the method further comprises:

detecting whether a user terminal is in an online state;

transmitting the payment information to a server;

and receiving charging response information of the server.

In one embodiment, the user terminal may periodically and automatically detect whether the user terminal is online, for example, once every 1 second. When the user terminal is detected to be in an online state, prompting the user to input payment information. In one embodiment, the payment information includes a user agreement to the payment and an account password. As shown in fig. 4F, the interface prompts the user "whether the terminal is currently on-line or not to pay for a ride". The user selects "confirm". An interface, as shown in fig. 4G, then appears in which the user is prompted to enter a payment password, which is the password of the account associated with the ride code application.

Then, the user terminal may send the payment information (the user agrees to pay, the account password) to the server, and after the server finishes the fee deduction, the user terminal receives the charging response information of the server. If the user's payment password matches the pre-stored password, payment can be completed and the billing response information includes a payment success message. Then, as shown in fig. 4H, the user terminal may display "payment successful" to the user.

Additionally, embodiments of the present disclosure may introduce an automatic degradation mechanism for user risk data. This is because if the user risk data of the user indicates a high risk, the user is not issued with an offline certificate or an offline ride code, and this is not released for a long time, the user may discard the use of the ride code application or use a vehicle not involving the ride code, which is disadvantageous to the popularization of the ride code application. Therefore, it is required to prompt that the user is not issued an offline certificate or an offline ride code due to the undesirable credit of the user in a short time, thereby attracting the user's attention and improving the payment status, but if this is not relieved for a long time, the popularization of the ride code application is affected.

Thus, under such consideration, in one embodiment, after step 520, the method comprises: step 525, if the user risk data indicates that the user risk is higher than the risk threshold, adjusting the user risk data to indicate that the user risk is lower than or equal to the risk threshold after a predetermined period of time since the user risk data was obtained.

The risk threshold is a threshold for measuring the risk of the user indicated by the user risk data. In one embodiment, the risk threshold may be defined at or slightly below a user risk data demarcation point where the user is issued an offline certificate and the user is not issued an offline certificate. And the user risk data demarcation point is the intersection point of the user risk data interval corresponding to the offline certificate issued to the user and the user risk data interval corresponding to the offline certificate not issued to the user. For example, in table 16, the user risk score 9.1 is the user risk data demarcation point. The risk threshold may be set to 9. Thus, if the user risk score is higher than 9, the user risk score is reduced to 9 after a predetermined period of time (e.g., 12 hours) from the time the user risk data is obtained. The user risk score is equal to 9, and the offline certificate or the offline riding code can be issued for the user, so that the user adhesiveness is prevented from being reduced because the offline certificate or the offline riding code is not issued for too long before the vehicle riding code issuing authority of the user is updated and configured next time.

In one embodiment, the user risk indicated by the user risk data may be gradually reduced over a predetermined period of time, such that after the predetermined period of time the user risk data is adjusted to indicate that the user risk is below or equal to the risk threshold.

Specifically, the user risk indicated by the user risk data is gradually reduced in a predetermined period, so that after the predetermined period, the user risk data is adjusted to indicate that the user risk is lower than or equal to the risk threshold, which may include:

dividing a preset time period into a plurality of sub-time periods, wherein the plurality of sub-time periods respectively correspond to a plurality of user risk values which are gradually decreased in sequence according to time sequence, the user risk value corresponding to the last sub-time period is the risk threshold, and the plurality of user risk values which are gradually decreased are lower than the user risk value indicated by the user risk data;

and each time a sub-time period passes, the user risk data is adjusted to indicate a user risk value corresponding to the sub-time period.

For example, the predetermined period is 12 hours, and the 12 hours are divided into 3 sub-periods: 1-4 hours, 5-8 hours, 9-12 hours. The current user risk score is 9.9 and the risk threshold is 9.9.6, 9.3 and 9 are user risk scores corresponding to the 3 sub-periods, respectively. After the 1 st to 4 th hours have passed, the user risk score is adjusted to 9.6; after the 5 th-8 th hour has elapsed, the user risk score is adjusted to 9.3; after the 9 th to 12 th hours have passed, the user risk score is adjusted to 9.

The advantage of gradually lowering the user risk indicated by the user risk data in the predetermined time period is that the user risk is gradually lowered according to the difference between the user risk indicated by the current user risk data and the risk threshold value, so that users with the user risk indicated by some user risk data only being slightly higher than the risk threshold value can quickly return to the line and row where the offline certificates and offline riding codes can be issued, and users with the user risk indicated by the user risk data exceeding the risk threshold value can be issued for the users almost until the predetermined time period is nearly completed, and the fairness and flexibility of issuing the offline certificates and the offline riding codes are improved. Meanwhile, the user risk indicated by the user risk data is gradually reduced, so that some users can see the hope of issuing an offline certificate and an offline riding code for the users as soon as possible, and the user adhesiveness is improved.

The risk threshold may be preset, but in one embodiment, the risk threshold is based on big data analysis. Specifically, the risk threshold is obtained by:

Acquiring an expected number of people corresponding to the risk threshold;

and determining the risk threshold according to the expected population ratio corresponding to the risk threshold and the statistical distribution of the user risk data of the users of the vehicle riding codes.

The expected population ratio corresponding to the risk threshold refers to a desired ratio of the population occupancy total number for which the user risk indicated by the user risk data is higher than the risk threshold. For example, the duty cycle is 5%, meaning that user risk indicated by the user risk data for 5% of the users is expected to be above the risk threshold. The expected number of people corresponding to the risk threshold may be preset, or may be input by an administrator and obtained from the administrator's input.

The risk threshold may then be determined based on the expected population ratio corresponding to the risk threshold and the statistical distribution of user risk data for the users of the vehicle ride code.

Assuming that the predetermined population ratio is 5%, as shown in fig. 12, a vertical line is found on the statistical distribution curve of the user risk data in fig. 12, so that in the area surrounded by the statistical distribution curve and the horizontal axis, the subarea divided on the right side of the vertical line occupies 5% of the area surrounded by the whole statistical distribution curve and the horizontal axis, and the intersection point of the vertical line and the horizontal axis is 9.1, and the determined risk threshold is 9.1.

The advantage of obtaining the risk threshold from the big data analysis is that it can avoid subjectivity caused by manually presetting the risk threshold. In addition, the real-time variation of crowd habit and preference can be fully considered, so that the degradation of the user risk data is more objective. For example, for a period of time just after the start of an offline ride, the user risk score may be generally high due to the general unfamiliarity of the business, resulting in many people forgetting to pay online after riding in the vehicle. At this time, if the risk threshold is too low, it may cause a problem of generally lowering the user risk indicated by the user risk data. The risk of the user is generally reduced, the user adhesiveness is improved, and a large number of bad accounts of a transportation company are easily caused. Thus, deriving the risk threshold from big data analysis may strike a good balance between improving user adhesion and increasing profits of the vehicle operator.

In addition, after the vehicle seat code issuing authority is configured in step 530, it is also possible to dynamically adjust the configured vehicle seat code issuing authority according to feedback of the user feedback, so that the configured vehicle seat code issuing authority is more objective.

In an embodiment that adjusts based on user feedback, as shown in FIG. 9, after step 530, the method may include:

step 531, receiving feedback of authority of the user for issuing the riding code of the vehicle;

step 532, obtaining user risk data of the user;

and 533, adjusting the configured vehicle riding code issuing authority based on the acquired user risk data and the feedback of the user.

In one embodiment, step 531 may include the following options as to whether the vehicle ride code issuance authority includes an indication of whether the off-line certificate is allowed to be issued to the user, a valid duration of the off-line certificate, a maximum number of times the off-line certificate is used by the user terminal to generate the vehicle ride code, an indication of whether the off-line ride code is allowed to be issued to the online user, a maximum number of off-line ride codes issued to the online user, and so on:

displaying to the user an option of vehicle ride code issuance authority, the option including one or more of an indication of whether to allow issuance of an offline certificate to the user, a validity duration of the offline certificate, a maximum number of times the offline certificate is used by the user terminal to generate vehicle ride codes, an indication of whether to allow issuance of an offline ride code to an online user, a maximum number of offline ride codes issued to the online user;

A user selection of an option is received.

Generally, the vehicle riding code issuing authority is not adjusted to a direction beneficial to the user as long as the user feeds back the vehicle riding code issuing authority. In one embodiment, step 533 includes: and determining whether to adjust the option fed back by the user corresponding to the user risk data interval according to a preset rule according to whether the number of the users of the same option which is positioned in the same user risk data interval and feeds back the vehicle riding code issuing authority within a specific time period exceeds a preset user number threshold value in a corresponding relation table (shown in table 16) of the user risk data interval and the vehicle riding code issuing authority.

For example, the user risk score is 4.5, and the option for issuing authority for the vehicle ride code fed back is the validity duration of the offline certificate. And 4.5, wherein in a corresponding relation table of the user risk score interval and the vehicle riding code issuing authority as shown in table 16, the user risk score interval is 2.5-5.1. The option of 805 people feeding back the effective duration of the offline certificate in one week in this interval exceeds the predetermined user number threshold 800. Therefore, the effective duration of the offline certificate corresponding to the user risk score interval 2.5-5.1 in the corresponding relation table of the user risk score interval and the vehicle riding code issuing authority as shown in the table 16 can be adjusted for 1 day. In one example, if the predetermined rule is to increase the effective duration by 0.5 days, the effective duration of the offline certificate corresponding to the user risk score interval 2.5-5.1 is adjusted to 1.5 days according to the predetermined rule.

The advantage of this embodiment is that, since the adjustment is not performed according to the feedback of the user's own option of the vehicle riding code issuing authority, but according to whether the number of users of the same option, which are located in the same user risk data interval as the user and feedback of the vehicle riding code issuing authority within a specific period of time, exceeds the predetermined user number threshold value in the user risk data interval and vehicle riding code issuing authority correspondence table (as shown in table 16), the influence caused by the subjectivity of the user feedback is reduced.

As shown in fig. 10, according to an embodiment of the present disclosure, there is also provided a vehicle ride code issuing authority configuration apparatus including:

an attribute and payment data acquisition unit 710 for acquiring user attribute data and historical payment data of a user riding a vehicle;

a user risk data obtaining unit 720, configured to obtain user risk data based on the user attribute data and the historical payment data;

and an issuing authority configuration unit 730, configured to configure a vehicle riding code issuing authority based on the user risk data.

In one embodiment, the vehicle ride code issuing authority includes: an indication of whether or not to permit issuance of an offline certificate to the user for offline generation of the vehicle ride code by the user terminal. The apparatus further comprises: an offline certificate issuance determination unit (not shown) for determining whether to issue an offline certificate in response to an offline certificate issuance request of the user, according to the indication of whether to permit the issuance of the offline certificate to the user.

In one embodiment, the vehicle ride code issuing authority includes: the validity duration of the offline certificate. The apparatus further comprises: an offline certificate issuance determination unit (not shown) for issuing an offline certificate of the valid duration in accordance with the valid duration in response to an offline certificate issuance request of the user.

In one embodiment, the vehicle ride code issuing authority includes: the offline certificate is used by the user terminal to generate a maximum number of vehicle ride codes. The apparatus further comprises: an offline certificate issuance determination unit (not shown) for issuing an offline certificate that can be used by the user terminal for the maximum number of times in response to an offline certificate issuance request of the user.

In one embodiment, the vehicle ride code issuing authority includes: an indication of whether an off-line ride code is allowed to be issued to an on-line user for use by the user in an off-line state with a ride vehicle. The apparatus further comprises: an offline ride code issuing determining unit (not shown) for determining whether to issue an offline ride code to the user in response to an offline ride code issuing request of the user on line, according to the indication of whether to permit the issue of the offline ride code to the user on line.

In one embodiment, the vehicle ride code issuing authority includes: the maximum number of offline ride codes issued to online users. The apparatus further comprises: an offline ride code issuing determining unit (not shown) for issuing offline ride codes to users on line in response to an offline ride code issuing request of the users on line, according to the maximum number.

In one embodiment, the attribute and payment data acquisition unit 710 is further configured to:

determining a first score based on the user attribute data;

determining a second score based on the historical payment data;

and obtaining user risk data based on the first score and the second score.

As shown in fig. 11, in one embodiment, the apparatus includes: and the user risk data downgrade unit 725 is configured to adjust the user risk data to indicate that the user risk is equal to or lower than the risk threshold after a predetermined period of time from when the user risk data is obtained if the user risk data indicates that the user risk is higher than the risk threshold.

In one embodiment, the issuing authority configuration unit 730 is further configured to:

the vehicle ride code issuing authority is configured according to a statistical distribution of user risk data of users using the vehicle ride code.

The user risk data demotion unit 725 and the user risk data obtaining unit 720 in fig. 11 together constitute the user risk data obtaining means 72 for obtaining and adjusting the user risk data.

As shown in fig. 11, in one embodiment, the apparatus further includes a release authority adjustment unit 735, and the release authority adjustment unit 735 is configured to:

receiving feedback of authority of a user for issuing a riding code of a vehicle;

acquiring user risk data of a user;

and adjusting the configured vehicle riding code issuing authority based on the acquired user risk data and the feedback of the user.

The issuing authority adjustment unit 735 and the issuing authority configuration unit 730 in fig. 11 are combined together to constitute the issuing authority configuration device 73 for configuration and adjustment of the vehicle occupant code issuing authority.

The server 1 according to the embodiment of the present disclosure is described below with reference to fig. 13. The server 1 shown in fig. 8 is only an example, and should not impose any limitation on the functions and the scope of use of the embodiment of the present invention.

As shown in fig. 13, the server 1 is in the form of a general purpose computing device. The components of the server 1 may include, but are not limited to: at least one processing unit 810, at least one memory unit 820, a bus 830 that connects the different system components, including the memory unit 820 and the processing unit 810.

The storage unit stores program code executable by the processing unit 810 such that the processing unit 810 performs the steps according to various exemplary embodiments of the present invention described in the description section of the exemplary method described above in the present specification, specifically, a vehicle ride code issuing authority configuration method including:

Optionally, the vehicle ride code issuing authority includes: an indication of whether or not to permit issuance of an offline certificate to the user for offline generation of the vehicle ride code by the user terminal. After configuring the vehicle ride code to issue the authority, the method further includes: and responding to the offline certificate issuing request of the user, and determining whether to issue the offline certificate according to the indication of whether to allow the offline certificate to be issued to the user.

Optionally, the vehicle ride code issuing authority includes: the validity duration of the offline certificate. After configuring the vehicle ride code to issue the authority, the method further includes: and responding to an off-line certificate issuing request of the user, and issuing the off-line certificate with the effective duration according to the effective duration.

Optionally, the vehicle ride code issuing authority includes: the offline certificate is used by the user terminal to generate a maximum number of vehicle ride codes. After configuring the vehicle ride code to issue the authority, the method further includes: and responding to the offline certificate issuing request of the user, and issuing the offline certificates which can be used by the user terminal for the maximum number of times.

Optionally, the vehicle ride code issuing authority includes: an indication of whether an off-line ride code is allowed to be issued to an on-line user for use by the user in an off-line state with a ride vehicle. After configuring the vehicle ride code to issue the authority, the method further includes: and responding to an offline riding code issuing request of the online user, and determining whether to issue the offline riding code to the user according to the indication of whether to allow the online user to issue the offline riding code.

Optionally, the vehicle ride code issuing authority includes: the maximum number of offline ride codes issued to online users. After configuring the vehicle ride code to issue the authority, the method further includes: and responding to an offline riding code issuing request of an online user, and issuing offline riding codes to the user according to the maximum number.

Optionally, the obtaining user risk data based on the user attribute data and the historical payment data specifically includes:

determining a first score based on the user attribute data;

determining a second score based on the historical payment data;

and obtaining user risk data based on the first score and the second score.

Optionally, after obtaining user risk data based on the user attribute data and the historical payment data, the method includes:

and if the user risk data indicates that the user risk is higher than the risk threshold, adjusting the user risk data to indicate that the user risk is equal to or lower than the risk threshold after a preset time period from the acquisition of the user risk data.

Optionally, the configuring the vehicle riding code issuing authority based on the user risk data specifically includes:

Optionally, after configuring the vehicle ride code issuing authority based on the user risk data, the method includes:

Acquiring user risk data of a user;

The storage unit 820 may include readable media in the form of volatile storage units, such as Random Access Memory (RAM) 8201 and/or cache memory 8202, and may further include Read Only Memory (ROM) 8203.

Storage unit 820 may also include a program/utility 8204 having a set (at least one) of program modules 8205, such program modules 8205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of which may include an implementation of a network environment.

Bus 830 may be one or more of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The server 1 may also communicate with one or more external devices 700 (e.g., keyboard, pointing device, bluetooth device, etc.), one or more devices that enable a user to interact with the server 1, and/or any device (e.g., router, modem, etc.) that enables the server 1 to communicate with one or more other computing devices. Such communication may occur through an input/output (I/O) interface 650. Also, the server 1 may communicate with one or more networks such as a Local Area Network (LAN), a Wide Area Network (WAN) and/or a public network, such as the Internet, through a network adapter 860. As shown, network adapter 860 communicates with other modules of server 1 via bus 830. It should be appreciated that although not shown in the figures, the server 1 may be implemented using other hardware and/or software modules, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data backup storage systems, and the like.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, including several instructions to cause a computing device (may be a personal computer, a server, a terminal device, or a network device, etc.) to perform the method according to the embodiments of the present disclosure.

In an exemplary embodiment of the present disclosure, there is also provided a computer program medium having stored thereon computer readable instructions, which when executed by a processor of a computer, cause the computer to perform the method described in the method embodiment section above.

According to an embodiment of the present disclosure, there is also provided a program product for implementing the method in the above method embodiments, which may employ a portable compact disc read only memory (CD-ROM) and comprise program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium would include the following: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The computer readable signal medium may include a data signal propagated in baseband or as part of a carrier wave with readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of remote computing devices, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., connected via the Internet using an Internet service provider).

It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit in accordance with embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

Furthermore, although the steps of the methods in the present disclosure are depicted in a particular order in the drawings, this does not require or imply that the steps must be performed in that particular order or that all illustrated steps be performed in order to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step to perform, and/or one step decomposed into multiple steps to perform, etc.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, including several instructions to cause a computing device (may be a personal computer, a server, a mobile terminal, or a network device, etc.) to perform the method according to the embodiments of the present disclosure.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any adaptations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims

1. A vehicle ride code issuing authority configuration method, characterized by comprising:

acquiring user attribute data and historical payment data of a user riding a vehicle; the historical payment data includes historical payment data for a ride vehicle using an offline ride code;

configuring a vehicle riding code issuing authority based on the user risk data;

wherein, based on the user risk data, configuring the vehicle riding code to issue authority comprises:

determining a corresponding relation table of each gear and a corresponding user risk data interval according to the number of people corresponding to each gear and the statistical distribution of the user risk data of the users of the vehicle riding codes;

2. The method of claim 1, wherein the vehicle ride code issuing authority comprises: an indication of whether or not to permit issuance of an offline certificate to the user, the offline certificate being used by the user terminal to generate the vehicle ride code offline,

after configuring the vehicle ride code to issue the authority, the method further includes: and responding to the offline certificate issuing request of the user, and determining whether to issue the offline certificate according to the indication of whether to allow the offline certificate to be issued to the user.

3. The method of claim 1, wherein the vehicle ride code issuing authority comprises: the duration of validity of the off-line certificate,

after configuring the vehicle ride code to issue the authority, the method further includes: and responding to an off-line certificate issuing request of the user, and issuing the off-line certificate with the effective duration according to the effective duration.

4. The method of claim 1, wherein the vehicle ride code issuing authority comprises: the offline certificate is used by the user terminal to generate a maximum number of vehicle ride codes,

after configuring the vehicle ride code to issue the authority, the method further includes: and responding to the offline certificate issuing request of the user, and issuing the offline certificates which can be used by the user terminal for the maximum number of times.

5. The method of claim 1, wherein the vehicle ride code issuing authority comprises: an indication of whether an off-line ride code is allowed to be issued to an on-line user, the off-line ride code for use by the user in an off-line state with a ride vehicle,

after configuring the vehicle ride code to issue the authority, the method further includes: and responding to an offline riding code issuing request of the online user, and determining whether to issue the offline riding code to the user according to the indication of whether to allow the online user to issue the offline riding code.

6. The method of claim 1, wherein the vehicle ride code issuing authority comprises: the maximum number of offline ride codes issued to online users,

after configuring the vehicle ride code to issue the authority, the method further includes: and responding to an offline riding code issuing request of an online user, and issuing offline riding codes to the user according to the maximum number.

7. The method according to claim 1, wherein said obtaining user risk data based on said user attribute data and said historical payment data, comprises:

Determining a first score based on the user attribute data;

determining a second score based on the historical payment data;

and obtaining user risk data based on the first score and the second score.

8. The method of claim 1, wherein after obtaining user risk data based on the user attribute data and the historical payment data, the method comprises:

9. The method of claim 1, wherein after configuring a vehicle ride code issuance authority based on the user risk data, the method comprises:

acquiring user risk data of a user;

10. A vehicle ride code issuing authority configuration device, characterized by comprising:

The attribute and payment data acquisition unit is used for acquiring user attribute data and historical payment data of a user riding a vehicle; the historical payment data includes historical payment data for a ride vehicle using an offline ride code;

the issuing authority configuration unit is used for configuring the vehicle riding code issuing authority based on the user risk data;

11. The apparatus of claim 10, wherein the user risk data obtaining unit is further configured to:

determining a first score based on the user attribute data;

determining a second score based on the historical payment data;

and obtaining user risk data based on the first score and the second score.

12. The apparatus as recited in claim 10, further comprising:

and the user risk data degradation unit is used for adjusting the user risk data to indicate that the user risk is equal to or lower than the risk threshold after a preset time period from the acquisition of the user risk data if the user risk data indicates that the user risk is higher than the risk threshold.

13. A server, comprising:

a memory storing computer readable instructions;

a processor reading computer readable instructions stored in a memory to perform the method of any one of claims 1-9.

14. A computer program medium having stored thereon computer readable instructions which, when executed by a processor of a computer, cause the computer to perform the method of any of claims 1-9.