Communication method, device and system and computer readable storage medium

By verifying the binding relationship between cloud mobile phone users and instances on the cloud server and using random value verification, the problem of theft and theft of cloud mobile phone soft SIM cards is solved, and the security protection of soft SIM cards is achieved.

CN120568321APending Publication Date: 2025-08-29HUAWEI TECH CO LTD
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
CN202410231609.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-02-29
Publication Date
2025-08-29

AI Technical Summary

Technical Problem

In the prior art, the soft SIM cards of cloud mobile phones are at risk of being stolen and stolen, and cannot effectively protect their integrity and confidentiality.

Method used

By verifying the binding relationship between cloud mobile phone users and instances in the cloud server, obtaining and using soft SIM card information only when there is a binding relationship, combining random value verification to prevent information leakage and replay attacks, the authentication of soft SIM card is achieved.

Benefits of technology

It effectively prevents theft and misappropriation of soft SIM cards, improves the security of the communication process, and protects the integrity and confidentiality of soft SIM cards.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120568321A_ABST
    Figure CN120568321A_ABST
Patent Text Reader

Abstract

The invention discloses a communication method, which is applied to a cloud server (or a partner cloud server), and comprises the following steps: after a cloud mobile phone application successfully logs in, the cloud server receives a cloud mobile phone instance starting request initiated by terminal equipment; the starting request carries identity information of a cloud mobile phone user; after determining that the cloud mobile phone user and the cloud mobile phone instance have a binding relationship based on the identity information, the cloud server obtains soft SIM card information corresponding to the cloud mobile phone instance; and the cloud server sends the soft SIM card information to an authentication server of an operator. The identity verification of the soft SIM card is realized, the soft SIM card information corresponding to the cloud mobile phone instance can be obtained only after the cloud mobile phone user and the cloud mobile phone instance have the binding relationship, and the technical problem that the soft SIM card is stolen and used while the integrity and confidentiality of the soft SIM card of the cloud mobile phone are protected is solved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a communication method, communication equipment, communication system, and computer-readable storage medium. Background Art

[0002] The Subscriber Identification Module (SIM) card, also known as a customer identification module card, user identification card, or smart card, is a common identifier for mobile operators. Currently, most mobile operators use SIM cards as identification cards for accessing their cellular networks. Before using a mobile device to access an operator's cellular network, users must first purchase a SIM card. This card authenticates the mobile device's access to the network.

[0003] A cloud phone is a mobile phone that leverages cloud computing technology for network terminal services, accessing cloud services through cloud servers. Currently, cloud phones can be configured with a soft SIM card (also known as a virtual SIM card), which allows them to make and receive calls. While protecting the integrity and confidentiality of a cloud phone's soft SIM card, preventing it from being stolen or misused remains a major concern. Summary of the Invention

[0004] The present application provides a communication method, communication equipment, communication system and computer-readable storage medium, which authenticate the soft SIM card of a cloud phone through the binding relationship between the user and the cloud phone instance, thereby solving the technical problem of how to prevent the soft SIM card from being stolen or misused while protecting the integrity and confidentiality of the cloud phone soft SIM card.

[0005] In a first aspect, the present application provides a communication method, applied to a cloud server (or a joint cloud server), the method comprising:

[0006] After the cloud phone application is successfully logged in, the cloud server receives a cloud phone instance startup request initiated by the terminal device; the startup request carries the identity information of the cloud phone user;

[0007] After confirming that the cloud phone user has a binding relationship with the cloud phone instance based on the identity information, the cloud server obtains the soft SIM card information corresponding to the cloud phone instance;

[0008] The cloud server sends the virtual SIM card information to the operator's authentication server.

[0009] The above embodiment verifies whether the cloud phone user who initiated the cloud phone instance startup request has a binding relationship with the cloud phone instance to be launched when the cloud phone application successfully logs in and the cloud phone instance is about to be launched, thereby achieving identity verification of the soft SIM card. Only after the cloud phone user and the cloud phone instance have a binding relationship can the soft SIM card information corresponding to the cloud phone instance be obtained, thereby performing the subsequent soft SIM card network access authentication process. If the cloud phone user and the cloud phone instance do not have a binding relationship, the soft SIM card may be misused. This solves the technical problem of protecting the integrity and confidentiality of the cloud phone soft SIM card while preventing the soft SIM card from being stolen or misused.

[0010] In a possible implementation, the sending the virtual SIM card information to the authentication server of the operator includes:

[0011] The cloud server initiates a network access request to the operator's authentication server; the network access request carries the soft SIM card information.

[0012] Through the above embodiment, after the cloud phone instance in the cloud server is started, it can carry the virtual SIM card information when initiating a network access request to the operator's authentication server to perform a subsequent virtual SIM card network access authentication process.

[0013] In a possible implementation, the network access request further carries a first random value; and after initiating the network access request to the operator's authentication server, the method further includes:

[0014] The cloud server receives the target random number and the first random result returned by the operator's authentication server; the first random result is the result information after the operator's authentication server processes the first random value, which is used to verify whether the returned target random number is valid.

[0015] Through the above embodiment, the first random value is carried in the network access request, which can prevent information from being leaked or tampered with by intentional attacks, prevent replay attacks on soft SIM identity authentication, and further improve the security of the communication process.

[0016] In a possible implementation, the method further includes:

[0017] After receiving the cloud phone instance startup request, the cloud server sends a network access authentication request to the operator's authentication server;

[0018] The cloud server receives the instruction information requesting authentication data returned by the authentication server of the operator;

[0019] Among them, after confirming that the cloud phone user has a binding relationship with the cloud phone instance based on the indication information and the identity information, the cloud server executes the step of obtaining the soft SIM card information corresponding to the cloud phone instance.

[0020] Through the above embodiment, after receiving a cloud phone instance startup request, the cloud server first sends a network access authentication request to the authentication server. After receiving the indication information returned by the authentication server, it confirms whether the cloud phone user has a binding relationship with the cloud phone instance. Only after the cloud phone user has a binding relationship with the cloud phone instance can the soft SIM card information corresponding to the cloud phone instance be obtained to realize the identity verification of the soft SIM card. If the cloud phone user and the cloud phone instance do not have a binding relationship, the soft SIM card may be misused. This solves the technical problem of protecting the integrity and confidentiality of the cloud phone soft SIM card while preventing the soft SIM card from being stolen and misused.

[0021] In one possible implementation, the network access authentication request carries a second random value; the indication information requiring authentication data carries a second random result; the second random result is the result information after the operator's authentication server processes the second random value, which is used to verify whether the returned indication information is valid.

[0022] Through the above embodiment, the second random value is carried in the network access authentication request, which can prevent information from being leaked or tampered with by intentional attacks, prevent replay attacks on soft SIM identity authentication, and further improve the security of the communication process.

[0023] In a possible implementation, the sending the virtual SIM card information to the authentication server of the operator includes:

