Card application management method and device, equipment and storage medium

Abstract

The application discloses a card application management method, device and equipment and a storage medium. The method comprises the following steps: a terminal generates a first message for updating a card application state identifier of a target smart card; and the first message is sent to the target smart card. In this way, the card application state identifier of the target smart card can be dynamically changed based on the first message. For example, in the case that the terminal carrying the smart card is lost, the card application state identifier of the smart card can be changed by the first message sent by another terminal, so that the terminal carrying the smart card can disable the related service of the card application on the smart card in the state of normal communication, without loss, and the security of the card application on the smart card is enhanced. In addition, the requirement of finding the lost terminal and the smart card through the network subsequently can also be met.

Description

Technical Field

[0001] This application relates to the field of smart cards, and more particularly to a method, apparatus, device, and storage medium for managing card applications. Background Technology

[0002] Smart cards (including UIM (User Identity Module) cards and SIM (Subscriber Identity Module) cards) are important physical identifiers of a user's mobile identity and a vital resource held by operators. A smart card (also known as a user identification module card) is an independent security carrier that can support security-related card applications, such as card shields (implementing the functionality of a USB security token on the card).

[0003] With the widespread use of smartphones and other smart terminals, user identification module cards often achieve multi-card functionality, such as replacing RMB, ID cards, work cards, access cards, transportation cards, car keys, and bank USB tokens. This helps users quickly make payments, check into hotels, and pass through airport security, thus meeting users' digital lifestyle needs in various scenarios including financial services, office work, and daily life. All of these business implementations involve the processing of card applications on smart cards. As card application services develop, smart cards will incorporate even more card applications.

[0004] However, if a user forgets their smart terminal with the smart card somewhere and it's uncertain whether it's lost, the card's applications are at risk of being misused. Users often need to call customer service (e.g., 10086) or go to a service center to report the smart card lost. A lost smart card loses its telecommunications function, making some of the aforementioned services unusable. However, services supporting offline transactions, such as work cards, digital RMB, and transportation cards, can still be used. This can cause users some financial loss and increase the difficulty of subsequently locating the smart terminal online. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, apparatus, device, and storage medium for managing card applications, aiming to improve the security of card applications.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] In a first aspect, embodiments of this application provide a card application management method applied to a terminal, the method comprising:

[0008] Generate a first message for updating the card application status identifier of the target smart card;

[0009] Send the first message to the target smart card.

[0010] In the above scheme, sending the first message to the target smart card includes:

[0011] The first message is sent to the first platform, and the first platform then sends the first message to the target smart card.

[0012] In the above scheme, the first message carries a first identifier indicating the target smart card and a second identifier indicating the card application status identifier to be updated.

[0013] In the above scheme, the first identifier is a mobile phone number, and the second identifier is a disabled service mode identifier or a normal service mode identifier.

[0014] In the above scheme, if the terminal is equipped with the target smart card, the method further includes:

[0015] In response to power-on or restart, a first event is sent to the target smart card to inform the terminal of its capability information;

[0016] Register a second event for sending a location status change message to the target smart card;

[0017] If a change in the network status of the terminal is detected, a location status change message is sent to the target smart card.

[0018] The location status change message carries a third identifier indicating whether the terminal is on the network.

[0019] Secondly, embodiments of this application provide a card application management method applied to a first platform, the method comprising:

[0020] The receiving terminal sends a first message for updating the card application status identifier of the target smart card;

[0021] Send the first message to the target smart card.

[0022] In the above scheme, the first message carries a first identifier indicating the target smart card and a second identifier indicating the card application status identifier to be updated.

[0023] In the above scheme, the first identifier is a mobile phone number, and the second identifier is a disabled service mode identifier or a normal service mode identifier.

[0024] The method in the above scheme further includes:

[0025] A risk control identifier is generated based on the historical communication data of the target smart card, and the risk control identifier is used to change the card application status identifier of the target smart card;

[0026] The risk control identifier is sent to the target smart card.

[0027] Thirdly, embodiments of this application provide a card application management method applied to smart cards, the method comprising:

[0028] The receiving terminal sends a first message, which is used to update the card application status identifier of the smart card;

[0029] The card application status identifier is updated based on the first message.

[0030] In the above scheme, updating the card application status identifier based on the first message includes:

[0031] If the first message carries a disabled service mode identifier, then the card application status identifier is updated to the disabled service mode identifier; or,

[0032] If the first message carries a normal service mode identifier, then the card application status identifier is updated to the normal service mode identifier.

[0033] The method in the above scheme further includes:

[0034] A first event sent by the receiving terminal to inform the terminal of its capabilities;

[0035] Register a second event with the terminal for sending a location status change message to the smart card;

[0036] The card application status identifier is updated based on the location status change message sent by the terminal.

[0037] In the above scheme, the location status change message carries a third identifier indicating whether the terminal is on the network, and updating the card application status identifier based on the location status change message sent by the terminal includes:

[0038] If the terminal is determined to be in a first offline state based on the third identifier, then the card application status identifier is updated to the authentication service mode identifier; or...

[0039] If the terminal is determined to be in the second state of being online based on the third identifier, the card application status identifier is updated to the normal service mode identifier.

[0040] In the above scheme, before updating the card application status identifier based on the location status change message sent by the terminal, the method further includes:

[0041] If the current card application status identifier is a prohibited service mode identifier, then skip updating the card application status identifier based on the location status change message sent by the terminal.

[0042] The method in the above scheme further includes:

[0043] Receive a risk control identifier sent by the first platform, the risk control identifier being used to update the card application status identifier of the smart card;

[0044] The card application status identifier is updated based on the risk control identifier.

[0045] In the above scheme, before updating the card application status identifier based on the risk control identifier, the method further includes:

