Internet of Things-based trusted calling methods, devices and equipment

Abstract

This application provides a trusted calling method, apparatus, and device based on the Internet of Things (IoT). In this method, the IoT trusted calling platform determines the validity of the user's identity in the current call based on a user authentication request received from a terminal. If the user's identity is determined to be valid, a verification result indicating the user's identity is valid is returned to the terminal. Then, based on a real number query request received from an outbound calling platform, the platform retrieves the real number corresponding to the trusted number from the database and sends the real number to the outbound calling platform. By hiding the real number through the trusted number, malicious binding and harassing calls are prevented, user information security is protected, and user experience is improved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) communication technology, and in particular to a trusted calling method, apparatus, and device based on IoT. Background Technology

[0002] IoT SIM cards are dedicated number segments used by telecom operators. They support basic communication services such as SMS, wireless data, and voice through dedicated network elements, and provide intelligent channel services such as communication link management and terminal management. IoT SIM cards are widely used in areas such as connected vehicles, wearable devices, and smart homes. However, with the increasing prevalence of IoT SIM cards, incidents of harassing phone calls and telecom fraud using them have occurred repeatedly.

[0003] In order to reduce the occurrence of the above-mentioned incidents, the Ministry of Industry and Information Technology has carried out real-name registration rectification for IoT cards, adding call numbers through a real-name registration mini-program, and restricting the incoming and outgoing call lists.

[0004] However, the above solution only limits the number of calls and does not completely eliminate malicious binding of family numbers for harassment, thus failing to effectively protect users' information security. Summary of the Invention

[0005] This application provides a trusted calling method, apparatus, and device based on the Internet of Things (IoT) to solve the problem that existing technologies cannot effectively protect user information security during IoT card calls.

[0006] Firstly, this application provides a trusted calling method based on the Internet of Things (IoT), applied to an IoT trusted calling platform, comprising:

[0007] The receiving terminal sends a user authentication request, which is used to request the authentication of the user who initiated the call. The user authentication request includes a user identity identifier, the terminal's device identifier, the terminal's current location information, and a trusted number for the requested call.

[0008] Based on the user authentication request, determine whether the user's identity is valid in this call;

[0009] If the user's identity is determined to be valid, a verification result indicating that the user's identity is valid is returned to the terminal;

[0010] Receive a real number query request sent by an outbound calling platform, wherein the real number query request includes the trusted number;

[0011] Based on the real number query request, the real number corresponding to the trusted number in the database is retrieved;

[0012] The real number is sent to the outbound calling platform.

[0013] In conjunction with the first aspect, in some embodiments, determining whether the user's identity is valid in the current call based on the user authentication request includes:

[0014] Determine whether the current location information of the terminal is consistent with the user's frequently used location information stored in advance;

[0015] If the current location information of the terminal is consistent with the user's frequently used location information, then based on the terminal's device identifier and the pre-stored device identifier, it is determined whether there has been a device replacement.

[0016] If there is no device replacement, then based on the pre-stored binding information of the terminal, determine whether the binding time of the terminal has exceeded the validity period;

[0017] If the binding time of the terminal has not exceeded the validity period, then based on the binding information, it is determined whether the binding time of the trusted number has exceeded the validity period;

[0018] If the binding time of the trusted number has not exceeded the validity period, then the identity of the user in this call is determined to be valid;

[0019] If the current location information of the terminal is inconsistent with the user's frequently used location information, or if there is a device change, or if the binding time of the terminal has expired, or if the binding time of the trusted number has expired, then the user's identity is determined to be invalid in this call.

[0020] In conjunction with the first aspect, in some embodiments, before determining whether the current location information of the terminal is consistent with the pre-stored frequently used location information of the user, the method further includes:

[0021] Get the duration from the last successful authentication of the user to the current time;

[0022] If the duration does not exceed the preset duration, the user's authentication is deemed successful.

[0023] In conjunction with the first aspect, in some embodiments, before the user authentication request sent by the receiving terminal, the method further includes:

[0024] The terminal receives an IoT card call authorization request, which includes IoT card information, user identity information, terminal device identifier, and authorization information.

[0025] Based on the IoT card call authorization request, the IoT card and the user are authorized and verified to confirm whether the IoT card trusted call permission has been enabled for the terminal.

[0026] If it is determined that the terminal has been granted trusted calling permission via the IoT card, a verification result is generated based on the user's identity information and the IoT card information.

[0027] The verification result is sent to the terminal. The verification result includes the user's identity identifier and trusted number on the Internet of Things trusted calling platform. The trusted number includes trusted long numbers and trusted short numbers.

[0028] In conjunction with the first aspect, in some embodiments, the method further includes:

[0029] The terminal receives a contact binding request, which includes the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, the preset contact binding validity period, and the authorization information.

[0030] Based on the real number of the contact to be bound, a verification SMS is sent to the terminal of the contact to be bound. The verification SMS is used to instruct the contact to be bound to verify identity and determine whether binding is allowed.

[0031] The terminal receiving the binding authorization result from the contact to be bound includes whether binding is allowed or not.

[0032] Based on the authorization result, a trusted number corresponding to the contact to be bound is generated, and based on the trusted number, the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, the preset contact binding validity period, and the authorization information, the contact to be bound is bound to the user;

[0033] The trusted number is sent to the terminal.

[0034] In conjunction with the first aspect, in some embodiments, the method further includes: receiving a call request sent by a contact's terminal, the call request including the contact's identity information and a trusted number for the call;

[0035] Based on the call request, query the stored user database to see if the trusted number has an identity identifier on the IoT trusted calling platform and whether the contact is bound to the trusted number;

[0036] If the trusted number has an identity identifier in the IoT trusted calling platform corresponding to the trusted number in the user database and the contact has been bound to the trusted number, then a call message is sent to the terminal corresponding to the trusted number.

[0037] In conjunction with the first aspect, in some embodiments, the method further includes:

[0038] If the user's identity is determined to be invalid, an error message is sent to the terminal, which instructs the terminal to terminate the call with the outbound calling platform.

[0039] In conjunction with the first aspect, in some embodiments, the method further includes:

[0040] If it is determined that the IoT card trusted calling permission should not be granted to the terminal, a binding error message is sent to the terminal, which indicates that the authorization of the terminal has failed.

[0041] Secondly, this application provides a trusted communication device based on the Internet of Things, comprising:

[0042] The first receiving module is used to receive a user authentication request sent by the terminal. The user authentication request is used to request the authentication of the user who initiated the call. The user authentication request includes a user identity identifier, the device identifier of the terminal, the current location information of the terminal, and a trusted number for the requesting call.

