CN117412268A

CN117412268A - Card application management method, device, equipment and storage medium

Info

Publication number: CN117412268A
Application number: CN202210806015.1A
Authority: CN
Inventors: 陈国华; 乐祖晖; 任晓明
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Priority date: 2022-07-08
Filing date: 2022-07-08
Publication date: 2024-01-16

Abstract

The application discloses a card application management method, device, equipment and storage medium. Wherein the method comprises the following steps: the terminal generates a first message for updating the card application state identification of the target smart card; and sending the first message to the target smart card. Therefore, the card application state identification of the target smart card can be dynamically changed based on the first message, for example, in the situation that the terminal loading the smart card is lost, the card application state identification of the smart card can be changed through the first message sent by other terminals, so that the terminal loading the smart card can disable related services of the card application on the smart card in a normal communication state without loss, the security of the card application on the smart card is enhanced, and in addition, the requirements of searching for the lost terminal and the smart card through a network can be met.

Description

Card application management method, device, equipment and storage medium

Technical Field

The present invention relates to the field of smart cards, and in particular, to a method, apparatus, device, and storage medium for managing card applications.

Background

Smart cards (including UIM (User Identity Module) and SIM (Subscriber Identity Module) cards) are important physical identifiers of mobile identities of users and are also important resources grasped by operators. A smart card (also known as a subscriber identity module card) is a separate security carrier on which security-related card applications, such as card shields (i.e. the function of the U shield is implemented on the card) etc. can be carried.

Along with the common application of intelligent terminals such as mobile phones, the user identification module card can often realize the function of integrating multiple cards, for example, can replace RMB, identity card, work card, entrance guard card, traffic card, car key, bank U shield and the like, help the user pay fast, transact hotel check-in, airport security check and the like, and further meet the requirements of the user on digital life in various scenes such as financial services, offices, life and the like. In the above-mentioned service implementation, the service processing of the card application on the smart card is involved. As card application services evolve, there will be more card applications on the smart card.

However, if the smart terminal on which the smart card is loaded by the user is forgotten somewhere, there is a risk that the card application on the smart card will be stolen by others if it is not determined whether it is lost. The user often needs to make a call to a customer service (for example, 10086) or go to a business hall to report the loss of the smart card, and the smart card reporting the loss can lose the telecommunication function, so that some of the services cannot normally operate, but the service supporting offline transactions such as the work card, the digital RMB, the traffic card and the like can still be used, thus causing a certain loss to the user and increasing the difficulty of searching for the smart terminal through the network.

Disclosure of Invention

In view of this, embodiments of the present application provide a method, apparatus, device, and storage medium for managing a card application, which aim to improve security of the card application.

The technical scheme of the embodiment of the application is realized as follows:

in a first aspect, an embodiment of the present application provides a method for managing a card application, which is applied to a terminal, where the method includes:

generating a first message for updating a card application state identification of the target smart card;

and sending the first message to the target smart card.

In the above solution, the sending the first message to the target smart card includes:

and sending the first message to a first platform, and sending the first message to the target smart card by the first platform.

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

In the above scheme, the first identifier is a mobile phone number, and the second identifier is a forbidden service mode identifier or a normal service mode identifier.

In the above solution, if the terminal loads the target smart card, the method further includes:

responsive to a power-on or a restart, sending a first event for informing the terminal of capability information to the target smart card;

Registering a second event for sending a location status change message to the target smart card;

if the network state of the terminal is determined to be changed, sending the position state change message to the target intelligent card;

wherein the location status change message carries a third identification identifying whether the terminal is on the network.

In a second aspect, an embodiment of the present application provides a method for managing a card application, applied to a first platform, where the method includes:

receiving a first message sent by a terminal and used for updating a card application state identifier of a target smart card;

and sending the first message to the target smart card.

In the above scheme, the method further comprises:

generating a wind control identifier based on historical communication data of the target smart card, wherein the wind control identifier is used for changing card application state identifiers of the target smart card;

and sending the wind control identification to the target smart card.

In a third aspect, an embodiment of the present application provides a method for managing a card application, applied to a smart card, where the method includes:

receiving a first message sent by a terminal, wherein the first message is used for updating a card application state identifier of the smart card;

updating the card application state identification based on the first message.

In the above solution, the updating the card application state identifier based on the first message includes:

if the first message carries a forbidden service mode identifier, updating the card application state identifier into the forbidden service mode identifier; or,

and if the first message carries a normal service mode identifier, updating the card application state identifier to the normal service mode identifier.

In the above scheme, the method further comprises:

receiving a first event which is sent by a terminal and used for informing the terminal of capability information;

registering a second event for transmitting a location status change message to the smart card with the terminal;

and updating the card application state identifier based on the position state change message sent by the terminal.

In the above solution, the location state change message carries a third identifier for identifying whether the terminal is on the network, and the updating the card application state identifier based on the location state change message sent by the terminal includes:

Updating the card application state identifier to an authentication service mode identifier based on the third identifier when the terminal is in a first state of being out of the network; or,

