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

Abstract

Provided in the present application are an incoming call processing method and apparatus, call processing method and apparatus, and an electronic device and a storage medium. The incoming call processing method comprises: when a call request is detected, acquiring a calling number, and executing a paid answering procedure regarding the calling number, wherein the paid answering procedure comprises triggering an incoming call alert after payment confirmation information corresponding to the calling number is detected, thereby increasing the costs for the calling number being answered. Since a calling user is required to pay a fee in order to trigger an incoming call alert, and no incoming call alert will be triggered if the calling user is unwilling to pay the fee, certain calls can be blocked, thereby effectively reducing the amount of incoming call alerts and actual call volume with nuisance calls. In addition, answering of nuisance calls can bring additional financial compensation to a called user, thereby effectively alleviating negative emotions of the called user caused by answering the nuisance calls, and thus improving the use experience.

Description

Incoming call processing, 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, and a 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, they still have at least the following deficiencies: first, the existing nuisance call interception function relies on the 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 mark based on cloud data or user manual marking, which is still a victim of nuisance calls, and many users are reluctant to mark, which results in a larger number of actual victims, and the calling users of nuisance calls also develop new numbers to avoid being marked and intercepted, the above factors result in a large number of unmarked nuisance calls in actual application, and users often cannot judge whether the call is a nuisance call before answering, and can only understand the intention of the other party after answering, which not only wastes the time and energy of the user, but also may cause unnecessary annoyance and risk. Second, the existing nuisance call interception function is intercepted according to the number marking information, which results in that if the calling number is marked as a nuisance call, no matter how important the call is, it will be directly intercepted by the called terminal, resulting in the missed important incoming call of the called user.

[0004] Therefore, it is necessary to provide a technical solution that can reduce the negative impact of nuisance calls on users and ensure that important calls have a chance to be answered. 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, and a call processing method, device, electronic equipment and storage medium, to solve the problem of frequent negative impact of nuisance calls on users.

[0006] The first aspect of the present application provides an incoming call processing method, comprising: in the case of detecting a call request, acquiring a calling number; performing a paid call process for the calling number, the paid call process comprising triggering an 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 method, comprising: in the case of detecting a call from a stranger, answering the call in the background and querying the caller by voice whether to agree to pay for the call; after receiving the agreement to pay information indicating that the caller agrees to pay for the call, sending payment guidance information to the caller terminal, the payment guidance information being used to guide the caller to pay for the call; and after detecting that the payment for the call is completed, triggering a call reminder for the stranger.

[0008] The third aspect of the present application provides a call processing method, comprising: in the case of detecting a calling request, performing a call intention recognition step; in the case of identifying that the call intention belongs to a paid call intention, performing a paid call process, the paid call process comprising triggering a call reminder after detecting payment confirmation information corresponding to the caller number, the paid call intention being a call intention that triggers a call reminder of the called terminal after the caller pays for the call.

[0009] The fourth aspect of the present application provides a call processing method, comprising: sending a calling request to a called number; playing or displaying paid call prompt information sent by the called terminal for the calling request; and performing payment confirmation according to the paid call prompt information, so that the called terminal triggers a call reminder according to payment confirmation information.

[0010] The fifth aspect of the present application provides a call processing method, comprising: determining a called number to be called; in the case of paid call for the called number, displaying a payment confirmation element; and after detecting that the caller performs a payment confirmation operation based on the payment confirmation element, sending a calling request to the called number.

[0011] The sixth aspect of the present application provides a call processing device, comprising: a caller number acquisition module, configured to acquire a caller number in the case of detecting a calling request; and a paid call execution module, configured to perform a paid call process for the caller number, the paid call process comprising triggering a call reminder after detecting payment confirmation information corresponding to the caller.

[0012] The seventh aspect of the present application provides a call processing device, comprising: a voice interaction module, configured to, in the case of detecting a call from a stranger, answer the call in the background and query the caller by voice whether to agree to pay for the call to remind the called user to answer the call; a payment guidance module, configured to, after receiving the agreement to pay information indicating that the caller agrees to pay for the call, send payment guidance information to the caller terminal, the payment guidance information being used to guide the caller to make payment for the call; and a call reminder module, configured to, after detecting that the payment for the call is completed, trigger a call reminder for the stranger.

[0013] The eighth aspect of the present application provides a call processing device, comprising: a call intention determination module, configured to perform a call intention recognition step when a call request is detected; a call intention trigger module, configured to perform a paid call process when the recognized call intention belongs to a paid call intention, wherein the paid call process comprises triggering a call reminder after detecting payment confirmation information corresponding to a calling number, and the paid call intention is a call intention that triggers a called terminal call reminder after a calling user pays a call charge.

[0014] The ninth aspect of the present application provides a call processing device, comprising: a call request sending module, configured to send a call request to a called number; a paid call information providing module, configured to play or display paid call prompt information sent by a called terminal for the call request; and a payment confirmation module, configured to perform payment confirmation according to the paid call prompt information, so that the called terminal triggers a call reminder according to payment confirmation information.

[0015] The tenth aspect of the present application provides a call processing device, comprising: a called number determination module, configured to determine a called number to be called; a payment element display module, configured to display a payment confirmation element when the called number needs to be called; and a call initiation module, configured to send a call request to the called number after detecting that a calling user performs a payment confirmation operation based on the payment confirmation element.

[0016] The eleventh 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 to fifth aspects of the present application.

[0017] The twelfth 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 to fifth aspects of the present application.

[0018] The thirteenth aspect of the present application provides a computer program product, comprising computer programs or instructions for executing the method of the first to fifth aspects of the present application.

[0019] The first aspect of the present application provides a call processing method. The call processing method comprises the following steps: detecting a call request; obtaining a calling number corresponding to the call request; and executing a paid call answering process for the calling number. The paid call answering process comprises the following steps: detecting payment confirmation information corresponding to the calling number; and triggering a call reminder when the payment confirmation information is detected. The call processing method can improve the call answering threshold of the calling number. The call reminder can be triggered only when the calling user pays the fee. The call reminder will not be triggered if the calling user does not want to pay the fee. Therefore, the call processing method can intercept some calls, effectively reducing the call reminder amount and the actual call amount of the harassment calls. In addition, the calling user needs to pay a certain fee to the called user to answer the harassment call. Therefore, the calling user can obtain additional economic compensation by answering the harassment call. Thus, the call processing method can effectively alleviate the negative emotions of the called user when answering the harassment call, and improve the user experience. In addition, the call processing method has high flexibility in intercepting the harassment call. The call is not intercepted according to the number marking information. If the call is an important call, the call can be completed by paying the fee even if the call is marked as a harassment call. Thus, the call processing method can retain the opportunity of successful call and avoid the important call being intercepted.

[0020] The call processing method provided by the second aspect and the third aspect of the present application, the call processing method provided by the fourth aspect and the fifth aspect, the call processing device provided by the sixth aspect to the eighth aspect, the call processing device provided by the ninth aspect and the tenth aspect, the electronic device provided by the eleventh aspect, the computer readable storage medium provided by the twelfth aspect, and the computer program product provided by the thirteenth aspect have 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

[0021] 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 refer to like elements throughout. Therein:

[0022] Fig. 1 schematically shows a first framework diagram of a call processing system according to some embodiments of the present application; Fig. 2 schematically shows a second framework diagram of a call processing system according to some embodiments of the present application; Fig. 3 schematically shows a third framework diagram of a call processing system according to some embodiments of the present application; Fig. 4 schematically shows a fourth framework diagram of a call processing system according to some embodiments of the present application; Fig. 5 schematically shows a flow diagram of a call processing method according to some embodiments of the present application; Fig. 6 schematically shows a user interface for editing a paid call answering condition according to some embodiments of the present application; Fig. 7 schematically shows a flow diagram of a call processing method according to some other embodiments of the present application; Fig. 8 schematically shows a flow diagram of a call processing method according to some further embodiments of the present application; Fig. 9 schematically shows a call processing apparatus according to some embodiments of the present application; Fig. 10 schematically shows a call processing apparatus according to some other embodiments of the present application; Fig. 11 schematically shows a call processing apparatus according to some further embodiments of the present application; Fig. 12 schematically shows a flow diagram of a call processing method according to some embodiments of the present application;

[0023] Fig. 16 schematically shows an electronic device according to some embodiments of the present application; and Fig. 17 schematically shows a computer readable storage medium according to some embodiments of the present application. DETAILED DESCRIPTION

[0024] Example embodiments of the present disclosure will be described herein below 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 implemented 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 will fully convey the scope of the present disclosure to those skilled in the art.

[0025] 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 only for the purpose of describing the 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.

[0026] In view of the problem that the existing technology has poor effect on intercepting spam calls, resulting in that users are frequently affected by spam calls, embodiments of the present application provide a call processing method, device, equipment, computer program product and computer readable storage medium, a call processing method, device, equipment, computer program product and computer readable storage medium, and a call processing system to solve the problem that users are frequently affected by spam calls, and the main technical concept is to process incoming calls by constructing a paid call answering scheme through technical means, for example, in the case of detecting a call request, the calling number is obtained, and then a paid call answering process is performed on the calling number, the paid call answering process includes triggering an incoming call reminder after detecting payment confirmation information corresponding to the calling number, based on the paid call answering scheme, the calling user can be prompted or complete payment of a certain call answering fee to the called user, and then the incoming call reminder is triggered to remind the called user to answer the incoming call, thereby improving the call answering threshold of the called number and providing additional economic compensation for the called user to answer the call, since the incoming call that does not want to pay the call answering fee will not disturb the called user, and the incoming call that wants to pay the call answering fee can provide economic compensation for the called user, so that the negative emotions of the called user in answering the spam call can be effectively alleviated, and the user experience is improved, in addition, the paid call answering scheme has high flexibility in intercepting spam calls, and is not arbitrarily intercepted according to the number marking information, if it is an important call, even if it is marked as a spam call, it can also complete the call by paying, thereby retaining the opportunity for successful phone call and avoiding important calls being intercepted.

[0027] It should be noted that one of the technical concepts embodied in the paid call answering in the embodiments of the present application is that the incoming call reminder of the called terminal is triggered after the calling user (promises or actually completes) pays a certain fee to the called user, thereby achieving 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 chargeable call answering, paid call answering, paid reminder, chargeable reminder, paid reminder, paid ringing, chargeable ringing, paid ringing, etc., all of the above are equivalent concepts, and their essence is to represent the technical concept that the incoming call reminder of the called terminal is triggered after the calling user (promises or completes) 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 incoming 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 it is implemented, it should be within the protection scope of the present application.

[0028] It is worth noting 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 a user to a telecom operator when the user uses a mobile phone, a fixed phone or other communication services. The call fee is different from the call answering fee paid by the present application to the called user. The payment object, payment purpose and function of the two are different, and they belong to completely different technical concepts. They should be strictly distinguished and should not be confused.

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

[0030] As shown in FIG. 1, a first framework diagram of a call processing system provided by some embodiments of the present application is schematically shown. A calling user initiates a call to a called terminal used by a called user using a calling terminal. The call is implemented by sending a call request to the called terminal through a telecom network. The called terminal can obtain a calling number and execute a paid answering process for the calling number by installing a first application program when detecting the call request. The paid answering process includes triggering a call reminder after detecting payment confirmation information corresponding to the calling number.

[0031] The called terminal can also selectively perform paid answering for the calling number. For example, after obtaining the calling number, a preset judgment mechanism can be used to determine whether the paid answering process needs to be performed for the calling number. For example, it can be determined whether the calling number meets the paid answering condition. If yes, the paid answering process needs to be performed. For another example, it can be determined whether the calling number is a stranger number. If yes, the paid answering process needs to be performed. For another example, it can be determined whether the calling number is identified as a number that needs to be paid for answering by a call number recognition model. If yes, the paid answering process needs to be performed. If the paid answering process needs to be performed, the paid answering process is performed. If the paid answering process does not need to be performed, a normal answering process is performed. The normal answering process refers to any answering process other than the paid answering process, such as directly triggering a call reminder, directly intercepting a blacklist number, using an artificial intelligence assistant to answer, transferring a call to a voice mailbox, etc. The embodiments of the present application are not limited. If the paid answering process is performed, a call reminder can be triggered after detecting payment confirmation information corresponding to the calling number. When the called user answers the call under the reminder of the call reminder, the calling user and the called user can realize a call.

[0032] 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, for providing service support for the called terminal to implement paid answering, such as intelligent voice interaction, payment information query and various other 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 paid answering process is executed, and if paid answering is not needed, the normal answering process is executed.

[0033] 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 communication connection between the calling terminal and the service end on the basis of the second framework diagram, and the calling terminal is installed with a second application program which is the same as or corresponding to the first application program, 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 further 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 implement more rich paid answering functions.

[0034] 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 implemented 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 implement 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 implemented through the payment device, which can ensure that the calling user can smoothly call in the paid answering scenario through the payment function, and the called user can also implement more rich paid answering functions.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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 the user, providing reliable support for the paid call service; 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 the user 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 the calling user and the called user. 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 the skilled in the art can flexibly set the service end according to the 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 realize the purpose of the present application, which should be within the protection scope of the present application.

[0039] 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 role 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.

[0040] 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:

[0041] Step S101: In the case of detecting a call request, the calling number is obtained.

[0042] 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.

[0043] For example, the first call application can realize the process of obtaining the calling number through the following exemplary steps S1011-S1013:

[0044] Step S1011, register an incoming call event listener: the first call application needs to register an incoming call event listener when starting. The function of the listener is to listen to the incoming call event notification generated by the operating system. For example, in the Android system, a broadcast receiver (BroadcastReceiver) can be used to realize it; in the iOS system, the Core Telephony framework can be used to realize it.

