Incoming call processing method and electronic device

Abstract

The present application discloses a method and electronic device for processing incoming calls, which relates to the field of communication technology and is applied to electronic devices. The electronic device includes a first communication module, including: the electronic device receives an incoming call request and obtains characteristic information of the incoming call request. The characteristic information includes an incoming call number, and the electronic device sends a verification request to the address where the incoming call number is located to verify whether the incoming call request comes from the address where the incoming call number is located. The electronic device receives response information for the verification request, and if the response information indicates that the address where the incoming call number is located has not sent an incoming call request, a risk number processing operation is performed. In the present application, the electronic device sends a verification request to the address where the incoming call number is located to identify whether the received incoming call request actually comes from the address where the incoming call number is located, which can effectively identify the authenticity of the incoming call number, and timely perform risk number processing operations to reduce the risk of loss of user information or resources to a certain extent.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of communication technology, and in particular, to a method and electronic device for processing an incoming call. Background Art

[0002] With the development of electronic equipment communication technology, the application scenarios of voice transmission (VoIP) based on the Internet protocol multimedia subsystem (IMS) are increasing. For example, online car-hailing drivers make VoIP calls with passengers through online car-hailing application platforms; food delivery drivers make VoIP calls with customers through food delivery application platforms, etc.

[0003] Electronic devices can use network virtual numbers to make VoIP calls, which results in a high risk of unreliable incoming numbers for VoIP calls. For example, the call initiator can disguise the network virtual number as a designated number to make a call request to the electronic device. When the electronic device rings, the calling number displayed is the disguised designated number, thereby misleading the user of the electronic device about the incoming number. In the subsequent call process, the risk of user information or resource leakage is increased.

[0004] The existing incoming call number risk identification technology is based on the risk number database or number blacklist to identify the risk of incoming call numbers, but the disguised designated numbers in the above scenario often do not exist in the risk number database or number blacklist. Therefore, the existing technology cannot realize the risk identification of the disguised designated numbers. Summary of the invention

[0005] The embodiment of the present application provides a method and electronic device for processing incoming calls. The electronic device can send a verification request to the address of the incoming call number to identify whether the received incoming call request actually comes from the address of the incoming call number, and can effectively identify the authenticity of the incoming call number. If the incoming call number is a virtual number disguised as another designated number, the verification response of the verification request will indicate that the address of the incoming call number has not sent an incoming call request. In this way, the electronic device can effectively determine whether the incoming call number is a risky number and perform risky number processing operations based on the incoming call number, thereby reducing the risk of loss of user information or resources to a certain extent.

[0006] In order to achieve the above-mentioned purpose, the embodiments of the present application adopt the following technical solutions.

[0007] In a first aspect, a method for processing an incoming call is provided, which is applied to an electronic device, the electronic device including a first communication module, and the method including:

[0008] The electronic device receives an incoming call request and obtains characteristic information of the incoming call request, wherein the characteristic information includes the incoming call number.

[0009] The electronic device sends a verification request to the address where the incoming call number is located to verify whether the incoming call request comes from the address where the incoming call number is located.

[0010] The electronic device receives response information for the verification request, and if the response information indicates that the address of the incoming call number has not initiated a call request, a corresponding risk handling operation is performed.

[0011] In the present application, the electronic device can obtain the characteristic information carried in the incoming call request, which includes the incoming call number. The electronic device can send a verification request to the address of the incoming call number to identify whether the received incoming call request actually comes from the address of the incoming call number, and can effectively identify the authenticity of the incoming call number. In particular, in the scenario where a virtual network number is used to disguise a designated number to initiate an incoming call request, if the incoming call number is indeed a disguised number A, and the incoming call request does not come from the address of the real number A, then the verification response of the verification request will indicate that the address of number A has not initiated the incoming call request. In this way, the electronic device can determine that the incoming call number is a disguised risk number and perform corresponding risk handling operations, which reduces the risk of loss of user information or resources to a certain extent.

[0012] In a possible implementation manner of the first aspect, the electronic device sends a verification request to an address where an incoming call number is located, including:

[0013] If the characteristic information does not include resource reservation information, the electronic device sends a verification request to the address where the incoming call number is located.

[0014] In the present application, when the feature information does not include resource reservation information, it means that the current incoming call request does not support resource reservation, and the incoming call request has a certain risk. In this case, the electronic device sends a verification request to the address of the incoming call number to further verify whether the incoming call request actually comes from the address of the incoming call number, so that the risk identification result of the incoming call request is more reliable.

[0015] In another possible implementation manner of the first aspect, the electronic device sends a verification request to the address where the incoming call number is located, including:

[0016] If the characteristic information does not include device capability information, the electronic device sends a verification request to the address where the incoming call number is located.

[0017] In the present application, the characteristic information does not include the device capability information, which means that the incoming call request may not come from the mobile terminal, which has certain risks. In this case, the electronic device sends a verification request to the address of the incoming call number to further verify whether the incoming call request actually comes from the address of the incoming call number, so that the risk identification result of the incoming call request is more reliable.

[0018] In another possible implementation manner of the first aspect, the feature information further includes an actual call number, and the electronic device sends a verification request to an address where the incoming call number is located, including:

[0019] If the actual calling number in the characteristic information is inconsistent with the incoming call number in the characteristic information, the electronic device sends a verification request to the address where the incoming call number is located.

[0020] In this application, if the actual call number in the feature information is inconsistent with the incoming call number in the feature information, it means that the incoming call request is a VoIP call, and the incoming call number is obtained by modifying and disguising the actual call number. Disguising the actual call number as another number has certain risks. In this case, the electronic device sends a verification request to the address where the incoming call number is located to further verify whether the incoming call request actually comes from the address where the incoming call number is located, making the risk identification result of the incoming call request more reliable. The inconsistency between the actual call number and the incoming call number can quickly and effectively identify whether the incoming call number is a disguised number.

[0021] In another possible implementation manner of the first aspect, the feature information further includes a user type of the call initiator, and the electronic device sends a verification request to the address of the incoming call number, including:

[0022] If the user type in the characteristic information indicates a non-cellular communication user, the electronic device sends a verification request to the address where the incoming call number is located.

[0023] In the present application, the field used to characterize the user type of the call initiator in the feature information is noa. When noa is subscriber, it indicates a cellular communication user; when the value of noa is not subscriber, for example, when the value of noa is national or the value is empty, the user type is a non-cellular communication user, indicating that the incoming call request is not from an ordinary call, and the incoming call request may be from a VoIP call. It is easier to disguise a network virtual number as a designated number in a VoIP call, making VoIP calls more at risk of user information or resource leakage. Therefore, when the user type indicates a non-cellular communication user, the electronic device sends a verification request to the address where the incoming call number is located to further verify whether the incoming call request actually comes from the address where the incoming call number is located, making the risk identification result of the incoming call request more reliable. The inconsistency between the actual calling number and the incoming call number can quickly and effectively identify whether the incoming call number is a disguised number.

[0024] In another possible implementation manner of the first aspect, performing the corresponding risk handling operation includes:

[0025] The electronic device performs a ringing operation in response to an incoming call request and outputs risk reminder information; the risk reminder information is used to remind the user that there is a risk in the incoming call request.

[0026] Or, the electronic device rejects the incoming call request.

[0027] or, when the characteristic information includes device capability information,

[0028] In response to an incoming call request, the electronic device performs a ringing operation and displays a guidance interface, wherein the guidance interface includes a first content and a second content, wherein the first content is used to provide the user with the device model corresponding to the incoming call request, and the second content is used to prompt the user to conduct a question-and-answer verification of the device model with the call initiator after the call is connected.

[0029] In this application, when the electronic device determines that the incoming call number is a risky number, it handles the risk in different ways. For example, if there is a certain risk, but the risk is not very high, the electronic device can respond to the incoming call request and output risk reminder information to provide the user with the possible risk of the call; if the risk is very high, the electronic device can directly refuse, thereby reducing the leakage of information or resources caused by the user answering the risky call from the source. Alternatively, the electronic device can also respond to the incoming call request and output a guidance interface. The content provided by the guidance interface can serve as a risk reminder for the user and increase the user's alertness to the current incoming call request. A variety of different processing methods can play a role in risk management and control to varying degrees while effectively reducing the risk of information or resource leakage caused by the user connecting to the risky number.

[0030] In another possible implementation manner of the first aspect, the feature information includes an actual call number and a user type of the call initiator; and the method further includes:

[0031] The electronic device uses feature information to calculate a risk quantification value for an incoming call request; wherein the feature information does not include resource reservation information, the feature information does not include device capability information, the actual call number is inconsistent with the incoming call number, and the user type indicates a non-cellular communication user, all of which are used to increase the risk quantification value.

[0032] The electronic device performs corresponding risk handling operations based on the risk quantification value.

[0033] In the present application, the electronic device obtains the risk quantification value of the incoming call request based on different characteristic information. The risk represented by the risk quantification value of the incoming call request obtained by the electronic device is more reliable. The risk quantification value also means the risk level of the incoming call request. Therefore, the electronic device can perform corresponding risk handling operations according to different levels of risk. The higher the risk level, the more direct the handling means for the incoming call request.

[0034] In another possible implementation manner of the first aspect, the method further includes:

[0035] If the response information indicates that the address of the incoming call number has not initiated a call request, the risk quantification value is increased and updated.

[0036] In the present application, the response information can directly indicate the consistency between the call initiator of the call request and the address of the incoming call number. If the response information indicates that the address of the incoming call number has not issued the call request, that is, the call initiator of the call request is not the address of the incoming call number, and the incoming call number is a disguised number, the electronic device increases and updates the risk quantification value to make the risk quantification value more accurate.

[0037] In another possible implementation manner of the first aspect, the feature information further includes device capability information; and the method further includes:

[0038] If the characteristic information includes device capability information, the electronic device obtains a comparison result between the device capability information in the characteristic information and the device capability information corresponding to the incoming call number;

[0039] If the comparison result indicates that the device capability information in the feature information is inconsistent with the device capability information corresponding to the incoming call number, the risk quantification value is increased and updated.

[0040] In the present application, the electronic device updates the risk quantification value based on the consistency between the device capability information in the feature information and the device capability information corresponding to the incoming call number, and identifies the risk of the incoming call request from different dimensions, so that the calculated risk quantification value is more accurate.

[0041] In another possible implementation manner of the first aspect, the method further includes:

[0042] If the risk quantification value is greater than a preset first threshold, the electronic device performs a ringing operation in response to the incoming call request and outputs risk reminder information, wherein the risk reminder information is used to remind the user that the incoming call request has risks.

[0043] In this application, if the risk quantification value is greater than a preset first threshold, the risk greater than the first threshold means that the incoming call request is risky, but the risk level is not very high. In this case, the electronic device responds to the incoming call request, performs a ringing operation, and outputs risk reminder information, which plays a role in accurately alerting the user.

[0044] In another possible implementation manner of the first aspect, the method further includes:

[0045] If the risk quantification value is less than or equal to a first threshold and greater than a preset second threshold, the electronic device responds to the incoming call request, performs a ringing operation, and displays a guidance interface, the guidance interface including a first content and a second content, the first content being used to provide the user with the device model corresponding to the incoming call request, and the second content being used to prompt the user to conduct a question-and-answer verification of the device model with the call initiator after the call is connected.

[0046] In this application, if the risk quantification value is less than or equal to the first threshold and greater than the second threshold, it means that the call request has a risk, but the risk level is not very high, and the user can be guided to further verify the risk of the incoming call request. The guidance interface can also play a role in alerting the user.

[0047] In another possible implementation manner of the first aspect, the method further includes:

[0048] If the risk quantification value is greater than a preset third threshold, the electronic device rejects the incoming call request; the third threshold is greater than the first threshold.

[0049] In this application, if the risk quantification value is greater than the preset third threshold, it means that the risk level of the incoming call request is very high, and if the user answers the call, it is easy to cause user information or resource leakage. In this case, the electronic device rejects the incoming call request. When the electronic device rejects the incoming call request, for the user, the electronic device does not ring or remind, and the user is unaware of this operation, which also fundamentally avoids the leakage of user information or resources when the user answers the call.

[0050] In a second aspect, a method for processing an incoming call is provided, which is applied to a server, the server including a second communication module, and the server is communicatively connected with an electronic device, the method including:

[0051] The server receives a verification request sent by the electronic device; the verification request is a request initiated by the electronic device based on the incoming call number in the feature information after obtaining the feature information of the incoming call request when receiving the incoming call request;

[0052] The server returns response information for the verification request to the electronic device; the response message is used to indicate whether the address of the incoming call number has initiated a call request.

[0053] In a third aspect, a method for processing an incoming call is provided, which is applied to a server, wherein the server includes a second communication module, and the server is communicatively connected with an electronic device, and the method includes:

[0054] The server receives the call request and obtains characteristic information of the call request, wherein the characteristic information includes an incoming call number and a destination number, and the destination number corresponds to an electronic device.

[0055] The server sends a verification request to the address where the incoming call number is located to verify whether the call request comes from the address where the incoming call number is located.

[0056] The server receives response information for the verification request. If the response information indicates that the address of the incoming call number has not initiated a call request, the server sends a call request and risk reminder information to the electronic device, or the server rejects the call request.

