Communication card management method and device, equipment, storage medium and product

Abstract

The embodiment of the invention provides a communication card management method and device, equipment, a storage medium and a product. The method comprises the following steps: receiving a cost merging request submitted by a user, and determining multiple types of communication cards for which the user applies for bill merging; determining the payment compliance rate of the user according to the historical payment record of each communication card; under the condition that the payment compliance rate is greater than a target compliance rate threshold value, obtaining the bills to be paid of the communication cards, and combining the bills to be paid to obtain a combined bill; and the combined bill is paid. According to the embodiment of the invention, the risk controllability of cost merging is guaranteed, the adaptability of service objects is also ensured, the barrier that different types of communication cards belong to different service platforms is broken, the unified management of the cost of multiple different types of communication cards held by the same user is realized, the multi-card management burden of the user is also obviously reduced, and the user experience is improved. The operation complexity is greatly reduced, the multi-card management efficiency and the user experience are effectively improved, and the operation cost is reduced at the same time.

Description

Technical Field

[0001] This application belongs to the field of Internet of Things (IoT) technology, and in particular relates to a method, apparatus, device, storage medium, and product for managing communication cards. Background Technology

[0002] With the booming development of the Internet of Things (IoT) business and the deep integration of smart devices with daily life, users generally face the complex need to operate and maintain multiple different types of communication cards (such as IoT cards and SIM cards) simultaneously. This situation not only increases the management burden on users, but also forces them to shuttle between IoT card service platforms and SIM card service platforms to perform cumbersome and isolated payment and management operations, which greatly reduces user experience and efficiency. Summary of the Invention

[0003] This application provides a method, apparatus, device, storage medium, and product for managing communication cards, which can solve the technical problem that the prior art cannot uniformly manage multiple communication cards of different types held by the same user.

[0004] In a first aspect, embodiments of this application provide a method for managing a communication card, the method comprising: Receive user-submitted bill consolidation requests and determine the various types of communication cards for which the user is requesting bill consolidation; The payment compliance rate of the user is determined based on the historical payment records of each communication card; If the payment compliance rate is greater than the target compliance rate threshold, the outstanding bills for each communication card are obtained and merged to obtain a merged bill; Make payment for the consolidated bill.

[0005] In one feasible implementation, the step of determining the user's payment compliance rate based on the historical payment records of each communication card includes: The payment activity of each communication card in each statistical period is determined based on the historical payment records of each communication card. The user qualification factor is determined based on the user qualification level. The compliance rate of each user is determined by assessing the payment activity of each communication card in each statistical period and the user qualification factor.

[0006] In one feasible implementation, the step of determining the payment activity level of each communication card in each statistical period based on the historical payment records of each communication card includes: The billing time and payment time of each communication card in each statistical period are determined based on the historical payment records of each communication card. The payment time interval for each communication card in each statistical period is determined based on the billing time and payment time of each communication card in each statistical period. The initial activity level of each communication card in each statistical period is determined based on the payment time interval of each communication card in each statistical period, the preset time interval of each communication card, and the payment base days of each communication card. The maximum value between the initial activity level of each communication card in each statistical period and the preset activity level of each communication card is taken as the payment activity level of each communication card in each statistical period.

[0007] In one feasible implementation, the step of determining the user's payment compliance rate by assessing the compliance rate based on the payment activity of each communication card in each statistical period and the user qualification factor includes: In the case of a communication card of type SIM card, the average payment activity of the SIM card in each statistical period is calculated to determine the payment factor of the SIM card. In the case of a communication card of type IoT identification card, the average payment activity of the IoT identification card in each statistical period is calculated, and the payment factor of the IoT identification card is determined according to the average activity and the user's preset risk factor. The user's payment compliance rate is determined by assessing the compliance rate based on the payment factors of the IoT identification card, the user identification card, and the user qualification factor.

[0008] In one feasible implementation, before the step of obtaining and merging the outstanding bills of each communication card to obtain a merged bill when the payment compliance rate is greater than the target compliance rate threshold, the method further includes: Determine the target payment health based on the payment information of all users; If the target payment health is within the health range, the historical compliance rate threshold will be used as the target compliance rate threshold. If the target payment health score is greater than the upper limit of the health score range, the maximum value between the lower limit of the compliance rate threshold and the first adjustment threshold shall be used as the target compliance rate threshold; wherein, the first adjustment threshold is the difference between the historical compliance rate threshold and the threshold adjustment step size; If the target payment health is less than the lower limit of the health range, the minimum value between the upper limit of the compliance rate threshold and the second adjustment threshold shall be used as the target compliance rate threshold; wherein, the second adjustment threshold is the sum of the historical compliance rate threshold and the threshold adjustment step size.

[0009] In one feasible implementation, the step of determining the target payment health based on the user payment information of all users includes: Based on the user payment information of all users, determine the average time interval between the billing time and payment time for each user, the payment amount for each user, and the number of times each user's bill is issued. The health score of each user is calculated based on the average time interval between billing time and payment time, the payment amount of each user, and the number of times each user's bill is issued. The target payment health score is obtained by averaging the payment health scores of each user.

[0010] In one feasible implementation, the step of making payment for the consolidated bill includes: If the current account balance is less than the total payment amount of the consolidated bill, a credit control priority sequence is determined. The amount due for payment of the object corresponding to the current priority is determined in the consolidated bill according to the credit control priority sequence; If the current account balance is greater than or equal to the outstanding payment amount of the object corresponding to the current priority, the outstanding payment amount of the object corresponding to the current priority will be paid. If the current account balance is less than the amount to be paid for the object corresponding to the current priority, the services of the current priority object and the objects following the current priority object in the credit control priority sequence shall be suspended.

[0011] Secondly, embodiments of this application provide a communication card management device, the device comprising: The processing module is used to receive bill consolidation requests submitted by users and determine the various types of communication cards for which users are requesting bill consolidation. The processing module is also used to determine the user's payment compliance rate based on the historical payment records of each communication card; The merging module is used to obtain the outstanding bills of each communication card and merge them to obtain a merged bill when the payment compliance rate is greater than the target compliance rate threshold. The payment module is used to make payments on the consolidated invoices.

[0012] Thirdly, embodiments of this application provide a communication card management device, the device including: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the communication card management method as described in the first aspect.

[0013] Fourthly, embodiments of this application provide a computer storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, they implement the communication card management method as described in the first aspect.