[0045] Step S1012, receive the incoming call event notification: when a new call request arrives, the operating system will trigger an incoming call event notification. The incoming call event listener of the first call application will receive the incoming call event notification. For example, in the Android system, the broadcast receiver will receive an ACTION_PHONE_STATE_CHANGED broadcast; in the iOS system, the callEventHandler callback of the CTCallCenter class can be used to receive the incoming call event.

[0046] Step S1013, analyze the incoming call data packet: after receiving the incoming call event notification, the first call application needs to analyze the incoming call data packet and extract the calling number therefrom. For example, in the Android system, the getLine1Number() method of the TelephonyManager class or the Extras of the Intent can be used to obtain the calling number; in the iOS system, the callerID attribute of the CTCall object can be used to obtain the calling number.

[0047] Step S102: performing a paid answering process for the calling number, the paid answering process comprising triggering a call reminder after detecting payment confirmation information corresponding to the calling number.

[0048] The paid answering process refers to a series of steps performed to realize the paid answering function, and at least comprises triggering a call reminder after detecting payment confirmation information corresponding to the calling number. The payment confirmation information can refer to payment confirmation information for paying an answering fee to a first account for this call, and the first account is an account corresponding to a called user using the called terminal, i.e., a called user account, which can be bound to the called number, so as to ensure that the called user can receive appropriate economic compensation before triggering the call reminder. In addition, the payment confirmation information can be generated by the called terminal according to the payment situation or the promised payment situation, or can be generated by the server according to the payment situation or the promised payment situation and sent to the called terminal, which can achieve the purpose of the present application.

[0049] In actual application, in order to protect the interests of the calling party and the called party, the calling party can first pay the listening fee to an intermediate account on a payment platform (which can be one of the service platforms provided by the server), and then transfer the full or partial listening fee to the called party account after the called party answers the call (the server deducts part of the service fee, so it is partial transfer). In this case, although the listening fee is paid to the called party account in two stages, from the perspective of the calling party, the purpose of payment is still to pay the called party, and from the perspective of the called party, the listening fee received is still from the calling party. Therefore, even if the payment record shows that the calling party makes a payment to the intermediate account and the called party receives payment from the intermediate account, as long as it is essentially consistent with the inventive concept of the present application, it should still be considered as an equivalent technical means of the present application and is within the protection scope of the present application. In this case, the payment confirmation information can also include payment confirmation information for paying the listening fee to the intermediate account for this call. Moreover, the server or the called terminal can create a paid listening order for each incoming call. The paid listening order has a unique identification code such as an order number. The calling party makes a payment according to the paid listening order, whether it is to pay the listening fee to the intermediate account or to the called party account, and the intermediate account pays the listening fee to the called party account, which can be traced and integrated according to the paid listening order to form complete listening fee circulation information to prove that the listening fee is paid by the calling party to the called party. In the case of intermediate protection by the intermediate account, the incoming call reminder needs to be triggered after the listening fee is paid to the intermediate account. Therefore, in this case, the payment confirmation information can specifically refer to the payment confirmation information for paying the listening fee for this call to the server (such as the intermediate account). The payment confirmation information can be associated with the paid listening order for this incoming call to ensure that it ultimately pays the listening fee to the called party.

[0050] The incoming call reminder refers to the process in which the called terminal notifies the called user that there is an incoming call waiting to be answered through various ways. It usually includes various forms such as ringtone, vibration, screen prompt, etc. The specific form can be determined according to the incoming call reminder mode set by the user in the terminal.

[0051] The call processing method provided by the embodiments of the present application can improve the call answering threshold of the calling number. Since the calling user is willing to pay the call answering fee to trigger the call reminder, and unwilling to pay the fee to not trigger the call reminder, the method can realize the interception of part of the telephone, effectively reducing the call reminder amount and the actual call amount of the harassing telephone on the called terminal. Since the call answering of the harassing telephone requires the calling user to pay a certain call answering fee to the called user, the call answering of the harassing telephone can bring additional economic compensation to the called user, thereby effectively alleviating the negative emotions of the called user in answering the harassing telephone, and even more willing to answer the strange telephone, improving the user experience. For example, if the user obtains the call answering fee from the process of answering the fraudulent telephone but is not cheated, a higher satisfaction and sense of achievement can be obtained. In addition, the interception of the harassing telephone has a high flexibility space, and is not arbitrarily intercepted according to the number marking information. If it is an important telephone, even if it is marked as a harassing telephone, it can be called by paying the fee, thereby retaining the opportunity of successful telephone call and avoiding the interception of important telephone.

[0052] It is considered that in actual application, the user often only needs to perform the paid call answering on the harassing telephone, and often does not select the paid call answering for the known contact person such as the acquaintance. Therefore, the embodiments of the present application can also selectively perform the paid call answering on the calling number. For example, after obtaining the calling number, whether the calling number needs to perform the paid call answering process can be determined according to a preset judgment mechanism. The preset judgment mechanism can be whether the calling number meets the preset paid call answering condition, and the paid call answering process needs to be performed if the calling number meets the condition. The preset judgment mechanism can also be whether the calling number is a strange number, and the paid call answering process needs to be performed if the calling number is a strange number. The preset judgment mechanism can also be whether the calling number is identified as a number that needs to be paid for call answering by a preset call number recognition model, and the paid call answering process needs to be performed if the calling number is identified. The preset judgment mechanism can also be whether the call intention corresponding to the calling number belongs to the paid call answering intention, and the paid call answering process needs to be performed if the call intention belongs to the paid call answering intention. The preset judgment mechanism can also be that the paid call answering condition and the paid call answering intention jointly determine whether the paid call answering process needs to be performed. If the calling number meets the paid call answering condition and the call intention belongs to the paid call answering intention, the paid call answering process needs to be performed. The above judgment mechanisms can be flexibly set according to the actual needs of the person skilled in the art, and the essential purpose is to select the calling number meeting the needs of the called user for paid call answering. Therefore, in some embodiments of the present application, the calling number can be selectively paid for call answering from multiple dimensions based on the above preset judgment mechanism. The above performing the paid call answering process on the calling number can include triggering the paid call answering process by using at least one of the following paid call answering triggering manners:

[0053] The first paid call answering triggering mode: in the case that the calling number meets the paid call answering condition, a paid call answering process is executed.

[0054] The second paid call answering triggering mode: in the case that the calling number is a stranger number, a paid call answering process is executed.

[0055] The third paid call answering triggering mode: in the case that the calling number is identified by a preset caller number identification model as needing paid call answering, a paid call answering process is executed, wherein the caller number identification model is set in the called terminal locally or on a server.

[0056] The fourth paid call answering triggering mode: in the case that the calling intention corresponding to the calling number belongs to a paid call answering intention, a paid call answering process is executed.

[0057] The fifth paid call answering triggering mode: in the case that the calling number meets the paid call answering condition and the calling intention corresponding to the calling number belongs to a paid call answering intention, a paid call answering process is executed.

[0058] The first paid call answering triggering mode is paid call answering according to a paid call answering condition. This mode allows the user to define a series of rules for selective paid call answering of incoming calls. The paid call answering condition is one or a series of conditions set for paid call answering, which can be set and take effect on the called terminal, and is used to determine whether the calling user needs to pay a call answering fee to trigger the incoming call reminder of the called terminal. It aims to restrict the called terminal to identify the calling number and limit the incoming call reminder of part of the calling number, so that this part of the calling number needs to pay a certain fee to trigger the incoming call reminder of the called terminal. In another aspect, the paid call answering condition is used to determine whether the calling number is suitable for the paid call answering process. If the calling number meets the paid call answering condition, the called terminal will execute the paid call answering process. If the calling number does not meet the paid call answering condition, the called terminal will execute the normal call answering process. Through this embodiment, the incoming call can be selectively answered according to the paid call answering condition freely set by the called user, which can meet the user's demand for flexible and customized paid call answering conditions, form a rich, diversified and personalized paid call answering condition for judging the incoming call, and better meet the user's paid call answering demand.

[0059] Based on the first paid answering trigger mode, the call processing method provided by the embodiment of the application can improve the answering threshold of the calling number by detecting the calling number when detecting the call request, and executing the paid answering process when the calling number meets the paid answering condition, the paid answering process including triggering the call reminder after detecting the payment confirmation information corresponding to the calling number, so that the answering threshold of the calling number can be improved. Since the calling user needs to pay the answering fee to trigger the call reminder, the call reminder of the harassing call will not be triggered if the calling user does not want to pay the fee, so that the interception of part of the calls can be realized, and the amount of call reminders and actual calls of the harassing calls on the called terminal can be effectively reduced. Since the answering of the harassing call requires the calling user to pay a certain answering fee to the called user, the answering of the harassing call can bring additional economic compensation to the called user, thereby effectively alleviating the negative emotions of the called user when answering the harassing call and improving the user experience. In addition, the interception of the harassing call has a high flexibility, and is not arbitrarily intercepted according to the number marking information. If it is an important call, even if it is marked as a harassing call, the call can be completed by paying the fee, so that the opportunity of successful call can be reserved, and the important call can be avoided from being intercepted.

[0060] The second paid answering trigger mode is paid answering for unknown calls. Since most of the harassing calls are unknown numbers, including unknown numbers in the paid answering range can help users avoid unnecessary disturbance and effectively curb malicious calling behavior. When detecting that the incoming call is an unknown number, the paid answering process is automatically started, and the call will be connected only after the calling user confirms to bear the answering fee. This not only protects the privacy of the user but also reduces the disturbance caused by unnecessary calls. This mode can meet the paid answering needs of most users, and the logic judgment is simpler, the implementation difficulty and cost are lower, the answering threshold of the unknown calling number can be improved, and it is suitable for users who like simple settings.

[0061] The third paid answering trigger mode is to use artificial intelligence technology and big data analysis technology to perform paid answering on the incoming call number. The incoming call number recognition model is trained by using artificial intelligence technology and big data analysis technology, such as using machine learning algorithm to analyze historical data and establish the incoming call number recognition model to evaluate the risk level of each incoming call. If the model determines that a certain incoming call has a high probability of belonging to the harassing or other undesirable category, it will suggest to execute the paid answering process. This method not only improves the decision accuracy but also enhances the intelligent level, making the judgment process more scientific and reasonable, and the recognition result more accurate, which can meet the paid answering needs of the called user to a large extent.

[0062] The fourth paid call answering trigger mode is to answer the call according to the calling intention of the calling user. The calling intention can be inferred by analyzing the historical behavior of the calling number, communication records and other related data, or the purpose or intention of the call can be identified according to the identity information and call information provided by the calling user, such as different types of call purposes, such as sales promotion, customer service follow-up, emergency notification, etc. The paid call answering intention refers to the intention of the calling user to pay the call answering fee before triggering the called terminal to remind the call, such as sales promotion, fraud, etc. The called terminal can determine the calling intention of the calling user by executing the call intention recognition step, and determine whether to trigger the paid call answering process according to the matching result of the call intention and the paid call answering intention. If the call intention matches the paid call answering intention, that is, the call intention belongs to the paid call answering intention, the paid call answering process is triggered; if the call intention does not match the paid call answering intention, that is, the call intention does not belong to the paid call answering intention, the normal call answering process is triggered.

[0063] In some embodiments, the call intention recognition step can use a pre-set call intention recognition model to analyze the intention of the current call. The model can be deployed locally on the called terminal or on the server. Based on machine learning algorithms and big data analysis techniques, the model can extract features from a large amount of historical call data and build a prediction model. When a new call request arrives, the call intention recognition model will evaluate the calling intention of the current call based on the characteristics of the current call number (i.e. the calling number) (such as call time, calling frequency, historical call records, etc.), and determine whether it belongs to the paid call answering intention. If it is determined that the calling intention of the current call belongs to the paid call answering intention, the paid call answering process is triggered.

[0064] In addition, the call intention recognition model can also identify the calling intention through social graph analysis, such as inferring the calling intention based on the social relationship between the calling user and the called user, and the common contacts and other factors.

[0065] In other embodiments, the calling user can send call additional information to the called terminal through the calling terminal, and the call additional information includes the identity information of the calling user and / or the call description information input by the calling user. Accordingly, the call intention recognition step can identify the calling intention of the calling user based on the call additional information. The call intention recognition step includes: receiving the call additional information sent by the calling terminal, the call additional information including the identity information of the calling user and / or the call description information; identifying the calling intention of the calling user according to the call additional information.

[0066] The incoming call additional information refers to information sent by the calling user to the called terminal through the calling terminal and / or information requested by the called terminal from the server about the calling user, including but not limited to identity information (such as name, company name, etc.) of the calling user and incoming call description information (such as call purpose, etc.) input by the calling user. The call intention of the calling user is identified according to the incoming call additional information. The call purpose or intention of the calling user can be determined by analyzing the incoming call additional information. This process can be implemented by using machine learning algorithms and big data analysis techniques to improve the accuracy and intelligence level of the determination.

[0067] For example, when the calling user wants to contact the called user by phone, some additional information can be input on the calling terminal, such as selecting an electronic business card suitable for this call or inputting the purpose or description of this call. These information will be sent to the called terminal as part of the incoming call additional information along with the call request. For example, on the calling terminal, the calling user can select to fill in or select preset identity information (such as name, company name, etc.) and input a short incoming call description information (such as "discussion on project X" or "urgent technical support request"). These information will be packaged into the incoming call additional information and transmitted to the called terminal through the communication network. After receiving the incoming call additional information, the called terminal automatically parses the information and identifies the call intention according to the preset algorithm. The call intention identification process can be implemented based on natural language processing (NLP) technology and machine learning model to extract key information from text and classify.

[0068] In some embodiments, the present application provides multiple incoming call interaction modes. The called terminal can obtain the above-mentioned incoming call additional information through the incoming call interaction process, which is illustrated as follows:

