Risk prompting method, terminal, server and storage medium

Abstract

The application discloses a risk prompting method and device, a terminal and a server. The method comprises the following steps: in response to a trigger operation of entering a resource transfer process performed by a user in a target application, querying a server for a risk label corresponding to a mobile terminal to which the target application belongs, the risk label being used for indicating whether the mobile terminal has a risk of disconnection, the risk label being determined by the server based on call transfer state data reported by the mobile terminal, the call transfer state data being obtained by the mobile terminal based on an operating system of the mobile terminal and uploaded to the server after the user logs in the target application by authorization; and if the risk label indicates that the mobile terminal has a risk of disconnection, outputting risk prompting information, the risk prompting information being used for prompting that a current resource transfer operation has a risk.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a risk warning method, terminal, server, and storage medium. Background Technology

[0002] Current scams are becoming increasingly sophisticated. Fraudsters, without the user's knowledge, use conferencing software to guide them to set their phones to forward calls to an unanswered number, then lure them into making transactions on various financial service platforms. Because the user's phone is in call forwarding mode, calls from relatives or the police are also redirected to an unanswered number, preventing timely notification of the scam and ultimately resulting in financial loss. Therefore, there is an urgent need for a solution that can effectively alert users to the risks of fraud. Summary of the Invention

[0003] The purpose of this application is to provide a risk warning method, terminal, server, and storage medium for effectively alerting users to fraud risks.

[0004] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0005] In a first aspect, embodiments of this application provide a risk warning method, the method comprising: responding to a user's triggering operation of entering a resource transfer process in a target application, querying a server for a risk tag corresponding to the mobile terminal to which the target application belongs, the risk tag being used to indicate whether the mobile terminal is at risk of losing contact, the risk tag being determined by the server based on call forwarding status data reported by the mobile terminal, the call forwarding status data being obtained by the mobile terminal based on the mobile terminal's operating system and uploaded to the server after the user authorizes login in the target application; if the risk tag indicates that the mobile terminal is at risk of losing contact, then outputting risk warning information, the risk warning information being used to indicate that the current resource transfer operation is at risk.

[0006] Secondly, embodiments of this application provide a risk warning method applied to a server. The method includes: receiving call forwarding status data reported by a mobile terminal to which a target application belongs, the call forwarding status data indicating whether the mobile terminal to which the target application belongs is in a call forwarding state; determining a risk label corresponding to the mobile terminal based on the call forwarding status data, the risk label indicating whether the mobile terminal is at risk of losing contact; and returning the risk label to the mobile terminal when the mobile terminal has a trigger operation to enter a resource transfer process, so as to instruct the mobile terminal to output risk warning information when the risk label indicates that the mobile terminal is at risk of losing contact, the risk warning information indicating that the current resource transfer operation is risky, and the trigger operation is input by the user in the target application.

[0007] Thirdly, embodiments of this application provide a risk warning device, the device comprising: a query unit, configured to, in response to a user's triggering operation of entering a resource transfer process in a target application, query the server for a risk tag corresponding to the mobile terminal to which the target application belongs, the risk tag being used to indicate whether the mobile terminal is at risk of losing contact, the risk tag being determined by the server based on the call forwarding status reported by the mobile terminal, the call forwarding status data being obtained by the mobile terminal based on the mobile terminal's operating system and uploaded to the server after the user authorizes login in the target application; and a display unit, configured to, if the risk tag indicates that the mobile terminal is at risk of losing contact, output risk warning information, the risk warning information being used to indicate that the current resource transfer operation is at risk.

[0008] Fourthly, this application provides a risk warning device applied to a server. The device includes: a receiving unit, configured to receive call forwarding status data reported by a mobile terminal to which a target application belongs, the call forwarding status data indicating whether the mobile terminal to which the target application belongs is in a call forwarding state; a determining unit, configured to determine a risk label corresponding to the mobile terminal based on the call forwarding status data, the risk label indicating whether the mobile terminal is at risk of losing contact; and a sending unit, configured to return the risk label to the mobile terminal when the mobile terminal has a trigger operation to enter a resource transfer process, to instruct the mobile terminal to output risk warning information when the risk label indicates that the mobile terminal is at risk of losing contact, the risk warning information indicating that the current resource transfer operation is risky, the trigger operation being input by the user in the target application.

[0009] Fifthly, embodiments of this application provide a terminal, including: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the method as described in the first aspect.

[0010] In a sixth aspect, embodiments of this application provide a server, including: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the method as described in the second aspect.

[0011] In a seventh aspect, embodiments of this application provide a computer-readable storage medium that, when the instructions in the storage medium are executed by the processor of an electronic device, enables the electronic device to perform the method described in the first aspect; or, when the instructions in the storage medium are executed by the processor of an electronic device, enables the electronic device to perform the method described in the second aspect. The at least one technical solution adopted in the embodiments of this application can achieve the following beneficial effects: the mobile terminal to which the target application belongs obtains its own call forwarding status data and reports it to the server, which then assigns a corresponding risk label to the mobile terminal based on the call forwarding status data; furthermore, in response to the user's triggering operation of entering the forwarding process in the target application, the mobile terminal queries the server for the risk label corresponding to the mobile terminal to determine whether the mobile terminal is at risk of losing contact. If the mobile terminal is at risk of losing contact, a risk warning message is also output to inform the user that the current resource transfer operation is risky, so that the user can receive an effective risk warning in a timely manner even when the mobile terminal is in a call forwarding state, so as to quickly determine whether they have been defrauded and stop the loss in time. It can be seen that the risk warning method provided in the embodiments of this application can effectively alert users to fraud risks and is conducive to improving the fraud risk identification rate. Attached Figure Description

[0012] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0013] Figure 1 A schematic diagram illustrating an application scenario of a risk warning method provided in one embodiment of this application;

[0014] Figure 2 A flowchart illustrating a risk warning method provided in one embodiment of this application;

[0015] Figure 3 A flowchart illustrating a method for obtaining call transfer status data, provided as an embodiment of this application;

[0016] Figure 4A flowchart illustrating a method for obtaining call transfer status data, provided as another embodiment of this application;

[0017] Figure 5A A flowchart illustrating a method for obtaining call transfer status data, provided as another embodiment of this application;

[0018] Figure 5B A flowchart illustrating a method for obtaining call transfer status data, provided as another embodiment of this application;

[0019] Figure 6 A schematic diagram illustrating a risk warning message provided in one embodiment of this application;

[0020] Figure 7 A flowchart illustrating a risk warning method provided for another embodiment of this application;

[0021] Figure 8 A flowchart illustrating a risk warning method provided in yet another embodiment of this application;

[0022] Figure 9 A flowchart illustrating a risk warning method provided in another embodiment of this application;

[0023] Figure 10 A schematic diagram of a risk warning device provided for one embodiment of this application;

[0024] Figure 11 A schematic diagram of a risk warning device provided for another embodiment of this application;

[0025] Figure 12 A schematic diagram of the structure of a terminal is provided for one embodiment of this application;

[0026] Figure 13 This is a schematic diagram of the structure of a server provided in one embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] The terms "first," "second," etc., used in this specification and claims are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in this specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0029] Explanation of some concepts:

[0030] Status bar local view class (_UIStatusBarLocalView) object: used to obtain view information on the status bar.

[0031] Status bar data class (UIStatusBar_Modern) object: used to retrieve data information from the status bar.

[0032] The UIStatusBarDataCellularEntry object is used to retrieve data information from the SIM card.

[0033] The UIStatusBarDataCellularEntry object is used to retrieve call forwarding status data.

