Data refreshing method and device, storage medium and electronic equipment

Abstract

The invention discloses a data refreshing method and device, a storage medium and electronic equipment, and relates to the technical field of communication. Responding to a refreshing process triggered by the service execution process, and initiating a refreshing instruction to the terminal; if a first result code returned by the terminal is received, a retry strategy of the refreshing instruction is executed according to the configuration data, and the first result code indicates that the current state of the terminal does not support execution of the refreshing instruction. Compared with the prior art, the dynamic retry strategy based on the preset configuration data is introduced, strong dependence of execution of the refreshing instruction on the instantaneous state of the terminal is effectively decoupled, and when the terminal fails to be refreshed due to the fact that the terminal is in a high-priority task (such as a call), the terminal can be refreshed successfully. The intelligent card module can plan the subsequent retry opportunity according to the configuration parameters reflecting the user behavior statistical rule, so that it is ensured that the refreshing instruction is successfully and efficiently executed at the first time after the call is ended, the target function is achieved, and the service reliability and the user experience are improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a data refresh method, apparatus, storage medium, and electronic device. Background Technology

[0002] In mobile communication systems, the SIM card serves as the core carrier for user authentication and service delivery. Its dynamic file system update capability is crucial for scenarios such as remote configuration management, permission activation, and network policy adjustments. When files within the SIM card are modified, the terminal typically relies on a caching mechanism to temporarily store the original content, causing updates to not take effect immediately. To ensure changes are promptly reflected on the terminal side, the SIM card needs to be powered on again to force the terminal to refresh the cache and reread the latest data from the card.

[0003] Currently, the Refresh command mechanism can be used to notify the terminal to perform a power-off and power-on operation on the card, thereby avoiding the need for users to manually insert or remove the card or restart the device.

[0004] However, the execution of refresh commands is limited by the current state of the terminal. For example, when the terminal is in the middle of a voice call, the system cannot execute refresh commands normally, which causes critical configuration updates to fail to take effect in a timely manner, affecting the reliability of services and user experience. Summary of the Invention

[0005] In view of this, this application provides a data refresh method, apparatus, storage medium, and electronic device, the main purpose of which is to improve the technical problem that the execution of refresh instructions is limited by the current state of the terminal, resulting in the failure of critical configuration updates to take effect in a timely manner, which affects the reliability of services and user experience.

[0006] In a first aspect, this application provides a data refresh method applied to a smart card module, comprising: Receive configuration data sent by the server; In response to the refresh process triggered by the business execution process, a refresh command is sent to the terminal; If a first result code is received from the terminal, the retry strategy for the refresh instruction is executed according to the configuration data. The first result code indicates that the current state of the terminal does not support the execution of the refresh instruction.

[0007] Secondly, this application provides a data refresh method applied to a terminal, comprising: In response to a refresh command initiated by the smart card module, the terminal's current state is checked to see if it meets the conditions for executing the refresh command. If the current state of the terminal meets the execution conditions of the refresh instruction, then the refresh instruction is executed; If the current state of the terminal does not meet the conditions for executing the refresh instruction, a result code is sent to the smart card module.

[0008] Thirdly, this application provides a data refresh method applied to a server, including: Based on historical call data, determine the characteristic parameters of call duration distribution; The call duration distribution feature parameters are encapsulated into configuration data, which is used to dynamically adjust the retry strategy of the refresh command when the refresh command fails to be executed. The configuration data is sent to the smart card module.

[0009] Fourthly, this application provides a data refresh device for use in a smart card module, comprising: The receiving module is configured to receive configuration data sent by the server. The initiation module is configured to send a refresh command to the terminal in response to a refresh process triggered by the business execution process. The execution module is configured to execute the retry strategy of the refresh instruction according to the configuration data if it receives a first result code returned by the terminal, wherein the first result code indicates that the current state of the terminal does not support the execution of the refresh instruction.

[0010] Fifthly, this application provides a data refresh device for use in a terminal, comprising: The detection module is configured to detect whether the current state of the terminal meets the execution conditions of the refresh command in response to the refresh command initiated by the smart card module. The execution module is configured to execute the refresh instruction if the current state of the terminal meets the execution conditions of the refresh instruction; The sending module is configured to send a result code to the smart card module if the current state of the terminal does not meet the execution conditions of the refresh instruction.

[0011] Sixthly, this application provides a data refresh device applied to a server, comprising: The determination module is configured to determine call duration distribution characteristic parameters based on historical call data; The encapsulation module is configured to encapsulate the call duration distribution feature parameters into configuration data, which is used to dynamically adjust the retry strategy of the refresh instruction when the refresh instruction fails to be executed. The sending module is configured to send the configuration data to the smart card module.

[0012] In a seventh aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the methods described in the first, second, or third aspects.

[0013] Eighthly, this application provides an electronic device including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the methods described in the first, second, or third aspects.

[0014] Ninthly, this application provides a computer program product having a computer program stored thereon, which, when executed by a processor, implements the methods described in the first, second, or third aspects.