[0046] If it is determined that the smart card has been updated to a prohibited service mode or an authenticated service mode based on the first message or a location status change message sent by the terminal, then the step of updating the card application status identifier based on the risk control identifier is skipped.

[0047] The method in the above scheme further includes:

[0048] In response to a business request, obtain the card application status identifier;

[0049] The service request is responded to based on the card application status identifier.

[0050] In the above scheme, responding to the service request based on the card application status identifier includes:

[0051] If the card application status identifier is a normal service mode identifier, then the service corresponding to the service request is provided; or,

[0052] If the card application status identifier is a service-prohibited mode identifier, then the service corresponding to the service request is rejected; or,

[0053] If the card application status identifier is an authentication service mode identifier, then the identity authentication process is initiated, and after successful identity authentication, the service corresponding to the business request is provided.

[0054] Fourthly, embodiments of this application provide a card application management device applied to a terminal, the management device comprising:

[0055] The generation module is used to generate a first message for updating the card application status identifier of the target smart card;

[0056] The first sending module is used to send the first message to the target smart card.

[0057] Fifthly, embodiments of this application provide a card application management device applied to a first platform, the management device comprising:

[0058] The first receiving module is used to receive a first message sent by the terminal for updating the card application status identifier of the target smart card;

[0059] The second sending module is used to send the first message to the target smart card.

[0060] Sixthly, embodiments of this application provide a card application management device for smart cards, the management device comprising:

[0061] The second receiving module is used to receive a first message sent by the terminal, the first message being used to update the card application status identifier of the smart card;

[0062] The identifier update module is used to update the card application status identifier based on the first message.

[0063] In a seventh aspect, embodiments of this application provide a terminal, including: a processor and a memory for storing a computer program capable of running on the processor, wherein the processor, when running the computer program, executes the steps of the method described in the first aspect of embodiments of this application.

[0064] Eighthly, embodiments of this application provide a first platform, including: a processor and a memory for storing a computer program capable of running on the processor, wherein the processor, when running the computer program, executes the steps of the method described in the second aspect of embodiments of this application.

[0065] Ninthly, embodiments of this application provide a smart card, including: a processor and a memory for storing a computer program capable of running on the processor, wherein the processor, when running the computer program, performs the steps of the method described in the third aspect of embodiments of this application.

[0066] In a tenth aspect, embodiments of this application provide a computer storage medium storing a computer program, which, when executed by a processor, implements the steps of any of the methods described in embodiments of this application.

[0067] The technical solution provided in this application embodiment involves a terminal generating a first message for updating the card application status identifier of a target smart card; and sending the first message to the target smart card. Thus, the card application status identifier of the target smart card can be dynamically changed based on the first message. For example, in a scenario where the terminal carrying the smart card is lost, the card application status identifier of the smart card can be changed via a first message sent by another terminal. This allows the terminal carrying the smart card to disable the relevant services of the card application on the smart card while in normal communication mode, without needing to report the card lost, thus enhancing the security of the card application on the smart card. Furthermore, it also meets the subsequent need to locate the lost terminal and smart card via the network. Attached Figure Description

[0068] Figure 1This is a flowchart illustrating a card application management method according to an embodiment of this application;

[0069] Figure 2 This is a flowchart illustrating a card application management method according to another embodiment of this application;

[0070] Figure 3 This is a flowchart illustrating a card application management method according to another embodiment of this application;

[0071] Figure 4 This is a schematic diagram of card application state transition in the application embodiments of this application;

[0072] Figure 5 This is a schematic diagram illustrating the process of changing the card application status to a service-disabled state based on user annotation in the application embodiments of this application;

[0073] Figure 6 This is a schematic diagram illustrating the process of changing the SIM card application state based on the location state of the terminal with the SIM card installed in the application embodiment of this application;

[0074] Figure 7 This is a schematic diagram illustrating the process of changing the card application status based on the risk control identifier of the business platform in the application embodiment of this application;

[0075] Figure 8 This is a schematic diagram illustrating the process of a SIM card responding to a service request based on a card application status identifier in an application embodiment of this application.

[0076] Figure 9 This is a schematic diagram of the structure of a card application management device according to an embodiment of this application;

[0077] Figure 10 This is a schematic diagram of the structure of a card application management device according to another embodiment of this application;

[0078] Figure 11 This is a schematic diagram of the structure of a card application management device according to another embodiment of this application;

[0079] Figure 12 A schematic diagram of the terminal structure in an embodiment of this application;

[0080] Figure 13 This is a schematic diagram of the structure of the first platform in the embodiment of this application;

[0081] Figure 14 This is a schematic diagram of the structure of a smart card according to an embodiment of this application. Detailed Implementation

[0082] The present application will now be described in further detail with reference to the accompanying drawings and embodiments.

[0083] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0084] This application provides a card application management method applied to a terminal. The terminal can be a first terminal that carries a target smart card, or a second terminal that does not carry the target smart card. Here, the terminal can be an electronic device such as a smartphone, smart bracelet, smartwatch, or wearable device. The smart card can be a UIM card or a SIM card carrying the card application. Figure 1 As shown, the management method includes:

[0085] Step 101: Generate a first message for updating the card application status identifier of the target smart card.

[0086] Here, the card application status identifier can be understood as an identifier used by the target smart card to determine whether it can launch the card application service. For example, the card application status identifier includes at least: a disabled service mode identifier and a normal service mode identifier, wherein the disabled service mode identifier indicates that the target smart card is in a state where the card application is prohibited from providing services, and the normal service mode identifier indicates that the target smart card is in a state where the card application is providing services normally.

[0087] For example, the terminal may have a pre-installed APP (application) for generating the first message. After logging into the APP, the user can generate the first message as needed. For example, when it is necessary to disable the card application on the target smart card, a first message can be generated to update the card application status identifier of the target smart card to the disabled service mode identifier; when it is necessary to start the card application on the target smart card normally, a first message can be generated to update the card application status identifier of the target smart card to the normal service mode identifier.