[0034] ForegroundView: Used to obtain view information on older versions of iOS.

[0035] The UIStatusBarIndicatorItemView object is used to retrieve view information on older versions of iOS.

[0036] The UIStatusBarItem object is used to retrieve device call forwarding status data on older versions of iOS.

[0037] Call forwarding, also known as forward transfer, is a feature that allows users to forward incoming calls to other numbers when they do not want to answer the phone or are unable to answer it.

[0038] Always call forwarding: This means that all incoming calls to this user are forwarded to other numbers, and the user will not receive any caller ID.

[0039] Unreachable status: This means that incoming calls to this phone cannot be connected. If all incoming calls are forwarded to other numbers, relatives or the police will be unable to contact the phone number.

[0040] Anonymous device identifier: refers to a unique identifier generated by the application owner for the user's device, used to identify that applications from the same developer belong to the same device.

[0041] To effectively alert users to fraud risks, this application proposes a risk alert method. The mobile terminal belonging to the target application obtains its own call forwarding status data and reports it to the server. The server then assigns a corresponding risk tag to the mobile terminal based on the call forwarding status data. Furthermore, in response to the user's triggering operation of entering the call forwarding process within the target application, the mobile terminal queries the server for its corresponding risk tag to determine if there is a risk of loss of contact. If such a risk exists, a risk alert is output to inform the user that the current resource transfer operation is risky. This ensures that users receive timely and effective risk warnings even when their mobile terminal is in call forwarding mode, allowing them to quickly determine if they have been scammed and mitigate losses. Therefore, the risk alert method provided in this application effectively alerts users to fraud risks and improves the fraud risk identification rate. The technical solutions provided by each embodiment of this application are described in detail below with reference to the accompanying drawings.

[0042] The risk warning method provided in this application embodiment can be applied to, for example, Figure 1 In the scenario shown, the scenario includes a mobile terminal 1 and a server 2. The mobile terminal 1 has a target application installed to provide business services. The mobile terminal 1 can be, for example, at least one of a mobile phone, a smart wearable device, etc. The server 2 refers to a server used to perform business processing. In this embodiment, if a user wants to apply for resource transfer services such as withdrawal or transfer, they can launch the target application on the mobile terminal 1. After the target application is launched, it records and displays an interactive page for user operation, through which the user can perform operations related to the resource transfer service.

[0043] To prevent users from suffering losses due to fraud, mobile terminal 1 can obtain its own call forwarding status data and report it to server 2. Server 2, based on the call forwarding status data of mobile terminal 1, analyzes whether mobile terminal 1 is at risk of being out of contact and assigns a corresponding risk tag to mobile terminal 1. When a user performs a trigger operation to enter the resource transfer process in the target application, mobile terminal 1 queries server 2 for the corresponding risk tag to determine whether mobile terminal 1 is at risk of being out of contact. If mobile terminal 1 is at risk of being out of contact, a risk warning message is output to inform the user that the current resource transfer operation is risky. This allows the user to receive timely and effective risk alerts even when mobile terminal 1 is in call forwarding state, enabling them to quickly determine whether they have been scammed and stop losses in time. The risk warning method provided in this application embodiment will describe in detail the interaction process between mobile terminal 1 and server 2.

[0044] based on Figure 1 In the aforementioned application scenario, this application provides a risk warning method. Please refer to [link / reference]. Figure 2 This is a flowchart illustrating a risk warning method provided in one embodiment of this application. This method can be applied to a terminal, such as... Figure 1 The mobile terminal 1 shown is an example. Figure 2 As shown, the method may include the following steps:

[0045] S202, in response to the user's triggering operation of entering the resource transfer process in the target application, query the server for the risk label corresponding to the mobile terminal to which the target application belongs.

[0046] The target application can be an application that provides resource transfer services. A resource transfer process refers to the process of transferring resources owned by one party to another. It is worth noting that the resources in this application embodiment can include funds, currency for circulation, etc. Furthermore, the resource transfer in this application embodiment can include, for example, but is more likely to include: cash withdrawal, payment, transfer, etc.

[0047] In practical applications, the resource transfer process can be triggered in any appropriate form, and the specific settings can be configured according to actual business needs. This application embodiment does not limit this.

[0048] For example, taking cash withdrawal as an example, users can fill in credit application information, such as their name, ID number, and contact information, through the target application's credit application page. After the user completes the credit application information, the mobile terminal of the target application can send the user's credit application information to the server. The server reviews the credit application information, and if the review is approved, it determines the maximum cash withdrawal limit that can be granted to the user and automatically initiates the resource transfer process. In other words, the user's action of confirming the completion of the credit application information on the credit application page can serve as a triggering action to enter the resource transfer process.

[0049] For example, users can also trigger the resource transfer process by clicking on the resource transfer application control displayed by the target application. In other words, the user's click on the resource transfer application control can also be used as a trigger to enter the transfer process.

[0050] Optionally, after receiving a trigger operation from the user in the target application to enter the transfer process, the mobile terminal to which the target application belongs may also display a resource transfer application page. On this resource transfer application page, the user can fill in the information required to apply for resource transfer, such as the account of the transferee, the account of the transferor, and the quantity of resources to be transferred.

[0051] In this embodiment, the risk label corresponding to the mobile terminal is used to indicate whether the mobile terminal is at risk of losing contact. The risk label corresponding to the mobile terminal is determined by the server based on the call forwarding status data reported by the mobile terminal. The call forwarding status data of the mobile terminal is used to indicate whether the mobile terminal is in a call forwarding state. Specifically, the call forwarding status data of the mobile terminal can be used to indicate whether the mobile terminal is in a constant call forwarding state. In practical applications, the call forwarding status data can be represented in any appropriate form, and the specific form can be selected according to actual needs; this embodiment does not limit this. For example, the call forwarding status data can be represented by a Boolean value: if the call forwarding status of the mobile terminal is unknown, the call forwarding status data is -1; if the mobile terminal is in a call forwarding state, the call forwarding status data is 1; if the mobile terminal is not in a call forwarding state, the value of the call forwarding status data is 0, and so on.

[0052] For example, if the mobile terminal is in a call forwarding state or the call forwarding state of the mobile terminal is unknown, the server can determine that the mobile terminal is at risk of losing contact, and then assign the corresponding risk label 1 to the mobile terminal; if the mobile terminal is not in a call forwarding state, the server can determine that the mobile terminal is not at risk of losing contact, and then assign the corresponding risk label 0 to the mobile terminal.

[0053] In this embodiment of the application, the call forwarding status data of the mobile terminal is obtained by the mobile terminal based on its operating system and uploaded to the server after the user authorizes login in the target application.

[0054] In this embodiment, the mobile terminal can acquire its own call forwarding status data and report it to the server at any appropriate time. The timing of acquisition and reporting can be set according to actual needs, and this embodiment does not limit this.

[0055] Optionally, after a user authorizes login in the target application, the mobile terminal can obtain its own call forwarding status data in real time and report it to the server. "Real time" here means that the time interval between two acquisitions of call forwarding status data is very short, such as 1 second or 1 minute. This ensures the accuracy of the call forwarding status data reported to the server.

[0056] Optionally, the mobile terminal may obtain its own call forwarding status data and report it to the server when it detects that the user has successfully logged into the target application; and / or, when the user has successfully logged into the target application, the mobile terminal may display a credit application page, and in response to the user's credit application information filling operation on the credit application page, obtain its own call forwarding status data and report it to the server.