[0014] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by the processor of an electronic device, cause the electronic device to perform a communication card management method as described in the first aspect.

[0015] The communication card management method, apparatus, device, storage medium, and product of this application embodiment, by receiving a user's fee merging request, first accurately identifies the various types of communication cards for which the user's bills need to be merged, and then assesses the user's payment compliance rate based on the historical payment records of each communication card. Only applications with a compliance rate higher than a target threshold are allowed to proceed to the next process, which not only ensures the controllability of the risk of fee merging but also ensures the adaptability of the service recipients. On this basis, the pending bills of each communication card are integrated to generate a unified merged bill and support one-stop payment, breaking down the barriers between different types of communication cards belonging to different service platforms. This enables unified management of the fees of multiple different types of communication cards held by the same user, significantly reduces the user's multi-card management burden, greatly reduces operational complexity, effectively improves the efficiency of multi-card management and user experience, and reduces operating costs. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic flowchart of an embodiment of a communication card management method provided in this application. Figure 2 This is a schematic diagram of the management architecture of the communication card management method provided in Embodiment 1 of this application; Figure 3 This is a schematic diagram of the integrated billing process of the communication card management method provided in Embodiment 1 of this application; Figure 4 This is a schematic diagram of the unified payment process for the communication card management method provided in Embodiment 1 of this application; Figure 5 This is a schematic diagram of the information control fusion process of the communication card management method provided in Embodiment 1 of this application; Figure 6 This is a flowchart illustrating a second embodiment of a communication card management method provided in this application. Figure 7This is a flowchart illustrating a third embodiment of a communication card management method provided in this application. Figure 8 This is a schematic diagram of the structure of a communication card management device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a communication card management device provided in an embodiment of this application. Detailed Implementation

[0018] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0019] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0020] For a single user holding multiple different types of SIM cards, such as IoT SIM cards for connecting to IoT devices and SIM cards for personal mobile communication, the user needs to remember information about each type of SIM card and log in to the corresponding platforms (such as IoT platforms and SIM card platforms) to manage the two types of fees separately. This results in a cumbersome and inefficient payment process. Furthermore, because information is not effectively integrated between the two platforms, users struggle to obtain a comprehensive overview of fees and a unified billing management experience, thus impacting user experience and satisfaction. Simultaneously, with the surge and diversification of IoT devices, different IoT SIM cards may correspond to different service packages and pricing standards, further exacerbating the complexity and challenge of fee management for users.

[0021] To address the problems of the prior art, embodiments of this application provide a method, apparatus, device, storage medium, and product for managing communication cards. The method for managing communication cards provided in this application embodiment will be described first below.

[0022] Figure 1 A flowchart illustrating a communication card management method according to an embodiment of this application is shown. Figure 1 As shown, the method may include steps 210-240: Step 210: Receive the user's request to consolidate bills and determine the various types of communication cards for which the user is requesting bill consolidation.

[0023] The execution entity in this embodiment can be a communication card management device, which is a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone. The communication card management device connects to multiple different types of communication card platforms (such as mobile phone card platforms and IoT card platforms) through preset interfaces to achieve cross-platform data interaction and business collaboration. The communication card management device has five built-in functional modules: an application fee merging module, an application compliance detection module, a fee merging and billing module, a fee merging and credit control module, and a unified fee payment module. The device architecture is shown in Figure 2.

[0024] The interaction logic and overall process between each module, management device, and communication card platform are as follows: Users submit a fee merging request online through any communication card platform. Upon receiving the request via an interface, the fee merging module of the management device immediately calls the communication card platform that initiated the request and other platforms corresponding to the cards to be merged for information pre-verification. After successful pre-verification, the fee merging module synchronizes the request and verification results to the application compliance detection module. Upon receiving the request, the application compliance detection module sends data requests to the platforms corresponding to each communication card to be merged, obtains the historical payment records for each card, and calculates the payment compliance rate based on the user's account status on each platform. If the detection is compliant, it sends a merge permission instruction and a list of cards to be merged to the fee fusion and billing module. If non-compliant, it returns a rejection reason to the user through the platform that initiated the request. Upon receiving the merge permission instruction, the fee fusion and billing module, based on the list of cards to be merged, synchronously retrieves the pending bills from each communication card platform via a cross-platform interface, integrates the bills according to the main merging platform's bill format, generates a merged bill, and synchronizes it to the fee fusion and credit control module.

[0025] The fee fusion and credit control module first identifies the main merged communication card platform, then calls the account interface of the main platform to obtain the current account balance; if the account balance is insufficient, it generates a fee amount to be paid and pushes it to the unified fee payment module; the unified fee payment module pushes the fee amount to be paid to the main merged communication card platform selected by the user through the interface, and at the same time provides multiple payment channels for the user to make payment.

[0026] A fee consolidation request refers to a request submitted by a user through any communication card platform to consolidate the outstanding fees of multiple different types of communication cards held by the user into a single bill. The fee consolidation request includes, but is not limited to, the following information: user identity information (e.g., ID card number, name), the card numbers of the communication cards to be consolidated (e.g., mobile phone card number, IoT card number), the fee consolidation method (e.g., fixed-amount consolidation, full-amount consolidation), and the fee credit control priority.

[0027] A fee consolidation request refers to a request submitted by a user through any communication card platform to consolidate the outstanding fees of multiple different types of communication cards held by the user into a single bill. The fee consolidation request includes, but is not limited to, the following information: user identity information (e.g., ID card number, name), the card numbers of the communication cards to be consolidated (e.g., mobile phone card number, IoT card number), the fee consolidation method (e.g., fixed-amount consolidation, full-amount consolidation), and the fee credit control priority.

[0028] The bill consolidation application module parses the bill consolidation request to determine the various types of communication cards the user is requesting to consolidate. These various types of communication cards refer to cards held by the same user but with different uses and billing rules, including but not limited to user identification cards (i.e., SIM cards) and Internet of Things (IoT) identification cards. User identification cards include, but are not limited to, SIM (Subscriber Identity Module) cards and USIM (Universal Subscriber Identity Module) cards, used to provide complete mobile communication services for individual users; IoT identification cards are IoT-SIM (Internet of Things-Subscriber Identity Module) cards specifically designed to provide low-power network connectivity services for IoT devices.