[0015] By employing the above technical solutions, this application provides a data refresh method, apparatus, storage medium, and electronic device. First, it receives configuration data from a server; then, in response to a refresh process triggered by a business execution flow, it sends a refresh command to the terminal; if a first result code is received from the terminal, the retry strategy of the refresh command is executed according to the configuration data, where the first result code indicates that the terminal's current state does not support the execution of the refresh command. Compared with existing technologies, this application effectively decouples the strong dependence of refresh command execution on the instantaneous state of the terminal by introducing a dynamic retry strategy based on preset configuration data on the smart card module side. When the terminal refuses to execute the refresh command and returns a specific result code due to being in a high-priority task (such as a call), the smart card module no longer passively waits or directly abandons the task. Instead, it autonomously plans subsequent retry opportunities based on configuration parameters pre-issued by the server that reflect statistical patterns of user behavior, thereby ensuring that the refresh command is successfully and efficiently executed immediately after the call ends, achieving the target function and improving business reliability and user experience.

[0016] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1A flowchart illustrating a data refresh method provided in an embodiment of this application is shown; Figure 2 A schematic diagram illustrating an example provided in an embodiment of this application is shown; Figure 3 A schematic diagram illustrating an example provided in an embodiment of this application is shown; Figure 4 A flowchart illustrating another data refresh method provided in an embodiment of this application is shown; Figure 5 A flowchart illustrating another data refresh method provided in an embodiment of this application is shown; Figure 6 This illustration shows a schematic diagram of the structure of a data refresh device provided in an embodiment of this application; Figure 7 This invention provides a schematic diagram of the structure of another data refresh device according to an embodiment of the present application. Figure 8 A schematic diagram of another data refresh device provided in an embodiment of this application is shown. Detailed Implementation

[0020] The embodiments of this application will now be described in more detail with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0021] To address the technical issue of refresh command execution being limited by the current terminal state, resulting in delayed updates of critical configurations and impacting service reliability and user experience, this embodiment provides a data refresh method, such as... Figure 1 As shown, applied to a smart card module, the method includes: Step 101: Receive configuration data sent by the server.

[0022] For example, the smart card module may include a SIM card, a USIM card, a UICC card, etc. This embodiment uses a SIM card as an example for ease of description. The server may be a business platform deployed by the operator or card management party. In this embodiment, the business platform can not only handle routine operations such as service activation, permission changes, and file updates, but also remotely configure and manage policies for the smart card module.

[0023] In some examples, the configuration data may include call duration distribution characteristic parameters; wherein, the call duration distribution characteristic parameters may include the median duration value μ. X One or more of the following: confidence interval lower limit n, interval value s, retry granularity p, and retry time limit threshold M. Step 102: In response to the refresh process triggered by the business execution process, send a refresh command to the terminal.

[0024] For example, when the card application receives a downlink SMS instruction from the service platform or is required by the current business execution process (e.g., after remotely updating the smart card module file to make the new configuration take effect, enabling or disabling a certain card function, repairing abnormal card status, executing network access policy changes, etc.), it assembles and initiates a refresh command (Refresh) to trigger the terminal to re-power the card. The format of the Refresh command is as follows: Figure 2 As shown, its overall structure is organized using Tag-Length-Value (TLV) encoding, containing multiple fields, each with a clear semantic meaning and purpose. For example, Command Details specifies the specific operation type; Device Identities indicate the source and target devices of the command; File List indicates the involved EF or DF files; Application Identifier (AID) uniquely identifies the target card application; Alpha Identifier provides displayable text that can be displayed on the screen while the terminal executes UICC commands; Icon Identifier is associated with the graphical representation; Text Attribute defines the attributes of the displayed text; Frame Identifier is used for position management in multi-frame display scenarios; Refresh enforcement policy indicates whether to force the terminal to perform a refresh action; and the value of Application Specific Refresh Data can be defined by the application itself, used to provide additional information to entities related to the application in the terminal, and can only be provided when the refresh mode is "Application Update". These fields are selectively filled according to the actual application scenario, with some being required and others being optional, ensuring that the instructions have good compatibility and resolvability between resource-constrained SIM cards and diverse terminals.

[0025] Step 103: If the first result code returned by the terminal is received, the retry strategy of the refresh instruction is executed according to the configuration data.

[0026] The first result code indicates that the current state of the terminal does not support the execution of the refresh command.

[0027] For example, if the result code value is 0x20, then the current result code is the first result code, which means that the current state of the terminal does not allow the execution of the Refresh command. At this time, it can be determined that the current user is in a call. After the call ends, the command will be able to be executed normally. Therefore, the application will initiate a retry at this time.

[0028] Optionally, step 103 may specifically include: determining the retry time interval corresponding to the refresh instruction based on the cumulative duration of the current call and the call duration distribution characteristic parameters; initiating a registration instruction for the status event to the terminal and setting the notification period of the status event as the retry time interval; and re-initiating the refresh instruction upon receiving the status event notification until the refresh instruction is successfully executed or the termination condition is met.