[0057] The risk reminder information is used to remind users of electronic devices that there are risks in their call requests.

[0058] In the present application, the server can obtain the characteristic information carried in the call request, which includes the incoming call number. The server can send a verification request to the address where the incoming call number is located to identify whether the received call request actually comes from the address where the incoming call number is located, and can effectively identify the authenticity of the incoming call number. In particular, in the scenario where a call request is initiated by disguising a virtual network number as a designated number, if the incoming call number is indeed a disguised number A, and the call request does not come from the address where the real number A is located, then the response information of the verification request will indicate that the address where the number A is located has not initiated a call request, so that the server can determine that the incoming call number is a disguised risk number. When the server determines that the incoming call number is a risk number, it can send a call request to the electronic device while sending a risk reminder information for reminding the user of the electronic device that the call request is risky; or, when the server determines that the incoming call number is a risk number, the server can directly reject the call request to intercept the call request of the risk number, greatly reducing the probability of the electronic device answering the risk number, and to a certain extent reducing the risk of user information or resources of the electronic device being lost.

[0059] In a possible implementation manner of the third aspect, the feature information includes at least one of resource reservation information, device capability information, an actual call number, and a user type of a call initiator; and the method further includes:

[0060] The server uses the feature information to calculate the risk quantification value of the call request; wherein, the resource reservation information indicating that no resources are reserved, the device capability information is empty, the actual call number is inconsistent with the incoming call number, and the user type indicates a non-cellular communication user, all of which are used to increase the risk quantification value.

[0061] The server performs corresponding risk handling operations based on the risk quantification value.

[0062] In the present application, when the server determines that the incoming call number is a risky number, it can obtain the risk quantification value of the call request, and perform risk processing in different ways based on the risk level represented by the risk quantification value. A variety of different processing methods correspond to different risk levels. While effectively reducing the risk of user information or resource leakage caused by risky call requests, it can play a risk management role to varying degrees, optimize the processing granularity of risk identification and risk avoidance, and make the risk identification of call requests more accurate.

[0063] In another possible implementation manner of the third aspect, the method further includes:

[0064] If the response information indicates that the address of the incoming call number has not initiated a call request, the risk quantification value is increased and updated.

[0065] In the present application, the response information can directly indicate the consistency between the call initiator who initiated the call request and the address where the incoming call number is located. If the response information indicates that the address where the incoming call number is located did not initiate the call request, that is, the call initiator who initiated the call request is not the address where the incoming call number is located, and the incoming call number is a disguised number, the electronic device increases and updates the risk quantification value to make the risk quantification value more accurate.

[0066] In another possible implementation manner of the third aspect, the server performs a corresponding risk processing operation based on the risk quantification value, including:

[0067] If the risk quantification value is greater than the preset first threshold, the server sends a call request and risk reminder information to the address of the destination number; if the risk quantification value is greater than the preset third threshold, the server rejects the call request; the third threshold is greater than the first threshold.

[0068] In the present application, when the server determines that the incoming call number is a risky number, it can obtain the risk quantification value of the call request, and perform risk processing in different ways based on the risk level represented by the risk quantification value. A variety of different processing methods correspond to different risk levels. While effectively reducing the user information or resource leakage that may be caused by risky call requests, it can play a risk management role to varying degrees, optimize the processing granularity of risk identification and risk avoidance, and make the risk identification of call requests more accurate.

[0069] In a fourth aspect, an electronic device is provided, which includes a mobile first communication module, a memory and one or more processors; the first communication module and the memory are coupled to the processor; the memory stores computer program code, and the computer program code includes computer instructions, and when the computer instructions are executed by the processor, the electronic device executes a method as described in any one of the above-mentioned first aspects.

[0070] In a fifth aspect, a server is provided, which includes a second communication module, a memory and one or more processors; the second communication module and the memory are coupled to the processor; the memory stores computer program code, and the computer program code includes computer instructions, and when the computer instructions are executed by the processor, the electronic device executes a method as described in any one of the second or third aspects above.

[0071] In the sixth aspect, a computer-readable storage medium is provided, which stores instructions, and when the computer-readable storage medium is run on an electronic device, the electronic device can execute any method described in the first aspect above; when the computer-readable storage medium is run on a server, the server can execute any method described in the second or third aspect above.

[0072] In the seventh aspect, a computer program product comprising instructions is provided, which, when running on an electronic device, enables the electronic device to execute any of the methods described in the first aspect above; and when running on a server, enables the server to execute any of the methods described in the second or third aspect above.

[0073] In an eighth aspect, an embodiment of the present application provides a chip, the chip including a processor, the processor being used to call a computer program in a memory to execute a method such as the first aspect, the second aspect, or the third aspect.

[0074] It can be understood that the beneficial effects that can be achieved by the electronic device described in the fourth aspect, the server described in the fifth aspect, the computer-readable storage medium described in the sixth aspect, the computer program product described in the seventh aspect, and the chip described in the eighth aspect provided above can refer to the beneficial effects of the first aspect and any possible design method thereof, the second aspect, and the third aspect and any possible design method thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] Figure 1 A schematic diagram of a call environment provided in an embodiment of the present application;

[0076] Figure 2 A schematic diagram of an interaction between a UAC, a UAS and a server for a session provided in an embodiment of the present application;

[0077] Figure 3 A schematic diagram of the header field information of an INVITE provided in an embodiment of the present application;

[0078] Figure 4 An interactive schematic diagram of a method for processing an incoming call provided in an embodiment of the present application;

[0079] Figure 5 A schematic diagram of information comparison of the Supported header field of a normal call and a VoIP call provided in an embodiment of the present application;

[0080] Figure 6 An interactive schematic diagram of another incoming call processing method provided by an embodiment of the present application;

[0081] Figure 7 A schematic diagram of information comparison of the Contact header field of a normal call and a VoIP call provided in an embodiment of the present application;

[0082] Figure 8 An interactive schematic diagram of another incoming call processing method provided by an embodiment of the present application;

[0083] Fig. 9 An interactive schematic diagram of another incoming call processing method provided by an embodiment of the present application;

[0084] Fig.10 A schematic diagram comparing the noa field of the From header field of a normal call and a VoIP call provided in an embodiment of the present application;

[0085] Fig.11 An interactive schematic diagram of another incoming call processing method provided by an embodiment of the present application;

[0086] Fig.12An interactive schematic diagram of another incoming call processing method provided by an embodiment of the present application;

[0087] Fig.13 A schematic diagram of an interface for outputting risk reminder information of an electronic device provided in an embodiment of the present application;

[0088] Fig.14 A schematic diagram of an interface for outputting guidance information of an electronic device provided in an embodiment of the present application;

[0089] Fig.15 An interactive schematic diagram of another incoming call processing method provided by an embodiment of the present application;

[0090] Fig.16 An interactive schematic diagram of another incoming call processing method provided by an embodiment of the present application;

[0091] Fig.17 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0092] Fig.18 A software structure block diagram of an electronic device provided in an embodiment of the present application;

[0093] Fig.19 An interactive schematic diagram of another incoming call processing method provided by an embodiment of the present application;

[0094] Fig. 20 An interactive schematic diagram of another incoming call processing method provided by an embodiment of the present application;

[0095] Fig.21 A schematic diagram of the structure of a server provided in an embodiment of the present application;

[0096] Fig. 22 A schematic diagram of the structure of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0097] In the description of the embodiments of the present application, the terms used in the following embodiments are only for the purpose of describing specific embodiments, and are not intended to be used as limitations to the present application. As used in the specification and the appended claims of the present application, the singular expressions "a", "said", "above", "the" and "this" are intended to also include such expressions as "one or more", unless there is a clear contrary indication in the context. It should also be understood that in the following embodiments of the present application, "at least one", "one or more" refer to one or more (including two). The term "and / or" is used to describe the association relationship of associated objects, indicating that three relationships can exist; for example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the associated objects before and after are a kind of "or" relationship.

[0098] References to "one embodiment" or "some embodiments" etc. described in this specification mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Thus, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways. The term "connection" includes direct connection and indirect connection, unless otherwise specified. "First" and "second" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated.

[0099] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0100] With the development of electronic equipment communication technology and the rapid development of Internet Protocol (IP) networks, there are more and more application scenarios for voice transmission (VoIP) based on IP multimedia system (IMS). For example, online car-hailing applications can provide VoIP call services for drivers and passengers; food delivery applications can provide VoIP call services for merchants, deliverymen and customers; online conference applications can provide VoIP call services for multiple participants, etc.

[0101] Electronic devices can use network virtual numbers to make VoIP calls, which increases the risk that the incoming call number of VoIP calls is unreliable. For example, the call initiator can disguise the network virtual number as a designated number to send a call request to the electronic device. When the electronic device rings, the caller ID code will be the disguised designated number, thereby misleading the user of the electronic device about the incoming call number. In the subsequent call process, the risk of user information or resource leakage is increased.

[0102] Existing caller number risk identification technology can identify the risks of caller numbers through a risk number database or a number blacklist. If the caller number is identified as being in a risk number database or a number blacklist, corresponding risk processing can be performed. Alternatively, the existing technology can also identify the risks of caller numbers according to the number arrangement rules of the caller numbers. For example, the official corporate numbers starting with "95" are usually five digits. If the caller number is an eight-digit number starting with "95", it is likely to be a risk number. For example, corporate numbers starting with "400" are usually only used for answering calls, and this number will not be used to call customers. If the caller number is a number starting with "400", it is likely to be a risk number. For example, numbers starting with "00" or "+" are international long-distance numbers and are likely to be risk numbers, and so on.

[0103] However, the designated number disguised in a VoIP call may be the number of the call recipient's address book contact or other designated number. The disguised designated number often does not exist in the risk number database or number blacklist, and does not have the characteristics of the number arrangement rules of the numbers mentioned above. The existing technology cannot identify the risk of disguised designated numbers. In addition, since the disguised designated number is more misleading, the risk of information or resource leakage during the call is greater in this scenario.

[0104] This embodiment provides a method for processing an incoming call, which can be applied to Figure 1In the call environment shown in FIG. 1 , the electronic device may execute the incoming call processing method provided by the present embodiment as an example. Figure 1 The terminal equipment shown.

[0105] in, Figure 1 Including terminal equipment that supports voice over new radio (VoNR) Figure 1 The figure shows a terminal device supporting VoNR, hereinafter referred to as NR terminal), NR base station, and NR network; a terminal device supporting voice over long term evolution (VoLTE) ( Figure 1 Shown in the figure are terminal equipment supporting VoLTE, hereinafter referred to as LTE terminal), LTE base station, and LTE network.

[0106] Figure 1 It also includes IMS network, switches, IP phone platform, intermediate number platform and other public switched telephone network platforms. Among them, the IP phone platform can forward the relevant requests in VoIP calls (also known as IP phones) and forward the requests to the IMS network for further request processing. Figure 1 The IMS network in the NR network includes an IMS network communicating with the NR network and an IMS network communicating with the LTE network.

[0107] Take a device / user initiating a VoIP call as an example. Figure 1 , a device / user initiates a VoIP call request to the destination number. The call request is forwarded to the network where the mobile terminal corresponding to the destination number is located through the IP phone platform and IMS network.

[0108] If the mobile terminal corresponding to the destination number is an NR terminal, the incoming call request is forwarded to the NR network through the IP telephone platform and the IMS network. The NR network forwards the incoming call request to the NR base station, and the NR base station sends the incoming call request to the NR terminal corresponding to the destination number.

[0109] If the mobile terminal corresponding to the destination number is an LTE terminal, the incoming call request is forwarded to the LTE network through the IP phone platform and the IMS network. The LTE network forwards the incoming call request to the LTE base station, and the LTE base station sends the incoming call request to the LTE terminal corresponding to the destination number. Figure 1If the IMS network communicating with the IP phone platform corresponds to the NR network, then the IMS network can forward the incoming call request to the switch, and the switch distributes the incoming call request to the IMS network corresponding to the LTE network. The IMS network forwards the incoming call request to the LTE network, and the LTE network forwards the incoming call request to the LTE base station, and the LTE base station sends the incoming call request to the LTE terminal corresponding to the destination number.

[0110] Optionally, taking the call request of a non-VoIP call initiated by an LTE terminal as an example, the non-VoIP call here can be understood as a call based on a public switched network provided by an operator (hereinafter referred to as a normal call). Figure 1 , the LTE terminal sends an incoming call request to the destination number. The incoming call request will be forwarded to the network where the mobile terminal corresponding to the destination number is located through the LTE base station, LTE network, and IMS network.

[0111] If the mobile terminal corresponding to the destination number is an NR terminal, the incoming call request is forwarded to the NR network through the LTE base station, LTE network, and IMS network. The NR network forwards the incoming call request to the NR base station, and the NR base station sends the incoming call request to the NR terminal corresponding to the destination number.

[0112] The IMS network also communicates with the intermediate number platform and other public switched telephone network platforms. For incoming call requests initiated through the intermediate number platform and other public switched telephone network platforms, the IMS network can forward the incoming call requests to the network where the mobile terminal corresponding to the destination number is located based on the destination number indicated in the incoming call requests.