and updating the card application state identifier to a normal service mode identifier based on the third identifier and determining that the terminal is in a second state of being in the network.

In the above solution, before the updating the card application state identifier based on the location state change message sent by the terminal, the method further includes:

and if the current card application state identifier is the forbidden service mode identifier, skipping the position state change message sent by the terminal to update the card application state identifier.

In the above scheme, the method further comprises:

receiving a wind control identifier sent by a first platform, wherein the wind control identifier is used for updating a card application state identifier of the smart card;

and updating the card application state identifier based on the wind control identifier.

In the above solution, before the updating the card application state identifier based on the wind control identifier, the method further includes:

and if the smart card is determined to be updated to be in a forbidden service mode or an authenticated service mode based on the first message or the position state change message sent by the terminal, skipping the updating of the card application state identification based on the wind control identification.

In the above scheme, the method further comprises:

responding to a service request, and acquiring the card application state identification;

and responding to the service request based on the card application state identification.

In the above solution, the responding the service request based on the card application state identifier includes:

if the card application state identifier is a normal service mode identifier, providing a service corresponding to the service request; or,

if the card application state identifier is a forbidden service mode identifier, rejecting the service corresponding to the service request; or,

if the card application state identifier is an authentication service mode identifier, an identity authentication flow is started, and after the identity authentication is passed, the service corresponding to the service request is provided.

In a fourth aspect, an embodiment of the present application provides a management apparatus for card application, applied to a terminal, where the management apparatus includes:

the generating module is used for generating a first message for updating the card application state identification of the target smart card;

and the first sending module is used for sending the first message to the target smart card.

In a fifth aspect, an embodiment of the present application provides a management apparatus for card application, applied to a first platform, where the management apparatus includes:

The first receiving module is used for receiving a first message sent by the terminal and used for updating the card application state identification of the target smart card;

and the second sending module is used for sending the first message to the target smart card.

In a sixth aspect, an embodiment of the present application provides a management device for card application, applied to a smart card, where the management device includes:

the second receiving module is used for receiving a first message sent by the terminal, wherein the first message is used for updating the card application state identifier of the smart card;

and the identification updating module is used for updating the card application state identification based on the first message.

In a seventh aspect, an embodiment of the present application provides a terminal, including: a processor and a memory for storing a computer program capable of running on the processor, wherein the processor is adapted to perform the steps of the method according to the first aspect of the embodiments of the present application when the computer program is run.

In an eighth aspect, embodiments of the present 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 is adapted to perform the steps of the method according to the second aspect of the embodiments of the present application when the computer program is run.

In a ninth aspect, embodiments of the present 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 is adapted to perform the steps of the method according to the third aspect of the embodiments of the present application when the computer program is run.

In a tenth aspect, embodiments of the present application provide a computer storage medium having a computer program stored thereon, which when executed by a processor, implements the steps of any of the methods of the embodiments of the present application.

According to the technical scheme provided by the embodiment of the application, the terminal generates a first message for updating the card application state identifier of the target smart card; and sending the first message to the target smart card. Therefore, the card application state identification of the target smart card can be dynamically changed based on the first message, for example, in the situation that the terminal loading the smart card is lost, the card application state identification of the smart card can be changed through the first message sent by other terminals, so that the terminal loading the smart card can disable related services of the card application on the smart card in a normal communication state without loss, the security of the card application on the smart card is enhanced, and in addition, the requirements of searching for the lost terminal and the smart card through a network can be met.

Drawings

FIG. 1 is a flow chart illustrating a method for managing card applications according to an embodiment of the present disclosure;

FIG. 2 is a flow chart illustrating a method for managing card applications according to another embodiment of the present disclosure;

FIG. 3 is a flowchart illustrating a method for managing card applications according to another embodiment of the present disclosure;

FIG. 4 is a schematic diagram illustrating state transition of a card application in an embodiment of the application of the present application;

FIG. 5 is a schematic flow chart of changing a card application state into a forbidden service based on user labels in an application embodiment of the present application;

fig. 6 is a schematic flow chart of changing a card application state based on a position state of a terminal loading a SIM card in an application embodiment of the present application;

FIG. 7 is a schematic flow chart of a card application state changing based on a wind control identifier of a service platform in an application embodiment of the present application;

fig. 8 is a schematic flow chart of a SIM card responding to a service request based on a card application status identifier in an application embodiment of the present application;

FIG. 9 is a schematic structural diagram of a management device for card application according to an embodiment of the present disclosure;

FIG. 10 is a schematic structural diagram of a management device for card application according to another embodiment of the present application;

FIG. 11 is a schematic structural diagram of a management device for card application according to another embodiment of the present application;

fig. 12 is a schematic structural diagram of a terminal according to an embodiment of the present application;

FIG. 13 is a schematic structural diagram of a first platform according to an embodiment of the present disclosure;

fig. 14 is a schematic structural diagram of a smart card according to an embodiment of the present application.

Detailed Description

The present application is described in further detail below with reference to the accompanying drawings and examples.

Unless defined otherwise, 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 in the description of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