[0029] In some examples, applications implement a timed retry mechanism by registering Status events with the terminal at specific time intervals. Each time a retry is initiated, the total duration *t* accumulated since the first failed Refresh command is recorded. This time *t* is then compared with several pre-configured key parameters based on the log-normal distribution of call duration to determine the current call termination probability interval. Depending on where *t* falls—e.g., the median neighborhood of a high-probability call termination, the outer perimeter of a low-probability but still reasonable interval, or a timeout region close to the long tail—the application dynamically selects the registration interval for the next Status event.

[0030] For example, this time interval is not fixed, but rather adaptively adjusted based on statistical patterns: a shorter retry interval is used during the period when the call is most likely to end to improve response speed, while the interval is gradually lengthened during the long tail phase where the call is less likely to continue to save resources. The entire retry strategy matches the retry rhythm with the distribution characteristics of actual user call behavior, ensuring that refresh commands are re-executed as soon as possible after the call ends, while avoiding the system overhead caused by invalid and frequent attempts.

[0031] Optionally, the above-mentioned determination of the retry time interval corresponding to the refresh command based on the cumulative duration of the current call and the call duration distribution characteristic parameters may specifically include: when the cumulative duration is less than the first interval threshold, the interval value is determined as the retry time interval, and the first interval threshold is the difference between the median duration and the interval value; when the cumulative duration is between the first interval threshold and the second interval threshold, the ratio of the interval value to the retry granularity is determined as the retry time interval, and the second interval threshold is the sum of the median duration and the interval value; when the cumulative duration is between the second interval threshold and the lower limit of the confidence interval, the interval value is determined as the retry time interval; when the cumulative duration is between the lower limit of the confidence interval and the retry time limit threshold, the retry time interval is determined according to the time interval sequence, and the first term of the time interval sequence is determined based on the interval value; when the cumulative duration reaches or exceeds the retry time limit threshold, the retry process is terminated and an anomaly marker is recorded.

[0032] For example, when When the application registers a Status event with a time interval of s, it attempts to initiate a Refresh command to retry upon receiving the Status event. If the retry is successful, the process ends; otherwise, it repeats the process. Here, μ* is the median value of the duration. X Approximate value, The threshold value for the first interval is... This is the threshold for the second interval.

[0033] For example, when When the application registers a Status event with a time interval of s / p, it attempts to initiate a Refresh command to retry upon receiving the Status event. If the retry is successful, the process ends; otherwise, step five is repeated. For example, n is the lower limit of the confidence interval, M is the retry time limit threshold, and when t∈(n,M), the application registers the status event time interval sequence T. d The following conditions must be met:

[0034] In some examples, the time interval d increases in the order of 2s, 4s…2is (i≥1), and the application follows the sequence T. d Register a Status event, incrementing the value of i by 1 each time a Status event is registered, and attempt to initiate a Refresh command to retry when a Status event is received. If the retry is successful, the process ends; otherwise, repeat this step.

[0035] For example, when t∈[M,+∞), the application will not retry, but will record the execution result and report it to the platform for marking.

[0036] For example, this embodiment introduces the log-normal distribution property of call duration and combines it with the Status event to flexibly update the time interval at which the application is triggered. This allows for different time intervals to be used to retry the Refresh command based on the different intervals in which the current call duration falls, thereby ensuring that the command takes effect as soon as possible and that the file update configuration takes effect on the terminal side as soon as possible, ensuring efficient execution.

[0037] Optionally, the method in this embodiment may further include: if a second result code is received from the terminal, an abnormal execution result and a user interaction instruction are generated, wherein the second result code indicates that the current terminal does not support the refresh instruction, and the user interaction instruction is used to trigger the terminal to display a restart prompt or a card insertion / removal prompt; the abnormal execution result is recorded in the log storage area of ​​the SIM card and reported to the server.

[0038] For example, if the value of the result code is greater than or equal to 0x30, then the current result code is determined to be the second result code, which means that the current terminal does not support the Refresh command. At this time, the application can prompt the user to perform actions such as restarting the terminal or inserting / removing the card through the DISPLAY TEXT or GET INKEY pop-up window so that the card file update takes effect. The card application can terminate / continue the business process as needed, record the relevant results, and report them to the platform for marking when necessary.

[0039] In some examples, such as Figure 3As shown, the Refresh command can be initiated by the SIM card to trigger the terminal to re-power the card. In scenarios such as SIM card process blocking and terminal session abnormality, it can effectively restore the card status to normal. However, the priority of the Refresh command is lower than the call priority. When the terminal is in a call, the Refresh command cannot be initiated normally. The retry mechanism for card application refresh commands proposed in this embodiment is based on the log-normal distribution property of call duration. The specific parameters of the probability density function are determined by the service platform in combination with large network data, and approximate values ​​are processed to take into account the limited hardware resources of the SIM card. After calculating several key values, the business platform updates the user's SIM card application configuration remotely. Subsequently, when the business platform issues business commands, if the command execution process involves a Refresh command, this retry mechanism will be triggered if an exception occurs during Refresh command execution. First, the application will judge based on the execution result returned by the terminal when executing the Refresh command, i.e., the Terminal Response. If the Refresh command executes successfully, the SIM card will be directly reset without receiving a Terminal Response. If the Terminal Response returns a value greater than or equal to 0x30, it indicates that the terminal does not support the command at all, retrying is meaningless, and the process terminates. If the Terminal Response is 0x20, it indicates that the terminal temporarily does not support executing the command. At this time, the application will count the duration and determine which interval of the log-normal distribution of call duration the current time falls into. Based on the current interval, the application will register Status events of different durations. When a Status event occurs, the terminal will notify the application, which will then initiate a retry. The application will continuously adjust the retry duration based on the distribution interval of the current total duration until the retry is successful and the card is reset. The Status event is used by the terminal to periodically detect the card status. The SIM card application can modify the notification interval of the Status event through instructions. When the application registers the Status event at a specific time interval, the terminal will notify the application at that time interval, thereby triggering the application to execute a specific process.

[0040] Compared to existing technologies, by applying the technical solution of this embodiment, the SIM card can efficiently and quickly complete the retry operation of the Refresh command in scenarios such as calls where the Refresh command cannot be executed immediately. For example, after the SIM card updates its internal file system, the file cache on the terminal side is usually not refreshed immediately, causing the configuration change to fail to take effect. In this case, the Refresh command is needed to trigger the terminal to reread the data in the card. Similarly, when the SIM card is in an abnormal state, the Refresh command can be used to reset the card and restore normal operation. However, when the terminal is in a call, the Refresh command will be refused to execute. To address this issue, the service platform and the SIM card can, based on the retry mechanism proposed in this proposal and considering the statistical characteristic that call duration follows a log-normal distribution, dynamically adjust the retry interval of the Refresh command according to the distribution range of the accumulated waiting time since the first failure: a shorter retry interval is used in the high-probability interval where the call is most likely to end, to improve response speed; the interval is appropriately extended in the long-tail interval where the call is less likely to continue, to avoid invalid attempts. This ensures that the Refresh command is successfully executed as soon as the call ends, achieving the target function of configuration update or state recovery.

[0041] Accordingly, to further illustrate the data refresh process, this embodiment provides the following: Figure 4 The specific method shown is applied to a terminal, and the method includes: Step 201: In response to the refresh command initiated by the smart card module, check whether the current state of the terminal meets the execution conditions of the refresh command.

[0042] Optionally, step 201 may specifically include: determining whether the current state of the terminal meets the execution conditions of the refresh instruction by querying the terminal's call status register, radio resource control layer state machine and / or smart card module interface busy / idle flag.

[0043] For example, the detection process may include querying multiple key state information sources within the terminal, such as the call status register to determine if the user is in a call, the radio resource control layer state machine to confirm whether the current radio connection is in an idle or high-priority service phase of a connected state, and the busy / idle flag of the SIM card interface to determine whether the SIM card channel is occupied by other operations. Only when it is confirmed that no high-priority task is running, radio resources are available, and the SIM interface is idle will the terminal determine that the current state meets the execution conditions of the Refresh instruction; otherwise, it will refuse to execute and return the corresponding error result code.

[0044] Step 202: If the current state of the terminal meets the execution conditions of the refresh instruction, then execute the refresh instruction.

[0045] In some examples, when the terminal successfully executes the Refresh command, it will immediately power off and then power on the SIM card to reset the card. During the entire process, the SIM card application will not receive any response or confirmation message from the terminal. If the execution fails, the terminal will return the relevant result code through Terminal Response.

[0046] Optionally, step 202 may specifically include: clearing the smart card module file data in the terminal cache; and rereading the updated file content from the smart card module into the terminal cache.

[0047] For example, clearing the SIM card file data stored in the terminal cache can ensure that old or outdated configuration information is completely removed. Then, the updated file content is read again from the SIM card's file system and loaded into the terminal cache, enabling the terminal to perform subsequent operations or provide corresponding services based on the latest in-card data.

[0048] Step 203: If the current state of the terminal does not meet the execution conditions of the refresh instruction, send the result code to the smart card module.

[0049] For example, the result code may include a first result code and a second result code, wherein the value of the first result code is 0x20, indicating that the current state of the terminal does not allow the execution of the Refresh command, and the value of the second result code is greater than or equal to 0x30, indicating that the current terminal does not support the Refresh command.

[0050] Optionally, the method in this embodiment may further include: in response to a status event registered by the smart card module, sending a status event notification to the smart card module when the notification period of the status event arrives.

[0051] In some examples, when the notification period set for the status event arrives, the terminal proactively sends a status event notification to the SIM card to trigger the application on the card to perform a preset subsequent operation, such as retrying the Refresh command.