[0113] The two parties of a voice call (including VoIP calls and ordinary calls) can establish a session based on the Session Initialization Protocol (SIP). SIP is a signaling control protocol that implements real-time communication applications based on IP networks. The communication system based on SIP adopts a client / server structure and consists of two parts: a user agent and a server.

[0114] Among them, the user agent is divided into the user agent client (UAC) and the user agent server (UAS). Among them, UAC is used to initiate a session request (i.e., the call initiator / caller), and UAS is used to accept and respond to session requests (i.e., the call receiver / called party). In fact, electronic devices with mobile communication modules should have both functions, that is, they can initiate a session and accept and respond to a session.

[0115] based on Figure 1The given call environment diagram shows that in the scenario where a device / user initiates a VoIP call to a destination number, the device / user is the UAC; the mobile terminal to which the destination number belongs is the UAS. NR base stations and NR networks, LTE base stations and LTE networks, IMS networks, etc. can act as servers.

[0116] When UAC initiates a call request, it usually sends the call request to the server in the same domain (for example, Figure 1 The server forwards the incoming call request to the UAS server according to the called address in the incoming call request (that is, the address of the destination number). The UAS server forwards the incoming call request to the UAS. Generally, after receiving the incoming call request, the UAS generates a response message for the incoming call request. The response message can be returned to the UAC along the path taken by the incoming call request. The UAC determines whether to establish a call, re-initiate a call, or cancel a call based on the content of the response message.

[0117] In a SIP-based communication environment, the messages exchanged between the client and the server include two types of messages. Among them, the message (request) sent from the client to the server is a request message. The message (response) sent from the server to the client is a response message (or response information).

[0118] Request messages include registration request REGISTER, incoming call request INVITE, response request ACK, cancellation request CANCEL, termination request BYE, operation request OPTIONS, etc.

[0119] Among them, REGISTER is used to provide address resolution mapping and register contact information.

[0120] INVITE, ACK, and CANCEL are used to establish a session; INVITE is used to invite a user to join a call; ACK is used to confirm that the client has received the final response to INVITE; BYE is used to terminate a call between two users.

[0121] OPTIOINS is used to request information about server capabilities, such as querying server load.

[0122] A response message refers to one or more responses returned by the server when it receives a request. Each response has a status code that represents the transaction status.

[0123] The response message status code of 1xx indicates a provisional response, the request has been received and is being processed. For example, status code 100 indicates trying; status code 180 indicates ringing; and status code 183 indicates session progress.

[0124] The response message status code of 2xx indicates successful processing, the request has been successfully received and processed correctly. For example, the status code of 200 means OK, the call has been established.

[0125] The status code of the response message is 3xx, which means redirection. Additional operations are required to complete the request. This request needs to be forwarded to other servers for processing.

[0126] The response message status code 4xx indicates a client error, the request contains an incorrect format or cannot be completed on this server, and 4XX can also indicate a connection failure.

[0127] The response message status code 5xx indicates a server error and the server cannot process the request correctly.

[0128] A response message with a status code of 6xx indicates a global error and the request cannot be processed by any server.

[0129] In combination with the process from UAC initiating a call request to UAC establishing a session with UAS, for example, Figure 2 A diagram of the interaction between UAC, UAS and server to establish a session is given, see Figure 2 ,include:

[0130] UAC sends an INVITE (incoming call request) to the server.

[0131] When the server receives the INVITE, it will immediately return a trying 100 response message to the UAC, indicating that it is trying to respond to the INVITE to prevent the UAC from retransmitting the INVITE.

[0132] The server receives the INVITE and forwards the INVITE to the UAS based on the called address (UAS corresponding address) carried in the INVITE.

[0133] The server returns a response message of trying 100 to the UAC, and the server sends an INVITE to the UAS, which can be executed asynchronously or synchronously. When executed asynchronously, the execution order of the two operations is not limited.

[0134] When the UAS receives the INVITE, it can also immediately return a trying 100 response message, indicating that it is trying to respond to the INVITE. If the UAS responds to the INVITE, it can return a 180 ringing response message to the server.

[0135] The server forwards the 180 ringing response message to the UAC.

[0136] After the UAS rings, if the UAS answers the call, the UAS will immediately generate a 200OK response message; the UAS returns a 200OK response message to the server.

[0137] The server sends a 200 OK response message to the UAC.

[0138] When UAC receives the 200OK response message, it generates an ACK response and sends it to UAS through the server.

[0139] At this point, data transmission based on the real-time transport protocol (RTP) and / or the real-time transport control protocol (RTCP) can be performed between the UAC and the UAS, and the UAC and the UAS can establish a call to start a conversation.

[0140] After the conversation ends, any participant (UAC and / or UAS) can send a BYE request to terminate the session. The BYE request can bypass the server (or be forwarded by the server) to the other end.

[0141] For example, the UAS sends a BYE request directly to the UAC to terminate the session.

[0142] After receiving the BYE request, the UAC sends a 200OK response message to confirm the response to the BYE request and ends the current session.

[0143] The scenario applicable to this embodiment is that when an electronic device receives an INVITE (incoming call request), it identifies the risk of the incoming call number carried in the INVITE to reduce the risk of the electronic device answering the risk number. The whole process mainly involves the processing operation of the INVITE, and the following embodiment mainly introduces the INVITE in further detail.

[0144] As a request message, INVITE includes a message body. Each message body includes a header field. The header field represents various characteristic information of the message conveying instructions.

[0145] Among them, the header field of INVITE is used to characterize the characteristic information contained in the incoming call request. Exemplarily, the header field of INVITE includes the call information header field (Call-identity document, Call-ID header field), the source information header field (From header field), the destination information header field (To header field), the communication information header field (Contact header field), the support information header field (Supported header field), the calling information header field (p-preferred-identity, PAI header field), etc.

[0146] The Call-ID header field is used to uniquely identify the call established between two user agents. The Call-ID header field is present in all SIP request messages and response messages.

[0147] The From header field includes relevant information of the initiator (UAC) of the INVITE. The header field may include a tag and a source number (actual call number) for identifying the initiator. The header field may also include a field for characterizing the user type. Exemplarily, the field for characterizing the user type may be noa. Generally, the value of noa in the From header field of the INVITE initiated by the operator user is subscriber. When the value of noa is subscriber, the user type is a cellular communication user.

[0148] The To header field includes relevant information of the final recipient of the INVITE (UAS, an electronic device in this embodiment). The header field may include information such as a tag and a destination number for identifying the final call recipient.

[0149] The Contact header field includes information such as the address of the initiator of the INVITE. The address of the initiator in the Contact header field can be used for routing other requests later. For example, the UAS can bypass the server and directly return a 200OK response message to the UAC address in the Contact header field of the received INVITE.

[0150] Optionally, the Contact header field also includes user equipment (UE) capability information of the initiator of the INVITE. The UE capability information includes UE network capability information and UE wireless access capability information.

[0151] The Supported header field includes relevant information for characterizing the extended methods that the UAC can support. For example, the Supported header field can include resource reservation information, which can indicate whether resource reservation is supported. If the resource reservation information is empty, it can also be considered that the Supported header field does not include a field for supporting resource reservation, which means that the UAC or this session does not support resource reservation.

[0152] The PAI header field includes the caller ID number sent to the UAS (referred to as the caller ID in this embodiment). The caller ID number sent to the UAS is the number displayed when the UAS rings. Generally speaking, the caller ID in the PAI header field should be consistent with the source number (actual call number) in the From header field.

[0153] In addition, the header fields of INVITE can also include the Allow header field used to indicate the methods that can be processed in a dialogue; the Accept header field used to indicate the session message body types supported by the UAC; the Expires header field used to indicate the validity period of the INVITE; the Via header field used to record the SIP route that the INVITE passes through, etc. Different header fields include different information required for the session.

[0154] Figure 3 A schematic diagram of the header field information of INVITE is given. Figure 3 In the From header field of INVITE, the From header field includes fields such as "f:tel:+86158****4621;tag=3506466537". Among them, the source number (actual call number) is "+86158****4621".

[0155] Figure 3 In the INVITE, the To header field includes the field "t:tel:+86153****1355". The destination number is "+86153****1355".

[0156] Figure 3In the INVITE, the Contact header field includes fields such as "Contact URI: ... Contact parameter: +g.3gpp.icsi-ref = ... Contact parameter: audio ... Contact parameter: video ... Contact parameter: +g.3gpp.mid-call ... ". Among them, the parameters starting with the field "Contact parameter" all represent the UE capability information of the UAC that initiates the INVITE, such as "+g.3gpp.icsi-ref = ..." indicates that the UAC has mobile communication capabilities; for example, "audio" and "video" indicate that the UAC has audio and video processing capabilities, and so on.

[0157] Figure 3 In the INVITE, the PAI header field includes "P-Preferred-Identity:<tel:+86158****4621> " and other fields. Among them, the caller ID number is "+86158****4621".

[0158] Figure 3 The information involved in each header field of the INVITE shown includes the incoming number, destination number, source number, UE capability information, and the like, as well as Figure 3 The resource reservation information, user type and other information in each header field of the INVITE not shown can be considered as characteristic information that can characterize the INVITE.

[0159] Since the header field of INVITE provides a variety of characteristic information about UAC, when UAS receives INVITE, it can perform risk identification of the incoming call request corresponding to INVITE based on one or more characteristic information to determine whether the incoming call number is a risky number.

[0160] The present application provides a method for processing an incoming call, which can be applied to an electronic device, the electronic device comprising a mobile communication module, and a reference Figure 4 Given an interactive schematic diagram, the method includes:

[0161] S201. An electronic device receives an incoming call request and obtains feature information of the incoming call request.

[0162] The electronic device in this embodiment is the call receiver (also known as the UAS (called party)). The incoming call request may come from a device that initiates a normal call through the public switched telephone network provided by the operator, or from a virtual IP address that initiates a VoIP call. The electronic device receives the incoming call request sent by the corresponding core network device (server).

[0163] The electronic device receives the incoming call request and can identify the risk of the current incoming call request before responding to the incoming call request. The header field of the incoming call request includes information such as the relevant information of the call initiator. The electronic device can parse the header field information of the incoming call request and obtain the characteristic information in the header field of the incoming call request for risk identification.

[0164] The feature information in this embodiment may include one or more information such as the actual calling number representing the call initiator, the UE capability information of the call initiator, the related information of the extension methods that the call initiator can support, the user type of the call initiator, the incoming call number of the call initiator, etc.

[0165] Among them, the incoming call number of the call initiator in the feature information is the incoming call number that will be displayed on the screen when the electronic device rings. In this embodiment, for some scenarios where a virtual network number is disguised as a designated number to initiate a call request, authenticity risk identification can be performed on the incoming call number to determine whether the incoming call number is disguised or real. Exemplarily, the designated number can be a number of a contact in the address book of the electronic device, a number of a public service, a regular number that is not entered into the risk number database or number blacklist, and so on. For example, public service numbers include bank customer service numbers, operator customer service numbers, express customer service numbers, and so on.

[0166] In general, the incoming call number is a real number, and the address of the call initiator who sends the incoming call request should be consistent with the address of the incoming call number. For example, if the incoming call number is the number of a contact in the address book of an electronic device, then the call initiator should be the device of the contact in the address book. When the call initiator is the device of the contact in the address book, that is, the incoming call request is initiated by the device of the contact in the address book, if the electronic device sends a verification request to the address of the incoming call number (that is, the device of the contact in the address book) to verify whether the incoming call request is initiated, the electronic device should theoretically receive a 200OK response message to indicate that the incoming call request is actually initiated by the address of the incoming call number (that is, the device of the contact in the address book).

[0167] If the incoming call number is a disguised number, the call initiator who sends the call request must be different from the address of the incoming call number, and the address of the call initiator may be a virtual IP address. For example, if the incoming call number is a disguised number of a contact in the address book of an electronic device, then the call initiator must not be the device of the contact in the address book. When the call initiator is not the device of the contact in the address book, that is, the device of the contact in the address book has not sent a call request, if the electronic device sends a verification request to the address of the incoming call number (that is, the device of the contact in the address book) to verify whether the call request is sent, since the device of the contact in the address book has not sent a call request, the device of the contact in the address book will not be able to process the verification request. In this case, the device of the contact in the address book will return a 4xx response message to the electronic device to indicate a connection failure, or client error and other information.

[0168] Therefore, in order to identify whether the incoming call number is a disguised risk number, after receiving the incoming call request, the electronic device can execute step S202 when obtaining the incoming call number in the incoming call request.

[0169] S202: The electronic device sends a verification request to the address of the incoming call number.

[0170] The verification request is used to verify whether the incoming call request comes from the address where the incoming call number is located.

[0171] In this embodiment, the electronic device can directly send a verification request to the address where the incoming call number is located based on the address where the incoming call number is located, and obtain response information to the verification request returned by the address where the incoming call number is located.

[0172] Optionally, the electronic device may also send a verification request carrying the address of the incoming call number to the upstream device, so that the upstream device forwards the verification request to the address of the incoming call number. Exemplarily, the upstream device may be a core network device or server of the network where the electronic device is located. For example, if the electronic device is an NR mobile terminal, then the core network device is an NR network device; if the electronic device is an LTE mobile terminal, then the core network device is an LTE network device.

[0173] The electronic device sends a verification request with the address of the incoming call number to the upstream device, and the upstream device can forward the verification request to the address of the incoming call number according to the address of the incoming call number. The upstream device receives the response information to the verification request returned by the address of the incoming call number, and returns the response information to the electronic device.

[0174] refer to Figure 4 ,Because the electronic device does not know whether the address of the incoming call number is the same as the call initiator's address / device before sending the verification request, Figure 4The dotted line in the figure represents the interactive operation of sending the verification request.

[0175] S203: The electronic device receives response information for the verification request. If the response information indicates that the address of the incoming call number has not initiated a call request, a corresponding risk handling operation is performed.

[0176] Based on the above S201 embodiment, if the incoming call number is a disguised risk number and the incoming call request does not come from the address where the incoming call number is located, then the response information received by the electronic device is a 4xx response information. The response information indicates that the address where the incoming call number is located has not initiated a call request, so the connection fails, or a client error is returned. In this case, the electronic device performs a corresponding risk handling operation. Optionally, if the electronic device does not receive a response message for the verification request, this situation may also indicate that the address where the incoming call number is located has not initiated a call request, and the electronic device needs to perform a corresponding risk handling operation.

[0177] If the incoming call number is not a disguised risk number, but a normal number, then the incoming call request is generally initiated by the address of the incoming call number, and the address of the call initiator who initiates the incoming call request is consistent with the address of the incoming call number. The response information received by the electronic device is a 200OK response information, which indicates that the incoming call request actually comes from the address of the incoming call number, so the response is successful. In this case, the electronic device determines that the incoming call number is not a risk number.

[0178] In this embodiment, the electronic device can obtain the characteristic information carried in the incoming call request, which includes the incoming call number. The electronic device can send a verification request to the address of the incoming call number to identify whether the received incoming call request actually comes from the address of the incoming call number, which can effectively identify the authenticity of the incoming call number. In particular, in the scenario where a virtual network number is used to disguise a designated number to initiate an incoming call request, if the incoming call number is indeed a disguised number A, and the incoming call request does not come from the address of the real number A, then the verification response to the verification request will indicate that the address of number A did not initiate the incoming call request. In this way, the electronic device can determine that the incoming call number is a disguised risk number, which reduces the risk of loss of user information or resources to a certain extent.

[0179] In addition to directly sending a verification request to the address of the incoming call number and identifying the risk of the incoming call request based on the received response information, the electronic device can also perform preliminary risk identification of the incoming call number based on other characteristic information in the header field of INVITE.

[0180] In some embodiments, the difference between some characteristic information in the header field of INVITE in ordinary calls and some characteristic information in the header field of INVITE in VoIP calls includes: the information contained in the Supported header field of INVITE in ordinary calls often indicates support for resource reservation; while the Supported header field of INVITE in VoIP calls does not include the relevant fields for supporting resource reservation. This is because ordinary calls need to occupy a certain bandwidth for communication, so the ability to support resource reservation is required; while VoIP calls do not necessarily need to occupy a certain bandwidth, and generally do not require support for resource reservation.

[0181] For example, Figure 5 A schematic diagram of information comparison of the Supported header field of a normal call and a VoIP call initiated over a public switched telephone network is provided. It can be seen that the fields of the Supported header field of the INVITE of a normal call include the relevant field "precondition..." for supporting resource reservation. For example, the fields of the Supported header field of the INVITE of an incoming call request (belonging to a VoIP call) initiated by application A, application B, application C, etc. do not include the relevant field of "precondition...", or the fields related to supporting resource reservation are considered to be empty.

[0182] In some embodiments, reference Figure 6 In the method for processing incoming calls provided in this embodiment, combined with Figure 4 After the electronic device executes S201, the electronic device sends a verification request to the address where the incoming call number is located, including:

[0183] S2021. If the characteristic information does not include resource reservation information, the electronic device sends a verification request to the address of the incoming call number.

[0184] In this embodiment, before the electronic device sends a verification request to the address where the incoming call number is located, the electronic device can preliminarily determine whether the incoming call number is risky based on whether the feature information includes resource reservation information.

[0185] Combination Figure 5If the Supported header field of INVITE does not include resource reservation information, that is, INVITE indicates that no resources are reserved, then the incoming call request may come from a VoIP call. In a VoIP call, it is easier to disguise a network virtual number as a designated number, making VoIP calls more likely to leak user information or resources. Therefore, when the feature information does not include resource reservation information, it means that the incoming call number has a certain risk. In this case, the electronic device sends a verification request to the address of the incoming call number to further verify whether the incoming call request actually comes from the address of the incoming call number, making the risk identification result of the incoming call request more accurate.

[0186] In some embodiments, the differences between some characteristic information in the header field of INVITE in a normal call and some characteristic information in the header field of INVITE in a VoIP call include: the Contact header field of INVITE in a normal call often includes the UE capability information of the initiator of INVITE; while the Contact header field of INVITE in a VoIP call does not include the UE capability information. This is because, in the scenario of a VoIP call, the initiator of the INVITE request may come from a virtual IP address, not from a physical electronic device, so it does not have the UE capability information.

[0187] For example, Figure 7 A schematic diagram comparing the information in the Contact header field of a normal call and a VoIP call is given. It can be seen that the fields in the Contact header field of the INVITE of a normal call include "audio; video; +g.3gpp.mid-call; +g.3gpp.srvcc-alerting; ..." and other related fields that represent the UE capability information. The fields in the Contact header field of the INVITE of the incoming call request (belonging to a VoIP call) initiated by application A, application B, application C, application D, etc. do not include the relevant fields of the UE capability information.

[0188] In some embodiments, reference Figure 8 In the method for processing incoming calls provided in this embodiment, combined with Figure 4 After the electronic device executes S201, the electronic device sends a verification request to the address where the incoming call number is located, including:

[0189] S2022: If the characteristic information does not include device capability information, the electronic device sends a verification request to the address of the incoming call number.

[0190] In this embodiment, before the electronic device sends a verification request to the address where the incoming call number is located, the electronic device can preliminarily determine whether the incoming call number is risky based on whether the feature information includes device capability information.

[0191] Combination Figure 7 If the Contact header field of INVITE does not include device capability information, or the device capability information of the Contact header field is empty, then the incoming call request may come from a VoIP call. In a VoIP call, it is easier to disguise a network virtual number as a designated number, making VoIP calls more likely to leak user information or resources. Therefore, when the feature information does not include device capability information, it means that the incoming call number has a certain risk. In this case, the electronic device sends a verification request to the address of the incoming call number to further verify whether the incoming call request actually comes from the address of the incoming call number, making the risk identification result of the incoming call request more accurate.

[0192] In some embodiments, the differences between some characteristic information in the header field of INVITE in a normal call and some characteristic information in the header field of INVITE in a VoIP call include: the source number in the From header field of INVITE in a normal call is always consistent with the incoming call number in the PAI header field. However, there is an inconsistency between the source number in the From header field of INVITE in a VoIP call and the incoming call number in the PAI header field. This is because, in the scenario of a VoIP call, the UAC can modify the network virtual number to a designated number to initiate an INVITE to the UAS, so that the source number (network virtual number or IP number) is inconsistent with the incoming call number (modified designated number).

[0193] In some embodiments, reference Fig. 9 The feature information also includes the actual calling number. In the method for processing incoming calls provided in this embodiment, Figure 4 After the electronic device executes S201, the electronic device sends a verification request to the address where the incoming call number is located, including:

[0194] S2023. If the actual calling number in the feature information is inconsistent with the incoming call number in the feature information, the electronic device sends a verification request to the address where the incoming call number is located.

[0195] In this embodiment, before the electronic device sends a verification request to the address where the incoming call number is located, the electronic device can preliminarily determine whether the incoming call number is risky based on the actual call number in the feature information.

[0196] Combination Figure 3The source number in the From header field and the incoming call number in the PAI header field are shown. If the source number (actual call number) in the From header field of INVITE is inconsistent with the incoming call number in the PAI header field, it means that the incoming call requests a VoIP call, and the incoming call number is obtained by modifying and disguising the actual call number. Disguising the actual call number as another number has certain risks. In this case, the electronic device sends a verification request to the address where the incoming call number is located to further verify whether the incoming call request actually comes from the address where the incoming call number is located, so that the risk identification result of the incoming call request is more accurate. The inconsistency between the actual call number and the incoming call number can quickly and effectively identify whether the incoming call number is a disguised number.

[0197] In some embodiments, the differences between some characteristic information in the header field of INVITE in ordinary calls and some characteristic information in the header field of INVITE in VoIP calls include: the value of the field noa representing the user type in the From header field of INVITE in ordinary calls is usually subscriber, indicating a cellular communication user; while the value of the field noa representing the user type in the From header field of INVITE in VoIP calls is usually national or the value of noa is empty.

[0198] For example, Fig.10 A comparison diagram of the noa field in the From header field of a normal call and a VoIP call is given. It can be seen that the noa field in the From header field of a normal call is "subscriber". The noa field in the From header field of an incoming call request initiated by application A, application B, application C, etc. (belonging to a VoIP call) is "national".

[0199] In some embodiments, reference Fig.11 The feature information also includes the user type of the call initiator. In the method for processing incoming calls provided in this implementation, Figure 4 After the electronic device executes S201, the electronic device sends a verification request to the address where the incoming call number is located, including:

[0200] S2024: If the user type in the feature information indicates a non-cellular communication user, the electronic device sends a verification request to the address where the incoming call number is located.

[0201] In this embodiment, before the electronic device sends a verification request to the address where the incoming call number is located, the electronic device can preliminarily determine whether the incoming call number is risky based on the user type in the feature information.

[0202] Combination Figure 3, if the field noa representing the user type in the From header field of INVITE does not indicate the first type of user, that is, the value of noa is not subscriber; the value of noa may be national or empty, it means that the incoming call request is not from an ordinary call, but may be from a VoIP call. It is easier to disguise a network virtual number as a designated number in a VoIP call, making VoIP calls more prone to user information or resource leakage. Therefore, when the user type indicates a non-cellular communication user, the electronic device sends a verification request to the address where the incoming call number is located to further verify whether the incoming call request actually comes from the address where the incoming call number is located, making the risk identification result of the incoming call request more reliable. The inconsistency between the actual call number and the incoming call number can quickly and effectively identify whether the incoming call number is a disguised number.

[0203] Based on the above identification and judgment based on different characteristic information, the electronic device can send a verification request to the address of the incoming call number when it is determined that there is a certain risk, so as to further verify the authenticity of the incoming call number. Multiple identification and verification can improve the reliability of risk identification of incoming call requests. It should be noted that the difference between some characteristic information in the header field of INVITE in ordinary calls and some characteristic information in the header field of INVITE in VoIP calls is not limited to the above cases. This embodiment can also process the incoming call number based on the difference of other characteristic information.

[0204] In some embodiments, in combination Figure 4 After executing S203, the electronic device refers to Fig.12 The method for processing an incoming call provided in this embodiment also includes:

[0205] S2041. The electronic device performs a ringing operation in response to an incoming call request and outputs risk reminder information.

[0206] The risk reminder information is used to remind the user that there are risks in the incoming call request.

[0207] In this embodiment, the electronic device can perform a ringing operation in response to an incoming call request. At this time, the electronic device will display an incoming call interface on the display screen. Fig.13(a), the electronic device performs a ringing operation to display an incoming call interface 1301, wherein the incoming call interface 1301 includes an incoming call number display area 1302, and the incoming call number display area may include an incoming call number and an operator identifier corresponding to the incoming call number. The incoming call interface 1301 may also include a reject control 1303, an answer control 1304, and a touch control 1305 for guiding sliding to reject or answer. The user clicks the touch control 1305, slides to the left to the reject control 1303, rejects the incoming call request, and terminates the call. The user clicks the touch control 1305, slides to the right to the answer control 1304, answers the incoming call request, and makes a call.

[0208] Since the electronic device has determined that the incoming call request has a risk, while performing the ringing operation to display the incoming call interface 1301, the electronic device can also display risk reminder information 1306 in the form of a floating window or a pop-up window in the incoming call interface 1301. Fig.13 (b), the content contained in the risk reminder information 1306 suspended and displayed on the incoming call interface 1301 may include fields such as "There is a risk in the incoming call, please answer it with caution" for reminding the user that the incoming call request has risks.

[0209] Optionally, after performing the ringing operation, the electronic device may immediately return a 180 ringing response message to the call initiator (or via the server). If the user answers the incoming call request, the electronic device may return a 200 OK response message to the call initiator (or via the server) when the call is connected.

[0210] Alternatively, the electronic device may further perform:

[0211] S2042. The electronic device rejects the incoming call request.

[0212] The electronic device determines that there is a risk in the incoming call request. In order to ensure that the user information or resources of the electronic device are not leaked, the electronic device can directly refuse to respond to the incoming call request. The electronic device can send a response message indicating the rejection of the response or the connection failure to the call initiator (or via the server), or the electronic device can directly ignore the incoming call request.

[0213] Alternatively, in the scenario where the incoming call number is a number of a contact in the electronic device's address book, further risk identification can be performed based on the device model used by the user for the contact in the address book. If the feature information includes device capability information, the electronic device can also perform:

[0214] S2043. The electronic device performs a ringing operation in response to the incoming call request and displays a guidance interface.

[0215] The guidance interface includes a first content and a second content, wherein the first content is used to provide the user with the device model corresponding to the incoming call request, and the second content is used to prompt the user to conduct a question-and-answer verification of the device model of the call initiator after the call is connected.

[0216] Optionally, the electronic device performs a ringing operation in response to the incoming call request, and may return a 180ringing response message to the call initiator (or via a server).

[0217] While the electronic device is performing a ringing operation and displaying the incoming call interface 1301, the electronic device can also display the guidance interface 1401 in the form of a floating window or a pop-up window in the incoming call interface 1301. Fig.14 , the guidance interface 1401 displayed on the incoming call interface 1301 includes a first content 1402 and a second content 1403. For example, the first content 1402 includes "the device model corresponding to the current incoming call request is ****"; the second content 1403 may include "the current incoming call request has risks, it is recommended to conduct a question-and-answer verification of the device model of the call initiator after the call is connected."

[0218] The electronic device may determine the corresponding device model based on the preset device information of different device models and the device information of the incoming call request. The device information may include various capability information of the device, such as mobile communication capability, wireless access capability, audio and video capability, etc.

[0219] In this embodiment, the content provided by the guidance interface can serve as a risk reminder for the user, thereby increasing the user's alertness to the current incoming call request.

[0220] It should be noted that Fig.12 The dotted box in the figure represents a processing method that can be executed by the electronic device when it determines that there is a risk in the incoming call request, and the three dotted boxes represent that the three processing methods are parallel optional solutions.

[0221] In some embodiments, the electronic device can also obtain relevant information about the device model of the address book contact input by the user in the address book display interface. In this way, the electronic device may not display the guidance interface, and if the incoming call number is the number of the address book contact, the corresponding device model is obtained while the ringing is executed, so as to obtain the device capability information based on the device model and compare it with the device capability information in the feature information, and perform corresponding processing operations.

[0222] In some embodiments, the electronic device may also perform other risk handling operations. For example, when it is determined that there is a risk in the incoming call request, the actual call number is stored in a risk number database or a number blacklist; or, the actual call number is reported to the risk warning platform. Optionally, the electronic device may also, under the premise that the user turns on the risk management permission, send a reminder message to assist in avoiding risks to the emergency contact entered by the user or other designated numbers that can provide assistance if it is determined that there is a risk in the incoming call request, and further prevent the leakage of user information or resources through the emergency contact of the user of the electronic device. Exemplarily, other designated numbers that can assist may be numbers of contacts in the address book, or numbers of the risk warning platform.

[0223] In some embodiments, the electronic device can also, under the premise that the user has enabled the incoming call risk management permission, if it is determined that the incoming call request is risky, and if it is detected that the user has opened a payment application, banking application, or other application that may cause user information or resource leakage during a call, output risk reminder information on the startup interface of these applications, further prevent the user from performing operations that may cause information or resource leakage, etc.

[0224] In some embodiments, the electronic device can also, under the premise that the user has enabled the call risk control authority, if it is determined that the incoming call request is risky, increase the risk filtering degree of the short message, and directly filter the risky short message as a junk short message, thereby reducing the probability that the user is misled by the risky short message to perform risky operations. Among them, the risky short message can be understood as a short message whose content includes a website or sensitive words. For example, sensitive words can include ordering, refund, payment, etc., and sensitive words can be pre-set.

[0225] In this embodiment, when the electronic device determines that there is a risk in the incoming call request, it handles the risk in different ways. For example, if there is a certain risk in the incoming call request, but the risk is not very high, the electronic device can respond to the incoming call request and output risk reminder information to provide the user with the possible risk of the incoming call request; if the risk is very high, the electronic device can directly reject it, thereby reducing the leakage of information or resources caused by the user answering the risky call from the source. Alternatively, the electronic device can also respond to the incoming call request, output a guidance interface, and further verify the risk of the incoming call request through the information input by the user. A variety of different processing methods can effectively reduce the risk of information or resource leakage caused by the user when connecting to the risky number, and play a role in risk management and control to varying degrees.

[0226] In some embodiments, the electronic device can also quantify the risk of incoming call requests and perform corresponding risk handling operations for incoming call requests of different risk levels, thereby optimizing more accurate risk reminders or risk management for the user side and optimizing the user's experience of risk management of incoming call numbers.

[0227] In some embodiments, if the feature information includes at least one of resource reservation information, device capability information, actual call number, and user type of the call initiator, combined with Figure 4 After the electronic device executes S201, the method for processing an incoming call provided in this embodiment can refer to Fig.15 ,include:

[0228] S205: The electronic device calculates a risk quantification value of the incoming call request using the feature information.

[0229] In this embodiment, the electronic device can calculate the probability that the incoming call request belongs to an ordinary call or a VoIP call based on the difference between the ordinary call and the VoIP call represented by the feature information. The risk of VoIP calls is relatively high, so the probability that the incoming call request belongs to an ordinary call or a VoIP call calculated based on the feature information can also be understood as calculating the risk of the incoming call request, and the calculated value is the risk quantification value of the incoming call request.

[0230] When receiving an incoming call request, the electronic device may initialize the risk quantification value corresponding to the incoming call request. The initial value of the risk quantification value may be 0, indicating that the incoming call request is not risky. The larger the risk quantification value, the greater the probability that the incoming call request is a VoIP call, and the greater the risk of the incoming call request.

[0231] Combined with the above Figure 3-Figure 11 In the embodiment, if each item in the feature information indicates that the incoming call request is a VoIP call, the risk quantification value of the incoming call request is increased and updated.

[0232] For example, if the resource reservation information in the feature information indicates that no resources are reserved, the risk quantification value is increased and updated. If the device capability information in the feature information is empty, the risk quantification value is increased and updated. If the actual call number in the feature information is inconsistent with the incoming call number, the risk quantification value is increased and updated. If the user type in the feature information indicates a non-cellular communication user, the field of the user type noa is not subscriber, the field of noa is national or the field is empty, the risk quantification value is increased and updated.

[0233] The increasing step length of the risk quantification value may be a natural number greater than 0, for example, 1, 2, 3, etc. The increasing step length of the risk quantification value of each feature information may be the same or different. The increasing step length of the risk quantification value corresponding to each feature information may be preset according to the degree to which different feature information can indicate that the incoming call request is a normal call or a VoIP call.

[0234] Exemplarily, when the increase step size is the same, the increase step size of the risk quantification value of each of the above-mentioned feature information can be 2.

[0235] Alternatively, illustratively, when the increase step is different, for example, the resource reservation information indicates that no resources are reserved, the increase step of the risk quantification value is 2. The device capability information in the feature information is empty, and the increase step of the risk quantification value is 2. The actual call number in the feature information is inconsistent with the incoming call number, and the increase step of the risk quantification value is 5. The user type in the feature information does not indicate a first type of user, and the increase step of the risk quantification value is 1. This embodiment does not limit the value of the increase step of the risk quantification value of each feature information in actual application.

[0236] Optionally, in some embodiments, the response information of the verification request received by the electronic device also indicates the risk of the incoming call request, and the electronic device may also update the risk quantification value based on the response information of the verification request. The method further includes:

[0237] If the response information indicates that the address of the incoming call number has not initiated a call request, the risk quantification value is increased and updated.

[0238] In this embodiment, if the response information indicates that the address where the incoming call number is located has not initiated a call request, that is, the call initiator who initiated the call request is not the address where the incoming call number is located, and the incoming call number is a disguised number, the electronic device increases and updates the risk quantification value. Among them, the increase step of the risk quantification value can be the same as the increase step of the risk quantification value of each of the above-mentioned feature information, for example, the increase step of the risk quantification value is also 2. Or, it can be different, for example, the response information can directly indicate the consistency between the call initiator who initiated the call request and the address where the incoming call number is located, so the value of the increase step can be slightly larger, for example, the response information indicates that the increase step of the risk quantification value where the incoming call number is located has not initiated a call request can be 10. This embodiment does not limit the value of the actual increase step of the risk quantification value.

[0239] Optionally, in some embodiments, when the feature information includes device capability information, the electronic device may further determine the risk of the incoming call request based on consistency identification between the device capability information and the device capability information in the feature information. The method further includes:

[0240] If the feature information includes device capability information, the electronic device obtains a comparison result between the device capability information in the feature information and the device capability information corresponding to the incoming call number; if the comparison result indicates that the device capability information in the feature information and the device capability information corresponding to the incoming call number are inconsistent, the risk quantification value is increased and updated.

[0241] In this embodiment, statistical analysis can be performed on different device capability information, IMS capability information, etc. displayed by electronic devices of different brands and models when used in different operators, and the device capability information corresponding to each device model of the electronic device obtained by the analysis can be obtained. The device capability information of electronic devices of different device models can be stored in the local storage space of the electronic device, or can also be stored in a cloud database or analysis server that has a communication connection with the electronic device. Among them, the device capability information of electronic devices of each device model can be stored in the correspondence between device signals and device capability information.

[0242] Optionally, in some embodiments, for each received device capability information of the feature information of the incoming call request, the electronic device may also update and store the device capability information each time in a local storage space or a cloud database or an analysis server as historical device capability information. Optionally, the electronic device may store the device capability information corresponding to the incoming call number based on the correspondence between the incoming call number and the device capability information.

[0243] When an incoming call request is received for the current time, the feature information includes device capability information or the device capability information is not empty, and the electronic device can compare the device capability information in the feature information with the device capability information in the local storage space or the cloud database or the analysis server for consistency.

[0244] In one case, if the incoming call number is not the number that makes a call request to the electronic device for the first time, then the electronic device can obtain the corresponding device capability information from the local storage space or the cloud database or the analysis server based on the incoming call number. In another case, if the incoming call number is the number that makes a call request to the electronic device for the first time, then the device capability information corresponding to the incoming call number does not exist in the local storage space or the cloud database or the analysis server. In this case, the electronic device can determine the device model corresponding to the incoming call number based on the device capability information in the feature information, and query the device capability information corresponding to the device model from the local storage space or the cloud database or the analysis server. If the device capability information corresponding to the device model is inconsistent with the device capability information in the feature information, it means that there is an abnormality in the device capability information of the feature information of the incoming call request, and the incoming call request has a certain risk, and the risk quantification value is increased and updated. Among them, the increase step of the risk quantification value can be the same as the increase step of the risk quantification value of each of the above-mentioned feature information, for example, the increase step of the risk quantification value is also 2. Or, it can also be different, for example, when the device capability information corresponding to the device model is inconsistent with the device capability information in the feature information, the increase step of the risk quantification value can be 5. This embodiment does not limit the value of the actual increase step of the risk quantification value.

[0245] In some embodiments, the electronic device may also perform risk identification of the incoming call request based on other feature information or other risk identification conditions, and increase or update the risk quantification value of the incoming call request accordingly.

[0246] S206: The electronic device performs corresponding risk handling operations based on the risk quantification value.

[0247] In this embodiment, the electronic device obtains the risk quantification value of the incoming call request, and performs corresponding processing on the incoming call number according to different degrees of risk. The higher the risk level, the more direct the processing method for the incoming call request.

[0248] In combination with the above S2041-S2043 embodiments, in this embodiment, the risk quantification value can be differentiated into different risk levels based on the value of the risk quantification value. For example, the risk quantification value belongs to the first risk value range, corresponding to the first level, and the first level is the highest level. If the risk quantification value represents the first level, the risk level of the incoming call request is very high, and if the user answers the call, it is easy to cause user information or resource leakage. In this case, the electronic device rejects the incoming call request. The electronic device rejects the incoming call request. For the user, the electronic device does not ring or remind, and the user is unaware of this operation, and fundamentally avoids the risk of user information or resource leakage caused by the user answering the call, that is, the electronic device executes S2043. The risk quantification value belongs to the second risk value range, corresponding to the second level, the second level is lower than the first level, and the incoming call request is risky, but the risk level is not very high. In this case, the electronic device can respond to the incoming call request, perform a ringing operation, and display a risk reminder interface, that is, execute S2041. The risk quantification value belongs to the third risk value range. For the third level, the third level is lower than the second level. The incoming call request has risks, but the risk level is not very high, and its risk can be further verified. The electronic device can respond to the incoming call request, perform a ringing operation, display a guidance interface, etc., that is, execute S2042.

[0249] In some embodiments, corresponding operations can also be performed according to the size relationship between the risk quantification value and the preset threshold. The size relationship between the risk quantification value and the preset threshold refines the granularity of the risk quantification value to represent the risk degree and optimizes the risk handling method corresponding to the incoming call request.

[0250] Exemplarily, in one embodiment, if the risk quantification value is greater than a preset first threshold, the electronic device responds to the incoming call request, performs a ringing operation, and outputs risk reminder information; the risk reminder information is used to remind the user that there is a risk in the incoming call request.

[0251] In this embodiment, if the risk quantification value is greater than the preset first threshold value, it means that there is a risk in the incoming call request, but the risk level is not very high. In this case, the electronic device performs a ringing operation in response to the incoming call request and outputs a risk reminder message. The risk reminder message is used to remind the user that there is a risk in the incoming call request (refer to S2041). Exemplarily, the first threshold value can be determined based on the increase step size of the risk quantification value. For example, the increase step size of each item that can increase the risk quantification value is 10. There are a total of 10 sub-items that can increase the risk quantification value, so the first threshold value can be 60.

[0252] Exemplarily, in another embodiment, if the risk quantification value is less than or equal to a first threshold value and greater than a preset second threshold value, the electronic device responds to the incoming call request, performs a ringing operation, and displays a guidance interface.

[0253] The guidance interface includes guidance information and controls, the guidance information is used to prompt the user to enter the device model of the incoming call number in the control; and the second threshold is less than the first threshold.

[0254] In this embodiment, the electronic device can receive the user's input operation on the control, obtain the device model of the incoming call number, and then based on the device capability information of the device model, if the device capability information of the device model is inconsistent with the device capability information in the feature information, the electronic device rejects the incoming call request.

[0255] If the risk quantification value is less than or equal to the first threshold and greater than the second threshold, it means that the incoming call request has a risk, but the risk level is not very high, and its risk can be further verified. In this case, S2042 is executed. Here, for example, if the first threshold is 60, then the third threshold can be 40.

[0256] Illustratively, in another embodiment, if the risk quantification value is greater than a preset third threshold, the electronic device rejects the incoming call request; the third threshold is greater than the first threshold.

[0257] The risk quantification value is greater than the preset third threshold value, which means that the risk level of the incoming call request is very high. If the user answers the call, it is easy to cause user information or resource leakage. In this case, the electronic device rejects the incoming call request. The electronic device rejects the incoming call request. For the user, the electronic device does not ring or remind, and the user is unaware of this operation, which fundamentally avoids the risk of user information or resource leakage caused by the user answering the call, that is, the electronic device executes S2043.

[0258] Here, illustratively, if the first threshold is 60, then the third threshold may be 80.

[0259] In some embodiments, if the risk quantification value is less than the second threshold, the risk of the incoming call request is considered to be low, and the electronic device can directly respond to the incoming call request and perform a ringing operation.

[0260] In this embodiment, when the electronic device determines that there is a risk in an incoming call request, it can obtain a risk quantification value for the incoming call request, and handle the risk in different ways based on the risk level represented by the risk quantification value. A variety of different processing methods correspond to different risk levels. While effectively reducing the information or resource leakage that may be caused by risky incoming call requests, it can play a risk management role to varying degrees, thereby optimizing the user's experience in risk identification and risk avoidance.

[0261] In some embodiments, the user can enable the risk control processing function of incoming call requests of the electronic device based on the system setting interface of the electronic device. Under the premise of enabling the incoming call risk control authority, the electronic device executes steps S201-S206 of the above embodiment.

[0262] Combination Figure 3-Figure 15 This embodiment provides a method for processing an incoming call, referring to Fig.16 ,include:

[0263] S301: An electronic device receives an incoming call request and obtains feature information of the incoming call request.

[0264] S302: The electronic device searches for device capability information corresponding to the incoming call number from preset device capability information of different device models in communication environments of different operators.

[0265] S303: Initialize the risk quantification value to 0.

[0266] S304, the electronic device determines whether the characteristic information includes resource reservation information; if not, the risk quantification value is increased and updated. After the risk quantification value is increased and updated or when the resource reservation information is included, S305 is executed.

[0267] S305. The electronic device determines whether the characteristic information includes device capability information; if not, the risk quantification value is increased and updated.

[0268] After the risk quantification value is added and updated or when the device capability information is included, S306 is executed.

[0269] S306. The electronic device determines whether the actual calling number is consistent with the incoming call number; if so, the risk quantification value is increased and updated.

[0270] After the risk quantification value is added and updated or when the actual calling number is consistent with the incoming call number, S307 is executed.

[0271] S307. The electronic device determines that noa is not a subscriber; if so, the risk quantification value is increased and updated.

[0272] After the risk quantification value is added and updated or when noa is a subscriber, S308 is executed.

[0273] S308. The electronic device determines whether the device capability information in the feature information is consistent with the device capability information corresponding to the incoming call number; if so, the risk quantification value is increased and updated.

[0274] After the risk quantification value is added and updated or when the device capability information in the feature information is consistent with the device capability information corresponding to the incoming call number, S309 is executed.

[0275] S309. The electronic device determines whether the risk quantification value is greater than a second threshold value; if so, execute S310; if not, execute S318.

[0276] S310. The electronic device sends a verification request to the address of the incoming call number.

[0277] S311. The response information received by the electronic device is a 200 OK response information, and S318 is executed.

[0278] Optionally, if the risk quantification value is greater than the fourth threshold, even when receiving a 200OK response message, the electronic device may further verify the risk of the incoming call request, that is, may execute S313.

[0279] The fourth threshold is greater than the second threshold. This can avoid receiving a 200OK response message, but the risk quantification value is relatively high, resulting in a problem of missing risk calls.

[0280] S312: The response information received by the electronic device is a 4xx response information, and the risk quantification value is increased and updated. After the risk quantification value is increased and updated, S313 is executed.

[0281] S313. The electronic device determines whether the risk quantification value is greater than a third threshold value; if so, execute S314; if not, execute S315.

[0282] S314: The electronic device rejects the incoming call request.

[0283] S315. The electronic device determines whether the risk quantification value is greater than a first threshold value; if so, execute S316; if not, execute S317.

[0284] S316: The electronic device performs a ringing operation in response to the incoming call request and outputs risk reminder information.

[0285] S317: The electronic device performs a ringing operation in response to the incoming call request and displays a guidance interface.

[0286] S318: The electronic device responds to the incoming call request and performs a ringing operation.

[0287] In the above steps S316-S318, the electronic device performs a ringing operation and returns a 180ringing response message to the call initiator.

[0288] In some embodiments, if the electronic device executes S304-S308, that is, after performing a risk analysis of the incoming call request based on the feature information, the risk quantification value obtained is greater than the third threshold, then the electronic device can directly execute S314, reject the incoming call request, and do not execute steps S309-S312; or, if the obtained risk quantification value is greater than the first threshold, the electronic device can directly execute S316, respond to the incoming call request, perform a ringing operation, and output risk reminder information, without executing steps S309-314.

[0289] The electronic device first determines the threshold value based on the risk quantification value, and executes S314 or S316 accordingly, thereby reducing the message interaction with the address of the incoming call number, reducing the data transmission cost of the electronic device, and improving the efficiency of risk identification of the electronic device.

[0290] In this embodiment, the electronic device can obtain the characteristic information carried in the incoming call request, obtain the risk quantification value of the incoming call request based on the multiple characteristic information, determine the risk level according to the relationship between the risk quantification value and the preset first threshold, second threshold and third threshold, and perform corresponding risk processing. The various processing methods effectively reduce the risk of information or resource leakage caused by the user when the risk number is connected, and refine the granularity of risk management and control processing for different risk levels, thereby optimizing the user's experience of risk identification and risk reminders.

[0291] Fig.16 Just give a combination Figure 4 , Figure 6 , Figure 8 , Fig. 9 , Fig.11 , Fig.12 as well as Fig.15 An execution logic diagram of the embodiment provided is provided. In practical applications, for the above combination Figure 4 , Figure 6 , Figure 8 , Fig. 9 , Fig.11 , Fig.12 as well as Fig.15 The execution logic of the provided embodiments is not limited.

[0292] The method for processing an incoming call provided in this embodiment can be applied to an electronic device including a first communication module. The electronic device 100 in the embodiment of the present application can be a mobile terminal such as a portable computer (such as a mobile phone), a tablet computer, a notebook computer, etc., and the following embodiments do not impose any special restrictions on the specific form of the electronic device.

[0293] Please refer to Fig.17, which shows a structural block diagram of an electronic device (such as an electronic device 100) provided in an embodiment of the present application. Among them, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a radio frequency module 150, a communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0294] The structure shown in the embodiment of the present invention does not limit the electronic device 100. It may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0295] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0296] The controller can be a decision maker that directs the various components of the electronic device 100 to work in coordination according to the instructions. It is the nerve center and command center of the electronic device 100. The controller generates an operation control signal according to the instruction operation code and timing signal to complete the control of fetching and executing instructions.