[0043] An authentication module is used to determine whether the user's identity is valid in this call based on the user authentication request.

[0044] The result return module is used to return a verification result indicating that the user's identity is valid to the terminal if the user's identity is determined to be valid.

[0045] The second receiving module is used to receive a real number query request sent by the outbound calling platform, wherein the real number query request includes the trusted number;

[0046] The first query module is used to query the database for the real number corresponding to the trusted number based on the real number query request;

[0047] The first sending module is used to send the real number to the outbound calling platform.

[0048] In conjunction with the second aspect, in some embodiments, the authentication module includes:

[0049] A location verification unit is used to determine whether the current location information of the terminal is consistent with the user's frequently used location information stored in advance;

[0050] The device verification unit is used to determine whether there is a device replacement phenomenon based on the device identifier of the terminal and the pre-stored device identifier if the current location information of the terminal is consistent with the user's commonly used location information;

[0051] The time verification unit is used to verify whether the binding time of the terminal has exceeded the validity period if there is no device replacement.

[0052] A number verification unit is used to determine, based on the binding information, whether the binding time of the trusted number has exceeded the validity period if the binding time of the terminal has not exceeded the validity period.

[0053] A valid confirmation unit is used to determine that the user's identity is valid in this call if the binding time of the trusted number has not exceeded the validity period.

[0054] The invalidation confirmation unit is used to determine that the user's identity is invalid in this call if the current location information of the terminal is inconsistent with the user's commonly used location information, or if there is a device change, or if the binding time of the terminal exceeds the validity period, or if the binding time of the trusted number exceeds the validity period.

[0055] In conjunction with the second aspect, in some embodiments, prior to the location verification unit, the device further includes:

[0056] The duration acquisition unit is used to acquire the duration from the last successful authentication of the user to the current time.

[0057] An authentication unit is used to determine that the user's authentication is successful if the duration does not exceed a preset duration.

[0058] In conjunction with the second aspect, in some embodiments, before the first receiving module, the apparatus further includes:

[0059] The third receiving module is used to receive the IoT card call authorization request sent by the terminal. The IoT card call authorization request includes IoT card information, user identity information, terminal device identifier, and authorization information.

[0060] The call authorization module is used to verify the authorization of the IoT card and the user based on the IoT card call authorization request, and to confirm whether the trusted call permission of the IoT card is enabled for the terminal.

[0061] The result generation module is used to generate a verification result based on the user's identity information and the information of the IoT card if it is determined that the IoT card trusted calling permission has been enabled for the terminal.

[0062] The second sending module is used to send a verification result to the terminal. The verification result includes the user's identity identifier and trusted number on the Internet of Things trusted calling platform, wherein the trusted number includes trusted long number and trusted short number.

[0063] In conjunction with the second aspect, in some embodiments, the apparatus further includes:

[0064] The fourth receiving module is used to receive a contact binding request sent by the terminal. The contact binding request includes the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, the preset contact binding validity period, and the authorization information.

[0065] The third sending module is used to send a verification SMS to the terminal of the contact to be bound based on the real number of the contact to be bound. The verification SMS is used to instruct the contact to be bound to verify identity and determine whether binding is allowed.

[0066] The fifth receiving module is used to receive the binding authorization result sent by the terminal of the contact to be bound, wherein the binding authorization result includes allowing binding or disallowing binding;

[0067] The result binding module is used to generate a trusted number corresponding to the contact to be bound based on the authorization result, and bind the contact to be bound to the user based on the trusted number, the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, the preset contact binding validity period, and the authorization information;

[0068] The fourth sending module is used to send the trusted number to the terminal.

[0069] In conjunction with the second aspect, in some embodiments, the apparatus further includes:

[0070] The sixth receiving module is used to receive a call request sent by the contact's terminal, the call request including the contact's identity information and the trusted number to be called;

[0071] The second query module is used to query, based on the call request, whether the trusted number has an identity identifier in the IoT trusted calling platform corresponding to the trusted number and whether the contact is bound to the trusted number in the stored user database;

[0072] The fifth sending module is used to send call information to the terminal corresponding to the trusted number if the identity identifier corresponding to the trusted number exists in the user database on the Internet of Things trusted calling platform and the contact has been bound to the trusted number.

[0073] In conjunction with the second aspect, in some embodiments, the apparatus further includes:

[0074] The sixth sending module is used to send an error message to the terminal if it is determined that the user's identity is invalid. The error message is used to instruct the terminal to terminate the call with the outbound calling platform.

[0075] In conjunction with the second aspect, in some embodiments, the apparatus further includes:

[0076] The seventh sending module is used to send a binding error message to the terminal if it is determined that the IoT card trusted calling permission should not be granted to the terminal. The binding error message is used to indicate that the terminal has failed to authorize.

[0077] Thirdly, this application provides an electronic device, including: a memory, a processor, and a communication interface;

[0078] The memory stores computer-executed instructions;

[0079] The processor executes computer execution instructions stored in the memory to implement the method described in any of the above aspects.

[0080] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the Internet of Things-based trusted calling method described in any of the above aspects.

[0081] The IoT-based trusted calling method, apparatus, and device provided in this application enable trusted calling permissions for the IoT card on the terminal via an IoT card calling authorization request sent by the terminal, and send a verification result containing a trusted number to the terminal. Upon receiving a user authentication request, the method verifies the validity of the user's identity. If the identity is valid, a verification result is sent to the terminal; if the identity is invalid, the method verifies the user's identity and sends a valid verification result to the terminal upon successful verification. Upon receiving a real number query request from an outbound calling platform, the method queries the real number corresponding to the trusted number and sends it to the outbound calling platform to call the contact. By assigning virtual numbers to users and contacts, and verifying users and contacts during the call establishment process, the real number is hidden after successful verification, preventing malicious binding and harassing calls, ensuring user information security, and improving user experience. Attached Figure Description

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

[0083] Figure 1 An application scenario diagram of the trusted calling method based on the Internet of Things provided in the embodiments of this application;

[0084] Figure 2 A flowchart illustrating an embodiment of the trusted calling method based on the Internet of Things provided in this application.

[0085] Figure 3 A flowchart illustrating a second embodiment of the trusted calling method based on the Internet of Things provided in this application.

[0086] Figure 4 A flowchart illustrating a third embodiment of the trusted calling method based on the Internet of Things provided in this application;

[0087] Figure 5 A flowchart illustrating Embodiment 4 of the trusted calling method based on the Internet of Things provided in this application;