[0057] For example, after the target application starts, it can display a login page, through which users can enter login information (such as username and password) to complete the login. After the login information entered by the user is verified, it can be determined that the user has successfully logged into the target application, which can then trigger the acquisition of call forwarding status data of the mobile terminal to which the target application belongs and report it to the server. Furthermore, after the user successfully logs into the target application, the mobile terminal also enters the credit granting application process, by displaying a credit granting application page for the user to fill in credit granting application information, such as name and ID number, as well as the user's contact information; after the user fills in the credit granting application information, the user can trigger the completion control in the credit granting application information. The mobile terminal responds to the user's triggering operation of the completion control in the target application by triggering its own call forwarding status data and reporting it to the server.

[0058] Understandably, logging in and filling out credit application information are usually mandatory steps before a user requests resource transfer. By triggering the mobile terminal to retrieve its own call transfer status data and report it to the server after either of these mandatory steps, this approach not only works for most target applications providing resource transfer services, preventing missed call transfer status data collection, but also avoids excessive processing resources consumed by real-time call transfer data retrieval. Of course, to further prevent missed call transfer status data collection, it's also possible to trigger the retrieval and reporting of call transfer status data to the server after all the aforementioned mandatory steps.

[0059] In this embodiment, the mobile terminal can obtain its own call transfer status data and report it to the server through any appropriate means. The acquisition and reporting methods can be selected according to actual needs, and this embodiment does not limit them.

[0060] Optionally, to avoid the leakage of user privacy and the legality of obtaining call forwarding status data, such as Figure 3 As shown, before the mobile terminal obtains call forwarding status data according to its own operating system, the risk warning method provided in this application embodiment may further include: displaying a login page for logging into the target application; responding to the login operation performed by the user on the login page; displaying authorization prompt information; and determining the permission information of the target application for the device information of the mobile terminal based on the operation performed by the user on the authorization prompt information, wherein the authorization prompt information is used to confirm whether the target application is allowed to obtain the device information of its own mobile terminal.

[0061] For example, after entering their username and password on the login page, a user can enter an action to trigger the login control. In response to this action, the mobile terminal displays an authorization prompt on the login page asking, "Allow the target application to access the mobile terminal's device information?". If the user confirms the authorization prompt (e.g., clicks the "Confirm" option), the target application is deemed to have permission to access the mobile terminal's device information. Conversely, if the user skips the authorization prompt (e.g., clicks the "Disallow" option), the target application is deemed not to have permission to access the mobile terminal's device information.

[0062] Furthermore, in S202 above, the mobile terminal can obtain call forwarding status data based on the target application's permission information regarding the mobile terminal's device information and a call forwarding status query strategy that matches the type of the mobile terminal's operating system. The mobile terminal's operating system includes both Android and iOS systems. The call forwarding status query strategy refers to the strategy used to obtain the mobile terminal's call forwarding status data from the operating system. Different types of operating systems employ different call forwarding status query strategies to obtain call forwarding status data.

[0063] Specifically, such as Figure 3 As shown, in S202 above, if the permission information indicates that the target application does not have permission to obtain the device information of its own mobile terminal, then the call forwarding status of the mobile terminal is determined to be unknown; if the permission information indicates that the target application has permission to obtain the device information of its own mobile terminal, then the call forwarding status data of the mobile terminal is obtained based on a forwarding status query strategy that matches the type of the mobile terminal's operating system. This allows the target application to legally and accurately obtain the call forwarding status data of its own mobile terminal while ensuring user privacy.

[0064] The transition state query strategies for the two types of operating systems are explained in detail below.

[0065] Scenario 1: The mobile terminal's operating system is Android.

[0066] Since the Android system's TelephonyManager provides basic information about the mobile terminal, and the PhoneStateListener class can monitor and handle incoming call status, these two classes can be used to obtain call forwarding status data for the mobile terminal. In other words, if the mobile terminal's operating system is Android, the call forwarding status query strategy matching the operating system type includes querying the mobile terminal's call forwarding status through the operating system's TelephonyManager and PhoneStateListener classes.

[0067] Specifically, such as Figure 4 As shown, based on the above call transfer status query strategy, obtaining call transfer status data of the mobile terminal includes the following steps:

[0068] Step A1: Write the phone status listening class object and the target event type used to represent the call transfer status of the mobile terminal to the operating system through the phone manager.

[0069] Among them, the telephone status listening class object is used by the mobile terminal's operating system to call back the mobile terminal's call transfer status data and write it into memory when it listens for an event of the target event type.

[0070] For example, the `TelephonyManager.listen` method can be used to write a `PhoneStateListener` object (a phone state listener class) and the target event type `PhoneStateListener.LISTEN_CALL_FORWARDING_INDICATOR` to the TelephonyManager. This allows the operating system to listen for the occurrence of the target event type through the `PhoneStateListener` object. If the target event type occurs, it indicates a change in the call forwarding state of the mobile terminal, prompting a callback of the mobile terminal's call forwarding state data and writing it to the memory variable `deviceCfi`.

[0071] It's worth noting that the operating system resets the memory variable `deviceCfi` before writing call forwarding status data to avoid data corruption. Furthermore, the steps of the operating system calling back the call forwarding status data from the mobile terminal and the mobile terminal calling the phone manager to write the phone status listener object and the target event type to the operating system are asynchronous.

[0072] Step A2: Call the thread blocking object to block the target thread and wait for the operating system to execute the callback operation.

[0073] For example, a mobile terminal can call a CountDownLatch object to block the target thread and set a preset blocking timeout.

[0074] Step A3: If an end-blocking message is received from the operating system or the blocking of the target thread times out, the target thread is used to write the call transfer status data in memory to a preset dataset.

[0075] The target thread is used to write call forwarding status data from memory into a preset dataset. The preset dataset is a pre-created dataset used to store the call forwarding status data of the mobile terminal. For example, after writing the callback call forwarding status data into memory, the operating system also returns an end-blocking message to the mobile terminal to notify it to end the blocking of the target thread. Upon receiving the end-blocking message from the operating system or if the blocking duration of the target thread exceeds a preset timeout period, the mobile terminal uses the target thread to associate the call forwarding status data in the memory variable `deviceCfi` with the mobile terminal's anonymous device identifier and writes it into the preset dataset `dataMap` to indicate that the call forwarding status data belongs to the mobile terminal.

[0076] Furthermore, the mobile terminal reports the call transfer status data in the dataset to the server.

[0077] For example, a mobile terminal can report a preset dataset (dataMap) to the server.

[0078] Understandably, when the mobile terminal's operating system is Android, the call forwarding status can be quickly and accurately obtained through the operating system's call manager and call status monitoring class. Furthermore, using a thread-blocking object to block the thread during the process of writing the call forwarding status data from the operating system callback to the preset dataset effectively adds a synchronization lock to the operation logic of writing the call forwarding status data to the preset dataset. Moreover, writing the call forwarding status data from the operating system to the preset dataset only after the thread blocking ends or times out effectively avoids write operation concurrency issues and ensures the accuracy of the call forwarding status data reported to the server.

[0079] Scenario 2: The mobile terminal's operating system is iOS.

[0080] Extensive research on iOS mobile devices revealed that call forwarding status data is typically hidden in the status bar. Therefore, the call forwarding status can be obtained from the status bar of these devices. In other words, if the mobile device's operating system is iOS, the call forwarding status query strategy that matches the operating system type includes retrieving the call forwarding status data from the mobile device's status bar.

[0081] Specifically, such as Figure 5A As shown, based on the above call transfer status query strategy, obtaining call transfer status data of the mobile terminal includes the following steps:

[0082] Step B1: Obtain the operating system version number.