[0297] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory, which can store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it can be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0298] In some embodiments, the processor 110 may include an interface. The interface may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a SIM interface, and / or a USB interface, etc.

[0299] The interface connection relationship between the modules shown in the embodiment of the present invention is only for illustrative purposes and does not constitute a structural limitation on the electronic device 100. The electronic device 100 may adopt different interface connection methods in the embodiment of the present invention, or a combination of multiple interface connection methods.

[0300] The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. While the charging management module 140 is charging the battery 142, it may also power the electronic device 100 through the power management module 141.

[0301] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and supplies power to the processor 110, the internal memory 121, the external memory interface 120, the display screen 194, the camera 193, and the communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some embodiments, the power management module 141 can also be set in the processor 110. In some embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

[0302] The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the radio frequency module 150, the communication module 160, the modem and the baseband processor.

[0303] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of antennas. For example, a cellular network antenna can be reused as a wireless local area network diversity antenna. In some embodiments, the antenna can be used in combination with a tuning switch.

[0304] The RF module 150 can provide a communication processing module for wireless communication solutions including 2G / 3G / 4G / 5G, etc., applied to the electronic device 100. The RF module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The RF module 150 receives electromagnetic waves from the antenna 1, and performs filtering, amplification, and other processing on the received electromagnetic waves, and transmits them to the modem for demodulation. The RF module 150 can also amplify the signal modulated by the modem, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the RF module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the RF module 150 can be set in the same device as at least some of the modules of the processor 110.

