CN111654574A - Call request processing method and device - Google Patents

Call request processing method and device Download PDF

Info

Publication number
CN111654574A
CN111654574A CN202010494970.7A CN202010494970A CN111654574A CN 111654574 A CN111654574 A CN 111654574A CN 202010494970 A CN202010494970 A CN 202010494970A CN 111654574 A CN111654574 A CN 111654574A
Authority
CN
China
Prior art keywords
client
call
information
white list
determining
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010494970.7A
Other languages
Chinese (zh)
Other versions
CN111654574B (en
Inventor
郑佳佳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Zhangmen Science and Technology Co Ltd
Original Assignee
Shanghai Zhangmen Science and Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Zhangmen Science and Technology Co Ltd filed Critical Shanghai Zhangmen Science and Technology Co Ltd
Priority to CN202010494970.7A priority Critical patent/CN111654574B/en
Publication of CN111654574A publication Critical patent/CN111654574A/en
Application granted granted Critical
Publication of CN111654574B publication Critical patent/CN111654574B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/66Substation equipment, e.g. for use by subscribers with means for preventing unauthorised or fraudulent calling
    • H04M1/663Preventing unauthorised calls to a telephone set
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/66Substation equipment, e.g. for use by subscribers with means for preventing unauthorised or fraudulent calling
    • H04M1/663Preventing unauthorised calls to a telephone set
    • H04M1/665Preventing unauthorised calls to a telephone set by checking the validity of a code
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/436Arrangements for screening incoming calls, i.e. evaluating the characteristics of a call before deciding whether to answer it

Abstract

The application discloses a method and a device for processing a call request, and relates to the technical field of communication. The specific implementation mode comprises the following steps: the method comprises the steps that a call white list of a second client side is obtained in response to the fact that a call request of the first client side to the second client side is received; judging whether the first client is in the call white list or not; and if the first client is not in the call white list, determining whether to check the first client based on the user category of the first client or the call information of the second client, wherein the call information is a historical call record or a call white list. According to the method and the device, whether the first client needs to be checked or not can be further accurately judged on the basis of the user category of the first client or the call information of the second client under the condition that the first client is judged not to be in the call white list of the second client, so that whether the incoming call of the first client is a harassing call or not can be preliminarily judged.

Description

Call request processing method and device
Technical Field
The embodiment of the application relates to the technical field of computers, in particular to the technical field of communication, and particularly relates to a method and a device for processing a call request.
Background
With the development of communication technology, almost everyone can use communication equipment such as a fixed-line telephone or a mobile phone to make a call. More and more users will encounter harassment of strange calls due to leakage of user information and the like.
In order to solve the problem, in the prior art, a user can set interception of strange numbers, so that the strange numbers can be intercepted as long as the strange numbers are dialed, and the user cannot receive calls of the strange numbers.
Disclosure of Invention
A method and a device for processing a call request, an electronic device and a storage medium are provided.
According to a first aspect, a method for processing a call request is provided, which includes: the method comprises the steps that a call white list of a second client side is obtained in response to the fact that a call request of a first client side to the second client side is received; judging whether the first client is in a call white list or not; and if the first client is not in the call white list, determining whether to verify the first client based on the user category of the first client or the call information of the second client, wherein the call information is a historical call record or a call white list.
According to a second aspect, there is provided a device for processing a call request, including: the device comprises an acquisition unit, a processing unit and a processing unit, wherein the acquisition unit is configured to respond to the receiving of a call request of a first client to a second client and acquire a call white list of the second client; a determining unit configured to determine whether the first client is in a call white list; the determining unit is configured to determine whether to check the first client based on the user category of the first client or the call information of the second client if the first client is not in the call white list, wherein the call information is a history call record or a call white list.
According to a third aspect, there is provided an electronic device comprising: one or more processors; a storage device for storing one or more programs which, when executed by one or more processors, cause the one or more processors to implement a method as in any embodiment of a method for processing a call request.
According to a fourth aspect, there is provided a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of any of the embodiments as a method of processing a call request.
According to the scheme of the application, whether the first client needs to be checked or not can be further accurately judged on the basis of the user category of the first client or the call information of the second client under the condition that the first client is judged not to be in the call white list of the second client, so that whether the incoming call of the first client is a harassing call or not can be preliminarily judged.
Drawings
Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:
FIG. 1 is an exemplary system architecture diagram to which some embodiments of the present application may be applied;
FIG. 2 is a flow diagram of one embodiment of a method of processing a call request according to the present application;
FIG. 3 is a schematic diagram of an application scenario of a method of processing a call request according to the present application;
FIG. 4 is a flow diagram of yet another embodiment of a method of processing a call request according to the present application;
FIG. 5 is a block diagram illustrating an embodiment of a device for processing a call request according to the present application;
fig. 6 is a block diagram of an electronic device for implementing a method for processing a call request according to an embodiment of the present application.
Detailed Description
The following description of the exemplary embodiments of the present application, taken in conjunction with the accompanying drawings, includes various details of the embodiments of the application for the understanding of the same, which are to be considered exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.
Fig. 1 shows an exemplary system architecture 100 to which embodiments of the call request processing method or call request processing apparatus of the present application may be applied.
As shown in fig. 1, the system architecture 100 may include terminals 101, 102, a network 104, and a server 103. The network 104 serves as a medium for providing communication links between the terminals 101, 102 and the server 103. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.
A user may use the terminals 101, 102 to interact with the server 103 via the network 104 to receive or send messages or the like. The terminals 101 and 102 may have various communication client applications installed thereon, such as a call application, a live application, an instant messaging tool, a mailbox client, social platform software, and the like.
Here, the terminals 101 and 102 may be hardware or software. When the terminals 101, 102 are hardware, they may be various electronic devices having a display screen, including but not limited to smart phones, tablet computers, e-book readers, laptop portable computers, desktop computers, and the like. When the terminals 101 and 102 are software, they can be installed in the electronic devices listed above. It may be implemented as multiple pieces of software or software modules (e.g., multiple pieces of software or software modules to provide distributed services) or as a single piece of software or software module. And is not particularly limited herein.
The server 103 may be a server providing various services, such as a background server providing support for the terminals 101, 102. The background server may analyze and perform other processing on the received data such as the call request of the terminal 101, and obtain a processing result (e.g., whether to check the first client). In practice, the server may establish a call connection between the terminals 101, 102, i.e. the terminals 101, 102 may be talking via the server 103.
It should be noted that the processing method of the call request provided in the embodiment of the present application may be executed by the server 103, and accordingly, a processing device of the call request may be disposed in the server 103.
It should be understood that the number of terminals, networks, and servers in fig. 1 are merely illustrative. There may be any number of terminals, networks, and servers, as desired for an implementation.
Continuing to refer to FIG. 2, a flow 200 of one embodiment of a method of processing a call request according to the present application is shown. The method for processing the call request comprises the following steps:
step 201, in response to receiving a call request of a first client to a second client, obtaining a call white list of the second client.
In this embodiment, an execution main body (for example, the server shown in fig. 1) on which the processing method of the call request operates may obtain the call white list of the second client in response to receiving the call request of the first client to the second client. The first client and the second client herein may refer to applications having a call function, which are installed on different terminals, respectively, or may refer to different terminals themselves. The call request is generally a request from a client that performs dialing to request a call with another client (such as the second client described above). The call white list of the second client refers to a client list which can be directly connected with the second client. That is, the dialing of the client in the call white list to the second client is not intercepted and the dialing connection is directly realized without verification. Clients in the call white list may be represented by client identifications, such as the client identifications may be telephone numbers. The connection, i.e., dial-up in the present application, means that after sending a call request to another client, the other client rings.
Step 202, determine whether the first client is in the call white list.
In this embodiment, the executing entity may determine whether the first client is in the call white list. That is, the execution subject may determine whether the client identifier of the first client is in the call white list of the second client.
Step 203, if the first client is not in the call white list, determining whether to verify the first client based on the user category of the first client or the call information of the second client, wherein the call information is a history call record or a call white list.
In this embodiment, the execution main body may determine whether to check the first client based on the user category of the first client or based on the call information of the second client when it is determined that the first client is not in the call white list. If the verification is determined, the execution main body verifies the first client, performs dial connection on the two clients after the first client passes the verification, and terminates the process when the first client fails the verification, that is, intercepts the incoming call of the first client. In addition, if it is determined that the verification is not performed, the execution subject may directly perform dial-up connection between the first client and the second client, so as to ring the second client.
In practice, the manner of the above-described verification may be various. For example, the check may be a voice check, for example, the execution body sends a text to be displayed, such as "please speak the name of my company" or "please speak the name of a contact" to the first client, so that the first client displays the text to be displayed. And the user of the first client speaks the reply voice, and the first client uploads the reply voice to the electronic equipment. If the execution subject judges that the reply voice matches the preset text (such as the name of the company or the name of the contact) of the second client, the verification is passed, and if the reply voice does not match, the verification is not passed.
Specifically, the call information may be one of the following: historical call records, call white lists. The history call record refers to a record of dial-up connections between the client and other clients, and specifically may include a record of ringing (turning on) no call and ringing and calling. For example, the execution subject may determine not to check the first client if there is a call log or a connection log with the first client in the history call log of the second client. In addition, the execution subject may also be determined based on a call white list of the second client. For example, if the client in the call white list of the second client has a connection record or a call record with the first client, the executing body may not verify the first client.
The user category refers to a category preset for a user using the client, and may include, for example, a normal category and an abnormal category. For example, a salesperson's client may be classified into an exception category. The execution subject may determine to check the clients classified as the exception category.
The method provided by the embodiment of the application can further and accurately judge whether the first client needs to be checked based on the user category of the first client or based on the call information of the second client under the condition that the first client is not in the call white list of the second client, so as to preliminarily judge whether the incoming call of the first client is a harassing call.
In some optional implementations of this embodiment, the call information is a history call record; the determining whether to check the first client based on the user category of the first client or the call information of the second client in step 203 may include: judging whether a dialing record of the second client to the first client exists in a historical call record of the second client; and if the dialing record of the second client to the first client exists, determining not to verify the first client.
In these optional implementation manners, the execution main body may determine whether a call record from the second client to the first client exists in the historical call record of the second client, and determine not to check the first client if the determination result indicates that the call record exists. In addition, the execution subject may determine to check the first client when the determination result indicates that the first client does not exist, or continuously determine whether to check the first client in another manner. The dialing record here refers to a call request sent by the second client to the first client. A record of a dialed call but not completed call connection, and a record of an already-called call may be included.
The realization modes directly connect the dialing of the client terminal actively dialed by the user of the second client terminal, so that the problem that the call back of the client terminal dialed by the second client terminal is rejected or the call back efficiency is reduced due to verification can be avoided.
In some optional implementations of this embodiment, the call information is a call white list; the determining whether to check the first client based on the user category of the first client or the call information of the second client in step 203 may include: determining each client in a call white list of a second client; judging whether the number of calls between the client and the first client in each client reaches a preset number threshold or not based on the historical call record of the first client; and if the number of calls between the client and the first client in each client reaches a preset number threshold, determining not to check the first client.
In these alternative implementations, the executing entity may determine each client in the call white list of the second client. Then, the execution main body may determine whether the number of times of calls between the client and the first client in each client reaches a preset number threshold. The number of calls can be looked up in the history call log of the first client. And determining not to check if the judgment result is present. In addition, the execution subject may determine to perform the check if the determination result indicates that the first client is absent, or may continue to determine whether to perform the check on the first client in another manner. The preset number threshold may be the preset number threshold set for the number of calls of the second client, or may be another value.
In these implementations, the members of the second client user's call white list are typically people in the same social group as the user, such as people who may be the same work unit. And the frequent contact person of the member is also likely to be in the social group, so that the user, namely the user of the second client, can be contacted with the member with a high probability for normal communication. These implementations may ensure that people in the same social group can contact normally using the frequent contact records of the members in the call white list of the second client.
In some optional implementations of this embodiment, the call information is a call white list; the determining whether to check the first client based on the user category of the first client or the call information of the second client in step 203 may include: determining a call white list of each client for each client in the call white list of the second client; judging whether the first client is in a call white list of any one client of each client; and if the first client is in the call white list of any one client of the clients, determining not to check the first client.
In these optional implementation manners, the execution main body may obtain, for each client in the call white list of the second client, a call white list of each client, and determine whether the first client exists in any one or more white lists of the call white lists. The execution subject may determine not to check the first client if the first client exists, and determine to check the first client or continue to determine whether to check the first client in another manner if the first client does not exist.
In these implementations, the members of the second client user's call white list are typically people in the same social group as the user, such as people who may be the same work unit. And people in the member's call white list are also likely to be in the social group, so there is a high probability that the user, i.e., the user of the second client, will be contacted for normal communication. These implementations may ensure that people in the same social group can contact normally using the call whitelists of the members in the call whitelist of the second client.
In some optional implementations of this embodiment, the determining whether to check the first client based on the user category of the first client or the call information of the second client in step 203 may include: judging whether the user class of the first client is a public service class or not; and if the user class of the first client is determined to be the public service class, determining not to check the first client.
In these optional implementation manners, the execution subject may determine whether the user class of the first client is a public service class, and determine not to check the first client if the determination result is yes. In addition, the execution main body may further determine to check the first client or continue to determine whether to check the first client in another manner if the determination result is negative. Specifically, the user category being the public service category may refer to a person of the client who provides public service for a courier, a bank service person, and the like.
According to the implementation modes, under the condition that the user of the first client is a public service worker, the incoming call of the first client is not considered to be a harassing call, so that the dialing connection is directly performed on the first client without verification, and the dialing connection efficiency is improved.
In some optional implementations of this embodiment, the method may further include: in response to determining that the first client is not verified, or determining that the first client is verified and the first client passes the verification, performing dial-up connection on the first client and the second client; receiving answering operation information of a second client, and communicating a call between the first client and the second client; responding to the call termination, sending confirmation information to the second client to enable the second client to display the confirmation information, wherein the confirmation information is information for confirming whether the first client is added into a call white list of the second client; and if receiving the adding confirmation information fed back by the second client, adding the first client into the call white list of the second client.
In these optional implementation manners, the execution main body may perform dial-up connection on the first client and the second client without checking or passing the checking, and connect the call between the two clients in response to receiving the answering operation information of the second client. The answering operation information here is information generated by the user of the second client. And in case of call termination, the executing body may send confirmation information to the second client so that the user of the second client sees the displayed confirmation information. If the user of the second client performs a confirmation operation on the confirmation information to confirm that the first client is added to the call white list of the second client, the execution main body may add the first client to the call white list of the second client. The execution main body can add the first client to the call white list by adding the client identifier of the first client to the call white list of the second client.
The realization methods can prompt the user of the second client to add the dialed client into the call white list under the condition of realizing the call, which is beneficial to improving the call connection efficiency of the second client and other clients, and in addition, the change possibly generated on the call white list enables the user to confirm, so that the operation of setting the call white list specially by the user can be avoided.
In some optional implementations of this embodiment, the method may further include: in response to the fact that the first client side is verified, sending information to be selected to the first client side to enable the first client side to display the information to be selected, wherein multiple options of the information to be selected are different user attribute information, and one option of the multiple options is user attribute information of a second client side; and in response to receiving the selection information of the user attribute information of the second client, which is fed back by the first client, determining that the first client passes the verification.
In these alternative implementations, the execution subject may verify the first client by using the user attribute information of the second client. Specifically, the execution main body sends information to be selected with a plurality of options to the first client, where one option is user attribute information of the second client, and the other options are not user attribute information. If the user of the first client selects the user attribute information of the second client, and then the first client feeds back the selection information to the execution main body, the first client can pass the verification. The user attribute information may be various information about user attributes, such as the name, work unit, and/or customer premises of the user, and the like.
As shown in fig. 3, the information to be selected may include "please select the name of the user", "zhang san", "li si", "wang wu", and "zhao liu". Wherein the name of the user of the second client is "Zhang III". If the user of the first client clicks "Zhang III", the first client may pass the check.
The realization modes can give a prompt to the user of the first client in a selection mode, so that the situation that the user of the first client cannot pass the verification due to forgetting and the like is avoided, and the recall rate of the verification is improved.
With further reference to fig. 4, a flow 400 of yet another embodiment of a method of processing a call request is shown. The process 400 includes the following steps:
step 401, in response to receiving a call request of a first client to a second client, obtaining a call white list of the second client.
In this embodiment, an execution main body (for example, the server shown in fig. 1) on which the processing method of the call request operates may obtain the call white list of the second client in response to receiving the call request of the first client to the second client. The first client and the second client herein may refer to applications having a call function, which are installed on different terminals, respectively, or may refer to different terminals themselves.
Step 402, determine whether the first client is in the call white list.
In this embodiment, the executing entity may determine whether the first client is in the call white list. That is, the execution subject may determine whether the client identifier of the first client is in the call white list of the second client.
Step 403, if the first client is not in the call white list, determining whether the number of calls between the first client and the second client in the historical call record of the second client reaches a preset number threshold, where the preset number threshold is greater than or equal to two times.
In this embodiment, the call information is a history call record. The execution main body may determine whether the number of calls between the first client and the second client in the history call record of the second client reaches a preset number threshold under the condition that the first client is not in the call white list. Specifically, the number of calls herein may refer to the number of rings and put through, or the number of calls may also refer to the total number of times a dial-up connection is made but not put through and made through. The preset number threshold may be any preset number, such as two, or a number greater than two, such as three, etc.
In step 404, if the number of times of calls between the first client and the second client reaches a preset number threshold, it is determined that the first client is not verified.
In this embodiment, if the determination result is that the number of times of call between the first client and the second client reaches the preset number threshold, the execution main body may determine not to check the first client, and directly perform dial-up connection between the first client and the second client.
Step 405, if the number of times of calls between the first client and the second client does not reach the preset number threshold, it is determined that the first client is verified.
In this embodiment, if the determination result is that the number of times of calls between the first client and the second client does not reach the preset number threshold, the execution main body may determine to verify the first client. And under the condition that the verification is passed, dial-up connection is carried out on the first client and the second client. And terminating the dialing process if the verification fails.
According to the implementation methods, under the condition that the number of calls between the first client and the second client in the historical call records is large, the first client is considered to be a normal user rather than a harassing user, and therefore the normal call request of the first client is prevented from being rejected.
With further reference to fig. 5, as an implementation of the methods shown in the above-mentioned figures, the present application provides an embodiment of a device for processing a call request, where the embodiment of the device corresponds to the embodiment of the method shown in fig. 2, and besides the features described below, the embodiment of the device may further include the same or corresponding features or effects as the embodiment of the method shown in fig. 2. The device can be applied to various electronic equipment.
As shown in fig. 5, the processing apparatus 500 for a call request of the present embodiment includes: an acquisition unit 501, a judgment unit 502, and a determination unit 503. The obtaining unit 501 is configured to, in response to receiving a call request of a first client to a second client, obtain a call white list of the second client; a determining unit 502 configured to determine whether the first client is in a call white list; a determining unit 503 configured to determine whether to check the first client based on the user category of the first client or the call information of the second client if the first client is not in the call white list, wherein the call information is a history call record or a call white list.
In this embodiment, specific processing of the obtaining unit 501, the determining unit 502, and the determining unit 503 of the device 500 for processing a call request and technical effects brought by the specific processing can refer to related descriptions of step 201, step 202, and step 203 in the corresponding embodiment of fig. 2, which are not described herein again.
In some optional implementations of this embodiment, the call information is a history call record; the determining unit 503 is further configured to perform determining whether to check the first client according to the user category of the first client or the call information of the second client as follows: judging whether the call times of the first client and the second client in the historical call record of the second client reach a preset time threshold value, wherein the preset time threshold value is more than or equal to two times; if the number of calls between the first client and the second client reaches a preset number threshold, determining not to verify the first client; and if the number of times of the calls between the first client and the second client does not reach a preset number threshold, determining to verify the first client.
In some optional implementations of this embodiment, the call information is a history call record; the determining unit 503 is further configured to perform determining whether to check the first client according to the user category of the first client or the call information of the second client as follows: judging whether a dialing record of the second client to the first client exists in a historical call record of the second client; and if the dialing record of the second client to the first client exists, determining not to verify the first client.
In some optional implementations of the embodiment, the determining unit 503 is further configured to perform determining whether to check the first client according to the user category of the first client or the call information of the second client as follows: judging whether the user class of the first client is a public service class or not; and if the user class of the first client is determined to be the public service class, determining not to check the first client.
In some optional implementations of this embodiment, the call information is a call white list; the determining unit 503 is further configured to perform determining whether to check the first client according to the user category of the first client or the call information of the second client as follows: determining each client in a call white list of a second client; judging whether the number of calls between the client and the first client in each client reaches a preset number threshold or not based on the historical call record of the first client; and if the number of calls between the client and the first client in each client reaches a preset number threshold, determining not to check the first client.
In some optional implementations of this embodiment, the call information is a call white list; the determining unit 503 is further configured to perform determining whether to check the first client according to the user category of the first client or the call information of the second client as follows: determining a call white list of each client for each client in the call white list of the second client; judging whether the first client is in a call white list of any one client of each client; and if the first client is in the call white list of any one client of the clients, determining not to check the first client.
In some optional implementations of this embodiment, the apparatus further includes: a dial-up unit configured to perform a dial-up connection for the first client and the second client in response to determining that the first client is not verified or that the first client is verified and passes the verification; the call unit is configured to receive answering operation information of the second client and communicate the call of the first client and the second client; a confirmation unit configured to send confirmation information to the second client in response to the call termination so as to cause the second client to display the confirmation information, wherein the confirmation information is information confirming whether to add the first client to a call white list of the second client; and the joining unit is configured to join the first client into the call white list of the second client if the joining confirmation information fed back by the second client is received.
In some optional implementations of this embodiment, the apparatus further includes: the sending unit is configured to respond to the determination that the first client is verified, and send information to be selected to the first client so that the first client can display the information to be selected, wherein multiple options of the information to be selected are different user attribute information, and one option of the multiple options is user attribute information of a second client; and the feedback unit is configured to respond to the received selection information of the user attribute information of the second client, which is fed back by the first client, and determine that the first client passes the verification.
According to an embodiment of the present application, an electronic device and a readable storage medium are also provided.
As shown in fig. 6, the electronic device is a block diagram of an electronic device according to a processing method of a call request in an embodiment of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present application that are described and/or claimed herein.
As shown in fig. 6, the electronic apparatus includes: one or more processors 601, memory 602, and interfaces for connecting the various components, including a high-speed interface and a low-speed interface. The various components are interconnected using different buses and may be mounted on a common motherboard or in other manners as desired. The processor may process instructions for execution within the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input/output apparatus (such as a display device coupled to the interface). In other embodiments, multiple processors and/or multiple buses may be used, along with multiple memories and multiple memories, as desired. Also, multiple electronic devices may be connected, with each device providing portions of the necessary operations (e.g., as a server array, a group of blade servers, or a multi-processor system). In fig. 6, one processor 601 is taken as an example.
The memory 602 is a non-transitory computer readable storage medium as provided herein. The memory stores instructions executable by the at least one processor, so that the at least one processor executes the processing method of the call request provided by the application. The non-transitory computer-readable storage medium of the present application stores computer instructions for causing a computer to execute the processing method of a call request provided by the present application.
The memory 602, which is a non-transitory computer-readable storage medium, may be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as program instructions/modules corresponding to the processing method of the call request in the embodiment of the present application (for example, the acquisition unit 501, the judgment unit 502, and the determination unit 503 shown in fig. 5). The processor 601 executes various functional applications and data processing of the server by running non-transitory software programs, instructions and modules stored in the memory 602, that is, implementing the processing method of the call request in the above method embodiment.
The memory 602 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created from use of the processing electronic device of the call request, and the like. Further, the memory 602 may include high speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory 602 may optionally include memory located remotely from the processor 601, which may be connected to the call request processing electronics over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The electronic device of the processing method of the call request may further include: an input device 603 and an output device 604. The processor 601, the memory 602, the input device 603 and the output device 604 may be connected by a bus or other means, and fig. 6 illustrates the connection by a bus as an example.
The input device 603 may receive input numeric or character information and generate key signal inputs related to user settings and function control of the processing electronics of the call request, such as an input device like a touch screen, a keypad, a mouse, a track pad, a touch pad, a pointer stick, one or more mouse buttons, a track ball, a joystick, etc. The output devices 604 may include a display device, auxiliary lighting devices (e.g., LEDs), and tactile feedback devices (e.g., vibrating motors), among others. The display device may include, but is not limited to, a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, and a plasma display. In some implementations, the display device can be a touch screen.
Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, application specific ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.
These computer programs (also known as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.
To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.
The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units described in the embodiments of the present application may be implemented by software or hardware. The described units may also be provided in a processor, and may be described as: a processor includes an acquisition unit, a judgment unit, and a determination unit. The names of these units do not in some cases form a limitation on the unit itself, and for example, the determination unit may also be described as "unit that determines whether the first client is in the call white list".
As another aspect, the present application also provides a computer-readable medium, which may be contained in the apparatus described in the above embodiments; or may be present separately and not assembled into the device. The computer readable medium carries one or more programs which, when executed by the apparatus, cause the apparatus to: the method comprises the steps that a call white list of a second client side is obtained in response to the fact that a call request of a first client side to the second client side is received; judging whether the first client is in a call white list or not; and if the first client is not in the call white list, determining whether to verify the first client based on the user category of the first client or the call information of the second client, wherein the call information is a historical call record or a call white list.
The above description is only a preferred embodiment of the application and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention herein disclosed is not limited to the particular combination of features described above, but also encompasses other arrangements formed by any combination of the above features or their equivalents without departing from the spirit of the invention. For example, the above features may be replaced with (but not limited to) features having similar functions disclosed in the present application.

Claims (10)

1. A method for processing a call request, the method comprising:
the method comprises the steps that a call white list of a second client side is obtained in response to the fact that a call request of the first client side to the second client side is received;
judging whether the first client is in the call white list or not;
and if the first client is not in the call white list, determining whether to verify the first client based on the user category of the first client or the call information of the second client, wherein the call information is a historical call record or a call white list.
2. The method of claim 1, wherein the call information is the historical call record; the determining whether to verify the first client based on the user category of the first client or the call information of the second client includes:
judging whether the call times of the first client and the second client in the historical call record of the second client reach a preset time threshold value, wherein the preset time threshold value is greater than or equal to two times;
if the number of times of calls between the first client and the second client reaches a preset number threshold, determining not to verify the first client;
and if the number of times of the calls between the first client and the second client does not reach a preset number threshold, determining to verify the first client.
3. The method of claim 1, wherein the call information is the historical call record; the determining whether to verify the first client based on the user category of the first client or the call information of the second client includes:
judging whether a dialing record of the second client to the first client exists in a historical call record of the second client;
and if the dialing record of the second client to the first client exists, determining not to check the first client.
4. The method of claim 1, wherein the determining whether to check the first client based on the user category of the first client or the call information of the second client comprises:
judging whether the user class of the first client is a public service class or not;
and if the user class of the first client is determined to be the public service class, determining not to check the first client.
5. The method of claim 1, wherein the call information is the call white list; the determining whether to verify the first client based on the user category of the first client or the call information of the second client includes:
determining each client in the call white list of the second client;
judging whether the number of calls between the client and the first client in each client reaches a preset number threshold or not based on the historical call record of the first client;
and if the number of times of calls between the client and the first client in each client reaches a preset number threshold, determining not to verify the first client.
6. The method of claim 1, wherein the call information is the call white list; the determining whether to verify the first client based on the user category of the first client or the call information of the second client includes:
determining a call white list of each client for each client in the call white list of the second client;
judging whether the first client is in a call white list of any one client of the clients;
and if the first client is in the call white list of any one client of the clients, determining not to verify the first client.
7. The method according to one of claims 1-6, wherein the method further comprises:
in response to determining that the first client is not verified, or determining that the first client is verified and the first client passes the verification, performing dial-up connection on the first client and the second client;
receiving answering operation information of the second client, and communicating the call between the first client and the second client;
responding to the call termination, sending confirmation information to the second client to enable the second client to display the confirmation information, wherein the confirmation information is information for confirming whether the first client is added to a call white list of the second client;
and if receiving the adding confirmation information fed back by the second client, adding the first client into the call white list of the second client.
8. The method according to one of claims 1-6, wherein the method further comprises:
in response to determining that the first client is verified, sending information to be selected to the first client, so that the first client displays the information to be selected, wherein multiple options of the information to be selected are different user attribute information, and one option of the multiple options is user attribute information of the second client;
and determining that the first client passes the verification in response to receiving the selection information of the user attribute information of the second client, which is fed back by the first client.
9. An electronic device, comprising:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-8.
10. A computer-readable storage medium, on which a computer program is stored, which program, when being executed by a processor, carries out the method according to any one of claims 1-8.
CN202010494970.7A 2020-06-03 2020-06-03 Call request processing method and device Active CN111654574B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010494970.7A CN111654574B (en) 2020-06-03 2020-06-03 Call request processing method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010494970.7A CN111654574B (en) 2020-06-03 2020-06-03 Call request processing method and device

Publications (2)

Publication Number Publication Date
CN111654574A true CN111654574A (en) 2020-09-11
CN111654574B CN111654574B (en) 2021-12-28

Family

ID=72343302

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010494970.7A Active CN111654574B (en) 2020-06-03 2020-06-03 Call request processing method and device

Country Status (1)

Country Link
CN (1) CN111654574B (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102223431A (en) * 2011-06-27 2011-10-19 杨子江 Method and system for preventing harassment call
CN105376426A (en) * 2014-08-25 2016-03-02 宇龙计算机通信科技(深圳)有限公司 Information management method based on address book and mobile terminal
CN109889647A (en) * 2019-03-21 2019-06-14 深圳市趣创科技有限公司 A kind of harassing call processing method and processing device
CN110233940A (en) * 2019-07-17 2019-09-13 上海尊源通讯技术有限公司 It is a kind of to establish call white list library system automatically for user
CN110290276A (en) * 2019-07-16 2019-09-27 深圳传音控股股份有限公司 Method, mobile terminal and the storage medium of interruption-free white list is added in application

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102223431A (en) * 2011-06-27 2011-10-19 杨子江 Method and system for preventing harassment call
CN105376426A (en) * 2014-08-25 2016-03-02 宇龙计算机通信科技(深圳)有限公司 Information management method based on address book and mobile terminal
CN109889647A (en) * 2019-03-21 2019-06-14 深圳市趣创科技有限公司 A kind of harassing call processing method and processing device
CN110290276A (en) * 2019-07-16 2019-09-27 深圳传音控股股份有限公司 Method, mobile terminal and the storage medium of interruption-free white list is added in application
CN110233940A (en) * 2019-07-17 2019-09-13 上海尊源通讯技术有限公司 It is a kind of to establish call white list library system automatically for user

Also Published As

Publication number Publication date
CN111654574B (en) 2021-12-28

Similar Documents

Publication Publication Date Title
US8849348B2 (en) Mobile device session switching
US8451995B2 (en) User status management in a voice calling architecture
US20100293247A1 (en) Application of social networking data
US20080148154A1 (en) Dynamic information publication enabling direct access to a preferred communication channel connection in integrated communication server
US10225397B2 (en) Caller relationship and risk assessment
US9160846B2 (en) Electronic system and method for screening incoming communications
US9888118B2 (en) Enterprise application integration on client computing devices
CN105262881A (en) Communication control method and electronic equipment
CN112307357A (en) Social method and device for strangers
US11711468B2 (en) Apparatus and method for accessing contact lists on an electronic device that is unavailable or unusable
US20240056528A1 (en) Voice Message Callback Action Enabling and Disabling
US20230300092A1 (en) Multichannel messaging system and method
US9058586B2 (en) Identification of a person located proximite to a contact identified in an electronic communication client
CN111654574B (en) Call request processing method and device
US9467565B2 (en) Supervisory communication system
US8996613B2 (en) Automated activity creation in a mobile device business application
US8320367B1 (en) Transitioning telephone from guest mode to custom mode based on logging in to computing system
US9277015B1 (en) Communication sequences based on user rules
US10992778B2 (en) Callee condition based communication with mobile devices
US20170012919A1 (en) Method and device for prioritizing messages based on based on originating time zone
US9622043B2 (en) Past location-based communication with mobile devices
US11785060B2 (en) Content-aware device selection for modifying content elements in digital collaboration spaces
KR101528419B1 (en) Communication convergence service providing method and system of personal computer and phone diveces
CN113286046A (en) Method, apparatus, and computer storage medium for information processing
CN115880055A (en) Abnormal transaction event processing method and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant