Incoming call processing method and apparatus, electronic device, and storage medium

Abstract

The present application provides an incoming call processing method and apparatus, an electronic device, and a storage medium. The incoming call processing method comprises: when a call request is detected, executing a first incoming call alert; and when it is detected that a called user inputs a paid answering operation for the first incoming call alert, executing a paid answering process, wherein the paid answering process comprises: when payment confirmation information corresponding to a calling number is detected, answering an incoming call or triggering a second incoming call alert. The second incoming call alert can be triggered or the incoming call can be answered only when the calling user pays a fee, and if the calling user is unwilling to pay a fee, the second incoming call alert would not be triggered or the incoming call would not be answered; therefore, interception of some calls can be realized, thereby effectively reducing the incoming call alert count and the actual call volume of harassing calls; in addition, answering harassing calls can bring additional economic compensation to the called user, thereby effectively alleviating the negative emotion of the called user answering a harassing call, and improving the use experience of the user.

Description

Incoming call processing method and device, electronic equipment and storage medium TECHNICAL FIELD

[0001] The present application relates to the technical field of electronic communication, in particular to an incoming call processing method and device, electronic equipment and storage medium. BACKGROUND

[0002] In modern communication technology, mobile phones have become an indispensable part of people's daily life. With the popularity of smart phones, users are facing an increasingly serious problem of nuisance calls, and a large number of nuisance calls such as sales promotion and fraud have brought great trouble to people's life.

[0003] Although many applications and mobile phone manufacturers provide nuisance call interception functions, the existing nuisance call interception functions rely on marking of nuisance calls, but this method has a large lag, and a certain number of users need to answer the nuisance calls, and then the cloud data is marked or manually marked by the user, which can only work after that. This part of the users are still victims of nuisance calls, and many users are not willing to mark, which leads to a larger number of actual victims, and the calling users of the nuisance calls also develop new numbers to avoid being marked and intercepted. The above factors lead to a large number of unmarked nuisance calls in actual application. For these nuisance calls, users often cannot judge whether they are nuisance calls before answering, and can only understand the intention of the other party after answering, which not only wastes the time and energy of the users, but also may cause unnecessary annoyance and risk.

[0004] Therefore, it is necessary to provide a technical solution that can reduce the negative impact of nuisance calls on users. SUMMARY

[0005] The purpose of the embodiments of the present application is to provide an incoming call processing method, device, electronic equipment and storage medium to solve the problem of frequent nuisance calls negatively affecting users.

[0006] One or more embodiments of the first aspect of the present application provide an incoming call processing method, comprising: in the case of detecting a call request, performing a first incoming call reminder; in the case of detecting that a called user inputs a paid call operation for the first incoming call reminder, performing a paid call process, the paid call process comprising connecting the incoming call or triggering a second incoming call reminder after detecting payment confirmation information corresponding to the calling number.

[0007] The second aspect of the present application provides a call processing device, comprising: a first call reminding module, configured to perform a first call reminding when a call request is detected; a paid answering performing module, configured to perform a paid answering process when a paid answering operation input by a called user is detected in response to the first call reminding, the paid answering process comprising connecting the call or triggering a second call reminding when payment confirmation information corresponding to a calling number is detected.

[0008] The third aspect of the present application provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method of the first aspect of the present application.

[0009] The fourth aspect of the present application provides a computer readable storage medium, having stored thereon computer readable instructions executable by a processor to implement the method of the first aspect of the present application.

[0010] The fifth aspect of the present application provides a computer program product, comprising computer programs or instructions for implementing the method of the first aspect of the present application.

[0011] The first aspect of the present application provides a call processing method. The first call reminder is executed when a call request is detected, and the paid call answering process is executed when the called user inputs a paid call answering operation for the first call reminder. The paid call answering process includes connecting the call or triggering a second call reminder when payment confirmation information corresponding to the calling number is detected. The paid call answering process can improve the call answering threshold of the calling number. The second call reminder or the call is connected only when the calling user pays the fee. The second call reminder or the call is not connected when the calling user does not want to pay the fee. Therefore, the present application can intercept some calls, effectively reduce the number of call reminders and actual calls of the harassment calls, and effectively alleviate the negative emotions of the called user when answering the harassment calls, thereby improving the user experience. In addition, the first call reminder is executed first when the call request is detected, and the called user decides whether to execute the paid call answering process. The called user can decide whether to perform the paid call answering process for each incoming call in real time. Therefore, the called user can decide the processing method of each incoming call according to the user's will, and the called user has greater freedom. The processing of each incoming call can meet the needs of the called user. In addition, the paid call answering process is executed according to the paid call answering operation input by the called user. Therefore, the paid call answering process is executed when the called user knows the call and can answer the call. In this case, the calling user has a high probability of being successfully answered after paying the call answering fee. The probability of the calling user paying the call answering fee but not being answered can be reduced. The resource waste caused by unnecessary paid call answering and refund process can be reduced. Therefore, the resource utilization rate and the call fluency are improved as a whole, thereby improving the calling experience of the calling user and the answering experience of the called user.

[0012] The call processing device provided by the second aspect of the present application, the electronic device provided by the third aspect of the present application, the computer readable storage medium provided by the fourth aspect of the present application, and the computer program product provided by the fifth aspect of the present application are based on the same inventive concept as the call processing method provided by the first aspect of the present application, and have the same or corresponding beneficial effects. BRIEF DESCRIPTION OF DRAWINGS

[0013] The above and other objects, features and advantages of the present application will become readily apparent from the detailed description that follows, read in conjunction with the accompanying drawings. In the drawings, several embodiments of the present application are illustrated by way of example and not limitation, in which like reference numerals indicate like or corresponding parts, wherein:

[0014] FIG. 1 schematically illustrates a first framework diagram of a call processing system according to some embodiments of the present application; FIG. 2 schematically illustrates a second framework diagram of a call processing system according to some embodiments of the present application; FIG. 3 schematically illustrates a third framework diagram of a call processing system according to some embodiments of the present application; FIG. 4 schematically illustrates a fourth framework diagram of a call processing system according to some embodiments of the present application; FIG. 5 schematically illustrates a flow diagram of a call processing method according to some embodiments of the present application; FIG. 6 schematically illustrates a diagram of a call processing apparatus according to some embodiments of the present application; and FIG. 7 schematically illustrates a diagram of an electronic device according to some embodiments of the present application. DETAILED DESCRIPTION

[0015] Exemplary embodiments of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. While example embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be embodied in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and fully convey the scope of the present disclosure to those skilled in the art.

[0016] It should be noted that the technical terms or scientific terms used in the present application should be the general meanings understood by the skilled in the art unless otherwise specified. The terms used in the embodiments of the present application are merely for the purpose of describing specific embodiments and are not intended to limit the present application. The singular forms "a", "an" and "the" used in the embodiments of the present application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. "Plural" generally includes at least two, but does not exclude the case of including at least one. "At least one" means one or more, "multiple" means two or more, and "at least two" means two or three or more. "And / or" is used to describe the relationship between the associated objects, which means that there can be three relationships, for example, "A and / or B" can represent three cases: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects. "At least one of the following" or the like means any combination of these items. For example, at least one of a, b or c can mean a, b, c, "a and b", "a and c", "b and c", or "a and b and c". In addition, the terms "first" and "second" are used to distinguish different objects, and are not intended to limit the size, content, order, timing, priority or importance of the plurality of objects. Furthermore, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps, units or elements is not limited to the listed steps, units or elements, but optionally includes steps, units or elements that are not listed, or optionally includes other steps, units or elements inherent to the process, method, product or device.

[0017] In view of the problem that the existing technology has poor effect on intercepting harassment calls, resulting in that users are frequently affected by harassment calls, embodiments of the present application provide a call processing method, device, equipment, computer program product and computer readable storage medium to solve the problem that users are frequently affected by harassment calls, and the main technical concept is to process calls by constructing a paid call answering scheme through technical means, for example, in the case of detecting a call request, performing a first call reminder, in the case of detecting that a called user inputs a paid call answering operation for the first call reminder, performing a paid call answering process, and the paid call answering process includes connecting the call or triggering a second call reminder after detecting payment confirmation information corresponding to the calling number, based on the paid call answering scheme, the calling user can be restricted to promise or complete payment of a certain call answering fee to the called user before triggering the second call reminder or connecting the call to remind the called user to answer the call, thereby improving the call answering threshold of the called number and providing the called user with additional economic compensation for answering the call. Since calls that do not want to pay the answering fee will not disturb the called user, calls that are willing to pay the answering fee can provide economic compensation for the called user, so the negative emotions of the called user in answering harassment calls can be effectively alleviated, and the user experience is improved. In addition, the present scheme first performs the first call reminder after detecting the call request, and the called user decides whether to perform the paid call answering process, so that the called user can decide in real time whether to perform paid call answering for each incoming call, so that the called user can decide the processing method of each incoming call according to the will, and the called user has greater freedom, and each incoming call can meet the needs of the called user. In addition, since the paid call answering process is executed according to the paid call answering operation input by the called user, the paid call answering process is executed when the called user knows the call and can answer the call. Under this condition, the calling user has a high probability of being successfully answered after paying the call answering fee, which can reduce the probability of the calling user paying the call answering fee but not being answered, reduce the resource waste caused by unnecessary paid call answering and refund process, thereby improving the resource utilization and call fluency, and further improving the calling experience of the calling user and the answering experience of the called user.

[0018] It should be noted that one of the technical concepts embodied in the paid call answering in the embodiments of the present application is to trigger the call reminder of the called terminal after the calling user (promising or actually completing) pays a certain fee to the called user, so as to achieve the purposes of anti-harassment and paid call answering. Therefore, the paid call answering involved in the embodiments of the present application can also be called fee-based call answering, paid call answering, paid reminder, fee-based reminder, paid reminder, paid ringing, fee-based ringing, and paid ringing. All the above are equivalent concepts, and their essence is to represent the technical concept of triggering the call reminder of the called terminal after the calling user (promising or actually completing) pays a certain fee to the called user. Correspondingly, the fee paid by the calling user to the called user in order to trigger the call reminder of the called terminal can be called call answering fee, ringing fee, ringing fee, reminder fee, compensation fee, etc., and the meanings expressed by them are essentially the same. Based on the above description, as long as it is in the same case as the inventive concept of the present application, no matter what name or concept its specific implementation is, it should be within the protection scope of the present application.

[0019] It should be noted that the call answering fee provided by the embodiments of the present application is different from the existing call fee. In the prior art, the call fee refers to the fee paid by the user to the telecom operator when using a mobile phone, a fixed phone or other communication services, which is different from the call answering fee paid by the present application to the called user. The payment object, payment purpose and role of the two are different, and they belong to completely different technical concepts, which should be strictly distinguished and not confused.

[0020] The system architecture corresponding to the embodiments of the present application will be exemplarily described below with reference to FIGS. 1 to 4.

[0021] As shown in FIG. 1, it schematically shows the first framework diagram of the call processing system provided by some embodiments of the present application. The calling user uses the calling terminal to initiate a call to the called terminal used by the called user, and the call is implemented by sending a call request to the called terminal through the telecom network. The called terminal can execute the first call reminder when detecting the call request, and execute the paid call answering process when detecting that the called user inputs the paid call answering operation for the first call reminder. The paid call answering process includes connecting the incoming call or triggering the second call reminder after detecting the payment confirmation information corresponding to the calling number.

[0022] In addition, please refer to FIG. 2, which schematically shows a second framework diagram of the call processing system provided by some embodiments of the present application, which adds a service end in communication connection with the called terminal on the basis of the first framework diagram, which is used to provide service support for the called terminal to implement paid answering, such as intelligent voice interaction, payment information query and various backend service support, so as to facilitate the called terminal to smoothly execute the paid answering process. In addition, for the case of selective paid answering of the calling number, the service end can further provide backend service support such as number category query and incoming call number identification model identification, so that the first application program can determine whether to perform paid answering according to the number category of the calling number, whether the calling number is identified by the preset incoming call number identification model and other information such as whether the number needs to be paid, and if paid answering is needed, the first incoming call reminder is executed, and if paid answering is not needed, the normal answering process is executed.

[0023] In addition, please refer to FIG. 3, which schematically shows a third framework diagram of the call processing system provided by some embodiments of the present application, which adds the communication connection between the calling terminal and the service end on the basis of the second framework diagram, and the second application program corresponding to the first application program is installed on the calling terminal, so that the service end can also provide service support for the calling terminal, such as convenient payment, non-contact payment, automatic payment, call query before payment and other service support, so that the calling user can initiate a call more conveniently, which helps to improve the smoothness of the call and thus improve the user experience of the calling user. The system architecture has slightly higher requirements for the hardware and software of the calling terminal, and requires the calling terminal to install the second application program, but can realize more rich paid answering functions.

[0024] Please refer to FIG. 4, which schematically shows a fourth framework diagram of the call processing system provided by some embodiments of the present application, which adds a payment device on the basis of the third framework diagram, and the call is still initiated by the calling terminal, but the payment of the answering fee is realized by the payment device. This system architecture is suitable for the case that the calling terminal does not have payment capability, the calling user needs other users or units to pay, etc. The payment device can install the second application program or not, as long as it has payment function and can realize the payment of the answering fee. The system architecture has lower requirements for the hardware and software of the calling terminal, and the payment of the answering fee is realized through the payment device, which can ensure that the calling user realizes smooth calling in the paid answering scenario through the payment function, and the called user can also realize more rich paid answering functions.

[0025] It should be noted that in the above description of FIG. 1 to FIG. 4, the call can be implemented through a telecommunications network, for example, through a traditional telephone network (PSTN, Public Switched Telephone Network), a next-generation network (NGN) or a mobile telephone network, etc., which is a more commonly used telephone communication method at present, but in actual application, the call and incoming call involved in the embodiments of the present application can also be implemented through an Internet link, for example, a voice chat call service (the corresponding call request is also called a voice chat invitation, a video chat invitation) implemented through a voice over Internet protocol (VoIP) based on an Internet protocol, etc., which is also applicable to the technical solutions provided in the embodiments of the present application and is within the protection scope of the present application.

[0026] In the following embodiment description, the above system architecture is mainly used for example-based description, so when reading the following various embodiments, the above system architecture can be reasonably selected and referred to for understanding, but it should be noted that the above system architecture is only an example given for the purpose of understanding, and actual application scenarios are varied and cannot be exemplified one by one. Those skilled in the art can make reasonable changes on the basis of the examples of the present application, and they should be within the protection scope of the present application without departing from the main idea of the present application.

[0027] In the embodiments of the present application, the calling terminal and the called terminal can be any electronic device with voice communication function, which can be a mobile terminal or a fixed terminal, such as a mobile phone, a fixed phone, a smart watch, a tablet computer, a vehicle-mounted terminal (smart car machine), smart glasses, etc. The server in the present embodiment can cover various forms of computing resources, including but not limited to network hosts, network servers, network server clusters or computer sets based on cloud computing. According to specific needs, the server can exist in the form of a single or multiple entities, which can be further divided into multiple more specific functional entities or functional modules according to business or function to optimize business processing and improve system efficiency. For example, it can include multiple servers, virtual servers or server clusters for processing different businesses, for example, a dedicated management server can be set up for better management of user account information; a dedicated database server can be configured for efficient storage and retrieval of user data; a credit management server can be deployed for accurate management of user call credit information; a payment business server can be set up for safe and convenient payment function; an artificial intelligence server can be introduced for intelligent speech recognition and synthesis service; an authentication business server can be built for security and reliability of user authentication, etc. The above various servers belong to the server.

[0028] Through this layered architecture and the division of functions of the service end, different business needs and technical challenges can be more flexibly responded to, and each specific service end focuses on a specific task, thereby improving the response speed and stability of the entire system. For example, the management server is responsible for handling all operations related to user accounts, such as registration, login, personal information update, etc., to ensure the integrity and consistency of user data; the database server focuses on efficient data storage and fast query, supporting the management and analysis of large-scale data sets; the credit management server is used to evaluate and maintain the call credit record of users, providing reliable support for paid call services; the payment business server integrates multiple payment gateways and security protocols to ensure the safety and transparency of the transaction process; the artificial intelligence server uses advanced algorithms and technologies to provide intelligent voice interaction experience for users; the authentication business server strictly verifies the identity of users to ensure the security and privacy protection of the system. Various service ends can work together to provide a smooth and secure communication experience for calling users and called users. It should be noted that the specific architecture of the service end is not limited in the embodiments of the present application, as the implementation schemes of the service end are diverse and cannot be listed one by one, and those skilled in the art can flexibly set the service end according to actual needs, as long as it is based on the technical concept provided by the embodiments of the present application, executes the method steps provided by the embodiments of the present application, and is used to achieve the purpose of the embodiments of the present application, which should be within the protection scope of the present application.

[0029] It can be understood that the calling terminal and the called terminal, the calling user and the called user, the calling number and the called number, etc. are divided according to the roles played in the call. In a call process, the party initiating the call request is called the calling terminal, the calling user and the calling number, and the party receiving the call request is called the called terminal, the called user and the called number. This division method is not only applicable to communication between mobile phones, but also applicable to communication between fixed phones (landline) and mobile phones, and any other form of voice or data communication.

[0030] As shown in FIG. 5, the incoming call processing method provided by the embodiments of the present application can include the following steps S101-S102:

[0031] Step S101: When a call request is detected, a first incoming call reminder is performed.

[0032] In some embodiments of the present embodiment, the execution subject of the incoming call processing method can be a called terminal, or a first application installed on the called terminal, or a combination of the called terminal, the first application and a server. The first application includes but is not limited to a call application, an auxiliary application (for example, a smart call assistant) having an auxiliary function for the call application, or other applications having a call function. The first application can be a system application or a third-party application, which aims to reduce nuisance calls and reduce the negative impact of nuisance calls on called users by providing a paid call answering function. The called terminal can realize the paid call answering function by installing the first application. In addition, in some alternative embodiments, the called terminal also needs to cooperate with the server to jointly realize the incoming call processing method provided in the present embodiment. In the present embodiment, the paid call answering function is mainly realized by installing a first call application on the called terminal, and the first call application is any application program having a call function.

[0033] The call request refers to a request initiated by a calling terminal to attempt to establish a call connection with a called terminal. The call request reaches the called terminal after being forwarded by various intermediate devices in a telecommunications network or the Internet. After the called terminal detects the call request, the first incoming call reminder can be executed.

[0034] Step S102: In the case where the called user inputs a paid call answering operation in response to the first incoming call reminder, a paid call answering process is executed, which includes connecting the incoming call or triggering a second incoming call reminder after detecting payment confirmation information corresponding to the calling number.

[0035] The paid call answering operation is an operation in which the called user selectively requires the calling user to pay a call answering fee to complete the call connection in order to screen or control the incoming call. After the called terminal detects the call request and issues the first incoming call reminder, if the called user is interested in the incoming call but wants the calling user to bear the call answering fee, the called user can input the paid call answering operation to trigger the paid call answering process.

[0036] The paid call answering process refers to a series of steps executed to achieve the paid call answering function. It includes at least triggering a second call notification or connecting the call after detecting payment confirmation information corresponding to the caller's number. The payment confirmation information can be payment confirmation information for the call to a first account, which is the account corresponding to the called user using the called terminal, i.e., the called user account. This first account can be bound to the called number, thereby ensuring that the called user receives appropriate financial compensation before triggering the second call notification or connecting the call. Furthermore, the payment confirmation information can be generated by the called terminal based on payment status or promised payment status, or it can be generated by the server based on payment status or promised payment status and then sent to the called terminal; both methods can achieve the purpose of this application embodiment.

[0037] Considering that in practical applications, in order to protect the rights and interests of both the caller and the called party, the caller can first pay the call fee to an intermediary account on a payment platform (which may be one of the service platforms provided by the server). After the called party answers the call, the call fee is transferred in full or in part (the server takes a service fee, so it is a partial transfer) to the called party's account. In this case, although the call fee is paid to the called party's account in two stages, from the caller's perspective, the purpose of the payment is still to pay the called party. From the called party's perspective, the call fee received still comes from the caller. Therefore, even if the payment record shows that the caller made a payment to the intermediary account and the called party received payment from the intermediary account, as long as it is essentially consistent with the inventive concept of this application, it should still be regarded as an equivalent technical means of this application and is also within the scope of protection of this application. In this case, the payment confirmation information can also include payment confirmation information for the payment of the call fee to the intermediary account for this call. Furthermore, the server or the called terminal can create a paid call answering order for each incoming call. Each paid call answering order has a unique identifier such as an order number. The calling user pays according to the paid call answering order. Whether the payment is made to an intermediary account, the called user's account, or vice versa, the paid call answering order can be used for traceability and integration to form complete call answering fee flow information, proving that the call answering fee was paid by the calling user to the called user. With an intermediary account providing intermediary protection, the call answering fee needs to trigger an incoming call notification on the called terminal after payment to the intermediary account. Therefore, in this case, the payment confirmation information can specifically point to the server (e.g., the intermediary account) confirming payment of the call answering fee. This payment confirmation information can be associated with the paid call answering order for this incoming call to ensure that the call answering fee is ultimately paid to the called user.

[0038] Call notification refers to the process by which the called terminal notifies the called user of an incoming call that the call is waiting to be answered through various means. These typically include multiple forms such as ringtones, vibrations, and screen notifications, the specific form of which can be determined based on the call notification settings configured by the user on the terminal. It should be noted that in some implementations of this application, two call notifications are executed: a first call notification and a second call notification. The difference between the two is that the first call notification allows the called user to input a paid answering action to trigger the paid answering process, while the second call notification is triggered based on payment confirmation information and only needs to support answering or rejecting the call.

[0039] Considering that if the called user can input the paid call option based on the first call notification, it means that the called user is aware of the call and is willing to wait for the caller to confirm payment. Therefore, after detecting the payment confirmation information corresponding to the caller's number, the call can be answered directly. In addition, considering that the time for the caller to confirm payment is uncertain, in order to avoid the called user waiting idly and to avoid answering the call when the called user is unprepared, thus reducing the call experience, a second call notification can be triggered after detecting the payment confirmation information corresponding to the caller's number. In this way, the called user can do other things before the second call notification without waiting, and then officially answer the call after being notified by the second call notification, which can effectively improve the user's call answering experience.

[0040] In some implementations, the second incoming call alert can be implemented with a lower alert intensity than the first incoming call alert. Alert intensity refers to the effectiveness and strength of a particular alert method in attracting the user's attention. Different alert methods have varying abilities to attract user attention; this strength is the alert intensity. For example, both the first and second incoming call alerts may include a ringing sound, but the ringing volume of the second alert is lower than that of the first alert, thus the alert intensity of the second alert is lower than that of the first alert. Similarly, the first alert may include a ringing sound and a screen notification (e.g., displaying the first alert interface), while the second alert includes vibration; the alert intensity of the second alert is also lower than that of the first alert. Furthermore, the first alert may include vibration and a screen notification, while the second alert also includes vibration, but the vibration duration of the second alert is shorter than that of the first alert, thus the alert intensity of the second alert is also lower than that of the first alert. Since the second incoming call notification is something the called user can anticipate and has a high probability of being answered, a low-intensity notification is sufficient to serve its purpose, while avoiding an overly strong notification that might disturb the called user.

[0041] The call handling method provided in this application, upon detecting a call request, executes a first call reminder, and upon detecting that the called user has entered a paid answering operation in response to the first call reminder, executes a paid answering process. The paid answering process includes connecting the call or triggering a second call reminder after detecting payment confirmation information corresponding to the caller's number. This paid answering process raises the threshold for callers to answer, as the caller must pay a fee to trigger the second call reminder or connect the call; otherwise, the call will not be triggered. Therefore, it can block some calls, effectively reducing the number of nuisance call reminders and actual call volume. Furthermore, since answering nuisance calls requires the caller to pay a certain fee to the called user, answering nuisance calls provides additional financial compensation to the called user, effectively alleviating the negative emotions of the called user regarding answering nuisance calls and improving user experience. In addition, this application's solution first executes an incoming call reminder upon detecting a call request, allowing the called user to decide whether to proceed with the paid answering process. This enables the called user to decide in real time whether to accept a paid call for each incoming call, thus allowing them to determine the handling of each call according to their wishes, giving them greater freedom and ensuring that the handling of each call meets their needs. Furthermore, since the paid answering process is executed based on the paid answering operation input by the called user, it is performed when the called user is aware of the incoming call and is able to answer it. In this case, the caller has a higher probability of being successfully answered after paying the answering fee, reducing the probability of the caller paying the answering fee but not being answered, reducing unnecessary paid answering and refund processes that lead to resource waste, thereby improving overall resource utilization and call fluency, and ultimately enhancing the calling experience for both the caller and the answering experience for the called user.

[0042] Considering that in some cases, the caller may be unwilling to pay for answering the call, while the called party may be willing to answer due to boredom or knowing who is calling, it would be a loss for both the caller and the called party if the call could not be connected because the caller was unwilling to confirm payment. In other cases, the called party may be busy or unavailable to answer the call for other reasons. If a paid answering process is still implemented, the caller may still not be able to answer the call after confirming payment and will need to request a refund. This would undoubtedly create unnecessary payment confirmation and refund processes, resulting in unnecessary resource waste. In cases like these, the aforementioned first call reminder needs to support the called user in performing more direct answering operations, such as directly answering or rejecting the call. Based on this, in some embodiments, the aforementioned first call reminder also supports the called user to input a direct answer operation to directly answer the call, and supports the called user to input a reject operation to directly reject the call. Accordingly, the method further includes: answering the call when the called user inputs a direct answer operation in response to the first call reminder; and rejecting the call when the called user inputs a reject operation in response to the first call reminder.

[0043] In addition, if no operation is detected within a preset time, that is, no operation is performed in response to the first incoming call reminder, it means that the called user cannot handle the incoming call at the moment, and the call can be automatically rejected to hang up automatically.

[0044] Through the above implementation, three call answering options can be provided to the called user through the first caller ID: paid answering, free answering, and rejecting the call. This allows the called user to decide their answering strategy for each call, meeting their flexible and autonomous call answering needs. For example, if the called user is willing to answer for free because they are bored or know who is calling, they can answer the call directly based on the first caller ID input, without waiting for the caller to pay the answering fee. If the called user is busy with other things and cannot answer the call, they can reject the call based on the first caller ID input, avoiding secondary disturbance after the caller pays the answering fee. This also reduces the probability of the caller paying the answering fee but not being answered, reducing unnecessary paid answering and refund processes that lead to resource waste. This improves overall resource utilization and call fluency, thereby enhancing the calling experience for both the caller and the called user.

[0045] The aforementioned paid call answering, direct call answering, and call rejection operations can be implemented using preset click operations, drag operations, gesture operations, voice control operations, etc. Click operations can be single clicks, double clicks, or any number of clicks, and can also be long presses or short presses. Drag operations can be dragging in a specific direction or dragging to a specific location or area. Gesture operations refer to a way for users to interact with the device by performing specific finger movements on the device's touchscreen; gesture operations can include various forms such as tapping, swiping, pinching, spreading, and long pressing. Voice control operations are a way for users to control the device based on their voice input. Those skilled in the art can flexibly set the implementation methods of the aforementioned paid call answering, direct call answering, and call rejection operations based on click operations, drag operations, gesture operations, and voice control operations; this application embodiment does not limit this.

[0046] In some embodiments, executing the first incoming call reminder includes: displaying a first incoming call reminder interface, and displaying a paid call answering trigger element, a direct call answering trigger element, and a reject call trigger element on the first incoming call reminder interface according to a preset arrangement; correspondingly, the paid call answering operation includes a first triggering operation based on the paid call answering trigger element; the direct call answering operation includes a second triggering operation based on the direct call answering trigger element; and the reject call operation includes a third triggering operation based on the reject call trigger element.

[0047] The aforementioned paid call answering trigger elements, direct call answering trigger elements, and call rejection trigger elements refer to user interaction elements displayed on the first incoming call reminder interface, such as interactive controls. These can be fixed or movable elements, and this application embodiment does not impose any limitations. These trigger elements correspond to different operations, allowing users to choose an appropriate response method according to their actual needs. In addition, the arrangement of the above-mentioned multiple trigger elements should conform to aesthetics and ergonomics, achieving the purpose of being both beautiful and easy to operate. This application embodiment does not impose any limitations on its specific arrangement method, and those skilled in the art can flexibly set it according to specific needs.

[0048] In this embodiment, by displaying paid call trigger elements, direct call trigger elements, and call rejection trigger elements in a preset arrangement on the first incoming call reminder interface, the user is provided with an operational entry point for paid call answering, direct call answering, and call rejection using visual elements. This significantly enhances the called user's choice and control over incoming calls. Moreover, through the intuitive and structured interface design and trigger element design, users can make quick decisions in a short time and conveniently and quickly input paid call answering, direct call answering, and call rejection operations. The overall operation is fast and efficient, further improving the overall user experience.

[0049] Based on the above embodiments, in some modified embodiments, the paid call answering trigger element includes a first control located on the first incoming call reminder interface, and the first triggering operation includes a dragging operation or a clicking operation on the first control; the direct call answering trigger element includes a second control located on the first incoming call reminder interface, and the second triggering operation includes a dragging operation or a clicking operation on the second control; the call rejection trigger element includes a third control located on the first incoming call reminder interface, and the third triggering operation includes a dragging operation or a clicking operation on the third control.

[0050] The first incoming call notification interface refers to the visual interface presented to the user by the called terminal when it receives a call request. It includes the three types of controls mentioned above, each corresponding to a different operation: the first control initiates the paid call answering process; the second control immediately answers the call; and the third control rejects the call. Users can input corresponding trigger operations by clicking or dragging the corresponding controls on the screen, thereby achieving different handling methods for incoming calls. Considering the risk of accidental clicks, this embodiment also supports dragging the controls to input paid call answering, direct answering, and rejecting operations, reducing the probability of accidental operations.

[0051] This implementation provides users with access to paid answering, direct answering, and rejecting calls through a first, second, and third control, significantly enhancing the called user's choice and control over incoming calls. Furthermore, the triggering operations and logic of these controls are relatively simple, resulting in low implementation costs, while ensuring good visual intuitiveness and convenient operation. These features allow users to quickly make answering decisions and easily input paid answering, direct answering, and rejecting operations. The overall operation is fast and efficient, further enhancing the overall user experience. In addition, compared to traditional call answering interfaces, this implementation provides called users with an extra service option—paid answering—allowing them to manually trigger the paid answering process for certain incoming call numbers, meeting their flexible and autonomous paid answering needs.

[0052] It should be noted that the first control, second control, and third control mentioned above can be different controls or the same control. For example, the first control, second control, and third control can be three virtual buttons, and the first trigger operation, second trigger operation, and third trigger operation are respectively click operations or drag operations of the first control, second control, and third control. Or, the first control, second control, and third control can be the same slider control, and the first trigger operation, second trigger operation, and third trigger operation are respectively operations of dragging the slider control to different positions or directions. All of the above methods have the advantages of being simple and easy to operate. In addition, the paid call answering operation is not limited to the first operation mentioned above, the direct call answering operation is not limited to the second operation mentioned above, and the call rejection operation is not limited to the third operation mentioned above. They can all be implemented through gesture operation, voice control operation, etc. The embodiments of this application will not be described in detail, and they should all be within the protection scope of this application.

[0053] Based on the aforementioned embodiments, in some other modified embodiments, the first call reminder interface is provided with a sliding element; the paid call answering trigger element includes a first trigger area provided on the first call reminder interface, and the first triggering operation includes dragging the sliding element to the first trigger area; the direct call answering trigger element includes a second trigger area provided on the first call reminder interface, and the second triggering operation includes dragging the sliding element to the second trigger area; the call rejection trigger element includes a third trigger area provided on the first call reminder interface, and the third triggering operation includes dragging the sliding element to the third trigger area.

[0054] In this embodiment, the first incoming call reminder interface includes a sliding element and three trigger areas. The paid call answering trigger element corresponds to the first trigger area, the direct call answering trigger element corresponds to the second trigger area, and the reject call element corresponds to the third trigger area. The sliding element can be a simple icon or button, or an electronic business card or caller information card, etc. This embodiment does not limit the type of element. Users can operate the element by dragging it. Different trigger areas correspond to different operations: the first trigger area is used to start the paid call answering process; the second trigger area is used to immediately answer the call; and the third trigger area is used to reject the call. Users can input the corresponding trigger operation by dragging the sliding element to a specific trigger area, thereby realizing different ways of handling incoming calls.

[0055] This implementation, by introducing sliding elements and multiple trigger areas, provides more intuitive and flexible operation options when receiving each call. This approach not only improves the user experience but also enhances interactivity and convenience, enabling users to make answering decisions more quickly. This significantly strengthens the called party's choice and control over answering calls. Moreover, the dragging operation of the aforementioned sliding elements is simple to execute, has good anti-accidental touch and anti-misoperation effects, and has low implementation costs. It ensures good visual intuitiveness and convenient and quick operation. These features allow users to quickly make answering decisions in a short time and conveniently and quickly input paid answering, direct answering, and rejecting operations. The overall operation is fast and efficient, further improving the overall user experience. In addition, compared to the traditional call answering interface, this implementation also provides the called party with an additional service option—paid answering—allowing the called party to manually trigger the paid answering process for some incoming call numbers, meeting the user's flexible and autonomous paid answering needs.

[0056] In some modified implementations, the first call notification interface may further include additional call information about the caller's number and / or call intent, wherein the additional call information includes the caller's identity information and / or call description information specific to the call.

[0057] The aforementioned caller ID information can be sent from the calling terminal to the called terminal, or it can be sent from the server to the called terminal at the request of the called terminal; both methods achieve the purpose of this embodiment. The called terminal can directly display the caller ID information, or it can first identify the caller's intent based on the caller ID information and then display the identified intent. The display can be in the form of a fixed format caller ID card. Formatting the card information helps improve reading efficiency, thus helping the called user quickly understand the caller's identity or purpose when viewing the first call notification, and subsequently decide on an answering strategy.

[0058] The caller's identity information can be transmitted to the called terminal via an electronic business card. This means the aforementioned call notification information can include an electronic business card containing the caller's identity information. An electronic business card is a digital business card format that typically includes detailed user information such as name, phone number, email address, and company name. Call description information includes business information related to the call entered by the caller (such as call purpose, appointment details, etc.). The first call notification screen is a prompt displayed on the called terminal when the first call notification is triggered, used to notify the user of a new call. For example, with each incoming call, the called terminal can also receive call notification information sent by the caller's terminal or the server. This call notification information may include the caller's identity information (such as name, job title, company) and / or the business information of the current call, and then this information is displayed on the first call notification screen.

[0059] The aforementioned caller ID information can be proactively sent by the calling terminal. For example, when initiating a call, the calling terminal can directly send a pre-stored electronic business card to the called terminal, allowing the called user to quickly understand the background and purpose of the call and make an answering decision. Alternatively, to reduce unnecessary data transmission, it can be determined whether it's the first call to the called number. If it's the first call, the pre-stored electronic business card is sent to the called terminal; otherwise, it's sent on demand, i.e., only upon the called terminal's request. Since the called user is unlikely to recognize the calling number on the first call, this helps them obtain information about the caller. Sending only on demand, without request, effectively reduces unnecessary electronic business card transmissions, such as when the two parties have already spoken multiple times. Since it's obviously unnecessary to send an electronic business card again when initiating a new call, this implementation method not only provides the called user with the necessary information support to answer the call, but also reduces unnecessary information transmission, saves network resources and system overhead, and reduces the interference caused by sending unnecessary electronic business cards to the called user. In addition, it can also query the called terminal to see if the caller's number meets the paid call receiving conditions corresponding to the called number. If it does, an electronic business card is sent to the called terminal. This method can more accurately determine whether the called user needs the caller's electronic business card, and send it only when needed, and not send it when not needed. Similarly, it can provide the called user with the necessary information support to answer the call, reduce unnecessary information transmission, save network resources and system overhead, and reduce the interference caused by sending unnecessary electronic business cards to the called user. Furthermore, if the calling user uploads the electronic business card to the server in advance, the various methods of sending electronic business cards by the calling terminal can be changed to the calling terminal triggering the server to send the electronic business card to the called terminal, or the server can identify various scenarios or send the electronic business card to the called terminal automatically according to the calling terminal's settings. Alternatively, the called terminal can initiate an electronic business card retrieval request to the server or the calling terminal, and then the server or the calling terminal responds to the electronic business card retrieval request and sends the electronic business card to the called terminal. Those skilled in the art can flexibly modify the implementation by referring to the foregoing exemplary description, and will not be elaborated here. All of these should be within the protection scope of this application.

[0060] The aforementioned call intent can be identified based on additional call information, analyzed using a pre-defined call intent recognition model, or derived from social graph analysis. For details, please refer to the subsequent descriptions of call intent recognition in the embodiments; these will not be repeated here. Displaying the call intent also helps users quickly understand the background and purpose of the call, improving the accuracy of answering decisions.

[0061] This implementation significantly enhances the functionality and transparency of call reminders. By displaying additional information or call intent on the first call reminder interface, the called user can obtain more information about the caller in advance, helping them quickly understand the background and purpose of the call, thereby improving the accuracy of their answering decision and contributing to a more informed decision. Simultaneously, it reduces user confusion caused by unclear call backgrounds, thus improving communication efficiency. Furthermore, this implementation ensures that users receive sufficient information before answering the call, avoiding misunderstandings or delays caused by information asymmetry.

[0062] In some modified implementations, the paid call answering process further includes: displaying a waiting payment prompt message until payment confirmation information corresponding to the caller number is detected, wherein the waiting payment prompt message is used to remind the caller that they are currently waiting for the caller to pay the call answering fee.

[0063] The "waiting for payment" message can refer to a notification message used to inform the called user that they are currently waiting for the caller to pay the call fee. This message can take the form of text, icons, or animations, and this embodiment of the application is not limited to any particular form. This provides real-time feedback to the called user, informing them that they are waiting for the caller to pay the call fee. For example, the interface might display a message such as "Waiting for the other party to pay the call fee, please wait" or a similar message. Furthermore, animation effects (such as a rotating loading icon) can be used to enhance the visual feedback.

[0064] After detecting that the calling user has completed payment and received payment confirmation information, the next step can be performed: if the called user has selected paid answering and payment confirmation information is detected, a second call reminder will be triggered or the call will be answered directly. In addition, the interface can be updated with prompts to notify the called user that payment has been completed and to indicate that the call will be answered soon or to display a second call reminder.

[0065] In addition, if no payment confirmation information is detected within a certain period of time, appropriate measures can be taken, such as displaying a timeout message or automatically canceling the call request. This can prevent long waiting times from leading to a poor user experience.

[0066] This implementation method, by introducing a waiting payment prompt message, can provide real-time feedback during the paid call process, ensuring that the called user can clearly understand the current status. This approach not only improves the user experience but also enhances the transparency and interactivity of the paid call mechanism, allowing users to wait for payment confirmation with greater peace of mind.

[0067] Based on the above implementation methods, in some modified implementation methods, displaying the waiting-to-pay notification information includes: switching the first incoming call reminder interface to a waiting-to-pay interface, and displaying the waiting-to-pay notification information on the waiting-to-pay interface; or...

[0068] The first incoming call reminder interface is switched to the application interface of the application that was running in the foreground before the first incoming call reminder was executed, and a waiting payment prompt message is displayed in a local area of ​​the application interface.

[0069] The "waiting for payment" screen refers to a dedicated interface displayed after detecting that the called party has selected the paid call option. A "local area" refers to a specific area within the application's interface used to display this waiting-for-payment information; it is typically located at the top, bottom, or other positions that do not interfere with the main operation.

[0070] This implementation provides two specific methods for displaying a waiting payment prompt message:

[0071] One approach is to switch the initial call notification screen to a waiting-for-payment screen, displaying a waiting-for-payment message. This screen should be designed to be simple and clear, focusing solely on the payment confirmation message and avoiding excessive distractions. For example, it could display a message like "Waiting for the other party to pay the call fee, please wait." Furthermore, animation effects (such as a rotating loading icon) can be used to enhance visual feedback, letting the user know that the caller is confirming payment. This approach helps concentrate the user's attention during the payment process, avoiding distractions and improving focus and user experience.

[0072] Another approach is to switch the first incoming call notification interface back to the application interface that was running in the foreground before the notification was executed, and display a "waiting for payment" message in a localized area of ​​that application interface. This aims to minimize disruption to the user's current activity, allowing them to continue using the existing application. The "waiting for payment" message can appear as a small window or floating notification, with content similar to "Waiting for the other party to pay the call fee, please wait," and may be accompanied by a simple animation (such as a loading icon). This implementation minimizes disruption to the user's current activity, allowing them to continue using the existing application while still seeing updates to the payment status. This approach not only improves the user experience but also enables users to maintain efficient operation while waiting.

[0073] The two methods of displaying the waiting payment prompt can be flexibly selected based on the user's preset settings, or according to the preset logic based on the running status of the application in the foreground before the first incoming call reminder. For example, if no application was running in the foreground before the first incoming call reminder, the waiting payment prompt can be displayed on the waiting payment interface. If an application was running in the foreground before the first incoming call reminder, the application interface can be switched back to display the waiting payment prompt, thus allowing the user to maintain efficient operation while waiting.

[0074] This implementation method, through the above two display methods of waiting payment prompts, can more flexibly meet the needs of different users. Whether focusing on the waiting payment process or wishing to continue using the original application, users can obtain clear status feedback. This method not only improves the user experience but also enhances the transparency and interactivity of the paid call mechanism, allowing users to wait for payment confirmation with greater peace of mind.

[0075] It should be noted that in some implementations, a first call reminder can be executed for each call request. The called user can choose to trigger paid call answering, free call answering, or reject the call based on the first call reminder interface, thus giving the caller complete control over the caller's choice.

[0076] Furthermore, considering that in practical applications, triggering a first call reminder for every incoming call could cause significant harassment to the called user, as they might not want to answer some calls at all, choosing neither free nor paid calls. For these calls with no value or prospect of being answered, a first call reminder would be considered harassment. Additionally, for calls from known numbers such as acquaintances, regular call reminders are sufficient, and triggering a first call reminder is unnecessary. The ringtone for the first call reminder can differ from the regular call reminder ringtone, allowing the called user to make an initial judgment based on the ringtone and thus prepare to handle the call. In view of the above issues, some embodiments require selectively executing the first call reminder to reduce the number of calls that do not warrant a paid call. Executing the first call reminder upon detecting a call request includes: upon detecting a call request, obtaining the caller's number; and selectively executing the first call reminder for the caller's number. By selectively executing first call reminders on caller ID numbers, the number of calls that do not warrant paid calls from triggering first call reminders is reduced. This reduces the number of call reminders and thus reduces nuisance calls. Furthermore, for known numbers, calls can be answered quickly based on regular call reminders, thereby meeting users' more specific and diverse paid call handling needs and improving overall call answering efficiency.

[0077] In some examples, the First Call application can specifically implement the process of obtaining the caller's number through the following exemplary steps: First, the First Call application needs to register an incoming call event listener at startup. The listener's function is to listen for incoming call event notifications generated by the operating system. For example, in the Android system, this can be implemented using a BroadcastReceiver; in the Apple iOS system, it can be implemented using the Core Telephony framework. Then, when a new call request arrives, the operating system will trigger an incoming call event notification. The First Call application's incoming call event listener will receive this notification. For example, in the Android system, the BroadcastReceiver will receive an ACTION_PHONE_STATE_CHANGED broadcast; in the iOS system, it can receive the incoming call event through the callEventHandler callback of the CTCallCenter class. Upon receiving an incoming call event notification, the first calling application needs to parse the incoming call data packet to extract the caller ID. For example, in the Android system, the caller ID can be obtained through the getLine1Number() method of the TelephonyManager class or from the Extras of the Intent; in the iOS system, the caller ID can be obtained through the callerID property of the CTCall object.

[0078] In some examples, a first call reminder can be selectively executed based on the caller ID. For instance, after obtaining the caller ID, a preset judgment mechanism can be used to determine whether a first call reminder should be executed. This preset judgment mechanism could be: determining whether the caller ID meets preset paid call conditions; if so, executing a first call reminder; determining whether the caller ID is an unknown number; if so, executing a first call reminder; determining whether the caller ID is identified by a preset caller ID recognition model as a number requiring paid call reception; if so, executing a first call reminder; or determining whether the caller ID's intent is for paid call reception; if so, executing a first call reminder. The judgment is based on both the conditions for receiving a paid call and the intent to receive a paid call. If the calling number meets the conditions for receiving a paid call and the caller's intent is to receive a paid call, then the first call reminder needs to be executed. This process is not elaborated upon here. Those skilled in the art can flexibly set the above judgment mechanism according to actual needs. Its essential purpose is to select the calling number that meets the called user's needs to execute the first call reminder. Therefore, in some embodiments of this application, based on the above preset judgment mechanism, the first call reminder can also be selectively executed on the calling number from multiple dimensions. The above selective execution of the first call reminder on the calling number may include triggering the execution of the first call reminder using at least one of the following call reminder triggering methods; otherwise, the first call reminder will not be executed:

[0079] The first call alert triggering method: If the calling number meets the conditions for paid call reception, the first call alert will be executed.

[0080] The second method for triggering incoming call alerts: If the calling number is an unknown number, the first incoming call alert will be executed.

[0081] The third method for triggering incoming call alerts: When the caller's number is identified by a preset caller ID model as requiring a paid call, the first incoming call alert is executed, wherein the caller ID model is set locally on the called terminal or on the server.

[0082] The fourth call alert triggering method: If the caller's intent is to receive a paid call, the first call alert will be executed.

[0083] The fifth call alert triggering method: If the calling number meets the conditions for paid call reception and the caller's intent is to receive a paid call, the first call alert will be executed.