[0088] Step 102: Send the first message to the target smart card.

[0089] Here, after the terminal sends the first message to the target smart card, the target smart card can update the card application status identifier stored locally based on the received first message.

[0090] For example, if the terminal is a first terminal that carries the target smart card, the first terminal can send a first message to the target smart card via a communication line connected to the target smart card. In this way, the user can locally change the card application status identifier of the target smart card on the first terminal, thereby allowing them to independently change the service status of the card application as needed.

[0091] For example, if the terminal is a second terminal that does not have the target smart card installed, sending the first message to the target smart card includes:

[0092] The first message is sent to the first platform, and the first platform then sends the first message to the target smart card.

[0093] In this way, users can remotely change the card application status identifier of the target smart card on the first terminal based on the second terminal. Thus, in the scenario where the first terminal carrying the target smart card is lost, the card application status identifier of the target smart card can be changed through the first message sent by the second terminal. This allows the first terminal to disable the relevant services of the card application on the target smart card while in normal communication mode, without the need to report the loss, thus enhancing the security of the card application on the smart card. In addition, it can also meet the need to find the lost first terminal and target smart card through the network later.

[0094] Here, the first platform can be a communication-related business platform. The first platform can send the first message to the target smart card through an SMS gateway or a BIP (Bearer Independent Protocol) gateway.

[0095] For example, the first message carries a first identifier indicating the target smart card and a second identifier representing the card application status identifier to be updated. Thus, the smart card can determine whether the first message matches itself based on the first identifier and update the card application status identifier based on the second identifier.

[0096] For example, the first identifier is a mobile phone number, and the second identifier is a disabled service mode identifier or a normal service mode identifier. For instance, the normal service mode identifier is 0, and the disabled service mode identifier is 1.

[0097] In some embodiments, if the terminal is equipped with the target smart card, the method further includes:

[0098] In response to power-on or restart, a first event is sent to the target smart card to inform the terminal of its capability information;

[0099] Register a second event for sending a location status change message to the target smart card;

[0100] If a change in the network status of the terminal is detected, a location status change message is sent to the target smart card.

[0101] The location status change message carries a third identifier indicating whether the terminal is on the network.

[0102] It is understandable that if the terminal is the first terminal with the target smart card installed, the first terminal can also send a location status change message to the target smart card. The target smart card can update the card application status identifier based on the third identifier carried in the location status change message that indicates whether the terminal is on the network. This enables the card application service status of the target smart card to be intelligently changed based on whether the terminal is on the network, thereby further improving the security of the card application on the target smart card.

[0103] For example, when the first terminal powers on or restarts, it sends a TerminalProfile event to the target smart card. After receiving the TerminalProfile event, the target smart card registers a LocationStatus Change Event with the first terminal. After registering the LocationStatus Change Event, if the first terminal experiences a network status change (e.g., going offline or switching to airplane mode), the first terminal will send a LocationStatus Change Event to the target smart card, thereby informing the target smart card of the location status change message. This location status change message carries a third identifier that indicates whether the terminal is on the network.

[0104] This application also provides a card application management method, applied to a first platform, such as... Figure 2 As shown, the management method includes:

[0105] Step 201: Receive a first message from the terminal for updating the card application status identifier of the target smart card.

[0106] Step 202: Send the first message to the target smart card.

[0107] Here, the first platform can be a communication-related business platform, which can send the first message to the target smart card through an SMS gateway or a BIP gateway.

[0108] For example, the first message carries a first identifier indicating the target smart card and a second identifier indicating the card application status identifier to be updated.

[0109] For example, the first identifier is a mobile phone number, and the second identifier is a disabled service mode identifier or a normal service mode identifier.

[0110] In some embodiments, the management method further includes:

[0111] A risk control identifier is generated based on the historical communication data of the target smart card, and the risk control identifier is used to change the card application status identifier of the target smart card;

[0112] The risk control identifier is sent to the target smart card.

[0113] For example, the first platform can determine the risk level of a user's mobile phone number based on the user's historical communication data, such as the frequency of receiving spam text messages and spam calls. If the risk level is high, a risk control identifier is generated to update the card application status identifier to a disabled service mode identifier; if the risk level is medium, a risk control identifier is generated to update the card application status identifier to an authenticated service mode identifier; and if the risk level is low, a risk control identifier is generated to update the card application status identifier to a normal service mode identifier. In this way, the target smart card can automatically update its local card application status identifier based on the received risk control identifier.

[0114] This application provides a card application management method, applied to smart cards, such as... Figure 3 As shown, the management method includes:

[0115] Step 301: Receive a first message sent by the terminal, the first message being used to update the card application status identifier of the smart card.

[0116] Step 302: Update the card application status identifier based on the first message.

[0117] Here, the card application status identifier can be understood as an identifier used by the smart card to determine whether it can launch the card application service. For example, the card application status identifier includes at least: a disabled service mode identifier and a normal service mode identifier, wherein the disabled service mode identifier indicates that the target smart card is in a state where the card application is prohibited from providing services, and the normal service mode identifier indicates that the target smart card is in a state where the card application is providing services normally.

[0118] For example, updating the card application status identifier based on the first message includes:

[0119] If the first message carries a disabled service mode identifier, then the card application status identifier is updated to the disabled service mode identifier; or,

[0120] If the first message carries a normal service mode identifier, then the card application status identifier is updated to the normal service mode identifier.

[0121] Exemplarily, the method further includes:

[0122] A first event sent by the receiving terminal to inform the terminal of its capabilities;

[0123] Register a second event with the terminal for sending a location status change message to the smart card;

[0124] The card application status identifier is updated based on the location status change message sent by the terminal.