[0069] The first incoming call interaction mode: the calling terminal sends an electronic business card, which records the identity information of the calling user, so as to indicate the identity of the calling user through the electronic business card. For example, insurance marketing, etc. The called terminal identifies the call intention according to the identity information of the calling user recorded on the electronic business card.

[0070] The second incoming call interaction mode: the calling user explains the call purpose by having a dialogue with the intelligent voice assistant of the called terminal, such as transmitting the call description information to the called terminal through voice, which includes the call purpose and other description information input by the calling user. The intelligent voice assistant of the called terminal identifies the call intention according to the call description information. This mode can use natural language processing technology and intelligent voice assistant to automatically parse the voice input of the calling user to understand and determine the purpose of the call.

[0071] 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.

[0072] For 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. Identity information refers to the basic information used to identify the caller, including but not limited to name, company name, and contact information.

[0073] In some examples, when a caller wants to contact a called user, they can select or fill in the user's electronic business card on their terminal and send it along with the call request to the called terminal. After receiving the electronic business card, the called terminal will automatically parse the identity information and identify the caller's intent based on this information. For example, if the electronic business card shows that the caller is a salesperson from an insurance company, the called terminal can identify the caller's intent as a sales pitch; if the electronic business card shows that the caller is an after-sales technician, the called terminal will identify the caller's intent as after-sales service.

[0074] Based on the first call interaction method, using electronic business cards, 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 a paid call process. 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 caller ID or call notification interface, helping the called user better understand the call background and make a more informed decision. For example, suppose an insurance salesperson attempts to contact a potential client. They can send an electronic business card containing their identity information through the calling terminal. Upon receiving the electronic business card, the client's mobile phone can recognize it as an insurance sales call and initiate a paid call process. After the caller pays the call fee, the called terminal provides a call notification, and the called user can decide whether to answer the call based on the electronic business card displayed on the call notification interface.

[0075] For the second type of call interaction, the intelligent voice assistant is an artificial intelligence 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 through voice or selection controls regarding the purpose or purpose of the call.

[0076] In some examples, when a caller dials a callee's number, the called terminal can answer the call and use a smart voice assistant to converse with the caller, guiding the caller to explain the purpose of the call. After the caller inputs the explanation of the call via voice, the smart voice assistant will automatically parse the voice input and identify the caller's intent. The called terminal can then decide how to handle the call based on the analysis results of the smart voice assistant.

[0077] 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.

[0078] For the third type of call interaction, the identity option is a preset set of options for the caller to select their identity category, such as insurance sales, financial services, student tutoring, real estate agency, delivery, etc. The call purpose option is also a preset set of options for the caller to select their call purpose, such as product promotion, package pickup, package delivery, etc.

[0079] In some examples, when a caller dials a callee's number, the callee's intelligent voice assistant can instruct the caller to select the appropriate identity or call purpose option to respond. The caller's terminal can display these options through a second call application, and the caller can choose the option that best suits their situation. The caller's terminal then feeds back the caller's selection to the callee's terminal, which identifies the caller's identity and call purpose based on the selected option information, thereby determining the caller's intent.

[0080] 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.

[0081] Based on the fourth paid call triggering method described above, by identifying the caller's intent, the called terminal can recognize the caller's intent and decide whether to execute the paid call process accordingly. This allows for more accurate call screening and processing, improving decision-making accuracy and enhancing user experience and service quality. For example, important or urgent calls can be quickly identified and allowed to pass, avoiding unnecessary charges that might cause the caller to refuse payment, thus preventing the called party from missing the call. Furthermore, potential nuisance calls can be effectively filtered through the paid mechanism, reducing disturbance to the called party and improving user experience and service satisfaction. This approach provides users with a more flexible and efficient communication management tool, ensuring that every call has high value.

[0082] The fifth paid call triggering method mentioned above comprehensively considers the paid call receiving conditions and the caller's intent to conduct paid call receiving. The judgment process of the paid call receiving conditions and the caller's intent can be understood with reference to the first and fourth paid call triggering methods mentioned above, and will not be repeated here. In addition, 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 the embodiments of this application. In order to improve overall efficiency and avoid waste of resources, in some embodiments, the judgment of the paid call receiving conditions can be performed first and then the judgment of the caller's intent can be performed. The paid call receiving process is executed 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. This includes: when the calling number meets the paid call receiving conditions, executing the caller's intent identification step.

[0083] If the identified caller intent is to receive a paid call, the paid call process will be executed.

[0084] Based on the fifth paid call triggering method mentioned above, by combining paid call conditions and caller intent recognition, it is possible to more accurately filter out calls that require paid call processing. 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 call processing more accurately meet the needs of the called party. 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 processing, improving the accuracy of paid call judgment. For example, if the caller is a relative of the called party but has changed their phone number, and the called party's terminal has set the paid call condition to [a specific condition], [the system can detect this]. When a caller requests a paid call from an unknown number, if the process only involves determining the conditions for a paid call, then the call would need to be paid for for that relative. However, if a caller intent recognition process is added, where the caller provides their identity information during the call, the caller intent recognition step can identify that the caller's intent is that of a relative, not a paid call. In this case, the normal call answering process can proceed, such as triggering a call reminder and displaying the caller intent recognition result on the reminder screen, allowing the called user to understand the caller's intent. Clearly, in this scenario, a dual verification mechanism can more accurately determine whether a paid call should be made to the caller's number, thus improving the user experience.

[0085] This application embodiment selectively processes paid calls by employing the aforementioned multiple paid call triggering methods, providing called users with a powerful and flexible calling tool to manage various situations in daily communication. It not only accurately identifies potential nuisance calls, reducing the possibility of user interference, but also allows users to set different paid call strategies according to their personal preferences, thereby achieving a more personalized service experience. Simultaneously, this mechanism promotes efficient resource allocation, as only truly valuable calls are accepted, thus reducing the cost and time wasted on ineffective communication. Furthermore, by introducing a caller ID model, it can continuously learn and optimize its judgment capabilities, further improving overall performance and service quality.

[0086] It should be noted that the above-mentioned paid call triggering methods are different basic solutions based on the same concept, and their criteria for infringement determination differ slightly. For example, the first paid call triggering method involves paid call conditions, which can be used to determine infringement based on the settings of the call application installed on the called terminal; the second paid call triggering method involves unknown numbers, which can be used to determine infringement based on whether the unknown number is in the contact list or whether the caller ID shows contact information; the third paid call triggering method involves caller ID recognition models, in which case using source code or product specifications for infringement determination is a feasible method; the fourth paid call triggering method involves caller ID intent recognition, which can be determined using source code or product specifications, and in schemes that use caller ID intent recognition based on additional caller ID information, the additional caller ID information can also be used for infringement determination; the fifth paid call triggering method requires both evidence related to paid call conditions and caller ID intent recognition for infringement determination. These various paid call triggering methods can also be combined, as will be shown in the subsequent implementation examples.

[0087] Based on the above-mentioned paid call triggering method, this application can also be extended and modified through the following many modified implementation methods to obtain more specific solutions applicable to various application scenarios. Any of the following modified implementation methods can be combined with any of the above-mentioned paid call triggering methods, or a suitable paid call triggering method can be selected and combined according to the technical content. Since there are too many combination schemes to describe them one by one, those skilled in the art should be able to combine various combination schemes according to actual needs to achieve more specific purposes based on the embodiments of this application, and all of them should be within the protection scope of this application.

[0088] In addition, for ease of understanding, the following embodiments are mainly based on the first paid call triggering method described above. However, the following embodiments are also applicable to the second to fifth paid call triggering methods described above. Those skilled in the art can make reasonable changes based on the following embodiments to make them applicable to the various paid call triggering methods described above. Therefore, some similar contents will not be described in detail. Please refer to each implementation method for mutual understanding.

[0089] It should be noted that in the above embodiments, the conditions for paid call reception can be set by default or set by the user.

[0090] For example, the first call application can preset a series of default paid call conditions. These default conditions are designed to provide users with a basic protection mechanism to help them reduce the interference of harassing calls. For example, the default setting is to charge for answering all unknown numbers, or to charge for answering specific types of unknown numbers (such as sales calls or scam calls). The default paid call conditions can take effect immediately when the user uses the application for the first time, without the need for complicated settings by the user. This can not only improve the user's convenience, but also ensure that the user can enjoy the anti-harassment function from the very beginning.

[0091] For example, users can set their own paid call conditions based on their needs and preferences. For instance, users can set paid call receiving for specific types of unknown numbers, numbers on or off a specific list, calls within a specific time period, or calls from specific regions. This flexible setting allows users to customize the paid call conditions to best suit their needs, giving them better control over their calling environment and reducing unnecessary interference. Furthermore, multiple sets of paid call conditions can be set, allowing users to flexibly adjust or select conditions based on their specific circumstances. For example, stricter conditions can be set for weekdays, while more lenient conditions can be set for weekends or holidays. This dynamic adjustment function allows users to flexibly respond to different calling needs.

[0092] Regarding the specific details of the paid call receiving 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 settings. This application embodiment does not impose any limitations.

[0093] 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.

[0094] 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 require paid answering. For example, users can choose to answer all unknown numbers for a fee, while answering known numbers for free.

[0095] Number category refers to information obtained by classifying telephone numbers according to the caller's purpose, business type, or the identity of the number holder (i.e., the caller). It is used to characterize the caller's purpose, business type, or the identity of the number holder. Categories include, but are not limited to, delivery calls, marketing calls, food delivery calls, fraud calls, official calls, and unclassified calls. Delivery calls can be from delivery companies or delivery personnel; marketing calls can be from marketing companies or individuals; food delivery calls can be from food delivery platforms or delivery personnel; fraud calls are suspected fraudulent calls; official calls are the office phones of government agencies, public service providers, public safety personnel, police, judicial organs, and other public institutions and their personnel; and unclassified calls are telephone numbers without number tagging information, number registration information, or number authentication information. By using number category as a condition for paid call reception, users can more precisely control which specific types of numbers require paid reception. For example, users can choose to receive marketing and fraudulent calls for a fee, while receiving other types of calls for free.

[0096] Furthermore, the aforementioned number categories can also be the result of multi-level classification. For example, marketing calls can be further subdivided according to marketing categories, including but not limited to: education and training, financial management, real estate agencies, insurance sales, e-commerce promotions, decoration companies, recruitment and headhunting, etc. This provides users with a richer and more detailed selection of number categories, allowing them to decide whether to trigger a paid call process 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, users might want to handle different types of marketing calls differently. Through multi-level categorization, 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. These subcategories can even be further subdivided. This allows users to set different paid call conditions based on their interests and needs. For numbers they are interested in or need, the answering threshold can be lowered (e.g., lowering the fee or not triggering the paid call process), while for numbers they are not interested in or need, the answering threshold can be raised (e.g., triggering the paid call process or increasing the fee). For instance, users can set paid call conditions to answer education and training marketing calls for free, while paying for financial management marketing calls. By categorizing numbers at multiple levels and applying this to setting paid call conditions, users can flexibly set multi-level paid call conditions according to their actual situation and needs, thereby achieving more precise call management.

[0097] It should be noted that the number category can classify both unknown and known numbers. However, since most users do not set up paid call reception for known numbers, in some implementations, the number category can be based on unknown numbers. That is, the number category can be obtained by classifying unknown numbers. In this case, the paid call reception conditions can be further determined based on the number category, in addition to the unknown numbers. Furthermore, embodiments of this application can also support triggering a paid call reception process for known numbers based on user-defined paid call reception conditions. The above explanation does not constitute or should be construed as limiting the scope of protection of this application.

[0098] A custom number list refers to a user-defined list of numbers used to allow users to specify which specific caller IDs will trigger a paid call handling process or not. This includes, but is not limited to, paid lists, free lists, blacklists, and whitelists. For example, numbers in the paid list may require paid call handling, numbers in the free list may not, numbers in the blacklist may be directly blocked, and numbers in the whitelist may trigger call alerts. Setting a custom number list helps users manage incoming calls more flexibly. It should be noted that the paid and free lists in this application embodiment may use other names in practical applications, but as long as they fulfill the function of limiting whether a paid call handling process is directly triggered as described in this application embodiment, they should be considered equivalent concepts and within the scope of protection of this application.

[0099] 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. Specific regions refer to numbers originating from a particular city or province, specific carriers refer to numbers originating from a specific telecommunications company, and international numbers refer to numbers originating from other countries or regions. By setting number origin, users can more precisely control which sources of numbers require paid access. For example, users can choose to pay for calls from numbers originating from a specific region or for international numbers.

[0100] The paid call indicator is a user-defined identifier for known phone numbers. It can have two states: true ("true") and null ("null"). Users can specify whether a particular phone number should be charged for calls. A true value indicates that the known number should be charged for calls, while a null value indicates that the known number should not be charged for calls. This indicator allows users to define which contacts or phone numbers should be subject to the paid call mechanism, providing a more personalized and controllable communication management approach. Users can set a paid answering flag for specific known numbers through the First Call application or related service interface. When a known number is set to have a paid answering flag by the called user (the paid answering flag changes from an empty value to a true value), and the paid answering condition is also set to trigger the paid answering process for incoming calls with a true paid answering flag, subsequent incoming calls from that known number will trigger the paid answering process. This helps the called user reduce the negative emotions caused by harassing calls or nuisance calls from known numbers. For example, the called user can choose to set this flag for certain frequently disturbing but not completely blocked known numbers (such as sales calls, non-emergency service hotlines, etc.) to receive calls for a fee.

[0101] 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 that the caller ID meets 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 paid call reception process. In addition, when the paid call indicator setting option is detected to be selected by the user and the paid call indicator changes from an empty value to a true value, the called number can be automatically added to the paid list. When the paid call indicator setting option changes from selected to unselected and the paid call indicator changes from a true value to an empty value, the called number can be automatically removed from the paid list. This provides users with a more convenient and timely way to add paid numbers, which helps to improve the user experience.