The embodiment of the application provides a card application management method, which is applied to a terminal, wherein the terminal can be a first terminal for loading a target smart card or a second terminal for not loading the target smart card. Here, the terminal may be an electronic device such as a smart phone, a smart bracelet, a smart watch, or an intelligent wearable device. The smart card may be a UIM card or a SIM card carrying a card application. As shown in fig. 1, the management method includes:

step 101, a first message for updating a card application state identification of a target smart card is generated.

Here, the card application state identification may be understood as an identification of whether the target smart card is able to start the card application service. Illustratively, the card application state identification includes at least: and the disabled service mode identifier and the normal service mode identifier, wherein the disabled service mode identifier indicates that the target smart card is in a state that the card application is forbidden to provide services, and the normal service mode identifier indicates that the target smart card is in a state that the card application is normally providing services.

For example, an APP (application program) for generating the first message may be preset on the terminal, and after logging in the APP, the user may generate the first message according to requirements, for example, when the card application on the target smart card needs to be disabled, may generate a first message for updating the card application state identifier of the target smart card to the disabled service mode identifier; when the card application on the target smart card needs to be started normally, a first message for updating the card application state identification of the target smart card to the normal service mode identification may be generated.

Step 102, sending the first message to the target smart card.

After the terminal sends the first message to the target smart card, the target smart card may update the locally stored card application state identifier according to the received first message.

For example, if the terminal is a first terminal that loads the target smart card, the first terminal may send the first message to the target smart card via a communication line connected to the target smart card. Therefore, the user can locally change the card application state identification of the target smart card on the first terminal based on the first terminal, so that the service state of the card application can be automatically changed according to the requirement.

For example, if the terminal is a second terminal that does not load the target smart card, the sending the first message to the target smart card includes:

Therefore, the user can remotely change the card application state identification of the target smart card on the first terminal based on the second terminal, so that the card application state identification of the target smart card can be changed through the first message sent by the second terminal under the condition that the first terminal loading the target smart card is lost, the first terminal can disable related services of the card application on the target smart card under the normal communication state, loss reporting is not needed, the safety of the card application on the smart card is enhanced, and in addition, the requirements of searching for the lost first terminal and the target smart card through a network can be met.

Here, the first platform may be a service platform related to communication, and the first platform may send the first message to the target smart card through a short message gateway or a BIP (Bearer Independent Protocol ) gateway.

Illustratively, the first message carries a first identification indicating the target smart card and a second identification representing a card application status identification to be updated. In this way, the smart card may determine whether the first message is a self-matching first message based on the first identification and update the card application state identification based on the second identification.

Illustratively, the first identifier is a mobile phone number, and the second identifier is a forbidden service mode identifier or a normal service mode identifier. For example, the normal service mode is identified as 0 and the forbidden service mode is identified as 1.

In some embodiments, if the terminal loads the target smart card, the method further comprises:

It can be understood that if the terminal is the first terminal for loading the target smart card, the first terminal may also send a location status change message to the target smart card, and the target smart card may update the card application status identifier based on the third identifier carried by the location status change message and identifying whether the terminal is on the network, so as to implement intelligent change of the card application service status of the target smart card based on whether the terminal is on the network, and further improve the security of card application on the target smart card.

Illustratively, when the first Terminal is powered on or restarted, the first Terminal sends a Terminal Profile event to the target smart card, after the target smart card receives the Terminal Profile event, registers Location Status Change Event event with the first Terminal, after the first Terminal registers Location Status Change Event event, if the first Terminal changes network state (for example, when off-line occurs or switches to a flight mode), the first Terminal sends Location Status Change Event to the target smart card, thereby informing the target smart card of a location state change message carrying a third identifier identifying whether the Terminal is on-line.

The embodiment of the application also provides a management method of the card application, which is applied to the first platform, as shown in fig. 2, and comprises the following steps:

step 201, a first message sent by a terminal for updating a card application state identifier of a target smart card is received.

Step 202, sending the first message to the target smart card.

Here, the first platform may be a service platform related to communication, and the first platform may send the first message to the target smart card through a short message gateway or a BIP gateway.

Illustratively, the first message carries a first identification indicating the target smart card and a second identification representing a card application status identification to be updated.

Illustratively, the first identifier is a mobile phone number, and the second identifier is a forbidden service mode identifier or a normal service mode identifier.

In some embodiments, the management method further comprises:

and sending the wind control identification to the target smart card.

The first platform may determine a risk level of the mobile phone number of the user based on historical communication data of the user, for example, a receiving frequency of a harassment short message, a receiving frequency of a harassment call, and the like, and if the risk level is high risk, generate a wind control identifier for updating the card application state identifier to the forbidden service mode identifier; if the risk level is risk, generating a wind control identifier for updating the card application state identifier into an authentication service mode identifier; and if the risk level is low risk, generating a wind control identifier for updating the card application state identifier to the normal service mode identifier. In this way, the target smart card may automatically update the local card application state identification based on the received wind control identification.

The embodiment of the application provides a card application management method, which is applied to a smart card, as shown in fig. 3, and comprises the following steps:

step 301, receiving a first message sent by a terminal, where the first message is used to update a card application state identifier of the smart card.

Step 302, updating the card application state identification based on the first message.

Here, the card application state identification may be understood as an identification by which the smart card determines whether it can start the card application service. Illustratively, the card application state identification includes at least: and the disabled service mode identifier and the normal service mode identifier, wherein the disabled service mode identifier indicates that the target smart card is in a state that the card application is forbidden to provide services, and the normal service mode identifier indicates that the target smart card is in a state that the card application is normally providing services.

Illustratively, said updating said card application state identification based on said first message comprises:

Illustratively, the method further comprises:

The terminal is a terminal for loading the smart card. Illustratively, when the Terminal is powered on or restarted, the Terminal sends a Terminal Profile event to the smart card, after the smart card receives the Terminal Profile event, registers Location Status Change Event an event with the Terminal, after registering Location Status Change Event an event, if a network state change occurs to the Terminal (for example, when a network disconnection occurs or a switch to a flight mode occurs), the Terminal sends Location Status Change Event to the smart card, so as to inform the smart card of a location state change message carrying a third identifier identifying whether the Terminal is on the network.

Illustratively, the updating the card application state identifier based on the location state change message sent by the terminal includes:

Illustratively, before the updating the card application state identifier based on the location state change message sent by the terminal, the method further includes:

It should be noted that, if the smart card has been marked as a forbidden service mode by the user before updating the card application state identifier based on the location state change message, the mode of the user identifier is preferentially satisfied, that is, the mode of the user identifier is higher in priority than the mode corresponding to the location state change message.

It should be noted that, if the smart card will identify the card application state identifier as the normal service mode identifier based on the location state change message, the smart card determines that the card application state identifier is the authentication service mode identifier, and determines that the terminal has recovered to the second state on the network based on the third identifier carried by the received location state change message, so that after the terminal recovers to the network, the card application state identifier is switched to the normal service mode identifier.

Illustratively, the management method further comprises:

It should be noted that, the wind control identifier is generated by the first platform based on the historical communication data of the user, specifically, may be generated based on a risk level of the mobile phone number of the user, for example, if the risk level is high risk, the wind control identifier for updating the card application state identifier to the forbidden service mode identifier is generated; if the risk level is risk, generating a wind control identifier for updating the card application state identifier into an authentication service mode identifier; and if the risk level is low risk, generating a wind control identifier for updating the card application state identifier to the normal service mode identifier.

Illustratively, when the smart card updates the card application state identifier based on the wind control identifier, the forbidden service mode identifier in the wind control identifier can be distinguished from the forbidden service mode identifier of the manual label, and the authentication service mode identifier in the wind control identifier can be distinguished from the authentication service mode identifier determined by the location state change information of the terminal, for example, in an application example, each identifier of the card application state identifier is as follows: the normal service mode identifier is 0, the forbidden service mode identifier is 1, the authentication service mode identifier is 2, the forbidden service mode identifier corresponding to the wind control identifier is 3, and the authentication service mode identifier corresponding to the wind control identifier is 4.

Illustratively, before the updating the card application state identifier based on the wind control identifier, the method further comprises:

It can be understood that when the smart card changes the card application state identifier, the priority of the first message is greater than the position state change message of the terminal, and the position state change message of the terminal is greater than the wind control identifier. Therefore, the intelligent card can preferably meet the service mode manually marked by the user or change the corresponding service mode according to the position state of the terminal, and the security of card application of the intelligent card is guaranteed.

Illustratively, the management method further comprises:

It will be appreciated that the smart card responds to the service request based on the card application status identifier, thereby improving the security of the card application.

Illustratively, said responding to said service request based on said card application state identification comprises:

The present application is described in further detail below in connection with examples of application.

In this embodiment, the smart card uses a SIM card as an example, and a schematic diagram of card application state transition is shown in fig. 4. It should be noted that, when the card application state of the smart card is a forbidden service (i.e., the card application state identifier is a forbidden service mode identifier), the card application state of the smart card cannot be switched to the authentication service. When the card application state is an authentication service (i.e., the card application state identification is an authentication service mode identification determined by the terminal network state or an authentication service mode determined by the service wind control), the user label can be changed to a forbidden service.

Fig. 5 is a schematic flow chart of changing the card application state to the forbidden service based on the user label in the application embodiment. As shown in fig. 5, the modification flow includes:

Step 501, the user logs in to the APP.

The APP is an APP which is preset on the terminal and used for changing the card application state identification, and a user can log in the APP through the modes of identity authentication and the like.

Step 502, the user marks the application on the SIM card as a forbidden service.

Here, the application state of the card in the SIM corresponding to the mobile phone number is marked as a forbidden service state by the APP.

Step 503, send a card application state identification request.

Here, the terminal may generate and send the aforementioned first information (i.e. the application state identifier request) to the service platform, where the first information carries the mobile phone number and the card application state identifier to be updated.

Step 504, a card application state identification request is sent.

Here, after receiving the first message sent by the terminal, the service platform sends the first message to the SIM through the short message gateway or the BIP gateway.