[0024] The cloud server sends authentication data to the operator's authentication server; the authentication data includes the soft SIM card information.

[0025] Through the above embodiment, when the cloud server sends authentication data to the operator's authentication server, it carries the virtual SIM card information for the subsequent virtual SIM card network access authentication process.

[0026] In a possible implementation, the authentication data carries a third random value; and after sending the authentication data to the operator's authentication server, the method further includes:

[0027] The cloud server receives the target random number and the third random result returned by the operator's authentication server; the third random result is the result information after the operator's authentication server processes the third random value, which is used to verify whether the returned target random number is valid.

[0028] Through the above embodiment, the third random value is carried in the authentication data, which can prevent information from being leaked or tampered with by intentional attacks, prevent replay attacks on soft SIM identity authentication, and further improve the security of the communication process.

[0029] In a possible implementation, the method further includes:

[0030] The cloud server receives the login request from the cloud phone application;

[0031] The cloud server sends login status information to the cloud phone application; wherein, after the cloud phone application successfully logs in, the login status information carries the user token of the cloud phone user.

[0032] Through the above embodiment, after the cloud phone application successfully logs in, the cloud server sends a login status message carrying a user token. The user token is a token for the cloud phone user and can be used to subsequently verify the identity of the soft SIM card.

[0033] In a possible implementation, the identity information of the cloud phone user includes the user token; and the method further includes:

[0034] The cloud server determines whether the user token that initiates the start request has a binding relationship with the cloud phone instance of the start request based on the stored binding relationship between the user token and the cloud phone instance;

[0035] Among them, different user tokens in the stored binding relationship correspond to different cloud phone instances.

[0036] Through the above embodiment, when a cloud phone application successfully logs in, the cloud server sends the cloud phone user's user token as the cloud phone user's identity information. Based on the stored binding relationship between the user token and the cloud phone instance, it can determine whether the user token initiating the launch request is bound to the cloud phone instance that initiated the launch request, thereby achieving identity verification of the soft SIM card. If the cloud phone user and the cloud phone instance are not bound, the soft SIM card may be misused. This solves the technical problem of protecting the integrity and confidentiality of the cloud phone soft SIM card while preventing the theft and misuse of the soft SIM card.

[0037] It is understandable that different user tokens in the stored binding relationship correspond to different cloud phone instances. Specifically, a cloud phone user can correspond to one or more cloud phone instances, and different cloud phone users can correspond to different cloud phone instances. The user token can be uniquely generated for a cloud phone user when logging in. In other words, the user token is uniquely associated with the cloud phone user, so different user tokens correspond to different cloud phone instances.

[0038] In one possible implementation, determining whether the user token initiating the start request has a binding relationship with the cloud phone instance of the start request based on the stored binding relationship between the user token and the cloud phone instance includes:

[0039] The cloud phone instance in the cloud server sends the user token of the startup request, the identifier of the cloud phone instance of the startup request, and the fourth random value to the identity authentication system; the identity authentication system stores the binding relationship between the user token and the cloud phone instance;

[0040] Determine, through the identity authentication system, whether the user token initiating the startup request has a binding relationship with the cloud phone instance of the startup request;

[0041] The cloud phone instance receives the confirmation result and the fourth random result returned by the identity authentication system; the fourth random result is the result information after the identity authentication system processes the fourth random value, which is used to verify whether the returned confirmation result is valid.

[0042] Through the above embodiment, carrying the fourth random value in the process of determining whether the user token that initiates the startup request has a binding relationship with the cloud phone instance of the startup request can prevent information from being leaked or tampered with by intentional attacks, prevent replay attacks on soft SIM identity authentication, and further improve the security of the communication process.

[0043] In a possible implementation, obtaining the soft SIM card information corresponding to the cloud phone instance includes:

[0044] The cloud phone instance in the cloud server sends a soft SIM card information acquisition request to the soft SIM card pool server; the soft SIM card information acquisition request carries the identifier of the cloud phone instance of the startup request and the fifth random value;

[0045] The cloud phone instance receives the soft SIM card information corresponding to the cloud phone instance of the startup request and the fifth random result returned by the soft SIM card pool server; the fifth random result is the result information after the soft SIM card pool server processes the fifth random value, which is used to verify whether the returned soft SIM card information is valid.

[0046] Through the above embodiment, the fifth random value is carried in the process of obtaining the virtual SIM card information from the virtual SIM card pool server, which can prevent the information from being leaked or tampered with by intentional attacks, prevent replay attacks on the virtual SIM identity authentication, and further improve the security of the communication process.

[0047] In a second aspect, the present application provides a communication device, including:

[0048] An instance startup request receiving module is used to receive a cloud phone instance startup request after the cloud phone application successfully logs in; the startup request carries the identity information of the cloud phone user;

[0049] A soft SIM card information acquisition module is used to obtain the soft SIM card information corresponding to the cloud phone instance after confirming that the cloud phone user has a binding relationship with the cloud phone instance based on the identity information;

[0050] The first sending module is configured to send the virtual SIM card information to the operator's authentication server.

[0051] In a possible implementation, the sending module is specifically configured to initiate a network access request to an authentication server of an operator; the network access request carries the virtual SIM card information.

[0052] In a possible implementation, the network access request further carries a first random value; and the communication device further includes:

[0053] The first receiving module is used to receive the target random number and the first random result returned by the operator's authentication server after the sending module initiates a network access request to the operator's authentication server; the first random result is the result information after the operator's authentication server processes the first random value, and is used to verify whether the returned target random number is valid.

[0054] In a possible implementation, the communication device further includes:

[0055] A second sending module is configured to send a network access authentication request to the operator's authentication server after the instance startup request receiving module receives the cloud phone instance startup request;

[0056] A second receiving module is configured to receive an indication message requesting authentication data returned by the authentication server of the operator;

[0057] Among them, after confirming that the cloud phone user has a binding relationship with the cloud phone instance based on the indication information and the identity information, the soft SIM card information acquisition module acquires the soft SIM card information corresponding to the cloud phone instance.

[0058] In one possible implementation, the network access authentication request carries a second random value; the indication information requiring authentication data carries a second random result; the second random result is the result information after the operator's authentication server processes the second random value, which is used to verify whether the returned indication information is valid.

[0059] In a possible implementation, the sending module is specifically configured to send authentication data to an authentication server of an operator; the authentication data includes the virtual SIM card information.

[0060] In a possible implementation, the authentication data carries a third random value; and the communication device further includes:

[0061] The third receiving module is used to receive the target random number and the third random result returned by the operator's authentication server after the sending module sends the authentication data to the operator's authentication server; the third random result is the result information after the operator's authentication server processes the third random value, and is used to verify whether the returned target random number is valid.

[0062] In a possible implementation, the communication device further includes:

[0063] The fourth receiving module is used to receive a login request from the cloud phone application;