[0125] It should be noted that the terminal is the terminal that has the smart card installed. For example, when the terminal powers on or restarts, it sends a Terminal Profile event to the smart card. After receiving the Terminal Profile event, the smart card registers a Location Status Change Event with the terminal. After registering the Location Status Change Event, if the terminal experiences a network status change (e.g., going offline or switching to airplane mode), the terminal will send a Location Status Change Event to the smart card, thereby informing the smart card of the location status change message. This location status change message carries a third identifier indicating whether the terminal is on the network.

[0126] For example, updating the card application status identifier based on the location status change message sent by the terminal includes:

[0127] If the terminal is determined to be in a first offline state based on the third identifier, then the card application status identifier is updated to the authentication service mode identifier; or...

[0128] If the terminal is determined to be in the second state of being online based on the third identifier, the card application status identifier is updated to the normal service mode identifier.

[0129] For example, before updating the card application status identifier based on the location status change message sent by the terminal, the method further includes:

[0130] If the current card application status identifier is a prohibited service mode identifier, then skip updating the card application status identifier based on the location status change message sent by the terminal.

[0131] It should be noted that if the smart card has already been marked as service prohibited by the user before the card application status identifier is updated based on the location status change message, then the mode identified by the user will be given priority. That is, the mode identified by the user has higher priority than the mode corresponding to the location status change message.

[0132] It should be noted that the smart card will change the card application status identifier to the normal service mode identifier based on the location status change message, provided that the smart card determines that the card application status identifier is the authentication service mode identifier and determines that the terminal has been restored to the second state of being online based on the third identifier carried in the received location status change message. Thus, after the terminal is restored to being online, the card application status identifier will be switched to the normal service mode identifier.

[0133] For example, the management method further includes:

[0134] Receive a risk control identifier sent by the first platform, the risk control identifier being used to update the card application status identifier of the smart card;

[0135] The card application status identifier is updated based on the risk control identifier.

[0136] It should be noted that the risk control identifier is generated by the first platform based on the user's historical communication data. Specifically, it can be generated based on the risk level of the user's mobile phone number. For example, if the risk level is high, a risk control identifier is generated to update the card application status identifier to the disabled service mode identifier; if the risk level is medium, a risk control identifier is generated to update the card application status identifier to the authenticated service mode identifier; and if the risk level is low, a risk control identifier is generated to update the card application status identifier to the normal service mode identifier.

[0137] For example, when a smart card updates its card application status identifier based on a risk control identifier, the disabled service mode identifier in the risk control identifier can be distinguished from the manually labeled disabled service mode identifier, and the authentication service mode identifier in the risk control identifier can be distinguished from the authentication service mode identifier determined by the terminal's location status change information. For example, in one application example, the identifiers of the card application status identifier are as follows: the normal service mode identifier is 0, the disabled service mode identifier is 1, the authentication service mode identifier is 2, the disabled service mode identifier corresponding to the risk control identifier is 3, and the authentication service mode identifier corresponding to the risk control identifier is 4.

[0138] For example, before updating the card application status identifier based on the risk control identifier, the method further includes:

[0139] If it is determined that the smart card has been updated to a prohibited service mode or an authenticated service mode based on the first message or a location status change message sent by the terminal, then the step of updating the card application status identifier based on the risk control identifier is skipped.

[0140] Understandably, when a smart card changes its card application status identifier, the first message takes precedence over the terminal location status change message, and the terminal location status change message takes precedence over the risk control identifier. This allows the smart card to prioritize service modes manually selected by the user or those corresponding to changes in the terminal's location status, thus enhancing the security of smart card applications.

[0141] For example, the management method further includes:

[0142] In response to a business request, obtain the card application status identifier;

[0143] The service request is responded to based on the card application status identifier.

[0144] Understandably, smart cards respond to service requests based on card application status identifiers, thereby improving the security of card applications.

[0145] For example, responding to the service request based on the card application status identifier includes:

[0146] If the card application status identifier is a normal service mode identifier, then the service corresponding to the service request is provided; or,

[0147] If the card application status identifier is a service-prohibited mode identifier, then the service corresponding to the service request is rejected; or,

[0148] If the card application status identifier is an authentication service mode identifier, then the identity authentication process is initiated, and after successful identity authentication, the service corresponding to the business request is provided.

[0149] The present application will be further described in detail below with reference to application examples.

[0150] In this application embodiment, the smart card is a SIM card as an example. The card application state transition diagram is as follows: Figure 4 As shown. It should be noted that when the smart card's application status is "service prohibited" (i.e., the card application status identifier is the "service prohibited" mode identifier), the smart card's application status cannot be switched to "authentication service". When the card application status is "authentication service" (i.e., the card application status identifier is the authentication service mode identifier determined by the terminal network status or the authentication service mode determined by business risk control), it can be changed to "service prohibited" by the user.

[0151] Figure 5 This illustration shows a flowchart of the process in this application embodiment where the card application status is changed to "service prohibited" based on user annotation. Figure 5 As shown, the change process includes:

[0152] Step 501: The user logs in to the APP.

[0153] This app is pre-installed on the terminal and is used to change the card application status identifier. Users can log in to the app through authentication and other methods.

[0154] Step 502: The user marks the application on the SIM card as a disabled service.

[0155] Here, the APP marks the application status of the SIM card corresponding to the mobile phone number as disabled.

[0156] Step 503: Send a card application status identifier request.

[0157] Here, the terminal can generate and send the aforementioned first message (i.e., application status identifier request) to the service platform. This first message carries the mobile phone number and the card application status identifier to be updated.

[0158] Step 504: Send a card application status identifier request.

[0159] Here, after receiving the first message from the terminal, the service platform sends the first message to the SIM through the SMS gateway or BIP gateway.

[0160] Step 505: Set the card application status identifier.

[0161] Here, the SIM card changes the locally stored card application status identifier based on the first received message. For example, the card application identifier is 0: normal service; 1: disabled service; 2: authentication service.