[0084] Furthermore, for cases where the first call reminder is not required, the normal answering process is executed. The normal answering process refers to any answering process other than the paid answering process, such as executing a regular call reminder, directly blocking blacklisted numbers, using an AI assistant to answer, or forwarding the call to voicemail. The regular call reminder only supports answering and rejecting operations, which is not limited in this embodiment. Alternatively, it can be understood that for cases where the first call reminder is executed, the paid answering trigger element is displayed on the first call reminder interface; that is, in addition to displaying the user trigger elements already present in the call reminder interface, a new paid answering trigger element is also displayed. Conversely, for cases where the first call reminder is not executed, the paid answering trigger element is not displayed on the first call reminder interface; only the direct answering trigger element and the rejecting trigger element are displayed, i.e., the existing user trigger elements already present in the call reminder interface are displayed.

[0085] The first call notification triggering method described above triggers the first call notification based on paid call conditions. This method allows users to customize a series of rules to selectively execute the first call notification for incoming calls. The paid call conditions are one or more conditions set to enable paid call services. These conditions can be set and activated on the called terminal and are used to determine whether the caller's number has a need for paid call services. In other words, the paid call conditions determine whether the caller's number is suitable for the paid call process. If the caller's number meets the paid call conditions, the called terminal will execute the first call notification, and the caller's number may trigger the paid call process. If the caller's number does not meet the paid call conditions, the called terminal will execute the normal call answering process. Through this implementation method, the first call notification can be selectively executed based on the paid call conditions freely set by the called user. This satisfies the user's need for flexible customization of paid call conditions, forming rich, diversified, and personalized paid call conditions to judge incoming calls, thus better meeting the user's paid call service needs.

[0086] The second call alert triggering method described above is to trigger the first call alert for unknown calls. Considering that in most cases only unknown numbers need to be answered for a fee, while known numbers do not, regular call alerts can be executed for known numbers. Only unknown numbers need to be alerted first, allowing the called user to further decide whether to trigger the paid call process. Through this implementation method, the first call alert can be selectively executed for unknown calls, thereby reducing the nuisance of the first call alert to the user.

[0087] The third method of triggering call alerts mentioned above utilizes artificial intelligence and big data analytics to trigger the first call alert for incoming call numbers. The caller ID model is trained using AI and big data analytics, such as machine learning algorithms analyzing historical data to build the model. This model assesses the risk level of each incoming call. If the model determines that a call has a high probability of being harassing or other unwanted, it will suggest triggering the first call alert, allowing the called user to decide whether to initiate the paid call process. This method not only improves decision-making accuracy but also enhances intelligence, making the judgment process more scientific and reasonable, and the identification results more accurate, thus largely meeting the called user's paid call needs.

[0088] The fourth method of triggering call alerts mentioned above is to trigger the first call alert based on the caller's intent. Call intent can refer to inferring the purpose or intention of the call by analyzing the caller's historical behavior, communication records, and other relevant data, or it can be identified based on the caller's identity information and call description information. Examples include different types of call purposes such as sales promotion, customer service follow-up, and emergency notifications. Paid call intent refers to call intents that require the caller to pay a fee to trigger a call alert on the called terminal, such as sales promotion or fraud. The called terminal can determine the caller's intent by performing call intent identification steps and determine whether to trigger the first call alert based on the matching result between the call intent and the paid call intent. If the call intent matches the paid call intent (i.e., the call intent belongs to paid call intent), the first call alert is triggered; if the call intent does not match the paid call intent (i.e., the call intent does not belong to paid call intent), a regular call alert is triggered.

[0089] In some implementations, a caller intent identification step is included before the first call notification. This step utilizes a pre-defined caller intent identification model to analyze the intent of the incoming call. This model can be deployed locally on the called terminal or on a server. Based on machine learning algorithms and big data analytics, it can extract features from a large amount of historical call data and build a predictive model. When a new call request arrives, the caller intent identification model assesses the caller intent based on various characteristics of the current caller number (i.e., the calling number) (such as call time, calling frequency, historical call records, etc.) and determines whether it is a paid call intention. If the caller intent is determined to be a paid call intention, the first call notification is triggered. Furthermore, the caller intent identification model can also identify caller intent through social graph analysis, for example, by inferring the caller intent based on the social relationships between the caller and the called user, as well as mutual contacts.

[0090] In other embodiments, the calling user can send call-related supplementary information to the called terminal through the calling terminal. This call-related supplementary information includes the calling user's identity information and / or call description information entered by the calling user. Accordingly, the above-mentioned call intent recognition step can be based on the above-mentioned call-related supplementary information to recognize the calling user's call intent. The call intent recognition step includes: receiving call-related supplementary information sent by the calling terminal, the call-related supplementary information including the calling user's identity information and / or call description information; and recognizing the calling user's call intent according to the call-related supplementary information.

[0091] In this context, caller ID information refers to information sent by the calling user to the called user's terminal, and / or information about the calling user requested by the called user from the server, including but not limited to the calling user's identity information (such as name, company name, etc.) and call description information entered by the calling user (such as the purpose of the call, etc.). Identifying the calling user's intent based on this caller ID information can be achieved by analyzing the caller ID information to determine the calling user's purpose or intent. This process can be implemented using machine learning algorithms and big data analytics to improve the accuracy and intelligence of the judgment.

[0092] For example, when a caller wants to contact a recipient by phone, they can enter additional information on their terminal, such as selecting an electronic business card suitable for the call, or entering the purpose or description of the call. This information will be sent to the recipient's terminal along with the call request as part of the call notification. After receiving the call notification, the recipient's terminal will automatically parse this information and identify the caller's intent based on a preset algorithm. This caller intent identification process can be based on Natural Language Processing (NLP) technology and machine learning models to extract key information from the text and classify it.

[0093] In some implementations, embodiments of this application provide multiple call interaction methods, through which the called terminal can obtain the aforementioned additional call information. Examples are provided below:

[0094] The first type of call interaction involves the calling terminal sending an electronic business card containing the caller's identity information. This electronic business card identifies the caller, for example, in insurance marketing. The called terminal then identifies the caller's intent based on the identity information recorded on the electronic business card.

[0095] The second method of call interaction involves the caller explaining their purpose through a dialogue with the called party's intelligent voice assistant. This could involve the caller conveying a description of their call via voice, including the purpose of the call. The called party's intelligent voice assistant then identifies the caller's intent based on this description. This method utilizes natural language processing technology and the intelligent voice assistant to automatically parse the caller's voice input to understand and determine the purpose of the call.

[0096] The third call interaction method involves the called terminal's intelligent voice assistant instructing the calling user to select the appropriate identity or call purpose option for response. The calling terminal can display the corresponding identity and / or call purpose options, and then, based on the calling user's selection, determine the selected option information and feed it back to the called terminal. The called terminal can then identify the calling user's identity and / or call purpose based on the selected option information, thereby determining the calling user's intent. This method can be implemented using the interactive voice response system provided in subsequent embodiments of this application. For a description of the interactive voice response system, please refer to the following embodiments; further details are omitted here.

[0097] In the first type of call interaction, an electronic business card is a digital personal information card that typically contains the caller's identity information (such as name, company name, and job title). The electronic business card can be sent directly to the called party's terminal via an application or communication protocol. The identity information refers to the basic information used to identify the caller, including but not limited to name, company name, and contact information. In some examples, when a caller wants to contact a called party, they can select or fill in their electronic business card on their terminal and send it along with the call request to the called party's terminal. Upon receiving the electronic business card, the called party's terminal automatically parses the identity information and identifies the caller's intent based on this information.

[0098] Based on the first call interaction method, using an electronic business card, the called terminal can quickly obtain and parse the caller's identity information, thereby accurately identifying the caller's intent and determining whether to trigger the first call reminder based on the intent. Since the electronic business card is edited by the caller, the recorded identity information is relatively reliable, resulting in more accurate identification of the caller's intent. Furthermore, the electronic business card can be displayed on the first call reminder interface, helping the called user better understand the background of the call and make a more informed decision about answering.

[0099] For the second type of call interaction, the intelligent voice assistant is an AI assistant based on natural language processing and speech recognition technologies. It can engage in voice conversations with the caller, understand the caller's intentions and needs, and identify the caller's intent. Call description information refers to information input by the caller via voice or selection controls regarding the purpose or purpose of the call. In some examples, when a caller dials a recipient's number, the recipient's terminal can answer the call and use the intelligent voice assistant to converse with the caller, guiding the caller to explain the purpose of their call. After the caller inputs the call description information via voice, the intelligent voice assistant automatically parses the voice input and identifies the caller's intent. The recipient's terminal can then decide how to handle the call based on the intelligent voice assistant's analysis results.

[0100] Based on the second call interaction method, utilizing an intelligent voice assistant, the called terminal can analyze the caller's voice input in real time, understand the purpose of the call, and make corresponding processing decisions accordingly. This method not only improves the intelligence level of call processing but also significantly enhances the user experience. Since the caller's description information is entered in real time during the call, it accurately explains the caller's purpose, thus the identified call intent has high accuracy, helping to more accurately determine whether to trigger the paid call process based on the call intent.

[0101] For the third type of call interaction, the identity option is a pre-set set of options for the caller to select their identity category, such as insurance sales, financial services, real estate agency, or delivery / takeout. The call purpose option is also a pre-set set of options for the caller to select their call purpose, such as product promotion, package pickup, or package delivery. In some examples, when a caller dials a recipient's number, the recipient's intelligent voice assistant can inform the caller to select the appropriate identity or call purpose option to respond. The caller's terminal can display these options through a second-party calling application. The caller can choose the option that best suits their situation. The caller's terminal then relays the caller's selection to the recipient's terminal, which identifies the caller's identity and call purpose based on the selected option information, thereby determining the caller's intent.

[0102] Based on the third call interaction method, by providing identity options and call purpose options, the input process of the calling user can be simplified and the accuracy of the call description information can be ensured. This method can not only improve the efficiency of call processing, but also reduce the occurrence of misjudgments. Since the identity options or call purpose options are selected by the calling user when making the call, they can accurately describe the calling user's purpose. Therefore, the identified call intent has high accuracy and helps to more accurately determine whether to trigger the paid answering process based on the call intent.

[0103] Based on the fourth call alert triggering method mentioned above, by identifying the caller's intent, the called terminal can identify the caller's intent and decide whether to execute the first call alert accordingly, thereby more accurately filtering and processing calls, which can improve the accuracy of decision-making and enhance user experience and service quality.

[0104] The fifth call reminder triggering method mentioned above comprehensively considers the paid call receiving conditions and the caller's intent to trigger the first call reminder. The process of judging the paid call receiving conditions and the caller's intent can be understood with reference to the first and fourth call reminder triggering methods mentioned above, and will not be repeated here. Furthermore, the judgment of the paid call receiving conditions and the judgment of the caller's intent can be implemented in parallel or sequentially; the order of implementation is not limited, and both can achieve the purpose of this application embodiment. To improve overall efficiency and avoid resource waste, in some embodiments, the judgment of the paid call receiving conditions can be performed first, followed by the judgment of the caller's intent. The step of executing the first call reminder when the calling number meets the paid call receiving conditions and the caller's intent corresponding to the calling number is a paid call receiving intent includes: when the calling number meets the paid call receiving conditions, performing a caller's intent identification step; and when the identified caller's intent is a paid call receiving intent, executing the first call reminder.

[0105] Based on the fifth call notification triggering method mentioned above, by combining paid call conditions and caller intent recognition, it is possible to more accurately filter out calls that require the first call notification. This dual verification mechanism not only improves the accuracy of judgment but also further reduces the occurrence of misjudgments, ensuring that numbers identified as requiring paid calls more accurately meet the needs of the called user. Furthermore, paid call conditions can be understood as initial selection, and caller intent recognition as secondary selection. Combining the two, only the caller intent recognition step needs to be performed on the initially selected caller numbers, thereby reducing the process of recognizing caller intent for unnecessary caller numbers, reducing unnecessary resource consumption for caller intent recognition, and improving overall efficiency. From another perspective, after initial selection, further caller intent recognition can more accurately determine whether the caller number needs to trigger the paid call process, further improving the accuracy of paid call judgment. For example, if the caller is a relative of the called user but has changed their phone number, and the called user's terminal has set the paid call condition to unknown numbers... The initial call notification process, if only assessing the conditions for paid call acceptance, might trigger a paid call for an unknown number. However, by adding a caller intent recognition process, where the caller discloses their identity information during the call, the caller intent recognition step can identify that the call is from a relative and not for paid service. This allows for a normal call acceptance process, such as triggering a regular call notification and displaying the caller intent recognition result, thus informing the called party of the caller's intent. Clearly, this dual verification mechanism in this scenario allows for a more accurate determination of whether a paid call should be accepted, improving the user experience.

[0106] Based on the above-described call reminder triggering method, this application can be further extended and modified through the following numerous variations to obtain more specific solutions applicable to various application scenarios. Any of the following variations can be combined with any of the above-described call reminder triggering methods, or a suitable call reminder triggering method can be selected and combined according to the technical content. Since there are too many combination schemes to list them all, those skilled in the art should be able to combine various schemes according to actual needs to achieve more specific purposes based on the embodiments of this application, and all of these should be within the protection scope of this application. Furthermore, for ease of understanding, the following descriptions of embodiments are mainly based on the first call reminder triggering method described above. However, the following descriptions of embodiments are also applicable to the second to fifth call reminder triggering methods described above. Those skilled in the art can make reasonable modifications based on the following descriptions of embodiments to make them applicable to the various call reminder triggering methods described above. Therefore, some similar content will not be described in detail; please refer to each embodiment for mutual understanding.

[0107] It should be noted that in the above embodiments, the paid call answering conditions can be either default settings or user-defined settings. For example, the first call application can preset a series of default paid call answering conditions. These default conditions aim to provide users with a basic protection mechanism to help them reduce the interference of harassing calls. For instance, the default setting allows paid answering of all unknown numbers. These default paid call answering conditions take effect immediately when the user first uses the application, without requiring complex settings. This improves user convenience and ensures that users enjoy the anti-harassment function from the very beginning. Alternatively, users can set their own paid call answering conditions according to their needs and preferences. For example, users can set paid answering of specific types of unknown numbers or paid answering of calls within a specific time period. This flexible setting method allows users to formulate the most suitable paid call answering conditions based on their actual situation, enabling them to better control their call environment and reduce unnecessary interference. Regarding the specific content of the paid call answering conditions, those skilled in the art can flexibly set default conditions according to actual needs, or provide multiple freely editable initial conditions and parameters for users to customize. This application embodiment does not limit this.

[0108] To meet users' needs for personalized paid call receiving conditions, in some implementations, the paid call receiving conditions may include at least one of the following elements: familiarity with the number, number category, custom number list, number source, paid call receiving identifier, membership level, caller ID model recognition result, effective time, and charging standard.

[0109] Number familiarity refers to categorization information based on whether the caller's number is in the called user's contact list. It indicates whether the called user recognizes the caller's number or the caller, including both unknown and known numbers. Unknown numbers are those not in the called user's contact list, while known numbers are those already in it. By setting number familiarity as a condition for paid call answering, users can more precisely control which types of numbers might require paid service.

[0110] Number category refers to information obtained by classifying telephone numbers based on the caller's purpose, service type, or the identity of the number holder (i.e., the caller). It is used to characterize the caller's purpose, service type, or the identity of the number holder, and includes, but is not limited to, delivery calls, marketing calls, food delivery calls, fraudulent calls, official calls, and unclassified numbers. By using number category as a condition for paid call reception, users can more precisely control which specific types of numbers may require paid reception.

[0111] Furthermore, the aforementioned number categories can also be the result of multi-level classification. For example, for marketing calls, they can be further subdivided according to marketing categories. These categories include, but are not limited to, education and training, financial management, real estate agencies, insurance sales, e-commerce promotions, decoration companies, and recruitment / headhunting, providing users with a richer and more detailed selection of number categories to choose from, allowing them to decide whether to trigger the first call alert for a more specific number category. Specifically, multi-level classification can not only initially classify numbers based on their nature and characteristics (such as call purpose, business category, or the identity of the number holder), but can also further refine the classification to meet users' personalized needs. For example, for marketing calls, users may want to handle different categories of marketing calls differently. Through multi-level classification, marketing calls can be further divided into subcategories such as education and training, financial management, real estate agencies, insurance sales, e-commerce promotions, decoration companies, and recruitment / headhunting, and even further subdivided into these subcategories. In this way, users can set different paid call conditions according to their interests and needs. By classifying phone numbers into multiple levels and applying this classification to the settings of paid call conditions, users can flexibly set up multi-level paid call conditions according to their actual situation and needs, thereby achieving more precise call management.

[0112] A custom number list is a user-defined list of numbers that allows users to specify which caller ID numbers will trigger first call alerts or not. This includes, but is not limited to, paid lists, free lists, blacklists, and whitelists. For example, numbers on the paid list may require a fee to answer calls, numbers on the free list may not, numbers on the blacklist may be blocked, and numbers on the whitelist may trigger regular call alerts. Setting up a custom number list helps users manage incoming calls more flexibly.

[0113] Number origin refers to the number's attribution information determined based on the caller's geographical location or carrier information, such as specific regions, specific carriers, and international numbers. By setting number origin, users can more precisely control which numbers from which sources require paid call reception.

[0114] The paid call indicator is a user-defined flag for known phone numbers. It can have two states: true ("true") and null ("null"). Users can set whether to pay for calls to specific phone numbers. A true flag indicates that the known number should be paid for; a null flag indicates that it should not. This flag allows users to define which contacts or phone numbers should trigger the first call notification, providing a more personalized and controllable communication management approach. Users can set the paid call indicator for specific known numbers through the First Call app or related service interfaces. When a known number has the paid call indicator set by the called user (the flag changes from null to true), and the paid call condition is set to trigger the paid call process for calls with a true flag, subsequent calls to that known number will trigger the first call notification.

[0115] The aforementioned paid call indicator can be set through the paid call condition editing interface or the contact editing interface. For example, in a specific example, after a called user completes a paid call from an unknown number, they can choose to save the caller ID to their contact list. The called terminal can display a notification message on the call-end screen indicating that the caller ID can be added as a contact, and provide a control (such as a button) for the user to operate (such as clicking the button) to confirm adding the caller ID. Upon detecting the called user's input indicating agreement to add the caller ID as a contact, the contact editing interface for adding the caller ID as a contact can be displayed, and the contact information can be displayed within this interface. The option to display a paid call indicator is displayed. The option is empty when unselected and true when selected. Based on the called user's selection of the paid call indicator setting option, a paid call indicator can be set for the aforementioned caller ID. This paid call indicator is used to mark the caller ID as meeting the conditions for paid call reception. For example, based on the user selecting the paid call indicator setting option, the paid call indicator is set to true; or based on the user not selecting the paid call indicator setting option, the paid call indicator is set to empty. After the contact is saved, the caller ID becomes a known number. If the caller ID receives another call, the paid call indicator of that caller ID can be used to determine whether the caller ID meets the conditions for paid call reception and trigger the first call notification.

[0116] Membership levels refer to the classification and rating of users in paid call answering services based on their membership purchase history, behavior, consumption records, or other relevant indicators. By setting different membership levels, a more personalized and differentiated service experience can be provided, while also introducing a new dimension to the call interaction between callers and recipients. Membership level can serve as one of the criteria for eligibility for paid call answering. For example, higher-level members can set up first-call alerts for unknown numbers above a certain level, while calls to unknown numbers below that level are directly rejected. Determining caller eligibility for paid call answering based on membership level allows for more flexible and personalized paid call answering solutions. A well-configured membership level mechanism not only enhances user experience but also promotes interaction and trust among users, creating a healthy and active communication environment.

[0117] Caller ID model is an intelligent model deployed locally on the called terminal or on the server. Its core function is to assess whether a caller ID number warrants an immediate alert by analyzing the caller's historical behavior patterns, communication records, and other relevant data. It can also use the called number's historical call answering behavior data for supplementary assessment. Specifically, the caller ID model utilizes machine learning algorithms and big data analytics to extract features from large amounts of historical call data and build predictive models based on these features. When a new call request arrives, the model evaluates the caller ID number in real time according to preset rules to determine whether it is likely to be harassing, telemarketing, or other unwanted. In one example, to implement the caller ID model's functionality, a large amount of training data needs to be collected and processed. This data typically includes, but is not limited to: basic information about the caller ID number (such as location and carrier), past call records (such as frequency and duration), and user feedback (such as the number of times it was marked as a harassing call). Through learning from this data, the model can identify which features are highly correlated with high-risk calls. For example, numbers that frequently dial different users' numbers but with extremely short call durations may be flagged as potential sources of harassment; while numbers frequently appearing on blacklists are more likely to be telemarketing calls. Building on this, the caller ID model can further improve accuracy by incorporating contextual information, such as the time of day, frequency of the call, and the user's current status (e.g., busy status). After completing the risk assessment of the caller ID number, the model generates an identification result to guide subsequent paid call decisions. If the model determines that the caller ID number has a high probability of harassment or telemarketing, it triggers the first call alert. This approach not only helps users effectively filter out unnecessary calls and reduce the inconvenience of answering unknown calls, but also prompts unnecessary callers to consider whether it is truly necessary to contact the user, thereby indirectly reducing the incidence of harassing calls. Furthermore, because the model is trained on a large amount of real data, its judgments have high reliability and can largely avoid misjudgments. By introducing the caller ID recognition model's identification results as an important dimension of the paid call answering conditions, this application's embodiments not only enhance the level of intelligence but also provide users with a more flexible and efficient call management tool.

[0118] In addition, in some modified implementations, the conditions for paid call reception may also include the following condition elements: effective time.

[0119] The aforementioned effective time, also known as the additional condition element, refers to the effective time information of the paid call receiving conditions. This time can include one or more time periods, referred to as the paid call receiving period. The default is all-day effective time, but it can also be a specific time period or date, including but not limited to working hours (e.g., 9:00-18:00), rest hours (e.g., 22:00-06:00), holidays, and weekends. Setting an effective time helps users better manage incoming calls within a specific time period and reduce unnecessary interference.

[0120] In addition, in some modified implementations, the conditions for receiving paid calls may also include the following elements: charging standards.

[0121] The charging standard refers to the specific charging information for paid call reception. It is the charging standard for the called user based on the calling number. It can use default settings or be flexibly adjusted by the user according to their personal needs. It can be a fixed amount charged per call, or a dynamic amount corresponding to different reception duration thresholds, number categories, and effective times. The fixed amount refers to a fixed amount that all eligible calling numbers must pay, while the dynamic amount sets different payment amounts based on different conditions, such as higher amounts for specific types of unknown numbers. By setting different charging standards, users can manage incoming calls more flexibly according to their needs and preferences. It should be noted that the charging standard can use default settings or be flexibly adjusted by the user according to their personal needs. Considering the convenience of payment and the widespread demand for the prepaid model, some embodiments of this application can adopt a per-call reception fee method. This eliminates the need to calculate reception fees based on factors such as call duration, reducing system load and improving payment efficiency. It should be noted that the charging standard can be used as one of the conditions for paid call reception, or it can be set and applied independently of the conditions for paid call reception. Those skilled in the art can set it flexibly according to actual needs, and all of them are within the protection scope of this application.