Step 505, set card application state identification.

Here, the SIM card alters the locally stored card application state identification based on the received first message, e.g., the card application identification is 0: normal service; 1: prohibiting service; 2: and (5) authenticating the service.

And step 506, returning a card application state identification response.

Here, the SIM card reports the card application state identification result to the service platform through the short message gateway or the BIP gateway.

And step 507, returning a card application state identification response.

Here, the service platform returns the identification result to the user APP.

It should be noted that, based on the similar flow, the user may set the card application to the normal service state, and the specific process is not described herein.

Fig. 6 is a flow chart showing a change of the card application state based on the position state of the terminal loading the SIM card in the present application embodiment. As shown in fig. 6, the modification flow includes:

in step 601, the Terminal transmits a Terminal Profile event.

When the user Terminal is started or restarted, the Terminal sends a Terminal Profile event to the SIM card.

At step 602, a Location Status Change Event event is registered.

After receiving the Terminal Profile event, the SIM card registers Location Status Change Event event with the Terminal.

Step 603, send Location Status Change Event, return to the terminal position state.

After the SIM card registers Location Status Change Event with the terminal, if the terminal gets off-line or in flight mode, it sends Location Status Change Event to the SIM card and returns to the terminal position state.

In step 604, when the card application state is a non-disabled service state, the card application state is identified as an authenticated service state.

The SIM card determines that the terminal is not on the network (i.e. off the network or in a flight mode) based on the position state sent by the terminal, and changes the card application state identifier into an authentication service mode identifier if the card application state is in a non-forbidden service state.

When the terminal network returns to normal, the method further comprises the following steps:

step 605, send Location Status Change Event, return to the terminal position state.

When the terminal network returns to normal, location Status Change Event is sent again to the SIM card and the terminal location status is returned. The SIM card marks the card application normal service state according to the terminal position state.

Step 606, when the card application state is a non-forbidden service state, it is identified as an authenticated service state.

The SIM card determines that the terminal is recovered to be on the network (namely off the network or in a flight mode) based on the position state sent by the terminal, and changes the card application state identifier into a normal service mode identifier if the card application state is in a non-forbidden service state.

It should be noted that, if the card application state of the SIM card is already marked as forbidden service by the user, the SIM card does not change the card application state identifier according to the location state of the terminal, that is, the service mode requirement of the user identifier is preferentially satisfied.

Fig. 7 is a schematic flow chart of changing the card application state based on the wind control identifier of the service platform in the embodiment of the application. As shown in fig. 7, the modification flow includes:

and 701, generating a wind control identifier.

Here, the service platform generates the wind control identifier based on the historical communication data of the user, specifically, may generate the wind control identifier based on the risk level of the mobile phone number of the user, for example, if the risk level is high risk, then generate the wind control identifier for updating the card application state identifier to the forbidden service mode identifier; if the risk level is risk, generating a wind control identifier for updating the card application state identifier into an authentication service mode identifier; and if the risk level is low risk, generating a wind control identifier for updating the card application state identifier to the normal service mode identifier.

Step 702, a card application state identification request is sent.

Here, the service platform sends a card application state identifier request (i.e. a wind control identifier) to the SIM through the sms gateway or the BIP gateway, where the card application state identifier request carries, for example, a mobile phone number and a card application state identifier to be updated.

Step 703, set card application status identification.

Here, the SIM card judges and updates the card application state identifier according to the current state, does not change the service state if the user has been identified, and marks the card application state identifier if the user has not been identified, for example: card application identification is 0: normal service; 1: prohibiting service; 2: an authentication service; 3: the wind control identification prohibits service; 4: the wind control identification authentication service.

Step 704, a card application state identification response is returned.

It should be noted that, when the SIM card performs card application status labeling, the user identifier (i.e. the aforementioned first message) takes precedence over the wind control identifier.

Fig. 8 shows a schematic flow chart of a SIM card responding to a service request based on a card application status identifier in the present application embodiment. As shown in fig. 8, the flow includes:

step 801, a user initiates a business transaction.

The user may initiate a business transaction related to the card application on the SIM card.

Step 802, a service request is initiated to the SIM card.

Here, the terminal may initiate a service request to the SIM card through a data short message, a BIP channel, a local card interface, near field communication, and the like.

Step 803, obtain the card application state identification.

The SIM card responds to the service request and acquires the card application state identification from the storage module of the card application state identification.

Step 804, return card application state identification.

The memory module of the card application state identifier returns the card application state identifier to the service card application.

Step 805, determine the card service status identifier.

The service card application judges whether to provide service or not or to provide service after user authentication according to the card application state identification, specifically, if the card application state identification is a normal service mode identification, providing the service corresponding to the service request; or if the card application state identifier is a forbidden service mode identifier, rejecting the service corresponding to the service request; or if the card application state identifier is the authentication service mode identifier, starting an identity authentication flow and providing the service corresponding to the service request after the identity authentication is passed

And step 806, returning a service response.

And returning a service response by the SIM card according to the card application state.