[0162] Step 506: Return card application status identifier response.

[0163] Here, the SIM card reports the card application status identifier result to the service platform through the SMS gateway or BIP gateway.

[0164] Step 507: Return card application status indicator response.

[0165] Here, the business platform returns the identification result to the user's APP.

[0166] It should be noted that, based on a similar process, users can set the card application to a normal service state; the specific process will not be elaborated here.

[0167] Figure 6 This illustration shows a flowchart illustrating how the SIM card application state changes based on the location state of the terminal with the SIM card installed, as shown in this application embodiment. Figure 6 As shown, the change process includes:

[0168] Step 601: The terminal sends a Terminal Profile event.

[0169] When a user terminal is powered on or restarted, the terminal sends a Terminal Profile event to the SIM card.

[0170] Step 602: Register the Location Status Change Event.

[0171] After receiving the Terminal Profile event, the SIM card registers a Location Status ChangeEvent with the terminal.

[0172] Step 603: Send a Location Status Change Event and return the terminal location status.

[0173] After the SIM card registers the Location Status Change Event with the terminal, if the terminal goes offline or enters airplane mode, it will send the Location Status Change Event to the SIM card and return the terminal's location status.

[0174] Step 604: When the card application status is a non-prohibited service status, it is marked as an authentication service status.

[0175] Based on the location status sent by the terminal, the SIM card determines that the terminal is not on the network (i.e., offline or in airplane mode) and the card application status is in a non-prohibited service state. Then, it changes the card application status identifier to the authentication service mode identifier.

[0176] When the terminal network returns to normal, the method also includes:

[0177] Step 605: Send a Location Status Change Event to return the terminal location status.

[0178] When the terminal network returns to normal, it will send a Location Status Change Event to the SIM card again and return the terminal's location status. The SIM card then uses the terminal's location status to indicate that the card application is in a normal service state.

[0179] Step 606: When the card application status is a non-prohibited service status, it is marked as an authentication service status.

[0180] Based on the location status sent by the terminal, the SIM card determines that the terminal has returned to the network (i.e., offline or in airplane mode) and the card application status is in a non-prohibited service state. Then, the card application status identifier is changed to a normal service mode identifier.

[0181] It should be noted that if the SIM card's application status has been marked as disabled by the user, the SIM card will not change the application status identifier based on the terminal's location status; that is, the service mode requirements marked by the user will be prioritized.

[0182] Figure 7 This illustration shows a flowchart illustrating how the card application status is changed based on the risk control identifier of the business platform in this application embodiment. For example... Figure 7 As shown, the change process includes:

[0183] Step 701: Generate risk control identifier.

[0184] Here, the business platform generates risk control identifiers based on the user's historical communication data. Specifically, risk control identifiers can be generated based on the risk level of the user's mobile phone number. For example, if the risk level is high, a risk control identifier is generated to update the card application status identifier to the disabled service mode identifier; if the risk level is medium, a risk control identifier is generated to update the card application status identifier to the authenticated service mode identifier; and if the risk level is low, a risk control identifier is generated to update the card application status identifier to the normal service mode identifier.

[0185] Step 702: Send a card application status identifier request.

[0186] Here, the business platform sends a card application status identifier request (i.e., risk control identifier) ​​to the SIM card through an SMS gateway or a BIP gateway. For example, the card application status identifier request carries the mobile phone number and the card application status identifier to be updated.

[0187] Step 703: Set the card application status identifier.

[0188] Here, the SIM card determines and updates the card application status identifier based on the current status. If the user has already identified the application status, the service status remains unchanged. If the user has not identified the application status, the card application status identifier is set. For example, card application identifier 0: normal service; 1: service prohibited; 2: authentication service; 3: risk control identifier: service prohibited; 4: risk control identifier: authentication service.

[0189] Step 704, return card application status indicator response.

[0190] Here, the SIM card reports the card application status identifier result to the service platform through the SMS gateway or BIP gateway.

[0191] It should be noted that when marking the card application status of a SIM card, the user identifier (i.e., the aforementioned first message) takes precedence over the risk control identifier.

[0192] Figure 8 This illustration shows a flowchart of how the SIM card responds to service requests based on the card application status identifier in this application embodiment. For example... Figure 8 As shown, the process includes:

[0193] Step 801: The user initiates a business transaction.

[0194] Users can initiate business transactions related to the card applications on their SIM cards.

[0195] Step 802: Initiate a service request to the SIM card.

[0196] Here, the terminal can initiate service requests to the SIM card through methods such as data SMS, BIP channel, local SIM card interface, and near-field communication.

[0197] Step 803: Obtain the card application status identifier.

[0198] In response to a service request, the SIM card retrieves the card application status identifier from the card application status identifier storage module.

[0199] Step 804: Return to card application status identifier.

[0200] The card application status identifier storage module returns the card application status identifier to the business card application.

[0201] Step 805: Determine the card service status identifier.

[0202] The service card application determines whether to provide service or require user authentication based on the card application status identifier. Specifically, if the card application status identifier is a normal service mode identifier, the service corresponding to the service request is provided; or, if the card application status identifier is a prohibited service mode identifier, the service corresponding to the service request is rejected; or, if the card application status identifier is an authentication service mode identifier, an identity authentication process is initiated, and the service corresponding to the service request is provided after successful identity authentication.

[0203] Step 806: Return the business response.

[0204] The SIM card returns a service response based on the card application status.

[0205] In order to implement the method of the embodiments of this application, the embodiments of this application also provide a card application management device, which is applied to a terminal. The card application management device corresponds to the above-mentioned terminal-side management method, and the steps in the above-mentioned terminal-side management method embodiments are also fully applicable to the card application management device embodiments.

[0206] like Figure 9 As shown, the card application management device includes a generation module 901 and a first sending module 902. The generation module 901 is used to generate a first message for updating the card application status identifier of the target smart card; the first sending module 902 is used to send the first message to the target smart card.

[0207] In some embodiments, the first sending module 902 is specifically used for:

[0208] The first message is sent to the first platform, and the first platform then sends the first message to the target smart card.

[0209] In some embodiments, the first message carries a first identifier indicating the target smart card and a second identifier indicating the card application status identifier to be updated.

[0210] In some embodiments, the first identifier is a mobile phone number, and the second identifier is a disabled service mode identifier or a normal service mode identifier.

[0211] In some embodiments, if the terminal is equipped with the target smart card, the first sending module 902 is further configured to: in response to power-on or restart, send a first event to the target smart card to inform the terminal of its capability information; the card application management device further includes: a registration module 903, configured to register a second event for sending a location status change message to the target smart card; the first sending module 902 is further configured to determine if the network status of the terminal has changed, and then send the location status change message to the target smart card; wherein the location status change message carries a third identifier indicating whether the terminal is on the network.

[0212] In practical applications, the generation module 901, the first sending module 902, and the registration module 903 can be implemented by the processor in the card application's management device. Of course, the processor needs to run the computer program in the memory to implement its functions.

[0213] In order to implement the method of the embodiments of this application, the embodiments of this application also provide a card application management device, which is applied to a first platform. The card application management device corresponds to the management method on the first platform side described above, and the steps in the management method embodiment on the first platform side are also fully applicable to the card application management device embodiment.

[0214] like Figure 10 As shown, the card application management device includes a first receiving module 1001 and a second sending module 1002. The first receiving module 1001 is used to receive a first message sent by the terminal for updating the card application status identifier of the target smart card; the second sending module 1002 is used to send the first message to the target smart card.

[0215] In some embodiments, the first message carries a first identifier indicating the target smart card and a second identifier indicating the card application status identifier to be updated.

[0216] In some embodiments, the first identifier is a mobile phone number, and the second identifier is a disabled service mode identifier or a normal service mode identifier.

[0217] In some embodiments, the card application management device further includes: a risk control module 1003, used to generate a risk control identifier based on the historical communication data of the target smart card, the risk control identifier being used to change the card application status identifier of the target smart card; and a second sending module 1002, used to send the risk control identifier to the target smart card.

[0218] In practical applications, the first receiving module 1001, the second sending module 1002, and the risk control module 1003 can be implemented by the processor in the card application management device. Of course, the processor needs to run the computer program in the memory to implement its functions.

[0219] In order to implement the method of the embodiments of this application, the embodiments of this application also provide a card application management device, which is applied to a smart card. The card application management device corresponds to the smart card-side management method described above, and the steps in the smart card-side management method embodiments are also fully applicable to the card application management device embodiments.

[0220] like Figure 11 As shown, the card application management device includes a second receiving module 1101 and an identifier update module 1102. The second receiving module 1101 is used to receive a first message sent by the terminal, the first message being used to update the card application status identifier of the smart card; the identifier update module 1102 is used to update the card application status identifier based on the first message.

[0221] In some embodiments, the identifier update module 1102 is specifically used for:

[0222] If the first message carries a disabled service mode identifier, then the card application status identifier is updated to the disabled service mode identifier; or,

[0223] If the first message carries a normal service mode identifier, then the card application status identifier is updated to the normal service mode identifier.

[0224] In some embodiments, the second receiving module 1101 is further configured to receive a first event sent by the terminal to inform the terminal of capability information; the card application management device further includes: a third sending module 1103, configured to register with the terminal a second event for sending a location status change message to the smart card; the identifier update module 1102 is further configured to update the card application status identifier based on the location status change message sent by the terminal.

[0225] In some embodiments, the location status change message carries a third identifier indicating whether the terminal is on the network, and updating the card application status identifier based on the location status change message sent by the terminal includes:

[0226] If the terminal is determined to be in a first offline state based on the third identifier, then the card application status identifier is updated to the authentication service mode identifier; or...

[0227] If the terminal is determined to be in the second state of being online based on the third identifier, the card application status identifier is updated to the normal service mode identifier.

[0228] In some embodiments, before updating the card application status identifier based on the location status change message sent by the terminal, the identifier update module 1102 is further configured to: if the current card application status identifier is a prohibited service mode identifier, skip updating the card application status identifier based on the location status change message sent by the terminal.

[0229] In some embodiments, the second receiving module 1101 is further configured to receive a risk control identifier sent by the first platform, the risk control identifier being used to update the card application status identifier of the smart card; the identifier updating module 1102 is further configured to update the card application status identifier based on the risk control identifier.

[0230] In some embodiments, before updating the card application status identifier based on the risk control identifier, the identifier update module 1102 is further configured to:

[0231] If it is determined that the smart card has been updated to a prohibited service mode or an authenticated service mode based on the first message or a location status change message sent by the terminal, then the step of updating the card application status identifier based on the risk control identifier is skipped.

[0232] In some embodiments, the card application management device further includes: a service processing module 1104, configured to obtain the card application status identifier in response to a service request; and to respond to the service request based on the card application status identifier.

[0233] In some embodiments, responding to the service request based on the card application status identifier includes:

[0234] If the card application status identifier is a normal service mode identifier, then the service corresponding to the service request is provided; or,

[0235] If the card application status identifier is a service-prohibited mode identifier, then the service corresponding to the service request is rejected; or,

[0236] If the card application status identifier is an authentication service mode identifier, then the identity authentication process is initiated, and after successful identity authentication, the service corresponding to the business request is provided.

[0237] In practical applications, the second receiving module 1101, the identifier update module 1102, the third sending module 1103, and the service processing module 1104 can be implemented by the processor in the card application's management device. Of course, the processor needs to run the computer program in the memory to implement its functions.