[0122] Based on the above description, in this embodiment, the paid call receiving conditions can be determined according to at least one of the following dimensions: familiarity with the number, number category, custom number list, number source, paid call receiving identifier, membership level, caller ID model recognition result, effective time, and charging standard. This embodiment generates paid call receiving conditions based on at least one of the above dimensions, enabling users to freely set paid call receiving conditions from different dimensions and angles, comprehensively meeting users' personalized paid call receiving needs and improving user experience.

[0123] Based on the above conditions, users can customize paid call receiving conditions. Specifically, in some implementations, the method further includes: in response to a setting trigger operation, displaying a paid call receiving condition editing interface, wherein the paid call receiving condition editing interface has editable elements corresponding to at least one of the following dimensions: number familiarity, number category, custom number list, number source, paid call receiving identifier, membership level, caller ID model recognition result, and effective time; and determining the paid call receiving conditions based on the called user's editing operation on the editable elements.

[0124] The set trigger operation can refer to a specific operation performed by the user in the operating system or application (such as the First Call app) to trigger the display of the paid call condition editing interface, such as clicking the "Settings" button or selecting the "Paid Call Conditions" option.

[0125] The paid call condition editing interface can refer to a user interface that allows users to customize paid call conditions. It includes at least one editable element corresponding to the above-mentioned condition elements, and may also include necessary interface elements such as labels or static text. The labels and static text can be used to identify and explain the condition elements so that users can understand and edit the above-mentioned condition elements and generate paid call conditions.

[0126] Editable elements can refer to controls or components in the user interface that can be edited and set, such as switches, sliders, input boxes, drop-down menus, forms, checkboxes, buttons, text boxes, and sliders.

[0127] The above methods enable users to more flexibly customize the conditions for receiving paid calls, improve the personalization capabilities of the paid call function, and meet users' personalized call answering needs.

[0128] In addition, based on the above implementation method, in some modified implementation methods, the method further includes: displaying a charging standard editing element on the paid call condition editing interface or the charging standard setting interface; and determining the charging standard based on the called user's editing operation on the charging standard editing element.

[0129] As mentioned above, the editing of the charging standard can be performed in the paid call condition editing interface or in a separate charging standard setting interface. Both can achieve the purpose of this application embodiment. Similar to the editable elements corresponding to the aforementioned condition elements, the above-mentioned charging standard editing elements can also refer to controls or components in the user interface that can be edited and set, such as input boxes, drop-down menus, sliders, etc.

[0130] It should be noted that different caller ID categories can have the same or different pricing standards. For example, marketing calls may be charged at 2 yuan per call, while fraudulent calls may be charged at 5 yuan per call. This raises the call threshold for different number categories to varying degrees and brings different levels of benefits to the called party. This tiered pricing standard helps the called party set different pricing standards for different number categories based on factors such as the risk of answering the call, the caller's willingness to call, and the called party's acceptance (or resistance) to the number category.

[0131] The above-mentioned charging methods, which correspond to different charging standards for different number categories, can be called tiered charging methods. In addition, tiered charging methods can also include different charging standards for different numbers based on familiarity, different numbers from different sources, different custom number lists, and different effective times. Based on the above description, in some modified implementations, the payment confirmation information includes confirmation information from the caller to the called user for paying the call reception fee. The call reception fee is determined according to the charging standard preset by the called terminal. The charging standard is determined according to the tiered charging method. The tiered charging method classifies the charging standard from at least one of the following dimensions: number familiarity, number category, custom number list, number source, paid call reception identifier, membership level, caller ID model recognition result, and effective time. Each dimension can correspond to different fee rules. For example, classifying numbers based on familiarity could mean different fees for unfamiliar and known numbers; classifying numbers based on membership level could mean different fees for different membership levels (e.g., regular members, premium members); and classifying numbers based on the results of the caller ID model could mean different fees for different caller ID model results, such as different risk levels identified by the caller ID model.

[0132] By establishing tiered pricing, different types of calls can be managed more precisely. This ensures that called users can flexibly set their own pricing based on their needs and preferences. This flexibility not only improves the user's communication experience but also effectively balances the interests of both callers and called users, ensuring fairness and efficiency in the communication process. Furthermore, tiered pricing incentivizes callers to carefully consider the necessity and urgency of a call before making it. Higher pricing encourages callers to be more cautious when making high-risk or low-acceptance calls, thereby reducing unnecessary calls and improving call quality and efficiency. In short, this multi-tiered, differentiated pricing system better meets the needs of different users and improves the overall quality of the communication environment.

[0133] In some examples, the paid call conditions determined based on the conditional elements of at least one of the above dimensions may include at least one of the following:

[0134] The caller ID is an unknown number; the caller ID belongs to a pre-defined category of numbers that require paid service; the caller ID is in a pre-defined custom number list; the caller ID's source is a pre-defined source of numbers that require paid service; the caller ID has a paid service identifier; the caller ID's membership level is a pre-defined membership level that requires paid service; the caller ID's call time is a pre-defined paid service time period; the caller ID is identified as requiring paid service by a pre-defined caller ID model.

[0135] Please refer to the foregoing explanation of the meaning and function of each of the above paid call conditions for further understanding. They will not be repeated here. Any one of them can be set as a paid call condition and used to trigger the first call reminder when the caller number meets that condition. In addition, the above items can also be combined to generate more detailed and accurate paid call conditions. When used in combination, the first call reminder can be triggered when the caller number meets any of the combined conditions, or when the caller number meets every single condition in the combination. Those skilled in the art can flexibly set the triggering mechanism according to actual needs. The embodiments in this application are not limited, and all of them should be within the protection scope of this application.

[0136] Furthermore, in the embodiments of this application, the calling terminal can pay the fee immediately upon initiating the call, or upon prompting by the called terminal, or after the call ends. All of these methods align with the inventive purpose of the embodiments of this application and should be within the scope of protection of this application. In some examples, considering that whether the calling number triggers the paid call process is determined by the called terminal, the called terminal should send a paid call notification message to the calling terminal to notify the calling terminal to make the payment. If necessary, it may also need to send payment guidance information to the calling terminal so that the calling user can pay the call fee according to the payment guidance information. Additionally, it may be necessary to send payment timing option information to the calling terminal so that the calling user can choose the payment timing.

[0137] Based on the above requirements, in some modified embodiments of this application, the paid call answering process further includes a paid information interaction step. This paid information interaction step may include: sending paid interaction information to the calling terminal corresponding to the calling number according to a preset paid information interaction method. The paid interaction information includes at least one of paid call answering prompt information, payment guidance information, payment timing option information, and automatic payment option information. Specifically, the paid call answering prompt information is used to remind the calling user that they need to pay the call answering fee to connect the call; the payment guidance information is used to guide the calling user to pay the call answering fee; the payment timing option information is used to provide at least one payment timing option for the calling user to choose from. The payment timing option includes a post-payment option and / or a pre-payment option. The post-payment option indicates that the call answering fee will be paid after the call ends, and the pre-payment option indicates that the call answering fee will be paid first before triggering a second call reminder or connecting the call.

[0138] The aforementioned paid information exchange methods may include, but are not limited to, at least one of the following:

[0139] The first method of payment information interaction: when an incoming call is received in the background, payment interaction information is sent to the calling terminal through the call link; the second method of payment information interaction: payment interaction information is sent to the calling terminal through an interactive voice response system; the third method of payment information interaction: payment interaction information is sent to the calling terminal through in-app notification; the fourth method of payment information interaction: payment interaction information is sent to the calling terminal via SMS.

[0140] Before sending the payment interaction information to the calling terminal for the first time through the call link, the call must be connected in the background with the external voice acquisition link and call playback link of the called terminal disconnected. Then, the payment interaction information is sent to the calling terminal through the call link. Subsequently, as long as the call is connected in the background, the payment interaction information can be sent to the calling terminal again.

[0141] Furthermore, the aforementioned interactive voice response system can be an external interactive voice response system provided by a telecommunications operator or a third-party service provider, or it can be a built-in interactive voice response system implemented collaboratively by a first call application and a second call application. Both can achieve the purpose of the embodiments of this application. In some embodiments, sending paid interaction information to the calling terminal through the interactive voice response system includes: sending paid interaction information to the calling terminal through the built-in interactive voice response system; wherein, the built-in interactive voice response system is implemented collaboratively by a first call application installed on the called terminal and a second call application installed on the calling terminal, the first call application sending paid interaction information to the second call application through a call link or an internet link, and the second call application sending response information to the paid interaction information to the first call application through an internet link.

[0142] It should be noted that the payment interaction information in the embodiments of this application may be pre-stored in the called terminal, or it may be generated by the intelligent voice assistant set in the called terminal. The intelligent voice assistant is an artificial intelligence assistant based on natural language processing technology and speech recognition technology, which can conduct voice dialogue with the calling user and generate appropriate payment interaction information to send to the calling terminal according to the dialogue. All of the above can achieve the purpose of the embodiments of this application, and they should all be within the protection scope of this application.

[0143] Furthermore, considering that different calling terminals support different paid information interaction methods, in some implementations, a paid information interaction method suitable for the calling terminal can be selected based on the calling terminal's device information. The step of sending paid interaction information to the calling terminal corresponding to the calling number according to the preset paid information interaction method may include: selecting a paid information interaction method suitable for sending the currently to-be-sent paid interaction information to the calling terminal from the preset paid information interaction methods based on the calling terminal's device information; and sending the paid interaction information to the calling terminal according to the determined paid information interaction method.

[0144] The following explanation, using specific needs and examples, further clarifies the above-mentioned paid information interaction methods. The interaction of paid call notification information, payment guidance information, and payment timing option information is explained based on the paid call notification step, payment guidance information sending step, and payment timing sending step, respectively. It should be noted that paid call notification information, payment guidance information, and payment timing option information are all subordinate concepts of paid interaction information, and the paid call notification step, payment guidance information sending step, and payment timing sending step are all subordinate implementations of the paid information interaction steps. The following explanations of subordinate concepts and implementations can be used to explain the above-mentioned superior concepts and implementations.

[0145] To prompt the calling terminal to make a payment, in some modified embodiments of this application, the payment information interaction step may include a paid call answering prompt step. This paid call answering prompt step may include: sending a paid call answering prompt message to the calling terminal corresponding to the calling number through a preset paid call answering prompt method. The paid call answering prompt message is used to remind the calling user that a call answering fee must be paid to connect the call. Specifically, it may remind the calling user that a call answering fee must be paid to remind the called user to answer the call. The paid call answering prompt method includes at least one of the following:

[0146] The first method of paid call notification: The call is answered in the background, and a paid call notification message is sent to the calling terminal through the call link; The second method of paid call notification: The paid call notification message is sent to the calling terminal through an interactive voice response system; The third method of paid call notification: The paid call notification message is sent to the calling terminal through an in-app notification; The fourth method of paid call notification: The paid call notification message is sent to the calling terminal via SMS.

[0147] Among them, the paid call answering prompt method refers to the paid information interaction method of sending paid call answering prompt information. Specifically, it refers to different forms of notification mechanisms set up to ensure that the caller can receive and understand the paid call answering request. These prompting methods may include, but are not limited to, voice prompts, SMS notifications and in-application messages, which will be explained below.

[0148] For the first type of paid call notification method, background call connection refers to the called terminal automatically connecting the call without requiring the called user to manually answer. This is done by disconnecting the external voice acquisition link and call playback link of the called terminal. Because the call connection action is performed in the background, it is called background call connection. It should be noted that in the case of a background call connection, the foreground does not provide any notification about the call being connected, and the called user does not need to speak with the caller. Voice data sent by the caller through the call link is not played. Therefore, the called user is unaware of the background call connection, allowing the called terminal to automatically connect the call and send paid call notification information and other paid interactive information to the caller without disturbing the called user.

[0149] The external voice acquisition link refers to the entire path from the microphone capturing external sound signals and transmitting them to the processing unit (such as the processor of a terminal like a mobile phone). It is responsible for collecting and sending the called party's voice data. This path includes hardware and software components to ensure that the captured external sound signals can be processed and used by the terminal. Disconnecting the external voice acquisition link of the called terminal in this application can refer to disconnecting any node of the external voice acquisition link of the called terminal, such as turning off the microphone or prohibiting the transmission or processing of audio signals acquired by the microphone. Therefore, disconnecting the external voice acquisition link can include disconnecting the microphone voice acquisition link. The microphone mentioned above can include the built-in microphone configured in the called terminal itself, or it can include an external microphone connected to the called terminal via wired or wireless means. In this way, after the call is connected in the background, the called user's voice will not be acquired or sent to the calling terminal, thus avoiding the leakage of the called user's voice to the calling user without the called user's knowledge, thereby protecting the privacy and security of the called user. At the same time, a paid call notification message and other paid interactive information are sent to the calling terminal corresponding to the calling number through the call link. In other words, this application embodiment uses the call link to send paid call notification messages and other paid interactive information to the calling terminal, thereby achieving the purpose of prompting the calling user to make a payment.

[0150] Specifically, disconnecting the external voice acquisition link can be achieved at different levels through various technical means, ensuring that the called terminal's microphone does not capture and upload any audio input. At the software level, the First Call application can be programmed to automatically disable microphone recording when a call is answered in the background, or temporarily change the audio capture status through the operating system's API interface, such as muting the microphone or stopping the audio service. It can also adjust the microphone's working mode through audio management functions to prevent it from receiving audio input, or even redirect input to an invalid device by modifying audio routing policies. These measures not only effectively control the acquisition and transmission of voice data without affecting other functions, but also ensure that the called user's privacy is fully protected during the process of answering a call in the background and sending a paid call notification to the calling terminal. This guarantees the security and reliability of communication and enhances the called user's trust in the paid call service.

[0151] The call playback link refers to the data transmission path from the communication network to the called terminal's speaker, responsible for receiving and playing the caller's voice data. Disconnecting the call playback link can be achieved at different levels through various technical means to ensure that the sound from the calling terminal is not played through the called terminal's speaker. At the software level, the first call application can be programmed to automatically pause the audio output service when a call is answered in the background, or the audio output path can be temporarily changed through the API interface provided by the operating system, such as redirecting the audio to a mute device or completely disabling the audio output function. At the hardware level, a dedicated hardware switch or circuit can be built in to directly cut off the audio signal line connected to the speaker, while a more common approach is to adjust the working mode of the dynamically configured audio codec to ignore the input signal. At the network protocol level, SIP signaling can be used to send appropriate instructions to temporarily suspend one party's audio stream without interrupting the entire call connection. Regardless of whether software control, hardware operation, or network protocol-level intervention is used, the core objective is to effectively prevent the sound from the calling terminal from being played through the called terminal without affecting other functions, thereby enabling the function of answering calls in the background and sending paid interactive information such as paid call confirmation messages. The aforementioned speaker may include a built-in speaker configured on the called terminal itself, or an external speaker connected to the called terminal via wired or wireless means.

[0152] The aforementioned paid call notification information and other paid interactive information can be pre-set and stored on the called terminal or the server, or it can be generated in real time according to the actual scenario and needs. This application embodiment does not limit this, nor does it limit the specific content of the paid call notification information and other paid interactive information. Those skilled in the art can flexibly set it according to actual needs. Taking paid call notification information as an example, as long as the meaning expressed by its content is to remind the calling user to pay the call fee to remind the called user to answer the call, it should be within the protection scope of this application.

[0153] It should be noted that sending paid call notifications and other paid interactive information to the calling terminal via the call link can be understood as sending paid call notifications and other paid interactive information to the calling terminal via voice through the call link. For example, after the called terminal detects a call request, if it determines that the calling number is an unknown number and meets the conditions for paid call reception, then the paid call reception process will be triggered. For example, with the external voice acquisition link with the microphone turned off and the call playback link disconnected, the background connects the call and sends a paid call reception notification to the calling terminal via voice. The calling terminal will then hear the paid call reception notification, such as "The number you dialed has enabled the paid call reception function for unknown numbers. The cost for this call is 1 yuan. Please answer after payment. If there is no answer, the full amount will be refunded. Please answer whether you agree to pay." If the calling user answers "agree," the payment process can proceed. After payment, the called terminal will ring to remind the called user to answer.

[0154] This application embodiment connects incoming calls in the background and sends paid call notifications and other paid interactive information to the calling terminal via the call link. This effectively achieves efficient transmission of paid call notifications and other paid interactive information, regardless of whether a second calling application is installed on the calling terminal, ensuring high compatibility. Furthermore, sending paid call notifications and other paid interactive information via voice through the call link is more intuitive and efficient for the calling user, making it easier for them to accept. Additionally, connecting incoming calls in the background to send paid call notifications and other paid interactive information has another advantage: telecom operators have a certain waiting time (also called ringing time) for current call technologies. (Or ringing cycle) is used to limit the time from when the caller dials the number, when the phone starts ringing, until the call is answered or automatically disconnected after a timeout, such as 30 seconds, 45 seconds, etc. If the call is not answered within the waiting time, a busy tone will be displayed and the call will be automatically disconnected. However, the caller may not have enough time to complete the payment within this waiting time, resulting in the call being automatically disconnected, or the call may be automatically disconnected right after the payment is completed. This will seriously affect the caller's experience and may also cause the called party to miss the call. However, by automatically connecting the call in the background and sending paid answering reminders and other paid interaction information, the above-mentioned waiting time is skipped, avoiding the situation where the call is automatically disconnected. This ensures that the caller's call and payment can be completed smoothly and that the called party does not miss the call.

[0155] It should be noted that, since the above method has already connected the incoming call in the background and the external voice acquisition link and the call playback link are both disconnected, after the second incoming call reminder is triggered or the incoming call is connected, after detecting the called user's direct answering operation in response to the call request, it is also necessary to restore the external voice acquisition link and the call playback link to a working state. For example, by turning on the microphone and speaker, etc., to ensure that the called user can successfully communicate with the caller after performing the direct answering operation.

[0156] Regarding the second type of paid call notification method, the Interactive Voice Response System (IVR) is an automated voice response system, typically provided by telecommunications operators or third-party service providers. It is primarily used to automate telephone call processing, guiding users to complete specific operations through voice menus and button selections. The first call application or server provided in this embodiment can integrate with the IVR system provided by the telecommunications operator or third-party service provider via API or SDK to achieve the function of sending paid call notification information and other paid interactive information to the calling user. For example, if the calling number meets the conditions for paid call notification, the first call application will directly or through the server send a request to the IVR system, requesting the IVR system to send paid call notification information and other paid interactive information to the calling user. After receiving the request, the IVR system sends the notification information to the calling user. The system prompts the user to send a pre-recorded voice prompt (i.e., payment interaction information), such as: "The call you made requires a payment of 1 yuan to remind the other party to answer. Please press 1 to pay." The calling user follows the prompts of the IVR system, such as pressing the number key 1 to indicate agreement to pay the fee. The IVR system will then guide the user to select a payment method, such as payment via a payment link, SMS payment, or in-app payment. After the user selects a payment method and completes the payment, the IVR system will send payment confirmation information back to the first calling application. Upon receiving the payment confirmation information, the calling application will trigger an incoming call reminder on the called terminal, reminding the called user to answer the call. After the called user answers, the IVR system establishes a call connection between the calling user and the called user, and both parties can communicate normally.

[0157] It is worth noting that IVR systems are usually not limited by the operator's ringing duration. This means that after receiving the voice prompt from the IVR system, the calling user has ample time to decide whether to pay and to perform the payment operation, and ensures that the called terminal's call reminder is triggered only after the payment is confirmed. Since the traditional ringing duration is usually short, it may not be enough for the calling user to complete complex operations. However, the IVR system can provide a longer interaction time, ensuring that the calling user has enough time to make a decision and pay. This mechanism can not only improve the user experience, but also ensure the smooth operation of the paid call receiving process.

[0158] Furthermore, although this application embodiment utilizes an IVR system provided by a telecommunications operator or third-party service provider, it differs from existing IVR systems. Specifically, existing IVR systems provided by telecommunications operators or third-party service providers process incoming calls before the called terminal. After the calling user initiates a call, they first interact with the IVR system, and only after specific operations are performed will the call request be further transmitted to the called terminal. In contrast, this application embodiment places the interactive voice response process of the IVR system within the processing flow of the called terminal. The interactive voice response of the IVR system is only triggered after the called terminal detects that the calling number meets the conditions for paid call reception. The caller ID notification is triggered on the called terminal only after the IVR interaction ends. The advantage of this design is that the determination of whether the caller's number meets the conditions for paid call reception is performed locally on the called terminal. There is no need to upload the called terminal's contact information and paid call reception conditions to the telecom operator or third-party service provider for the determination of unknown numbers and whether they meet the conditions for paid call reception. On the one hand, this helps protect user privacy and reduce the risk of privacy leakage. On the other hand, it can reduce the dependence on telecom operators or third-party service providers and the resource requirements, and help reduce the complexity and implementation cost of building an IVR system with the help of telecom operators or third-party service providers.

[0159] In this implementation, by using an IVR system to send paid call notifications and other paid interactive information to the calling terminal, it ensures that when a calling user attempts to dial a called user's number, they immediately receive clear paid call notifications and understand the necessity of payment. This instant voice prompt is more intuitive and immediate than text messages or in-app notifications, quickly attracting the calling user's attention and guiding them to complete the payment operation, thus improving the timeliness and success rate of payment. At the same time, the IVR system can also provide multiple payment methods, allowing the calling user to choose the most convenient payment method according to their preferences, thereby improving the user's overall communication experience.

[0160] It should be noted that the above description uses IVR system services provided by telecom operators or third-party service providers as examples, but the implementation scheme of this application is not limited to this. The interactive voice response system provided in this application embodiment can be implemented using existing IVR systems provided by telecom operators or third-party service providers, or it can be implemented based on an interactive voice response system built into a call application or an interactive voice response system built on a server. For example, the calling terminal has a second call application installed, and the called terminal has a first call application installed. The second call application and the first call application can be connected through a call link to achieve telephone communication, or they can be connected through an Internet link to achieve the interaction of other information (such as key information). In the case of connecting through an Internet link, the two can be connected through a server.

[0161] Based on this, in some implementations, an interactive voice response system can be implemented through the collaborative work between the first call application and the second call application. This interactive voice response system can be called a built-in interactive voice response system. Accordingly, the aforementioned sending paid interactive information such as paid call notification information to the calling terminal through the interactive voice response system can include: sending paid interactive information such as paid call notification information to the calling terminal using the built-in interactive voice response system.

[0162] Among these, sending paid interactive information such as paid call notification messages using a built-in interactive voice response system can be achieved in at least the following exemplary ways:

[0163] The first interactive response method involves sending paid call notifications and other paid interactive information to the calling terminal via the call link when an incoming call is connected in the background. The calling terminal then plays the paid call notifications and other paid interactive information via voice and displays multiple buttons through a second call application. Each button corresponds to a different response, and different buttons correspond to different responses. At this time, the calling user can respond by clicking the buttons in the second call application, for example, by expressing a willingness to pay. The second call application sends the button click information (i.e., the response information) to the first call application via the Internet link. The first call application determines the calling user's willingness to pay based on the button click information from the second call application, thereby achieving the purpose of interactive response using the built-in interactive voice response system. Multiple rounds of interaction can be set according to actual needs, and this application embodiment does not limit this.

[0164] The first interactive response method is largely similar in technical concept to the aforementioned first paid call notification method, both being implemented in the background when an incoming call is connected. The difference lies in that, in the first paid call notification method, the calling user responds via voice, and the response information (voice signal) is fed back to the called terminal through the call link. The called terminal uses voice recognition technology to identify the response information and determine the calling user's willingness to pay. In contrast, in the aforementioned first interactive response method, the calling user responds via buttons, and the response information (button click information) is fed back to the called terminal through the internet link. The called terminal determines the calling user's willingness to pay based on the button click information.

[0165] The first interactive response method described above sends paid interactive information, such as a paid call notification, to the calling terminal via the call link when an incoming call is connected in the background. This avoids the problem of automatic disconnection due to excessively long interaction times exceeding the waiting period, thus ensuring the smooth completion of the interactive response process. Compared to implementing an interactive voice response system through telecommunications operators or third-party service providers, this implementation method is less difficult and less costly to implement.

[0166] It should be noted that, when using the first interactive response method described above, it is also necessary to restore the external voice acquisition link and the call playback link to a smooth state after detecting the called user's direct answering operation in response to the call request. For example, the microphone and speaker can be turned on to ensure that the called user can successfully communicate with the calling user after performing the direct answering operation.

[0167] The second interactive response method involves the called terminal sending paid call notification information, such as a paid call confirmation message, to the calling terminal via an internet link while the call is on hold. This paid interactive information can include voice or text messages. The calling terminal can play the paid interactive information via voice or display it in a second calling application. The second calling application displays multiple buttons, each corresponding to a different response. The calling user can respond by clicking the buttons in the second calling application, for example, by expressing a willingness to pay. The second calling application sends the button click information (i.e., the response information) to the first calling application via an internet link. The first calling application determines the calling user's willingness to pay based on the button click information from the second calling application, thereby achieving the purpose of interactive response using a built-in interactive voice response system. Multiple rounds of interaction can be set according to actual needs, and this application embodiment does not limit this.

[0168] In the second interactive response method described above, the interactive response process between the called and called terminals is achieved through the internet link, thus eliminating the need to connect the incoming call. Compared to implementing an interactive voice response system through telecommunications operators or third-party service providers, this implementation method is less difficult and less costly to implement.

[0169] It should be noted that, in the embodiments of this application, "link" refers to a physical or logical connection between two nodes in communication and network technologies used for data transmission. This can be a physical link, a logical link, or a combination of both. A physical link refers to an actual hardware connection, such as wires, optical fibers, or radio waves. These media are responsible for transmitting electrical or optical signals between two nodes. For example, in a telephone network, a physical link consists of telephone lines or optical fibers; while in a wireless network, a physical link consists of radio waves or microwaves. A logical link is a set of rules and protocols built upon a physical link to ensure that data is transmitted in an orderly manner. A logical link can span multiple physical links and optimize data transmission efficiency through mechanisms such as routing and flow control. For example, in a computer network, a logical link can be implemented through the data link layer of the TCP / IP protocol stack to ensure that data packets correctly reach their destination.

[0170] In this application embodiment, both the call link and the Internet link can be constructed based on the above physical links and / or logical links. The call link specifically refers to the connection path used to transmit voice data, ensuring real-time voice communication between the calling terminal and the called terminal. The connection between the calling terminal and the called terminal can be established and maintained based on traditional telephone networks (PSTN, Public Switched Telephone Network), mobile phone networks, and Voice over Internet Protocol (VoIP) services, ensuring that both parties can conduct real-time voice communication. An internet link refers to a data transmission path established between two terminals via internet protocols (such as TCP / IP). It is suitable for various types of data transmission, including but not limited to web browsing, file downloading, and instant messaging. Internet links have high versatility and flexibility, supporting a wide range of applications and services. They are not limited to specific types of data but can carry any form of digital information, such as text and multimedia content. The advantages of internet links lie in their wide coverage and high interoperability, enabling users to access global network resources anytime, anywhere. For the transmission of paid interactive information, internet links can provide additional information interaction channels, such as key presses and payment links. This information can be transmitted between the calling and called terminals via push notifications, SMS messages, or in-application messages.

[0171] The third interactive response method involves the following: When a calling user dials a number from a second calling application to a called user, the second calling application does not initiate the call immediately. Instead, it first queries the first calling application through the server to determine whether the calling number meets the paid call conditions set by the called terminal. In other words, it checks whether the calling number requires a paid call for the called number, or whether the calling number needs to pay a call fee to the called number. These three statements have the same meaning. If the conditions for paid call are met, the second calling application calls the built-in interactive voice response system to directly broadcast the message on the calling terminal and interacts with the calling user based on the key input. These interactions include, but are not limited to, agreeing to payment, selecting a payment method, and initiating a payment application. After payment is completed, a call is initiated to the called number. Since payment has already been completed, the called number, upon receiving the call request and detecting that the calling number meets the paid call conditions and has confirmed payment, can directly trigger a second call notification or answer the call. Compared to implementing an interactive voice response system through telecom operators or third-party service providers, this implementation method is less difficult and less costly. Since payment is confirmed before the call is initiated, and no call is initiated without payment confirmation, some calls can be filtered at the calling terminal's source, reducing the actual number of calls made by the calling terminal and lowering the load on the telecom network. Furthermore, this method is not limited by the telecom operator's ringing duration, ensuring that the calling user has sufficient time to make a decision and pay, thereby improving the user's calling experience. Additionally, compared to the first paid call confirmation method, since no actual call is initiated before payment, the called terminal's background call connection function is not triggered, thus avoiding call charges and helping to save call costs for the calling user. It is important to note that the aforementioned call charges refer to the fees that users need to pay to telecom operators when using mobile phones, landlines, or other communication services. This is different from the call confirmation fee paid to the called user in this application. The payment objects and purposes are different, and they belong to completely different technical concepts and should not be confused.

[0172] It should be noted that sending paid call notifications to the calling terminal through the built-in interactive voice response system of the calling application has another advantage: since the calling application is self-developed, it can not only broadcast paid call notifications and other paid interactive information via voice, but also display such notifications and other paid interactive information on the display interface of the second calling application. This ensures the accuracy and intuitiveness of information transmission. Furthermore, since the reading speed of visual information is higher than the listening speed of voice information, it also helps to improve call efficiency and user call experience.

[0173] In the above example, the built-in interactive voice response system of the call application is used as an example for illustration. Those skilled in the art can build an interactive voice response system on the server side based on the above exemplary description and by changing the technical elements and processes to realize the transmission of the above paid call notification information and the interaction with the caller. It will not be elaborated here, and it should also be within the protection scope of this application.

[0174] For the third type of paid call notification method, in-app notification refers to sending notifications or prompts to the calling terminal through the message push function within the application. For example, the first calling application can use in-app notification to send paid call notifications and other paid interactive information to the second calling application, and display it on the calling terminal's display interface. Since the reading speed of visual information is higher than the listening speed of voice information, this implementation method has high intuitiveness and also helps to improve call efficiency and user call experience.

[0175] The fourth method of paid call notification utilizes SMS service in mobile communication networks. An SMS message containing paid call notification information and other paid interaction information is sent to the calling terminal. Upon seeing the SMS, the calling user can directly click the response link or reply to the SMS. The first call application or server can identify the calling user's payment intent based on the content of the response link or reply. The SMS sent to the calling terminal can contain multiple response links, each corresponding to different response information. Thus, after the calling user clicks a response link, the called terminal can determine the calling user's response information by detecting the trigger information of each response link, thereby identifying the calling user's payment intent.

[0176] It should be noted that the above four methods of providing paid call notifications can be implemented individually or in combination without conflict. For example, when both the calling and called terminals have corresponding calling applications installed, the call application's built-in interactive voice response system can be used to send paid call notification information to the calling terminal, or in-application notifications can be used simultaneously. This increases the delivery rate of paid call notification information through multiple methods. Those skilled in the art can expand upon this example, and this embodiment is not limited. Furthermore, inspired by the above four methods, those skilled in the art can also use other modified methods to send paid call notification information to the calling terminal. These will not be elaborated here, but all should be within the scope of protection of this application under the same technical concept.

[0177] Furthermore, the first calling application can also simultaneously support multiple paid information interaction methods (such as paid call notification methods). Before the paid information interaction step (such as the paid call notification step), it first detects the device information and call environment of the calling terminal, such as whether a second calling application is installed. Based on at least one of the priority of the device information, call environment, and pre-set paid information interaction methods (such as paid call notification methods), it selects an appropriate paid information interaction method (such as paid call notification method) to send paid interaction information (such as paid call notification information) to the calling terminal, so as to perform paid call notification and other paid information interaction to the calling terminal. For example, if the calling terminal has a second calling application installed, the interactive voice response system built into the calling application is used first to send paid call notification information to the calling terminal. Examples will not be listed here. Those skilled in the art can make reasonable extensions and modifications based on the above examples, and all of them should be within the protection scope of this application.

[0178] It should be noted that after receiving and playing or displaying the aforementioned paid call notification, the calling terminal generally needs to confirm whether it agrees to pay the call fee and reply to the called terminal. This allows the called terminal to continue the call process based on the "agree to pay" message and to reject the call request based on the "reject" message indicating disagreement. The calling user can trigger the reply (i.e., response message) through keypad reply, in-app confirmation, or voice response. This reply message can be either an agreement to pay or a rejection of payment. Keypad reply refers to the calling user generating a reply message by operating a designated key on the calling terminal. It can respond to all of the aforementioned paid call notification methods, making it a simple, convenient, and highly versatile reply method that requires no additional equipment or software support and is suitable for all types of calling terminals. If both the calling and called terminals have the same calling application installed, in-app confirmation is also a convenient and secure method. For example, when the calling terminal receives a paid call notification, the calling application will display a selection interface on the calling terminal's screen, prompting the user to choose to agree to or refuse payment, and providing corresponding selection controls. The calling user can then use these controls to choose to agree to or refuse payment. If the calling user chooses to agree to payment, the calling application will generate an agreement to payment information and send it to the called terminal; if the calling user chooses to refuse payment, it will generate a refusal to payment information and send it to the called terminal. The advantage of this method is that it provides a good user experience, an intuitive interface, and can provide more content within the interface, such as payment platform interfaces, to allow the calling user to make payment directly without having to select an agreement to payment option, thereby simplifying the overall process. Voice response refers to the calling user expressing their willingness to pay through voice response. For example, when sending a paid call notification through a call link, the calling user can respond with voice to indicate whether they agree to pay or refuse to pay. The called terminal or server can confirm the calling user's intention through voice recognition and generate payment agreement or payment refusal information. This method is suitable for users who cannot or are inconvenient to use button operation, such as while driving or when their hands are inconvenient, and has a high degree of naturalness and flexibility.

[0179] To enable paid call reception, the called terminal should also send payment guidance information to the calling terminal, so that the calling terminal can pay the call reception fee according to the payment guidance information. Accordingly, based on any of the aforementioned implementation methods, the payment information interaction step may also include a payment guidance information sending step. This payment guidance information sending step may include: sending payment guidance information to the calling terminal corresponding to the calling number through a preset payment guidance information sending method, so that the calling user can pay the call reception fee to the called user according to the payment guidance information. The payment guidance information sending method includes at least one of the following:

[0180] The first method of sending payment guidance information is to send payment guidance information to the calling terminal via SMS; the second method is to send payment guidance information to the calling terminal via in-app notification; the third method is to send payment guidance information to the calling terminal via voice message.

[0181] The payment guidance information sending method refers to the paid information interaction method for sending payment guidance information. The payment guidance information is used to guide the caller to pay the call reception fee. Specifically, it may include payment parameters required for the caller to pay the call reception fee, typically including at least one of the following: receiving account, payment amount, payment method, payment link, and payment order number, to ensure the caller can successfully complete the payment operation. Specifically, the receiving account can be the account set up by the called user to collect the call reception fee, i.e., the first account mentioned in the previous embodiment. With a payment platform as an intermediary, the receiving account can also be the intermediary account corresponding to the payment platform; this application embodiment does not limit this. The payment amount is the specific call reception fee that the caller needs to pay. The payment method is the method the caller can choose to make the payment, which may include multiple payment options so that the caller can choose the most convenient method. Common payment methods include, but are not limited to, bank transfer, third-party payment platforms (such as Alipay, WeChat Pay, etc.), and credit card payment. Each payment method will provide corresponding payment guidance to help the caller complete the payment operation. The payment link is a link that can be clicked directly to make the payment, simplifying the payment process. The caller can access the payment link directly. Clicking the link redirects directly to the payment page for payment. The payment link is typically generated by the payment platform and transmitted to the calling user via a secure, encrypted channel, ensuring the security of the payment process. The payment order number is a unique identifier for each call. The called terminal or server can generate a payment order (also known as a paid call receipt order) for each call meeting the conditions for paid call reception, either directly or through a third-party payment platform, and send the unique payment order number (also known as the paid call receipt order number) to the calling terminal. The calling terminal can then directly invoke the payment order and make the payment based on the payment order number. Those skilled in the art can flexibly configure the content of the above payment guidance information according to the payment environment and actual needs to enable the calling user to pay the called user for call reception fees based on the payment guidance information. In some specific examples, to enhance security, complete account information is usually not sent directly; instead, a one-time payment link, payment order number, or other security mechanisms are used to protect account information from disclosure.

[0182] For the first method of sending payment guidance information mentioned above, payment guidance information is sent to the calling terminal via SMS. This method utilizes the SMS service in the mobile communication network to send an SMS containing payment guidance information such as a payment link and payment amount to the calling user. After receiving the SMS, the calling user can directly click on the payment link to jump to the payment page, or follow the instructions in the SMS to complete the payment operation. For example, the SMS content may be: "The call you made requires a payment of 1 yuan to remind the other party to answer. Please click the following link to make the payment: [Payment Link]".

[0183] Regarding the second method of sending payment guidance information, payment guidance information is sent to the calling terminal via in-app notification. If both the calling and called users have the same calling app installed, payment guidance information can be sent via push notification within the app. This notification usually appears in the user's phone notification bar, and when the user opens the calling app, they can see detailed payment information within the app. This method provides a richer interactive experience, such as completing the payment directly within the app without being redirected to an external website or app. For example, the in-app notification might display: "The call you made requires a payment of 1 yuan to remind the other party to answer. Please click here to make the payment."

[0184] Regarding the third method of sending payment guidance information, payment guidance information is sent to the calling terminal via voice information. In this method, voice information can be sent directly to the calling terminal via voice broadcast or through the interactive voice response system mentioned in the foregoing embodiments of this application to inform the calling user that a fee needs to be paid to continue the call. The voice information may include the payment amount, payment method, and specific steps on how to complete the payment. For example, the voice prompt may be: "The call you made requires a payment of 1 yuan to remind the other party to answer. Please press 1 to pay." The calling user operates according to the voice prompt, selects the payment method, and completes the payment.

[0185] By using the aforementioned methods of sending payment guidance information, it is possible to ensure that the calling user receives the payment guidance information in a timely manner and can complete the payment operation conveniently and quickly. Among them, sending payment guidance information via SMS can cover a wide range of users and improve payment accessibility, especially for calling users who do not have specific calling applications installed, allowing them to complete the payment without obstacles, thus demonstrating high compatibility and universality. Sending payment guidance information via in-app notifications can provide a more secure and convenient payment experience, enhancing user trust. Sending payment guidance information via voice message can ensure immediacy and intuitiveness, improving the success rate of payments.

[0186] It should be noted that the above-mentioned methods for sending payment guidance information can be implemented individually or in combination without conflict, and this embodiment does not impose any limitations. Furthermore, those skilled in the art can also employ other modified methods to send payment guidance information to the calling terminal, inspired by the above-mentioned methods. These will not be elaborated upon here, but all should fall within the scope of protection of this application under the same technical concept.

[0187] Furthermore, the first calling application can also support multiple payment guidance information sending methods simultaneously. Before sending the payment guidance information, it first detects the calling terminal's payment environment (e.g., device information), such as whether a second calling application or a payment application is installed. Based on the calling terminal's payment environment (e.g., device information) and / or the priority of pre-set payment guidance information sending methods, it selects an appropriate payment guidance information sending method to send the payment guidance information to the calling terminal, so that the calling user can pay the callee's call fee according to the payment guidance information. For example, if the calling terminal does not have a second calling application installed, the payment guidance information is sent to the calling terminal via SMS first. If the calling terminal has a second calling application installed, the payment guidance information is sent to the calling terminal via in-app notification first, and so on. These are just a few examples; those skilled in the art can make reasonable extensions and modifications based on the above examples, and all of them should be within the protection scope of this application.

[0188] It should be noted that the above-mentioned payment guidance information sending step can be performed sequentially or simultaneously with the paid call confirmation step. That is, the payment guidance information can be sent after the paid call confirmation information or sent together with it. For example, the paid call confirmation information can be sent to the calling terminal first, and the payment guidance information can be triggered after receiving feedback from the calling terminal agreeing to the payment. Alternatively, the payment guidance information can be sent to the calling terminal together with the paid call confirmation information. In this way, the calling user can directly make the payment if they agree to it, which is more efficient and helps to improve the calling efficiency and user experience of the calling user. Those skilled in the art can make reasonable extensions and modifications based on the above examples, and all of them should be within the protection scope of this application.

[0189] Furthermore, the call reception fee paid by the calling user to the called user can be paid directly, such as by the calling user's second account directly to the called user's first account, or it can be paid indirectly, such as by the calling user's second account first paying an intermediary account, and then by the intermediary account paying the called user's first account. As long as the called user ultimately benefits from receiving the call, the payment confirmation information can be generated based on the calling user's payment behavior or after the call reception fee reaches the called user's account. That is, the payment confirmation information can be generated after the calling user completes the payment to the intermediary account or after the intermediary account completes the payment to the called user. This application embodiment does not limit this. Furthermore, the caller's payment to the called user for answering the call can be paid in full or in part to the called user. For example, part of the caller's payment can be given to the called user, and the other part can be given to the service account of the first call application as a technical service fee. Neither of these methods harms the called user's purpose as a beneficiary of the paid call, and both are consistent with the inventive purpose of the embodiments of this application and should be within the protection scope of this application.

[0190] It should be noted that the payment confirmation information in this application embodiment can be payment completion information, that is, information confirming that the calling user has completed payment, indicating that the receiving fee corresponding to the calling number has been paid. The payment completion information can be triggered based on the calling user's payment behavior, for example, it can be triggered after the calling user completes payment to the intermediary account, or it can be triggered after the receiving fee reaches the called user's account, for example, it can be triggered after the intermediary account completes payment to the called user, thus ensuring that the called user can receive the receiving fee before triggering the second call reminder or connecting the call. In addition, the payment confirmation information can also be payment commitment information, that is, information confirming that the calling user will make payment, indicating that the calling user promises to pay the receiving fee for this call, thus triggering the second call reminder or connecting the call first when the calling user promises to pay, and then making payment after the call ends. By moving the payment process to the end of the call, call efficiency can be effectively improved. Both of the above methods can be used to achieve the purpose of this application embodiment, which will be described below.

[0191] In the first scenario, the payment confirmation information can be payment completion information, which confirms that the payment has been successfully completed. This information can be generated by the payment platform (such as a bank or third-party payment system) and sent to the called terminal's server or the first call application via a secure channel. Alternatively, the first call application or server can detect payment completion by monitoring the transaction information of the called user's first account. For example, it can query the transaction information for payment completion corresponding to the calling number. If found, a second call reminder or call can be triggered. Furthermore, any existing method for obtaining payment completion information can be used; these are all within the scope of this application and will not be elaborated upon here. Payment completion information may include, but is not limited to, key data such as payment status, payment amount, payment timestamp, payment transaction ID (i.e., payment order number), and the calling number associated with the payment. Once the called terminal obtains and verifies the payment completion information, confirming that the payment has indeed been completed, it will then lift the call silence and trigger a second call reminder or call can be answered. This method ensures that the called user receives payment before making a call, thus protecting the rights of the called user.

[0192] In the second scenario, the payment confirmation information can be a payment commitment. A payment commitment refers to the caller's confirmation that they will make the payment. In this case, the caller has not yet actually completed the payment operation, but has clearly indicated their willingness to pay the call fee. The payment commitment can be transmitted in various ways, such as via keypad reply, in-app confirmation, or voice response. After receiving the payment commitment, the called terminal can temporarily lift the call silence and trigger a second call notification or answer the call. This method provides a faster response time and helps improve call efficiency. It is easy to understand that this method is more suitable for users with high trust levels, or for situations where a call needs to be established quickly in an emergency, but it is also applicable in other situations.

[0193] Based on the above description of payment confirmation information, this application embodiment supports at least two paid call answering modes: one is a prepayment-before-answering mode, in which the payment confirmation information is payment completion information; the other is a pay-after-answering mode, in which the payment confirmation information is payment commitment information. In specific implementation, the above paid call answering modes can be provided to users for selection. Users can choose to accept one of the paid call answering modes, or they can choose to accept both of the above paid call answering modes. Different paid call answering modes can also be set for different number categories. In addition, different paid call answering modes can also be set according to the caller's credit information. For example, for lost number codes and fraudulent calls, only the prepayment-before-answering mode is supported, while for unclassified calls and non-lost number codes, both of the above paid call answering modes are supported. After the settings are completed, the paid call answering process can be executed according to the paid call answering mode selected by the user, and a suitable paid call answering mode can be provided for the caller to make a call based on the caller's number category and credit information.

[0194] In some specific implementations, the called terminal can send payment timing option information to the calling terminal through a payment timing sending step. This payment timing option information includes a variety of selectable payment timing options, which may include, but are not limited to, at least one of the following:

[0195] The first option indicates a postpaid option where you pay for the incoming call after the call ends; the second option indicates a prepaid option where you pay for the incoming call before triggering a second call notification or connecting the call.

[0196] The aforementioned payment timing option information can be sent separately, for example, after the paid call notification step, or it can be sent together with the aforementioned paid call notification information or payment guidance information, or it can be sent as part of the aforementioned paid call notification information or payment guidance information. This application embodiment does not limit this. After the calling terminal plays or displays the aforementioned payment timing option information, the calling user can choose a payment timing option that suits them. If the calling user chooses the postpaid option, the payment commitment information will be triggered. If the calling user chooses the prepaid option, payment needs to be made, and the payment completion information will be triggered after the payment is completed. It should be noted that the aforementioned postpaid option and prepaid option can be displayed or played together, or one of them can be displayed or played separately. For example, only the postpaid option can be displayed, or payment method options (such as bank transfer, third-party payment, in-app wallet payment, etc.) can be displayed at the same time. The aforementioned payment method option can also implicitly indicate the meaning of paying before answering the call, or it can be regarded as a prepaid option, only combined with a specific payment method.