In order to implement the method of the embodiment of the present application, the embodiment of the present application further provides a card application management device, which is applied to a terminal, where the card application management device corresponds to the terminal-side management method, and each step in the terminal-side management method embodiment is also completely applicable to the embodiment of the card application management device.

As shown in fig. 9, the card application management apparatus includes: a generating module 901 and a first transmitting module 902. The generating module 901 is configured to generate a first message for updating a card application state identifier of a target smart card; the first sending module 902 is configured to send the first message to the target smart card.

In some embodiments, the first sending module 902 is specifically configured to:

In some embodiments, the first message carries a first identification indicating the target smart card and a second identification representing a card application status identification to be updated.

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.

In some embodiments, if the terminal loads the target smart card, the first sending module 902 is further configured to: responsive to a power-on or a restart, sending a first event for informing the terminal of capability information to the target smart card; the card application management apparatus 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 send the location status change message to the target smart card if it is determined that the network status of the terminal changes; wherein the location status change message carries a third identification identifying whether the terminal is on the network.

In actual application, the generating module 901, the first transmitting module 902 and the registering module 903 may be implemented by a processor in a management device of the card application. Of course, the processor needs to run a computer program in memory to implement its functions.

In order to implement the method of the embodiment of the present application, the embodiment of the present application further provides a card application management device, which is applied to the first platform, where the card application management device corresponds to the first platform side management method, and each step in the first platform side management method embodiment is also completely applicable to the card application management device embodiment.

As shown in fig. 10, the card application management apparatus includes: a first receiving module 1001 and a second transmitting module 1002. The first receiving module 1001 is configured to receive a first message sent by a terminal and used for updating a card application state identifier of a target smart card; the second sending module 1002 is configured to send the first message to the target smart card.

In some embodiments, the card application management apparatus further includes: the wind control module 1003 is configured to generate a wind control identifier based on historical communication data of the target smart card, where the wind control identifier is used to change a card application state identifier of the target smart card; the second sending module 1002 is further configured to send the wind control identifier to the target smart card.

In practical application, the first receiving module 1001, the second sending module 1002, and the wind control module 1003 may be implemented by a processor in the card application management device. Of course, the processor needs to run a computer program in memory to implement its functions.

In order to implement the method of the embodiment of the present application, the embodiment of the present application further provides a card application management device, which is applied to a smart card, where the card application management device corresponds to the smart card side management method, and each step in the smart card side management method embodiment is also completely applicable to the card application management device embodiment.

As shown in fig. 11, the card application management apparatus includes: a second receiving module 1101 and an identity updating module 1102. The second receiving module 1101 is configured to receive a first message sent by a terminal, where the first message is used to update a card application status identifier of the smart card; the identifier update module 1102 is configured to update the card application state identifier based on the first message.

In some embodiments, the identity update module 1102 is specifically configured to:

In some embodiments, the second receiving module 1101 is further configured to receive a first event sent by a terminal and used for notifying the capability information of the terminal; the card application management apparatus 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 updating module 1102 is further configured to update the card application state identifier based on a location state change message sent by the terminal.

In some embodiments, the location state change message carries a third identifier that identifies whether the terminal is on the network, and updating the card application state identifier based on the location state change message sent by the terminal includes:

In some embodiments, before the updating the card application state identifier based on the location state change message sent by the terminal, the identifier updating module 1102 is further configured to: and if the current card application state identifier is the forbidden service mode identifier, skipping the position state change message sent by the terminal to update the card application state identifier.

In some embodiments, the second receiving module 1101 is further configured to receive a first platform sending a wind control identifier, where the wind control identifier is used to update a card application status identifier of the smart card; the identifier updating module 1102 is further configured to update the card application state identifier based on the wind control identifier.

In some embodiments, before the updating the card application state identifier based on the wind control identifier, the identifier updating module 1102 is further configured to:

In some embodiments, the card application management apparatus further includes: a service processing module 1104, configured to obtain the card application state identifier in response to a service request; and responding to the service request based on the card application state identification.

In some embodiments, the responding to the service request based on the card application state identification includes:

In actual application, the second receiving module 1101, the identifier updating module 1102, the third sending module 1103 and the service processing module 1104 may be implemented by a processor in a management device of the card application. Of course, the processor needs to run a computer program in memory to implement its functions.

It should be noted that: in the management device for card application provided in the above embodiment, only the division of each program module is used for illustration, and in practical application, the above processing allocation may be performed by different program modules according to needs, that is, the internal structure of the device is divided into different program modules, so as to complete all or part of the above processing. In addition, the device for managing card applications provided in the above embodiment and the method embodiment for managing card applications belong to the same concept, and specific implementation processes thereof are detailed in the method embodiment and are not described herein again.

Based on the hardware implementation of the program modules, and in order to implement the method of the embodiment of the application, the embodiment of the application also provides a terminal. Fig. 12 shows only an exemplary structure of the terminal, not all of which may be implemented as needed.