[0029] The fee merging module calls the platform corresponding to each type of communication card to be merged to pre-verify the information in the fee merging request. The pre-verification must meet all of the following conditions, including but not limited to: the user submitting the request has passed online real-name authentication; if there is a user identification card among the communication cards of each type, the user identification card must be verified by SMS; if there is an IoT identification card among the communication cards of each type, the IoT identification card must exist in the IoT card platform and not be cancelled; the user submitting the request is consistent with the real-name user of each type of communication card.

[0030] After the pre-verification is passed, the application fee merging module forwards the fee merging request to the application compliance detection module for compliance detection; if the pre-verification fails, the relevant prompt information of verification failure will be returned to the user through the communication card platform where the user submitted the application and the process will be terminated.

[0031] Step 220: Determine the payment compliance rate of the user based on the historical payment records of each communication card.

[0032] After the request passes the pre-verification, the compliance detection module calls the payment record query interface of the platform corresponding to each communication card to be merged to obtain the historical payment records of each communication card for the past N consecutive statistical periods. The historical payment records include, but are not limited to, the billing time and the payment time for each statistical period. In this embodiment, N statistical periods are set to 24 months. The number and duration of statistical periods can also be adjusted according to needs, and this embodiment does not impose any restrictions on this.

[0033] Payment compliance rate refers to a quantitative indicator calculated based on a user's historical payment records, reflecting that the user's payment behavior meets the standards of timely and full payment. The higher the compliance rate, the better the user's payment signal.

[0034] Optionally, the compliance detection module calculates the number of payment delay days (payment time - billing time) for each communication card in each statistical period based on the historical payment records of each card, and assigns a base score for the corresponding period based on the number of delay days (e.g., full score for 0 delay days, 0 points for delays exceeding a preset threshold). Subsequently, a weighted average is calculated on the base scores of all the user's communication cards across all periods (e.g., more recent statistical periods have higher weights) to obtain the payment compliance rate.

[0035] In addition to the methods mentioned above, payment compliance rates can also be calculated using methods including but not limited to the following: The application compliance detection module standardizes key dimensions (such as payment delay days, bill amount volatility, etc.) in historical payment records to construct feature vectors, and inputs them into a pre-trained classification model (such as logistic regression or gradient boosting tree); This model learns the correlation pattern between payment behavior and arrears risk in historical data, outputs the probability value of the user's future arrears, and then maps this probability value in reverse (e.g., the lower the probability of arrears risk, the higher the payment compliance rate) as the user's payment compliance rate.

[0036] Step 230: If the payment compliance rate is greater than the target compliance rate threshold, obtain the pending payment bills of each communication card and merge them to obtain a merged bill.

[0037] The target compliance rate threshold is a compliance rate threshold used to determine whether a user is eligible for fee consolidation. It can be set in advance by the operator based on the business risk level, or it can be dynamically adjusted based on the payment health of all users in the system (such as the average compliance rate of all users, the overall arrears rate, etc.).

[0038] The compliance check module compares the user's payment compliance rate with the target compliance rate threshold. If the payment compliance rate is less than or equal to the target compliance rate threshold, the system will return a message to the user via the communication card platform through which the application was submitted, indicating that fee merging is not currently supported, and terminate the process. If the payment compliance rate is greater than the target compliance rate threshold, the fee merging request is approved.

[0039] Optionally, if the payment compliance rate exceeds the target compliance rate threshold, the application compliance detection module immediately sends a merge permission instruction, a list of cards to be merged, and the user-specified fee merging method to the fee merging and billing module. After receiving the above information, the fee merging and billing module initiates a bill retrieval request to the platform corresponding to each communication card to be merged through a standardized cross-platform interface, based on the list of cards to be merged. After each communication card platform responds to the request, it immediately integrates the detailed fee information of its own communication card to be transferred to the communication card platform for which the user submitted the application, according to the fee merging method, and encrypts the data using advanced encryption standards. The two communication card platforms exchange and store each other's public keys in advance, and use asymmetric encryption technology of private key encryption and public key decryption to ensure the unique verification of transmission parameters and data security, and then pushes the encrypted bill to be paid to the fee merging and billing module.

[0040] The billing and merging module decrypts and verifies the encrypted bills to be paid pushed by each communication card platform. If the verification is correct, the bills are merged according to the rule of total amount summation + itemized details retention. That is, the merged bill includes the total amount of cross-platform fees, and the fee details of each communication card are marked as independent entries, clearly distinguishing the card type and fee items. Finally, the generated merged bill is pushed to the communication card platform where the user submitted the application for use in the subsequent unified payment process.

[0041] To facilitate understanding, we will now explain the bill merging process using an example of a user holding an IoT SIM card and a mobile phone SIM card. The merged billing process is as follows: Figure 3As shown. After the billing consolidation module initiates a bill retrieval request to each communication card platform to be consolidated, the IoT card platform first completes the monthly billing for that IoT card, generating the original billing data for the current period. Based on the user-specified billing consolidation method (full consolidation / fixed-amount consolidation), the IoT card platform extracts the billing details that need to be transferred to the SIM card platform for consolidation and payment, and uses advanced encryption standards to perform asymmetric encryption on these details. The IoT card platform pushes the encrypted billing details to the billing consolidation module via a mesh network (the transmission channel corresponding to the standardized cross-platform interface); the billing consolidation module decrypts and verifies the details, and after confirming that they are correct, forwards them to the SIM card platform for which the user submitted the application. The SIM card platform receives the decrypted IoT card billing details and loads them into the SIM card's real-time billing account, completing the initial consolidation of cross-platform billing. When generating the monthly total bill, the mobile SIM card platform lists the IoT card fee details as independent items, summarizes them with the current fee of the mobile SIM card itself to form a unified consolidated bill, and pushes the bill to the user's terminal for subsequent unified payment process. This not only makes it easier for users to understand the cost composition, but also achieves refined and efficient cost management.

[0042] Step 240: Pay the consolidated bill.

[0043] After the consolidated bill is pushed to the SIM card platform where the user submitted the application, the fee fusion and credit control module automatically calls the SIM card platform's account interface to obtain the current account balance and compares it with the total amount of the consolidated bill: If the current account balance is greater than or equal to the total amount of the consolidated bill: the fee fusion credit control module directly triggers the account deduction operation of the communication card platform that submitted the request. After the deduction is completed, a payment completion notification is sent to the unified fee payment module. The communication card platform that submitted the request simultaneously cancels the consolidated fee. If there is a surplus amount after the account deduction, it will be automatically pre-deposited and the account balance will be updated. At the same time, the bill status of the card will be updated to paid on other communication card platforms that are to be consolidated.