[0088] Figure 6 A flowchart illustrating Embodiment 5 of the trusted calling method based on the Internet of Things provided in this application;

[0089] Figure 7 A schematic diagram illustrating the terminal binding change in the IoT-based trusted calling method provided in this application embodiment;

[0090] Figure 8 A schematic diagram of the trusted wake-up process for a trusted call method based on the Internet of Things provided in this application embodiment;

[0091] Figure 9 A schematic diagram of the structure of a trusted communication device based on the Internet of Things provided in this application.

[0092] Figure 10 A schematic diagram of the structure of a second embodiment of the trusted communication device based on the Internet of Things provided in this application;

[0093] Figure 11 A schematic diagram of the structure of a third embodiment of the trusted communication device based on the Internet of Things provided in this application;

[0094] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0095] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0096] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0097] With the continuous advancement of technology, the powerful functions and widespread applications of IoT SIM cards have attracted the attention of many enterprises. IoT SIM cards are gradually becoming a carrier for realizing intelligent hardware devices. However, with the popularization of IoT SIM cards, incidents of phone harassment and telecommunications fraud using them have occurred repeatedly. To prevent the malicious use of IoT SIM card calling functions, the Ministry of Industry and Information Technology (MIIT) has implemented real-name registration for IoT SIM cards and controlled calling functions, restricting incoming and outgoing call whitelists. However, these methods only limit the number of incoming and outgoing calls and do not completely eliminate malicious binding of numbers for harassment. User information security remains ineffective during calls.

[0098] To address the aforementioned issues, this application provides a trusted calling method, apparatus, and device based on the Internet of Things (IoT), which achieves end-to-end trusted authentication for IoT SIM card calls, eliminating malicious binding of phone numbers for harassment and ensuring user information security. Specifically, traditional IoT SIM card communication functions require real-name authentication when binding users and limiting the number of contacts a user can bind. When a user initiates a call, their call permissions are verified before the call is established. However, these methods only limit the number of contacts a user can bind and cannot prevent malicious binding for harassment, nor can they effectively guarantee user information security. Considering these issues, the inventors investigated whether it is possible to perform security verification on users and contacts during the call establishment process using an IoT SIM card, thereby ensuring user information security. Based on this, the technical solution of this application is proposed.

[0099] Figure 1 This diagram illustrates an application scenario of the IoT-based trusted calling method provided in this embodiment. The IoT-based trusted calling method is primarily applied to scenarios where enterprise users make calls using IoT cards. These scenarios typically include at least one user, one contact, a terminal, an IoT trusted calling platform, and an outbound calling platform. The user is a user under a tenant created by the enterprise; the contact is a contact bound to the user; and the terminal can be an electronic device capable of making calls, such as a smartphone, computer, or smart home device. The terminal, the IoT trusted calling platform, and the outbound calling platform can communicate via an application programming interface (API).

[0100] This application does not impose any restrictions on the specific form and type of the physical equipment.

[0101] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0102] Figure 2 The flowchart of Embodiment 1 of the Internet of Things-based trusted calling method provided in this application is as follows: Figure 2 As shown, the IoT-based trusted calling method provided in this application is applied to an IoT trusted calling platform, specifically including:

[0103] S101: Receive user authentication request sent by the terminal.

[0104] In this step, the user's IoT SIM card-bound terminal makes outbound calls through the IoT Trusted Calling Platform. To ensure user information security, user authentication is required when initiating a call. When the user initiates a call on their terminal, the terminal sends a user authentication request to the IoT Trusted Calling Platform.

[0105] Specifically, when a user initiates a call through a terminal, the terminal calls an application programming interface (API) to send a user authentication request to the IoT trusted calling platform. The user authentication request includes the user's identity identifier, the terminal's device identifier, the terminal's current location information, and a trusted number for the requested call. This trusted number is a virtual number.

[0106] S102: Based on the user authentication request, determine whether the user's identity is valid in this call.

[0107] In this step, to prevent malicious binding and harassment calls using IoT cards, after receiving the user authentication request from the terminal, it is necessary to authenticate the user based on the user authentication request to determine whether the user's identity for this call is valid.

[0108] Specifically, based on the user authentication request, the system retrieves the time elapsed since the last successful user authentication to the current duration. If the duration does not exceed the preset time, the user's authentication is considered successful, indicating that the call is normal and can be established. If the duration exceeds the preset time, the user's identity needs to be re-verified based on the user's identity identifier, the terminal's device identifier, the terminal's current location information, and the trusted number requesting the call, thereby determining whether the user's identity is valid for this call.

[0109] S103: If the user's identity is determined to be valid, a verification result indicating that the user's identity is valid is returned to the terminal.

[0110] In this step, if the user's identity is confirmed to be valid based on the user authentication request in the above steps, in order to enable the terminal to establish a normal call with the contact, the IoT trusted calling platform generates a verification result and returns the verification result to the terminal.

[0111] Specifically, the verification result generated by the IoT trusted calling platform is returned to the terminal to indicate that the user's identity is valid, the call has calling permissions, and the terminal can establish a call.

[0112] S104: Receive real number query requests sent by the outbound calling platform.

[0113] In this step, after the IoT Trusted Calling Platform returns the verification result to the terminal, the terminal calls the Application Programming Interface (API) based on the verification result. Through the API, it calls the outbound calling platform. After receiving the call from the terminal, the outbound calling platform needs to obtain the contact's real number in order to make the outbound call. Therefore, the outbound calling platform sends a real number query request to the IoT Trusted Calling Platform based on the trusted number called by the terminal. The IoT Trusted Calling Platform receives the real number query request sent by the outbound calling platform and proceeds to the next step.

[0114] Among them, the real number query request received by the IoT trusted calling platform includes the trusted number called by the terminal.

[0115] S105: Based on the real number query request, retrieve the real number corresponding to the trusted number from the database.

[0116] In this step, in order to establish a call with the contact, the IoT trusted calling platform uses the trusted number in the real number query request sent by the outbound calling platform to query the real number that matches the trusted number of this call in the database of trusted numbers and real numbers.

[0117] S106: Send the real number to the outbound calling platform.

[0118] In this step, in order to make calls to contacts through the outbound calling platform, the IoT trusted calling platform sends the real number corresponding to the trusted number called by the terminal to the outbound calling platform. The outbound calling platform then makes calls to contacts based on the real number corresponding to the trusted number.