[0064] The third sending module is used to send login status information to the cloud phone application; wherein, after the cloud phone application logs in successfully, the login status information carries the user token of the cloud phone user.

[0065] In a possible implementation, the identity information of the cloud phone user includes the user token; and the communication device further includes:

[0066] A determination module, configured to determine whether a user token initiating the startup request has a binding relationship with the cloud phone instance of the startup request based on the stored binding relationship between the user token and the cloud phone instance;

[0067] Among them, different user tokens in the stored binding relationship correspond to different cloud phone instances.

[0068] In a possible implementation, the determining module specifically includes:

[0069] A sending unit, configured to send the user token of the startup request, the identifier of the cloud phone instance of the startup request, and a fourth random value to an identity authentication system; the identity authentication system stores a binding relationship between the user token and the cloud phone instance;

[0070] A binding relationship confirmation unit, configured to determine, through the identity authentication system, whether a user token initiating the startup request has a binding relationship with the cloud phone instance of the startup request;

[0071] The first receiving unit is used to receive the confirmation result and the fourth random result returned by the identity authentication system; the fourth random result is the result information after the identity authentication system processes the fourth random value, and is used to verify whether the returned confirmation result is valid.

[0072] In a possible implementation, the soft SIM card information acquisition module specifically includes:

[0073] An acquiring unit, configured to send a request for acquiring virtual SIM card information to a virtual SIM card pool server; the request for acquiring virtual SIM card information carries an identifier of the cloud phone instance requested to start the request and a fifth random value;

[0074] A second receiving unit is configured to receive the soft SIM card information corresponding to the cloud phone instance of the startup request and a fifth random result returned by the soft SIM card pool server; the fifth random result is result information after the soft SIM card pool server processes the fifth random value, and is used to verify whether the returned soft SIM card information is valid.

[0075] In a third aspect, the present application provides a communication system comprising: one or more processors and one or more memories; the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer executable programs. When the one or more processors execute the computer executable programs, the communication system executes any possible implementation method as in the first aspect.

[0076] In a fourth aspect, the present application provides a computer-readable storage medium storing a computer program. When the computer program runs on a processor of an electronic device, the electronic device executes any possible implementation method as in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0077] Figure 1 This is a schematic diagram of the implementation of the eSIM without a physical chip provided by this application;

[0078] Figure 2 This is a schematic diagram of the system architecture of a communication method provided by this application;

[0079] Figure 3 This is a flow chart of a communication method provided by this application;

[0080] Figure 4 This is a flow chart of a communication method according to another embodiment of the present application;

[0081] Figure 5 It is a structural diagram of the communication system provided by this application. DETAILED DESCRIPTION

[0082] The following is a clear and detailed description of the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in the text is only a description of the association relationship between related objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0083] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to imply or suggest relative importance or implicitly indicate the number of the technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of this application, unless otherwise specified, "plurality" means two or more.

[0084] First, the terms involved in the embodiments of the present application are introduced.

[0085] (1) Cloud phone application software APP

[0086] The app running on your phone can create a cloud phone instance. This cloud phone instance runs as a virtual machine or container on a cloud server (such as a joint venture cloud server). After opening the cloud phone app and starting the cloud phone instance, you can remotely control it in real time via video streaming.

[0087] The mobile phone in this application may be an electronic device or terminal device with communication function, including but not limited to a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with wireless communication function, a computing device or other processing device connected to a wireless modem, a vehicle-mounted device, a wearable device, a terminal device in a future 5G / 6G network, or a terminal device in a future evolved public land mobile communication network (PLMN), etc.

[0088] (2) Cloud Phone Example

[0089] A cloud phone instance is a virtual computing environment for mobile phones on a cloud server. Logically, it's a mobile phone, including basic computer components like a processor (chip), memory, hard drive, operating system, and network. It runs the Android operating system and common applications. Essentially, it's a virtual machine or container on a cloud server (such as a joint venture cloud server). The cloud phone app allows you to start and stop the cloud phone instance and deploy apps.

[0090] (3) Operators

[0091] In this application, "operator" can refer to the operator's core network, which includes a number of service capabilities, and can specifically refer to operator equipment or operator systems, which may include 5G core network (5GC) / IP Multimedia Subsystem (IMS) authentication server, which is responsible for implementing authentication management, session management and routing, service triggering, network interoperability and other functions.

[0092] Specifically, operators can include the following service modules: ① Control Service, which communicates with external systems, transmits information to voice channels, and controls display. It is responsible for communicating with external systems, receiving and sending control information, and managing various call functions such as call display and call forwarding. ② Number Book Service, which maintains a pool of virtual numbers and manages the binding between customers and virtual numbers. ③ Address Service, which allows users to obtain the caller's geographic location, such as in emergency calls, where the caller's location must be determined. ④ Voice Service, which is used to create call channels and enable calls between two or more users.

[0093] Currently, the demand for independent voice numbers for cloud phones is based on the following background:

[0094] Special industry users require independent numbers: For security reasons, some industry customers require that voice service processes not fall back to the real device. They want to be able to make and receive calls directly from the cloud phone, leaving no trace on the real device. This requires the cloud phone to have a completely independent number from the real device. Current cloud phone voice technology works as follows: Whether using a real device number directly or using a multiple-number plan with a small number, calls made from the cloud phone essentially fall back to the real device, and call information is recorded on the real device.

[0095] New user expansion: The current multi-number plan adopts one card with multiple numbers, which can only be used by mobile users. Through the cloud voice independent number function, telecom users can also have a new mobile number when using the mobile cloud phone APP, bringing a new user to China Mobile.

[0096] In the field of mobile communications, SIM features can be implemented in two ways: SIM cards and electronic SIM cards (Embedded-SIM, eSIM). eSIM cards are further divided into two types: those with physical chips and those without physical chips. Cloud phones are software-based and cannot use eSIMs with physical chips. Only eSIMs without physical chips can be used. eSIMs without physical chips can be divided into those based on Trusted Execute Environment (TEE) and those implemented purely by software. Figure 1 shown.

[0097] The industry's cloud phones are mainly used in cloud gaming, cloud applications, content monitoring, corporate office, simulation testing and other scenarios. Generally, they do not have soft SIM cards, do not have the function of making calls, and there is no precedent to refer to. Figure 1 The analysis of the above-mentioned SIM implementation method shown can satisfy the cloud phone scenario by implementing an eSIM without a physical chip based on TEE or soft SIM.

[0098] In cloud phone scenarios, there's a risk of SIM card theft and misuse. SIM cards are the foundation of cloud phone voice services. Each cloud phone user has their own SIM card, and each user may even have multiple SIM cards. Both cloud phones and SIM cards are software-based, lacking physical chips like real SIM cards. This creates the risk of SIM card theft. For example, if cloud phone user A steals user B's SIM card and uses it to make calls or register internet financial accounts within user A's cloud phone instance, this could cause unnecessary losses to user B.