[0305] The modem may include a modulator and a demodulator. The modulator is used to modulate the low-frequency baseband signal to be sent into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After the low-frequency baseband signal is processed by the baseband processor, it is passed to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker 170A, a receiver 170B, etc.), or displays an image or video through a display screen 194. In some embodiments, the modem may be an independent device. In some embodiments, the modem may be independent of the processor 110 and be arranged in the same device as the RF module 150 or other functional modules.

[0306] The communication module 160 can provide a communication processing module for wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 100. The communication module 160 can be one or more devices integrating at least one communication processing module. The communication module 160 receives electromagnetic waves via the antenna 2, modulates the frequency of the electromagnetic wave signal and filters it, and sends the processed signal to the processor 110. The communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency of it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2. In this embodiment, the first communication module can be the communication module 160.

[0307] In some embodiments, the antenna 1 of the electronic device 100 is coupled to the RF module 150, and the antenna 2 is coupled to the communication module 160, so that the electronic device 100 can communicate with the network and other devices through wireless communication technology. The wireless communication technology may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), LTE, BT, GNSS, WLAN, NFC, FM, and / or IR technology. The GNSS may include a global satellite positioning system (satellite based augmentation systems, SBAS), a global navigation satellite system (global navigation satellite system, GLONASS), a BeiDou navigation satellite system (BeiDou navigation satellite system, BDS), a Quasi-Zenith satellite system (Quasi-Zenith satellite system, QZSS) and / or a satellite based augmentation system (satellite based augmentation systems, SBAS).