[0052] Compared to existing technologies, by applying the technical solution of this embodiment, the SIM card can efficiently and quickly complete the retry operation of the Refresh command in scenarios such as calls where the Refresh command cannot be executed immediately. For example, after the SIM card updates its internal file system, the file cache on the terminal side is usually not refreshed immediately, causing the configuration change to fail to take effect. In this case, the Refresh command is needed to trigger the terminal to reread the data in the card. Similarly, when the SIM card is in an abnormal state, the Refresh command can be used to reset the card and restore normal operation. However, when the terminal is in a call, the Refresh command will be refused to execute. To address this issue, the service platform and the SIM card can, based on the retry mechanism proposed in this proposal and considering the statistical characteristic that call duration follows a log-normal distribution, dynamically adjust the retry interval of the Refresh command according to the distribution range of the accumulated waiting time since the first failure: a shorter retry interval is used in the high-probability interval where the call is most likely to end, to improve response speed; the interval is appropriately extended in the long-tail interval where the call is less likely to continue, to avoid invalid attempts. This ensures that the Refresh command is successfully executed as soon as the call ends, achieving the target function of configuration update or state recovery.

[0053] Accordingly, to further illustrate the data refresh process, this embodiment provides the following: Figure 5 The specific method shown is applied to the server side, and the method includes: Step 301: Determine the call duration distribution characteristic parameters based on historical call data.

[0054] Optionally, the call duration distribution feature parameters include one or more of the following: median duration, lower limit of confidence interval, interval value, retry granularity, and retry time limit threshold; correspondingly, step 301 may specifically include: determining the median duration, lower limit of confidence interval, interval value, retry granularity, and retry time limit threshold based on the log-normal distribution characteristics of historical call data.

[0055] For example, before the application is used for the first time, the business platform sends the relevant configuration of the retry policy to the application, which determines the retry granularity, maximum retry time limit, and key time nodes for retry.

[0056] In some examples, the call duration of users follows a log-normal distribution, meaning that the call duration of most users will be concentrated around a specific value, and the overall distribution is right-skewed (positively skewed). Numerically, this means that most calls will end within a certain duration, and only a few will last for a long time.

[0057] For example, based on the analysis of a large amount of historical user call data, the business platform confirms that the overall call duration exhibits a typical statistical pattern: most calls are concentrated around a common duration, while longer or extremely short calls account for a smaller proportion, with the overall distribution skewed to the right. Based on this pattern, the platform can calculate a set of key parameters that effectively describe this distribution characteristic, including the median representing typical call duration, the lower limit of the 95% confidence interval covering most call scenarios, the range value used to divide different retry strategy intervals, the granularity for controlling the retry frequency during periods with a high probability of call termination, and the maximum retry time limit set to avoid infinite waiting. Considering the limited processing power of SIM cards, which do not support complex mathematical operations and high-precision numerical representations, all these parameters are accurately calculated on the business platform side, then simplified and integerized to ensure efficient storage and use in resource-constrained card environments.

[0058] For example, the probability density function of the logarithmic distribution of call duration can be determined by the following formula:

[0059] Where μ and σ are the mean and standard deviation of the logarithmic distribution, respectively. The business platform determines the specific values ​​of μ and σ based on historical call data, and determines the median call duration μ according to the following formula. X With geometric standard deviation σ X :

[0060] In some examples, due to limitations in SIM card computing power and resources, some complex operations, such as index fetching, logarithmic fetching, and certain data types, such as floating-point numbers, are not supported by the SIM card. Therefore, the above values ​​need to be pre-calculated and processed, using rounding down to obtain an approximate value μ* of the median duration.

[0061] For example, a 95% confidence interval is used to describe the distribution range of the original data X, indicating that there is a 95% probability that the data will fall within this interval. Here, only the lower limit is needed to define the distribution of the total duration interval. To determine the lower limit of the 95% confidence interval, let its corresponding value be n. Then n can be obtained by the following formula:

[0062] In some examples, since the SIM card retry interval depends on the Status event, a minimum configurable interval value t is set. min Depending on the type of terminal, t min The interval is typically 2-5 seconds. First, determine the interval value s using the following formula:

[0063] In some examples, the retry granularity p should satisfy:

[0064] In some examples, the business platform determines the maximum retry time limit M based on the distribution of historical call data. Based on experience, the call duration is generally no more than 1 hour, so M can be 1 hour or, considering the coverage of 95% of the data range, M=n can be directly chosen.

[0065] Step 302: Encapsulate the call duration distribution feature parameters into configuration data.

[0066] In some examples, configuration data is used to dynamically adjust the retry strategy for refresh commands when execution fails.

[0067] Optionally, step 302 may specifically include: encoding the call duration distribution feature parameters according to a preset data format to generate a target configuration data frame.