[0099] In order to solve the above problems, this application provides a communication method for authenticating the soft SIM card of the cloud phone through the binding relationship between the user and the cloud phone instance, which can solve the technical problem of how to prevent the soft SIM card from being stolen or misused while protecting the integrity and confidentiality of the cloud phone soft SIM card.

[0100] Figure 2 This is a schematic diagram of the system architecture of a communication method provided by this application, which specifically includes:

[0101] Electronic devices or terminal devices in the user domain, such as Figure 2 The phone in the cloud phone app is installed and can run the cloud phone app. Through the cloud phone app, you can start one or more cloud phones.

[0102] The servers of the joint cloud domain may specifically include the joint cloud identity authentication system, multiple cloud phone instances, and soft SIM card pool servers.

[0103] in:

[0104] The joint cloud identity authentication system can be used to handle cloud phone application login, user token feedback, confirm the binding relationship between cloud phone identity and cloud phone instance, etc.

[0105] Each cloud phone instance can logically simulate a mobile phone and may have an identity authentication module for interacting with the joint cloud identity authentication system and an access authentication module for interacting with the operator's authentication server.

[0106] The soft SIM card pool server may include a processor and a baseboard management controller (BMC). The BMC is responsible for core functions such as hardware status management, operating system management, health status management, and power consumption management. The BMC can be a small operating system independent of the server system, a chip integrated into the motherboard, or plugged into the motherboard via a high-speed serial computer expansion bus standard (Peripheral Component Interconnect Express, PCIE).

[0107] The soft SIM card pool server can be equipped with a Basic Input Output System (BIOS), which can be a tamper-proof boot program engraved on the motherboard ROM chip. The BIOS is responsible for calculating the system self-test program (POST) and the system self-boot program. The BIOS can also include ARM Trusted Firmware (ATF), providing a comprehensive security solution.

[0108] The soft SIM card pool server can also be equipped with a common environment (Rich Execution Environment, REE) for mobile devices, such as the Android system; and a TEE. The systems and applications running on the REE can be called the operating system OS (or Rich OS) and client applications (Client APP, CA). The CA can correspond to some upper-layer applications, such as fingerprint collection, payment applications, etc., and interact with the TEE environment by calling the TEE Client API. The TEE Client API is the interface provided to the outside by the TEE driver in the REE, which enables the CA running in the REE to exchange data with the trusted application (Trusted Application, TA) in the TEE. TEE is an independent execution environment that runs side by side with the REE and has its own execution space. The TA is an application that performs specific functions in the TEE. Each TA has one or more corresponding CAs in the REE. In the REE environment, by calling the CA's interface, information can be transmitted to the TEE environment to execute the TA, complete the corresponding function, and then return the calculation result.

[0109] The interaction process between CA and TA can be as follows: CA first calls the TEE Client API to trigger a system call, entering the REE operating system kernel state. Based on the parameters of the CA call, the corresponding REE driver is found. The REE driver enters monitor mode by calling assembly instructions and switches the processor to secure kernel state, entering secure mode. After switching to the TEE, the CA's service request is transmitted to the TEE side via the bus. The TEE OS then calls the corresponding TA through the TEE Internal API. Finally, after the TA completes its execution, it returns the results and data to the CA. After execution, it returns to the TEE kernel state and calls assembly instructions to enter the monitor mode and switch back to the REE environment.

[0110] It is understood that the communication method disclosed in the embodiments of this application involves steps executed in a server of the joint cloud domain, and can be set as needed to be executed or interactively executed by the joint cloud identity authentication system, cloud phone instance, or soft SIM card pool server. This application does not impose any restrictions.

[0111] The operator domain or telecom cloud domain may specifically include a 5GC / IMS authentication server.

[0112] The following is combined with Figure 3 To the attached Figure 4 The communication method of the embodiment of the present application is described with two embodiments, taking the mobile phone in the user domain, the server in the joint cloud domain, and the authentication server in the telecom cloud domain as three examples for explanation:

[0113] Example 1

[0114] Figure 3 This is a flow chart of a communication method provided by this application.

[0115] Step S300: The cloud phone app of the user domain phone initiates a login request for the cloud phone application to the server of the joint cloud domain;

[0116] Specifically, when a user wants to start the cloud phone app, they can click the cloud phone app icon on their phone, and the cloud phone app will then send a login request to the joint cloud identity authentication system in the joint cloud domain server. The login request may include information such as the user name and password.

[0117] In one possible implementation, the login request may also include a random value, a nonce, an app version, a protocol version, and an identification code. The nonce can be the current session ID or any random value, used for information verification between the communicating parties. The app version is used to compare whether the app versions of both parties are consistent. The protocol version is used to verify whether the protocols are consistent. The identification code is used to identify the service provider or developer's protocol.

[0118] Step S301: The joint venture cloud identity authentication system receives the login request and verifies whether the login is authorized;

[0119] Specifically, the joint cloud identity authentication system stores cloud phone user information (e.g., user information stored when all cloud phones are registered), including usernames, passwords, and cloud phone instance-related information (e.g., cloud phone instance IDs). The joint cloud identity authentication system verifies whether the login is authorized based on the username and password in the received login information.

[0120] In one possible implementation, if the login request also includes a Nonce, the joint cloud identity authentication system will process the Nonce according to the verification rules pre-negotiated by the communicating parties, for example, by adding 1 to the Nonce, to obtain the processed random value processing result and return it to the other party. If the login request also includes an APP version, the joint cloud identity authentication system will compare it with the cloud phone APP version information corresponding to the user stored in its own storage to check whether they are consistent. If the login request also includes a protocol version, the joint cloud identity authentication system can verify whether the protocol is consistent based on the received protocol version. If the login request also includes an identification code, the joint cloud identity authentication system can identify whether it complies with the agreement of the service provider or developer based on the identification code.

[0121] Step S302: The joint cloud identity authentication system sends login status information to the cloud phone APP of the user domain phone;

[0122] Specifically, the login status information may include a status code, user name, and identification code. After the joint cloud identity authentication system verifies the user name and password in the login information and authorizes the user to log in, the status code in the login status information may be status information indicating that the login is successful, and the login status information also carries the user token of the cloud phone user. The joint cloud identity authentication system can generate a user token for the cloud phone user after verifying the user name and password in the login information and authorizing the user to log in, and authenticate the user for subsequent interactions.

[0123] If the joint venture cloud identity authentication system cannot authorize the user to log in after verifying the user name and password in the login information, the status code in the login status information may be status information indicating that the login was unsuccessful.

[0124] In one possible implementation, if the login request includes a nonce, the login status information carries the random value processing result of the nonce. After receiving the login status information, the cloud phone app can parse the random value processing result to determine whether the information is valid.

[0125] Step S303: The cloud phone APP of the user domain phone receives the login status information;