[0083] Step B2: If the operating system version number is lower than the preset version number, then obtain the operating system status bar object through the application object corresponding to the target application.

[0084] In iOS, each application has a corresponding application object. This application object is the first object created by the operating system for the application when it starts; it is a singleton object. In this embodiment, the application object (UIApplication) corresponding to the target application refers to the object created by the operating system for the target application after it starts. Application-level operations, such as operations on the status bar, can be performed through the application object (UIApplication). In practical applications, the application object (UIApplication) corresponding to the target application can be obtained through the static method sharedApplication of UIApplication.

[0085] In iOS versions below iOS 13.0, the data in the status bar could be obtained through the application object (UIApplication). However, in iOS 13.0 and later, the underlying implementation of the status bar changed, and the view implementation logic of the status bar was completely refactored. Therefore, the data in the status bar cannot be obtained from the application object (UIApplication). Thus, the default version number is iOS 13.0. If the mobile terminal's operating system version is lower than iOS 13.0, then in step B2 above, the status bar object can be obtained through the application object (UIApplication) corresponding to the target application, so that the call forwarding status data of the mobile terminal can be obtained based on this status bar object.

[0086] For example, such as Figure 5BAs shown, in step B2 above, the status bar object can be obtained by calling the valueForKeyPath method of the application object (UIApplication) with the string parameter _statusBar. Then, it is determined whether the status bar object is a status bar data class (UIStatusBar_Modern) object, where the status bar data class (UIStatusBar_Modern) object is used to obtain the data on the status bar. If not, the status bar object obtained through the application object (UIApplication) is used as the final status bar object. If it is, the final status bar object is obtained by calling the valueForKeyPath method of the status bar data class (UIStatusBar_Modern) object with the string parameter _statusBar.

[0087] Step B3: Obtain the call forwarding status data of the mobile terminal from the status bar of the mobile terminal through the status bar object.

[0088] Specifically, in step B3 above, the operating system's foreground view attribute object can be obtained through the status bar object; then, the operating system's status bar indicator view object can be obtained through the foreground view attribute object; further, the operating system's status bar data class object can be obtained through the status bar indicator view object; finally, the call forwarding status of the mobile terminal can be determined and reported to the server through the type value of the status bar data class object.

[0089] For example, such as Figure 5BAs shown, in step B3 above, the mobile terminal can obtain a view object (UIview) by calling the valueForKeyPath method of the final status bar object, passing the foreground view string parameter, and then calling the view object's subview method to obtain a list of subviews. Next, it iterates through the subview list, finding the subview of type UIStatusBarIndicatorItemView by determining the view type. This subview is the UIStatusBarIndicatorItemView object. Then, it calls the valueForKeyPath method of the UIStatusBarIndicatorItemView object, passing the item string parameter, to obtain an object instance. It then determines whether the obtained object instance is a UIStatusBarItem object. If so, it calls the valueForKeyPath method of the UIStatusBarItem object, passing the type string parameter, to obtain the mobile terminal's call forwarding status data. This data is then associated with the anonymous device identifier and written into a preset dataset callForwardingState. Finally, the preset dataset callForwardingState is reported to the server. The preset dataset callForwardingState refers to a pre-created dataset used to store call forwarding status data.

[0090] like Figure 5A As shown, based on the above call forwarding status query strategy, obtaining call forwarding status data of a mobile terminal may further include the following steps:

[0091] Step B4: If the operating system version number is not lower than the preset version number, then obtain the operating system status bar manager object through the application object corresponding to the target application.

[0092] Step B5: Use the status bar manager object to query and obtain the call forwarding status data of the mobile terminal from the status bar of the mobile terminal.

[0093] Specifically, such as Figure 5BAs shown, in step B5 above, the mobile terminal can obtain a status bar data class (UIStatusBar_Modern) object through the status bar manager (UIStatusBarManager) object. The status bar data class object is used to obtain the data on the mobile terminal's status bar. Then, it obtains the status bar call data entity class (UIStatusBarDataCellularEntry) object of the mobile terminal's Subscriber Identity Module (SIM) card through the status bar data class object. Finally, it obtains the call forwarding status data of the SIM card through the status bar call data entity class object.

[0094] For example, in step B5 above, the mobile terminal can use the `respondsToSelector` method of the `UIStatusBarManager` object to determine if the `@selector(createLocalStatusBar)` method exists. If it exists, it passes `@selector(createLocalStatusBar)` to the `performSelector` method of `UIStatusBarManager` to create a local view class (`_UIStatusBarLocalView`) object. Then, it uses the `respondsToSelector` method of this `UIStatusBarLocalView` object to determine if the `@selector(statusBar)` method exists. If it exists, it passes `@selector(statusBar)` to the `performSelector` method of the `UIStatusBarLocalView` object to create a `UIStatusBar_Modern` object. If this `UIStatusBar_Modern` object is not null, it calls the `valueForKeyPath` method of the `UIStatusBar_Modern` object, passes the string `_statusBar` to obtain the target status bar object, and then calls the `valueForKeyPath` method of the target status object, passes the string `currentData` to obtain `_UIStatusBarData`. (Status bar data information class) object; further, call the valueForKeyPath method of the UIStatusBarData object to obtain the UIStatusBarDataCellularEntry objects of SIM card 1 and SIM card 2 respectively; further, obtain the call forwarding status data of SIM card 1 through the UIStatusBarDataCellularEntry object of SIM card 1, associate the call forwarding status data of SIM card 1 with the anonymous device identifier of the mobile terminal and write it into the preset dataset callForwardingState1, and obtain the call forwarding status data of SIM card 2 through the UIStatusBarDataCellularEntry object of SIM card 2, associate the call forwarding status data of SIM card 2 with the anonymous device identifier of the mobile terminal and write it into the preset dataset callForwardingState2; finally, report the preset datasets callForwardingState1 and callForwardingState2 to the server.

[0095] This application embodiment illustrates a specific implementation of S202 described above. It should be understood that S202 can also be implemented in other ways, and this application embodiment does not limit this implementation.

[0096] S204. If the risk label corresponding to the mobile terminal indicates that the mobile terminal is at risk of losing contact, then output a risk warning message.

[0097] The risk warning information is used to indicate that the current resource transfer operation is risky. In this embodiment, the mobile terminal can output the risk warning information in any appropriate form, such as displaying the risk warning information in text form or playing the risk warning information by voice. The specific choice can be made according to actual needs, and this embodiment does not limit this.

[0098] Optionally, the risk warning information is displayed on the resource transfer application page. The resource transfer application page is displayed in response to a user's triggering action in the target application to enter the resource transfer process. Accordingly, outputting the risk warning information includes displaying the risk warning information as a pop-up window on the resource transfer application page, which can, to some extent, prevent the user from continuing to perform the next operation through the resource transfer application page, thereby increasing the user's attention to the risk warning information. Accordingly, after step 204 above, the method provided in this application embodiment may further include: canceling the display of the risk warning information in response to the user's confirmation operation of the risk warning information.

[0099] For example, such as Figure 6 As shown, if the mobile terminal is at risk of losing connection, it indicates a high probability that the user is being scammed. A pop-up window will then appear on the resource transfer application page, displaying a risk warning message: "There is a risk of fraud. Please confirm whether this resource transfer application is a voluntary action by yourself," along with "voluntary" and "involuntary" controls for the user to choose from. This provides a precise reminder to the user, allowing them to select whether the action is voluntary or involuntary. If the user closes the pop-up or selects the "voluntary" control, it is confirmed that the user is voluntarily applying for the resource transfer, and the pop-up window will be removed, allowing the user to continue the application. If the user selects the "involuntary" control, it is confirmed that the user is aware of the potential for fraud and may terminate the resource transfer application.