[0068] In some examples, the business platform encapsulates call duration distribution characteristic parameters in the format shown in Table 1 and updates the relevant configuration of the card application through the application configuration update interface. The parameter format can be encapsulated in TLV format, and the application configuration can be updated remotely or by writing to the card using a card reader.

[0069] Table 1

[0070] Step 303: Send the configuration data to the SIM card.

[0071] For example, after completing the update of the application's refresh instruction policy configuration, the service platform can send service instructions to the SIM card application normally via downlink SMS or other remote channels. These instructions may involve operations such as file updates, permission activation, and network configuration changes. When the execution process requires triggering a SIM card reset to make the changes take effect, the card application will automatically initiate a dynamic retry mechanism in the event that the REFRESH instruction fails, based on the configured retry policy.

[0072] Compared to existing technologies, by applying the technical solution of this embodiment, the SIM card can efficiently and quickly complete the retry operation of the Refresh command in scenarios such as calls where the Refresh command cannot be executed immediately. For example, after the SIM card updates its internal file system, the file cache on the terminal side is usually not refreshed immediately, causing the configuration change to fail to take effect. In this case, the Refresh command is needed to trigger the terminal to reread the data in the card. Similarly, when the SIM card is in an abnormal state, the Refresh command can be used to reset the card and restore normal operation. However, when the terminal is in a call, the Refresh command will be refused to execute. To address this issue, the service platform and the SIM card can, based on the retry mechanism proposed in this proposal and considering the statistical characteristic that call duration follows a log-normal distribution, dynamically adjust the retry interval of the Refresh command according to the distribution range of the accumulated waiting time since the first failure: a shorter retry interval is used in the high-probability interval where the call is most likely to end, to improve response speed; the interval is appropriately extended in the long-tail interval where the call is less likely to continue, to avoid invalid attempts. This ensures that the Refresh command is successfully executed as soon as the call ends, achieving the target function of configuration update or state recovery.

[0073] Furthermore, as Figure 1 The specific implementation of the method shown in this embodiment provides a data refresh device applied to a smart card module, such as... Figure 6 As shown, the device includes: a receiving module 41, an initiating module 42, and an execution module 43.

[0074] The receiving module 41 is configured to receive configuration data sent by the server; Initiation module 42 is configured to send a refresh command to the terminal in response to a refresh process triggered by the business execution process; The execution module 43 is configured to execute the retry strategy of the refresh instruction according to the configuration data if it receives a first result code returned by the terminal. The first result code indicates that the current state of the terminal does not support the execution of the refresh instruction.

[0075] In some examples of this embodiment, the configuration data includes call duration distribution characteristic parameters; correspondingly, the execution module 43 is specifically configured to determine the retry time interval corresponding to the refresh instruction based on the cumulative duration of the current call and the call duration distribution characteristic parameters; initiate a registration instruction for a status event to the terminal and set the notification period of the status event to the retry time interval; and re-initiate the refresh instruction upon receiving a status event notification until the refresh instruction is successfully executed or the termination condition is met.

[0076] In some examples of this embodiment, the call duration distribution feature parameters include one or more of the following: median duration, lower limit of confidence interval, interval value, retry granularity, and retry time limit threshold. Correspondingly, the execution module 43 is further configured to: when the cumulative duration is less than a first interval threshold, determine the interval value as the retry time interval, where the first interval threshold is the difference between the median duration and the interval value; when the cumulative duration is between the first interval threshold and a second interval threshold, determine the ratio of the interval value to the retry granularity as the retry time interval, where the second interval threshold is the sum of the median duration and the interval value; when the cumulative duration is between the second interval threshold and the lower limit of confidence interval, determine the interval value as the retry time interval; when the cumulative duration is between the lower limit of confidence interval and the retry time limit threshold, determine the retry time interval based on a time interval sequence, where the first term of the time interval sequence is determined based on the interval value; when the cumulative duration reaches or exceeds the retry time limit threshold, terminate the retry process and record an anomaly flag.

[0077] In some examples of this embodiment, the execution module 43 is further configured to generate an abnormal execution result and a user interaction instruction if it receives a second result code returned by the terminal. The second result code indicates that the current terminal does not support the refresh instruction, and the user interaction instruction is used to trigger the terminal to display a restart prompt or a card insertion / removal prompt. The abnormal execution result is recorded in the log storage area of ​​the smart card module and reported to the server.

[0078] Furthermore, as Figure 4 The specific implementation of the method shown in this embodiment provides a data refresh device applied to a terminal, such as... Figure 7 As shown, the device includes: a detection module 51, an execution module 52, and a transmission module 53.

[0079] The detection module 51 is configured to detect whether the current state of the terminal meets the execution conditions of the refresh command in response to the refresh command initiated by the smart card module. The execution module 52 is configured to execute the refresh instruction if the current state of the terminal meets the execution conditions of the refresh instruction; The sending module 53 is configured to send a result code to the smart card module if the current state of the terminal does not meet the execution conditions of the refresh instruction.