[0126] Specifically, after receiving the login status information, the cloud phone app parses the status code in the login status information. If the status code indicates that the login is authorized, then step S304 is executed after the login is successful; if the status code indicates that the login is unsuccessful, then the process can be terminated or the cloud phone app login request can be re-initiated.

[0127] In one possible implementation, the login status information carries a random value processing result after processing the Nonce. The cloud phone APP parses the random value processing result in the login status information, and then processes the Nonce itself according to the verification rules agreed upon by both parties to obtain a processing result. The parsed processing result is compared with the processing result obtained by its own processing. If they are consistent, it indicates that the login status information is valid and the subsequent steps can be continued; if they are inconsistent, it indicates that it has been attacked by hackers or the network is abnormal, and the login status information received this time is invalid, and the subsequent steps are not executed.

[0128] Step S304: The cloud phone APP of the user domain phone triggers the startup of the cloud phone instance;

[0129] Specifically, the cloud phone app can be configured with one or more cloud phones, such as cloud phone a, cloud phone b, cloud phone c, etc. Users can trigger the cloud phone instance corresponding to one of the cloud phones as needed. The following example uses triggering and starting the cloud phone instance corresponding to cloud phone a to illustrate.

[0130] The server of the joint cloud domain has multiple cloud phone instances. After selecting to trigger the cloud phone instance corresponding to cloud phone a, the cloud phone app sends a cloud phone instance startup request to the cloud phone instance corresponding to cloud phone a on the server of the joint cloud domain (referred to as cloud phone a instance). This startup request may carry the user token received in step S302.

[0131] Step S305: The cloud phone instance a receives the cloud phone instance startup request and initiates an identity confirmation request to the joint cloud identity authentication system;

[0132] Specifically, after receiving the cloud phone instance startup request, the cloud phone instance a can initiate an identity confirmation request to the joint cloud identity authentication system through its own identity authentication module. The identity confirmation request can carry the user token of the startup request (i.e., the user token received in step S302) and the identifier of the cloud phone instance that initiated the startup request (i.e., cloud phone instance a).

[0133] In a possible implementation, the identity confirmation request may further carry a fourth random value Nonce, which is used by both communicating parties to perform information verification.

[0134] Step S306: The joint cloud identity authentication system receives the identity confirmation request and confirms the binding relationship between the cloud phone user and the cloud phone a instance;

[0135] Exemplarily, the joint cloud identity authentication system stores the binding relationship between the user token and the cloud phone instance, which can be specifically as follows: As shown in Table 1: The joint cloud identity authentication system can store the binding relationship between the cloud phone instances corresponding to different cloud phone users. A cloud phone user can be bound to one or more cloud phone instances. Different cloud phone users have different bound cloud phone instances. Exemplarily, the cloud phone instance shown in Table 1 can be the identifier of the cloud phone instance, and the identifiers of different cloud phone instances are different. For example, the identifier of cloud phone instance a is different from the identifiers of other instances.

[0136] Cloud phone user 1 Cloud phone a instance, cloud phone b instance Cloud phone user 2 Cloud Phone C Instance … … Cloud phone users Cloud phone x instance, cloud phone y instance, cloud phone z instance

[0137] Table 1

[0138] When the cloud phone APP initiates a login request for the cloud phone user and the login is successful, the joint cloud identity authentication system will send the user token generated for the cloud phone user to the cloud phone APP, that is, the user token also has a corresponding relationship with the cloud phone user who initiated the login request. In other words, the joint cloud identity authentication system is equivalent to storing the binding relationship between the user token and the cloud phone instance. It is understandable that this application does not limit other implementation methods of the binding relationship between the user token and the cloud phone instance, as long as it can be shown that the binding relationship between the user token and the cloud phone instance is stored.

[0139] Then, when confirming the binding relationship between the cloud phone user and the cloud phone instance A, the joint cloud identity authentication system can first resolve the corresponding cloud phone user based on the user token in the identity confirmation request, then confirm the cloud phone instance corresponding to the cloud phone user from Table 1, and finally determine whether the identifier of the confirmed cloud phone instance contains the identifier of the cloud phone instance carried in the identity confirmation request. If so, it is confirmed that the cloud phone user has a binding relationship with the cloud phone instance A. If not, it is confirmed that the cloud phone user does not have a binding relationship with the cloud phone instance A.

[0140] In one possible implementation, if the identity confirmation request also carries the fourth random value Nonce, the joint cloud identity authentication system will process the fourth random value Nonce according to the verification rules pre-negotiated by the communicating parties, for example, by adding Nonce+3, to obtain the processed fourth random result and return it to the other party.

[0141] Step S307: The joint cloud identity authentication system returns a feedback result to the cloud phone a instance;

[0142] Specifically, the joint cloud identity authentication system can return a feedback result to the identity authentication module of the cloud phone instance A. The feedback result is used to indicate that the cloud phone user has a binding relationship with the cloud phone instance A (i.e., identity confirmation is passed), or that the cloud phone user does not have a binding relationship with the cloud phone instance A (i.e., identity confirmation is failed).

[0143] In a possible implementation, if the identity confirmation request also carries the fourth random value Nonce, then the feedback result also carries the fourth random result.

[0144] Step S308: The cloud phone a instance receives the feedback result;

[0145] Specifically, if the feedback result indicates that the identity confirmation is successful, step S309 can be executed; if the feedback result indicates that the identity confirmation is unsuccessful, the cloud phone a instance can feedback a message that the cloud phone instance startup failed to the cloud phone APP, and the current processing flow can be ended.

[0146] In one possible implementation, if the feedback result carries the fourth random result, the cloud phone a instance parses the fourth random result in the feedback result, and then processes the fourth random value according to the verification rules agreed upon by both parties to obtain a processing result. The parsed fourth random result is compared with the processing result obtained by its own processing. If they are consistent, it indicates that the feedback result is valid and the subsequent steps can be continued; if they are inconsistent, it indicates that it has been attacked by hackers or the network is abnormal, and the feedback result received this time is invalid, and the subsequent steps are not executed.

[0147] Step S309: the cloud phone a instance sends a request to obtain the soft SIM card information to the soft SIM card pool server;

[0148] Specifically, the identity authentication module of the cloud phone a instance can request the corresponding soft SIM card information from the soft SIM card pool server. The soft SIM card information acquisition request can carry the identifier of the cloud phone instance that initiates the request (such as the cloud phone a instance) to obtain the soft SIM card information corresponding to the cloud phone instance.

[0149] In a possible implementation, the soft SIM card information acquisition request may further carry a fifth random value for information verification between the communicating parties.

[0150] Step S310: The virtual SIM card pool server receives the virtual SIM card information acquisition request and searches for corresponding virtual SIM card information;

[0151] Specifically, the soft SIM card pool server stores the soft SIM card information corresponding to the cloud phone instance. The soft SIM card information in this application can be a soft International Mobile Subscriber Identity (IMSI), etc., which can be used for operator authentication and network access information.

