Incoming call processing method and device
Receive and analyze non-whitelist calls through the local call model, identify and intercept harassing calls, solve the problem of interception in the existing technology that cannot cope with number changes, and realize accurate phone management and user protection.
Patent Information
- Application Number
- CN202510850966.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-24
- Publication Date
- 2025-08-29
AI Technical Summary
The prior art is difficult to effectively reduce the disturbance of non-whitelisted phone calls to users, especially harassing phone calls, and cannot cope with the interception problem of calling party after changing numbers.
The local call model is used to answer non-whitelist incoming calls, analyze call data through machine learning, identify incoming call types, and automatically hang up incoming calls when identified as a masked type. The training data includes historical call data and incoming call type tags. Users can manually correct the model to improve recognition accuracy.
It realizes accurate identification and interception of non-whitelisted phone calls, reduces the possibility of users being exposed to harassing calls, reduces the risk of privacy leakage, and improves user anti-harassment experience and device use security.
Smart Images
Figure CN120567962A_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the field of communication technology, and specifically relates to a method and device for processing incoming calls. Background Art
[0002] With the popularization of communication technology, harassing calls often infiltrate people's daily lives with the help of virtual numbers, Internet calls and other technologies, affecting users' privacy and security and disrupting their lives.
[0003] Currently, technologies for preventing phone harassment primarily rely on cloud-based services or local rule bases. The former relies on carriers identifying high-frequency calling behavior, while the latter uses local blacklists configured on mobile phones to block calls. However, these methods have significant limitations. Blacklists or carriers' high-frequency call blocking methods can only restrict fixed numbers or specific calling patterns. Once the caller changes their number, the blocking becomes ineffective, failing to fundamentally address the problem of phone harassment.
[0004] Therefore, it is currently difficult to reduce the disturbance to users caused by non-whitelisted calls. Summary of the Invention
[0005] The purpose of the embodiments of the present application is to provide a method and device for handling incoming calls, which can reduce the disturbance to users caused by non-whitelisted calls.
[0006] In a first aspect, an embodiment of the present application provides a method for handling an incoming call, the method comprising:
[0007] In the case of receiving a non-whitelist call, the local call model answers the non-whitelist call and obtains the first call data;
[0008] Analyzing the first call data using a local call model to determine the first incoming call type; the local call model is trained based on a plurality of training data, the training data including interrelated historical call data and incoming call type labels;
[0009] When the first incoming call type is consistent with the screened call type, the non-whitelisted call is hung up.
[0010] In a second aspect, an embodiment of the present application provides an incoming call processing device, the device comprising:
[0011] An answering module, configured to, when a non-whitelist incoming call is received, answer the non-whitelist incoming call by a local call model and obtain first call data;
[0012] a determination module, configured to analyze the first call data using the local call model to determine a first incoming call type; the local call model is trained based on a plurality of training data, the training data including interrelated historical call data and incoming call type labels;
[0013] The hanging up module is used to hang up the non-whitelist call when the first incoming call type is consistent with the screened call type.
[0014] In a third aspect, an embodiment of the present application provides an electronic device comprising a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the programs or instructions are executed by the processor, the steps of the method described in the first aspect are implemented.
[0015] In a fourth aspect, an embodiment of the present application provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the method described in the first aspect are implemented.
[0016] In a fifth aspect, an embodiment of the present application provides a chip, which includes a processor and a communication interface, the communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the method described in the first aspect.
[0017] In a sixth aspect, an embodiment of the present application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the method described in the first aspect.
[0018] In an embodiment of the present application, when a non-whitelist call is received, the local call model automatically answers the non-whitelist call and obtains the first call data, thereby avoiding the possibility of the user being directly exposed to harassing calls; the first call data is analyzed by the local call model to determine the first call type. Since the local call model is trained based on multiple training data, the training data includes interrelated historical call data and call type labels. Therefore, the local call model can accurately predict the first call type corresponding to the first call data through the mapping relationship learned from the historical call data and the call type labels. When the first call type is consistent with the blocked call type, the non-whitelist call is hung up, thereby reducing the disturbance to the user by non-whitelist calls. BRIEF DESCRIPTION OF THE DRAWINGS
[0019] Figure 1 This is a flow chart of a method for handling incoming calls provided by an embodiment of the present application;
[0020] Figure 2 is a schematic diagram of a first input for a first incoming call type provided by an embodiment of the present application;
[0021] Figure 3 is a schematic diagram of a second input for a first incoming call type provided by an embodiment of the present application;
[0022] Figure 4This is a structural diagram of an incoming call processing device provided in an embodiment of the present application;
[0023] Figure 5 This is one of the hardware structure diagrams of the electronic device according to the embodiment of the present application;
[0024] Figure 6 This is the second hardware structure diagram of the electronic device according to the embodiment of the present application. DETAILED DESCRIPTION
[0025] The following will be combined with the accompanying drawings of the embodiments of the present application to clearly describe the technical solutions of the embodiments of the present application. Obviously, the embodiments described are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments of the present application, all other embodiments obtained by ordinary technicians in this field are within the scope of protection of this application.
[0026] The terms "first," "second," and the like in the specification and claims of this application are used to distinguish similar objects, and are not used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of this application can be implemented in an order other than that illustrated or described herein, and that the objects distinguished by "first," "second," and the like are generally of the same type, and do not limit the number of objects; for example, the first object can be one or more. In addition, the term "and / or" in the specification and claims refers to at least one of the connected objects, and the character " / " generally indicates that the objects connected are in an "or" relationship.
[0027] The incoming call processing method provided in the embodiment of the present application can be applied to at least the following application scenarios, which are described below.
[0028] Currently, harassing phone calls severely disrupt people's normal lives and have numerous negative consequences. In the insurance market, frequent sales calls can disrupt personal rhythms, for example, waking office workers during their lunch break. In loan cases, criminals use "low-interest loans" as bait, defrauding many people of their fees. Homebuying calls often use false offers, some with fake listings, or induce risks in signing contracts.
[0029] In response to the problems arising from related technologies, the embodiments of the present application provide a method and device for handling incoming calls, which can reduce the disturbance to users caused by non-whitelisted calls.
[0030] The following describes in detail the incoming call processing method provided by the embodiment of the present application through specific embodiments and application scenarios in conjunction with the accompanying drawings.
[0031] Figure 1 A flowchart of a method for handling incoming calls provided in an embodiment of the present application.
[0032] like Figure 1 As shown, the incoming call processing method may include steps 110 to 130, and the method is applied to an incoming call processing device, as shown below:
[0033] Step 110: When a non-whitelist call is received, the local call model answers the non-whitelist call and obtains first call data;
[0034] Whitelist: refers to the list of numbers that are allowed to be answered, which is set by the user. When a number in the whitelist calls, the call will be connected normally or given priority.
[0035] Non-whitelist calls: calls from numbers that have not been added to the user's whitelist. These numbers may be unfamiliar numbers, unsaved numbers, or numbers marked by default as "unknown", "harassment", "fraud", etc.
[0036] Local call model: Based on machine learning technology, the model is trained using a large amount of training data containing historical call data and its corresponding call type labels. It is deployed on local devices to process and analyze incoming call data.
[0037] First call data: The call voice, text, and other related data recorded after the local call model answers a non-whitelist call.
[0038] When an electronic device receives a non-whitelisted call, the local call model automatically takes over the call and records the voice data during the call as the first call data, preventing the user from being directly exposed to harassing calls.
[0039] In a possible embodiment, before step 110, the following steps may be further included:
[0040] Extract the user's voiceprint features and conversation features from historical call data;
[0041] The initial call model is trained based on the voiceprint features and conversation features to obtain the local call model.
[0042] Voiceprint features: The unique acoustic features produced by each person when speaking, including physical properties such as intonation, timbre, and frequency, can be used to identify the speaker's identity or characteristics and are unique and stable.
[0043] Conversation features: Historical call data reflects features of the call topic, semantics, and speech patterns, such as the frequency of specific keywords, the logical structure of sentences, and conversation scenarios.
[0044] Initial call model: A basic model architecture that has not yet been fully trained. It has the ability to initially process call data and requires data training to optimize parameters and recognition logic.
[0045] Local call model: The initial call model is trained with voiceprint features and conversation features, then deployed on local devices to become a mature model for actually handling unknown calls.
[0046] Using acoustic analysis and natural language processing techniques from historical call data, we extract the user's voiceprint and conversation features. Voiceprint features are used to identify the caller's identity, while conversation features are used to mine the semantics and patterns of call content.
[0047] The extracted voiceprint features and conversation features are used as training data and input into the initial call model. Through the machine learning algorithm, the model parameters are adjusted so that the initial call model learns the user's speaking characteristics, thereby training the initial call model into a local call model.
[0048] Step 120: Analyze the first call data using a local call model to determine the first incoming call type; the local call model is trained based on a plurality of training data, the training data including interrelated historical call data and incoming call type labels;
[0049] First call type: After analyzing the first call data, the local call model determines the category of the unfamiliar call, such as insurance sales, loan promotion, etc.
[0050] The local call model analyzes the first call data based on the patterns and features learned from the training data. Using technologies such as speech recognition and semantic analysis, it matches the call content with the features in the training data to determine the type of the first incoming call.
[0051] In a possible embodiment, before step 120, the following steps may be further included:
[0052] Analyze historical call data through the initial call model to obtain the predicted call type;
[0053] The initial call model is trained according to the predicted call type and the call type label until the initial call model meets the training stop condition, thereby obtaining a local call model.
[0054] Initial call model: This is an untrained basic model architecture with preliminary call data analysis capabilities.
[0055] Historical call data: Existing call record data, including call voice, text, and other information, is the raw material for model training.
[0056] Predicted call type: The initial call model uses historical call data to estimate the call type through preliminary analysis.
[0057] Call type label: The true category of historical call data that is pre-annotated manually or determined through reliable means, serves as a reference standard for model training.
[0058] Training stop conditions: Pre-set model training termination criteria, such as the error rate between the predicted call type and the call type label falling below a certain threshold or the number of iterations reaching an upper limit, are used to determine whether model training has achieved the desired results.
[0059] Local call model: The initial call model is repeatedly trained. Once the training stop conditions are met, it is deployed on local devices to form a mature model for actual analysis and processing of unknown calls.
[0060] The initial call model is used to analyze and process historical call data. Based on the model's existing parameters and algorithms, the call type is predicted for each historical call record, resulting in a predicted call type. The predicted call type is compared with the call type label, and the error between the two is calculated. Based on this error, a machine learning algorithm is used to adjust the parameters of the initial call model to make the model's predictions more closely resemble the actual call type label.
[0061] After each parameter adjustment, the model is checked to see if it meets the training stop criteria. If not, the prediction, comparison, and optimization process is repeated using more historical call data. If it does, training stops. The model at this point is now a local call model with high call type recognition accuracy, ready for practical application.
[0062] Specifically, an initial call model is built into the electronic device and collects a large amount of historical call data labeled with actual call types, covering a variety of call types, such as insurance sales, loan promotions, and normal work calls. The initial call model analyzes this historical call data, predicting the call type of each call and comparing the predictions with the call type labels. If there are any prediction errors, such as predicting a call from an insurance salesperson as a normal call, the model parameters are adjusted using a machine learning algorithm. This process is repeated continuously. When the model's prediction error rate falls below a preset threshold for multiple consecutive times, training stops and the final local call model is obtained. This local call model can then be used to automatically identify the type of unfamiliar callers.
[0063] Through iterative training based on historical data, the local call model can learn the characteristic patterns of different call types, significantly improving the accuracy of call type identification and effectively reducing misjudgments and missed judgments; the training process is based on local data, reducing the risk of privacy leakage caused by uploading data to the cloud; by setting training stop conditions, the model ensures that training stops when ideal performance is achieved, avoiding overtraining and improving training efficiency; the final local call model can quickly and accurately analyze unfamiliar calls, accurately block harassing calls, and significantly improve users' anti-harassment experience and device safety.
[0064] In a possible embodiment, after step 120, the following steps may be further included:
[0065] storing the first call data and the first incoming call type in association with each other;
[0066] receiving a first input of a first incoming call type, the first input being used to modify the first incoming call type to a second incoming call type; screening incoming call types including the first incoming call type and the second incoming call type;
[0067] In response to the first input, the local call model is updated according to the first call data and the second incoming call type.
[0068] First call data: real-time call information such as voice and text recorded by the local call model after answering an unknown call.
[0069] First incoming call type: The incoming call category determined by the local call model after preliminary analysis of the first call data.
[0070] Second call type: The call category that the user manually modified through the first input, such as changing "insurance sales" to "fraud call".
[0071] First input: User interaction with the model recognition result, used to correct incorrect call type determination, such as clicking the "Mark as Other Type" button. Figure 2 As shown, the user can modify the first incoming call type "health care product sales" through the first input;
[0072] Blocked call types: A set of system preset and user-defined call categories that need to be blocked, including the first call type and the corrected second call type.
[0073] The first call data is bound to the initially determined first call type and stored to form labeled training samples, providing data support for subsequent model optimization. The user's input regarding the first call type is received, the first call type is updated to the second call type, and the set of blocked call types is simultaneously updated.
[0074] The local call model is retrained based on the user's corrected second call type and the corresponding first call data. The model parameters are adjusted using a machine learning algorithm to learn more accurate feature matching logic, improving subsequent recognition accuracy.
[0075] For example, a local call model analyzes a non-whitelisted call and identifies the first call type as "loan promotion" and stores the first call data. However, upon answering the call, the user discovers the caller is actually a fraud ring and manually changes the first call type to "fraud" through the phone interface. The system then adds "fraud" to the blocked call types. The local call model is then retrained based on the revised "fraud" label and the corresponding call data. Subsequent calls using similar sales pitches can be more accurately identified as "fraud" and automatically disconnected.
[0076] Therefore, through manual correction by users, the model can learn more detailed characteristics of incoming call types and reduce the misjudgment rate; users can adjust the blocking rules according to actual scenarios to make the system more suitable for personal needs; data correction and storage are completed locally, without the need to upload to the cloud, reducing the risk of call content leakage; the model can continue to iterate based on user feedback and adapt to new types of harassment tactics.
[0077] In a possible embodiment, after step 120, the following steps may be further included:
[0078] receiving a second input of the first incoming call type, the second input being used to modify the first incoming call type to a non-screened incoming call type;
[0079] In response to the second input, the local call model is updated according to the first call data and the type of the unscreened incoming call.
[0080] Second input: The user's interactive operation to intervene in the first incoming call type determined by the model, which is used to mark it as a normal incoming call type that does not need to be blocked. Figure 3 As shown, the user can modify the first incoming call type to a non-screened incoming call type through the second input;
[0081] Non-screened call types: system-preset call categories or user-defined call categories that do not trigger interception, such as contact calls, work calls, etc., as opposed to screened call types.
[0082] When the local call model mistakenly identifies a normal call as a harassment call, the user uses a second input to mark it as an unshielded call. The first call data is then bound to the corrected unshielded call type to form a new training sample. The model is then retrained based on this sample to enhance its ability to recognize normal call features and reduce the probability of similar misjudgments in the future.
[0083] For example, when a customer service representative of a bank calls in, the local call model analyzes the first call type and determines that it is an "insurance salesperson" and is about to hang up automatically. When the user subsequently views or listens to the first call data, they find that it is a normal business notification from the bank and mark it as "bank service" through interface operations. The first call data is associated with "bank service" and the local call model is updated. When the user subsequently receives a call from the bank with similar language, the model can accurately identify it as a non-harassment type, allowing the user to answer the call normally.
[0084] Therefore, the local call model is corrected through user feedback, reducing the probability of misjudging normal calls as harassment and avoiding missing important notifications; by learning more characteristics of normal call scenarios, the model can more accurately distinguish between harassment and non-harassment calls and adapt to complex and changeable real-world scenarios.
[0085] Step 130: When the first incoming call type is consistent with the screened incoming call type, hang up the non-whitelisted call.
[0086] Blocked call types: Pre-set a set of nuisance call types to be blocked, such as insurance sales calls, bank loan calls, home purchase sales calls, and health product sales calls.
[0087] The determined first incoming call type is compared with the preset blocked call type. If the two are consistent, the system automatically hangs up the non-whitelisted call to intercept harassing calls.
[0088] Specifically, the electronic device has a built-in local call model, which has been trained using a large amount of historical call data and corresponding call type labels for insurance, loan, and home sales promotions. When a user's phone receives a call from a non-whitelisted call, the local call model automatically answers the call, records the call content as the first call data, and analyzes the first call data to determine that the first call type is a loan sales promotion, which matches the "loan harassment" call type in the blocked call type. The phone then automatically hangs up the call.
[0089] Automatically handle unfamiliar calls through the local call model, preventing users from being exposed to nuisance calls and protecting privacy. Compared with traditional blacklists or cloud-based interception, it reduces data upload and reduces the risk of privacy leakage. By analyzing the first call data through the local call model, it can accurately identify nuisance calls in complex scenarios and reduce misjudgments. Automatically hang up calls of the type of blocked calls, reducing the burden of users manually setting interception rules, and improving the anti-nuisance experience and usage efficiency.
[0090] In a possible embodiment, after analyzing the first call data using a local call model, if the call type of the non-whitelist call cannot be determined, a call prompt message is output, where the call prompt message is used to prompt the user to answer the non-whitelist call.
[0091] Call prompt information: When the model cannot determine the type of incoming call, an interactive reminder is sent to the user to guide the user to decide whether to answer the non-whitelisted call.
[0092] After the local call model extracts features from the first call data, if it can't match a known blocked or unblocked call type, it determines the call type as "Unable to Determine." If the model analysis indicates uncertainty, a call prompt message is generated, such as "Suspected unfamiliar important call, do you want to answer?", placing the decision-making power in the hands of the user. The user decides whether to answer the call based on the prompt message, avoiding missed calls or exposure to harassment caused by misjudgment by the model.
[0093] For example, if a caller receives a call from a non-whitelisted provider and the local call model analyzes the call content and finds that the caller mentions both "promotional events" and "emergency matters," with mixed features that are difficult to categorize, the user will be prompted with a message: "Mixed call detected, possibly an important call, do you want to answer?" along with a brief preview of the call content using keywords such as "events" and "emergency matters." The user can then identify the call as a potential partner and answer it, avoiding missing important calls due to the model's inability to identify them.
[0094] For non-whitelist calls that the model cannot identify, the decision-making power is given to the user, reducing the omission of important calls, enhancing the sense of security, and avoiding accidental interception. It is suitable for new and atypical harassment scenarios. The user's answering decision on ambiguous calls can be used as new training data and subsequently used to supplement the training model to improve its recognition ability in complex scenarios.
[0095] In an embodiment of the present application, when a non-whitelist call is received, the local call model automatically answers the non-whitelist call and obtains the first call data, thereby avoiding the possibility of the user being directly exposed to harassing calls; the first call data is analyzed by the local call model to determine the first call type. Since the local call model is trained based on multiple training data, the training data includes interrelated historical call data and call type labels. Therefore, the local call model can accurately predict the first call type corresponding to the first call data through the mapping relationship learned from the historical call data and the call type labels. When the first call type is consistent with the blocked call type, the non-whitelist call is hung up, thereby reducing the disturbance to the user by non-whitelist calls.
[0096] The call processing method provided in the embodiment of the present application can be executed by a call processing device. In the embodiment of the present application, the call processing device provided in the embodiment of the present application is described by taking the call processing method performed by the call processing device as an example.
[0097] Figure 4 4 is a block diagram of an incoming call processing device provided in an embodiment of the present application. The device 400 includes:
[0098] The answering module 410 is configured to, when a non-whitelist incoming call is received, answer the non-whitelist incoming call by the local call model and obtain first call data;
[0099] a determination module 420 configured to analyze the first call data using the local call model to determine a first incoming call type; the local call model is trained based on a plurality of training data, the training data including interrelated historical call data and incoming call type labels;
[0100] The hanging up module 430 is configured to hang up the non-whitelist call when the first incoming call type is consistent with the screened call type.
[0101] In a possible embodiment, the apparatus 400 further includes:
[0102] An extraction module, configured to extract the user's voiceprint features and conversation features from the historical call data;
[0103] A training module is used to train an initial call model according to the voiceprint features and the conversation features to obtain the local call model.
[0104] In a possible embodiment, the apparatus 400 further includes:
[0105] a storage module, configured to associate and store the first call data with the first incoming call type;
[0106] a first receiving module, configured to receive a first input regarding the first incoming call type, wherein the first input is used to modify the first incoming call type to a second incoming call type; the screened incoming call types include the first incoming call type and the second incoming call type;
[0107] The first updating module is configured to update the local call model in response to the first input and according to the first call data and the second incoming call type.
[0108] In a possible embodiment, the apparatus 400 further includes:
[0109] a second receiving module, configured to receive a second input regarding the first incoming call type, wherein the second input is used to modify the first incoming call type to a non-shielded incoming call type;
[0110] The second updating module is configured to update the local call model in response to the second input and according to the first call data and the non-screened incoming call type.
[0111] In a possible embodiment, the apparatus 400 further includes:
[0112] The output module is used to output call prompt information when the call type of the non-whitelist call cannot be determined after analyzing the first call data through the local call model, and the call prompt information is used to prompt the user to answer the non-whitelist call.
[0113] In an embodiment of the present application, when a non-whitelist call is received, the local call model automatically answers the non-whitelist call and obtains the first call data, thereby avoiding the possibility of the user being directly exposed to harassing calls; the first call data is analyzed by the local call model to determine the first call type. Since the local call model is trained based on multiple training data, the training data includes interrelated historical call data and call type labels. Therefore, the local call model can accurately predict the first call type corresponding to the first call data through the mapping relationship learned from the historical call data and the call type labels. When the first call type is consistent with the blocked call type, the non-whitelist call is hung up, thereby reducing the disturbance to the user by non-whitelist calls.
[0114] The call processing device in the embodiment of the present application can be an electronic device or a component in the electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices other than a terminal. For example, the electronic device can be a mobile phone, a tablet computer, a laptop computer, a PDA, an in-vehicle electronic device, a mobile Internet device (MID), an augmented reality (AR) / virtual reality (VR) device, a robot, a wearable device, an ultra-mobile personal computer (UMPC), a netbook or a personal digital assistant (PDA), etc. It can also be a server, a network attached storage (NAS), a personal computer (PC), a television (TV), a teller machine or a self-service machine, etc., and the embodiment of the present application does not specifically limit it.
[0115] The incoming call processing device of the embodiment of the present application may be a device having an action system. The action system may be an Android action system, an iOS action system, or other possible action systems, which are not specifically limited in the embodiment of the present application.
[0116] The call processing device provided in the embodiment of the present application can implement each process implemented in the above method embodiment. To avoid repetition, it will not be described here.
[0117] Alternatively, as Figure 5 As shown, an embodiment of the present application further provides an electronic device 510, including a processor 511, a memory 512, and a program or instruction stored in the memory 512 and executable on the processor 511. When the program or instruction is executed by the processor 511, each step of any of the above-mentioned incoming call processing method embodiments is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be described here.
[0118] It should be noted that the electronic devices in the embodiments of the present application include the above-mentioned mobile electronic devices and non-mobile electronic devices.
[0119] Figure 6 A schematic diagram of the hardware structure of an electronic device implementing an embodiment of the present application.
[0120] The electronic device 600 includes but is not limited to components such as a radio frequency unit 601 , a network module 602 , an audio output unit 603 , an input unit 604 , a sensor 605 , a display unit 606 , a user input unit 607 , an interface unit 608 , a memory 609 , and a processor 610 .
[0121] Those skilled in the art will understand that the electronic device 600 may also include a power source (such as a battery) to power each component, and the power source may be logically connected to the processor 610 through a power management system, thereby implementing functions such as charging, discharging, and power consumption management through the power management system. Figure 6 The electronic device structure shown in the figure does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently, which will not be repeated here.
[0122] The processor 610 is configured to, upon receiving a non-whitelist incoming call, answer the non-whitelist incoming call by a local call model to obtain first call data;
[0123] Processor 610 is further configured to analyze the first call data using the local call model to determine a first incoming call type; the local call model is trained based on a plurality of training data, the training data including interrelated historical call data and incoming call type labels;
[0124] The processor 610 is further configured to, when the first incoming call type is consistent with the screened call type, hang up the non-whitelisted call.
[0125] Optionally, the processor 610 is further configured to use an extraction module to extract the user's voiceprint features and conversation features from the historical call data;
[0126] The processor 610 is further configured to train an initial call model according to the voiceprint features and the conversation features to obtain the local call model.
[0127] Optionally, the memory 609 is configured to store the first call data and the first incoming call type in association with each other;
[0128] A user input unit 607 is configured to receive a first input regarding the first incoming call type, wherein the first input is configured to modify the first incoming call type to a second incoming call type; the screened incoming call types include the first incoming call type and the second incoming call type;
[0129] The processor 610 is further configured to update the local call model in response to the first input and according to the first call data and the second incoming call type.
[0130] Optionally, the user input unit 607 is configured to receive a second input on the first incoming call type, where the second input is used to modify the first incoming call type to a non-screened incoming call type;
[0131] The processor 610 is further configured to update the local call model in response to the second input and according to the first call data and the unscreened incoming call type.
[0132] Optionally, the audio output unit 603 is used to output a call prompt message when the call type of the non-whitelist call cannot be determined after analyzing the first call data through the local call model, and the call prompt message is used to prompt the user to answer the non-whitelist call.
[0133] Optionally, the display unit 606 is used to output a call prompt message when the call type of the non-whitelist call cannot be determined after analyzing the first call data through the local call model, and the call prompt message is used to prompt the user to answer the non-whitelist call.
[0134] In an embodiment of the present application, when a non-whitelist call is received, the local call model automatically answers the non-whitelist call and obtains the first call data, thereby avoiding the possibility of the user being directly exposed to harassing calls; the first call data is analyzed by the local call model to determine the first call type. Since the local call model is trained based on multiple training data, the training data includes interrelated historical call data and call type labels. Therefore, the local call model can accurately predict the first call type corresponding to the first call data through the mapping relationship learned from the historical call data and the call type labels. When the first call type is consistent with the blocked call type, the non-whitelist call is hung up, thereby reducing the disturbance to the user by non-whitelist calls.
[0135] It should be understood that in an embodiment of the present application, the input unit 604 may include a graphics processing unit (GPU) 6041 and a microphone 6042, and the graphics processor 6041 processes image data of a static picture or video image obtained by an image capture device (such as a camera) in a video image capture mode or an image capture mode. The display unit 606 may include a display panel 6061, and the display panel 6061 may be configured in the form of a liquid crystal display, an organic light emitting diode, etc. The user input unit 607 includes a touch panel 6071 and at least one of other input devices 6072. The touch panel 6071 is also called a touch screen. The touch panel 6071 may include two parts: a touch detection device and a touch controller. Other input devices 6072 may include but are not limited to a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, and an action stick, which will not be repeated here. The memory 609 can be used to store software programs and various data, including but not limited to applications and action systems. The processor 610 may integrate an application processor and a modem processor, wherein the application processor mainly processes the action system, user pages and applications, etc., and the modem processor mainly processes wireless communications. It is understandable that the modem processor may not be integrated into the processor 610.
[0136] The memory 609 can be used to store software programs and various data. The memory 609 may mainly include a first storage area for storing programs or instructions and a second storage area for storing data, wherein the first storage area may store an operating system, applications or instructions required for at least one function (such as a sound playback function, an image playback function, etc.). In addition, the memory 609 may include a volatile memory or a non-volatile memory, or the memory x09 may include both volatile and non-volatile memory. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), a synchronous dynamic random access memory (SDRAM), a double data rate synchronous dynamic random access memory (DDRSDRAM), an enhanced synchronous dynamic random access memory (ESDRAM), a synchronous link dynamic random access memory (SLDRAM), and a direct memory bus random access memory (DRRAM). The memory 609 in the embodiment of the present application includes but is not limited to these and any other suitable types of memory.
[0137] Processor 610 may include one or more processing units. Optionally, processor 610 integrates an application processor and a modem processor. The application processor primarily handles operations related to the operating system, user interface, and application programs, while the modem processor primarily processes wireless communication signals, such as a baseband processor. It is understood that the modem processor may not be integrated into processor 610.
[0138] An embodiment of the present application also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, each process of the above-mentioned incoming call processing method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.
[0139] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
[0140] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned incoming call processing method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.
[0141] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.
[0142] An embodiment of the present application provides a computer program product, which is stored in a storage medium. The program product is executed by at least one processor to implement the various processes of the above-mentioned incoming call processing method embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.
[0143] It should be noted that, in this article, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element. In addition, it should be noted that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in the opposite order according to the functions involved. For example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.
[0144] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), including a number of instructions for enabling a terminal (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.
[0145] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of this application, ordinary technicians in this field can also make many forms without departing from the purpose of this application and the scope of protection of the claims, all of which are within the protection of this application.
Claims
1. A method for handling incoming calls, characterized in that: The method comprises: In the case of receiving a non-whitelist incoming call, the local call model answers the non-whitelist incoming call to obtain first call data; Analyzing the first call data using the local call model to determine a first incoming call type; the local call model is trained based on a plurality of training data, the training data including interrelated historical call data and incoming call type labels; When the first incoming call type is consistent with the screened call type, the non-whitelisted call is hung up.
2. The method according to claim 1, characterized in that In the case of receiving a non-whitelist incoming call, before the local call model answers the non-whitelist incoming call, the method further includes: Extracting the user's voiceprint features and conversation features from the historical call data; An initial call model is trained according to the voiceprint features and the conversation features to obtain the local call model.
3. The method according to claim 1, characterized in that After analyzing the first call data using the local call model to determine the first incoming call type, the method further includes: storing the first call data and the first incoming call type in association with each other; receiving a first input for the first incoming call type, wherein the first input is used to modify the first incoming call type to a second incoming call type; the screened incoming call types include the first incoming call type and the second incoming call type; In response to the first input, the local call model is updated according to the first call data and the second incoming call type.
4. The method according to claim 1, wherein After analyzing the first call data using the local call model to determine the first incoming call type, the method further includes: receiving a second input regarding the first incoming call type, wherein the second input is used to modify the first incoming call type to a non-screened incoming call type; In response to the second input, the local call model is updated according to the first call data and the unscreened incoming call type.
5. The method according to claim 1, characterized in that The method further comprises: After analyzing the first call data using the local call model, if the call type of the non-whitelist call cannot be determined, a call prompt message is output, where the call prompt message is used to prompt the user to answer the non-whitelist call.
6. A call processing device, characterized in that: The device comprises: An answering module, configured to, when a non-whitelist incoming call is received, answer the non-whitelist incoming call by a local call model and obtain first call data; a determination module, configured to analyze the first call data using the local call model to determine a first incoming call type; the local call model is trained based on a plurality of training data, the training data including interrelated historical call data and incoming call type labels; The hanging up module is used to hang up the non-whitelist call when the first incoming call type is consistent with the screened call type.
7. The device according to claim 6, characterized in that The device further comprises: An extraction module, configured to extract the user's voiceprint features and conversation features from the historical call data; A training module is used to train an initial call model according to the voiceprint features and the conversation features to obtain the local call model.
8. The device according to claim 6, characterized in that The device further comprises: a storage module, configured to associate and store the first call data with the first incoming call type; a first receiving module, configured to receive a first input regarding the first incoming call type, wherein the first input is used to modify the first incoming call type to a second incoming call type; the screened incoming call types include the first incoming call type and the second incoming call type; The first updating module is configured to update the local call model in response to the first input and according to the first call data and the second incoming call type.
9. The device according to claim 6, characterized in that The device further comprises: a second receiving module, configured to receive a second input regarding the first incoming call type, wherein the second input is used to modify the first incoming call type to a non-shielded incoming call type; The second updating module is configured to update the local call model in response to the second input and according to the first call data and the non-screened incoming call type.
10. The device according to claim 6, characterized in that The device further comprises: The output module is used to output call prompt information when the call type of the non-whitelist call cannot be determined after analyzing the first call data through the local call model, and the call prompt information is used to prompt the user to answer the non-whitelist call.