[0197] Corresponding to the above-mentioned paid call notification method, the payment timing option information can also be sent to the calling terminal through at least one payment timing sending method. The payment information interaction step may include a payment timing sending step, which may include: sending payment timing option information to the calling terminal corresponding to the calling number through a preset payment timing sending method. The payment timing option information is used to provide at least one payment timing option for the calling user to choose from. The payment timing sending method includes at least one of the following:

[0198] The first method of sending payment timing information is to send payment timing option information to the calling terminal via a call link; the second method is to send payment timing option information to the calling terminal via an interactive voice response system; the third method is to send payment timing option information to the calling terminal via in-app notification; and the fourth method is to send payment timing option information to the calling terminal via SMS.

[0199] In practical implementation, the above-mentioned methods for sending payment notifications can correspond to the aforementioned paid call notification methods. For example, when using the first paid call notification method, a call link has already been established between the calling terminal and the called terminal, indicating that the current scenario is suitable for transmitting information through the call link; therefore, the first payment notification method is adopted. Similarly, when using the second paid call notification method, it indicates that the interactive voice response system is available, indicating that the current scenario is suitable for transmitting information through the interactive voice response system; therefore, the second payment notification method is adopted. Furthermore, when using the third paid call notification method, it indicates that the calling terminal also has the corresponding calling application installed, indicating that the current scenario is suitable for transmitting information through in-application notifications; therefore, the third payment notification method is adopted, and so on. For detailed explanations of the implementation methods and advantages / disadvantages of the above-mentioned multiple payment notification methods, please refer to the aforementioned explanations of the corresponding paid call notification methods; they will not be repeated here.

[0200] Building upon the above, calling users can trigger payment commitments through methods such as key presses, in-app confirmation, or voice responses. Key presses, where the calling user initiates the payment commitment by pressing a designated key on their device, are applicable to all payment timing methods and are a simple, convenient, and versatile response method that requires no additional equipment or software support, making it suitable for all types of calling devices. If both the calling and called devices have the same calling app installed, in-app confirmation is also a convenient and secure method. For example, after receiving the payment timing option, the calling app displays a selection interface on the calling device's screen, prompting the user to choose a payment timing and providing selection controls. The calling user can then select the desired payment timing option. The calling app records the calling user's payment intention and generates a payment commitment message for the called device if the user selects a postpaid option. This method offers the advantages of a good user experience, an intuitive interface, and the ability to integrate more payment options, such as in-app payment links or third-party payment platform interfaces, thus simplifying the payment process. Voice response refers to the caller expressing their willingness to pay through voice. For example, when sending payment timing options via a call link, the caller can reply with a voice indicating their willingness to pay the call fee after the call ends. The called terminal or server can confirm the caller's intention through voice recognition and generate a payment commitment. This method is suitable for users who cannot or are unable to use button operations, such as while driving or when their hands are unavailable, offering high naturalness and flexibility. In some examples, after receiving a paid call notification, the calling terminal will play or display the notification. The caller can reply to the notification. After receiving the payment agreement from the calling terminal, the called terminal will then send payment timing options to the calling terminal. After playing or displaying these options, the caller can select the desired payment timing option and reply. If the caller selects the postpaid option, a payment commitment will be generated on either the calling or called terminal. The called terminal can then trigger a second call notification or answer the call based on this payment commitment.

[0201] Since the promised payment information indicates that the caller is willing to pay the call fee, but the payment has not yet been actually completed, the aforementioned payment guidance information sending step needs to be performed after the call ends. This serves two purposes: firstly, it provides the caller with payment guidance information so that the caller can pay the call fee according to the payment guidance information; secondly, it also serves as a reminder to the caller to pay, reducing the probability that the caller will forget to pay the call fee after hanging up the phone.

[0202] Furthermore, to prevent caller default, a follow-up mechanism is needed to monitor and verify whether the actual payment is completed on time. If the payment is not completed, corresponding measures need to be taken, such as restricting future call requests or issuing a payment reminder to the caller. Therefore, in some implementations, the payment confirmation information includes promised payment information. Correspondingly, the method may also include: after the call ends, executing default handling steps based on the promised payment information, the default handling steps including at least one of the following:

[0203] If the promised payment information is not fulfilled within the first time limit, a call charge collection reminder message is sent to the calling terminal. The call charge collection reminder message is used to remind the calling user to pay the call charge for this call. If the promised payment information is not fulfilled within the second time limit, a default information message for the calling number is sent to the server. The default information message is used to restrict other called terminals connected to the server from receiving calls from the calling number.

[0204] The first time limit refers to a pre-set, relatively short period within which the calling user must complete payment. Failure to pay within the first time limit is considered a breach of contract. The second time limit refers to a pre-set, relatively long period beyond which payment is considered a serious breach of contract. The second time limit is longer than the first time limit. The call charge collection reminder message is a notification sent to the calling user, reminding them to pay the call charge. The default information records information about the calling user's failure to fulfill payment commitments. This may include a default flag marking the calling user and / or the calling number as untrustworthy. The user and number marked as untrustworthy are referred to as the defaulting user and defaulting number, respectively. Call restrictions refer to limiting subsequent calls from defaulting numbers and / or defaulting users. Examples include rejecting the current call from the calling number, canceling the calling number's postpayment privileges, requiring the calling user to pay any outstanding call charges before continuing to call, and increasing the call charge for the calling number. Call restrictions can be imposed on defaulting numbers and defaulting users using at least one of the above methods.

[0205] This approach effectively manages the payment behavior of callers, ensuring the rights of called users are protected. Specifically, timely sending of call charge reminders prompts encourages callers to complete payments as soon as possible, thereby increasing the payment rate. For users who consistently fail to fulfill their payment commitments, they can be marked as defaulters or their caller ID numbers can be flagged as untrustworthy, with corresponding restrictions imposed to effectively prevent malicious behavior. A strict default handling mechanism enhances the trustworthiness of the entire paid call service, encouraging more users to utilize the service. The entire default handling process can be automated, reducing manual intervention, improving efficiency, and lowering operating costs. Based on the above, this implementation method can take effective default handling measures when callers fail to fulfill their payment commitments on time, protecting the rights of called users, maintaining the healthy operation of the entire paid call service mechanism, improving user experience and trustworthiness, and achieving an efficient, convenient, and secure paid call service process.

[0206] In some modified implementations, before executing the first incoming call reminder, the method may further include: detecting whether the calling number is a lost signal code; if the calling number is detected to be a lost signal code, restricting the calling number from receiving calls; if the calling number is detected not to be a lost signal code, triggering the first incoming call reminder.

[0207] The detection of whether the calling number is a lost signal code can be achieved by sending a lost signal code query request for the calling number to the server. After receiving the query request, the server can query the database to see if the calling number corresponds to any lost signal information. If there is lost signal information, the server determines that the calling number is a lost signal code; otherwise, it determines that the calling number is not a lost signal code. The server then feeds back the determination result indicating whether the calling number is a lost signal code to the called terminal. Alternatively, the server can feed back the query result indicating whether the calling number corresponds to any lost signal information to the called terminal, which can then determine whether the calling number is a lost signal code based on the query result. Both methods can achieve the purpose of this application embodiment and should be within the protection scope of this application.

[0208] The above-mentioned call receiving restrictions can be implemented using at least one of the following methods: rejecting the current call from the calling number, canceling the calling number's postpayment privileges, requiring the calling user to pay any unpaid call charges before continuing to call, and increasing the call receiving charges payable by the calling number.

[0209] The first call restriction method: Call Rejection. This method directly rejects the incoming call from the calling number. It completely prevents interference from untrusted sources, ensuring only trusted calls can access the user's communication environment. Simultaneously, it conveys a clear message to the calling user: due to previous non-payment commitments, the current call attempt has been rejected, which helps prompt the calling user to resolve historical debts as soon as possible. Furthermore, a call restriction reminder message can be sent through an interactive voice response system or a second-party calling application. This reminder message serves to remind the calling user that they must pay any outstanding call charges before the call restriction can be lifted.

[0210] The second call answering restriction method: cancel the caller ID's post-payment permission. Under this method, the "answer first, pay later" model is not supported; the paid call answering process can only be executed according to the "pay first, answer later" model. The caller must prepay the call answering fee as a guarantee to trigger the called party's call reminder function, thus preventing lost signal numbers from using the "reminder first, pay later" method for calls. This method ensures that the call answering fee is safely credited before the call begins, reducing the risk of subsequent collection efforts.

[0211] The third method of call restriction: The caller must pay any outstanding call charges before continuing to call. This method proactively reminds the caller to pay any outstanding charges as a prerequisite for continuing the call. It aims not only to recover past debts but also to give the caller an opportunity to rectify the situation and encourage compliance with established payment rules. Once the caller completes payment, their number can be removed from the blacklist, restoring their normal communication rights. Therefore, this method protects the rights of the called party while providing flexibility, making it suitable for situations where breaches of contract may be due to negligence rather than intentional misconduct, and helps rebuild trust between the two parties.

[0212] The fourth method of caller ID restriction involves increasing the caller ID fee. Under this method, higher fees can be set for callers who frequently breach contracts or are repeatedly listed on blacklists, increasing the cost of repeat calls. This serves as a deterrent and filters out callers with genuine urgent needs who are willing to pay the higher cost. The higher fee threshold effectively reduces unnecessary harassing calls, protects the privacy and time of the called party, and provides a way for users who occasionally breach contracts but wish to regain trust to demonstrate their sincerity by paying a higher fee and gradually restore normal communication privileges.

[0213] The call-receiving restrictions in this application embodiment can be flexibly set and extended based on the above-mentioned various call-receiving restriction methods, combined with actual needs. This application embodiment does not limit these methods. The various call-receiving restriction methods can be implemented in combination or in stages according to the degree of restriction. For example, the degree of restriction may be directly proportional to the number of breaches of trust or the degree of breach of trust; the more breaches of trust or the higher the degree of breach of trust, the more severe the restriction. Conversely, the fewer breaches of trust or the lower the degree of breach of trust, the lighter the restriction. Callers can remove the breach of trust label and call-receiving restrictions by paying previously unpaid call fees, or by increasing the number of times or percentage of fulfilled obligations to reduce the degree of restriction. All of these measures can effectively urge callers to pay call fees promptly, ensuring that called users receive call compensation.

[0214] It should be noted that the aforementioned payment confirmation information only needs to correspond to the calling number. This application embodiment does not limit the payment entity that performs the payment behavior. The payment entity can be the calling terminal, the payment device, or the server, etc. Correspondingly, the aforementioned payment confirmation information can be generated based on the payment behavior of the calling terminal, or based on the payment behavior of other payment devices, or generated by the server deducting from a designated account according to the deduction agreement corresponding to the calling number, or generated based on an automatic payment mechanism, etc. This application embodiment does not limit this, as long as the payment confirmation information is associated with the calling number and can indicate that it is used to pay for the calling behavior of the calling number to the called number. Furthermore, the payment confirmation information and the caller ID number can be directly or indirectly associated. For example, when a caller makes a payment, the second call application can automatically add the caller ID number as a payment note. After the payment is completed, the payment confirmation information carries the aforementioned payment note information, and the called terminal can determine that the payment completion information is associated with the caller ID number based on the payment note information. Alternatively, the called terminal or server can generate a payment order for the caller ID number based on the call request. After the caller terminal makes the payment based on the payment order, the payment confirmation information can be indirectly associated with the caller ID number based on the payment order. The above are merely exemplary descriptions of associating payment confirmation information with the caller ID number. Those skilled in the art can implement this directly or with modifications, and all such implementations should be within the scope of protection of this application.

[0215] In addition, when the called terminal supports multi-card services, as a non-essential implementation method, in order to make the payment purpose of the payment confirmation information clearer, the payment confirmation information can also be associated with the called number. For example, by adding the called number to the above-mentioned payment remarks information to directly associate the payment confirmation information with the called number, or by indirectly associating the payment confirmation information with the called number through the payment order, etc. This application will not elaborate on each of these, and they should all be within the protection scope of this application.

[0216] It should be noted that the calling number can be a mobile phone number, a landline number, or a virtual number. This application embodiment does not limit the number, and all of them are applicable to the call processing solution provided in this application.

[0217] In some application scenarios, the calling number can be a fixed number, and the calling terminal can be a landline or other communication device that does not have independent payment capabilities. To enable payment of call charges in such cases, some embodiments of this application support a payment device to pay call charges on behalf of the calling terminal that does not have independent payment capabilities. Accordingly, in the prepaid-after-answer mode, the payment confirmation information can be payment completion information generated based on the call charges paid by the payment device, thus enabling calls to the called number to be made even when the calling terminal does not support payment functionality. In addition, the payment device can also make payments on behalf of the calling terminal after the call ends in the prepaid-after-answer mode, which is also within the scope of protection of this application. It should be noted that the payment device provided in the embodiments of this application can be a terminal device such as a mobile phone, tablet computer, laptop computer, desktop computer, etc., or a server-side device such as a server. It can be a device with payment functionality set up on the calling user side, such as the management machine of a call center, the back-end service device of call software, etc., or a payment device provided on the server side specifically for providing payment services to users, etc., which is not limited in the embodiments of this application.

[0218] In some application scenarios, the calling number can also be a virtual number. A virtual number refers to a phone number generated through technical means that does not directly correspond to a physical telephone line or actual SIM card. These numbers are usually assigned to users by service providers and can be used in various application scenarios, such as for privacy protection, temporary communication, or as an intermediary number to mask the real contact information of both parties. The calling terminal corresponding to the virtual number refers to the device that actually initiates the call. This can be any device capable of making calls via the Internet or telephone network, such as smartphones, tablets, landlines, or even dedicated communication devices. When a user makes a call using a virtual number, the user's actual call request is first routed to the platform providing the virtual number service, and then the platform forwards the call to the target called party, i.e., the called terminal, according to preset rules. In addition, when a calling user initiates a call using a virtual number, a payment device can be used to pay the call charges on their behalf, which can also achieve the purpose of this invention and should be within the scope of protection of this application.

[0219] To simplify the payment process and improve user experience, this application embodiment also provides an automatic payment mechanism. When a calling number initiates a call, if the conditions for paid call reception are met, the corresponding reception fee can be deducted directly from the payment account pre-linked to the calling number, either directly or after confirmation by the calling user. This eliminates the need for the calling user to manually pay each time. After automatic payment is completed, a payment confirmation message can be generated to further trigger call notifications on the called terminal. An exemplary implementation of the automatic payment mechanism is as follows:

[0220] First, the administrator of the calling number can enable the automatic payment function and bind a payment account according to the automatic payment agreement. This payment account can be a bank account, credit card account, third-party payment platform account, or a call platform account opened on the call application server; this embodiment does not limit this. For individual users, the automatic payment function can be enabled and a payment account bound in a second call application. For company users, the administrator can sign the automatic payment agreement through the management webpage or client provided by the server to enable the automatic payment function and bind a payment account. Multiple phone numbers can be bound to the same payment account to meet the company's need for unified payment of call reception fees for outbound calls initiated by employees. For example, for a company-managed telemarketing platform or team, multiple phone numbers of the telemarketing team can be bound to the company's centralized management payment account. Furthermore, the payment account bound to the same phone number is not limited to one; for example, it can include a primary payment account and a backup payment account to ensure smooth payment of call reception fees. After the automatic payment function is enabled, the binding relationship between the calling number and the payment account will be stored by the server.

[0221] When a calling user initiates a call using a calling number, the called terminal, upon receiving the call request, immediately checks whether the calling number meets the conditions for paid call reception. If the conditions are met, an automatic payment step is triggered. The automatic payment step may include: querying the server to see if the calling number meets the automatic payment conditions; and, if the calling number meets the automatic payment conditions, triggering an automatic payment operation, which includes automatically paying the call reception fee based on the payment account linked to the calling number.

[0222] The aforementioned automatic payment conditions may include: having a pre-bound payment account and / or having automatic payment authorization, etc. After confirming that the automatic payment conditions are met, an automatic payment operation can be triggered. This automatic payment operation can be triggered directly by the called terminal, through the server, or through the calling terminal; all of these can achieve the purpose of this application embodiment. The aforementioned automatic payment operation includes automatically paying the call reception fee based on the payment account bound to the calling number. Specifically, it may include requesting payment of the call reception fee required for this call using the payment account bound to the calling number. Furthermore, it may include making payment to the first account held by the called user, for example, sending an automatic payment request to a preset payment channel, requesting deducting the call reception fee required for this call from the bound payment account and transferring the funds to the first account held by the called user.

[0223] The automatic payment mechanism is applicable to common telecommunications call scenarios such as mobile phone numbers, virtual numbers, landlines, corporate phones, and telemarketing platforms, and is particularly suitable for situations requiring frequent paid calls with a stable source of payment. The automatic payment mechanism significantly improves the efficiency and convenience of the paid call process, providing a smoother, more undisturbed call experience, thereby optimizing the user experience. It not only reduces the inconvenience of callers having to perform additional payment operations before each call but also ensures a fast and accurate payment process, avoiding the risk of call interruption due to delayed payment. For users who frequently initiate calls, the automatic payment mechanism provides great convenience, allowing callers to focus on the communication itself without worrying about payment issues. Furthermore, for common telecommunications call scenarios such as virtual numbers, landlines, corporate phones, and telemarketing platforms, where payment of call charges is affected by factors such as the caller's terminal lacking payment functionality, caller inconvenience in paying, the need for centralized payment by the company or organization, or payment on behalf of others, the automatic payment mechanism or payment on behalf function can effectively solve these problems, ensuring smooth payment of call charges and making the call processing method provided in this application applicable to various call scenarios. Furthermore, since automatic payment requires pre-payment of funds into the payment account to ensure sufficient funds to cover call charges, it ensures that every successful call is accompanied by reasonable financial compensation to the called user, thereby improving the overall quality and reliability of communication.

[0224] It should be noted that, in order to prevent the automatic payment mechanism from being abused, in some implementations, the automatic payment operation needs to be triggered only after the calling user confirms. Accordingly, after detecting that the calling number meets the conditions for paid answering, the method further includes: detecting whether the calling number is bound to a payment account for automatic payment; if the calling number is bound to the payment account, sending automatic payment option information to the calling terminal, the automatic payment option information being used by the calling user to trigger the use of the automatic payment mechanism to pay the answering fee.

[0225] The detection of whether the calling number is bound to a payment account for automatic payment can be achieved by sending a query request to the server. Since the server stores a large number of phone number and payment account binding relationships, querying these binding relationships can detect whether the calling number is bound to a payment account. If no payment account is bound, the aforementioned paid call confirmation prompt step can be triggered to continue the paid call process. If a payment account is bound, the automatic payment option sending step can be triggered, and automatic payment option information can be sent to the calling terminal. After receiving the automatic payment option information, the calling terminal will display or play the automatic payment option information for the calling user to choose. The calling user can choose whether to use the automatic payment mechanism to pay for the call. If the user chooses to use it, the automatic payment mechanism can be triggered to pay for the call. If the user chooses not to use it, the paid call process can continue according to the aforementioned paid call confirmation prompt step.

[0226] In addition, the aforementioned automatic payment option information can be sent separately from the payment guidance information, or they can be sent together. For example, after sending the automatic payment option information and the payment guidance information together, the calling terminal can display multiple payment methods at the same time. Among them, multiple payment methods can be provided for the user to choose from according to the payment guidance information, and automatic payment using the payment account can also be offered as an optional payment method for the user. This not only simplifies the overall interaction process, but also gives the calling user more payment options and makes payment more convenient, which can help improve the overall call fluency and user experience.

[0227] Considering that callers expect sufficient call time when choosing paid call answering services, if the called party hangs up immediately after the call is connected, this behavior clearly does not meet the caller's expectations. Frequent occurrences of this will gradually erode some callers' willingness to pay, hindering the establishment of a fair, efficient, and sustainable communication environment. Therefore, it is necessary to reasonably constrain the caller's call duration to ensure that the caller's rights are fully protected, thereby balancing the rights and obligations of both callers and called parties in paid call answering scenarios and maintaining a good call experience. Specifically, in some modified implementations, the method may further include: after the call is connected, executing a call duration protection process, which includes using a preset call duration protection method to protect the call duration. The call duration protection method includes at least one of the following:

[0228] The system plays or displays call protection prompts, including a message indicating that the called user's answering time must exceed the call protection duration. It also displays call duration progress information on the called terminal's call interface, including call timing and a call protection duration indicator. Within the call protection duration, in response to the first hang-up trigger input by the called user, the system maintains the call and displays call protection prompts, including a message indicating that the called user's answering time must exceed the call protection duration. Within the call protection duration, in response to the second hang-up trigger input by the called user, the system hangs up the call. The system hides the hang-up control within the call protection duration and displays the hang-up control after the call duration exceeds the call protection duration; the hang-up control allows the called user to input a hang-up trigger operation.

[0229] The call duration protection process refers to a series of measures initiated after a call is connected based on preset conditions to prevent the called user from ending the call prematurely and to ensure that the call reaches the preset minimum duration requirement. These measures may include, but are not limited to, playing or displaying call protection prompts, displaying call duration progress information, responding to the first hang-up trigger to maintain the call status and provide a prompt, and hiding the hang-up control. The aim is to protect the rights of the calling user after payment and avoid unnecessary fee disputes or service quality issues due to excessively short calls. Considering that the call duration protection process primarily protects the rights of paid calling users, it can be triggered when the payment confirmation information is payment completed. That is, the call duration protection process is executed only after confirming that the calling user has paid the call fee. If the payment confirmation information is a payment commitment, the call duration protection process may or may not be executed; this application embodiment does not limit this.

[0230] The call protection period refers to a minimum call duration preset in a paid call service. It aims to ensure that the caller has enough time to communicate with the called party and avoid poor user experience or infringement of rights due to excessively short call time. After the caller pays a certain fee to initiate a paid call, the called party's terminal or the server can determine whether the actual call has reached the reasonable duration requirement based on this preset call protection period. If the call is connected but the actual call duration does not reach the call protection period, a refund process can be executed according to the set rules to refund part or all of the fee to the caller to compensate for the failure to obtain the expected service experience.

[0231] The call duration progress information is displayed on the called party's terminal's call interface. It includes the call timer and call protection duration indicator, which reminds the called party of the current call duration and the minimum required call duration. The call protection duration indicator can be marked with visual information (such as images, text, icons, color bars, progress bars, etc.) to make it easy for the called party to intuitively understand the minimum required call duration. Combined with the call timer information, it can display the call duration progress information, thus intuitively conveying the current call time progress information to the called party. This, to a certain extent, prevents the called party from hanging up the phone prematurely, protects the rights of the caller, and ensures that every paid call can achieve the expected service quality.

[0232] The call protection message is a notification sent to the called user that the call duration must exceed the call protection time. It can be played via voice or displayed on the screen. It can play or display immediately after the called user answers the call, or after the called user initiates the first hang-up attempt, thus providing timely reminders when the called user attempts to hang up. The hang-up control is an interface element for the called user to input the hang-up trigger. It redisplays after the call duration exceeds the protection time, allowing for a normal hang-up.

[0233] In some examples, once a call is connected, the called party's interface displays call duration progress information, including the call timer and call protection duration indicator. This not only allows the called party to clearly understand the current call's progress but also reminds them of the minimum call duration to be reached. If, within the call protection duration, the called party attempts to end the call via the first hang-up trigger, the called party maintains the call and displays a call protection message on the screen, clearly informing the called party that they must continue the call until the protection duration is exceeded. If the called party attempts to hang up again (the second hang-up trigger), the call can be terminated. Furthermore, to further prevent accidental or intentional hang-ups, the hang-up control can be hidden within the call protection duration, only reappearing after the call duration exceeds the protection duration, allowing the called party to end the call normally.

[0234] It should be noted that the call answering time information can start from the time the called user performs a direct answering operation, or from the time the call link between the two parties is opened or restored, rather than from the time the call is answered in the background, so as to accurately record the actual call duration of both parties.

[0235] This implementation method, by introducing a call duration protection mechanism, ensures that every paid call meets the caller's expectations and avoids dissatisfaction caused by the called party hanging up too early. Therefore, this approach not only protects the caller's rights and enhances trust in paid call services, but also effectively balances the interests and needs of both parties. While protecting call duration, it also fully supports the called party hanging up at any time, ensuring that every paid call meets the reasonable expectations of both parties, maintaining a fair and transparent paid call environment, and improving the user's call experience.

[0236] Based on the above implementation methods, in some modified implementation methods, the step of executing the call duration protection procedure after the call is connected may include: executing the call duration protection procedure after the call is connected if the calling number meets the call duration protection conditions; wherein, the call duration protection conditions include at least one of the following:

[0237] The payment confirmation information corresponding to the calling number is payment completion information, and the paid call reception fee includes the call reception duration protection fee; the calling number belongs to a preset number category that supports call reception duration protection; the membership level corresponding to the calling number belongs to a preset membership level that supports call reception duration protection; and the calling number has enabled call reception duration protection permissions.

[0238] Among them, the call duration protection conditions are the specific conditions for determining whether the call duration protection process needs to be initiated. These conditions can be determined based on multiple dimensions such as payment status, number type, membership level, and permission settings.

[0239] The call duration protection fee is an additional charge paid by the caller when paying the call answering fee. It ensures that the call meets a preset minimum duration requirement. This fee is usually part of the call answering fee, which may include a basic fee and an additional fee. The basic fee is necessary to trigger a second call reminder or to connect the call, while the additional fee is for obtaining additional benefits, such as call duration protection, personalized ringtones, and personalized effects. The fee for obtaining these benefits is called the call duration protection fee. When a caller chooses to pay a call answering fee that includes the call duration protection fee, the call duration protection process will be automatically initiated after the call is connected. By explicitly confirming payment completion information and triggering the call duration protection process only when the paid call fee includes a call duration protection fee, the system ensures that the process is only initiated if the caller agrees and pays the additional fee. This allows the system to tailor the process to the caller's needs, fully exercising their autonomy and meeting their individual requirements. Furthermore, the call duration protection fee provides additional benefits to the called party, balancing their input with output. If the called party wishes to terminate the call early, the fee can be refunded through the subsequent refund process, ensuring the rights of both the caller and the called party are protected.

[0240] As explained above, dividing call reception fees into basic and additional charges not only allows for flexible responses to diverse user needs but also improves overall service quality and user experience. For regular calls, the caller only needs to pay the basic fee to enjoy basic paid call reception services; while callers with special needs can choose to pay additional charges to obtain more value-added services and protections. This approach not only enhances flexibility and adaptability but also provides users with more choices, ensuring that each call receives the optimal service configuration based on the actual situation.

[0241] Number categories that support call duration protection refer to preset number categories that meet specific conditions. These number categories enable the call duration protection process to be initiated after the call is connected. Different number categories (such as unclassified numbers, marketing calls, and scam calls) may have different additional charges and service terms, so the decision to initiate the process can be made based on the number category. For example, unclassified numbers support call duration protection, so the call duration protection process can be executed; while scam calls should not be subject to call duration protection and therefore should not be subject to it. By checking the caller's number category, the call duration protection mechanism can be flexibly applied to adapt to different usage scenarios and technical needs. This approach not only improves call effectiveness but also protects the rights of the caller.

[0242] Membership tiers supporting call duration protection automatically determine whether to initiate the protection process based on the caller's membership level. Premium members or those choosing specific service packages may enjoy more protection measures and service guarantees, thereby improving user satisfaction. For example, premium members have the right to call duration protection to ensure the quality and effectiveness of their important calls. By checking the membership level corresponding to the caller's number, a personalized service experience can be provided based on the user's subscription level. This approach not only enhances the user experience but also enables differentiated services to be provided according to the actual needs of different users, improving overall service satisfaction.

[0243] Call duration protection permissions refer to the permission settings for whether the calling number has enabled the call duration protection function. The corresponding call duration protection process will only be initiated if this permission is enabled, ensuring that user rights are fully protected. This permission setting can be enabled or disabled by the user, or it can be configured by the service provider based on the user's subscription level or specific needs. By checking whether the calling number has enabled call duration protection permissions, it ensures that the call duration protection process will only be initiated if the calling user explicitly agrees and enables the function. This approach not only enhances user autonomy but also strengthens flexibility and security, ensuring that each call meets the preset minimum duration requirement, thereby improving call effectiveness and service quality.

[0244] In practice, the system can first check if the calling number meets any of the call duration protection conditions. If it does, the call duration protection process is immediately initiated. For example, if the caller's payment confirmation information is complete and the paid call charges include call duration protection fees, the protection process can be automatically initiated after the call is connected. Similarly, if the calling number's number category belongs to a preset category that supports call duration protection, or if the calling number's membership level belongs to a preset membership level that supports call duration protection, the call duration protection process can also be initiated. Furthermore, it can be checked whether the calling number has enabled call duration protection permissions to ensure that the protection process is only initiated if the permissions are already enabled.

[0245] It should be noted that the above-mentioned multiple call duration protection conditions can be used individually or in combination. When used in combination, the call duration protection process can be executed if any one condition is met, or it can be executed only if all conditions are met. This application does not limit the implementation of these conditions, and those skilled in the art can implement them flexibly according to actual needs. All of these implementations should be within the scope of protection of this application.

[0246] By introducing the aforementioned call duration protection conditions, it is possible to determine whether to implement the call duration protection process based on these conditions, thereby protecting the rights and obligations of both the calling and called users. Furthermore, the call duration protection mechanism can be flexibly applied according to different dimensions of conditions, adapting to various complex scenarios and technical needs, meeting users' diverse and personalized paid call needs, enhancing user experience, making users pay more attention to effective communication during calls, and improving overall service satisfaction.

[0247] Considering that in cases where the calling number is a friend's new number, the calling number is a new customer's number, or the calling user has paid but the called user has not answered, it is often necessary to refund the paid call fee to the calling user. In view of the above requirements, in some modified implementations, the method may further include: triggering the execution of a refund processing procedure when the refund trigger conditions are met. The refund processing procedure includes refunding the full or partial amount of the call fee already paid by the calling user. The refund trigger conditions include at least one of the following: the call is automatically disconnected because the called user did not answer, the call is ended by both the called and called users and the call duration is less than the preset call protection duration, or a manual refund operation input by the called user is detected.

[0248] Refund trigger conditions refer to the specific conditions that enable the refund processing procedure, ensuring that part or all of the call charges can be refunded automatically or upon user request under certain circumstances. The call protection period is a pre-set minimum call duration standard used to protect the rights of the caller and prevent excessively short call times from affecting the user experience. Manual refund operation refers to the process where a user actively initiates and requests the refund processing procedure through a specific interface or channel.

[0249] The refund process refers to a series of procedures that are automatically executed by the called terminal or the server or based on the user's request when specific refund trigger conditions are met in paid call services. The purpose is to refund part or all of the call fee already paid by the calling user, or to cancel the caller's commitment to pay and no longer charge the caller the promised call fee.

[0250] The refund processing procedure involves multiple steps and technical mechanisms to ensure its security, accuracy, and efficiency. When refund trigger conditions are detected, such as a call being automatically disconnected before being answered, a call ending within a shorter than preset call protection time, or the called user manually requesting a refund, the refund processing procedure is initiated. For example, the refund request is first verified to confirm it meets preset refund rules. Then, the specific amount to be refunded is calculated; this may be a full refund or a partial refund, depending on the actual call details and pre-set refund rules. The funds are then refunded to the caller's payment account through a secure payment channel, ensuring the safety and accuracy of funds. Relevant information about the refund event, including the reason for the refund, the refund amount, and the refund time, is recorded for subsequent auditing and analysis to improve overall service quality. Furthermore, to enhance user experience and system reliability, the refund processing procedure may also include sending notifications to users informing them of the refund status and processing result. This not only increases users' right to know but also enhances their trust in the paid call service. For example, once the refund is successfully processed, an SMS or in-app message can be sent to the calling user, specifying the exact amount of the refund and the expected arrival time, ensuring that the user can understand and confirm the refund status in a timely manner.

[0251] In some examples, when a caller initiates a call but the called party does not answer and automatically hangs up after a certain period, the called terminal or server can automatically trigger a refund process, returning the paid call fee in full or proportionally to the caller. This effectively protects the caller's rights. If the call is connected but the actual call duration does not reach the preset call protection time (e.g., 1 minute), a refund process can also be executed according to set rules. This mechanism ensures that even if the call is brief, the caller will not suffer unnecessary financial losses due to the short call duration. It should be noted that this method can be limited to refunds only when the called party initiates the call and hangs up, while no refund is required when the caller hangs up. Furthermore, to give the called party some flexibility and control, the refund process can be initiated manually using a refund control. This method is suitable for certain special circumstances, such as when the called party discovers they know the caller after the call and wants a refund.

[0252] This implementation method, by introducing multiple refund trigger conditions, can provide a more intelligent and personalized communication management solution while protecting user rights. This approach helps to increase the trust of both the calling and called parties in the paid call service. It can provide the called party with anti-harassment and call compensation functions, while also protecting the rights of the calling party, thereby improving the user experience. In particular, it provides a more transparent and reasonable solution in ensuring call quality and fairness, ensuring that every paid call meets the reasonable expectations of both parties as much as possible.

[0253] The refund amount in the above-mentioned refund process can be a full refund or a partial refund according to the platform's regulations or the called user's custom requirements. This application embodiment does not limit the amount, and all of them should be within the protection scope of this application.

[0254] Furthermore, the above-mentioned refund process can be initiated by the called terminal. For example, for call charges paid directly to the called user's account, the called terminal can initiate the refund. Alternatively, the above-mentioned refund process can also be initiated by the server. For example, in the implementation method where the call charges are first paid to the server and then paid to the called user after the call ends, the server can initiate the refund after the call ends and detect that the refund triggering conditions are met, without further payment to the called user. In addition, it can also be triggered by the called terminal requesting the server. All of these methods can achieve the purpose of the embodiments of this application, and will not be elaborated here. They should all be within the protection scope of this application.

[0255] In some examples, the calling user pays the call reception fee to the server (e.g., a payment platform). The server then generates a payment confirmation message and sends it to the called terminal. The called terminal triggers a second call notification based on the payment confirmation message. After the call ends, if the call duration exceeds the call reception protection period, a portion of the call reception fee will be deducted from the platform service fee, and the remaining call reception fee will be paid to the called user's first account. If the call duration is less than the call reception protection period, a refund process will be executed, and the call reception fee will be fully or partially refunded to the calling user.

[0256] Based on the above implementation, in some modified implementations, the method further includes: displaying a call end interface after the call ends, and displaying a manual refund trigger element on the call end interface, wherein the manual refund trigger element is used for the called user to input a manual refund operation; and determining that the refund trigger condition is met in response to the manual refund operation input by the called user based on the manual refund trigger element.

[0257] The call end screen refers to the screen or page a user sees after a call ends. This screen not only summarizes the information of the just-ended call, such as call duration and cost details, but also provides various follow-up action options, such as refund options, adding contacts, and marking the call. These options can be displayed and selected by the user using elements such as controls to enhance user experience and interactivity. Specifically, the call end screen should appear immediately after the call ends, ensuring that users can quickly obtain relevant information and take further action as needed. For example, users can use this screen to view call logs, save contact information, or perform other related operations. In addition, the call end screen can integrate extra functions and services, such as rating call quality and sending text messages, thus providing users with a centralized and convenient operating platform.

[0258] On the call end screen, the manual refund trigger element is a specific user interface element used to provide the called user with refund options and allow the user to input a manual refund operation. It is usually represented by a button, selection form, control, or other interactive component with a clear label (such as "One-click refund of incoming call charges" or "Drag the incoming call charge label to process the refund") for user identification. When the called user clicks, selects, or drags the manual refund trigger element, it means that a manual refund operation has been entered, and the called terminal can trigger the refund processing flow. In the refund processing flow, the refund can be processed directly according to the predetermined rules. In this case, the entire refund process can be called a one-click refund, that is, the called user only needs to click, select, or drag the refund option in the manual refund trigger element, and the refund can be completed automatically without any further operation.

[0259] In some modified implementations, the refund options displayed on the call end screen are not limited to one; there can be multiple options. Different refund options correspond to different refund amounts, which can be displayed as a percentage or a specific amount. This application embodiment does not limit this; for example, refunds of 100%, 80%, 50%, 30%, 1 yuan, 0.5 yuan, etc. Multiple refund options can be displayed and selected by the user through multiple manual refund trigger elements, i.e., one refund option and one manual refund trigger element. Correspondingly; furthermore, multiple refund options can also be integrated into a single manual refund trigger element for display and user selection. For example, the manual refund trigger element can use drop-down menus, checkboxes, selection forms, etc., to display multiple refund options for the called user to choose from. Additionally, the manual refund trigger element can also include a refund amount input box, where the called user enters the refund amount. Furthermore, the aforementioned refund options and refund amount input box can also be separately placed on the call end screen from the manual refund trigger element, all of which can achieve the purpose of this application embodiment. In summary, the refund processing flow specifically includes refunding the caller's paid call charges based on the refund amount input (including selection) by the called user, thereby providing users with a convenient and fast manual refund solution that supports customized refund amounts, meeting users' diverse and flexible manual refund needs. The aforementioned refund amount can be input based on a manual refund trigger element. For example, the refund options can be matched one-to-one with the manual refund trigger element, or multiple refund options can be integrated into a single manual refund trigger element. This combines the input of the refund amount with the manual refund trigger element, simplifying the display interface and making it easier for users to quickly input the required refund amount for manual refund operations. This helps improve the efficiency of manual refunds and the user experience.

[0260] Based on the above implementation method, in some modified implementation methods, the method further includes: after the call ends, detecting whether the duration of the call has reached a preset call protection duration; if the duration of the call is less than the call protection duration, determining that the refund trigger condition is met.

[0261] After a call ends, the system automatically detects the actual call duration and compares it to a preset call protection period. If the detection result shows that the call duration is less than the preset call protection period, the system automatically determines that this meets the refund trigger condition and initiates the corresponding refund process. This implementation ensures that the refund process is automatically initiated when the call duration is shorter than the preset call protection period, effectively protecting the rights of the calling user.

[0262] Based on the above implementation method, in some modified implementation methods, the method further includes: determining that the refund trigger condition is met when it is detected that the incoming call is not answered by the called user.

[0263] In this case, "not answered by the called user" means that the called user does not answer the call or refuses to answer it within a certain period of time after the caller alerts the user. If the caller has already paid the answering fee, this obviously meets the conditions for triggering a refund and a refund can be issued.

[0264] This implementation method can automatically detect and respond to unanswered calls without requiring additional user intervention, thus simplifying the refund application process and ensuring that the refund process is automatically initiated when a call is not answered, thereby effectively protecting the rights and interests of the calling user.

[0265] It should be noted that the refund mentioned in the foregoing embodiments can be implemented when the payment confirmation information is payment completed, thereby refunding the caller's paid call reception fee. Alternatively, it can be implemented when the payment confirmation information is a payment commitment. In this case, the refund can be understood as refunding the caller's payment commitment, and the caller will no longer be charged the promised call reception fee.

[0266] In some modified embodiments of this application, the method may further include: in response to a contact addition operation for the calling number, obtaining an electronic business card corresponding to the calling number; and adding the calling user as a contact based on the identity information recorded in the electronic business card.

[0267] The contact addition operation refers to an action performed by a user on a communication application or device to save a phone number (in this case, the caller ID) to the contact list, thereby adding the phone number as a contact. An electronic business card is a digital business card format that typically contains detailed user information, such as name, phone number, email address, company name, and other identity information. Furthermore, the electronic business card provided in this application embodiment can also record business information related to the current call (such as the purpose of the call, appointment details, etc.). When a user performs the operation of adding a caller ID as a contact, the called terminal can automatically detect and obtain the electronic business card corresponding to the caller ID, and complete the contact addition process based on the user information recorded in the electronic business card. The electronic business card can be obtained in real-time from the calling terminal or the server, or it can be obtained in advance and then called in real-time.

[0268] For example, when a called user adds a caller ID number as a contact, the called terminal can immediately start a background process to find and retrieve the electronic business card associated with that caller ID number. This electronic business card can be stored in the calling terminal, a cloud server, a local database, or other accessible data sources. Once the electronic business card is retrieved, the user information within it can be parsed and automatically populated into the relevant fields of the contact addition interface, such as name, phone number, and email address. Then, a new contact entry is created based on this information and saved to the user's contact list.

[0269] This implementation method significantly enhances the intelligence of contact management. Firstly, by automatically acquiring and utilizing electronic business card information, the need for users to manually input contact information is reduced, thus simplifying the process and improving efficiency. Secondly, it ensures the accuracy and completeness of contact information, avoiding inconsistencies caused by manual input errors. Furthermore, since the electronic business card originates from the caller and is initially generated by the caller, the accuracy and authenticity of the information are guaranteed. In addition, this automated processing method enhances the user experience, allowing users to complete multiple tasks in a single operation, improving overall operational efficiency and user satisfaction.

[0270] It should be noted that the paid call answering method provided in this embodiment can coexist with and be combined with existing harassment call blocking schemes to obtain more personalized anti-harassment functions, meet diverse user needs, and provide users with a more intelligent and flexible communication environment. For example, existing commonly used harassment call blocking schemes typically block harassment calls based on number tagging information. By integrating the technical solution of this application, some types of unknown calls can be directly blocked based on number tagging information, while other types of unknown calls can receive a first call alert to further execute the paid call answering process. For example, phone numbers that have been repeatedly marked as advertising, sales, or fraudulent can be directly blocked to prevent these unwanted calls from disturbing users. For those numbers that are not widely marked but are still unknown, a paid call answering process can be selected to ensure that only calls from those willing to pay will trigger a call alert on the called terminal. Furthermore, it can determine whether to directly block or perform a first call reminder based on the number of times a phone number is marked. For example, if the number of markings is less than a preset threshold, a first call reminder is performed; if the number of markings is greater than the preset threshold, the call is directly blocked, thereby effectively filtering out high-risk harassing calls. The preset threshold can be flexibly set according to user needs or can be set by the user themselves. This application embodiment does not limit this.

[0271] By organically combining paid call answering methods with harassing call blocking solutions, users can be provided with more powerful and personalized communication management tools, thereby significantly improving their calling experience, providing more personalized and secure anti-harassment services, and meeting diverse usage needs. Specifically, while protecting users from frequent harassment, it also preserves the possibility of receiving important unknown calls. For example, when a user receives a call from an unknown number from a new customer or potential partner, even if the number has not been widely flagged, the paid call answering mechanism still allows the caller to choose whether to pay a certain fee to ensure the call proceeds smoothly. This approach maintains the user's peace and provides a channel for calls with genuine communication needs. At the same time, by setting reasonable flagging thresholds, the handling strategies for different calls can be dynamically adjusted, making the entire anti-harassment system more intelligent and efficient.

[0272] It should be noted that, for the sake of simplicity, some steps in the embodiments described in this application are specified to be executed by the called terminal, the call application, or the server. The scheme executed by the called terminal or the call application can be executed directly by the call application, while the scheme executed by the server can be triggered by the called terminal or the call application sending relevant data and requests to the server and obtaining the execution result data from the server. All relevant parts can be understood with reference to the description in this section. They are all simplified modifications to the implementation methods of this application and should all be within the protection scope of this application.

[0273] Based on the above embodiments, the call processing method provided in this application can at least achieve the following technical effects:

[0274] 1. Raise the caller ID threshold: By setting a paid call-receiving condition on the called user's terminal, the caller needs to pay a fee to trigger the caller ID's call notification. If the caller is unwilling to pay, a second call notification or call will not be triggered. Since some harassing callers are usually unwilling to pay extra fees, caller ID will not be triggered for caller IDs who do not agree to pay. This can effectively reduce the number of harassing call notifications and actual call volume, and block some harassing calls. By raising the caller ID threshold and reducing the number of harassing calls, the negative impact of harassing calls on called users is reduced.

[0275] 2. Generating Revenue for Called Users: Since answering harassing calls requires the caller to pay a certain fee to the called user, if the caller is willing to pay to trigger a second caller ID or answer the call, the called user can receive some financial compensation when answering these calls, generating additional income for the called user. This financial compensation can effectively alleviate the negative emotions of the called user when answering harassing calls, thereby reducing the negative impact of harassing calls on the called user from the perspective of financial compensation.

[0276] 3. Enhanced User Control: Upon detecting a call request, this solution first executes an incoming call notification, allowing the called user to decide whether to proceed with the paid answering process. This enables the called user to decide in real-time whether to accept a paid call for each incoming call, thus allowing them to determine the handling of each call according to their wishes, providing greater freedom and ensuring that the handling of each call meets their needs. Furthermore, since the paid answering process is executed based on the called user's input, it is only performed when the called user is aware of the incoming call and is able to answer it. In this case, the caller has a higher probability of being successfully answered after paying the answering fee, reducing the probability of paying but not being answered. This minimizes resource waste caused by unnecessary paid answering and refund processes, thereby improving overall resource utilization and call fluency, ultimately enhancing the calling experience for both the caller and the receiving experience for the called user.

[0277] 4. Reduce users' time and energy waste: Since the calling user needs to pay a fee to trigger the called terminal to execute a second call reminder or connect the call, and most calling users will only pay for important or valuable calls, the called user can more confidently confirm the other party's true intention before answering the call if the calling number can trigger a second call reminder or connect the call. This reduces the time and energy wasted on answering harassing calls and improves call efficiency.