As shown in fig. 12, a terminal 1200 provided in an embodiment of the present application includes: at least one processor 1201, memory 1202, a user interface 1203, and at least one network interface 1204. The various components in terminal 1200 are coupled together by a bus system 1205. It is to be appreciated that the bus system 1205 is employed to facilitate connected communications between the components. The bus system 1205 includes a power bus, a control bus, and a status signal bus in addition to the data bus. But for clarity of illustration, the various buses are labeled as bus system 1205 in fig. 12.

The user interface 1203 may include, among other things, a display, keyboard, mouse, trackball, click wheel, keys, buttons, touch pad, or touch screen, etc.

The memory 1202 in the present embodiment is used to store various types of data to support the operation of the terminal. Examples of such data include: any computer program for operating on a terminal.

The card application management method disclosed in the embodiment of the present application may be applied to the processor 1201 or implemented by the processor 1201. The processor 1201 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the method for managing card applications may be performed by integrated logic circuits of hardware in the processor 1201 or by instructions in the form of software. The processor 1201 may be a general purpose processor, a digital signal processor (DSP, digital Signal Processor), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. The processor 1201 may implement or perform the methods, steps, and logic blocks disclosed in embodiments of the present application. The general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly embodied in a hardware decoding processor or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium in the memory 1202, and the processor 1201 reads the information in the memory 1202 and, in combination with its hardware, performs the steps of the method for managing card applications provided in the embodiments of the present application.

In an exemplary embodiment, the terminal may be implemented by one or more application specific integrated circuits (ASIC, application Specific Integrated Circuit), DSP, programmable logic device (PLD, programmable Logic Device), complex programmable logic device (CPLD, complex Programmable Logic Device), field programmable gate array (FPGA, field Programmable Gate Array), general purpose processor, controller, microcontroller (MCU, micro Controller Unit), microprocessor (Microprocessor), or other electronic element for performing the aforementioned methods.

Based on the hardware implementation of the program modules, and in order to implement the method of the embodiment of the present application, the embodiment of the present application further provides a first platform. Fig. 13 shows only an exemplary structure of the first platform, not all of which may be implemented as desired.

As shown in fig. 13, a first platform 1300 provided in an embodiment of the present application 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 by a bus system 1305. It is appreciated that the bus system 1305 is used to implement the connectivity communications between these components. The bus system 1305 includes a power bus, a control bus, and a status signal bus in addition to the data bus. But for clarity of illustration, the various buses are labeled as bus system 1305 in fig. 13.

The user interface 1303 may include, among other things, a display, a keyboard, a mouse, a trackball, a click wheel, keys, buttons, a touch pad, or a touch screen.

The memory 1302 in the present 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 for operating on the first platform.

The method for managing card applications disclosed in the embodiments of the present application may be applied to the processor 1301 or implemented by the processor 1301. Processor 1301 may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the method for managing card applications may be performed by integrated logic circuits of hardware in the processor 1301 or instructions in the form of software. The processor 1301 may be a general purpose processor, a digital signal processor (DSP, digital Signal Processor), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. Processor 1301 may implement or perform the methods, steps, and logic blocks disclosed in embodiments of the present application. The general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly embodied in a hardware decoding processor or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium in the memory 1302, and the processor 1301 reads information in the memory 1302, and in combination with its hardware, performs the steps of the method for managing card applications provided in the embodiments of the present application.

In an exemplary embodiment, the first platform 1300 may be implemented by one or more ASIC, DSP, PLD, CPLD, FPGA, general-purpose processors, controllers, MCU, microprocessor, or other electronic elements for performing the foregoing methods.

Based on the hardware implementation of the program modules, and in order to implement the method of the embodiment of the application, the embodiment of the application also provides a smart card. Fig. 14 shows only an exemplary structure of the smart card, not all of which may be implemented as required.

As shown in fig. 14, a smart card 1400 provided in an embodiment of the present application includes: at least one processor 1401, memory 1402, and at least one network interface 1403. The various components in the smart card 1400 are coupled together by a bus system 1404. It is to be appreciated that the bus system 1404 is employed to facilitate connection communications between the components. The bus system 1404 includes a power bus, a control bus, and a status signal bus in addition to the data bus. The various buses are labeled as bus system 1404 in fig. 14 for clarity of illustration.

The memory 1402 in the embodiment of the present application is used to store various types of data to support the operation of the smart card. Examples of such data include: any computer program for operating on a smart card.

The card application management method disclosed in the embodiment of the present application may be applied to the processor 1401 or implemented by the processor 1401. The processor 1401 may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the method for managing card applications may be performed by integrated logic circuits of hardware in the processor 1401 or instructions in the form of software. The processor 1401 as described above may be a general purpose processor, a digital signal processor (DSP, digital Signal Processor), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. The processor 1401 may implement or perform the methods, steps, and logic blocks disclosed in embodiments of the present application. The general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly embodied in a hardware decoding processor or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium in memory 1402. The processor 1401 reads the information in the memory 1402 and, in combination with its hardware, performs the steps of the method for managing card applications provided in the embodiments of the present application.