[0100] Optionally, after S204 above, the risk warning method provided in this application embodiment may further include: receiving a transfer request operation performed by a user on a resource transfer request page; and sending a resource transfer request to a server based on the transfer request operation, wherein the resource transfer request is used to request the transfer of resources used by the transferor to the transferee. For example, the mobile terminal may obtain the information required for the resource transfer application filled in by the user on the resource transfer request page of the target application, such as the transferee's account, the transferor's account, and the quantity of resources to be transferred, and then send the information required for the resource transfer application to the server in the resource transfer request, so that the server can complete the resource transfer operation based on the information required for the resource transfer application.

[0101] The risk alert method provided by one or more embodiments of this application involves the mobile terminal to which the target application belongs acquiring its own call forwarding status data and reporting it to the server. The server then assigns a corresponding risk label to the mobile terminal based on the call forwarding status data. Furthermore, in response to a user's triggering operation to enter the call forwarding process within the target application, the mobile terminal queries the server for the corresponding risk label to determine if there is a risk of loss of contact. If there is a risk of loss of contact, a risk alert is output to inform the user that the current resource transfer operation is risky. This ensures that the user receives timely and effective risk warnings even when the mobile terminal is in call forwarding mode, allowing them to quickly determine if they have been scammed and mitigate losses. Therefore, the risk alert method provided by the embodiments of this application can effectively alert users to fraud risks, thus improving the fraud risk identification rate.

[0102] based on Figure 1 In the aforementioned application scenario, this application provides another risk warning method. Please refer to [link / reference]. Figure 7 This is a flowchart illustrating a risk warning method provided in one embodiment of this application. This method can be applied to a server, such as... Figure 1 Server 2 is shown. (As shown) Figure 7 As shown, the method may include the following steps:

[0103] S702, receive call transfer status data reported by the mobile terminal to which the target application belongs.

[0104] The call forwarding status data reported by the mobile terminal is used to indicate whether the mobile terminal is in a call forwarding state.

[0105] S704, based on the call transfer status data of the mobile terminal, determines the risk label corresponding to the mobile terminal.

[0106] Among them, the risk label corresponding to the mobile terminal is used to indicate whether the mobile terminal is at risk of losing connection.

[0107] For example, if the mobile terminal is in a call forwarding state or the call forwarding state of the mobile terminal is unknown, the server can determine that the mobile terminal is at risk of losing contact, and then assign the corresponding risk label 1 to the mobile terminal; if the mobile terminal is not in a call forwarding state, the server can determine that the mobile terminal is not at risk of losing contact, and then assign the corresponding risk label 0 to the mobile terminal.

[0108] In this embodiment, the server can determine the risk label corresponding to the mobile terminal at any appropriate time. The specific settings can be configured according to actual business needs, and this embodiment does not limit this.

[0109] Optionally, prior to S704 above, the risk warning method provided in this application embodiment may further include: receiving a credit request sent by a mobile terminal, the credit request carrying the user's credit application information, the credit request being used to request processing of the user's credit application information; and processing the credit application information using a first thread. Correspondingly, in S704 above, a second thread is used to determine the risk label corresponding to the mobile terminal based on call transfer status data, wherein the first thread and the second thread are executed asynchronously.

[0110] For example, a credit request can be generated by a mobile terminal based on credit application information filled in by a user on a credit application page of a target application and sent to the server. After receiving the credit request from the mobile terminal, the server can start a first thread to assess the user's credit limit based on the credit application information, and asynchronously start a second thread to determine the risk label corresponding to the mobile terminal based on the mobile terminal's call forwarding status data.

[0111] Understandably, since filling out credit application information is usually a necessary process before users apply for resource transfer, processing credit application information and asynchronously determining the call transfer status data of mobile terminals after entering this necessary process can not only be applied to most target applications that provide resource transfer services, but also ensure the accuracy of risk labels.

[0112] S706 When the mobile terminal enters the resource transfer process, the risk label corresponding to the mobile terminal is returned to the mobile terminal to instruct the mobile terminal to display risk warning information if the risk label indicates that the mobile terminal is at risk of losing contact.

[0113] The risk warning information is used to indicate that the current resource transfer operation carries risks. For example, this risk label is used to display risk warning information on the resource transfer application page. The trigger for entering the resource transfer process is an action entered by the user in the target application.

[0114] Optionally, the server may determine that the mobile terminal has entered the resource transfer process upon receiving a risk query request from the mobile terminal. The risk query request is sent to the server by the mobile terminal when the user performs a triggering operation to enter the resource transfer process within the target application.

[0115] The risk alert method provided by one or more embodiments of this application involves the mobile terminal to which the target application belongs acquiring its own call forwarding status data and reporting it to the server. The server then assigns a corresponding risk label to the mobile terminal based on the call forwarding status data. Furthermore, in response to a user's triggering operation to enter the call forwarding process within the target application, the mobile terminal queries the server for the corresponding risk label to determine if there is a risk of loss of contact. If there is a risk of loss of contact, a risk alert is output to inform the user that the current resource transfer operation is risky. This ensures that the user receives timely and effective risk warnings even when the mobile terminal is in call forwarding mode, allowing them to quickly determine if they have been scammed and mitigate losses. Therefore, the risk alert method provided by the embodiments of this application can effectively alert users to fraud risks, thus improving the fraud risk identification rate.

[0116] based on Figure 1 As illustrated in the application scenario, this application also provides a risk warning method. Please refer to... Figure 8 This is a flowchart illustrating a risk warning method according to an embodiment of this application. The diagram depicts a specific implementation of the interaction between a mobile terminal and a server. Figure 8 As shown, the method may include:

[0117] S802, the mobile terminal obtains its own call transfer status data and reports it to the server.

[0118] The specific implementation of S802 is similar to the specific implementation of call transfer status data in S202. For details, please refer to the detailed description of S202 above, which will not be repeated here.

[0119] Optionally, such as Figure 9As shown, prior to S802 above, the risk warning method provided in this application embodiment may further include: the mobile terminal displaying a login page for logging into the target application through the target application; the mobile terminal responding to the login operation performed by the user on the login page of the target application, displaying authorization prompt information, the authorization prompt information being used to confirm whether the target application is allowed to obtain the device information of the mobile terminal; the mobile terminal determining the target application's permission information for the device information based on the operation performed by the user on the authorization prompt information in the target application. Accordingly, in S802 above, the mobile terminal, based on the permission information and a transfer status query strategy matching the type of the mobile terminal's operating system, obtains its own call transfer status data and reports it to the server.

[0120] Optionally, such as Figure 9 As shown, in S802 above, when the mobile terminal detects that the user has successfully logged into the target application, it obtains its own call transfer status data and reports it to the server.

[0121] Optionally, such as Figure 9 As shown in Figure 802 above, when a user successfully logs into the target application, the mobile terminal displays a credit application page and, in response to the user's credit application information entry operation on the credit application page, obtains its own call forwarding status data and reports it to the server.

[0122] Optionally, such as Figure 9 As shown, the mobile terminal also sends a credit request to the server based on the credit application information filled in by the user on the credit application page. The credit request carries the user's credit application information and is used to request the processing of the user's credit application information.

[0123] S804, the mobile terminal responds to the user's trigger operation in the target application to enter the transfer process and displays the resource transfer application page.

[0124] Optionally, such as Figure 9 As shown, upon receiving a successful authorization response from the server, the mobile terminal can determine whether it has received user input to trigger the transfer process, and then display the resource transfer application page.

[0125] S806, the server determines the risk label corresponding to the mobile terminal based on the call transfer status data reported by the mobile terminal.

[0126] The specific implementation of S806 is similar to that of S704. For details, please refer to the detailed description of S704 above, which will not be repeated here.

[0127] Optionally, such as Figure 9As shown, the server can store the received call transfer status data.

[0128] Optionally, such as Figure 9 As shown, when the server receives a credit request sent by the mobile terminal, it can use a first thread to process the credit request information and a second thread to determine the risk label corresponding to the mobile terminal based on the call forwarding status data of the mobile terminal. The first thread and the second thread are executed asynchronously.

[0129] S808, the mobile terminal queries the server for the risk label corresponding to the mobile terminal.

[0130] The specific implementation of S808 is similar to that of S202. For details, please refer to the detailed explanation of S202 above, which will not be repeated here.

[0131] S810: If the risk label corresponding to the mobile terminal indicates that the mobile terminal is at risk of losing contact, the mobile terminal will display risk warning information on the resource transfer application page.

[0132] The specific implementation of S810 is similar to that of S204. For details, please refer to the detailed explanation of S204 above. It will not be repeated here.

[0133] Optionally, such as Figure 9 As shown, the mobile terminal can display risk warning information in the form of a pop-up window on the resource transfer application page; furthermore, after the above S810, in response to the user's confirmation operation of the risk warning information, the display of the risk warning information is canceled.

[0134] Optionally, such as Figure 9 As shown, if the mobile terminal receives a transfer request operation performed by the user on the resource transfer request page, it sends a resource transfer request to the server based on the transfer request operation, and the server transfers the resources owned by the transferor to the transferee.

[0135] The risk alert method provided by one or more embodiments of this application involves the mobile terminal to which the target application belongs acquiring its own call forwarding status data and reporting it to the server. The server then assigns a corresponding risk label to the mobile terminal based on the call forwarding status data. Furthermore, in response to a user's triggering operation to enter the call forwarding process within the target application, the mobile terminal queries the server for the corresponding risk label to determine if there is a risk of loss of contact. If there is a risk of loss of contact, a risk alert is output to inform the user that the current resource transfer operation is risky. This ensures that the user receives timely and effective risk warnings even when the mobile terminal is in call forwarding mode, allowing them to quickly determine if they have been scammed and mitigate losses. Therefore, the risk alert method provided by the embodiments of this application can effectively alert users to fraud risks, thus improving the fraud risk identification rate.

[0136] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0137] In addition, with the above Figure 2 Corresponding to the risk warning method shown, this application also provides a risk warning device. Please refer to... Figure 10 The diagram below illustrates the structure of a risk warning device 1000 according to an embodiment of this application. The device 1000 can be applied to a mobile terminal and may include:

[0138] The query unit 1010 is used to respond to the trigger operation of the user entering the resource transfer process in the target application, and query the server for the risk label corresponding to the mobile terminal to which the target application belongs. The risk label is used to indicate whether the mobile terminal is at risk of losing contact. The risk label is determined by the server based on the call transfer status reported by the mobile terminal. The call transfer status data is obtained by the mobile terminal based on the mobile terminal's operating system and uploaded to the server after the user authorizes login in the target application.

[0139] The display unit 1020 is used to output risk warning information if the risk label indicates that the mobile terminal is at risk of losing connection. The risk warning information is used to indicate that the current resource transfer operation is at risk.

[0140] Optionally, the risk warning information is displayed on the resource transfer application page, which is displayed in response to the user's triggering operation to enter the resource transfer process in the target application;

[0141] The display unit outputs risk warning information, including: displaying the risk warning information in the form of a pop-up window on the resource transfer application page; after displaying the risk warning information on the resource transfer application page, the method further includes: canceling the display of the risk warning information in response to the user's confirmation operation of the risk warning information.

[0142] Optionally, the mobile terminal obtains call forwarding status data according to system settings, including: obtaining the call forwarding status data of the mobile terminal when it is detected that the user has successfully logged into the target application; and / or, displaying a credit application page when the user has successfully logged into the target application, and obtaining the call forwarding status data of the mobile terminal in response to the user's credit application information filling operation performed on the credit application page.

[0143] Optionally, the display unit is further configured to: display a login page for logging into the target application before the mobile terminal obtains call forwarding status data according to the mobile terminal's operating system; and display authorization prompt information in response to the login operation performed by the user on the login page, wherein the authorization prompt information is used to confirm whether the target application is allowed to obtain the device information of the mobile terminal.

[0144] The mobile terminal obtains call forwarding status data based on its operating system, including: determining the target application's permission information for the device information based on the user's operation on the authorization prompt information; and obtaining the call forwarding status data of the mobile terminal based on the permission information and a forwarding status query strategy that matches the type of the mobile terminal's operating system.

[0145] Optionally, based on the permission information and a call forwarding status query strategy matching the type of the mobile terminal's operating system, the call forwarding status data of the mobile terminal is obtained, including: if the permission information indicates that the target application does not have permission to obtain the device information of the mobile terminal, then the call forwarding status of the mobile terminal is determined to be unknown; if the permission information indicates that the target application has permission to obtain the device information of the mobile terminal, then the call forwarding status data of the mobile terminal is obtained based on a call forwarding status query strategy matching the type of the mobile terminal's operating system.

[0146] Optionally, if the operating system is an Android system, the call transfer status query strategy matching the type of the operating system includes: querying the call transfer status of the mobile terminal through the phone manager and phone status monitoring class of the operating system;

[0147] The call forwarding status query strategy based on matching the operating system type of the mobile terminal to obtain the call forwarding status data of the mobile terminal includes: writing a call status monitoring class object and a target event type representing the call forwarding status of the mobile terminal to the operating system through the call manager; the call status monitoring class object is used by the operating system to call back the call forwarding status data of the mobile terminal and write it into memory when the target event type is detected; calling a thread blocking object to block the target thread and waiting for the operating system to execute the callback operation; the target thread is used to write the call forwarding status data in memory into a preset dataset, which is used to store the call forwarding status data of the mobile terminal; if an end blocking message is received from the operating system or the blocking of the target thread times out, the target thread is used to write the call forwarding status data in memory into the preset dataset.

[0148] Optionally, if the operating system is iOS, the call transfer status query strategy matching the type of the operating system includes obtaining the call transfer status data of the mobile terminal from the status bar of the mobile terminal.

[0149] The call forwarding status query strategy based on matching the type of the mobile terminal's operating system to obtain the call forwarding status data of the mobile terminal includes: obtaining the version number of the operating system; if the version number of the operating system is lower than a preset version number, then obtaining the status bar object of the operating system through the application object corresponding to the target application, wherein the application object refers to the object created by the operating system for the target application after the target application is launched; and obtaining the call forwarding status data of the mobile terminal from the status bar of the mobile terminal through the status bar object.

[0150] Optionally, obtaining the call forwarding status data of the mobile terminal from the status bar of the mobile terminal through the status bar object includes: obtaining the foreground view attribute object of the operating system through the status bar object; obtaining the status bar indicator view object of the operating system through the foreground view attribute object; obtaining the status bar data class object of the operating system through the status bar indicator view object; and determining the call forwarding status of the mobile terminal through the type value of the status bar data class object.

[0151] Optionally, obtaining the call forwarding status data of the mobile terminal based on the call forwarding status query strategy that matches the type of the mobile terminal's operating system includes: if the version number of the operating system is not lower than the preset version number, then obtaining the status bar manager object of the operating system through the application object corresponding to the target application; and obtaining the call forwarding status data of the mobile terminal from the status bar of the mobile terminal through the status bar manager object.