[0152] After receiving the request for obtaining the soft SIM card information, the soft SIM card pool server parses the request, obtains the identifier of the cloud phone instance that initiated the request, and learns which soft SIM card information needs to be searched.

[0153] In one possible implementation, if the identity confirmation request also carries the fifth random value, the soft SIM card pool server processes the fifth random value according to the verification rules pre-negotiated by the communicating parties, for example, by adding Nonce+5 to obtain the processed fifth random result and returns it to the other party.

[0154] Step S311: The soft SIM card pool server returns the soft SIM card information to the cloud phone a instance;

[0155] Specifically, the soft SIM card pool server may return the soft SIM card information to the identity authentication module of the cloud phone instance a. If the identity confirmation request also carries the fifth random value, the soft SIM card information may carry the fifth random result.

[0156] Step S312: the cloud phone a instance receives the soft SIM card information;

[0157] Specifically, Cloud Phone A instance parses the received virtual SIM card information to obtain information used for operator authentication and network access. If the virtual SIM card information also carries the fifth random result, Cloud Phone A instance parses the fifth random result and processes the fifth random value according to the agreed-upon verification rules to obtain a processing result. The parsed fifth random result is then compared with the processing result obtained by the instance. If they match, the virtual SIM card information is valid and subsequent steps can be continued. If they do not match, it indicates a hacker attack or network anomaly, and the received virtual SIM card information is invalid, so subsequent steps will not be executed.

[0158] Step S313: Cloud phone instance a initiates a network access request to the 5GC / IMS authentication server;

[0159] Specifically, the access authentication module of the cloud phone a instance can initiate a network access request to the 5GC / IMS authentication server. The network access request carries the soft SIM card information. In one possible implementation, the network access request can also carry a first random value for information verification between the communicating parties.

[0160] In a possible implementation, step S313 may further specifically include the cloud phone a instance first initiating an authentication request to the 5GC / IMS authentication server, and after the 5GC / IMS authentication server returns information requesting authentication data to the cloud phone a instance, the cloud phone a instance then initiates the network access request to the 5GC / IMS authentication server.

[0161] Step S314: The 5GC / IMS authentication server receives the network access request;

[0162] Specifically, after the 5GC / IMS authentication server parses the network access request, it generates authentication information, which can be a set of random numbers.

[0163] In one possible implementation, the network access request also carries a first random value. The 5GC / IMS authentication server then processes the first random value according to the verification rules pre-negotiated by the communicating parties, for example, by adding Nonce+4 to obtain the processed first random result and returns it to the other party.

[0164] Step S315: The 5GC / IMS authentication server returns authentication information to the cloud phone a instance;

[0165] Specifically, the 5GC / IMS authentication server can return authentication information to the access authentication module of the cloud phone a instance.

[0166] In a possible implementation, the network access request further carries a first random value, and the authentication information may further carry the first random result.

[0167] Step S316: The cloud phone a instance receives the authentication information returned by the 5GC / IMS authentication server.

[0168] Specifically, Cloud Phone A instance parses the authentication information. If the authentication information also carries the first random result, Cloud Phone A instance parses the first random result and processes the first random value according to the verification rules agreed upon by both parties. After obtaining a processing result, it compares the parsed first random result with the processing result obtained by its own processing. If they are consistent, the authentication information is valid and the subsequent steps can be continued. If they are inconsistent, it indicates that it has been attacked by a hacker or the network is abnormal. The authentication information received this time is invalid and the subsequent steps will not be executed.

[0169] It is understandable that the cloud phone a instance can subsequently send the authentication information (such as the set of random numbers) to the soft SIM card pool server, and let the soft SIM card pool server calculate the authentication result based on the authentication information and the key through the agreed algorithm, and return it to the cloud phone a instance, and the cloud phone a instance returns the authentication result to the 5GC / IMS authentication server. If the 5GC / IMS authentication server compares the authentication information in its database with another authentication result calculated by the agreed algorithm with the key, and the authentication result of the received cloud phone a instance, if they are consistent, the authentication is passed, indicating that the cloud phone a instance has successfully joined the network. If they are inconsistent, the authentication fails, indicating that the cloud phone a instance has failed to join the network.

[0170] Example 2

[0171] Figure 4 This is another flow chart of the communication method provided by this application.

[0172] Step S400: The cloud phone APP of the user domain mobile phone initiates a login request for the cloud phone application to the server of the joint cloud domain;

[0173] Step S401: The joint venture cloud identity authentication system receives the login request and verifies whether the login is authorized;

[0174] Step S402: The joint cloud identity authentication system sends login status information to the cloud phone APP of the user domain phone;

[0175] Step S403: The cloud phone APP of the user domain phone receives the login status information;

[0176] Step S404: The cloud phone APP of the user domain phone triggers the startup of the cloud phone instance;

[0177] Step S405: The cloud phone a instance receives the cloud phone instance startup request;

[0178] Specifically, steps S400 to S405 may refer to the above Figure 3 In steps S300 to S305 of the embodiment, the cloud phone a instance receives the content of the cloud phone instance startup request.

[0179] Step S406: The cloud phone instance a initiates an authentication request to the 5GC / IMS authentication server;

[0180] Specifically, after the cloud phone a instance receives the cloud phone instance startup request, it can first trigger an authentication request to the 5GC / IMS authentication server.

[0181] In a possible implementation, the authentication request may further carry a sixth random value Nonce, which is used by both communicating parties to perform information verification.

[0182] Step S407: The 5GC / IMS authentication server receives the authentication request and returns information requesting authentication data to the cloud phone a instance;

[0183] Specifically, if the authentication request carries the sixth random value Nonce, then the information requiring authentication data may carry verification result processing information, which processes the sixth random value Nonce, obtains the processed verification result processing information and returns it to the other party.

[0184] Step S408: The cloud phone a instance receives information requesting authentication data;

[0185] In one possible implementation, if the information requiring authentication data contains the verification result processing information, the cloud phone a instance parses the verification result processing information in the information requiring authentication data, and then processes the sixth random value Nonce according to the verification rules agreed upon by both parties and obtains a processing result. The parsed verification result processing information is compared with the processing result obtained by its own processing. If they are consistent, it indicates that the information requiring authentication data is valid and the subsequent steps can be continued; if they are inconsistent, it indicates that it has been attacked by hackers or the network is abnormal, and the information requiring authentication data received this time is invalid, and the subsequent steps are not executed.

[0186] Step S409: The cloud phone a instance initiates an identity confirmation request to the joint cloud identity authentication system;

[0187] Specifically, after the cloud phone a instance receives the information requesting authentication data, it triggers an identity confirmation request to the joint cloud identity authentication system.

[0188] In one possible implementation, after the cloud phone a instance receives the cloud phone instance startup request in step S405, steps S406 and S409 may be triggered at the same time. Then, after step S408, the process may wait until step S416 is completed before jumping to step S417 to continue execution.