[0119] The IoT-based trusted calling method provided in this application determines the validity of the user's identity in the current call based on a user authentication request sent by the receiving terminal. If the user's identity is determined to be valid, a verification result indicating the user's identity is valid is returned to the terminal. Then, based on a real number query request sent by the receiving outbound calling platform, the real number corresponding to the trusted number in the database is retrieved and sent to the outbound calling platform. By using a virtual number during the call and verifying the user's identity to establish the call, malicious binding and harassing calls are prevented, information security control is strengthened and upgraded, and the user experience is improved.

[0120] Figure 3 The flowchart of Embodiment 2 of the Internet of Things-based trusted calling method provided in this application is as follows: Figure 3 As shown, based on the above embodiment, step S102 specifically includes:

[0121] S1021: Get the duration from the last time a user was successfully authenticated to the present.

[0122] In this step, the IoT trusted calling platform verifies the user's identity each time the user initiates a call. To facilitate call establishment, the platform queries the pre-stored historical call records to obtain the time when the user's identity was last verified. Based on the time when the user's identity was last verified, the platform calculates the duration from the time when the user's identity was last verified to the present.

[0123] S1022: If the duration does not exceed the preset duration, the user's authentication is confirmed to be successful.

[0124] In this step, verifying the user's identity every time a call is initiated would waste a lot of time. Therefore, when a user initiates a call, a preset duration is set, which is the time between the successful identity verification and the next call. The user's identity is valid within the preset duration. The duration obtained in the above steps is compared with the preset duration. If the duration does not exceed the preset duration, it means that the user's previous identity verification is still valid, and the user's identity verification is confirmed to be successful.

[0125] In one specific implementation, the preset validity period for user authentication is set to 10 minutes. This means that after completing one authentication, the user can re-establish a call within 10 minutes without further authentication. The above description of the preset duration of 10 minutes is merely an example, and this application does not impose a specific limitation on the preset duration.

[0126] S1023: Determine whether the terminal's current location information is consistent with the user's frequently used location information stored in advance.

[0127] In this step, as described above, if the duration does not exceed the preset time, the user's identity verification is successful. If the duration exceeds the preset time, the user's identity needs to be re-verified. First, location information needs to be verified. The user authentication request sent by the receiving terminal includes the terminal's current location information. When the user authorizes an IoT card call, the user's frequently used location information is pre-stored. To prevent the user's IoT card from being stolen and to prevent harassment of contacts by the thief, the terminal's current location information needs to be compared with the pre-stored frequently used location information to determine if they match.

[0128] Specifically, when a user authorizes a call using an IoT card, the user's frequently used location information can be any range of province, city, district, or region. If the user initiates a call outside the range of the frequently used location, it indicates that the location information is inconsistent. If the user initiates a call within the range of the frequently used location, it indicates that the location information is consistent.

[0129] S1024: If the terminal's current location information is consistent with the user's frequently used location information, then determine whether there has been a device replacement based on the terminal's device identifier and the pre-stored device identifier.

[0130] In this step, after confirming the location information in the above steps, if the terminal's current location information is consistent with the user's commonly used location information, it means that the location information verification is successful. Next, the device information needs to be verified. The device identifier of the terminal in the user authentication request is compared with the pre-stored device identifier to determine whether there is a device replacement phenomenon. If the terminal's device identifier is the same as the pre-stored device identifier, it means that there is no device replacement phenomenon. If the terminal's device identifier is different from the pre-stored device identifier, it means that there is a device replacement phenomenon.

[0131] S1025: If there is no device replacement, determine whether the terminal binding time has exceeded the validity period based on the pre-stored terminal binding information.

[0132] In this step, the terminal's device identifier is compared with the pre-stored device identifier through the above steps. If there is no device replacement, the terminal's binding information is verified. The binding time of the terminal is queried in the pre-stored terminal binding information and compared with the preset validity period to determine whether the terminal's binding time has exceeded the validity period.

[0133] Specifically, taking a preset validity period of 1 year as an example, if the binding time of the terminal exceeds 1 year, it means that the binding time of the terminal has expired; if the binding time of the terminal does not exceed 1 year, it means that the binding time of the terminal is valid.

[0134] Optionally, the IoT trusted communication platform will send a notification message to the terminal 15 days, 7 days, 2 days, and 1 day before the terminal's binding validity period expires. This notification message will prompt the user to rebind the terminal. The IoT trusted communication platform will stop sending notification messages to the terminal once the user has completed the rebinding.

[0135] S1026: If the binding time of the terminal has not exceeded the validity period, then determine whether the binding time of the trusted number has exceeded the validity period based on the binding information.

[0136] In this step, if the binding time of the terminal has not exceeded the validity period as determined by the above steps, the binding information of the trusted number is verified. The binding time of the trusted number in the binding information is compared with the preset validity period to determine whether the binding time of the trusted number has exceeded the validity period.

[0137] The verification method for the binding information of trusted numbers is the same as that for the binding information of the terminals mentioned above, and will not be repeated here.

[0138] S1027: If the binding time of the trusted number has not exceeded the validity period, then the user's identity is confirmed to be valid in this call.

[0139] In this step, by verifying the trusted number binding information as described above, if the trusted number binding time has not exceeded the validity period, it means that the user's trusted number still has call permissions, and thus the user's identity is confirmed to be valid in this call.

[0140] S1028: If the terminal's current location information is inconsistent with the user's frequently used location information, or if there is a device change, or if the terminal's binding time has expired, or if the trusted number's binding time has expired, then the user's identity in this call is determined to be invalid.

[0141] In this step, to ensure user information security and prevent malicious harassment calls, multiple verifications are performed on the user's identity after the user initiates a call. These verifications include location information verification, device information verification, terminal binding information verification, and trusted number binding information verification. If any of these verifications fails, it indicates that the user is abnormal, and the user's identity is deemed invalid for this call, preventing the call from being established normally.

[0142] The IoT-based trusted calling method provided in this application determines the user's identity by obtaining the time elapsed since the last successful user authentication. If the time elapsed is within a preset duration, the user's authentication is considered successful. If the time elapsed is beyond the preset duration, the method checks if the terminal's current location information matches the user's pre-stored frequently used location information. If they match, the method uses the terminal's device identifier and pre-stored device identifier to determine if a device change has occurred. If no device change has occurred, the method uses pre-stored terminal binding information to determine if the terminal's binding time has expired. If the binding time has not expired, the method uses the binding information to determine if the trusted number's binding time has expired. If the trusted number's binding time has not expired, the user's identity is considered valid in the current call. This multi-factor authentication of the user's identity prevents malicious binding and malicious phone harassment, thus ensuring user information security.

[0143] Figure 4 A flowchart illustrating Embodiment 3 of the trusted calling method based on the Internet of Things provided in this application is shown below. Figure 4 As shown, based on Embodiment 1, before receiving the user authentication request sent by the terminal in step S101, it is necessary to enable the user's terminal with IoT card trusted calling permission, specifically including:

[0144] S107: Receive the IoT card call authorization request sent by the terminal.

[0145] In this step, to enable the IoT SIM card's calling function, the user's terminal needs to be bound to the IoT SIM card, and the terminal needs to be authorized to make calls. The user initiates an IoT SIM card call authorization request through the terminal's business system, and the trusted IoT calling platform receives the IoT SIM card call authorization request sent by the terminal. The terminal's business system can be a terminal application or a web application; this solution does not specifically limit this. The IoT SIM card call authorization request includes the IoT SIM card information, the user's identity information, the terminal's device identifier, and authorization information.

[0146] In one specific implementation, the IoT SIM card is applicable to enterprises. Users applying for IoT SIM card trusted calling authorization all belong to the enterprise. The IoT trusted calling platform needs to create a tenant account for the enterprise before it can enable IoT SIM card trusted calling permissions for the terminals of the corresponding users under the tenant. When the IoT trusted calling platform creates a tenant account for the enterprise, it will assign authorization information to the enterprise. The authorization information includes the enterprise's identifier and key. The authorization information is mainly used by the user to verify the user's identity.

[0147] S108: Based on the IoT card call authorization request, verify the authorization of the IoT card and the user to confirm whether the trusted call permission of the IoT card has been enabled for the terminal.

[0148] In this step, after receiving the IoT card call authorization request, in order to prevent malicious binding from harming user information security, the IoT trusted calling platform performs authorization verification on the IoT card and the user according to the IoT card call authorization request to confirm whether the IoT card trusted calling permission is enabled for the terminal.

[0149] Specifically, the information of the IoT card and the authorization information in the received IoT card call authorization request are compared with the information of the IoT card and the authorization information contained in the tenant information created for the enterprise. If the information of the IoT card and the authorization information are consistent with the information of the IoT card and the authorization information contained in the tenant information, the user authorization verification is confirmed to be successful and the trusted calling permission of the IoT card can be opened for the terminal. If any of the information of the IoT card and the authorization information are inconsistent with the tenant information, the user authorization verification is confirmed to be unsuccessful and the trusted calling permission of the IoT card cannot be opened for the terminal.

[0150] S109: If it is determined that the terminal has been granted trusted calling permission for the IoT card, then a verification result is generated based on the user's identity information and the IoT card information.

[0151] In this step, the user authorization is verified through the above steps to confirm that the terminal has been granted trusted calling permissions for the IoT card. The IoT trusted calling platform generates a verification result for the user based on the user's identity information and IoT card information. The verification result includes the user's identity identifier and trusted number on the IoT trusted calling platform.

[0152] In one specific implementation, to ensure user information security, after confirming that the IoT card's trusted calling permission is enabled for the terminal, a corresponding trusted number is generated for the user for calls. The trusted number includes a trusted long number and a trusted short number, which are virtual numbers. The trusted long number represents the user's tenant; each tenant corresponds to one trusted long number, and the same trusted long number cannot be assigned to different tenants. Different users under a tenant are assigned short numbers, separated by commas. For example, in 02022953126, 001 is a trusted number, 02022953126 is the trusted long number, and 001 is the trusted short number. The number of digits and the specific number of the trusted number can be automatically generated by the system; this solution does not impose specific limitations.

[0153] S110: Send the verification result to the terminal.

[0154] In this step, in order to successfully enable trusted calling permissions for the IoT SIM card on the terminal, the IoT trusted calling platform sends the generated verification result to the terminal. The terminal receives the verification result and successfully enables trusted calling permissions for the IoT SIM card.

[0155] S111: If it is determined that the IoT card trusted calling permission should not be granted to the terminal, a binding error message is sent to the terminal.

[0156] In this step, after verifying the user's authorization in the previous steps, if the IoT card information or authorization information is inconsistent with the tenant information, it indicates that the user is abnormal, and it is determined that the IoT card's trusted calling permission will not be granted to the terminal. At this time, the IoT trusted calling platform generates a binding error message and sends it to the terminal. The binding error message indicates that the user's identity information sent by the terminal is abnormal, and the IoT card's trusted calling permission cannot be granted.

[0157] The IoT-based trusted calling method provided in this application verifies the authorization of the IoT card and the user based on the IoT card call authorization request sent by the terminal. It confirms whether trusted calling permissions have been granted to the terminal. If authorized, a verification result is generated and sent to the terminal based on the user's identity information and the IoT card information. If not authorized, a binding error message is sent to the terminal. By authorizing and verifying the user and assigning a trusted number for calls after successful verification, user information security is ensured, and nuisance calls are avoided.

[0158] Figure 5 The flowchart of Embodiment 4 of the Internet of Things-based trusted calling method provided in this application is as follows: Figure 5 As shown, before establishing a call via an IoT SIM card, it is necessary to bind the call contact to the user, specifically including:

[0159] S112: Receive a contact binding request sent by the terminal.

[0160] In this step, to make calls using the IoT SIM card, the contact to be connected to the user's terminal needs to be bound. The user initiates a contact binding request through the terminal, and the IoT Trusted Calling Platform receives the contact binding request sent by the terminal. The contact binding request includes the user's identity information, the user's identity identifier on the IoT Trusted Calling Platform, the real phone number of the contact to be bound, the preset contact binding validity period, and authorization information.

[0161] S113: Send a verification SMS to the terminal of the contact to be bound, based on the real number of the contact to be bound.

[0162] In this step, to prevent malicious binding and damage to user information security, after the user sends a contact binding request to the IoT Trusted Calling Platform, the IoT Trusted Calling Platform verifies the user's identity based on the user's identity information in the contact binding request, the user's identity identifier on the IoT Trusted Calling Platform, and the authorization information. Once the user's identity verification is successful, a verification SMS is sent to the terminal of the contact to be bound based on the real number of the contact to be bound. The verification SMS is used to instruct the contact to be bound to verify identity.

[0163] Specifically, the verification SMS includes the user's identity information. The contact to be bound can determine whether the user is the person they want to bind based on the user's identity information in the SMS. If so, binding is allowed; otherwise, binding is not allowed.

[0164] S114: Receive the binding authorization result sent by the terminal of the contact to be bound.