[0152] Optionally, obtaining the call forwarding status data of the mobile terminal from the status bar of the mobile terminal through the status bar manager object includes: obtaining a status bar data class object through the status bar manager object, the status bar data class object being used to obtain data on the status bar of the mobile terminal; obtaining a status bar call data entity class object of the user identification SIM card of the mobile terminal through the status bar data class object; and obtaining the call forwarding status data of the SIM card through the status bar call data entity class object.

[0153] Obviously, the risk warning device provided in this application embodiment can serve as... Figure 2 The entity implementing the risk warning method shown, for example Figure 2 In the risk warning method shown, step S202 can be performed by... Figure 10 The query unit in the risk warning device shown executes the step S204, which can be performed by... Figure 10 The display unit in the risk warning device shown is activated.

[0154] According to another embodiment of this application, Figure 10 The risk warning device shown can be constructed by combining each unit individually or entirely into one or more other units, or one or more of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effect of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the risk warning device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0155] According to another embodiment of this application, a general-purpose computing device, such as a computer, including processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), can run an application capable of performing tasks such as... Figure 2 The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 10 The risk warning device shown herein, and the risk warning method for implementing the embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable storage medium, and transferred via the computer-readable storage medium to an electronic device, such as a terminal, for execution therein.

[0156] In addition, with the above Figure 7 Corresponding to the risk warning method shown, this application also provides a risk warning device. Please refer to... Figure 11 The diagram below illustrates the structure of a risk warning device 1100 according to an embodiment of this application. This device 1100 can be applied to a mobile terminal and may include:

[0157] The receiving unit 1110 is used to receive call forwarding status data reported by the mobile terminal to which the target application belongs, wherein the call forwarding status data is used to indicate whether the mobile terminal to which the target application belongs is in a call forwarding state.

[0158] The determining unit 1120 is used to determine the risk label corresponding to the mobile terminal based on the call transfer status data, wherein the risk label is used to indicate whether the mobile terminal is at risk of losing contact.

[0159] The sending unit 1130 is configured to return the risk label to the mobile terminal when the mobile terminal has a trigger operation to enter the resource transfer process, so as to instruct the mobile terminal to output risk warning information when the risk label indicates that the mobile terminal has a risk of losing connection. The risk warning information is used to indicate that the current resource transfer operation has a risk. The trigger operation is input by the user in the target application.

[0160] Optionally, the receiving unit is further configured to receive a credit granting request sent by the mobile terminal before the determining unit determines the risk label corresponding to the mobile terminal based on the call transfer status data. The credit granting request carries the user's credit granting application information and is used to request the processing of the user's credit granting application information.

[0161] The device further includes: a processing unit for processing the credit application information using a first thread; and a determining unit for determining a risk label corresponding to the mobile terminal based on the call transfer status data, including: determining the risk label corresponding to the mobile terminal using a second thread based on the call transfer status data, wherein the first thread and the second thread are executed asynchronously.

[0162] Obviously, the risk warning device provided in this application embodiment can serve as... Figure 7 The entity implementing the risk warning method shown, for example Figure 7 In the risk warning method shown, step S702 can be performed by... Figure 11 The receiving unit in the risk warning device shown executes step S704, which can be performed by... Figure 11 The determination unit in the risk warning device shown executes step S706, which can be performed by... Figure 11 The sending unit in the risk warning device shown is performing this action.

[0163] According to another embodiment of this application, Figure 11 The risk warning device shown can be constructed by combining each unit individually or entirely into one or more other units, or one or more of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effect of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the risk warning device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0164] According to another embodiment of this application, a general-purpose computing device, such as a computer, including processing elements and storage elements such as CPU, RAM, and ROM, can be used to run an application capable of performing tasks such as... Figure 7 The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 11 The risk warning device shown herein, and the risk warning method for implementing the embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable storage medium, and may be transferred via the computer-readable storage medium to an electronic device such as a server, and run therein.

[0165] Figure 12 This is a schematic diagram of the terminal structure according to an embodiment of this application. Please refer to it. Figure 12At the hardware level, the terminal includes a processor, and optionally also an internal bus, network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the terminal may also include other hardware required for other services.

[0166] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 12 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0167] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0168] The processor reads the corresponding computer program from non-volatile memory into memory and then runs it, forming a risk warning device at the logical level. The processor executes the program stored in memory and specifically performs the following operations: In response to a user's trigger operation in the target application to enter a resource transfer process, it queries the server for a risk tag corresponding to the mobile terminal to which the target application belongs. The risk tag indicates whether the mobile terminal is at risk of losing contact. The risk tag is determined by the server based on call forwarding status data reported by the mobile terminal. This call forwarding status data is obtained by the mobile terminal based on its operating system and uploaded to the server after the user authorizes login in the target application. If the risk tag indicates that the mobile terminal is at risk of losing contact, a risk warning message is output, indicating that the current resource transfer operation is risky.

[0169] The above is as stated in this application. Figure 2The method executed by the risk warning device disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0170] The terminal can also perform Figure 2 The method, and implement the risk warning device in Figure 1 The functions of the embodiment shown in Figure 5 will not be described again in this application.

[0171] Of course, in addition to software implementation, the terminal of this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0172] This application also proposes a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by a portable terminal including multiple applications, enable the portable terminal to perform... Figure 2The method of the illustrated embodiment is specifically used to perform the following operations: In response to a user's triggering operation to enter a resource transfer process in a target application, the server is queried for a risk tag corresponding to the mobile terminal to which the target application belongs. The risk tag is used to indicate whether the mobile terminal is at risk of losing contact. The risk tag is determined by the server based on call forwarding status data reported by the mobile terminal. The call forwarding status data is obtained by the mobile terminal based on its operating system and uploaded to the server after the user authorizes login in the target application. If the risk tag indicates that the mobile terminal is at risk of losing contact, a risk warning message is output. The risk warning message is used to indicate that the current resource transfer operation is at risk.

[0173] Figure 13 This is a schematic diagram of the server structure according to an embodiment of this application. Please refer to it. Figure 13 At the hardware level, the server includes a processor, and optionally an internal bus, network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the server may also include other hardware required for other business operations.

[0174] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 13 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0175] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0176] The processor reads the corresponding computer program from non-volatile memory into memory and then runs it, forming a risk warning device at the logical level. The processor executes the program stored in memory and specifically performs the following operations: receiving call forwarding status data reported by the mobile terminal to which the target application belongs, the call forwarding status data indicating whether the mobile terminal to which the target application belongs is in a call forwarding state; determining a risk tag corresponding to the mobile terminal based on the call forwarding status data, the risk tag indicating whether the mobile terminal is at risk of being out of contact; when the mobile terminal has a trigger operation to enter a resource transfer process, returning the risk tag to the mobile terminal to instruct the mobile terminal that, if the risk tag indicates that the mobile terminal is at risk of being out of contact, output risk warning information, the risk warning information indicating that the current resource transfer operation is risky, the trigger operation being input by the user in the target application.

[0177] The above is as stated in this application. Figure 7 The method executed by the risk warning device disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0178] The server can also execute Figure 7The method, and implement the risk warning device in Figure 7 The functions of the embodiments shown are not described again in this application.

[0179] Of course, in addition to software implementation, the server in this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0180] This application also proposes a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by a portable server comprising multiple applications, enable the portable server to perform... Figure 7 The method of the illustrated embodiment is specifically used to perform the following operations: receiving call forwarding status data reported by the mobile terminal to which the target application belongs, the call forwarding status data indicating whether the mobile terminal to which the target application belongs is in a call forwarding state; determining a risk label corresponding to the mobile terminal based on the call forwarding status data, the risk label indicating whether the mobile terminal is at risk of losing contact; when the mobile terminal has a trigger operation to enter the resource transfer process, returning the risk label to the mobile terminal to instruct the mobile terminal to output risk warning information when the risk label indicates that the mobile terminal is at risk of losing contact, the risk warning information indicating that the current resource transfer operation is at risk, the trigger operation being input by the user in the target application.

[0181] In summary, the above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

[0182] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a computer.

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

[0184] It should also be noted that 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 limitation, 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.

[0185] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

Claims

1. A risk warning method, characterized in that, include: In response to the user's triggering operation of entering the resource transfer process in the target application, the server is queried for the risk tag corresponding to the mobile terminal to which the target application belongs. The risk tag is used to indicate whether the mobile terminal is at risk of losing contact. The risk tag is determined by the server based on the call transfer status data reported by the mobile terminal. The call transfer status data is obtained by the mobile terminal based on the mobile terminal's operating system and uploaded to the server after the user authorizes login in the target application. If the risk label indicates that the mobile terminal is at risk of losing connection, a risk warning message is output. The risk warning message is used to indicate that the current resource transfer operation is at risk.

2. The method according to claim 1, characterized in that, The risk warning information is displayed on the resource transfer application page, which is displayed in response to the user's triggering operation to enter the resource transfer process in the target application; The output risk warning information includes: The risk warning information is displayed as a pop-up window on the resource transfer application page; After outputting the risk warning information, the method further includes: In response to the user's confirmation of the risk warning information, the display of the risk warning information is cancelled.

3. The method according to claim 1, characterized in that, The mobile terminal obtains call forwarding status data according to system settings, including: Upon detecting that a user has successfully logged into the target application, the call forwarding status data of the mobile terminal is obtained; and / or, If the user successfully logs into the target application, a credit application page is displayed, and in response to the user's credit application information entry operation on the credit application page, the call forwarding status data of the mobile terminal is obtained.

4. The method according to claim 1, characterized in that, Before the mobile terminal obtains call forwarding status data according to the mobile terminal's operating system, the method further includes: Display the login page for logging into the target application; In response to the login operation performed by the user on the login page, an authorization prompt message is displayed, which is used to confirm whether the target application is allowed to obtain the device information of the mobile terminal; Based on the user's actions in response to the authorization prompt, the target application's permission information regarding the device information is determined; The mobile terminal obtains call forwarding status data according to its operating system, including: Based on the permission information and a call forwarding status query strategy that matches the type of the mobile terminal's operating system, the call forwarding status data of the mobile terminal is obtained.

5. The method according to claim 4, characterized in that, The method of obtaining call forwarding status data of the mobile terminal based on the permission information and a forwarding status query strategy that matches the type of the mobile terminal's operating system includes: If the permission information indicates that the target application does not have permission to obtain the device information of the mobile terminal, then the call forwarding status of the mobile terminal is determined to be unknown; If the permission information indicates that the target application has permission to obtain the device information of the mobile terminal, then the call forwarding status data of the mobile terminal is obtained based on a call forwarding status query strategy that matches the type of the mobile terminal's operating system.

6. The method according to claim 5, characterized in that, If the operating system is Android, the call transfer status query strategy that matches the type of the operating system includes: querying the call transfer status of the mobile terminal through the phone manager and phone status monitoring class of the operating system; The call forwarding status query strategy based on matching the operating system type of the mobile terminal to obtain the call forwarding status data of the mobile terminal includes: The phone manager writes a phone status listening class object and a target event type representing the call forwarding status of the mobile terminal to the operating system. The phone status listening class object is used by the operating system to call back the call forwarding status data of the mobile terminal and write it into memory when the target event type is detected. The thread blocking object is invoked to block the target thread and wait for the operating system to execute a callback operation. The target thread is used to write the call transfer status data in memory into a preset dataset, which is used to store the call transfer status data of the mobile terminal. If an end-blocking message is received from the operating system or a timeout occurs while blocking the target thread, the target thread is used to write the call transfer status data in memory into the preset dataset.

7. The method according to claim 5, characterized in that, If the operating system is iOS, the call transfer status query strategy that matches the operating system type includes obtaining the call transfer status data of the mobile terminal from the status bar of the mobile terminal. The call forwarding status query strategy based on matching the operating system type of the mobile terminal to obtain the call forwarding status data of the mobile terminal includes: Obtain the version number of the operating system; If the version number of the operating system is lower than the preset version number, the status bar object of the operating system is obtained through the application object corresponding to the target application. The application object refers to the object created by the operating system for the target application after the target application is started. The call forwarding status data of the mobile terminal is obtained from the status bar of the mobile terminal through the status bar object.

8. The method according to claim 7, characterized in that, The call forwarding status data of the mobile terminal is obtained from the status bar of the mobile terminal through the status bar object, including: The operating system's foreground view property object is obtained through the status bar object; The operating system's status bar indicator view object is obtained through the foreground view property object; The status bar data class object of the operating system is obtained through the status bar indicator view object; The call forwarding status of the mobile terminal is determined by the type value of the status bar data class object.

9. The method according to claim 7, characterized in that, The call forwarding status query strategy based on matching the operating system type of the mobile terminal to obtain the call forwarding status data of the mobile terminal includes: If the version number of the operating system is not lower than the preset version number, then the status bar manager object of the operating system is obtained through the application object corresponding to the target application. The call forwarding status data of the mobile terminal is obtained from the status bar of the mobile terminal through the status bar manager object.

10. The method according to claim 9, characterized in that, The step of obtaining the call forwarding status data of the mobile terminal from the status bar of the mobile terminal through the status bar manager object includes: The status bar manager object is used to obtain the status bar data class object, which is used to obtain the data on the status bar of the mobile terminal. The status bar call data entity object of the user identification SIM card of the mobile terminal is obtained through the status bar data object. The call status transfer status data of the SIM card is obtained through the status bar call data entity class object.

11. A risk warning method, characterized in that, Applied to a server, the method includes: Receive call forwarding status data reported by the mobile terminal to which the target application belongs, wherein the call forwarding status data is used to indicate whether the mobile terminal is in a call forwarding state; Based on the call forwarding status data, a risk label corresponding to the mobile terminal is determined. The risk label is used to indicate whether the mobile terminal is at risk of losing contact. When the mobile terminal triggers an operation to enter the resource transfer process, the risk label is returned to the mobile terminal to instruct the mobile terminal to output risk warning information when the risk label indicates that the mobile terminal is at risk of losing connection. The risk warning information is used to indicate that the current resource transfer operation is risky. The triggering operation is entered by the user in the target application.

12. The method according to claim 11, characterized in that, Before determining the risk label corresponding to the mobile terminal based on the call forwarding status data, the method further includes: The system receives a credit granting request sent by the mobile terminal, the credit granting request carrying the user's credit granting application information, and the credit granting request is used to request the processing of the user's credit granting application information; The credit application information is processed using the first thread; The step of determining the risk label corresponding to the mobile terminal based on the call forwarding status data includes: The second thread determines the risk label corresponding to the mobile terminal based on the call transfer status data, wherein the first thread and the second thread are executed asynchronously.

13. A terminal, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 10.

14. A server, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in claim 11 or 12.

15. A computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the terminal performs the method as described in any one of claims 1 to 10; or the server performs the method as described in any one of claims 11 or 12.

Images