[0044] If the account balance is less than the total amount of the consolidated bill, the expense fusion credit control module calculates the outstanding payment difference (i.e., the total amount of the consolidated bill – the current account balance), generates an outstanding payment list, freezes the amount already deducted from the account, and pushes the outstanding payment list to the expense unified payment module. After receiving the list of pending payments, the unified payment module synchronizes it to the user terminal interface of the requesting communication card platform. At this point, the user can view their current account balance and the amount due on the requesting platform, and choose a payment method to top up. After the user selects a payment channel and completes payment of the outstanding balance, the unified payment module immediately sends a payment success message to the fee fusion and credit control module. After payment, the requesting communication card platform processes the historical pending consolidated fees according to the corresponding rules, automatically pre-depositing any excess fees and updating the account balance. Simultaneously, the fee fusion and credit control module synchronizes with other communication card platforms awaiting consolidation, completing the bill cancellation for the corresponding cards and updating their status to "paid," ultimately completing the payment of the consolidated bills.

[0045] For ease of understanding, taking the mobile phone card platform as the main communication card platform as an example, the unified payment process is as follows: Figure 4 As shown, the unified payment module synchronizes the pending payment list to the SIM card service platform (user terminal interface); simultaneously, the SIM card system synchronizes the outstanding amount, issuance time, and issuance frequency corresponding to this consolidated bill to the SIM card service platform. Users select their SIM card account on the SIM card service platform, view the current account balance and outstanding payment information, and then select a payment method to complete the recharge. The payment time and amount are synchronized to the SIM card system. After receiving the payment information, the SIM card system processes the outstanding payment cancellation: if there is a remainder after deducting the outstanding payment, the excess is automatically pre-deposited into the account, the account balance is updated, and the latest account balance is then synchronized back to the SIM card service platform for display to the user. After the user completes the payment, the unified payment module reports a successful payment result to the fee fusion and credit control module; the fee fusion and credit control module then synchronizes this result to other communication card platforms awaiting consolidation, completing the bill cancellation and status update for the corresponding cards, thus ending the consolidated bill payment process.

[0046] In one feasible implementation, step 240 may include steps A11-A13: Step A11: If the current account balance is less than the total payment amount of the consolidated bill, determine the credit control priority sequence.

[0047] Credit control priority sequence refers to the service priority sorting rules that users preset and can customize when submitting a fee merging request. It can cover card level (e.g., priority sorting is: SIM card > IoT card) or specific sub-service levels of the card (e.g., priority sorting is: SIM card data > IoT card data > SIM card voice > IoT card voice > others).

[0048] The current account balance refers to the current account balance of the communication card platform from which the user submitted the request, i.e., the main communication card platform for payment. When the current account balance is detected to be less than the total payment amount of the consolidated bill, the fee fusion and credit control module obtains the credit control priority sequence from the fee fusion request.

[0049] Step A12: Determine the amount to be paid for the object corresponding to the current priority in the consolidated bill according to the credit control priority sequence.

[0050] The current priority object refers to the object being processed in descending order of the credit control priority sequence. It can be a type of communication card or a specific service item of a card. The fee fusion credit control module selects the first object in the credit control priority sequence as the current priority object according to the descending order of the credit control priority sequence, and extracts the current due amount for that object from the item details of the consolidated bill.

[0051] Step A13: If the current account balance is greater than or equal to the amount due for payment of the object corresponding to the current priority, the amount due for payment of the object corresponding to the current priority shall be paid.

[0052] If the current account balance is greater than or equal to the amount due for the object corresponding to the current priority, the fee fusion credit control module triggers the account deduction operation of the main communication card platform to deduct the amount due for the object from the current account balance. After the deduction is completed, the account balance is automatically updated, and the next priority object is selected as the new object corresponding to the current priority according to the order of the credit control priority sequence. Steps A12-A13 are repeated until the account balance is insufficient to trigger the subsequent process.

[0053] Step A14: If the current account balance is less than the amount to be paid for the object corresponding to the current priority, suspend the service for the object corresponding to the current priority and the service for the object following the object corresponding to the current priority in the credit control priority sequence.

[0054] If the current account balance is less than the amount to be paid for the object corresponding to the current priority, the fee fusion credit control module will directly shut down the service corresponding to the object corresponding to the current priority, and at the same time shut down all low-priority services in the credit control priority sequence that are ranked after the object.

[0055] For ease of understanding, taking a user holding both a SIM card and an IoT card, with the credit control priority sequence being SIM card > IoT card, and the SIM card platform being the primary communication card platform, as an example, the fee credit control integration process is as follows: Figure 5As shown: After the process is started, the amount of the merged fee (i.e. the total payment amount of the merged bill) is determined. At the same time, the current account balance of the mobile phone card is obtained, and it is determined whether the account balance is greater than or equal to the amount of the merged fee. If the balance is sufficient, the payment is completed directly. If the balance is insufficient, the process of clearing the bill is initiated and it is determined whether the mobile phone card / IoT card is in arrears. If it is in arrears, the arrears suspension mechanism is triggered. Otherwise, the key process of intelligent hierarchical credit control is initiated. After entering the credit control process, the fee fusion credit control module retrieves the credit control priority sequence. First, it selects the first object in the sequence (SIM card) as the current priority object and extracts its outstanding payment amount. It then checks whether the current account balance is greater than or equal to the outstanding payment amount of the SIM card. If the balance is sufficient, the SIM card fee is deducted and the account balance is updated. Next, it selects the next priority object (IoT card) and checks whether the remaining balance is greater than or equal to the outstanding payment amount of the IoT card. If the balance is sufficient, the fee is deducted and the process ends; otherwise, the IoT card service is suspended.

[0056] If the balance is insufficient: select the next priority object (IoT card) and determine if the remaining balance is greater than or equal to the amount to be paid on the IoT card; if sufficient, deduct the fee and shut down the SIM card service; if still insufficient, shut down both the SIM card and IoT card services at the same time, and the process ends.

[0057] In this implementation, when the account balance is insufficient to cover the combined costs, a user-customizable credit control priority sequence is enabled. The logic of prioritizing payments based on high priority and shutting down current and subsequent low-priority services when the balance is insufficient ensures the continuity and stability of high-priority communication cards or segmented services, while maximizing the effective utilization efficiency of the user's account balance, thus achieving the optimal match between cost allocation and business service priorities.