[0189] Step S410: The joint cloud identity authentication system receives the identity confirmation request and confirms the binding relationship between the cloud phone user and the cloud phone a instance;

[0190] Step S411: The joint cloud identity authentication system returns a feedback result to the cloud phone a instance;

[0191] Step S412: the cloud phone a instance receives the feedback result;

[0192] Step S413: the cloud phone a instance sends a request to obtain the soft SIM card information to the soft SIM card pool server;

[0193] Step S414: The virtual SIM card pool server receives the virtual SIM card information acquisition request and searches for corresponding virtual SIM card information;

[0194] Step S415: The soft SIM card pool server returns the soft SIM card information to the cloud phone a instance;

[0195] Step S416: The cloud phone a instance receives the soft SIM card information;

[0196] Specifically, steps S410 to S416 may refer to the above Figure 3 Steps S306 to S312 of the embodiment.

[0197] Step S417: The cloud phone a instance sends authentication data to the 5GC / IMS authentication server;

[0198] Specifically, the authentication data carries the virtual SIM card information. In a possible implementation, the network access request may also carry a first random value for information verification between the communicating parties.

[0199] Step S418: The 5GC / IMS authentication server receives the authentication data;

[0200] Specifically, after the 5GC / IMS authentication server parses the authentication data, it generates authentication information, which can be a set of random numbers.

[0201] In one possible implementation, the authentication data also carries a first random value. The 5GC / IMS authentication server processes the first random value according to the verification rules pre-negotiated by the communicating parties, for example, by adding Nonce+4 to obtain the processed first random result and returns it to the other party.

[0202] Step S419: The 5GC / IMS authentication server returns authentication information to the cloud phone a instance;

[0203] In a possible implementation, the authentication data further carries a first random value, and the authentication information may further carry the first random result.

[0204] Step S420: The cloud phone a instance receives the authentication information returned by the 5GC / IMS authentication server.

[0205] Specifically, Cloud Phone A instance parses the authentication information. If the authentication information also carries the first random result, Cloud Phone A instance parses the first random result and processes the first random value according to the verification rules agreed upon by both parties. After obtaining a processing result, it compares the parsed first random result with the processing result obtained by its own processing. If they are consistent, the authentication information is valid and the subsequent steps can be continued. If they are inconsistent, it indicates that it has been attacked by a hacker or the network is abnormal. The authentication information received this time is invalid and the subsequent steps will not be executed.

[0206] It is understandable that the cloud phone a instance can subsequently send the authentication information (such as the set of random numbers) to the soft SIM card pool server, and let the soft SIM card pool server calculate the authentication result based on the authentication information and the key through the agreed algorithm, and return it to the cloud phone a instance, and the cloud phone a instance returns the authentication result to the 5GC / IMS authentication server. If the 5GC / IMS authentication server compares the authentication information in its database with another authentication result calculated by the agreed algorithm with the key, and the authentication result of the received cloud phone a instance, if they are consistent, the authentication is passed, indicating that the cloud phone a instance has successfully joined the network. If they are inconsistent, the authentication fails, indicating that the cloud phone a instance has failed to join the network.

[0207] In addition, the embodiment of the present application also provides a communication device, which can be a server of the joint cloud domain, including a device for executing the above Figure 3 or Figure 4 Modules for steps in the joint venture cloud domain server.

[0208] The embodiment of the present application further provides a communication system, which may include one or more processors and one or more memories; the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer executable programs. When the one or more processors execute the computer executable programs, the communication system performs the above Figure 3 or Figure 4 Steps for co-operating cloud domain servers. For example, Figure 5 The structural diagram of the communication system provided by the embodiment of the present application is shown. The communication system 50 may include: a joint cloud identity authentication system, a cloud phone instance device, and a soft SIM card pool server.

[0209] The joint cloud identity authentication system may include a first input device 501, a first output device 502, a first memory 503, and a first processor 504. The cloud phone instance device may include a second input device 505, a second output device 506, a second memory 507, and a second processor 508. The soft SIM card pool server may include a third input device 509, a third output device 5010, a third memory 5011, and a third processor 5012.

[0210] It is understandable that the number of the first processor 504, the second processor 508 or the third processor 5012 can be one or more. Figure 5 In the embodiment of the present application, the above-mentioned input device, output device, memory and processor may be connected via a bus or other means, wherein: Figure 5 The bus connection is taken as an example.

[0211] The following combines the above Figure 3In the embodiment, each processor executes the program in its own memory and may perform the following steps:

[0212] The first processor 504 of the joint cloud identity authentication system receives a login request from the cloud phone app on the user domain phone via the first input device 501 and then verifies whether the login is authorized. The first processor 504 sends login status information to the cloud phone app on the user domain phone via the first output device 502. If the login is authorized, the login status information may also carry the user token of the cloud phone user. The cloud phone app on the user domain phone receives the login status information.

[0213] The second processor 508 of the cloud phone instance device receives the cloud phone instance startup request through the second input device 505 and initiates an identity confirmation request to the joint cloud identity authentication system through the second output device 506 .

[0214] The first processor 504 of the joint cloud identity authentication system receives the identity confirmation request via the first input device 501 and confirms the binding relationship between the cloud phone user and the cloud phone instance A. The first processor 504 returns a feedback result to the cloud phone instance device via the first output device 502. The second processor 508 of the cloud phone instance device receives the feedback result via the second input device 505. If the feedback result indicates that the identity confirmation is successful, it sends a request to obtain the virtual SIM card information to the virtual SIM card pool server via the first output device 502.

[0215] The third processor 5012 of the virtual SIM card pool server receives the virtual SIM card information acquisition request through the third input device 509 and searches for the corresponding virtual SIM card information; and returns the virtual SIM card information to the cloud phone instance through the third output device 5010.

[0216] The second processor 508 of the cloud phone example device receives the virtual SIM card information through the second input device 505, obtains the operator authentication network access information, and initiates a network access request to the 5GC / IMS authentication server through the second output device 506. The second processor 508 receives the authentication information returned by the 5GC / IMS authentication server through the second input device 505.

[0217] Combined with the above Figure 4 In the embodiment, each processor executes the program in its own memory and may perform the following steps:

[0218] The first processor 504 of the joint cloud identity authentication system receives a login request from the cloud phone app on the user domain phone via the first input device 501 and then verifies whether the login is authorized. The first processor 504 sends login status information to the cloud phone app on the user domain phone via the first output device 502. If the login is authorized, the login status information may also carry the user token of the cloud phone user. The cloud phone app on the user domain phone receives the login status information.

[0219] The second processor 508 of the cloud phone instance device receives the cloud phone instance startup request via the second input device 505, initiates an authentication request to the 5GC / IMS authentication server via the second output device 506, and receives a message requesting authentication data from the 5GC / IMS authentication server via the second input device 505. The second processor 508 then initiates an identity confirmation request to the joint cloud identity authentication system via the second output device 506; or, while initiating the authentication request to the 5GC / IMS authentication server via the second output device 506, simultaneously initiates an identity confirmation request to the joint cloud identity authentication system.