[0102] 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, users can be provided with a more personalized and differentiated service experience. It also introduces 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, high-level members can set unknown numbers above a certain level to trigger the paid call answering process, while unknown numbers below that level will be directly rejected and will not trigger the paid call answering process. In addition, membership level can also affect the calculation method of call charges, priority processing, and other privileges in paid call answering scenarios.

[0103] By determining whether a caller's number qualifies for paid call reception based on membership level, a more flexible and personalized paid call reception plan can be provided. Through a reasonable configuration of the membership level mechanism, not only can the user experience be improved, but also interaction and trust among users can be promoted, creating a healthy and active communication environment.

[0104] 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 a paid call 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, promotional, or otherwise unwanted.

[0105] In one example, to implement the caller ID model, a large amount of training data first needs to be collected and processed. This data typically includes, but is not limited to, basic information about the caller ID (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 spam call). By learning from this data, the model can identify which features are highly associated with high-risk calls. For example, numbers that frequently dial different users' numbers but with extremely short call durations may be marked as potential sources of spam; while numbers that frequently appear on blacklists are more likely to be telemarketing calls. Furthermore, the caller ID model can combine contextual information, such as the time period and frequency of the call, and the user's current status (such as whether they are busy or not), to further improve the accuracy of the identification.

[0106] Once the caller ID model completes its risk assessment of the caller ID, it generates an identification result to guide subsequent paid call decisions. If the model determines that the caller ID has a high probability of being a nuisance or salesperson, it recommends implementing a paid call process for that number, or directly triggers the paid call process. This approach not only helps users effectively filter out unnecessary call interference and reduce the inconvenience caused by 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 nuisance calls. Furthermore, because the model is trained on a large amount of real data, its judgment results have high reliability and can largely avoid misjudgments.

[0107] Furthermore, the caller ID model supports continuous updates and self-optimization. With the accumulation of new data, the model can continuously adjust its internal parameters through online learning to adapt to changing communication environments and technological trends. This means that over time, the caller ID model can increasingly accurately identify which calls should trigger a paid call process, thus providing users with a more precise service experience. By introducing the caller ID model's identification results as an important dimension of the paid call condition, this application not only enhances the level of intelligence but also provides users with a more flexible and efficient call management tool.

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

[0109] The aforementioned effective time, also known as the additional condition element, refers to the time information when the paid call receiving condition takes effect. This time can include one or more time periods, referred to as the paid call receiving period. The default is all-day validity, 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 specific time periods. For example, users can choose to receive all incoming calls for a fee between 10 PM and 6 AM, or receive specific types of numbers for a fee on holidays and weekends, reducing unnecessary interference and improving call reliability and user experience.

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

[0111] The pricing standard refers to the specific fee information for paid call reception. It's the charging standard for the called user based on the caller's number. It can use default settings or be flexibly adjusted by the user according to their individual needs. It can be a fixed amount charged per call, or a dynamic amount corresponding to different call duration thresholds, number categories, and effective times. A fixed amount means all eligible caller ID numbers must pay a fixed amount, while a dynamic amount sets different payment amounts based on different criteria, such as charging higher amounts for specific types of unknown numbers. For example, a user can set a rule that all unknown numbers must pay a fixed amount of 1 yuan per call; or charge 2 yuan per call for specific types of unknown numbers (such as marketing calls). By setting different pricing standards, users can manage incoming calls more flexibly according to their needs and preferences. It should be noted that the pricing standard can use default settings or be flexibly adjusted by the user according to their individual needs. Considering the convenience of payment and the widespread demand for the prepayment-then-call mode, some embodiments of this application can adopt a per-call payment method. This eliminates the need to calculate the call fee based on factors such as call duration, thereby reducing system load and improving payment efficiency. Moreover, it can meet the special requirements of the prepayment-then-call mode.

[0112] 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.

[0113] Based on the above description, in this embodiment, the paid call answering conditions can be determined based on at least one of the following condition elements: number familiarity, number category, custom number list, number source, paid call answering identifier, membership level, caller ID model recognition result, effective time, and charging standard. Specifically, as described in the foregoing embodiments, number familiarity, number category, custom number list, number source, paid call answering identifier, membership level, and caller ID model recognition result can all be used as unique condition elements to generate paid call answering conditions individually or in combination. Effective time and charging standard are generally used as additional condition elements combined with other condition elements to generate paid call answering conditions. However, in some modified embodiments, paid call answering conditions can also be generated independently based on effective time or charging standard. For example, effective time can be used as the sole condition element to generate paid call answering conditions independently. A paid call answering condition generated based on effective time could be that the paid call answering process is executed for all call requests within the effective time, and not executed for all call requests outside the effective time. Thus, as long as the call occurs within the effective time, the paid call answering process can be triggered. Furthermore, the pricing standard can also be used as the sole condition element to generate paid call answering conditions. For example, the paid call answering conditions generated based on the pricing standard could be that all incoming calls are answered for a fee, and charges are applied according to the pricing standard. This can also meet specific user anti-harassment needs, and is consistent with the inventive intent of this application, and should therefore be within the scope of protection of this application. The embodiments of this application, by generating paid call answering conditions based on at least one of the above-mentioned condition elements, can support users in freely setting paid call answering conditions from different dimensions and angles, comprehensively meeting users' personalized paid call answering needs and improving the user experience.

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] In one example, when a user performs a setting trigger operation, the First Call app responds and displays a paid call condition editing interface. This interface has editable elements corresponding to at least one of the following dimensions: number familiarity, number category, custom number list, number source, paid call indicator, membership level, and caller ID model recognition result. Furthermore, to add additional conditions such as effective time and pricing to the paid call conditions, the interface can also have editable elements corresponding to at least one of the following dimensions: effective time and pricing standard. Users can set and modify these elements, such as selecting to pay for all unknown numbers, paying for marketing calls, setting blacklists and whitelists, determining whether to execute the paid call process based on caller ID model recognition results, selecting to pay for all unknown numbers between 7 AM and 8 PM, setting to pay for numbers in specific regions, and setting specific pricing standards. The First Call app determines the final effective paid call conditions based on the user's editing of these elements.

[0119] 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.

[0120] It should be noted that the above conditions can be selected individually or in combination to form paid call answering conditions. Users only need to edit the corresponding editable elements. For example, users can combine multiple conditions to form complex paid call answering conditions according to their needs and preferences. These combined conditions can cover multiple dimensions. For example, users can set up paid call answering for all unknown numbers except for official business calls, express delivery calls, and food delivery calls. The charging standard for uncategorized calls is 1 yuan / call, the charging standard for marketing calls is 2 yuan / call, and the charging standard for fraudulent calls is 5 yuan / call. Thus, different answering fees are charged for different types of callers based on the degree of harassment or the user's tolerance for harassing calls.

[0121] Furthermore, to ensure the effectiveness and flexibility of the combined paid call conditions, different priorities can be set for different condition elements to form logically clear and accurate paid call conditions. The specific priority settings will not be elaborated in this application embodiment. Those skilled in the art can flexibly set and adjust them according to actual needs, or the user can set the priority of each condition element himself.

[0122] Please refer to Figure 6, which schematically illustrates a paid call receiving condition editing interface provided by some embodiments of this application. In some specific examples, when the user performs a setting trigger operation, the paid call receiving condition editing interface will be displayed. On this interface, the user can see and edit multiple editable elements. For example, the user can enable the paid call receiving function for unknown numbers by turning on the switch corresponding to the "Enable paid call receiving for unknown numbers" function in Figure 6. On this basis, the user can further turn on the switch corresponding to "Category Settings" to trigger the expansion of the category settings control, and select the number category for which the paid call receiving function needs to be enabled in the category settings control. For example, in Figure 6, "Marketing Calls", "Fraud Calls" and "Uncategorized Calls" are selected to specifically enable the paid call receiving function. The paid call receiving function will not be enabled for "Express Delivery Calls", "Food Delivery Calls" and "Business Calls" which are not selected. In addition, the charging standard can be set to "1 yuan / time". After the user completes the settings, they can click the "Back" button to save the edited paid call receiving conditions and make them effective.

[0123] In addition, in some examples, users can also edit editable elements by choosing to pay for all unknown numbers, choosing to answer courier calls for free, adding specific customers' numbers to a whitelist, and setting a fixed charge of 1 yuan per call for all eligible callers, or a charge of 2 yuan per call for specific types of unknown numbers (such as marketing calls). Every operation performed by the user in the editing interface will be recorded by the system. For example, if the user selects "marketing calls" in the checkbox corresponding to the number category and enters "1 yuan" in the input box of the charging standard, the First Call application will update these settings in real time and save these settings as conditions for paid call answering after the user completes all editing operations.

[0124] To ensure that user settings take effect accurately, the following steps can be performed on user editing operations:

[0125] 1. Real-time feedback: When users are making editing operations, the First Call app can provide real-time feedback, displaying a preview of the current settings so that users can understand the paid call conditions they have set in real time, improving the intuitiveness of the paid call condition settings and enhancing the user experience. For example, when a user selects to pay for all unknown numbers, a message can be displayed immediately to inform the user that this setting will affect all incoming calls not in the contact list.

[0126] 2. Verification and Prompts: The first call application or server can verify the user's settings to ensure that all input data is in the correct and reasonable format, so as to ensure that the generated paid call conditions are logically sound and rigorous. For example, if the user enters a negative number in the input box of the charging standard, the application can pop up a prompt to inform the user that the input is invalid and ask the user to re-enter it.

[0127] 3. Saving and Applying: When the user completes all editing operations and clicks the "Save" or "Back" button, the First Call application or server can save the user's settings to the database and apply these settings immediately.

[0128] 4. History and Restore: The First Call app or server can also record every setting operation the user makes, allowing the user to view and restore previous settings, further enhancing the user experience. For example, users can view all past settings in the settings history and choose to restore to a specific setting.

[0129] 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.

[0130] 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. Those skilled in the art can flexibly set them according to actual needs, and they should all be within the protection scope of this application.

[0131] It should be noted that different caller ID categories can have the same or different pricing standards. For example, unclassified calls might be charged 1 yuan per call, marketing calls 2 yuan per call, and fraudulent calls 5 yuan per call. This raises the barrier to entry for different number categories and provides varying levels of benefit to the called party. This tiered pricing system helps called parties set different rates based on factors such as the risk associated with each number category, the caller's willingness to call, and the called party's acceptance (or resistance) to that number category. For instance, unclassified calls typically refer to those... Unidentified numbers that are not clearly categorized may pose some risk of harassment, but the overall risk is relatively low. Therefore, setting a charge of 1 yuan per call can serve as a screening measure without excessively burdening the caller. Marketing calls usually originate from businesses and are often promotional in nature, posing a higher risk of harassment. To reduce interference from these calls, a higher charge of 2 yuan per call can be set, thereby raising the bar for answering marketing calls. Scam calls are the most dangerous type of call. These calls may not only lead to financial losses but also threaten user safety. Therefore, setting a maximum charge of 5 yuan per call can significantly raise the bar for answering scam calls and effectively reduce their interference.

[0132] 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.

[0133] Tiered pricing can be implemented based on at least one of several dimensions, including number familiarity, number category, custom number list, number source, paid call indicator, membership level, caller ID model results, and effective date. Each dimension can correspond to different rate rules. For example, tiering based on number familiarity could mean different rates for unfamiliar and known numbers; tiering based on number category could mean different rates for different types of phone numbers (e.g., local, long-distance, international); tiering based on custom number lists could mean different rates for numbers on different custom lists; and tiering based on number source could mean different rates for numbers from different channels. Different pricing standards can be applied to different numbers on a channel or platform (such as regular telephone networks, VoIP services, etc.); different pricing standards can be applied based on paid call identification tags; different pricing standards can be applied based on membership levels (such as regular members, premium members, etc.); different pricing standards can be applied based on caller ID model identification results (e.g., different risk levels identified by the caller ID model correspond to different pricing standards); and different pricing standards can be applied based on effective time (e.g., weekdays, non-weekdays, peak hours, off-peak hours).

[0134] By establishing tiered pricing, different types of calls can be managed more precisely. This allows called users to flexibly set pricing based on their needs and preferences. For example, users who frequently receive marketing calls can have higher pricing to reduce their frequency, while those who frequently receive unclassified calls can have lower pricing to facilitate important but unclassified calls. This flexibility not only improves the user experience but also effectively balances the interests of 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 calls before making them. Higher pricing encourages callers to be more cautious when making high-risk or low-acceptance calls, 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.

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

[0136] 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.

[0137] Please refer to the foregoing explanation of the meaning and function of each of the above paid call conditions for further understanding. This will not be repeated here. Any one of these conditions can be set as a paid call condition and used to trigger the paid call process when the calling number meets that condition. Furthermore, the above conditions can be combined to generate more detailed and precise paid call conditions. When used in combination, the paid call process can be triggered when the calling number meets any one of the combined conditions, or when the calling number meets every single condition in the combined condition. Those skilled in the art can flexibly set the triggering mechanism according to actual needs. This application does not limit the scope of the embodiments described, and all of them should be within the protection scope of this application.

[0138] In addition, some commonly used paid call receiving conditions are introduced. In some specific implementations, the paid call receiving conditions may include any of the following:

[0139] The first condition is to accept paid calls from all unknown numbers; the second condition is to accept paid calls from unknown numbers within the preset paid call category; and the third condition is to accept paid calls from unknown numbers outside the preset free call category.

[0140] The preset paid call categories can refer to user-defined categories of numbers that require paid call reception, such as marketing calls and advertising calls. Preset free call categories can refer to user-defined categories of numbers that do not require paid call reception, such as delivery calls and takeout calls. Preset paid list can refer to a user-defined list of specific numbers that require paid call reception, such as a paid list. Preset free list can refer to a user-defined list of specific numbers that do not require paid call reception, such as a free list.