It will be appreciated that the memory 1202, 1302, 1402 described above can be either volatile memory or nonvolatile memory, and can include both volatile and nonvolatile memory. Wherein the nonvolatile Memory may be Read Only Memory (ROM), programmable Read Only Memory (PROM, programmable Read-Only Memory), erasable programmable Read Only Memory (EPROM, erasable Programmable Read-Only Memory), electrically erasable programmable Read Only Memory (EEPROM, electrically Erasable Programmable Read-Only Memory), magnetic random access Memory (FRAM, ferromagnetic random access Memory), flash Memory (Flash Memory), magnetic surface Memory, optical disk, or compact disk Read Only Memory (CD-ROM, compact Disc Read-Only Memory); the magnetic surface memory may be a disk memory or a tape memory. The volatile memory may be random access memory (RAM, random Access Memory), which acts as external cache memory. By way of example, and not limitation, many forms of RAM are available, such as static random access memory (SRAM, static Random Access Memory), synchronous static random access memory (SSRAM, synchronous Static Random Access Memory), dynamic random access memory (DRAM, dynamic Random Access Memory), synchronous dynamic random access memory (SDRAM, synchronous Dynamic Random Access Memory), double data rate synchronous dynamic random access memory (ddr SDRAM, double Data Rate Synchronous Dynamic Random Access Memory), enhanced synchronous dynamic random access memory (ESDRAM, enhanced Synchronous Dynamic Random Access Memory), synchronous link dynamic random access memory (SLDRAM, syncLink Dynamic Random Access Memory), direct memory bus random access memory (DRRAM, direct Rambus Random Access Memory). The memory described in the embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.

In an exemplary embodiment, the present embodiment further provides a computer storage medium, which may be a computer readable storage medium, for example, including a memory 1202 storing a computer program, where the computer program may be executed by the processor 1201 of the terminal to perform the steps described in the terminal-side method of the embodiment of the present application; as another example, the memory 1302 includes a memory storing a computer program executable by the processor 1301 of the first platform to perform the steps described in the first platform side method of the embodiment of the present application; for another example, a memory 1402 storing a computer program is included, which can be executed by the processor 1401 of the smart card to perform the steps of the smart card-side method of the embodiment of the present application. The computer readable storage medium may be ROM, PROM, EPROM, EEPROM, flash Memory, magnetic surface Memory, optical disk, or CD-ROM.

It should be noted that: "first," "second," etc. are used to distinguish similar objects and not necessarily to describe a particular order or sequence.

In addition, the embodiments described in the present application may be arbitrarily combined without any collision.

The foregoing is merely a specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for managing card applications, applied to a terminal, the method comprising:

and sending the first message to the target smart card.

2. The method of claim 1, wherein said sending said first message to said target smart card comprises:

3. The method of claim 1, wherein the step of determining the position of the substrate comprises,

the first message carries a first identifier indicating the target smart card and a second identifier indicating a card application state identifier to be updated.

4. A method according to claim 3, wherein the first identity is a handset number and the second identity is a disabled service mode identity or a normal service mode identity.

5. The method of claim 1, wherein if the terminal loads the target smart card, the method further comprises:

6. A method of managing card applications, applied to a first platform, the method comprising:

and sending the first message to the target smart card.

7. The method of claim 6, wherein the step of providing the first layer comprises,

8. The method of claim 7, wherein the first identifier is a cell phone number and the second identifier is a disabled service mode identifier or a normal service mode identifier.

9. The method of claim 6, wherein the method further comprises:

and sending the wind control identification to the target smart card.

10. A method of managing card applications, applied to a smart card, the method comprising:

updating the card application state identification based on the first message.

11. The method of claim 10, wherein the updating the card application state identification based on the first message comprises:

12. The method according to claim 10, wherein the method further comprises:

13. The method of claim 12, wherein the location state change message carries a third identification identifying whether the terminal is on a network, and wherein updating the card application state identification based on the location state change message sent by the terminal comprises:

14. The method of claim 13, wherein prior to updating the card application state identification based on the location state change message sent by the terminal, the method further comprises:

15. The method according to claim 10, wherein the method further comprises:

16. The method of claim 15, wherein prior to updating the card application state identification based on the wind control identification, the method further comprises:

17. The method according to claim 10, wherein the method further comprises:

18. The method of claim 17, wherein said responding to said service request based on said card application state identification comprises:

19. A management apparatus of a card application, applied to a terminal, comprising:

20. A management device for card applications, applied to a first platform, the management device comprising:

21. A management device for card applications, applied to a smart card, said management device comprising:

22. A terminal, comprising: a processor and a memory for storing a computer program capable of running on the processor, wherein,

the processor being adapted to perform the steps of the method of any of claims 1 to 5 when the computer program is run.

23. A first platform, comprising: a processor and a memory for storing a computer program capable of running on the processor, wherein,

the processor being adapted to perform the steps of the method of any of claims 6 to 9 when the computer program is run.

24. A smart card, comprising: a processor and a memory for storing a computer program capable of running on the processor, wherein,

the processor being adapted to perform the steps of the method of any of claims 10 to 18 when the computer program is run.

25. A computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of any of claims 1 to 18.