[0220] The first processor 504 of the joint cloud identity authentication system receives the identity confirmation request via the first input device 501 and confirms the binding relationship between the cloud phone user and the cloud phone instance A. The first processor 504 returns a feedback result to the cloud phone instance device via the first output device 502. The second processor 508 of the cloud phone instance device receives the feedback result via the second input device 505. If the feedback result indicates that the identity confirmation is successful, it sends a request to obtain the virtual SIM card information to the virtual SIM card pool server via the first output device 502.

[0221] The third processor 5012 of the virtual SIM card pool server receives the virtual SIM card information acquisition request through the third input device 509 and searches for the corresponding virtual SIM card information; and returns the virtual SIM card information to the cloud phone instance through the third output device 5010.

[0222] The second processor 508 of the cloud phone example device receives the virtual SIM card information through the second input device 505, obtains the information used for operator authentication and network access, and sends the authentication data to the 5GC / IMS authentication server through the second output device 506. The second processor 508 receives the authentication information returned by the 5GC / IMS authentication server through the second input device 505.

[0223] It should be understood that each step in the above method embodiments provided herein can be implemented by hardware integrated logic circuits in a processor or by software instructions. The method steps disclosed in the embodiments of this application can be directly implemented as being executed by a hardware processor, or by a combination of hardware and software modules in a processor.

[0224] The present application also provides a communication service processing device, which includes: one or more processors and one or more memories; the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer executable programs. When the one or more processors execute the computer executable programs, the electronic device executes the method in any one of the above embodiments.

[0225] The present application also provides a computer program product, which includes: a computer program (also referred to as code, or instruction), which, when executed, enables a computer to execute the method executed by the communication service processing device of any of the above embodiments.

[0226] The present application also provides a computer-readable storage medium storing a computer program (also referred to as code or instruction). When the computer program is executed, the computer executes the method executed by the communication service processing device in any of the above embodiments.

[0227] The various implementation modes of this application can be combined arbitrarily to achieve different technical effects.

[0228] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive).

[0229] Those skilled in the art will appreciate that all or part of the process steps in the above-described method embodiments can be implemented by a computer program instructing the relevant hardware. The program can be stored in a computer-readable storage medium, and when executed, the program can include the process steps in the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0230] In short, the above are only embodiments of the technical solution of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made based on the disclosure of the present invention should be included in the scope of protection of the present invention.

Claims

1. A communication method, characterized in that: include: After the cloud phone application is successfully logged in, receive the cloud phone instance startup request; The activation request carries the identity information of the cloud phone user; After confirming that the cloud phone user has a binding relationship with the cloud phone instance based on the identity information, obtaining the soft SIM card information corresponding to the cloud phone instance; The virtual SIM card information is sent to the operator's authentication server.

2. The method according to claim 1, characterized in that The sending of the virtual SIM card information to the operator's authentication server includes: Initiate a network access request to the operator's authentication server; the network access request carries the virtual SIM card information.

3. The method according to claim 2, characterized in that The network access request also carries a first random value; after initiating the network access request to the operator's authentication server, the method further includes: Receive the target random number and the first random result returned by the operator's authentication server; the first random result is the result information after the operator's authentication server processes the first random value, which is used to verify whether the returned target random number is valid.

4. The method according to claim 1, wherein The method further comprises: After receiving the cloud phone instance startup request, sending a network access authentication request to the operator's authentication server; Receiving an instruction message requesting authentication data returned by the authentication server of the operator; Among them, after confirming that the cloud phone user has a binding relationship with the cloud phone instance based on the indication information and the identity information, the step of obtaining the soft SIM card information corresponding to the cloud phone instance is performed.

5. The method according to claim 4, characterized in that The network access authentication request carries a second random value; the indication information requiring authentication data carries a second random result; the second random result is the result information after the operator's authentication server processes the second random value, which is used to verify whether the returned indication information is valid.

6. The method according to claim 4 or 5, characterized in that The sending of the virtual SIM card information to the operator's authentication server includes: Sending authentication data to the operator's authentication server; the authentication data includes the soft SIM card information.

7. The method according to claim 6, characterized in that The authentication data carries a third random value; after sending the authentication data to the operator's authentication server, the method further includes: Receive the target random number and the third random result returned by the operator's authentication server; the third random result is the result information after the operator's authentication server processes the third random value, which is used to verify whether the returned target random number is valid.

8. The method according to any one of claims 1 to 7, characterized in that Also includes: Receive login requests from cloud phone applications; Sending login status information to the cloud phone application; wherein, after the cloud phone application successfully logs in, the login status information carries the user token of the cloud phone user.

9. The method according to claim 8, characterized in that The identity information of the cloud phone user includes the user token; the method further includes: Based on the stored binding relationship between the user token and the cloud phone instance, determining whether the user token that initiated the startup request has a binding relationship with the cloud phone instance of the startup request; Among them, different user tokens in the stored binding relationship correspond to different cloud phone instances.

10. The method according to claim 9, characterized in that The determining, based on the stored binding relationship between the user token and the cloud phone instance, whether the user token initiating the startup request has a binding relationship with the cloud phone instance of the startup request includes: Sending the user token of the startup request, the identifier of the cloud phone instance of the startup request, and the fourth random value to the identity authentication system; the identity authentication system stores the binding relationship between the user token and the cloud phone instance; Determine, through the identity authentication system, whether the user token initiating the startup request has a binding relationship with the cloud phone instance of the startup request; Receive the confirmation result and the fourth random result returned by the identity authentication system; the fourth random result is the result information after the identity authentication system processes the fourth random value, which is used to verify whether the returned confirmation result is valid.

11. The method according to any one of claims 1 to 10, characterized in that The obtaining of the soft SIM card information corresponding to the cloud phone instance includes: Sending a request for obtaining soft SIM card information to a soft SIM card pool server; the request for obtaining soft SIM card information carries the identifier of the cloud phone instance of the startup request and a fifth random value; Receive the soft SIM card information corresponding to the cloud phone instance of the startup request and the fifth random result returned by the soft SIM card pool server; the fifth random result is the result information after the soft SIM card pool server processes the fifth random value, which is used to verify whether the returned soft SIM card information is valid.

12. A communication device, characterized in that: The method comprises modules for performing the steps of the method according to any one of claims 1 to 11.

13. A communication system, characterized in that: include: one or more processors and one or more memories; The one or more memories are coupled to one or more processors, and the one or more memories are used to store computer-executable programs. When the one or more processors execute the computer-executable programs, the communication system executes the method according to any one of claims 1 to 11.

14. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed on a processor of an electronic device, the electronic device is caused to execute the method according to any one of claims 1 to 11.

Citation Information

Cited By

  • Cloud mobile phone starting method and device, storage medium and electronic equipment

    CN121284016A