[0141] The above paid call conditions can be set by default or by the user. It should be noted that the first to third conditions can be set and executed individually, or combined as long as they do not conflict logically. For example, the First Call application can provide checkboxes for number categories of unknown numbers in the paid call condition editing interface, stating that selected number categories will be paid for, while unselected number categories will not be paid for. These checkboxes list all number categories, for example, including "delivery calls," "marketing calls," "food delivery calls," "fraud calls," "official calls," and "uncategorized calls." If "marketing calls," "fraud calls," and "uncategorized calls" are selected, while "delivery calls," "food delivery calls," and "official calls" are unselected, then the paid call condition represented by the checkbox can be interpreted as paying for unknown numbers other than delivery calls, food delivery calls, and official calls, or it can be interpreted as paying for unknown numbers of marketing calls, fraud calls, and uncategorized calls. In this case, the second and third conditions can coexist. Furthermore, for marketing calls, etc., sub-checkboxes can be further triggered to allow for more detailed selection based on the marketing category. This will not be elaborated further here. The above examples should not be construed as limiting the scope of protection of this application.

[0142] It should be noted that the first to third conditions above are commonly used paid call receiving conditions. However, in practical applications, more complex paid call receiving conditions can be formed by combining them with custom number lists, number sources, effective time, paid call receiving indicators, membership levels, caller ID model recognition results, and charging standards, in order to meet users' more personalized setting needs.

[0143] It is easy to understand that, before executing the paid call process in the above steps where the calling number meets the conditions for paid call reception, a payment condition matching step may also be included. This payment condition matching step may include: detecting whether the calling number meets the conditions for paid call reception.

[0144] If the conditions are met, the paid call receiving process will be triggered.

[0145] Based on this, if the call does not meet the requirements, the normal call answering process is triggered. The normal call answering process refers to any call answering process other than the paid call answering process, such as directly triggering call reminders, directly blocking blacklisted numbers, using an AI assistant to answer the call, transferring the call to voicemail, etc. This application does not limit the scope of the implementation.

[0146] The step of detecting whether the calling number meets the conditions for paid call reception may include: determining the condition elements included in the conditions for paid call reception; obtaining the element attributes of the calling number corresponding to the determined condition elements; and determining whether the calling number meets the conditions for paid call reception based on the element attributes corresponding to the calling number.

[0147] Different conditional elements correspond to different element attributes. For example, regarding number familiarity, the element attribute can include contact numbers and unknown numbers, which can be determined by matching the caller's number with the contact list of the called terminal. Regarding number category, the element attribute can include marketing calls, food delivery calls, fraudulent calls, etc., which can be determined based on the caller's tagging information, registration information, and authentication information. For a custom number list, the element attribute can be a specific caller number. Regarding number source, the element attribute can include information such as the number's location. Regarding effective time, the element attribute can include information such as the time of the call. By determining the above element attributes of the caller's number, it can be further matched with the paid call receiving conditions to determine whether the caller's number meets the conditions for paid call receiving.

[0148] Considering that in practical applications, some callers are unwilling to pay to trigger call notifications on the called terminal, and that ringing immediately upon receiving a call would inevitably harass the called user, in some implementations, the paid call answering process further includes: keeping the incoming call silent in the foreground for the call request until payment confirmation information corresponding to the caller number is detected.

[0149] In this context, keeping incoming calls silent on the foreground means that when the called party's terminal detects an incoming call that meets the conditions for paid reception, it does not issue a call notification, nor does it play a ringtone or vibrate. This is to avoid disturbing the called party by issuing a call notification before confirming the caller's payment. The call notification is only triggered after the payment confirmation information corresponding to the caller's number is detected. This ensures that the called party is answering a call from someone willing to pay after receiving a call notification, thus avoiding interference from calls from people who are unwilling to pay.

[0150] Considering that in some cases, the called user may not answer the call promptly, if the call reminder is only triggered after payment confirmation, the caller may have to wait a long time after confirming payment before being answered. In other cases, the caller may not be willing to pay the answering fee, but the called user may be willing to answer the call because they are bored or know who is calling. If the call reminder cannot be triggered because the caller does not confirm payment, it is a loss for both the caller and the called user. In such cases, the called user needs to be informed of the incoming call information in advance before the call reminder. Therefore, in some modified implementations, the paid answering process also includes: triggering a pre-reminder call for the call request if the pre-reminder conditions are met.

[0151] The above pre-alert conditions can be flexibly set according to the actual application scenario. The pre-alert conditions can specifically include at least one of the following: the pre-alert function is currently enabled, the current scenario meets the preset pre-alert scenario, the calling number belongs to the pre-alert number category, the calling number belongs to the pre-alert number list, and the current time is within the pre-alert period.

[0152] The pre-reminder function is a service option that users can enable or disable. When this function is enabled, the pre-reminder function takes effect and can provide pre-reminders for call requests.

[0153] A pre-alert scenario refers to a set of conditions that automatically determine whether to trigger a pre-alert for incoming calls based on the current environment or usage status. These conditions can be set by the user. For example, the system can determine whether the current scenario meets the preset pre-alert scenario based on factors such as the device's location information, current application usage, and ambient noise level. If it does, the pre-alert for incoming calls can be triggered automatically.

[0154] The pre-alert number category refers to the category of numbers that can trigger pre-alert calls. For the definition and explanation of number categories, please refer to the aforementioned embodiments regarding number categories. The pre-alert number category can be set by default in the calling application or set and modified by the user; this application embodiment does not impose such limitations. By setting the pre-alert number category to determine whether an incoming call will trigger a pre-alert, the user's personalized setting needs can be fully met, achieving the goal of providing pre-alerts only for incoming calls from certain number categories.

[0155] A pre-alert list is a user-defined list of phone numbers that the user wants to receive automatic alerts when called. These numbers are typically from close contacts, work colleagues, or other priority communication recipients. By adding important contacts to the pre-alert list, users can respond quickly to calls from these numbers, ensuring they don't miss important conversations. This approach is convenient, fast, and respectful of user preferences.

[0156] A pre-reminder period refers to one or more time periods set by the user. During these periods, pre-reminders are automatically triggered for all incoming calls that meet certain criteria. For example, users can set pre-reminder periods during weekday office hours or evening rest periods to handle incoming calls more flexibly during these times. By configuring pre-reminder periods appropriately, users can receive and handle important calls promptly without disrupting their normal lives and work, thereby improving communication efficiency and personal satisfaction.

[0157] By introducing pre-reminder functions, pre-reminder scenarios, pre-reminder number categories, pre-reminder number lists, and pre-reminder time periods, a more intelligent and personalized communication management solution can be provided while protecting user rights. This ensures that every successful call meets the actual needs of both parties, improves the professionalism and reliability of the service, and enhances users' trust in paid call services.

[0158] For example, a pre-reminder function switch can be set in the first call application. If the called user turns on the pre-reminder function switch, the pre-reminder function will take effect, indicating that the pre-reminder function is currently enabled. At this time, it can be considered that the pre-reminder conditions are met, and the incoming call pre-reminder can be triggered. Alternatively, pre-reminder scenarios can be further set. For example, the incoming call pre-reminder can be executed when the called user's terminal screen is on. The on screen indicates that the user is using the terminal, and executing the pre-reminder in this case can achieve better results. Another example is that the incoming call pre-reminder can be set to be executed in scenarios other than when playing full-screen games. Since users often do not want to be disturbed when playing full-screen games, executing the incoming call pre-reminder in scenarios other than when playing full-screen games can effectively avoid the interference of pre-reminders to users. Those skilled in the art can set more pre-reminder scenarios for users to choose from according to actual needs, so as to meet users' needs for more free and personalized pre-reminder settings.

[0159] In addition, the aforementioned methods of pre-call reminders include, but are not limited to, ringing, vibration, and screen notifications. In this way, pre-call reminders and subsequent call reminders form a secondary reminder mechanism, which increases the probability that the called party will answer the call if the caller is willing to pay the answering fee.

[0160] In addition, for situations where the called party is willing to answer the call for free because they are bored or know who is calling, the call can be answered directly based on the caller ID reminder without waiting for the caller to pay the answering fee. Accordingly, after the caller ID reminder is triggered, the method may also include: answering the call based on the caller's input of a direct answer operation in response to the caller ID reminder.

[0161] The direct answering operation includes a first operation on the first control in the call pre-notification interface, which triggers the answering of the incoming call. The call pre-notification interface is an interface displayed to the user in advance before the formal call notification. It can be a prompt interface displayed on the called terminal when the call pre-notification is triggered, used to provide the user with an earlier call notification.

[0162] Through this implementation method, incoming call pre-reminders can not only remind the called user of a new incoming call, but also provide an answering option for the called user to choose whether they are willing to answer the call for free. If the called user enters the direct answering action in response to the incoming call pre-reminder, the call can be connected directly, thereby eliminating the caller's payment step.

[0163] In cases where the called party is busy or unable to answer the call for other reasons, the caller does not need to continue paying, because even if they pay, the called party will not answer. Therefore, the call can be rejected directly based on the call pre-reminder without waiting for the caller to pay the answering fee. Accordingly, after the call pre-reminder is triggered, the method may also include: rejecting the call based on the rejection operation input by the called party in response to the call pre-reminder.

[0164] The call rejection operation includes a second operation on the second control in the incoming call pre-reminder interface, which is used to trigger the rejection of the incoming call.

[0165] Through this implementation method, the incoming call pre-reminder can also provide a rejection option, allowing the called user to choose whether to directly reject the call. If the called user enters a rejection operation for the incoming call pre-reminder, the call can be rejected directly. On the one hand, this can save the caller from paying the fee, and on the other hand, it will not trigger the incoming call reminder again and cause subsequent disturbance to the called user.

[0166] In addition to directly answering and directly rejecting calls as described above, the paid call answering process needs to continue, waiting for the caller to pay the answering fee before triggering the call reminder. Correspondingly, after triggering the call reminder, the method may also include: based on the called user's input of a waiting-for-payment operation in response to the call reminder or detecting no operation within a preset time, closing the call reminder and continuing the paid call answering process, wherein the waiting-for-payment operation includes a third operation on a third control in the call reminder interface, the third operation being used to trigger the waiting-for-payment operation.

[0167] The continued paid call answering process includes the content and steps of the paid call answering process provided in this application, such as keeping incoming calls silent in the foreground and performing paid information exchange steps.

[0168] Through this implementation method, the incoming call reminder can also provide a pay-as-you-go option, allowing the called user to choose whether to wait for the caller to pay the answering fee before triggering the incoming call reminder to answer the call. If the called user enters the pay-as-you-go option for the incoming call reminder, the incoming call reminder can be turned off directly and the paid answering process can continue, thereby charging for harassing calls before answering the call.

[0169] Furthermore, if no operation is detected within a preset time, i.e. no operation is performed on the incoming call pre-reminder input, the incoming call pre-reminder will be automatically turned off and the paid call answering process will continue, such as continuing to execute the paid call answering prompt steps. The preset time can be 3 seconds, 5 seconds, 10 seconds, etc., and those skilled in the art can flexibly set it according to actual needs. This application embodiment does not limit it. Its value is intended to play a pre-reminder role without disturbing the user for too long, so it should be a relatively short time.

[0170] 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 operation, second operation, and third operation are respectively click operations or drag operations on the first control, second control, and third control. Or, the first control, second control, and third control can be the same slider, and the first operation, second operation, and third operation are respectively operations to drag the slider to different positions or directions. All of the above methods have the advantages of being simple and easy to operate. In addition, the direct answering operation is not limited to the first operation mentioned above, the rejecting operation is not limited to the second operation mentioned above, and the waiting for payment 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.

[0171] The above implementation significantly improves user experience, especially by providing more flexible and personalized services in different application scenarios. It not only simplifies the call setup process and improves communication efficiency but also enhances user satisfaction with the paid call mechanism. For example, a user receives a pre-call alert displaying, "You have a call from an unknown number from a renovation company. Please choose to answer for free, answer for a fee, or reject the call." If the user is preparing for renovations and is currently free, they can answer directly; if the user is busy with work or unable to answer the call, they can choose to reject it; if the user has no renovation needs but is currently free, they can choose to answer for a fee, waiting for the caller to pay before answering.

[0172] This application embodiment, by introducing an incoming call pre-reminder mechanism, can provide a more intelligent and personalized communication management solution while protecting user rights. This approach can improve the professionalism and reliability of paid call answering services, and provide users with a smoother and more undisturbed service experience.

[0173] It should be noted that the methods of pre-call reminders and regular call reminders can be the same or different, and this application does not limit this. It is worth noting that if the caller is unwilling to pay for the call, the pre-call reminder can, to some extent, interfere with the called party. Therefore, in practical applications, the pre-call reminder can be implemented with a lower reminder intensity than the regular call reminder. Reminder intensity refers to the effectiveness and strength of a reminder method in attracting the user's attention. Different reminder methods have different abilities to attract user attention; the strength of this ability is the reminder intensity. For example, both incoming call alerts and pre-call alerts use a ringing sound, but the ringing volume of the pre-call alert is lower than that of the incoming call alert. This reduces the alert strength of the pre-call alert. Similarly, if both incoming call alerts and pre-call alerts use vibration or screen notifications, the pre-call alert's alert strength is also lower. Furthermore, if both incoming and pre-call alerts use vibration, but the vibration duration of the pre-call alert is shorter than that of the incoming call alert, the pre-call alert's alert strength is also lower. By limiting the alert strength of pre-call alerts to be lower than that of the incoming call alert, the function of pre-call alerts can be achieved, ensuring that the called party is aware of an incoming call before the actual call, thereby increasing the probability of the call being answered and meeting the special needs of called parties to proactively answer calls from unpaid callers. This also largely avoids pre-call alerts causing annoyance to users.

[0174] Furthermore, in the embodiments of this application, the calling terminal can pay the fee immediately upon initiating the call, or upon prompting from 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 example embodiments, 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.

[0175] 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 the call reminder.

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

[0177] 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.

[0178] 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.

[0179] 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.

[0180] 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.

[0181] 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.

[0182] 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.

[0183] 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:

[0184] 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.

[0185] 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.

[0186] 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.

[0187] 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] 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.

[0192] 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.

[0193] 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 incoming call reminder is triggered and the called user's direct answering operation in response to the call request is detected, 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.

[0194] 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.

[0195] 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.

[0196] 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.

[0197] 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.

[0198] 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.

[0199] 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.

[0200] 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:

[0201] 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.

[0202] 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.

[0203] 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.

[0204] 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.

[0205] 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.

[0206] 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.

[0207] 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.

[0208] 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.

[0209] The third interactive response method involves the following: When a caller dials a number from a second calling application to a called party, 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 caller's number meets the paid call conditions set by the called party's terminal. In other words, it checks whether the caller's number requires a paid call for the called party, or whether the caller needs to pay a call fee to the called party. These three statements have the same meaning. If the conditions for a paid call are met, the second calling application uses its built-in interactive voice response system to directly broadcast a message on the caller's terminal and interacts with the caller based on the key inputs. 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 then initiated to the called party. Since payment has already been completed, the called party, upon receiving the call request and detecting that the caller's number meets the paid call conditions and has confirmed payment, can directly trigger a call notification. 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.

[0210] 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.

[0211] 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.

[0212] 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.

[0213] 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.

[0214] 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.

[0215] 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.

[0216] 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.

[0217] 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:

[0218] 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.

[0219] 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.

[0220] 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]".

[0221] 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."

[0222] 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.

[0223] 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.

[0224] 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.

[0225] 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.

[0226] 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.

[0227] 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.

[0228] 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 receives the receiving fee before triggering the call reminder. 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 call reminder first when the calling user promises to pay, and then making payment after the call ends. By moving the payment process to after the call ends, 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.

[0229] 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 call reminder can be triggered. Furthermore, any existing method for obtaining payment completion information can be used, which will not be elaborated here, as all are within the scope of this application. 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 call reminder. This method ensures that the called user receives payment before making a call, thereby protecting the called user's rights.

[0230] In the second scenario, the payment confirmation information can be a payment commitment message. This means the caller confirms 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 message can be transmitted in various ways, such as via keypad reply, in-app confirmation, or voice response. After receiving the payment commitment message, the called terminal can temporarily lift the call silence and trigger a call reminder. 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.

[0231] 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.

[0232] In some implementations, the called terminal can send payment timing option information to the calling terminal via 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:

[0233] 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 call notifications.

[0234] 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.

[0235] 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:

[0236] 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.

[0237] 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.

[0238] 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 calling user expressing their willingness to pay through voice response. For example, when sending payment timing options through a call link, the calling user can use voice response to indicate their willingness to pay the call fee after the call ends. The called terminal or server can use voice recognition to confirm the calling user's intention and generate a payment commitment. 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.

[0239] In some examples, after receiving a paid call notification, the calling terminal will play or display the notification. The calling user can reply to the notification. After receiving a payment agreement from the calling terminal, the called terminal will then send a payment timing option to the calling terminal. After the calling terminal plays or displays the payment timing option, the calling user can select the desired payment timing option and reply. If the calling user selects the postpaid option, a payment commitment will be generated on either the calling or called terminal. The called terminal can then trigger a call reminder based on the payment commitment.

[0240] 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.

[0241] 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:

[0242] 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.

[0243] The first time limit refers to a pre-set short time period during which the calling user needs to complete the payment. Failure to complete the payment within the first time limit is considered a breach of contract.

[0244] The second time limit refers to a pre-set longer time period. Failure to pay within this period is considered a serious breach of contract. The second time limit is longer than the first time limit.

[0245] The call charge reminder message is a notification sent to the caller to remind them to pay the call charge.

[0246] Dishonesty information refers to information that records a caller's failure to fulfill a payment commitment. It may include dishonesty markers used to mark the caller and / or the caller number as untrustworthy. The user and number marked as untrustworthy are referred to as dishonest user and dishonesty marker, respectively.

[0247] Call restriction refers to limiting subsequent calls from lost number numbers and / or untrustworthy users. For example, 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, or increasing the call charges required from the calling number. Call restrictions can be imposed on lost number numbers and untrustworthy users in at least one of the above ways.

[0248] For example, when a caller dials a number and selects the "pay after call" postpaid option, the called terminal will generate a payment commitment and trigger a call notification to allow the call. After the call ends, the system will begin monitoring the fulfillment of the payment commitment.

[0249] If, within the first time limit (e.g., 2 hours), it is detected that the promised payment information has not been fulfilled, meaning the caller has not completed the payment, the server of the called terminal or the first call application will automatically generate a call charge reminder message. This call charge reminder message can be sent to the calling terminal via SMS, email, or in-app notification. The content usually includes details of the call, the amount due, the payment method, and a link. The call charge reminder clearly informs the caller that the fee needs to be paid as soon as possible to avoid further default processing.

[0250] If the promised payment information is still not fulfilled within the second time limit (e.g., 24 hours), the first call application or server will generate a credit information record for the calling number. This credit information will be stored on the server and shared with other called terminals that are connected to the server. These called terminals can restrict incoming calls from the aforementioned calling number or calling user based on the credit information. Restriction measures may include directly rejecting the call, forwarding the call to voicemail, or displaying a warning message when answering the call to remind the called user that this is a credit information record.

[0251] 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.

[0252] It should be noted that the first and second time limits mentioned above can be flexibly set according to actual needs. Generally, the second time limit needs to be greater than the first time limit. This application does not limit its specific value.

[0253] In some modified implementations, before the payment condition matching step or the execution of the paid call receiving process, 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 step S102 or the payment condition matching step.

[0254] 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.

[0255] 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.

[0256] 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.

[0257] 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.

[0258] 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.

[0259] 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.

[0260] 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.

[0261] 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.

[0262] 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.

[0263] 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.

[0264] 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.

[0265] In the above scenarios, considering that fixed terminals are not convenient for installing a second calling application and making payments, and that the calling terminal cannot display in-app notifications if it does not have a second calling application installed, in some modified implementations, sending paid call notification information to the calling terminal corresponding to the calling number through a preset paid call notification method includes: determining a paid call notification method suitable for the calling terminal from a preset range of paid call notification methods based on the device information of the calling terminal, for example, determining at least one paid call notification method suitable for the calling terminal from the aforementioned multiple paid call notification methods; and sending the paid call notification information to the calling terminal according to the determined paid call notification method, so that the calling terminal can play or display the paid call notification information.

[0266] For example, in some specific cases, if the calling number meets the conditions for paid call reception, the device information of the calling terminal can be further detected. This device information refers to hardware and software characteristics related to the calling terminal, such as device type, operating system type, version number, and whether a specific application (such as a second-call application) is installed. This data helps the called terminal or the server understand the capabilities and limitations of the calling terminal, and thus intelligently selects the most suitable paid call reception prompt method based on this information. For example, for traditional communication devices like landlines, it can be identified that they lack intelligent operating systems, application installation capabilities, and online payment functions, requiring the first paid call reception prompt method to be selected. For modern mobile devices such as smartphones, more detailed attributes such as their operating system type (e.g., Android or iOS), version number, screen size, network connection status, and whether a specific application (such as a second-call application) is installed can be detected. If a second-call application is installed, both the first and third paid call reception prompt methods can be selected simultaneously.

[0267] It is easy to understand that before determining the appropriate paid call notification method for the calling terminal from the preset paid call notification methods based on the device information of the calling terminal, the process may further include: obtaining the device information of the calling terminal, wherein the device information includes at least one of the following: device type and installation status of the second call application.

[0268] The types of devices may include, but are not limited to, landline phones, mobile phones, virtual phones, etc., and the installation status of the second calling application may include installed or not installed.

[0269] Specifically, when a call request arrives, the called terminal can obtain basic information about the calling terminal from the telecom operator's network through signaling interaction. This typically includes preliminary clues such as the caller's number location and operator identification. Subsequently, if the calling terminal supports this, the called terminal can further attempt to establish a data connection with the calling terminal to obtain more in-depth device information. For smart devices that support Internet Protocol (IP) protocols, key parameters such as operating system version, browser type and version, and device model can be obtained through HTTP header fields, User-Agent strings, etc. Furthermore, in some cases, additional information may be collected using specially developed application programming interfaces (APIs) or pre-built server-side proxies, such as whether specific applications are installed or whether the device's geolocation service is enabled.

[0270] For landline phones and other non-smart devices, while complex device information cannot be directly obtained, the general characteristics of the terminal can still be inferred indirectly through methods such as caller ID ranges and device descriptions in registration information. For example, numbers with certain prefixes may correspond to the internal switching system of a large enterprise, while other numbers may be associated with ordinary landlines used in homes. This method, based on historical experience and database matching, can, to some extent, compensate for the insufficiency of directly obtaining device information.

[0271] Comprehensive and accurate collection of device information enables the call processing method provided in this application to better adapt to various calling terminal environments. It selects the most suitable paid call notification method for each call, not only improving the success rate of payment notification delivery but also enhancing the user experience. Users receive guidance tailored to their device, reducing confusion and operational difficulties caused by incompatibility. For example, when the calling terminal is a landline, a clear voice prompt can be played through an interactive voice response system, providing simple button confirmation options. For smart mobile devices equipped with large screens and touch interfaces, in-app notifications can be sent, displaying illustrated payment guides, or even integrating secure and convenient payment plugins. In short, detailed analysis of device information enables more personalized and efficient call processing services, ensuring that all types of calling terminals can smoothly participate in the paid call process.

[0272] Furthermore, in some modified implementations, the aforementioned payment guidance information sending step may include: selecting a payment guidance information sending method suitable for the calling terminal based on the device information of the calling terminal and sending payment guidance information to the calling terminal, so that the calling user can pay the call reception fee according to the payment guidance information.

[0273] Through this implementation method, the call processing method provided in this application embodiment can better adapt to various calling terminal environments based on comprehensive and accurate device information collection. It selects the most suitable payment guidance information sending method for each call, which not only improves the success rate of payment guidance information transmission, but also enhances the user experience, because the user will receive guidance that matches their device, reducing confusion and operational difficulties caused by incompatibility.

[0274] In addition, in some modified implementations, the aforementioned payment timing sending step may include: selecting a payment timing sending method suitable for the calling terminal based on the device information of the calling terminal and sending payment timing option information to the calling terminal, so that the calling user can select a payment timing based on the payment timing option information.

[0275] Through this implementation method, the call processing method provided in this application embodiment can better adapt to various calling terminal environments based on comprehensive and accurate device information collection, and select the most suitable payment timing sending method for each call. This not only improves the success rate of payment timing option information transmission, but also enhances the user experience, because the user will receive guidance that matches their device, reducing confusion and operational difficulties caused by incompatibility.

[0276] In some applications, the calling number can also be a virtual number. A virtual number is 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 applications, such as protecting privacy, temporary communication, or as an intermediary number to mask the real contact information of both parties. The calling terminal corresponding to a 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 equipment. 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.

[0277] For scenarios involving virtual number callers, the implementation can be carried out with reference to the aforementioned embodiments that select appropriate paid call notification methods and / or payment guidance information sending methods based on the device information of the calling terminal. These will not be repeated here. Based on this, further implementation can be carried out using paid call notification methods, payment guidance information sending methods, and payment timing sending methods suitable for virtual number caller scenarios. For example, for virtual numbers dialed through smart devices, existing in-app notifications or IVR voice prompts can continue to be used. However, for virtual calls dialed from traditional landlines that do not support applications or network connections, if they access the virtual number service through a gateway, it must be ensured that the selected payment information interaction method can work normally on such terminals. For example, using IVR to play clear voice instructions to traditional landlines, informing the caller how to complete the payment. Furthermore, for cases where the caller initiates a call using a virtual number, a payment device can be used to pay the call fee on their behalf, which also achieves the purpose of this invention and should be within the scope of protection of this application.

[0278] 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:

[0279] 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.

[0280] 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.

[0281] 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.

[0282] 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.

[0283] 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.

[0284] 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.

[0285] The above-mentioned automatic payment option sending step may include: sending automatic payment option information to the calling terminal corresponding to the calling number through at least one of the following automatic payment option sending methods, wherein the automatic payment option information is used for the calling user to choose whether to use the automatic payment mechanism to pay the incoming call fee:

[0286] The first method of sending the automatic payment option is through a call link to the calling terminal. In this method, the calling terminal can announce the automatic payment option via voice, and the calling user can reply via voice whether to use the automatic payment mechanism to pay the call fee. The second method is through an interactive voice response system to send the automatic payment option to the calling terminal. In this method, the calling terminal can announce the automatic payment option via voice, and the calling user can reply via button to whether to use the automatic payment mechanism to pay the call fee. The third method is through in-app notification to send the automatic payment option to the calling terminal. In this method, the calling terminal can display the automatic payment option within the second call application, and the calling user can select whether to use the automatic payment mechanism to pay the call fee using the selection controls on the displayed interface. The fourth method is through SMS to send the automatic payment option to the calling terminal. In this method, the calling terminal can display a link corresponding to the automatic payment option in the SMS, and the calling user can click the link to indicate whether to use the automatic payment mechanism to pay the call fee.

[0287] In practical implementation, the above automatic payment option sending methods 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 automatic payment option sending method is adopted accordingly. 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 automatic payment option sending method is adopted accordingly. 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 automatic payment option sending method is adopted accordingly. For detailed implementation methods and advantages / disadvantages analysis of the above-mentioned multiple automatic payment option sending methods, please refer to the aforementioned corresponding descriptions of multiple paid call notification methods; they will not be repeated here.

[0288] Building upon the above, the calling user can trigger the automatic payment instruction through methods such as key press reply, in-app confirmation, or voice response. Key press reply refers to the calling user triggering the automatic payment instruction by pressing a designated key on their terminal. This method can respond to various automatic payment options mentioned above, making it a simple, convenient, and highly versatile response 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 the automatic payment option information, the second calling application will display a selection interface on the calling terminal's screen, prompting the user to choose the automatic payment mechanism to pay for the incoming call. The calling user can then select the automatic payment option using the selection controls, and the second calling application will generate an automatic payment agreement instruction and send it to the called terminal or the server. The advantage of this method is 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, thereby simplifying the payment process. Voice response refers to the calling user expressing their willingness to pay through voice response. For example, when sending automatic payment option information through a call link, the calling user can reply with voice to indicate their willingness to pay the call fee using the automatic payment mechanism. The called terminal or server can confirm the calling user's intention through voice recognition and generate an instruction to agree to automatic payment. 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.

[0289] When a caller chooses to use the automatic payment mechanism to pay for incoming calls, the calling terminal can send an automatic payment consent instruction to the called terminal or server. The called terminal or server can then trigger the automatic payment operation based on this instruction. The advantage of having the called terminal or server trigger the automatic payment operation is that it places lower demands on the calling terminal's equipment. This way, regardless of whether the calling number is a landline, virtual phone number, or a number requiring payment on behalf of another, the automatic payment mechanism can be triggered with a simple reply. For example, for the first and second automatic payment option sending methods mentioned above, the calling user can achieve automatic payment through a simple voice or keypad reply. For the third automatic payment option sending method, the calling user can also achieve automatic payment through a simple control selection operation. The low difficulty of operation for the calling user helps improve the smoothness of incoming call payment and enhances the user experience.

[0290] It should be noted that, regarding the third automatic payment option sending method mentioned above, since the calling terminal also has a second call application installed, when the calling user selects to use the automatic payment mechanism to pay the incoming call fee through the selection control, they do not need to return an automatic payment consent instruction to the called terminal. Instead, they can directly return an automatic payment consent instruction to the server, so that the automatic payment operation can be triggered directly through the server. This process is simpler and more efficient.

[0291] 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.

[0292] 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:

[0293] 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.

[0294] 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.

[0295] 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.

[0296] 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.

[0297] The call protection reminder message is used to remind the called user that the call duration must exceed the call protection time. It can be played by voice or displayed on the screen. It can be played or displayed immediately after the called user answers the call, or after the called user enters the first hang-up trigger operation, so as to remind the called user in time when they try to hang up.

[0298] The hang-up control is an interface element that allows the called user to input the hang-up trigger operation. It can be redisplayed after the call duration exceeds the protection time, allowing normal hang-up operations.

[0299] 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.

[0300] For example, suppose a called user answers an unknown call that meets the conditions for paid answering. After the caller pays the answering fee, the called user's terminal sends a call notification. Once the call is connected, the called user's terminal displays a call protection message to remind them that they need to listen for a sufficient duration to receive the answering fee. The call duration progress is also displayed on the call interface, indicating that the current call has lasted 0 minutes and updating in real time. The call protection period is 1 minute. If the called user attempts to hang up after 10 seconds, the called user's terminal will not hang up immediately but will maintain the call and display the call protection message again, informing them that they need to continue the call until it exceeds 1 minute. If the called user attempts to hang up again, they will be allowed to hang up, but an automatic refund process will be executed. Although this results in a loss of answering fees for the called user, it satisfies the called user's need to hang up at any time and avoids the dissatisfaction caused by forced answering of calls. In addition, in some feasible implementations, the hang-up control will be hidden during this 1 minute and will only be displayed again after the call duration exceeds 1 minute, allowing normal hang-up operations. This approach not only ensures the rights of the calling user but also provides a more reasonable and transparent call management mechanism.

[0301] 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.

[0302] 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.

[0303] In some modified implementations, 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:

[0304] 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.

[0305] 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.

[0306] The call duration protection fee is an additional charge paid by the caller when paying the call reception fee. This fee ensures the call meets a preset minimum duration requirement. It's typically part of the call reception fee, which may include a base fee and an additional fee. The base fee is necessary to trigger call reminders, while the additional fee covers 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 reception fee that includes this protection, the call duration protection process will automatically begin 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.

[0307] 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.

[0308] 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.

[0309] 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.

[0310] 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.

[0311] 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.

[0312] 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.

[0313] 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.

[0314] 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.

[0315] 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.

[0316] 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.

[0317] 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.

[0318] 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.

[0319] 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.

[0320] 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.

[0321] 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.

[0322] In some examples, the calling user pays the call reception fee to the server (such as a payment platform). The server then generates a payment confirmation message and sends it to the called terminal. The called terminal triggers a call reminder based on the payment confirmation message. After the call ends, if the call duration exceeds the call 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 protection period, a refund process will be executed, and the call reception fee will be fully or partially refunded to the calling user.

[0323] 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.

[0324] 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.

[0325] 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.

[0326] 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.

[0327] In addition, after the manual refund operation is triggered, users can be guided to complete the necessary information input, such as the reason for the refund. This provides users with an intuitive and convenient refund entry point by using the manual refund trigger element, enabling users to actively initiate a refund request according to their needs. The existence of the manual refund trigger element not only enhances the user's autonomy, but also ensures that users can quickly and effectively apply for a refund when needed.

[0328] 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.

[0329] 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.

[0330] 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.

[0331] 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.

[0332] 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.

[0333] 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.

[0334] In some modified embodiments of this application, the method may further include: displaying additional call information and / or call intent about the caller number on the caller ID interface and / or call pre-reminder interface, wherein the additional call information includes the caller's identity information and / or call description information for this call.

[0335] 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 application embodiment. The called terminal can directly display the aforementioned caller ID information, or it can first identify the caller's intent based on the aforementioned 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, thereby helping the called user quickly understand the caller's identity or purpose when viewing the call notification, and thus decide on an answering strategy.

[0336] The caller's identity information can be transmitted to the called terminal via an electronic business card. This means the aforementioned call-related 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 call notification interface is a prompt displayed on the called terminal when a call notification is triggered, notifying the user of an incoming call. The pre-call notification interface is an interface displayed to the user before the official call notification. It can be a prompt displayed on the called terminal when a pre-call notification is triggered, providing the user with earlier notification of an incoming call.

[0337] For example, with each incoming call, the called terminal can also receive additional call information sent by the calling terminal or the server. This additional information may include the caller's identity information (such as name, job title, company) and / or call details (such as call purpose, scheduled time). This information is then displayed on the call notification screen and / or the call pre-notification screen. For instance, the call notification screen, in addition to displaying the caller's number, can also show the caller's name, company name, and profile picture, as well as a brief description of the call. If a call pre-notification screen exists, this information can also be displayed in advance, giving the user more time to prepare for the call.

[0338] 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.

[0339] The aforementioned call intent can be identified based on additional call information, analyzed using a pre-defined call intent recognition model, or analyzed using social graphs. For details, please refer to the relevant descriptions of call intent recognition in the preceding 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.

[0340] This implementation significantly enhances the functionality and transparency of call reminders. By displaying additional information about the caller's number or the caller's intent on the call reminder interface and / or pre-call reminder interface, called users 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 decisions and facilitating more informed decision-making. It also 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.

[0341] 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.

[0342] 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 embodiment can also record business information related to the current call (such as the purpose of the call, appointment details, etc.). When a user adds a caller ID as a contact, the called terminal can automatically detect and obtain the electronic business card corresponding to that 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 retrieved in real-time. For example, when a calling user initiates a call to a called user, they can simultaneously choose to send their electronic business card to the called user. In this way, the called terminal can receive and display the calling user's electronic business card upon receiving the call request, helping the called user determine whether to answer the call based on the electronic business card.

[0343] 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.

[0344] 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.

[0345] In some application scenarios, the called terminal can be a device that supports multiple SIM (Subscriber Identity Module) cards, such as a dual-SIM device. A dual-SIM device is a mobile device with two built-in SIM card slots, allowing users to insert two different SIM cards at the same time, thereby managing two independent phone numbers and data connections on the same mobile phone. In this case, the same paid call conditions can be set for different phone numbers of the called terminal, or different paid call conditions can be set for phone numbers corresponding to different SIM cards. The incoming call is processed differently based on the called number. In the above-mentioned call processing method, in addition to obtaining the calling number, the called number requested by the call request can also be determined. The paid call conditions corresponding to the called number are used to determine whether the calling number meets the paid call conditions. If the paid call conditions are met, the paid call process is executed. Therefore, in the above-mentioned embodiments regarding paid call conditions, the paid call conditions can all refer to the paid call conditions corresponding to the called number. The call processing methods and their paid call processes, settings and specific steps described in the above embodiments can also be applied to the called number. They will not be described in detail here, and they should also be within the protection scope of this application.

[0346] 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 a paid call answering process can be implemented for other types of unknown calls. 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 implemented to ensure that only calls from those willing to pay will trigger call reminders on the called terminal. In addition, it can determine whether to directly block or execute a paid call process based on the number of times a phone number is marked. For example, if the number of markings is less than a preset threshold, the paid call process is executed; if the number of markings is greater than the preset threshold, the incoming 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 himself. This application embodiment does not limit this.

[0347] 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.

[0348] 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.

[0349] In some implementations, the aforementioned number category can be determined based on number classification information, which can be determined based on at least one of number tagging information, number registration information, and number authentication information. Number tagging information refers to information used by third-party service providers or users to tag numbers; this tagging information can include courier phone numbers, sales phone numbers, fraudulent phone numbers, etc. Number registration information can refer to the identity information selected by the number holder during registration on the service platform corresponding to the First Calling application, or the identity information selected for the number on that service platform. The same user can register different identity information for different numbers they own, or they can register the same identity information. For example, if a courier has two phone numbers, they can register their phone number A (used for deliveries) as a courier phone number, and their personal phone number B as a personal phone number, or not register any identity information at all. Number authentication information can refer to the identity information determined by the number holder after authenticating the number on the service platform corresponding to the First Calling application. Unlike number registration information, number authentication information requires the number holder to provide necessary identity verification materials for successful authentication. Therefore, number authentication information has higher authenticity and reliability than identity registration information, helping to more accurately determine the number category.

[0350] The first call application and server (such as the service platform or server corresponding to the first call application) can determine the number classification information of a phone number (such as a calling number) based on at least one of the above number tagging information, number registration information, and number authentication information. For example, if the number tagging information of a phone number is a fraudulent call, then its number classification information can be determined as a fraudulent call; if the number authentication information of a phone number is a delivery call, then its number classification information can be determined as a delivery call; if the number tagging information, number registration information, and number authentication information of a phone number are all empty, that is, there is no corresponding number tagging information, number registration information, and number authentication information, then its number classification information can be determined as an unclassified phone number, thereby realizing the classification of phone numbers.

[0351] Considering that the number tagging information, number registration information, and number authentication information corresponding to the same phone number may be different, thus causing confusion in phone number classification, some embodiments of this application can also set different priorities for number tagging information, number registration information, and number authentication information according to a preset number classification strategy. Then, the number classification information of the phone number (e.g., the calling number) is determined based on the above-mentioned number tagging information, number registration information, and number authentication information. Among them, number authentication information has the highest priority, followed by number tagging information, and lastly number registration information. When there are multiple different pieces of information for the same phone number, the information with the highest priority is used for classification. For example, if the number authentication information of a phone number is a courier phone number, even if its number tagging information is a marketing phone number, it is still classified as a courier phone number; as another example, if the number registration information of a phone number is a courier phone number, but its number tagging information is a fraud phone number and its number authentication information is empty, it is classified as a fraud phone number.

[0352] Furthermore, the aforementioned priorities can also be customized by the user. For example, users can customize the priority of each information source in the paid call conditions editing interface. For instance, users can select number tagging information as having the highest priority to ensure that the system prioritizes number tagging information from third-party service providers or users. This customizable priority setting can meet users' personalized needs and improve the system's flexibility.

[0353] By employing the aforementioned number classification strategy, phone numbers can be categorized more accurately, thereby helping users manage incoming calls more precisely, ensuring that important calls are answered smoothly, and reducing unnecessary nuisance calls.

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

[0355] 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 reminder. If the caller is unwilling to pay, the caller ID will not be triggered. Since some harassing callers are usually unwilling to pay extra fees, the caller ID will not be triggered for callers who do not agree to pay. This can effectively reduce the number of harassing call reminders 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.

[0356] 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 call alerts, 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.

[0357] 3. Improved flexibility in call handling: This application's solution offers greater flexibility in blocking nuisance calls. It does not simply block calls based on number marking information. Even if a number is marked as a nuisance call, it can still complete the call if the caller is willing to pay and meets the caller's paid call conditions. This avoids important calls being mistakenly blocked and ensures that users do not miss truly important calls.

[0358] 4. Enhanced User Control: This application allows users to set personalized paid call conditions according to their needs, such as paid call receiving for specific types of unknown numbers or numbers in a specific list, as well as setting compensation fees. This flexible setting method enables users to better control the call environment, reduce unnecessary interference, and obtain more suitable f...

Claims