[0165] In this step, the contact to be bound generates an authorization result based on the verification SMS in the above steps and sends the authorization result to the IoT Trusted Calling Platform. The IoT Trusted Calling Platform then sends the authorization result to the terminal. The authorization result includes whether binding is allowed or not.

[0166] S115: Based on the authorization result, generate a trusted number corresponding to the contact to be bound, and bind the contact to be bound to the user based on the trusted number, the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, the preset contact binding validity period, and the authorization information.

[0167] In this step, based on the authorization results received in the previous steps, a corresponding trusted number is generated for the contact to be bound, and the contact to be bound and the user are bound together.

[0168] Specifically, if the authorization result is "binding allowed," a correct trusted number corresponding to the contact to be bound is generated. This number can be appended to the trusted short number of the user's trusted number. If the authorization result is "binding not allowed," an error message is generated, which is "00" appended to the trusted short number of the user's trusted number. In the case of "binding allowed," generating a trusted number for the contact to be bound can involve appending 2 or 3 digits to the trusted short number of the user's trusted number, depending on actual needs.

[0169] S116: Send the trusted number to the terminal.

[0170] In this step, in order for the user to successfully establish a call with the bound contact through the terminal, the trusted number generated for the bound contact in the previous steps is sent to the terminal.

[0171] The IoT-based trusted calling method provided in this application sends a verification SMS to the terminal of the contact to be bound upon receiving a contact binding request from the receiving terminal. Then, based on the binding authorization result received from the terminal of the contact to be bound, a trusted number corresponding to the contact to be bound is generated. Finally, based on the trusted number, the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, the preset contact binding validity period, and authorization information, the contact to be bound is bound to the user, and the trusted number is sent to the terminal. By sending a verification SMS to the contact to be bound, malicious binding is avoided, thus ensuring user information security.

[0172] Figure 6 The flowchart of Embodiment 5 of the Internet of Things-based trusted calling method provided in this application is as follows: Figure 6 As shown, the trusted calling method based on the Internet of Things provided in this application can also realize trusted incoming calls, specifically including:

[0173] S117: Receive call requests sent by the contact's terminal.

[0174] In this step, the contact can initiate a call to the user through the terminal. The contact initiates a call request through the contact's terminal, and the IoT trusted calling platform receives the call request sent by the contact's terminal. The call request includes the contact's identity information and the trusted number to be called.

[0175] S118: Based on the call request, query the stored user database to see if there is an identity identifier for the trusted number on the IoT trusted calling platform and whether the contact is bound to the trusted number.

[0176] In this step, to avoid harassing calls, the IoT Trusted Calling Platform, based on the call request received in the above steps, queries the stored user database to see if there is an identity identifier on the IoT Trusted Calling Platform corresponding to the trusted number, and whether the contact person is bound to the trusted number, thereby determining whether a call can be established.

[0177] Specifically, if the user database contains an identity identifier for a trusted number on the IoT trusted calling platform and the contact person is bound to the trusted number, then a call can be established. If the user database does not contain an identity identifier for a trusted number on the IoT trusted calling platform or the contact person is not bound to the trusted number, then a call cannot be established.

[0178] S119: If the user database contains an identity identifier for a trusted number on the IoT trusted calling platform and the contact person is already bound to the trusted number, then send a call message to the terminal corresponding to the trusted number.

[0179] In this step, if the user database contains the identity identifier of the trusted number on the IoT trusted calling platform and the contact person is bound to the trusted number, it means that the call is normal and can be established.

[0180] The IoT-based trusted calling method provided in this application, upon receiving a call request from a contact's terminal, queries a stored user database to determine if a trusted number corresponds to an identity identifier on the IoT trusted calling platform and whether the contact is bound to the trusted number. If the user database contains the corresponding identity identifier and the contact is bound to the trusted number, then call information is sent to the terminal corresponding to the trusted number. By verifying the identity of both the user and the contact during the call initiation process, user information security is ensured, and nuisance calls are prevented.

[0181] The trusted calling method based on the Internet of Things provided in this application can, when the user's bound terminal changes, such as Figure 7 As shown, when a user changes their terminal, a change notification is pushed to the central control platform. The central control platform then sends the change information to the IoT Trusted Communication Platform, which archives the change information.

[0182] The trusted calling method based on the Internet of Things provided in this application can also achieve trusted wake-up, such as... Figure 8 As shown, the specific process includes:

[0183] a) The user initiates a wake-up request for the IoT-bound terminal in the tenant application system. This wake-up request includes the user's identity identifier and authorization information on the IoT trusted communication platform.

[0184] b. The tenant system backend sends a wake-up request to the IoT Trusted Calling Platform, which then verifies the identity of the tenant and the user terminal based on the wake-up request.

[0185] c. The IoT Trusted Calling Platform calls the trusted number corresponding to the IoT card and sends a wake-up result to the IoT Trusted Calling Platform. The wake-up result includes either a wake-up failure or a wake-up success. When the wake-up result is a failure, it includes the user's identity identifier on the IoT Trusted Calling Platform and the reason for the failure. When the wake-up result is a success, it includes the user's identity identifier on the IoT Trusted Calling Platform and a timestamp.

[0186] Figure 9 This is a schematic diagram of the structure of a trusted communication device based on the Internet of Things provided in this application, as shown in the following example. Figure 9 As shown, the IoT-based trusted calling device 200 includes:

[0187] The first receiving module 201 is used to receive a user authentication request sent by the terminal. The user authentication request is used to request the authentication of the user who initiated the call. The user authentication request includes the user's identity identifier, the terminal's device identifier, the terminal's current location information, and the trusted number for the request call.

[0188] The authentication module 202 is used to determine whether the user's identity is valid in this call based on the user's authentication request.

[0189] The result return module 203 is used to return a verification result indicating that the user's identity is valid to the terminal if the user's identity is determined to be valid.

[0190] The second receiving module 204 is used to receive a real number query request sent by the outbound calling platform, which includes a trusted number.

[0191] The first query module 205 is used to retrieve the real number corresponding to the trusted number in the database based on the real number query request.

[0192] The first sending module 206 is used to send the real number to the outbound calling platform.

[0193] Figure 10 This is a schematic diagram of the structure of a second embodiment of the trusted communication device based on the Internet of Things provided in this application, as shown below. Figure 10 As shown, the authentication module 202 includes:

[0194] The duration acquisition unit 2021 is used to obtain the duration from the time of the last successful user authentication to the current time.

[0195] The authentication unit 2022 is used to determine that the user's authentication is successful if the duration does not exceed a preset duration.

[0196] The location verification unit 2023 is used to determine whether the terminal's current location information is consistent with the user's frequently used location information that has been stored in advance.

[0197] The device verification unit 2024 is used to determine whether there is a device replacement phenomenon based on the device identifier of the terminal and the pre-stored device identifier if the current location information of the terminal is consistent with the user's commonly used location information.

[0198] The time verification unit 2025 is used to verify whether the terminal's binding time has exceeded the validity period based on the pre-stored terminal binding information if there is no device replacement.

[0199] The number verification unit 2026 is used to determine whether the binding time of a trusted number has exceeded the validity period based on the binding information if the binding time of the terminal has not exceeded the validity period.

[0200] The valid confirmation unit 2027 is used to confirm the user's identity in this call if the binding time of the trusted number has not exceeded the validity period.

[0201] The invalidation confirmation unit 2028 is used to determine that the user's identity is invalid in this call if the terminal's current location information is inconsistent with the user's commonly used location information, or if there is a device change, or if the terminal's binding time has exceeded the validity period, or if the binding time of the trusted number has exceeded the validity period.

[0202] Figure 11 A schematic diagram of the structure of the IoT-based trusted calling device embodiment three provided in this application is shown below. Figure 11 As shown, the IoT-based trusted calling device 200 also includes:

[0203] The third receiving module 207 is used to receive the IoT card call authorization request sent by the terminal. The IoT card call authorization request includes IoT card information, user identity information, terminal device identifier, and authorization information.

[0204] The call authorization module 208 is used to verify the authorization of the IoT card and the user based on the IoT card call authorization request, and to confirm whether the trusted call permission of the IoT card is enabled for the terminal.

[0205] The result generation module 209 is used to generate a verification result based on the user's identity information and the IoT card information if it is determined that the terminal has been granted trusted calling permission for the IoT card.

[0206] The second sending module 210 is used to send the verification result to the terminal. The verification result includes the user's identity identifier and trusted number on the Internet of Things trusted calling platform. The trusted number includes trusted long number and trusted short number.

[0207] Optionally, the IoT-based trusted calling device 200 also includes:

[0208] The fourth receiving module 211 is used to receive a contact binding request sent by the terminal. The contact binding request includes the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, the preset contact binding validity period, and authorization information.

[0209] The third sending module 212 is used to send a verification SMS to the terminal of the contact to be bound based on the real number of the contact to be bound. The verification SMS is used to instruct the contact to be bound to verify identity and determine whether binding is allowed.

[0210] The fifth receiving module 213 is used to receive the binding authorization result sent by the terminal of the contact to be bound, the binding authorization result including whether binding is allowed or not.

[0211] The result binding module 214 is used to generate a trusted number corresponding to the contact to be bound based on the authorization result, and bind the contact to be bound to the user based on the trusted number, the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, the preset contact binding validity period, and the authorization information.

[0212] The fourth sending module 215 is used to send a trusted number to the terminal.

[0213] Optionally, the IoT-based trusted calling device 200 also includes:

[0214] The sixth receiving module 216 is used to receive a call request sent by the contact's terminal. The call request includes the contact's identity information and the trusted number to be called.

[0215] The second query module 217 is used to query, based on the call request, whether there is an identity identifier in the stored user database corresponding to the trusted number on the Internet of Things trusted calling platform, and whether the contact is bound to the trusted number.

[0216] The fifth sending module 218 is used to send call information to the terminal corresponding to the trusted number if there is an identity contact in the trusted IoT call platform that is bound to the trusted number in the user database.

[0217] Optionally, the IoT-based trusted calling device 200 also includes:

[0218] The sixth sending module 219 is used to send an error message to the terminal if the user's identity is determined to be invalid. The error message is used to instruct the terminal to terminate the call with the outbound calling platform.

[0219] The seventh sending module 220 is used to send a binding error message to the terminal if it is determined that the IoT card trusted calling permission will not be granted to the terminal. The binding error message is used to indicate that the terminal authorization has failed.

[0220] The IoT-based trusted calling device provided in this embodiment is used to execute the IoT-based trusted calling method in any of the aforementioned method embodiments. Its implementation principle and technical effect are similar, and will not be repeated here.

[0221] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 12 As shown, the electronic device 300 includes: a memory 301, a processor 302, and a communication interface 303;

[0222] Memory 301 stores computer-executed instructions.

[0223] The processor 302 executes computer execution instructions stored in the memory 301 to implement the technical solutions in any of the above embodiments.

[0224] Communication interface 303 is used to enable communication between the IoT trusted calling platform and user terminals as well as the outbound calling platform.

[0225] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method in any of the embodiments.

[0226] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solutions provided in any of the above method embodiments.

[0227] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0228] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A trusted communication method based on the Internet of Things, characterized in that, Applications in IoT trusted communication platforms include: The receiving terminal sends a user authentication request, which is used to request the authentication of the user who initiated the call. The user authentication request includes a user identity identifier, the terminal's device identifier, the terminal's current location information, and a trusted number for the request call. The trusted number is a virtual number. Based on the user authentication request, determine whether the user's identity is valid in this call; If the user's identity is determined to be valid, a verification result indicating that the user's identity is valid is returned to the terminal; Receive a real number query request sent by an outbound calling platform, wherein the real number query request includes the trusted number; Based on the real number query request, the real number corresponding to the trusted number in the database is retrieved; Send the real number to the outbound calling platform; The step of determining whether the user's identity is valid in this call based on the user authentication request includes: Determine whether the current location information of the terminal is consistent with the user's frequently used location information stored in advance; If the current location information of the terminal is consistent with the user's frequently used location information, then based on the terminal's device identifier and the pre-stored device identifier, it is determined whether there has been a device replacement. If there is no device replacement, then based on the pre-stored binding information of the terminal, determine whether the binding time of the terminal has exceeded the validity period; If the binding time of the terminal has not exceeded the validity period, then based on the binding information, it is determined whether the binding time of the trusted number has exceeded the validity period; If the binding time of the trusted number has not exceeded the validity period, then the identity of the user in this call is determined to be valid; If the current location information of the terminal is inconsistent with the user's frequently used location information, or if there is a device change, or if the binding time of the terminal has expired, or if the binding time of the trusted number has expired, then the user's identity is determined to be invalid in this call.

2. The method according to claim 1, characterized in that, Before determining whether the current location information of the terminal is consistent with the pre-stored frequently used location information of the user, the method further includes: Get the duration from the last successful authentication of the user to the current time; If the duration does not exceed the preset duration, the user's authentication is deemed successful.