[0308] The electronic device 100 implements the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

[0309] The display screen 194 is used to display images, videos, etc. For example, the display screen 194 can display an incoming call reminder interface and a voice call interface. In an embodiment of the present application, if the electronic device 100 receives an in-application call request initiated by the opposite end in the first application, the display screen 194 of the electronic device 100 can display a voice call interface including the business information of the first application. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.

[0310] In this embodiment, if the risk quantification value is greater than a preset first threshold, the electronic device may display risk reminder information on the display screen. Optionally, the electronic device displays it in a floating interface or pop-up window. Fig.13 shown.

[0311] If the risk quantification value is less than or equal to the first threshold value and greater than the second threshold value, the electronic device may display a guidance interface on the display screen, referring to Fig.14 The guide interface includes guide information and controls, and the controls can be used to allow the user to enter the device model of the incoming call number.

[0312] Optionally, the guidance interface may further include a confirmation control for submitting the device model of the incoming call number input by the user. After the electronic device receives the user's confirmation operation, the electronic device does not display the guidance interface. If the electronic device determines that the device model of the incoming call number is consistent with the device capability information of the device model, the electronic device may perform a ringing operation while hiding the guidance interface, and display the incoming call ringing interface on the display screen. If the device model of the incoming call number is inconsistent with the device capability information of the device model, the electronic device may not perform the ringing operation. The interface displayed on the display screen is the default interface before the incoming call ringing interface is displayed.

[0313] The electronic device 100 can realize the shooting function through ISP, camera 193, video codec, GPU, display screen and application processor.

[0314] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0315] The internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. The memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, a phone book, etc.), etc. In addition, the memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, other volatile solid-state storage devices, a universal flash storage (UFS), etc.

[0316] The electronic device 100 can implement audio functions such as music playing and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0317] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be arranged in the processor 110, or some functional modules of the audio module 170 can be arranged in the processor 110.

[0318] The speaker 170A, also called a "speaker", is used to convert an audio electrical signal into a sound signal. The electronic device 100 can listen to music or listen to a hands-free call through the speaker 170A.