A call processing method, characterized in that, The method comprises: In the case of detecting a call request, obtaining a calling number; Performing a paid call answering process for the calling number, the paid call answering process comprising triggering a call reminder after detecting payment confirmation information corresponding to the calling number. The method of claim 1, wherein The paid call answering process for the calling number comprises any one of the following: In the case where the calling number meets a paid call answering condition, performing a paid call answering process; In the case where the calling number is a stranger number, performing a paid call answering process; In the case where the calling number is identified by a preset call number identification model as needing a paid call answering, performing a paid call answering process; In the case where a call intent corresponding to the calling number belongs to a paid call answering intent, performing a paid call answering process; In the case where the calling number meets a paid call answering condition and a call intent corresponding to the calling number belongs to a paid call answering intent, performing a paid answering process. The method according to claim 2, characterized in that The paid call answering process in the case where the calling number meets a paid call answering condition and a call intent corresponding to the number belongs to a paid call answering intent comprises: In the case where the calling number meets a paid call answering condition, performing a call intent identification step; In the case where the identified call intent belongs to a paid call answering intent, performing a paid call answering process. The method according to claim 3, characterized in that The call intent identification step comprises: Receiving call additional information sent by a calling terminal, the call additional information comprising identity information of a calling user and / or call description information; Identifying a call intent of the calling user according to the call additional information. The method according to claim 2, characterized in that The paid call answering condition comprises at least one of the following: The calling number is a stranger number; The number category of the calling number belongs to a preset number category needing a paid call answering; The calling number is within a preset custom number list; The number source of the calling number belongs to a preset number source needing a paid call answering; The calling number corresponds to a paid call answering identifier; The member level corresponding to the calling number belongs to a preset member level needing a paid call answering; The call time of the calling number belongs to a preset paid call answering period needing a paid call answering; The calling number is identified by a preset call number identification model as needing a paid call answering. The method according to claim 2, characterized in that The paid call answering condition is determined according to condition elements of at least one of the following dimensions: number familiarity, number category, custom number list, number source, paid call answering identifier, member level, call number identification model identification result, effective time, and charging standard. The method according to claim 2, characterized in that The method further comprises: In response to a setting trigger operation, displaying a paid call answering condition editing interface, the paid call answering condition editing interface being provided with editable elements corresponding to condition elements of at least one of the following dimensions: number familiarity, number category, custom call number list, number source, paid call answering identifier, member level, call number identification model identification results, effective time, and call number identification model identification results; Determining a paid call answering condition according to an editing operation of the called user on the editable elements. The method of claim 7, wherein The method further comprises: In the paid call answering condition editing interface or the charging standard setting interface, displaying a charging standard editing element; According to the editing operation of the called user on the charging standard editing element, the charging standard is determined. The method of claim 1, wherein The paid answering process further includes: For the call request, the incoming call is kept silent in the foreground until the payment confirmation information corresponding to the calling number is detected. The method of claim 1, wherein The paid answering process further includes: For the call request, the incoming call pre-alert is triggered when it is detected that the current situation meets the pre-alert condition. The method of claim 10, wherein The alert intensity of the incoming call pre-alert is less than that of the incoming call alert. The method of claim 10, wherein The current pre-alert condition includes at least one of the following: the pre-alert function is currently turned on, the current situation meets the pre-set pre-alert scenario, the calling number belongs to the pre-alert number category, the calling number belongs to the pre-alert number list, and the current time is within the pre-alert time period. The method of claim 11, wherein After triggering the incoming call pre-alert, the method further includes at least one of the following: According to the direct answering operation input by the called user for the incoming call pre-alert, the current incoming call is connected; According to the rejection operation input by the called user for the incoming call pre-alert, the current incoming call is rejected; According to the payment waiting operation input by the called user for the incoming call pre-alert or the detection of no operation within a pre-set time, the incoming call pre-alert is closed and the paid answering process is continued. The method of claim 1, wherein The paid answering process further includes a payment information interaction step, which includes: According to a pre-set payment information interaction mode, payment interaction information is sent to the calling terminal corresponding to the calling number, the payment interaction information including at least one of the following: paid answering prompt information, payment guidance information, payment opportunity option information, and automatic payment option information. The method of claim 14, wherein The payment information interaction mode includes at least one of the following: In the case of connecting the incoming call in the background, the payment interaction information is sent to the calling terminal through the call link; The payment interaction information is sent to the calling terminal through the interactive voice response system; The payment interaction information is sent to the calling terminal through the application notification; The payment interaction information is sent to the calling terminal through the short message. The method of claim 15, wherein The payment interaction information is sent to the calling terminal through the interactive voice response system, including: The payment interaction information is sent to the calling terminal through the built-in interactive voice response system; The built-in interactive voice response system is realized by the first call application installed on the called terminal and the second call application installed on the calling terminal, the first call application sending the payment interaction information to the second call application through the call link or the Internet link, and the second call application sending the response information to the payment interaction information to the first call application through the Internet link. The method of claim 14, wherein According to the pre-set payment information interaction mode, the payment interaction information is sent to the calling terminal corresponding to the calling number, including: According to the device information of the calling terminal, the payment information interaction mode suitable for sending the current payment interaction information to be sent to the calling terminal is selected from the pre-set payment information interaction mode; The payment interaction information is sent to the calling terminal according to the determined payment information interaction mode. The method of claim 1, wherein The payment confirmation information includes payment completion information or promised payment information; The payment completion information indicates that the call charge for the calling number has been paid. The commitment payment information indicates that the calling user commits to pay the call charge for the current call. The method of claim 18, wherein The payment confirmation information includes payment completion information, which is generated according to the payment behavior of the calling terminal, the payment device or the server. The method of claim 18, wherein The payment confirmation information includes commitment payment information; correspondingly, the method further includes: After the call ends, performing a breach handling step according to the commitment payment information, the breach handling step including at least one of the following: In the case where it is detected that the commitment payment information is not fulfilled within a first time limit, sending a call charge recovery prompt information to the calling terminal, the call charge recovery prompt information being used to prompt the calling user to pay the call charge for the current call; In the case where it is detected that the commitment payment information is not fulfilled within a second time limit, sending a bad faith information for the calling number to the server, the bad faith information being used for the other called terminals in communication connection with the server to limit the call of the calling number. The method of claim 1, wherein The payment confirmation information includes confirmation information of the calling user paying the call charge to the called user, the call charge being determined according to a pre-set charging standard of the called terminal, the charging standard being determined according to a hierarchical charging mode, the hierarchical charging mode classifying the charging standard from at least one of the following dimensions: number familiarity, number category, self-defined number list, number source, paid call identification, member level, incoming call number identification model identification result, effective time. The method of claim 1, wherein Before executing the paid call process, further including: Detecting whether the calling number is a bad faith number; In the case where it is detected that the calling number is a bad faith number, limiting the call of the calling number; The call limitation is implemented in at least one of the following call limitation modes: rejecting the current incoming call of the calling number, canceling the postpaid payment authority of the calling number, limiting the calling user to continue calling after paying the historical unpaid call charge, increasing the call charge to be paid by the calling number. The method of claim 1, wherein The paid call process further includes an automatic payment step; the automatic payment step includes: Querying whether the calling number meets the automatic payment condition through the server; In the case where the calling number meets the automatic payment condition, triggering an automatic payment operation, the automatic payment operation including automatically paying the call charge based on the payment account bound to the calling number. The method of claim 1, wherein The method further includes: After the incoming call is connected, executing a call duration protection process, the call duration protection process including protecting the current call by a pre-set call duration protection mode, the call duration protection mode including at least one of the following: Playing or displaying a call protection prompt information, the call protection prompt information including prompt information prompting the call duration to be greater than a call protection duration; Displaying a call duration progress information on the call interface of the called terminal, the call duration progress information including current call timing information and a call protection duration identifier; In the call answering protection duration, in response to a first hang-up trigger operation input by the called user, a call state is maintained and a call answering protection prompt information is displayed; In the call answering protection duration, in response to a second hang-up trigger operation input by the called user, the current call is hung up; In the call answering protection duration, a hang-up control is hidden, and after the call answering duration exceeds the call answering protection duration, the hang-up control is displayed, the hang-up control being used for the called user to input a hang-up trigger operation. The method of claim 24, wherein The call answering duration protection procedure is executed after the incoming call is connected, and the call answering duration protection procedure comprises the following steps: In the case that the calling number meets the call answering duration protection condition, the call answering duration protection procedure is executed after the incoming call is connected; wherein the call answering duration protection condition comprises at least one of the following: The payment confirmation information corresponding to the calling number is payment completion information, and the paid call answering fee includes the call answering duration protection fee; The number category of the calling number belongs to a preset number category supporting the call answering duration protection; The member level corresponding to the calling number belongs to a preset member level supporting the call answering duration protection; The calling number has opened the call answering duration protection permission. The method of claim 1, wherein The method further comprises: In the case that the refund trigger condition is met, a refund processing procedure is triggered to be executed, the refund processing procedure comprising refunding the call answering fee paid by the calling user in full or in part; The refund trigger condition comprises 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 a preset call answering protection duration, and a manual refund operation input by the called user is detected. The method of claim 26, wherein The method further comprises: After the call is ended, a call ended interface is displayed, and a manual refund trigger element is displayed on the call ended interface; In response to a manual refund operation input by the called user based on the manual refund trigger element, it is determined that the refund trigger condition is met. The method of claim 26, wherein The refund processing procedure comprises: According to the refund amount input by the called user, the call answering fee paid by the calling user is refunded. The method according to any one of claims 1 to 28, characterized in that The method further comprises: In the incoming call reminding interface and / or the incoming call pre-reminding interface, incoming call additional information and / or incoming call intention about the calling number are displayed, the incoming call additional information comprising identity information of the calling user and / or incoming call description information for the current incoming call. The method according to any one of claims 1 to 28, characterized in that The method further comprises: In response to a contact adding operation for the calling number, an electronic business card corresponding to the calling number is obtained; According to the identity information recorded in the electronic business card, the calling user is added as a contact. The method according to any one of claims 1 to 28, characterized in that The method further comprises: In a contact editing interface in which the calling number is added as a contact, a paid call answering identifier setting option is displayed; According to a selection operation of the called user on the paid call answering identifier setting option, a paid call answering identifier for the calling number is set, the paid call answering identifier being used to mark that the calling number meets a paid call answering condition. A call processing method, characterized in that, The method further comprises: In the case that a call from a stranger number is detected, the incoming call is connected in the background and a preset voice is used to inquire whether the calling user agrees to pay the call answering fee; After receiving agreement payment information indicating that the calling user agrees to pay the call answering fee, payment guide information is sent to the calling terminal, the payment guide information being used to guide the calling user to pay the call answering fee; trigger a call reminding for the stranger number after detecting payment completion of the call charge. A call processing method, characterized in that, The method comprises: performing a call intention identification step in case of detecting a call request; performing a paid call process in case that the identified call intention belongs to a paid call intention, the paid call process comprising triggering a call reminding after detecting payment confirmation information corresponding to the calling number, the paid call intention being a call intention that triggers a call reminding of the called terminal after the calling user pays the call charge. The method of claim 33, wherein The call intention identification step comprises: receiving call additional information sent by the calling terminal, the call additional information comprising identity information of the calling user and / or call description information; identifying the call intention of the calling user according to the call additional information. A call processing method, characterized by, The method comprises: sending a call request to a called number; playing or displaying paid call prompt information sent by the called terminal for the call request; performing payment confirmation according to the paid call prompt information, so that the called terminal triggers a call reminding according to payment confirmation information. A call processing method, characterized by, The method comprises: determining a called number to be called; displaying a payment confirmation element in case that the called number needs to be called for payment; sending a call request to the called number after detecting that the calling user performs a payment confirmation operation based on the payment confirmation element. The call processing method according to claim 36, wherein The method further comprises: inquiring, from the called terminal or a server, whether the calling number meets a paid call condition of the called number; determining that the called number needs to be called for payment in case that the calling number meets the paid call condition of the called number. An incoming call processing apparatus characterized by comprising: The method comprises: a calling number obtaining module configured to obtain a calling number in case of detecting a call request; a paid call performing module configured to perform a paid call process for the calling number, the paid call process comprising triggering a call reminding after detecting payment confirmation information corresponding to the calling. An incoming call processing apparatus characterized by comprising: The method comprises: a voice interaction module configured to, in case of detecting a call from a stranger number, connect the call in the background and ask the calling user whether to agree to pay a call charge to remind a called user to answer the call according to a preset voice; a payment guidance module configured to, after receiving agreement payment information indicating that the calling user agrees to pay the call charge, send payment guidance information to the calling terminal, the payment guidance information being used to guide the calling user to pay the call charge; a call reminding module configured to trigger a call reminding for the stranger number after detecting payment completion of the call charge. An incoming call processing apparatus characterized by comprising: The method comprises a call intention determining module configured to perform a call intention identification step in case of detecting a call request; a call intention triggering module configured to perform a paid call process in case that the identified call intention belongs to a paid call intention, the called process comprising triggering a call reminding after detecting payment confirmation information corresponding to the calling number, the paid intention being a call intention that triggers a call reminding of the called terminal after the calling user pays a call charge. A call processing apparatus characterized by comprising: The method comprises a call request sending module configured to send a call request to a called number; a paid call information providing module configured to play or display paid call prompt information sent by the called terminal for the call request; The payment confirmation module is configured to perform payment confirmation according to the paid prompt information, so that the called terminal triggers the incoming call reminder according to the payment confirmation information. A call processing apparatus characterized by comprising: The method comprises: A called number determination module is configured to determine a called number to be called. A payment element display module is configured to display a payment confirmation element when the called number needs to be paid for listening. A call initiation module is configured to send a call request to the called number after detecting that the calling user performs a payment confirmation operation based on the payment confirmation element. An electronic device, comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to implement the method of any one of claims 1-37. A computer-readable storage medium, characterized by A computer readable medium having stored thereon computer readable instructions executable by a processor to implement the method of any one of claims 1-37. A computer program product, characterized in that The computer program product comprises computer programs or instructions for executing the method of any one of claims 1 to 37.

Images