[0238] It should be noted that the card application management device provided in the above embodiments is only illustrated by the division of the above program modules when managing card applications. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program modules to complete all or part of the processing described above. In addition, the card application management device and the card application management method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0239] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide a terminal. Figure 12 This is merely an exemplary structure of the terminal, not the entire structure; implementation is possible as needed. Figure 12 The structure shown may be part or all of the structure.

[0240] like Figure 12 As shown, the terminal 1200 provided in this embodiment includes at least one processor 1201, a memory 1202, a user interface 1203, and at least one network interface 1204. The various components in the terminal 1200 are coupled together via a bus system 1205. It can be understood that the bus system 1205 is used to implement communication between these components. In addition to a data bus, the bus system 1205 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 12 The general labeled all buses as Bus System 1205.

[0241] The user interface 1203 may include a monitor, keyboard, mouse, trackball, click wheel, buttons, touchpad, or touch screen.

[0242] The memory 1202 in this embodiment is used to store various types of data to support the operation of the terminal. Examples of such data include any computer program used to operate on the terminal.

[0243] The card application management method disclosed in this application embodiment can be applied to, or implemented by, processor 1201. Processor 1201 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the card application management method can be completed by the integrated logic circuitry in the hardware of processor 1201 or by instructions in software form. The processor 1201 can be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 1201 can implement or execute the methods, steps, and logic block diagrams disclosed in this application embodiment. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application embodiment can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can be located in a storage medium, specifically memory 1202. Processor 1201 reads information from memory 1202 and, in conjunction with its hardware, completes the steps of the card application management method provided in this application embodiment.

[0244] In an exemplary embodiment, the terminal may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0245] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide a first platform. Figure 13 This is merely an exemplary structure of the first platform, not the entire structure; implementation is possible as needed. Figure 13 The structure shown may be part or all of the structure.

[0246] like Figure 13As shown, the first platform 1300 provided in this embodiment includes at least one processor 1301, a memory 1302, a user interface 1303, and at least one network interface 1304. The various components in the first platform 1300 are coupled together via a bus system 1305. It can be understood that the bus system 1305 is used to implement communication between these components. In addition to a data bus, the bus system 1305 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 13 The general designated all buses as Bus System 1305.

[0247] The user interface 1303 may include a monitor, keyboard, mouse, trackball, click wheel, buttons, touchpad, or touch screen.

[0248] The memory 1302 in this embodiment is used to store various types of data to support the operation of the first platform. Examples of such data include any computer program used to operate on the first platform.

[0249] The card application management method disclosed in this application embodiment can be applied to, or implemented by, processor 1301. Processor 1301 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the card application management method can be completed by the integrated logic circuitry in the hardware of processor 1301 or by instructions in software form. The processor 1301 can be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 1301 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can be located in a storage medium, specifically memory 1302. Processor 1301 reads information from memory 1302 and, in conjunction with its hardware, completes the steps of the card application management method provided in the embodiments of this application.

[0250] In an exemplary embodiment, the first platform 1300 may be implemented by one or more ASICs, DSPs, PLDs, CPLDs, FPGAs, general-purpose processors, controllers, MCUs, microprocessors, or other electronic components to perform the aforementioned method.

[0251] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide a smart card. Figure 14 This is only an exemplary structure of the smart card, not the entire structure; it can be implemented as needed. Figure 14 The structure shown may be part or all of the structure.

[0252] like Figure 14 As shown, the smart card 1400 provided in this embodiment includes at least one processor 1401, a memory 1402, and at least one network interface 1403. The various components in the smart card 1400 are coupled together via a bus system 1404. It can be understood that the bus system 1404 is used to implement communication between these components. In addition to a data bus, the bus system 1404 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 14 The general designated all buses as Bus System 1404.

[0253] The memory 1402 in this embodiment is used to store various types of data to support the operation of the smart card. Examples of such data include any computer program used to operate on the smart card.

[0254] The card application management method disclosed in this application embodiment can be applied to, or implemented by, processor 1401. Processor 1401 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the card application management method can be completed by integrated logic circuits in the hardware of processor 1401 or by instructions in software form. The processor 1401 can be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 1401 can implement or execute the methods, steps, and logic block diagrams disclosed in this application embodiment. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application embodiment can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can be located in a storage medium, specifically memory 1402. Processor 1401 reads information from memory 1402 and, in conjunction with its hardware, completes the steps of the card application management method provided in this application embodiment.

[0255] It is understood that the aforementioned memories 1202, 1302, and 1402 can be volatile or non-volatile memories, or both. Specifically, non-volatile memories can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memories can be random access memory (RAM), used as external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0256] In exemplary embodiments, this application also provides a computer storage medium, specifically a computer-readable storage medium, such as a memory 1202 storing a computer program, which can be executed by a processor 1201 of a terminal to complete the steps described in the terminal-side method of this application embodiment; or a memory 1302 storing a computer program, which can be executed by a processor 1301 of a first platform to complete the steps described in the first platform-side method of this application embodiment; or a memory 1402 storing a computer program, which can be executed by a processor 1401 of a smart card to complete the steps described in the smart card-side method of this application embodiment. The computer-readable storage medium can be a ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM, etc.

[0257] It should be noted that terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0258] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0259] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for managing card applications, characterized in that, Applied to a terminal, the method includes: A first message is generated for updating a card application status identifier of a target smart card; the first message carries a first identifier indicating the target smart card and a second identifier indicating the card application status identifier to be updated; if the terminal does not have the target smart card installed, the terminal sends the first message to a first platform, and the first platform sends the first message to the target smart card; if the terminal has the target smart card installed, the terminal sends the first message to the target smart card via a communication line connected to the target smart card; the method further includes: In response to power-on or restart, a first event is sent to the target smart card to inform the terminal of its capability information; Register a second event for sending a location status change message to the target smart card; If a change in the network status of the terminal is detected, a location status change message is sent to the target smart card. The location status change message carries a third identifier indicating whether the terminal is on the network.

2. The method according to claim 1, characterized in that, The first identifier is a mobile phone number, and the second identifier is either a disabled service mode identifier or a normal service mode identifier.

3. A method for managing card applications, characterized in that, Applied to a first platform, the method includes: The receiving terminal sends a first message for updating the card application status identifier of the target smart card; the first message carries a first identifier indicating the target smart card and a second identifier indicating the card application status identifier to be updated; Send the first message to the target smart card; The method further includes: A risk control identifier is generated based on the historical communication data of the target smart card, and the risk control identifier is used to change the card application status identifier of the target smart card; The risk control identifier is sent to the target smart card.

4. The method according to claim 3, characterized in that, The first identifier is a mobile phone number, and the second identifier is either a disabled service mode identifier or a normal service mode identifier.

5. A method for managing card applications, characterized in that, Applied to smart cards, the method includes: The receiving terminal sends a first message, which is used to update the card application status identifier of the smart card; Update the card application status identifier based on the first message; The method further includes: A first event sent by the receiving terminal to inform the terminal of its capabilities; Register a second event with the terminal for sending a location status change message to the smart card; The card application status identifier is updated based on the location status change message sent by the terminal. The location status change message carries a third identifier indicating whether the terminal is on the network.

6. The method according to claim 5, characterized in that, The step of updating the card application status identifier based on the first message includes: If the first message carries a disabled service mode identifier, then the card application status identifier is updated to the disabled service mode identifier; or, If the first message carries a normal service mode identifier, then the card application status identifier is updated to the normal service mode identifier.

7. The method according to claim 5, characterized in that, The step of updating the card application status identifier based on the location status change message sent by the terminal includes: If the terminal is determined to be in a first offline state based on the third identifier, then the card application status identifier is updated to the authentication service mode identifier; or... If the terminal is determined to be in the second state of being online based on the third identifier, the card application status identifier is updated to the normal service mode identifier.

8. The method according to claim 7, characterized in that, Before updating the card application status identifier based on the location status change message sent by the terminal, the method further includes: If the current card application status identifier is a prohibited service mode identifier, then skip updating the card application status identifier based on the location status change message sent by the terminal.

9. The method according to claim 5, characterized in that, The method further includes: Receive a risk control identifier sent by the first platform, the risk control identifier being used to update the card application status identifier of the smart card; The card application status identifier is updated based on the risk control identifier.

10. The method according to claim 9, characterized in that, Before updating the card application status identifier based on the risk control identifier, the method further includes: If it is determined that the smart card has been updated to a prohibited service mode or an authenticated service mode based on the first message or a location status change message sent by the terminal, then the step of updating the card application status identifier based on the risk control identifier is skipped.

11. The method according to claim 5, characterized in that, The method further includes: In response to a business request, obtain the card application status identifier; The service request is responded to based on the card application status identifier.

12. The method according to claim 11, characterized in that, The step of responding to the service request based on the card application status identifier includes: If the card application status identifier is a normal service mode identifier, then the service corresponding to the service request is provided; or, If the card application status identifier is a service-prohibited mode identifier, then the service corresponding to the service request is rejected; or, If the card application status identifier is an authentication service mode identifier, then the identity authentication process is initiated, and after successful identity authentication, the service corresponding to the business request is provided.

13. A card application management device, characterized in that, The management device, applied to a terminal, includes: The generation module is used to generate a first message for updating the card application status identifier of the target smart card; the first message carries a first identifier indicating the target smart card and a second identifier indicating the card application status identifier to be updated; A first sending module is configured to, if the terminal is not equipped with the target smart card, send the first message to a first platform, and have the first platform send the first message to the target smart card; if the terminal is equipped with the target smart card, send the first message to the target smart card via a communication line connected to the target smart card; and, In response to power-on or restart, a first event is sent to the target smart card to inform the terminal of its capability information; Register a second event for sending a location status change message to the target smart card; If a change in the network status of the terminal is detected, a location status change message is sent to the target smart card. The location status change message carries a third identifier indicating whether the terminal is on the network.

14. A card application management device, characterized in that, The management device, applied to the first platform, includes: The first receiving module is configured to receive a first message sent by the terminal for updating the card application status identifier of the target smart card; the first message carries a first identifier indicating the target smart card and a second identifier indicating the card application status identifier to be updated; The second sending module is used to send the first message to the target smart card; The risk control module is used to generate a risk control identifier based on the historical communication data of the target smart card. The risk control identifier is used to change the card application status identifier of the target smart card. The second sending module is also used to: send the risk control identifier to the target smart card.

15. A card application management device, characterized in that, The management device, applied to smart cards, includes: The second receiving module is used to receive a first message sent by the terminal, the first message being used to update the card application status identifier of the smart card; The identifier update module is used to update the card application status identifier based on the first message; The second receiving module is further configured to: receive a first event sent by the terminal to inform the terminal of its capability information; The management device further includes a third sending module, which is used to: register a second event with the terminal for sending a location status change message to the smart card; The identifier update module is also used to: update the card application status identifier based on the location status change message sent by the terminal; The location status change message carries a third identifier indicating whether the terminal is on the network.

16. A terminal, characterized in that, include: A processor and memory for storing computer programs that can run on the processor, wherein, The processor, when running a computer program, performs the steps of the method according to any one of claims 1 to 2.

17. A first platform, characterized in that, include: A processor and memory for storing computer programs that can run on the processor, wherein, The processor, when running a computer program, performs the steps of the method according to any one of claims 3 to 4.

18. A smart card, characterized in that, include: A processor and memory for storing computer programs that can run on the processor, wherein, The processor, when running a computer program, performs the steps of the method according to any one of claims 5 to 12.

19. A computer storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 12.

Images