[0278] 5. Benefits for Callers: The call processing method provided in this application not only benefits called users but also offers numerous advantages to callers. For example, taking a caller engaged in marketing as an example, this solution can improve the connection rate of marketing calls. Specifically, by setting paid answering conditions, it can help users filter out high-quality marketing calls. Marketing call initiators typically hope to establish contact with potential customers via telephone. Paying a fee can serve as a screening mechanism, ensuring that only truly sincere marketing calls are successfully dialed. This not only improves the connection rate of marketing calls but also enhances the effectiveness of marketing activities. For marketing call initiators, paying a fee increases the value of the call, demonstrating sincerity and increasing the called user's willingness to answer. Knowing that the other party has paid a fee, the called user is more likely to answer the call, thereby improving the connection rate of marketing calls. When called users know that the initiator of the marketing call has paid for it, they will have a higher sense of trust in these calls. This trust can make called users more willing to answer the call, thereby increasing the connection rate and conversion rate of marketing calls. Therefore, the embodiments of this application can also promote the healthy development of telephone sales business by charging for answering incoming calls, reducing or eliminating users' resistance and rejection of telephone sales, and enabling users who really need it to receive better services.

[0279] In the above embodiments, a call processing method is provided. Correspondingly, this application also provides a call processing device. The call processing device provided in this application can implement the above call processing method. The call processing device can be implemented by software, hardware, or a combination of both. For example, the call processing device may include integrated or separate functional modules or units to perform the corresponding steps in the above methods. Please refer to Figure 6, which schematically shows a schematic diagram of a call processing device provided by some embodiments of this application. Since the device embodiments are basically similar to the method embodiments, the description is relatively simple. Relevant parts can be referred to in the description of the method embodiments, and repeated parts will not be described again. The device embodiments described below are merely illustrative.

[0280] As shown in Figure 6, the incoming call processing device may include: a first incoming call reminder module 101, used to execute a first incoming call reminder when a call request is detected; and a paid answering execution module 102, used to execute a paid answering process when the called user inputs a paid answering operation in response to the first incoming call reminder, wherein the paid answering process includes connecting the incoming call or triggering a second incoming call reminder after detecting payment confirmation information corresponding to the calling number.

[0281] In some modified embodiments, the device further includes: a direct answer execution module, configured to answer the incoming call when the called user inputs a direct answer operation in response to the first incoming call reminder; and a rejection execution module, configured to reject the incoming call when the called user inputs a rejection operation in response to the first incoming call reminder.

[0282] In some modified embodiments, the first incoming call reminder module 101 includes: a first incoming call reminder unit, used to display a first incoming call reminder interface, the first incoming call reminder interface including paid call answering trigger elements, direct call answering trigger elements, and reject call triggering elements displayed in a preset arrangement; correspondingly, the paid call answering operation includes a first triggering operation based on the paid call answering triggering element; the direct call answering operation includes a second triggering operation based on the direct call answering triggering element; and the reject call operation includes a third triggering operation based on the reject call triggering element.

[0283] In some modified implementations, the paid call receiving execution module 102 further includes: a waiting payment information display unit, used to display a waiting payment prompt information until payment confirmation information corresponding to the calling number is detected, the waiting payment prompt information being used to indicate that the call is currently waiting for the calling user to pay the call receiving fee.

[0284] In some modified implementations, the waiting payment information display unit includes: a waiting payment interface display subunit, used to switch the first incoming call reminder interface to the waiting payment interface and display waiting payment prompt information on the waiting payment interface; or, an application interface display subunit, used to switch the first incoming call reminder interface to the application interface of the application running in the foreground before executing the first incoming call reminder and display waiting payment prompt information in a local area of ​​the application interface.

[0285] In some modified implementations, the first incoming call reminder module 101 includes: a calling number acquisition unit, used to acquire the calling number when a call request is detected; and a reminder selection unit, used to selectively execute a first incoming call reminder for the calling number.

[0286] In some modified implementations, the selection reminder unit includes: a first selection reminder subunit, configured to execute a first call reminder when the calling number meets the conditions for paid call reception; a second selection reminder subunit, configured to execute a first call reminder when the calling number is an unknown number; a third selection reminder subunit, configured to execute a first call reminder when the calling number is identified by a preset caller ID model as requiring paid call reception; a fourth selection reminder subunit, configured to execute a first call reminder when the caller ID corresponding to the calling number has a paid call reception intention; and a fifth selection reminder subunit, configured to execute a first call reminder when the calling number meets the conditions for paid call reception and the caller ID corresponding to the calling number has a paid call reception intention.

[0287] In some modified embodiments, the device further includes: a condition editing interface display module, used to display a paid call receiving condition editing interface in response to a setting trigger operation, the paid call receiving condition editing interface having editable elements corresponding to at least one of the following dimensions: number familiarity, number category, custom number list, number source, paid call receiving identifier, membership level, caller ID model recognition result, effective time, and caller ID model recognition result; the condition editing module is used to determine the paid call receiving conditions based on the called user's editing operation on the editable elements.

[0288] In some modified embodiments, the device further includes: an editing interface display module, used to display a charging standard editing element on the paid call condition editing interface or the charging standard setting interface; and a charging standard editing module, used to determine the charging standard based on the called user's editing operation on the charging standard editing element.

[0289] In some modified embodiments, the device further includes: a caller intent recognition module; the caller intent recognition module includes: an additional information receiving unit, used to receive additional call information sent by the calling terminal, the additional call information including the identity information of the calling user and / or call description information; and a caller intent recognition unit, used to recognize the caller intent of the calling user based on the additional call information.

[0290] In some modified implementations, the paid call receiving execution module 102 further includes: a paid information interaction unit, used to send paid interaction information to the calling terminal corresponding to the calling number according to a preset paid information interaction method, wherein the paid interaction information includes at least one of paid call receiving prompt information, payment guidance information, payment timing option information, and automatic payment option information.

[0291] In some modified implementations, the payment information interaction unit includes: a built-in interaction subunit, used to send payment interaction information to the calling terminal through a built-in interactive voice response system.

[0292] In some modified implementations, the paid information interaction unit includes: an interaction mode selection subunit, configured to select, based on the device information of the calling terminal, a paid information interaction mode suitable for sending the currently to-be-sent paid interaction information to the calling terminal from a preset paid information interaction mode; and a paid information interaction subunit, configured to send the paid interaction information to the calling terminal according to the determined paid information interaction mode.

[0293] In some modified implementations, the payment confirmation information includes commitment payment information; correspondingly, the device further includes a default processing module, used to perform default processing steps based on the commitment payment information after the call ends.

[0294] In some modified embodiments, the device further includes: a lost signal code detection module for detecting whether the calling number is a lost signal code; and a call restriction module for restricting the calling number from receiving calls when the calling number is detected to be a lost signal code.

[0295] In some modified implementations, the paid call receiving execution module 102 further includes: an automatic payment unit, used to query the calling number through the server whether it meets the automatic payment conditions; and to trigger an automatic payment operation if the calling number meets the automatic payment conditions, the automatic payment operation including automatically paying the call receiving fee based on the payment account bound to the calling number.

[0296] In some modified embodiments, the device further includes: a call duration protection module, used to execute a call duration protection process after the call is connected, the call duration protection process including using a preset call duration protection method to protect the call duration.

[0297] In some modified implementations, the call duration protection module includes: a call duration protection unit, used to execute the call duration protection process after the incoming call is connected if the calling number meets the call duration protection conditions.

[0298] In some modified embodiments, the apparatus further includes a refund processing module, used to trigger the execution of a refund processing procedure when a refund trigger condition is met, the refund processing procedure including refunding the full or partial amount of the caller's prepaid call charges.

[0299] In some modified embodiments, the device further includes: a manual refund element display module, used to display a call end interface after the call ends, and display a manual refund trigger element on the call end interface; and a manual refund trigger module, used to determine that the refund trigger condition is met in response to a manual refund operation input by the called user based on the manual refund trigger element.

[0300] In some modified implementations, the refund processing module includes a refund processing unit, used to refund the caller's already paid call fee based on the refund amount input by the called user.

[0301] In some modified embodiments, the device further includes: an electronic business card acquisition module, used to acquire an electronic business card corresponding to the calling number in response to a contact addition operation for the calling number; and a contact addition module, used to add the calling user as a contact based on the identity information recorded in the electronic business card.

[0302] In some modified embodiments, the device further includes: a paid call identification option display module, used to display a paid call identification setting option in a contact editing interface where the caller number is added as a contact; and a paid call identification option setting module, used to set a paid call identification for the caller number based on the called user's selection operation of the paid call identification setting option, wherein the paid call identification is used to mark the caller number as meeting the paid call conditions.

[0303] The call processing device provided in this application embodiment is based on the same inventive concept and has the same beneficial effects as the call processing method provided in the foregoing embodiments of this application, and will not be described again here.

[0304] This application also provides an electronic device corresponding to the call processing method provided in the foregoing embodiments. The electronic device can be any device with communication and voice call capabilities, such as a mobile phone, landline (fixed-line phone), smartwatch, tablet computer, vehicle terminal (smart car system), smart glasses, etc., to execute the above-mentioned call processing method.

[0305] Please refer to Figure 7, which schematically illustrates an electronic device provided by some embodiments of this application. As shown in Figure 7, the electronic device 20 includes: a processor 200, a memory 201, a bus 202, and a communication interface 203. The processor 200, the communication interface 203, and the memory 201 are connected via the bus 202. The memory 201 stores a computer program that can run on the processor 200. When the processor 200 runs the computer program, it executes the incoming call processing method provided by any of the foregoing embodiments of this application.

[0306] The memory 201 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 203 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network.

[0307] Bus 202 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 201 is used to store programs. After receiving an execution instruction, the processor 200 executes the program. The incoming call processing method disclosed in any of the foregoing embodiments of this application can be applied to the processor 200, or implemented by the processor 200.

[0308] The processor 200 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 200 or by instructions in software form. The processor 200 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 201. The processor 200 reads the information in memory 201 and, in conjunction with its hardware, completes the steps of the above method.

[0309] The electronic device provided in this application embodiment is based on the same inventive concept as the call processing method provided in the foregoing embodiments of this application, and has the same beneficial effects as the method it adopts, operates or implements.

[0310] This application also provides a computer-readable medium corresponding to the call processing method provided in the foregoing embodiments. The computer-readable storage medium can be an optical disc, a disk, a hard disk, a USB flash drive, a memory card, etc., and stores a computer program (i.e., a program product) thereon. When the computer program is run by a processor, it will execute the call processing method provided in any of the foregoing embodiments.

[0311] It should be noted that examples of the computer-readable storage medium may include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0312] The computer-readable storage medium provided in the above embodiments of this application and the call processing method provided in the foregoing embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0313] This application also provides a computer program product, which includes a computer program or instructions for executing any of the above-described call handling methods. The computer program or instructions may be software or a program product containing instructions that can run on a computing device or be stored on any usable medium. When the computer program or instructions are executed on at least one computing device, the at least one computing device performs the call handling method described in the above embodiments. The computer program product provided in the above embodiments of this application is based on the same inventive concept as the call handling method provided in the foregoing embodiments of this application and has the same beneficial effects as the above-described call handling method.

[0314] It should be noted that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0315] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0316] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0317] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0318] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0319] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application.

Claims

1. A method for handling incoming calls, characterized in that, include: Upon detecting a call request, a first call notification will be issued; If the system detects that the called user has entered a paid call answering operation in response to the first call reminder, the system executes a paid call answering process, which includes connecting the call or triggering a second call reminder after detecting payment confirmation information corresponding to the caller's number.

2. The method according to claim 1, characterized in that, The method further includes: If the system detects that the called user has directly answered the call in response to the first call reminder, the call will be connected. If the system detects that the called user has entered a reject operation in response to the first call reminder, the call will be rejected.

3. The method according to claim 2, characterized in that, The execution of the first incoming call reminder includes: The first incoming call reminder interface is displayed, which includes paid call triggering elements, direct call triggering elements, and call rejection elements displayed in a preset arrangement. Accordingly, the paid call answering operation includes a first triggering operation based on the input of the paid call answering triggering element; The direct answering operation includes a second triggering operation based on the input of the direct answering triggering element; The rejection operation includes a third trigger operation based on the rejection trigger element input.

4. The method according to claim 3, characterized in that, The paid call triggering element includes a first control located on the first incoming call reminder interface, and the first triggering operation includes dragging or clicking the first control. The direct call answering trigger element includes a second control located on the first incoming call reminder interface, and the second triggering operation includes dragging or clicking the second control. The call rejection element includes a third control located on the first incoming call reminder interface, and the third trigger operation includes dragging or clicking the third control.

5. The method according to claim 3, characterized in that, The first incoming call notification interface has a sliding element; The paid call answering trigger element includes a first trigger area located on the first incoming call reminder interface, and the first triggering operation includes dragging the sliding element to the first trigger area. The direct call answering trigger element includes a second trigger area located on the first incoming call reminder interface, and the second triggering operation includes dragging the sliding element to the second trigger area; The call rejection element includes a third trigger area located on the first incoming call reminder interface, and the third trigger operation includes dragging the sliding element to the third trigger area.

6. The method according to claim 3, characterized in that, The first incoming call notification interface also includes additional information about the caller's number and / or the caller's intent. The additional information includes the caller's identity information and / or a description of the incoming call.

7. The method according to claim 1, characterized in that, The paid call receiving process also includes: The system displays a "waiting for payment" message until payment confirmation information corresponding to the calling number is detected. The "waiting for payment" message is used to indicate that the system is currently waiting for the calling user to pay the call fee.

8. The method according to claim 7, characterized in that, The message displaying the waiting payment prompt includes: Switch the first incoming call notification screen to a pay-as-you-go screen, and display a pay-as-you-go message on the pay-as-you-go screen; or... The first incoming call reminder interface is switched to the application interface of the application that was running in the foreground before the first incoming call reminder was executed, and a waiting payment prompt message is displayed in a local area of ​​the application interface.

9. The method according to claim 1, characterized in that, Upon detecting a call request, the execution of a first incoming call alert includes: Upon detecting a call request, obtain the caller ID; Selectively execute the first caller ID reminder for the called number.

10. The method according to claim 9, characterized in that, The selective execution of the first caller ID reminder for the calling number includes: If the calling number meets the conditions for paid call reception, the first caller ID will be activated; If the calling number is an unknown number, the first caller ID will be activated; If the caller ID is identified by the preset caller ID recognition model as requiring a paid call, a first call reminder is executed; If the caller ID corresponding to the caller ID indicates a paid call intention, the first caller ID reminder will be executed. If the calling number meets the conditions for paid call reception and the caller's intent is to receive a paid call, the first caller alert is executed.

11. The method according to claim 10, characterized in that, The conditions for receiving paid calls include at least one of the following: The calling number is an unknown number; The caller ID number belongs to the category of numbers that are pre-set to require paid call reception; The caller ID number is in the preset custom number list; The caller ID number is from a number source that is pre-selected as requiring a paid call. The calling number has a paid call indicator; The caller ID number corresponds to a membership level that is pre-set to require paid call reception; The caller ID number was received during a pre-set paid call period. The caller ID number is identified by a pre-defined caller ID model as a call that requires payment.

12. The method according to claim 10, characterized in that, The conditions for paid call answering are determined based on at least one of the following factors: familiarity with the number, number category, custom number list, number source, paid call answering identifier, membership level, caller ID model recognition result, effective time, and charging standard.

13. The method according to claim 10, characterized in that, The method further includes: In response to the setting trigger operation, the paid call receiving condition editing interface is displayed. The paid call receiving condition editing interface has editable elements corresponding to at least one of the following dimensions: number familiarity, number category, custom number list, number source, paid call receiving identifier, membership level, caller ID model recognition result, effective time, and caller ID model recognition result. The conditions for receiving a paid call are determined based on the editing operations performed by the called user on the editable elements.

14. The method according to claim 13, characterized in that, The method further includes: The charging standard editing elements are displayed in the paid call conditions editing interface or the charging standard setting interface; The charging standard is determined based on the called user's editing operation on the charging standard editing element.

15. The method according to claim 10, characterized in that, Before executing the first incoming call alert, a caller intent recognition step is included, which includes: Receive incoming call supplementary information sent by the calling terminal, the incoming call supplementary information including the calling user's identity information and / or call description information; The caller's intent is identified based on the additional call information.

16. The method according to claim 1, characterized in that, The alert strength of the second incoming call reminder is less than that of the first incoming call reminder.

17. The method according to claim 1, characterized in that, The paid call receiving process also includes a paid information interaction step, which includes: According to a preset payment information interaction method, a payment interaction message is sent to the calling terminal corresponding to the calling number. The payment interaction message includes at least one of the following: paid call notification message, payment guidance message, payment timing option message, and automatic payment option message.

18. The method according to claim 17, characterized in that, The paid information interaction method includes at least one of the following: When an incoming call is connected in the background, a payment interaction message is sent to the calling terminal through the call link. Send payment interaction information to the calling terminal through an interactive voice response system; Send payment interaction information to the calling terminal via in-app notification; The system sends payment interaction information to the calling terminal via SMS.

19. The method according to claim 18, characterized in that, Sending payment interaction information to the calling terminal via an interactive voice response system includes: The system sends payment interaction information to the calling terminal through a built-in interactive voice response system. The built-in interactive voice response system is implemented by a first call application installed on the called terminal and a second call application installed on the calling terminal. The first call application sends paid interaction information to the second call application through a call link or an Internet link, and the second call application sends response information to the paid interaction information through an Internet link.

20. The method according to claim 17, characterized in that, Sending payment interaction information to the calling terminal corresponding to the calling number according to a preset payment information interaction method includes: Based on the device information of the calling terminal, a payment information interaction method suitable for sending the currently to-be-sent payment interaction information to the calling terminal is selected from the preset payment information interaction methods; The payment interaction information is sent to the calling terminal according to the determined payment information interaction method.

21. The method according to claim 1, characterized in that, The payment confirmation information includes: payment completion information or payment commitment information; wherein... The payment completion information indicates that the call fee for the calling number has been paid. The promised payment information indicates that the calling user promises to pay for the call reception fee for this call.

22. The method according to claim 21, characterized in that, The payment confirmation information includes payment completion information, which is generated based on the payment behavior of the calling terminal, the payment device, or the server.

23. The method according to claim 21, characterized in that, The payment confirmation information includes a payment commitment; correspondingly, the method further includes: After the call ends, a default handling procedure is executed based on the promised payment information, the default handling procedure including at least one of the following: If the promised payment information is not fulfilled within the first time limit, a call charge collection reminder message is sent to the calling terminal. The call charge collection reminder message is used to remind the calling user to pay the call charge for this call. If the promised payment information is not fulfilled within the second time limit, a default information message for the calling number is sent to the server. The default information message is used to restrict other called terminals connected to the server from receiving calls to the calling number.

24. The method according to claim 1, characterized in that, The payment confirmation information includes confirmation information from the calling user to the called user regarding payment of the call answering fee. The call answering fee is determined according to the pre-set charging standard of the called terminal. The charging standard is determined according to a tiered charging method, which tiers the charging standard based on at least one of the following dimensions: familiarity with the number, number category, custom number list, number source, paid call answering identifier, membership level, caller ID model recognition result, and effective time.

25. The method according to claim 1, characterized in that, Before executing the first incoming call alert, the process also includes: Detect whether the calling number is a lost signal code; If the calling number is detected to be a lost signal number, the calling number will be restricted from receiving calls. The call receiving restriction is implemented using at least one of the following methods: rejecting the current call from the calling number, canceling the calling number's postpayment privileges, requiring the calling user to pay any unpaid call charges before continuing to call, and increasing the call receiving charges payable by the calling number.

26. The method according to claim 1, characterized in that, The paid call receiving process also includes: an automatic payment step; the automatic payment step includes: The server queries whether the calling number meets the automatic payment conditions. If the calling number meets the automatic payment conditions, an automatic payment operation is triggered, which includes automatically paying the call fee based on the payment account linked to the calling number.

27. The method according to claim 1, characterized in that, The method further includes: After the call is connected, a call duration protection process is executed. This process includes protecting the call duration using a preset call duration protection method, which includes at least one of the following: Play or display call protection prompt information, which includes a prompt that the called user's answering time must be greater than the call protection time; The call interface of the called terminal displays call duration progress information, which includes call timing information and call protection duration indicator. During the call protection period, in response to the first hang-up trigger operation entered by the called user, the call status is maintained and the call protection prompt message is displayed; Within the call protection period, in response to the second hang-up trigger operation entered by the called user, the current call is terminated; The call-to-hang-up control is hidden during the call protection period and displayed after the call protection period has expired. The call-to-hang-up control is used for the called user to input the call-to-hang-up trigger operation.

28. The method according to claim 27, characterized in that, The process of protecting call duration after the call is connected includes: If the calling number meets the call duration protection conditions, the call duration protection procedure is executed after the call is connected; wherein, the call duration protection conditions include at least one of the following: The payment confirmation information corresponding to the calling number is the payment completion information, and the paid call reception fee includes the call duration protection fee; The calling number belongs to a preset number category that supports call duration protection; The membership level corresponding to the calling number is a preset membership level that supports call duration protection; The calling number has been granted call duration protection.

29. The method according to claim 1, characterized in that, The method further includes: If the refund triggering conditions are met, the refund processing procedure will be triggered, which includes refunding the full or part of the caller's paid call fee. The refund triggering conditions include at least one of the following: the call is not answered by the called user, the call is ended by the called user and the call duration is less than the preset answer protection duration, or a manual refund operation input by the called user is detected.

30. The method according to claim 29, characterized in that, The method further includes: After the call ends, a call end screen is displayed, and a manual refund trigger element is shown on the call end screen; In response to the called user's manual refund operation based on the manual refund trigger element, it is determined that the refund trigger condition is met.

31. The method according to claim 29, characterized in that, The refund processing procedure includes: The caller will receive a refund based on the amount entered by the called user.

32. The method according to any one of claims 1-31, characterized in that, The method further includes: In response to the contact addition operation for the caller ID number, the electronic business card corresponding to the caller ID number is obtained; The caller is added as a contact based on the identity information recorded in the electronic business card.

33. The method according to any one of claims 1-31, characterized in that, The method further includes: In the contact editing interface where the caller ID is added as a contact, the option to set a paid call indicator is displayed; Based on the called user's selection of the paid call identification setting option, a paid call identification is set for the calling number. The paid call identification is used to mark the calling number as meeting the conditions for paid call reception.

34. A call processing device, characterized in that, include: The first incoming call reminder module is used to execute the first incoming call reminder when a call request is detected; The paid call answering execution module is used to execute the paid call answering process when it detects that the called user has entered a paid call answering operation in response to the first call reminder. The paid call answering process includes connecting the call or triggering the second call reminder after detecting the payment confirmation information corresponding to the caller number.

35. An electronic device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the method as claimed in any one of claims 1-33.

36. A computer-readable storage medium, characterized in that, It stores computer-readable instructions that can be executed by a processor to implement the method as described in any one of claims 1-33.

37. A computer program product, characterized in that, The computer program product includes a computer program or instructions for performing the method as described in any one of claims 1 to 33.

Images