[0058] This embodiment receives user-submitted fee consolidation requests, first accurately identifies the various types of communication cards for which bills need to be consolidated, and then assesses the user's payment compliance rate based on the historical payment records of each communication card. Only applications with compliance rates higher than a target threshold are allowed to proceed to the next stage, ensuring both the controllability of fee consolidation risks and the suitability of the service recipients. On this basis, the pending bills of each communication card are integrated to generate a unified consolidated bill and support one-stop payment, breaking down the barriers between different types of communication cards belonging to different service platforms. This enables unified management of the fees of multiple different types of communication cards held by the same user, significantly reduces the burden of multi-card management for users, greatly reduces operational complexity, effectively improves the efficiency of multi-card management and user experience, and reduces operating costs.

[0059] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 6In the communication card management method, step 220 may include steps 310-330: Step 310: Determine the payment activity level of each communication card in each statistical period based on the historical payment records of each communication card.

[0060] Payment enthusiasm refers to a quantitative indicator reflecting the timeliness and initiative of payment behavior for a single communication card to be merged within a certain statistical period. The higher the value of payment enthusiasm, the more active the payment behavior is within that statistical period.

[0061] Optionally, for each statistical period of each communication card, the number of days between the billing time and the payment time is calculated. The shorter the interval, the higher the payment enthusiasm value assigned to that period, thus obtaining the payment enthusiasm of each communication card in each statistical period. In addition to the above method, other methods can also be used to calculate payment enthusiasm, and this embodiment does not limit this.

[0062] Step 320: Determine the user qualification factor based on the user's user qualification level.

[0063] User credit rating is a classification system implemented by telecom operators based on factors such as user network usage duration, cumulative spending, and types of services handled. It serves as a label to measure a user's creditworthiness. The user credit factor is a coefficient determined based on the user credit rating and used to adjust compliance rate assessment results; the higher the user credit rating, the larger the value of this factor.

[0064] In some embodiments, the user's qualification level within the operator is queried, and the user qualification factor corresponding to the user is determined based on the mapping relationship between the user qualification level and the factor. For example, if a user's qualification level is Gold User, then the user qualification factor... The value is 1; if the user's qualification level is silver, then the user qualification factor is 1. If the value is 0.9 and the user's qualification level is bronze, then the user qualification factor is... It is 0.8.

[0065] Step 330: Based on the payment activity of each communication card in each statistical period and the user qualification factor, the compliance rate is evaluated to determine the payment compliance rate of the user.

[0066] Optionally, the arithmetic mean of the payment compliance rate of all user's communication cards across all statistical periods can be calculated, and the product of the arithmetic mean and the user's qualification factor can be used as the user's payment compliance rate. Besides the above method, other methods can also be used to calculate the payment compliance rate, and this embodiment does not limit this approach.

[0067] In one possible implementation, step 310 may include steps B11-B14: Step B11: Determine the billing time and payment time of each communication card in each statistical period based on the historical payment records of each communication card.

[0068] Step B12: Determine the payment time interval for each communication card in each statistical period based on the billing time and payment time of each communication card in each statistical period.

[0069] Step B13: Determine the initial activity level of each communication card in each statistical period based on the payment time interval of each communication card in each statistical period, the preset time interval of each communication card, and the payment base days of each communication card.

[0070] Step B14: The maximum value between the initial activity level of each communication card in each statistical period and the preset activity level of each communication card is taken as the payment activity level of each communication card in each statistical period.

[0071] Preset time interval: The payment time limit standard pre-configured by the operator for different types of communication cards (such as mobile phone cards and IoT cards) is used as the core benchmark for judging the timeliness of communication card users' payment behavior and provides a reference threshold for the quantitative calculation of the initial enthusiasm (for example, because mobile phone cards involve the continuity of basic communication services, the preset time interval is set to 3 calendar days; because IoT cards are mostly automatic deduction scenarios of devices, the preset time interval is set to 5 calendar days).

[0072] Number of days for payment base This is the preset time interval between the billing time and the payment time, for example, 1 day. The preset time interval for each communication card... This refers to the maximum allowed payment interval for each communication card, such as the preset interval for a mobile phone card. The preset time interval for IoT cards is 90 days. The preset motivation level is a pre-set minimum motivation score. In this embodiment, the preset motivation level is set to 0, but it can also be adjusted as needed.

[0073] For each SIM card: The compliance testing module calls the payment record query interface provided by the platform corresponding to each SIM card to be merged. From the historical payment record data returned by each platform, it accurately extracts the billing time and the payment time for each SIM card in each statistical period. The payment time interval between the two can be calculated in calendar days, i.e., payment time - billing time, thus obtaining the payment time interval corresponding to each statistical period. .

[0074] For each communication card in the m-th statistical period: based on the payment interval, the preset time interval of the communication card, and the number of payment base days for the communication card, calculate the initial activity level of the communication card in the m-th statistical period: The initial level of payment activity is compared with the preset level, and the maximum value between the two is taken as the payment activity level for that period, specifically the payment activity level for the m-th statistical period. = The level of payment enthusiasm and the payment time interval in each statistical period follow a normal distribution.

[0075] In this embodiment, the billing and payment times for each communication card in each statistical period are extracted, the payment interval is calculated, and the initial initiative is quantified by combining the preset time interval, the number of payment base days, and other parameters. The maximum value of the initial initiative and the preset initiative are taken to accurately quantify the payment initiative, providing reliable data support for subsequent compliance assessments.

[0076] In one feasible implementation, step 330 may include steps C11-C13: Step C11: In the case of a communication card of type SIM card, calculate the average payment activity of the SIM card in each statistical period to determine the payment factor of the SIM card.

[0077] The compliance detection module first determines whether a user identification card exists among the various types of communication cards to be merged; if so, it extracts the payment activity of that user identification card over the past N consecutive statistical periods. The average of payment activity across all periods is calculated using the arithmetic mean method; this average is the payment factor for the user identification card. Specifically: = , = In this implementation, N is 24, and the statistical period is in months. This avoids the impact of anomalies in a single statistical period on the overall judgment, thus obtaining accurate payment factors for user identification cards. .

[0078] Step C12: In the case of a communication card of type IoT identification card, calculate the average payment activity of the IoT identification card in each statistical period, and determine the payment factor of the IoT identification card based on the average activity and the user's preset risk factor.

[0079] The compliance detection module determines whether an IoT identification card exists among the various types of communication cards to be merged. If it does, based on a preset risk control model, it identifies whether there are any preset prohibited risk behaviors in the usage of the IoT identification card (such as malicious arrears, unauthorized card swiping, abnormal cross-regional use, etc.). If it does, the preset risk factor L corresponding to the IoT identification card can be set to 0. If it does not exist, the preset risk factor L can be set to 1. Through the zero-tolerance rule for risk behaviors, precise control over high-risk scenarios of IoT cards can be achieved.

[0080] The application compliance testing module extracts the payment activity of the IoT identification card over the past N consecutive statistical periods. The arithmetic mean of these factors is calculated to obtain the average level of activity. This average level of activity is then multiplied by a preset risk factor; the product is the payment factor for the IoT identification card. Specifically: =L× ; = In this embodiment, N is 24, and the statistical period is in months.

[0081] Step C13: Based on the payment factor of the IoT identification card, the payment factor of the user identification card, and the user qualification factor, a compliance rate assessment is performed to determine the user's payment compliance rate.

[0082] The compliance testing module applies to all communication card payment factors and user qualification factors. Multiplying them together, the resulting product is the user's compliance rate.

[0083] Optionally, when the communication cards to be merged only include IoT identification cards and user identification cards, the user's payment compliance rate X = .

[0084] In this embodiment, by calculating the payment factors of user identification cards and IoT identification cards differently, and combining them with user qualification factors, compliance rate assessment is completed, thus achieving accurate compliance determination in cross-type communication card scenarios.

[0085] This embodiment determines the payment activity level of each communication card in each statistical period based on its historical payment records; it determines the user's user qualification factor based on the user's user qualification level; and it assesses the user's payment compliance rate by combining the payment activity level of each communication card in each statistical period with the user qualification factor. By integrating the dual-dimensional assessment of payment activity level of communication cards in each statistical period and user qualification factor, the user's payment compliance rate is accurately quantified, providing reliable data support for subsequent service management such as fee consolidation eligibility determination.

[0086] Based on any one or more embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 7 Before step 330, steps 410-440 may also be included: Step 410: Determine the target payment health based on the user payment information of all users.

[0087] The term "full user" refers to all users who have completed registration and activated communication card-related services in the payment system. Their payment behavior data constitutes the basic sample pool for group payment credit assessment. User payment information is a collection of payment-related data of all users within a specific time period, including but not limited to the average payment time interval across all statistical periods, the number of payments due, the total amount actually paid in the most recent statistical period, and the total amount of fees due in the most recent statistical period.

[0088] The target payment health score y is a comprehensive group payment credit index obtained by quantifying the user payment information of all users. It is used to reflect the overall payment performance ability and credit level of users in the system. The higher the score, the better the overall credit environment and the lower the system risk.

[0089] Optionally, the compliance detection module can obtain the payment information of all users and output a quantified target health score through a preset health score calculation model (e.g., standardizing and weighting multiple indicators). Besides the above method, other methods can also be used to calculate the target payment health score; this embodiment does not limit this approach.

[0090] Step 420: If the target payment health is within the health range, the historical compliance rate threshold is used as the target compliance rate threshold.

[0091] The health range is a pre-set target payment health normal range. , Historical compliance rate threshold This is the previously effective target compliance rate threshold. If the target payment health score calculated from all users' payment information is within the healthy range, the compliance rate threshold will not be adjusted; the historical compliance rate threshold will be directly used as the currently effective target compliance rate threshold. In this embodiment, Set it to 0.8. The initial value of the compliance rate threshold is set to 0.8, which can be adjusted as needed. This embodiment does not impose any restrictions on this.

[0092] Step 430: If the target payment health score is greater than the upper limit of the health score range, the maximum value between the lower limit of the compliance rate threshold and the first adjustment threshold is taken as the target compliance rate threshold; wherein, the first adjustment threshold is the difference between the historical compliance rate threshold and the threshold adjustment step size.