[0319] The receiver 170B, also called a "earpiece", is used to convert audio electrical signals into sound signals. When the electronic device 100 receives a call or voice message, the voice can be received by placing the receiver 170B close to the human ear.

[0320] Microphone 170C, also called "microphone" or "microphone", is used to convert sound signals into audio electrical signals. When making a call or sending a voice message, the user can speak by putting his mouth close to microphone 170C to input the sound signal into microphone 170C. The electronic device 100 can be provided with at least one microphone 170C. In some embodiments, the electronic device 100 can be provided with two microphones 170C, which can not only collect sound signals but also realize noise reduction function. In some embodiments, the electronic device 100 can also be provided with three, four or more microphones 170C to realize the collection of sound signals, noise reduction, identification of sound sources, realization of directional recording function, etc.

[0321] The earphone interface 170D is used to connect a wired earphone and can be a USB interface 130, or a 3.5 mm open mobile terminal platform (OMTP) standard interface or a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0322] The SIM card interface 195 is used to connect the SIM. The SIM card can be connected to and separated from the electronic device 100 by inserting it into the SIM card interface 195 or pulling it out from the SIM card interface 195. The electronic device 100 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, and the like. Multiple cards can be inserted into the same SIM card interface 195 at the same time. The types of the multiple cards can be the same or different. The SIM card interface 195 can also be compatible with different types of SIM cards. The SIM card interface 195 can also be compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to implement functions such as calls and data communications. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0323] The software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. Taking the system as an example, the software structure of the electronic device 100 is exemplified.

[0324] Fig.181 is a software structure diagram of the electronic device 100 of an embodiment of the present invention. The electronic device includes an application layer, an application framework layer, an Android runtime and a system library, and a kernel layer. The layered architecture divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces.

[0325] The application layer can include a series of application packages. Fig.18 As shown, the application package may include applications such as phone, WLAN, and short message.

[0326] The application framework layer provides application programming interface (API) and programming framework for the applications in the application layer. The application framework layer includes some predefined functions. Fig.18 As shown, the application framework layer may include a processing module, a window manager, a content provider, a view system, a phone manager, a resource manager, and a notification manager.

[0327] In this embodiment, the processing module can execute the above Figure 3-Figure 16 The method for processing incoming calls provided in the embodiments. For example, receiving an incoming call request, obtaining characteristic information of the incoming call request; calculating the risk quantification value of the incoming call request based on the characteristic information; and issuing corresponding instructions to the corresponding module to perform corresponding operations based on the different risk quantification values. For example, when it is necessary to display a risk reminder interface or a guide interface, the processing module may send a control instruction to the view system to enable the view system to perform the operation of displaying the risk reminder interface or the guide interface.

[0328] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0329] Content providers are used to store and retrieve data and make it accessible to applications. The data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0330] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0331] In this embodiment, the view system can provide, for example, Fig.13 The risk reminder interface shown, Fig.14The guidance interface shown, the incoming call interface when ringing, and the display interface of other electronic devices.

[0332] The phone manager is used to provide communication functions of the electronic device 300. For example, the management of call status (including connecting, hanging up, etc.).

[0333] In this embodiment, if the processor performs a ringing operation in response to an incoming call request, and the user performs an answering operation based on the incoming call interface, the phone manager connects the call corresponding to the incoming call request in response to the user's answering operation.

[0334] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0335] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

[0336] Android runtime includes core library and virtual machine. Android runtime is responsible for scheduling and management of Android system. Core library consists of two parts: one is the function that Java language needs to call, and the other is Android core library.

[0337] The application layer and the application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0338] The system library may include multiple functional modules, such as surface manager, media libraries, 3D graphics processing library (such as openGL ES), 2D graphics engine (such as SGL), etc.

[0339] The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications. The media library supports playback and recording of multiple common audio and video formats, as well as static image files. The media library can support multiple audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc. The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, synthesis, and layer processing. The 2D graphics engine is a drawing engine for 2D drawing.

[0340] The kernel layer is the layer between hardware and software. The kernel layer contains at least display driver, camera driver, audio driver, and sensor driver.

[0341] The execution subject of risk identification and risk handling of incoming call requests may not be limited to electronic devices. For example, risk identification and risk handling of incoming call requests may also be performed by an upstream device of the electronic device. For example, the upstream device may be a core network device (server) in the same domain or in a different domain of the electronic device.

[0342] In some embodiments, the method for processing incoming calls provided in this embodiment can also be applied to a server, referring to Fig.19 ,include:

[0343] S401. The server receives a call request and obtains characteristic information of the call request.

[0344] In this embodiment, the server receives the call request of the call initiator forwarded by the core network device of other networks through the switching network; the server may also receive the call request of the call initiator through the IMS network.

[0345] The server receives the call request and can identify the risk of the current call request before sending the call request to the corresponding electronic device. The header field of the call request includes information such as the relevant information of the call initiator. The server can parse the header field information of the call request and obtain the characteristic information in the header field of the call request for risk identification.

[0346] The characteristic information in this embodiment may include one or more information such as the actual call number representing the call initiator, the UE capability information of the call initiator, the related information of the extension method that the call initiator can support, the user type of the call initiator, the incoming call number of the call initiator, the address of the call initiator, and the destination number, etc. Among them, the destination number corresponds to the electronic device.

[0347] For some scenarios where a virtual network number is disguised as a designated number to initiate a call request, the server can identify the authenticity risk of the incoming call number to determine whether the incoming call number is disguised or real. Similar to the electronic device in S201, the server can send a verification request to the address of the incoming call number to verify whether the call request is initiated to determine whether the call request is initiated by the address of the incoming call number (that is, the device of the contact in the address book).

[0348] S402: The server sends a verification request to the address where the incoming call number is located to verify whether the call request comes from the address where the incoming call number is located.

[0349] In this embodiment, the server may directly send a verification request to the address where the incoming call number is located based on the address where the incoming call number is located, and obtain response information to the verification request returned by the address where the incoming call number is located.

[0350] Optionally, the server may also send a verification request carrying the address of the incoming call number to the switching network or IMS network, so that the switching network or IMS network forwards the verification request to the address of the incoming call number. The switching network or IMS network receives the response information to the verification request returned by the address of the incoming call number, and returns the response information to the server.

[0351] S403: The server receives response information for the verification request. If the response information indicates that the address of the incoming call number has not initiated a call request, the server sends a call request and risk reminder information to the electronic device, or the server rejects the call request.

[0352] Among them, the risk reminder information is used to remind users of electronic devices that the incoming call number is a risky number.

[0353] If the incoming call number is a disguised risk number and the call request does not come from the address of the incoming call number, the response information received by the server is a 4xx response information. The response information indicates that the address of the incoming call number did not initiate a call request, so the connection failed, or a client error was returned. In this case, the server sends a call request and risk reminder information to the electronic device or the server rejects the call request.

[0354] Optionally, if the electronic device does not receive response information to the verification request, this may also indicate that the address of the incoming call number has not initiated a call request, and the electronic device needs to perform corresponding risk handling operations.

[0355] If the incoming call number is a risk number, the server can send a risk reminder message while sending a call request to the electronic device to remind the user of the electronic device that the incoming call number is a risk number. Alternatively, the server directly rejects the call request. That is, the server does not send the call request to the electronic device.

[0356] If the incoming call number is not a disguised risk number, the incoming call number is a normal number, the call request is initiated from the address of the incoming call number, and the address of the call initiator who initiates the call request is consistent with the address of the incoming call number. Then the response information received by the server is a 200OK response information. The response information indicates that the call request actually comes from the address of the incoming call number, so the response is successful. In this case, the server normally sends the call request to the electronic device.

[0357] In this embodiment, the server can obtain the characteristic information carried in the call request, which includes the incoming call number. The server can send a verification request to the address of the incoming call number to identify whether the received call request actually comes from the address of the incoming call number, and can effectively identify the authenticity of the incoming call number. In particular, in the scenario where a call request is initiated by disguising a virtual network number as a designated number, if the incoming call number is indeed a disguised number A, and the call request does not come from the address of the real number A, then the verification response of the verification request will indicate that the address of number A did not initiate the call request, so that the server can determine that the incoming call number is a disguised risk number. When the server determines that the incoming call number is a risk number, it can send a call request to the electronic device and send a risk reminder message for reminding the user of the electronic device that the call request is risky; or, when the server determines that the call request is risky, the server can directly reject the call request to intercept the call request of the risk number, greatly reducing the probability of the electronic device answering the risk number, and to a certain extent reducing the risk of user information or resources of the electronic device being lost.

[0358] Optionally, since the characteristic information of the call request received by the server also includes the IP address of the call initiator, the server can directly trace back based on the IP address to determine whether the IP address is a risky address, thereby identifying the risk of the call request. Alternatively, the server can also identify the risk of the call request based on other information in the characteristic information, which is not limited in this embodiment.

[0359] In some embodiments, the feature information may also include resource reservation information, device capability information, the actual call number, and the user type of the call initiator. The server may determine whether the incoming call number is a risky number based on the feature information and the received response information. The method for the server to identify the risk of the incoming call number based on the feature information of the call request and the received response information can be found in the electronic device side. Figure 5-Figure 11 The method provided in the embodiment will not be described in detail here.

[0360] Furthermore, in some embodiments, the server may also quantify the risk of the call request and obtain a risk quantification value of the call request. Fig.15 The method provided in the embodiment obtains the risk quantification value of the call request, which will not be described in detail here.

[0361] After the server obtains the risk quantification value of the incoming call request, it can perform risk management and control operations of different granularities based on different risk quantification values.

[0362] For example, different degrees of risk management operations include rejecting call requests; sending call requests and risk reminder information to electronic devices; sending call requests to electronic devices normally, etc.

[0363] Exemplarily, different risk levels can be differentiated for the risk quantification value based on the numerical value of the risk quantification value. For example, the risk quantification value belongs to the first risk value range, corresponding to the first level, and the first level is the highest level. If the risk quantification value represents the first level, the server can directly reject the call request. That is, the server does not send the call request to the electronic device, and the electronic device will not receive the call request, which greatly reduces the risk of leakage of user information or resources of the electronic device. If the risk quantification value belongs to the second risk value range, corresponding to the second level, the second level is lower than the first level, the server can forward the call request to the electronic device, and at the same time, send risk reminder information to the electronic device. If the risk quantification value belongs to the third risk value range, for the third level, the third level is lower than the second level, the server will normally forward the call request to the electronic device.

[0364] In some embodiments, corresponding risk processing can also be performed according to the size relationship between the risk quantification value and the preset threshold. The size relationship between the risk quantification value and the preset threshold refines the granularity of the risk quantification value representing the risk degree and optimizes the execution strategy of the risk processing corresponding to the call request.

[0365] If the risk quantification value is greater than a preset first threshold, the server may send risk reminder information while sending a call request to the electronic device.

[0366] If the risk quantification value is greater than the preset first threshold, it means that the incoming call number is risky, but the risk level is not very high. In this case, the server can send a call request to the electronic device and send a risk reminder message to the electronic device; the risk reminder message is used to remind the user that the incoming call number is a risky number. Exemplarily, the first threshold preset here is the same as the first threshold preset in S206.

[0367] If the risk quantification value is greater than a preset second threshold, the server directly rejects the call request.

[0368] If the risk quantification value is greater than the preset second threshold, it means that the risk level of the call request is very high, and if the user answers the call, it is easy to cause user information or resource leakage. In this case, the server rejects the call request or ignores the call request, and does not send the call request to the electronic device. For the electronic device, it is equivalent to not having this call request, and it also fundamentally avoids the risk of causing electronic device user information or resource leakage. The second threshold preset here can be the same as the third threshold preset in S206.

[0369] In this embodiment, the first threshold is smaller than the second threshold. The values ​​of the first threshold and the second threshold may also be determined according to actual conditions, which is not limited in this embodiment.

[0370] In this embodiment, when the server determines that the incoming call number is a risky number, it can obtain the risk quantification value of the call request, and perform risk processing in different ways based on the risk level represented by the risk quantification value. A variety of different processing methods correspond to different risk levels. While effectively reducing the user information or resource leakage that may be caused by risky call requests, it can play a risk management role to varying degrees, optimize the processing granularity of risk identification and risk avoidance, and make the risk identification of call requests more reliable.

[0371] Combination Fig.19 As well as the above embodiments, this embodiment provides a method for processing an incoming call, referring to Fig. 20 ,include:

[0372] S501, the server receives a call request and obtains characteristic information of the call request;

[0373] S502: The server obtains preset device capability information of different device models in communication environments of different operators.

[0374] S503: The server initializes the risk quantization value to 0.

[0375] S504: The server determines whether the characteristic information includes resource reservation information; if not, the risk quantification value is added and updated. After the risk quantification value is added and updated or when the resource reservation information is included, S505 is executed.

[0376] S505. The server determines whether the characteristic information includes device capability information; if not, the risk quantification value is increased and updated.

[0377] After the risk quantification value is added and updated or when the device capability information is included, S506 is executed.

[0378] S506. The server determines whether the actual calling number is consistent with the incoming call number; if so, the risk quantification value is increased and updated.

[0379] After the risk quantification value is added and updated or when the actual calling number is consistent with the incoming call number, S507 is executed.