3. The method according to claim 1 or 2, characterized in that, Before the user authentication request sent by the receiving terminal, the method further includes: The terminal receives an IoT card call authorization request, which includes IoT card information, user identity information, terminal device identifier, and authorization information. Based on the IoT card call authorization request, the IoT card and the user are authorized and verified to determine whether to enable trusted call permissions for the IoT card for the terminal. If it is determined that the terminal has been granted trusted calling permission via the IoT card, a verification result is generated based on the user's identity information and the IoT card information. The verification result is sent to the terminal. The verification result includes the user's identity identifier and trusted number on the Internet of Things trusted calling platform. The trusted number includes trusted long numbers and trusted short numbers.

4. The method according to claim 3, characterized in that, The method further includes: The terminal receives a contact binding request, which includes the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, a preset contact binding validity period, and the authorization information. Based on the real number of the contact to be bound, a verification SMS is sent to the terminal of the contact to be bound. The verification SMS is used to instruct the contact to be bound to verify identity and determine whether binding is allowed. The terminal receiving the binding authorization result from the contact to be bound includes whether binding is allowed or not. Based on the authorization result, a trusted number corresponding to the contact to be bound is generated, and based on the trusted number, the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, the preset contact binding validity period, and the authorization information, the contact to be bound is bound to the user; The trusted number is sent to the terminal.

5. The method according to claim 4, characterized in that, The method further includes: The terminal receiving the contact sends a call request, the call request including the contact's identity information and a trusted number for the call; Based on the call request, query the stored user database to see if the trusted number has an identity identifier on the IoT trusted calling platform and whether the contact is bound to the trusted number; If the trusted number has an identity identifier in the IoT trusted calling platform corresponding to the trusted number in the user database and the contact has been bound to the trusted number, then a call message is sent to the terminal corresponding to the trusted number.

6. The method according to claim 1, characterized in that, The method further includes: If the user's identity is determined to be invalid, an error message is sent to the terminal, which instructs the terminal to terminate the call with the outbound calling platform.

7. The method according to claim 3, characterized in that, The method further includes: If it is determined that the IoT card trusted calling permission should not be granted to the terminal, a binding error message is sent to the terminal, which indicates that the authorization of the terminal has failed.

8. A trusted communication device based on the Internet of Things, characterized in that, include: The first receiving module is used to receive a user authentication request sent by the terminal. The user authentication request is used to request the authentication of the user who initiated the call. The user authentication request includes a user identity identifier, the device identifier of the terminal, the current location information of the terminal, and a trusted number for the requesting call. An authentication module is used to determine whether the user's identity is valid in this call based on the user authentication request. The result return module is used to return a verification result indicating that the user's identity is valid to the terminal if the user's identity is determined to be valid. The second receiving module is used to receive a real number query request sent by the outbound calling platform, wherein the real number query request includes the trusted number; The first query module is used to query the database for the real number corresponding to the trusted number based on the real number query request; The first sending module is used to send the real number to the outbound calling platform; The authentication module includes: A location verification unit is used to determine whether the current location information of the terminal is consistent with the user's frequently used location information stored in advance; The device verification unit is used to determine whether there is a device replacement phenomenon based on the device identifier of the terminal and the pre-stored device identifier if the current location information of the terminal is consistent with the user's commonly used location information; The time verification unit is used to verify whether the binding time of the terminal has exceeded the validity period if there is no device replacement. A number verification unit is used to determine, based on the binding information, whether the binding time of the trusted number has exceeded the validity period if the binding time of the terminal has not exceeded the validity period. A valid confirmation unit is used to determine that the user's identity is valid in this call if the binding time of the trusted number has not exceeded the validity period. The invalidation confirmation unit is used to determine that the user's identity is invalid in this call if the current location information of the terminal is inconsistent with the user's commonly used location information, or if there is a device change, or if the binding time of the terminal exceeds the validity period, or if the binding time of the trusted number exceeds the validity period.

9. The apparatus according to claim 8, characterized in that, Prior to the location verification unit, the device further includes: The duration acquisition unit is used to acquire the duration from the last successful authentication of the user to the current time. An authentication unit is used to determine that the user's authentication is successful if the duration does not exceed a preset duration.

10. The apparatus according to claim 8 or 9, characterized in that, Prior to the first receiving module, the device further includes: The third receiving module is used to receive the IoT card call authorization request sent by the terminal. The IoT card call authorization request includes IoT card information, user identity information, terminal device identifier, and authorization information. The call authorization module is used to perform authorization verification on the IoT card and the user according to the IoT card call authorization request, and determine whether to enable trusted call permission for the IoT card for the terminal. The result generation module is used to generate a verification result based on the user's identity information and the information of the IoT card if it is determined that the IoT card trusted calling permission has been enabled for the terminal. The second sending module is used to send a verification result to the terminal. The verification result includes the user's identity identifier and trusted number on the Internet of Things trusted calling platform, wherein the trusted number includes trusted long number and trusted short number.

11. The apparatus according to claim 10, characterized in that, The device further includes: The fourth receiving module is used to receive a contact binding request sent by the terminal. The contact binding request includes the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, the preset contact binding validity period, and the authorization information. The third sending module is used to send a verification SMS to the terminal of the contact to be bound based on the real number of the contact to be bound. The verification SMS is used to instruct the contact to be bound to verify identity and determine whether binding is allowed. The fifth receiving module is used to receive the binding authorization result sent by the terminal of the contact to be bound, wherein the binding authorization result includes allowing binding or disallowing binding; The result binding module is used to generate a trusted number corresponding to the contact to be bound based on the authorization result, and bind the contact to be bound to the user based on the trusted number, the user's identity information, the user's identity identifier on the IoT trusted calling platform, the real number of the contact to be bound, the preset contact binding validity period, and the authorization information; The fourth sending module is used to send the trusted number to the terminal.

12. The apparatus according to claim 11, characterized in that, The device further includes: The sixth receiving module is used to receive a call request sent by the contact's terminal, the call request including the contact's identity information and the trusted number to be called; The second query module is used to query, based on the call request, whether the trusted number has an identity identifier in the IoT trusted calling platform corresponding to the trusted number and whether the contact is bound to the trusted number in the stored user database; The fifth sending module is used to send call information to the terminal corresponding to the trusted number if the identity identifier corresponding to the trusted number exists in the user database on the Internet of Things trusted calling platform and the contact has been bound to the trusted number.

13. An electronic device, characterized in that, include: Memory, processor, communication interface; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the Internet of Things-based trusted calling method as described in any one of claims 1 to 7.

Images