[0080] In some examples of this embodiment, the detection module 51 is further configured to determine whether the current state of the terminal meets the execution conditions of the refresh instruction by querying the terminal's call status register, radio resource control layer state machine and / or smart card module interface busy / idle flag.

[0081] In some examples of this embodiment, the execution module 52 is further configured to clear the smart card module file data in the terminal cache; and to reread the updated file content from the smart card module into the terminal cache.

[0082] In some examples of this embodiment, the sending module 53 is further configured to send a status event notification to the smart card module when the notification period of the status event arrives in response to a status event registered by the smart card module.

[0083] Furthermore, as Figure 5 The specific implementation of the method shown in this embodiment provides a data refresh device applied to the server side, such as... Figure 8 As shown, the device includes: a determining module 61, an encapsulation module 62, and a sending module 63.

[0084] The determination module 61 is configured to determine the call duration distribution characteristic parameters based on historical call data; The encapsulation module 62 is configured to encapsulate the call duration distribution feature parameters into configuration data, which is used to dynamically adjust the retry strategy of the refresh instruction when the refresh instruction fails to be executed. The sending module 63 is configured to send the configuration data to the smart card module.

[0085] In some examples of this embodiment, the call duration distribution feature parameters include one or more of the following: median duration, lower limit of confidence interval, interval value, retry granularity, and retry time limit threshold; correspondingly, the determining module 61 is further configured to determine the median duration, lower limit of confidence interval, interval value, retry granularity, and retry time limit threshold based on the log-normal distribution feature of the historical call data.

[0086] In some examples of this embodiment, the encapsulation module 62 is further configured to encode the call duration distribution feature parameters according to a preset data format to generate a target configuration data frame.

[0087] It should be noted that for other corresponding descriptions of the various functional units involved in the data refresh device provided in this embodiment, please refer to... Figure 1 , Figure 4 and Figure 5 The corresponding descriptions in [the document] will not be repeated here.

[0088] Based on the above, Figure 1 , Figure 4 and Figure 5 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figure 1 , Figure 4 and Figure 5 The method shown.

[0089] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0090] Based on the above, Figure 1 , Figure 4 and Figure 5 The method shown, and Figure 6 , Figure 7 and Figure 8 To achieve the above objectives, the present application also provides an electronic device, such as a personal computer, server, laptop computer, intelligent robot, or other intelligent terminal, as illustrated in the virtual device embodiment. This device includes a storage medium and a processor; the storage medium stores a computer program; and the processor executes the computer program to implement the above-described virtual device. Figure 1 , Figure 4 and Figure 5 The method shown.

[0091] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0092] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0093] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0094] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms, or it can be implemented by hardware. By applying the solution of this embodiment, compared with the prior art, this embodiment can effectively solve the problem that the Refresh command cannot be executed during the operation of high-priority tasks such as calls, resulting in the SIM card file update configuration not taking effect immediately on the terminal side. By introducing this retry mechanism, the system is compatible with high-priority scenarios such as calls, significantly improving the availability of the Refresh command, so that the remote update of the SIM card file can take effect in a timely manner without the user manually restarting the terminal or removing and inserting the card. The retry time interval strategy adopted by this mechanism is not fixed or random, but dynamically adjusted based on the log-normal distribution characteristics of the actual user call duration. A more intensive retry rhythm is adopted in the time interval of high probability call end, while the interval is gradually lengthened in the long tail interval, which not only ensures that the refresh operation can be executed as soon as possible, but also controls the number of retries within a reasonable range to avoid resource waste. This allows operators to implement "hot updates" of SIM card files. For example, they can remotely modify the User Service Table (UST) file to enable functions such as call event acquisition and call forwarding, or update authentication-related file clusters to dynamically control the terminal's access permissions to the mobile network. Previously, such operations typically required a terminal restart or SIM card power-on to trigger a cache refresh, resulting in a poor user experience. This embodiment supports the SIM card proactively initiating a refresh and intelligently retrying, ensuring that even if the user is in a call, a reset and configuration synchronization can be quickly completed after the call ends. For example, when a temporary service suspension occurs during a call, this retry mechanism can be used to take effect immediately after the call ends, ensuring the suspension command is executed on time and improving service reliability.

[0095] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0096] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A data refresh method, characterized in that, Applications in smart card modules include: Receive configuration data sent by the server; In response to the refresh process triggered by the business execution process, a refresh command is sent to the terminal; If a first result code is received from the terminal, the retry strategy for the refresh instruction is executed according to the configuration data. The first result code indicates that the current state of the terminal does not support the execution of the refresh instruction.

2. The method according to claim 1, characterized in that, The configuration data includes call duration distribution characteristic parameters; The retry strategy for executing the refresh instruction based on the configuration data includes: The retry time interval corresponding to the refresh command is determined based on the cumulative duration of the current call and the call duration distribution characteristic parameters. Send a registration instruction for the status event to the terminal, and set the notification period of the status event to the retry time interval; Upon receiving a status event notification, the refresh command is re-initiated until the refresh command is successfully executed or the termination condition is met.

3. The method according to claim 2, characterized in that, The call duration distribution feature parameters include one or more of the following: median duration, lower limit of confidence interval, interval value, retry granularity, and retry time limit threshold. The step of determining the retry time interval corresponding to the refresh command based on the cumulative duration of the current call and the call duration distribution characteristic parameters includes: When the cumulative duration is less than the first interval threshold, the interval value is determined as the retry time interval, and the first interval threshold is the difference between the median duration and the interval value. When the cumulative duration is between the first interval threshold and the second interval threshold, the ratio of the interval value to the retry granularity is determined as the retry time interval, and the second interval threshold is the sum of the median duration and the interval value; When the cumulative duration is between the second interval threshold and the lower limit of the confidence interval, the interval value is determined as the retry time interval; When the cumulative duration is between the lower limit of the confidence interval and the retry time limit threshold, the retry time interval is determined based on the time interval sequence, and the first term of the time interval sequence is determined based on the interval value; When the cumulative duration reaches or exceeds the retry timeout threshold, the retry process is terminated and an exception flag is recorded.

4. The method according to claim 1, characterized in that, After sending a refresh command to the terminal, the method further includes: If the second result code returned by the terminal is received, an abnormal execution result and a user interaction instruction are generated. The second result code indicates that the current terminal does not support the refresh instruction. The user interaction instruction is used to trigger the terminal to display a restart prompt or a card insertion / removal prompt. The abnormal execution result is recorded in the log storage area of ​​the smart card module and reported to the server.

5. A data refresh method, characterized in that, Applied to terminals, including: In response to a refresh command initiated by the smart card module, the terminal's current state is checked to see if it meets the conditions for executing the refresh command. If the current state of the terminal meets the execution conditions of the refresh instruction, then the refresh instruction is executed; If the current state of the terminal does not meet the conditions for executing the refresh instruction, a result code is sent to the smart card module.

6. The method according to claim 5, characterized in that, Whether the current state of the detection terminal meets the conditions for executing the refresh command includes: By querying the terminal's call status register, radio resource control layer state machine, and / or smart card module interface busy / idle flags, it can be determined whether the terminal's current state meets the conditions for executing the refresh instruction.

7. The method according to claim 5, characterized in that, Executing the refresh instruction includes: Clear the smart card module file data in the terminal cache; The updated file content is reread from the smart card module and stored in the terminal cache.

8. The method according to claim 5, characterized in that, The method further includes: In response to a status event registered by the smart card module, a status event notification is sent to the smart card module when the notification period for the status event arrives.

9. A data refresh method, characterized in that, Applied to the server side, including: Based on historical call data, determine the characteristic parameters of call duration distribution; The call duration distribution feature parameters are encapsulated into configuration data, which is used to dynamically adjust the retry strategy of the refresh command when the refresh command fails to be executed. The configuration data is sent to the smart card module.

10. The method according to claim 9, characterized in that, The call duration distribution feature parameters include one or more of the following: median duration, lower limit of confidence interval, interval value, retry granularity, and retry time limit threshold. The process of determining call duration distribution characteristic parameters based on historical call data includes: Based on the log-normal distribution characteristics of the historical call data, the median duration, lower limit of the confidence interval, interval value, retry granularity, and retry time limit threshold are determined.

11. The method according to claim 9, characterized in that, The step of encapsulating the call duration distribution feature parameters into configuration data includes: The call duration distribution feature parameters are encoded according to a preset data format to generate a target configuration data frame.

12. A data refresh device, characterized in that, Applications in smart card modules include: The receiving module is configured to receive configuration data sent by the server. The initiation module is configured to send a refresh command to the terminal in response to a refresh process triggered by the business execution process. The execution module is configured to execute the retry strategy of the refresh instruction according to the configuration data if it receives a first result code returned by the terminal, wherein the first result code indicates that the current state of the terminal does not support the execution of the refresh instruction.

13. A data refresh device, characterized in that, Applied to terminals, including: The detection module is configured to detect whether the current state of the terminal meets the execution conditions of the refresh command in response to the refresh command initiated by the smart card module. The execution module is configured to execute the refresh instruction if the current state of the terminal meets the execution conditions of the refresh instruction; The sending module is configured to send a result code to the smart card module if the current state of the terminal does not meet the execution conditions of the refresh instruction.

14. A data refresh device, characterized in that, Applied to the server side, including: The determination module is configured to determine call duration distribution characteristic parameters based on historical call data; The encapsulation module is configured to encapsulate the call duration distribution feature parameters into configuration data, which is used to dynamically adjust the retry strategy of the refresh instruction when the refresh instruction fails to be executed. The sending module is configured to send the configuration data to the smart card module.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 11.

16. An electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 11.

17. A computer program product having a computer program stored thereon, characterized in that, When the computer program product is executed by a processor, it implements the method of any one of claims 1 to 11.

Images