[0380] S507. The server determines that noa is not a subscriber; if so, the risk quantification value is increased and updated.

[0381] After the risk quantification value is added and updated or when noa is a subscriber, S508 is executed.

[0382] S508. The server determines whether the device capability information in the feature information is consistent with the device capability information corresponding to the incoming call number; if so, the risk quantification value is increased and updated.

[0383] After the risk quantification value is added and updated or when the device capability information in the feature information is consistent with the device capability information corresponding to the incoming call number, S509 is executed.

[0384] S509. The server determines whether the risk quantification value is greater than a third threshold; if so, execute S510; if not, execute S518.

[0385] The third threshold here may be the same as the second threshold in S309.

[0386] S510. The server sends a verification request to the address of the incoming call number.

[0387] S511. The response information received by the server is a 200 OK response information, and S518 is executed.

[0388] S512. The response information received by the server is a 4xx response information, and the risk quantification value is increased and updated.

[0389] After the risk quantification value is added and updated, S513 is executed.

[0390] S513. The server determines whether the risk quantification value is greater than a second threshold; if so, execute S514; if not, execute S515.

[0391] S514: The server rejects the call request.

[0392] The server may send a rejection response message to the call initiator, or directly ignore the call request.

[0393] S515. The server determines whether the risk quantification value is greater than a first threshold; if so, execute S516; if not, execute S517.

[0394] S516: The server sends a call request and reminder information to the electronic device.

[0395] S517: The server sends a call request to the electronic device.

[0396] In this embodiment, the server can obtain the characteristic information carried in the call request, which includes the incoming call number. The server can send a verification request to the address of the incoming call number to identify whether the received call request actually comes from the address of the incoming call number, and can effectively identify the authenticity of the incoming call number. In particular, in the scenario where a call request is initiated by disguising a virtual network number as a designated number, if the incoming call number is indeed a disguised number A, and the call request does not come from the address of the real number A, then the verification response of the verification request will indicate that the address of number A has not initiated a call request, so that the server can determine that the incoming call number is a disguised risk number. When the server determines that the call request is risky, it can send a call request to the electronic device and send a reminder message for reminding the user of the electronic device that the call request is risky; or, when the server determines that the incoming call number is a risky number, the server can directly reject the call request to intercept the call request of the risky number, greatly reducing the probability of the electronic device answering the risky number, and to a certain extent reducing the risk of user information or resources of the electronic device being lost.

[0397] Fig.21 It is only a schematic diagram of the execution logic of the incoming call processing method provided by this embodiment with the server as the execution subject. In practical applications, the execution logic of the incoming call processing method provided by the above embodiment is not limited.

[0398] For example, a schematic diagram of the structure of a server 200 provided in an embodiment of the present application is as follows: Fig.21 As shown, the server 200 may include: a processor 201 , a memory 202 , a communication interface 203 , and a bus 204 . The processor 201 , the memory 202 , and the communication interface 203 may be connected via the bus 204 .

[0399] The processor 201 is the control center of the server, and can be a general-purpose central processing unit (CPU) or other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor. As an example, the processor 201 can include one or more CPUs, such as Fig.21 CPU 0 and CPU 1 are shown in .

[0400] The memory 202 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto.

[0401] In a possible implementation, the memory 202 may exist independently of the processor 201. The memory 202 may be connected to the processor 201 via a bus 204 and used to store data, instructions, or program codes. When the processor 201 calls and executes the instructions or program codes stored in the memory 202, the method for processing an incoming call provided in the embodiment of the present application can be implemented.

[0402] In another possible implementation, the memory 202 may also be integrated with the processor 201 .

[0403] The communication interface 203 is used for the server to connect with other devices through a communication network, which may be Ethernet, a radio access network (RAN), a wireless local area network (WLAN), etc. The communication interface 203 may include a receiving unit for receiving data and a sending unit for sending data.

[0404] In this embodiment, the server can communicate with the electronic device or other devices through the communication interface to realize the transmission of request messages and response messages such as call requests, verification requests, and response information.

[0405] The bus 204 may be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.21 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0406] It should be pointed out that Fig.21 The structure shown in the figure does not constitute a limitation on the server, except Fig.21 In addition to the components shown, the server may include more or fewer components than shown, or combine certain components, or arrange the components differently.

[0407] The present application also provides a chip system (eg, a system on a chip (SoC)), such as Fig. 22 As shown, the chip system includes at least one processor 701 and at least one interface circuit 702. The processor 701 and the interface circuit 702 can be interconnected by lines. For example, the interface circuit 702 can be used to receive signals from other devices (such as a memory of an electronic device). For another example, the interface circuit 702 can be used to send signals to other devices (such as a processor 701 or a camera of an electronic device). Exemplarily, the interface circuit 702 can read instructions stored in the memory and send the instructions to the processor 701. When the instruction is executed by the processor 701, the electronic device / server can perform the various steps in the above embodiments. Of course, the chip system may also include other discrete devices, which are not specifically limited in the embodiments of the present application.

[0408] An embodiment of the present application also provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on the above-mentioned electronic device, the electronic device executes each function or step executed by the electronic device 100 or the server 200 in the above-mentioned method embodiment.

[0409] The embodiment of the present application also provides a computer program product, which, when executed on a computer, enables the computer to execute the functions or steps executed by the electronic device 100 or the server 200 in the above method embodiment. For example, the computer may be the above electronic device 100 or the server 200.

[0410] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0411] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0412] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0413] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0414] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0415] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for processing an incoming call, characterized in that: Applied to an electronic device, the electronic device includes a first communication module; the method includes: The electronic device receives an incoming call request and obtains characteristic information of the incoming call request; the characteristic information includes an incoming call number; If the characteristic information indicates that the incoming call request is a voice transmission VoIP call, the electronic device sends a verification request to the address where the incoming call number is located; the verification request is used to verify whether the incoming call request comes from the address where the incoming call number is located; The electronic device receives response information for the verification request. If the response information indicates that the address of the incoming call number did not initiate the incoming call request, the electronic device quantifies the risk based on the feature information and the response information, and performs corresponding risk handling operations; different degrees of risk quantification levels correspond to different risk handling operations.

2. The method according to claim 1, characterized in that The electronic device sends a verification request to the address of the incoming call number, including: If the characteristic information does not include resource reservation information, the electronic device sends a verification request to the address where the incoming call number is located.

3. The method according to claim 1 or 2, characterized in that: The electronic device sends a verification request to the address of the incoming call number, including: If the characteristic information does not include device capability information, the electronic device sends a verification request to the address where the incoming call number is located.

4. The method according to claim 1 or 2, characterized in that: The characteristic information also includes an actual calling number, and the electronic device sends a verification request to the address of the incoming calling number, including: If the actual calling number in the feature information is inconsistent with the incoming call number in the feature information, the electronic device sends a verification request to the address where the incoming call number is located.

5. The method according to claim 1 or 2, characterized in that: The characteristic information also includes the user type of the call initiator, and the electronic device sends a verification request to the address of the incoming call number, including: If the user type in the feature information indicates a non-cellular communication user, the electronic device sends a verification request to the address where the incoming call number is located.

6. The method according to claim 1, characterized in that The performing of corresponding risk handling operations includes: The electronic device performs a ringing operation in response to the incoming call request and outputs risk reminder information; the risk reminder information is used to remind the user that the incoming call request has risks; or, The electronic device refuses to respond to the incoming call request; or, The characteristic information includes device capability information, The electronic device performs a ringing operation and displays a guidance interface in response to the incoming call request, wherein the guidance interface includes a first content and a second content, wherein the first content is used to provide the user with the device model corresponding to the incoming call request, and the second content is used to prompt the user to perform a question-and-answer verification of the device model with the call initiator after the call is connected.

7. The method according to claim 1, characterized in that The characteristic information further includes at least one of an actual call number and a user type of the call initiator; the electronic device performs risk quantification based on the characteristic information and the response information, and performs corresponding risk processing operations, including: The electronic device calculates the risk quantification value of the incoming call request by using the feature information; wherein the feature information does not include resource reservation information, the feature information does not include device capability information, the actual call number is inconsistent with the incoming call number, and the user type indicates a non-cellular communication user, all of which are used to increase the risk quantification value; The electronic device performs a corresponding risk handling operation based on the risk quantification value.

8. The method according to claim 7, characterized in that The method further comprises: If the response information indicates that the address of the incoming call number has not initiated a call request, the risk quantification value is increased and updated.

9. The method according to claim 7 or 8, characterized in that: The characteristic information also includes device capability information; the method also includes: If the feature information includes device capability information, the electronic device obtains a comparison result between the device capability information in the feature information and the device capability information corresponding to the incoming call number; If the comparison result indicates that the device capability information in the feature information is inconsistent with the device capability information corresponding to the incoming call number, the risk quantification value is increased and updated.

10. The method according to claim 7, characterized in that The electronic device performs corresponding risk processing operations based on the risk quantification value, including: If the risk quantification value is greater than a preset first threshold, the electronic device responds to the incoming call request, performs a ringing operation, and outputs risk reminder information; the risk reminder information is used to remind the user that the incoming call request is risky.

11. The method according to claim 10, characterized in that The electronic device performs corresponding risk processing operations based on the risk quantification value, including: If the risk quantification value is less than or equal to the first threshold and greater than a preset second threshold, the electronic device responds to the incoming call request, performs a ringing operation, and displays a guidance interface, the guidance interface including a first content and a second content, the first content being used to provide the user with the device model corresponding to the incoming call request, and the second content being used to prompt the user to perform a question-and-answer verification of the device model with the call initiator after the call is connected.

12. The method according to claim 10 or 11, characterized in that: The electronic device performs corresponding risk processing operations based on the risk quantification value, including: If the risk quantification value is greater than a preset third threshold, the electronic device rejects the incoming call request; the third threshold is greater than the first threshold.

13. A method for processing an incoming call, characterized in that: Applied to a server, the server includes a second communication module, the server is communicatively connected with an electronic device, and the method includes: The server receives a verification request sent by the electronic device; the verification request is a request initiated by the electronic device based on the incoming call number in the feature information after receiving the incoming call request and obtaining feature information of the incoming call request, when it is determined that the feature information indicates that the incoming call request is a voice transmission VoIP call; the verification request is used to verify whether the incoming call request comes from the address where the incoming call number is located; The server returns response information for the verification request to the electronic device; the response message is used to indicate whether the address of the incoming call number has initiated a call request. When the response message indicates that the address of the incoming call number has not initiated a call request, the response message is used to enable the electronic device to quantify risks based on the feature information and the response information, and perform corresponding risk handling operations; different degrees of risk quantification levels correspond to different risk handling operations.

14. A method for processing an incoming call, characterized in that: Applied to a server, the server includes a second communication module, the server is communicatively connected with an electronic device, and the method includes: The server receives a call request and obtains characteristic information of the call request; the characteristic information includes an incoming call number and a destination number, and the destination number corresponds to the electronic device; If the characteristic information indicates that the incoming call request is a voice transmission call, the server sends a verification request to the address where the incoming call number is located; the verification request is used to verify whether the call request comes from the address where the incoming call number is located; The server receives response information for the verification request. If the response information indicates that the address of the incoming call number has not initiated a call request, the server performs risk quantification based on the feature information and the response information. Based on the degree of risk quantification, the server sends the call request and risk reminder information to the electronic device or the server rejects the call request; the risk reminder information is used to remind a user using the electronic device that the call request is risky.

15. The method according to claim 14, characterized in that The feature information also includes at least one of the actual call number and the user type of the call initiator; The server performs risk quantification based on the feature information and the response information, including: The server calculates the risk quantification value of the call request using the feature information; wherein the feature information does not include resource reservation information, the feature information does not include device capability information, the actual call number is inconsistent with the incoming call number, and the user type indicates a non-cellular communication user, all of which are used to increase the risk quantification value; The server performs corresponding risk handling operations based on the risk quantification value.

16. The method according to claim 15, characterized in that The method further comprises: If the response information indicates that the address where the incoming call number is located has not initiated a call request, the risk quantification value is increased and updated.

17. The method according to claim 15 or 16, characterized in that The server performs corresponding risk processing operations based on the risk quantification value, including: If the risk quantification value is greater than a preset first threshold, the server sends the call request and the risk reminder information to the electronic device; and / or, If the risk quantification value is greater than a preset third threshold, the server rejects the call request; the third threshold is greater than the first threshold.

18. An electronic device, characterized in that: The electronic device includes a first communication module, a memory and one or more processors; the first communication module and the memory are coupled to the processor; the memory stores computer program code, and the computer program code includes computer instructions. When the computer instructions are executed by the processor, the electronic device executes the method as described in any one of claims 1-12.

19. A server, characterized in that: The electronic device includes a second communication module, a memory and one or more processors; the second communication module and the memory are coupled to the processor; the memory stores computer program code, and the computer program code includes computer instructions. When the computer instructions are executed by the processor, the electronic device executes the method as described in any one of claims 13 or 14-17.

20. A computer-readable storage medium, characterized in that: It comprises computer instructions, which, when executed on an electronic device, enable the electronic device to execute the method as described in any one of claims 1 to 12; and when executed on a server, enable the server to execute the method as described in any one of claims 13 or 14 to 17.

Images