[0093] When the target health level is greater than the upper limit of the health range (i.e., y> In cases where the threshold needs to be appropriately lowered, the historical compliance rate threshold should be calculated first. and threshold adjustment step size The difference between them yields the first adjustment threshold. .

[0094] The pre-set lower limit of the compliance rate threshold The maximum value among the first adjustment thresholds is used as the target compliance rate threshold, which can be specifically: =max( In this embodiment, Set it to 0.01. The value is set to 0.7, but it can be adjusted according to needs. This embodiment does not impose any restrictions on this.

[0095] Step 440: If the target payment health is less than the lower limit of the health range, the minimum value between the upper limit of the compliance rate threshold and the second adjustment threshold is taken as the target compliance rate threshold; wherein, the second adjustment threshold is the sum of the historical compliance rate threshold and the threshold adjustment step size.

[0096] When the target payout health level is less than the lower limit of the health level range (i.e., y < 0), the payout is less than the lower limit of the health level range. In cases where the threshold needs to be appropriately increased, the historical compliance rate threshold should be calculated first. and threshold adjustment step size The sum between them yields the second adjustment threshold. .

[0097] The pre-set compliance rate threshold upper limit The minimum value between the second and third adjustment thresholds is used as the target compliance rate threshold, which can be specifically: =min( + In this embodiment, The value is set to 0.9, but it can be adjusted according to needs. This embodiment does not impose any restrictions on this.

[0098] In one feasible implementation, step 410 may include steps D11-D13: Step D11: Based on the user payment information of all users, determine the average time interval between the billing time and payment time for each user, the payment amount for each user, and the number of times each user's bill is issued.

[0099] For each user in the entire user base, using their payment information, calculate the payment time interval between the bill issuance time and the actual payment time for each bill within each statistical period, and then take the arithmetic mean of the payment time intervals to obtain the user's average time interval. The unit can be daily. Using user payment information within a specific time period, the total actual payment amount for that user in the most recent statistical period can be obtained. The total amount payable by this user in the most recent statistical period. And the number of bills issued for outstanding fees, N, and the payment amount includes the user's total actual payment amount. and total amount payable .

[0100] Step D12: Calculate the health status of each user based on the average time interval between billing time and payment time, the payment amount of each user, and the number of times each user's bill is issued, and determine the payment health status of each user.

[0101] For each user: based on the average time interval between billing time and payment time, payment amount, number of bill issuances, and the weight of each issuance. Weighting of the difference between issuance time and payment time Weights of payment completion rate The preset maximum number of times the message can be sent is a threshold. (e.g., 12) and the preset maximum time difference threshold (For example, over 30 days), calculate each user's payment health score, specifically as follows: = (1 - ) + (1 - )+ (1 - ) Among them, the maximum distribution coefficient threshold is used to normalize the impact of the number of distributions, and the maximum time difference threshold is used to normalize the impact of time difference. + + = 1. In this embodiment, the values ​​of the three are set to 1 / 3 respectively. They can also be adjusted according to actual needs. This embodiment does not limit this.

[0102] The more times a bill for outstanding fees is issued, the more likely the user is to make delayed payments. The greater the difference between the bill issuance time and the payment time, the worse the user's timeliness in paying. The smaller the ratio of the actual payment amount to the amount due, the weaker the user's willingness to pay.

[0103] Step D13: Calculate the average of the payment health scores of each user to obtain the target payment health score.

[0104] Optionally, the target payment health score is obtained by averaging the payment health scores of all users, specifically: y = ,in The number of users. When a user's payment information is updated, the user's payment health is updated based on that user's payment information, and the target payment health is updated simultaneously.

[0105] In this implementation, by extracting the average payment interval, payment amount, and number of bill issuances for all users, the payment health of a single user is quantified and the average is taken to obtain the target payment health. This achieves a multi-dimensional and accurate assessment, reflecting both individual payment credit and accurately presenting the overall payment health status of the group, providing reliable data support for the subsequent dynamic adjustment of the compliance rate threshold.

[0106] This embodiment determines the target payment health based on the payment information of all users. When the target payment health is within the health range, a historical compliance rate threshold is used as the target compliance rate threshold. When the target payment health is greater than the upper limit of the health range, the maximum value between the lower limit of the compliance rate threshold and a first adjustment threshold is used as the target compliance rate threshold. The first adjustment threshold is the difference between the historical compliance rate threshold and the threshold adjustment step size. When the target payment health is less than the lower limit of the health range, the minimum value between the upper limit of the compliance rate threshold and the second adjustment threshold is used as the target compliance rate threshold. The second adjustment threshold is the sum of the historical compliance rate threshold and the threshold adjustment step size. By quantifying the target payment health based on the payment information of all users and dynamically adjusting the compliance rate threshold according to its matching with the health range (using the historical threshold in normal conditions, lowering it when it is too high, and raising it when it is too low, subject to boundary constraints), precise adaptation of the threshold to the group's payment credit status is achieved, ensuring reasonable service coverage while controlling business risks.

[0107] It should be noted that the acquisition, storage, use, and processing of data in the embodiments of this application all comply with the relevant provisions of national laws and regulations. Furthermore, it should be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0108] like Figure 8 As shown, this application embodiment provides a communication card management device 200, which may include a processing module 201, a merging module 202, and a payment module 203; Processing module 201 is used to receive a bill consolidation request submitted by the user and determine the various types of communication cards for which the user is requesting bill consolidation.

[0109] The processing module 201 is also used to determine the user's payment compliance rate based on the historical payment records of each communication card.

[0110] The merging module 202 is used to obtain the outstanding bills of each communication card and merge them to obtain a merged bill when the payment compliance rate is greater than the target compliance rate threshold.

[0111] Payment module 203 is used to make payments for the consolidated bill.

[0112] The conversion module 204 is used to perform text sequence conversion on the multimodal fusion feature vector to obtain the management result of the communication card.

[0113] Optionally, the processing module 201 is further configured to: The payment activity of each communication card in each statistical period is determined based on the historical payment records of each communication card. The user qualification factor is determined based on the user qualification level. The compliance rate of each user is determined by assessing the payment activity of each communication card in each statistical period and the user qualification factor.

[0114] Optionally, the processing module 201 is further configured to: The billing time and payment time of each communication card in each statistical period are determined based on the historical payment records of each communication card. The payment time interval for each communication card in each statistical period is determined based on the billing time and payment time of each communication card in each statistical period. The initial activity level of each communication card in each statistical period is determined based on the payment time interval of each communication card in each statistical period, the preset time interval of each communication card, and the payment base days of each communication card. The maximum value between the initial activity level of each communication card in each statistical period and the preset activity level of each communication card is taken as the payment activity level of each communication card in each statistical period.

[0115] Optionally, the processing module 201 is further configured to: In the case of a communication card of type SIM card, the average payment activity of the SIM card in each statistical period is calculated to determine the payment factor of the SIM card. In the case of a communication card of type IoT identification card, the average payment activity of the IoT identification card in each statistical period is calculated, and the payment factor of the IoT identification card is determined according to the average activity and the user's preset risk factor. The user's payment compliance rate is determined by assessing the compliance rate based on the payment factors of the IoT identification card, the user identification card, and the user qualification factor.

[0116] Optionally, the merging module 202 is further configured to: Determine the target payment health based on the payment information of all users; If the target payment health is within the health range, the historical compliance rate threshold will be used as the target compliance rate threshold. If the target payment health score is greater than the upper limit of the health score range, the maximum value between the lower limit of the compliance rate threshold and the first adjustment threshold shall be used as the target compliance rate threshold; wherein, the first adjustment threshold is the difference between the historical compliance rate threshold and the threshold adjustment step size; If the target payment health is less than the lower limit of the health range, the minimum value between the upper limit of the compliance rate threshold and the second adjustment threshold shall be used as the target compliance rate threshold; wherein, the second adjustment threshold is the sum of the historical compliance rate threshold and the threshold adjustment step size.

[0117] Optionally, the merging module 202 is further configured to: Based on the user payment information of all users, determine the average time interval between the billing time and payment time for each user, the payment amount for each user, and the number of times each user's bill is issued. The health score of each user is calculated based on the average time interval between billing time and payment time, the payment amount of each user, and the number of times each user's bill is issued. The target payment health score is obtained by averaging the payment health scores of each user.

[0118] Optionally, the payment module 203 is further configured to: If the current account balance is less than the total payment amount of the consolidated bill, a credit control priority sequence is determined. The amount due for payment of the object corresponding to the current priority is determined in the consolidated bill according to the credit control priority sequence; If the current account balance is greater than or equal to the outstanding payment amount of the object corresponding to the current priority, the outstanding payment amount of the object corresponding to the current priority will be paid. If the current account balance is less than the amount to be paid for the object corresponding to the current priority, the services of the current priority object and the objects following the current priority object in the credit control priority sequence shall be suspended.

[0119] Figure 9 A schematic diagram of the hardware structure of the communication card management device provided in an embodiment of this application is shown.

[0120] The communication card management device may include a processor 301 and a memory 302 storing computer program instructions.

[0121] Specifically, the processor 301 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0122] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 302 may include removable or non-removable (or fixed) media, or memory 302 may be non-volatile solid-state memory. Memory 302 may be internal or external to the integrated gateway disaster recovery device.

[0123] In one instance, memory 302 may be read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0124] Memory 302 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0125] The processor 301 reads and executes computer program instructions stored in the memory 302 to achieve... Figure 1 The communication card management method in the illustrated embodiment.

[0126] In one example, the management device for the communication card may further include a communication interface 303 and a bus 304. Wherein, for example... Figure 9 As shown, the processor 301, memory 302, and communication interface 303 are connected through bus 304 and complete communication with each other.

[0127] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0128] Bus 304 includes hardware, software, or both, that couples components of the communication card's management device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 304 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0129] The management device for this communication card can be based on the management method of the communication card, thereby achieving integration. Figures 1-7 The described method for managing communication cards.

[0130] Furthermore, in conjunction with the communication card management methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the communication card management methods in the above embodiments.

[0131] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the communication card management methods described in the above embodiments.

[0132] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0133] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0134] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0135] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0136] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method of managing a communication card, characterized by, The method comprises: receiving a user-submitted fee consolidation request, determining multiple types of communication cards applied for bill consolidation by the user; determining a fee compliance rate of the user according to historical fee payment records of the communication cards; in the case where the fee compliance rate is greater than a target compliance rate threshold, obtaining to-be-paid bills of the communication cards and consolidating to obtain a consolidated bill; paying the consolidated bill.

2. The method of claim 1, wherein, The step of determining the fee compliance rate of the user according to the historical fee payment records of the communication cards comprises: determining a fee initiative of the communication cards in each statistical period according to the historical fee payment records of the communication cards; determining a user qualification factor of the user according to a user qualification level of the user; determining the fee compliance rate of the user according to the fee initiative of the communication cards in each statistical period and the user qualification factor.

3. The method of claim 2, wherein, The step of determining the fee initiative of the communication cards in each statistical period according to the historical fee payment records of the communication cards comprises: determining a bill issuing time of the communication cards in each statistical period and a fee payment time of the communication cards in each statistical period according to the historical fee payment records of the communication cards; determining a fee payment time interval of the communication cards in each statistical period according to the bill issuing time of the communication cards in each statistical period and the fee payment time of the communication cards in each statistical period; determining an initial initiative of the communication cards in each statistical period according to the fee payment time interval of the communication cards in each statistical period, a preset time interval of the communication cards, and a fee reference number of days of the communication cards; taking a maximum value of the initial initiative of the communication cards in each statistical period and a preset initiative of the communication cards as the fee initiative of the communication cards in each statistical period.

4. The method of claim 2, wherein, The step of determining the fee compliance rate of the user according to the fee initiative of the communication cards in each statistical period and the user qualification factor comprises: in the case where there is a communication card of a type of user identification card, performing mean value calculation on the fee initiative of the user identification card in each statistical period to determine a fee factor of the user identification card; in the case where there is a communication card of a type of Internet of Things identification card, performing mean value calculation on the fee initiative of the Internet of Things identification card in each statistical period, and determining a fee factor of the Internet of Things identification card according to the mean value of the initiative and a preset risk factor of the user; determining the fee compliance rate of the user according to the fee factor of the Internet of Things identification card, the fee factor of the user identification card, and the user qualification factor.

5. The method of claim 1, wherein, Before the step of obtaining to-be-paid bills of the communication cards and consolidating to obtain a consolidated bill in the case where the fee compliance rate is greater than a target compliance rate threshold, the method further comprises: determining a target payment health degree according to user fee payment information of all users; in the case where the target payment health degree is within a health degree range, taking a historical compliance rate threshold as the target compliance rate threshold; In a case where the target payment health degree is greater than the upper limit value of the health degree range of the health degree, the maximum value between the compliance rate threshold lower limit value and a first adjustment threshold value is taken as the target compliance rate threshold value, wherein the first adjustment threshold value is a difference value between the historical compliance rate threshold value and a threshold adjustment step length; In a case where the target payment health degree is less than the lower limit value of the health degree range of the health degree, the minimum value between the compliance rate threshold upper limit value and a second adjustment threshold value is taken as the target compliance rate threshold value, wherein the second adjustment threshold value is a sum value between the historical compliance rate threshold value and a threshold adjustment step length.

6. The method of claim 5, wherein, The step of determining the target payment health degree according to the user payment information of the total quantity of users comprises: According to the user payment information of the total quantity of users, the time interval mean value between the account withdrawal time and the payment time of each user, the payment amount of each user, and the number of times of bill issuance of each user are determined; According to the time interval mean value between the account withdrawal time and the payment time of each user, the payment amount of each user, and the number of times of bill issuance of each user, the payment health degree of each user is determined through health degree calculation; The payment health degrees of the users are subjected to mean value calculation to obtain the target payment health degree.

7. The method according to any one of claims 1 to 6, characterized in that, The step of paying the combined bill comprises: In a case where the current account balance is less than the total payment amount of the combined bill, a sequence of control priorities is determined; According to the sequence of control priorities, the to-be-paid amount of the current priority corresponding object in the combined bill is determined; In a case where the current account balance is greater than or equal to the to-be-paid amount of the current priority corresponding object, the to-be-paid amount of the current priority corresponding object is paid; In a case where the current account balance is less than the to-be-paid amount of the current priority corresponding object, the current priority object and the services after the current priority corresponding object in the sequence of control priorities are discontinued.

8. A management apparatus of a communication card, characterized by comprising: The device comprises: A processing module is configured to receive a fee combination request submitted by a user, and determine a plurality of types of communication cards for which the user applies for bill combination; The processing module is further configured to determine a payment compliance rate of the user according to historical payment records of the communication cards; A combination module is configured to, in a case where the payment compliance rate is greater than a target compliance rate threshold value, obtain to-be-paid bills of the communication cards and combine the to-be-paid bills to obtain a combined bill; A payment module is configured to pay the combined bill.

9. A management device of a communication card, characterized by comprising: The management device of the communication card comprises a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the management method of the communication card according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions, and the computer program instructions are executed by the processor to implement the management method of the communication card according to any one of claims 1-7.

11. A computer program product, characterised in that, The instructions in the computer program product are executed by the processor of the electronic device, so that the electronic device performs the management method of the communication card according to any one of claims 1-7.

Images