A method and device for adaptively predicting phone bill arrears

Abstract

The application provides a method for self-adaptive prediction of phone bill arrears, comprising the following steps: real-time monitoring and receiving each CDR phone bill pushed by a basic operator; extracting resource consumption from the latest N phone bills of each user currently in an active state; receiving D_predict(t) and T_deplete of each user; putting the user into a high-risk risk control dynamic trigger queue; maintaining a high-risk risk control dynamic timer, and triggering a local risk control judgment process when the timer is zero; dynamically calculating a trigger interval of the next judgment according to the latest T_deplete of the user after each risk control judgment is completed or after each new phone bill arrives and the deduction is completed; triggering the risk control judgment according to the calculated time interval; and solving the problem that virtual merchants cannot perceive that the user continues to use the service to cause the "arrears over-stay" bad account problem.

Description

Technical Field

[0001] This invention belongs to the field of AI and virtual operator call detail record (CDR) processing, and in particular relates to a method and apparatus for adaptively predicting CDR arrears. Background Technology

[0002] In mobile resale services, MVNOs typically lack independent core network elements and cannot directly obtain real-time communication signaling (such as RADIUS or Diameter). Deductions for user call charges and data usage rely entirely on billing call detail records (CDRs) asynchronously pushed in batches by the main operator (MNO) via FTP or API. These CDRs are usually pushed in batches approximately every 15 minutes, and during peak network periods, holidays, or cross-provincial or international roaming scenarios, the push delay can extend to several hours.

[0003] During this call detail record (CDR) delay window, if a user's local credit limit has reached zero, the MVNO (Mobile Virtual Network Operator) can only passively wait for the next batch of CDRs to arrive before deducting charges and notifying the user of the outstanding amount. As a result, the user can continue to use the service during this period, leading to serious "overdue payment and suspension" bad debts and causing significant economic losses to the MVNO.

[0004] It is important to note that basic telecom operators only provide call detail record (CDR) push services and do not offer any form of real-time balance query or cumulative usage query interface. Virtual operators (MVNOs) determine a user's balance entirely based on the deduction results from received CDRs. This means that MVNOs cannot obtain a user's real-time status through "active querying" and can only passively discover outstanding charges after the CDRs arrive. Summary of the Invention

[0005] The purpose of this embodiment is to provide an adaptive method and apparatus for predicting overdue call details, which can solve the problem of bad debts caused by virtual operators being unable to detect users' overdue payments and continuing to use services.

[0006] An adaptive method for predicting overdue call detail records includes: Call detail record (CDR) latency analysis steps: Monitor and receive each CDR pushed by the basic operator in real time, record the T_service end time and T_reception time of each CDR, calculate the latency Di = T_reception time - T_service end time, and store Di in the latency sample pool according to service type, province, and network standard. When it is necessary to predict the expected latency D_predict(t) at the current moment, retrieve the latency sample set that matches the dimensions within the most recent time window from the sample pool, and calculate D_predict(t) = Σ(Wi×Di) / ΣWi using a weighted moving average algorithm, where Wi is the weight coefficient that decays over time. User consumption rate estimation step: For each currently active user, extract the resource consumption from the N most recently received bills of the user, and calculate the short-term average resource consumption rate R_consume = total consumption / total time span covered by the N bills; retrieve the current available balance B_avail of the user from the virtual operator local billing database; estimate the time required for the user to exhaust resources T_deplete = B_avail / R_consume; Risk assessment step: Receive D_predict(t) and the T_deplete of each user, and execute the judgment condition T_deplete ≤ a×D_predict(t) for each active user, where a is a safety correction coefficient; if the judgment condition is satisfied, the user is admitted to the high-risk control dynamic trigger queue; if the judgment condition is not satisfied, the user is filtered out; Active risk control triggering step: Maintain an independent timer for each user entering the high-risk control dynamic trigger queue, and trigger a local risk control judgment process when the timer expires; Adaptive trigger interval calculation step: After each risk control judgment is completed or after each new bill arrives and the fee deduction is completed, dynamically calculate the trigger interval for the next judgment according to the user's latest T_deplete as I = max(I_min, b×T_deplete), where I_min is the shortest trigger interval allowed by the apparatus, and b is a frequency adjustment factor; set the calculated I as the countdown duration for the user's next risk control judgment; Multi-level pre-control response step: Trigger the risk control judgment at the calculated time interval, read the user's current remaining quota from the local billing database, and judge whether the user has a substantial arrearage: if the user is in arrears, immediately send a pre-shutdown or QoS speed limit degradation instruction to the basic operator; if the user is not in arrears, enter a disaster tolerance judgment sub-process — check whether the time interval Δt since the user last received a bill satisfies Δt > a×D_predict(t), if yes, trigger preventive shutdown and send an informing short message, start a background asynchronous reconciliation task and wait for subsequent bills to arrive for verification and service restoration; if not, continue monitoring according to the adaptive trigger interval.

[0007] Further, in the bill delay analysis step, the weighted moving average algorithm adopts an exponentially weighted moving average, with the weight coefficient Wi = a×(t - t_i), where a is an attenuation factor, 0<a<1, t is the current moment, and t_i is the receiving moment of the i-th sample.

[0008] Further, in the user consumption rate estimation step, the value of N ranges from 5 to 20; if the user has multiple types of resources, penetration calculation is performed according to the resource stack priority to obtain the comprehensive available balance.

[0009] Furthermore, in the risk assessment step, the safety correction coefficient 'a' ranges from 1.2 to 1.5, and the value of 'a' is dynamically adjusted according to the time period: a larger value is taken for periods with large fluctuations in prediction delay, and a smaller value is taken for periods with relatively stable prediction delay.

[0010] Furthermore, in the adaptive trigger interval calculation step, the value of b ranges from 0.3 to 0.5; between the arrival of two call detail records (CDRs), T_deplete remains constant, and the trigger interval I also remains unchanged; the update of T_deplete only occurs after a new CDR arrives and the billing is completed, and I then undergoes a step jump.

[0011] Furthermore, in the multi-level pre-control response steps, when it is determined that there is a substantial arrears, the control action and result are recorded and the process exits; when a preventive shutdown is triggered, a notification SMS is sent to the user's mobile phone number, with the message "Due to the device detecting that your account may have an arrears risk, temporary shutdown protection has been implemented. If the shutdown is accidental, please wait for the call detail record to be synchronized before automatic reactivation"; after the subsequent call detail record arrives, the user's actual arrears are verified. If it is verified that there is no arrears, a quick reactivation without application is automatically triggered and a reactivation notification SMS is sent. If it is verified that there is indeed an arrears, the shutdown status is maintained.

[0012] Furthermore, it also includes a self-healing step for call detail record (CDR) timeouts: when a CDR is determined to be severely out of service and triggers a preventative shutdown, an asynchronous reconciliation task is initiated in the background to continuously wait for subsequent CDRs; after subsequent CDRs arrive, the user's actual outstanding charges are verified. If no charges are found, a fast service restoration is automatically triggered; if charges are found to be incurred, the service remains in a standby state.

[0013] Furthermore, the delay sample pool is classified and stored according to the dimensions of service type, province, and network standard. When making predictions, the call detail record (CDR) delay analysis step only uses the sample set that matches the dimension of the current CDR to be predicted. The value of the security correction coefficient 'a' is dynamically adjusted according to the time period.

[0014] An adaptive device for predicting overdue call detail records (CDRs), used to implement the method of claim 1, comprising: The call detail record (CDR) latency analysis module is configured to monitor and receive each CDR pushed by the basic operator in real time, record the T_service end time and T_reception time of each CDR, and calculate the latency Di = T_reception time - T_service end time. Di is then categorized and stored in the latency sample pool according to service type, province, and network standard. When it is necessary to predict the expected latency D_predict(t) at the current moment, the latency sample set that matches the dimensions within the most recent time window is taken from the sample pool, and the weighted moving average algorithm is used to calculate D_predict(t) = Σ(Wi×Di) / ΣWi, where Wi is the weight coefficient that decays over time. The user consumption rate estimation module is configured to extract resource consumption from the N most recently received call detail records (CDRs) for each currently active user, calculate the short-term average resource consumption rate R_consume = total consumption / total time span covered by the N CDRs; retrieve the user's current available balance B_avail from the MVNO's local billing database; estimate the time required for the user to exhaust their resources T_deplete = B_avail / R_consume, and output T_deplete to the risk assessment model. The risk assessment model is configured to receive D_predict(t) and T_deplete for each user. For each active user, the judgment condition T_deplete≤a×D_predict(t) is executed, where a is the security correction coefficient, with a value range of 1.2~1.5. If the judgment condition is met, the user is admitted to the high-risk risk control dynamic trigger queue; if the judgment condition is not met, the user is filtered. The proactive risk control trigger queue is configured to maintain an independent timer for each user entering the queue. When the timer reaches zero, a local risk control judgment process is triggered. The adaptive trigger interval algorithm module is configured to dynamically calculate the trigger interval I=max(I_min, b×T_deplete) for the next judgment based on the user's latest T_deplete after each risk control judgment is completed or after each new call detail record arrives and the deduction is completed. Where I_min is the shortest trigger interval allowed by the device and b is a frequency adjustment factor with a value between 0.3 and 0.5. The calculated I is set as the countdown time for the user's next risk control judgment. The multi-level pre-control response module is configured to be triggered at calculated time intervals. It reads the user's current remaining credit from the local billing database and determines whether there is a substantial overdue payment. If there is an overdue payment, it immediately sends a pre-shutdown or QoS rate limiting and downgrading instruction to the basic operator. If there is no overdue payment, it enters the disaster recovery assessment sub-process—checking whether the time interval Δt between the user and the last received call detail record (CDR) satisfies Δt > a×D_predict(t). If it does, it triggers a preventive shutdown and sends a notification SMS, and starts a background asynchronous reconciliation task to wait for subsequent CDRs to arrive before verifying and restoring service. If it does not satisfy the condition, it continues to monitor according to the adaptive trigger interval.

[0015] Furthermore, the multi-level pre-control response module is also configured to: record the control action and result and exit the process when it is determined that there is a substantial overdue payment; send a notification SMS to the user's mobile phone number when a preventive shutdown is triggered; start a background asynchronous reconciliation task to continuously wait for subsequent call details, and verify the user's actual overdue payment after the subsequent call details arrive. If it is verified that there is no overdue payment, it will automatically trigger a quick reactivation without application and send a reactivation notification SMS. If it is verified that there is indeed an overdue payment, it will remain in the shutdown state.

[0016] This invention provides a method and apparatus for adaptively predicting overdue call detail records (CDRs), which solves the problem of bad debts caused by virtual operators (MVNOs) continuing to use services despite overdue payments, resulting in "overdue payment and service suspension".

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] Figure 1 : A structural diagram of the adaptive prediction of overdue call detail records provided in an embodiment of the present invention; Figure 2: A flowchart of the call detail record delay prediction method for the adaptive prediction of call detail record arrears provided in an embodiment of the present invention; Figure 3: Flowchart of user consumption estimation and exhaustion time calculation for the adaptive prediction of overdue call details provided in an embodiment of the present invention; Figure 4: Flowchart of high-risk user access filtering for the adaptive prediction of overdue call detail records provided in an embodiment of the present invention; Figure 5: A schematic diagram of the adaptive shrinkage ladder of the adaptive prediction of overdue call detail records provided in an embodiment of the present invention; Figure 6: Adaptive shrinkage logic flowchart of the adaptive prediction of overdue call detail records provided in an embodiment of the present invention; Figure 7: A flowchart of the control response processing of the adaptive prediction of overdue call detail records provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the present invention will now be described with reference to the accompanying drawings in the embodiments of the present invention.

[0020] This embodiment provides an adaptive method for predicting overdue call detail records (CDRs). This method is applied to the BOSS device of a mobile virtual network operator (MVNO) service and is used to achieve accurate prevention of overdue calls without relying on any real-time query interface of the basic operator through adaptive proactive risk control.

[0021] like Figure 1 As shown, the device of the present invention includes six core functional modules: a call detail record (CDR) delay analysis module, a user consumption rate estimation module, a risk assessment model, an active risk control trigger queue, an adaptive trigger interval algorithm, and a multi-level pre-control response module.

[0022] Step 1: Dynamically calculate the expected delay of the current call detail record (CDR): like Figure 2 As shown, the call detail record (CDR) delay prediction process specifically includes the following sub-steps: Step S101: The device monitors and receives each CDR call detail record (CDR) pushed by the basic operator in real time. Upon receiving each CDR i, it immediately records its T_service end time (the time when the user service ends as recorded in the CDR) and T_reception time (the time when the device actually receives the CDR).

[0023] Step S102: Calculate the delay Di of the call detail record i = T_reception time – T_service end time, in seconds.

[0024] Step S103: Store the calculated Di into the latency sample pool, which is classified and stored according to service type (such as traffic, voice, SMS), province, network standard (4G / 5G) and other dimensions.

[0025] Step S104: When it is necessary to predict the expected delay D_predict(t) at the current moment, the device retrieves the set of delay samples {D1, D2, ..., Dn} that match the dimensions within the most recent time window (e.g., the past 1 hour) from the sample pool.

[0026] Step S105: Apply a weighted moving average algorithm to the sample set, assigning higher weights to samples closer to the current time. The calculation formula is: D_predict(t) = Σ(Wi × Di) / ΣWi; Where Wi is the weight coefficient of the i-th sample, which decays over time. As an example, an exponentially weighted moving average can be used, with the weight coefficient Wi = α^(t - t_i^), where α is the decay factor (0 < α < 1), t is the current time, and t_i is the receiving time of the i-th sample.

[0027] Step 2: Estimate the user's real-time consumption rate and exhaustion time: like Figure 3 As shown, the user consumption estimation and exhaustion time calculation process specifically includes the following sub-steps: Step S201: For each user currently in an "active state", the device extracts the resource consumption (number of bytes of data or number of seconds of voice calls) from the N most recently received call detail records. Preferably, the value of N is in the range of 5 to 20, which ensures both statistical stability and sensitivity to recent consumption behavior.

[0028] Step S202: Calculate the user's average resource consumption rate R_consume over a short period of time: R_consume = Total consumption / Total time span covered by N call detail records; The unit is, for example, bytes per second or seconds per second (for voice services).

[0029] Step S203: Retrieve the user's current available balance (or the remaining available credit within the corresponding package) B_avail from the MVNO's local billing database. If the user has multiple types of resources (such as general traffic + targeted traffic + account balance), the device performs a pass-through calculation according to the resource stack priority to obtain the comprehensive available balance. For example, when general traffic is exhausted, targeted traffic is automatically consumed, and when targeted traffic is exhausted, the account balance is consumed. The device accumulates and calculates the comprehensive available balance according to this priority order.

[0030] Step S204: Estimate the time T_deplete required for the user to exhaust account resources at the current consumption rate. T_deplete = B_avail / R_consume; in seconds.

[0031] Step S205: Output the calculated T_deplete to the risk assessment model and update it synchronously in the user state cache.

[0032] Step 3: High-risk user identification and proactive risk control triggering queue access filtering like Figure 4 As shown, the high-risk user access filtering process specifically includes the following sub-steps: Step S301: The risk assessment model receives D_predict(t) from the call detail record delay analysis module and T_deplete from each user from the consumption estimation module.

[0033] Step S302: For each active user, the device executes the determination condition: T_deplete ≤ a × D_predict_(t); where a is the safety correction coefficient, typically ranging from 1.2 to 1.5, used to reserve a safety margin for call detail record (CDR) delay prediction deviations. Those skilled in the art can adjust the value of a within this range according to the actual operational scenario. For example, a larger value of a (e.g., 1.5) can be selected for periods with large predicted delay fluctuations (such as holidays), while a smaller value of a (e.g., 1.2) can be selected for periods with relatively stable predicted delays.

[0034] Step S303: If the judgment condition is met (i.e., "yes"), it means that the user is likely to exhaust the balance within the current call detail record delay window and the virtual operator will not be able to detect the user's arrears before the next batch of call detail records arrives. The device will then admit the user into the "high-risk risk control dynamic trigger queue".

[0035] Step S304: If the judgment condition is not met (i.e., "no"), it means that the user has sufficient balance and will not incur charges before the expected call details arrive. The device filters the user and does not enter the risk control trigger queue, thus saving device computing resources.

[0036] Step S305: After this screening, usually only less than 5% of users will enter the high-risk queue, while the remaining 95% or more of safe users will be excluded from proactive risk control.

[0037] Step 4: Adaptively reduce the risk control trigger interval based on the remaining exhaustion time: like Figure 5 and Figure 6 As shown, the adaptive shrinking process for risk control judgment trigger intervals specifically includes the following sub-steps: Step S401: For each user entering the "High-Risk Risk Control Dynamic Trigger Queue", the device maintains an independent timer. When the timer reaches zero, a local risk control judgment process is triggered.

[0038] Step S402: After each risk control judgment is completed (or after each new call detail record arrives and the deduction is completed), the device dynamically calculates the trigger interval I for the next judgment based on the user's latest T_deplete: I = max(I_min, b ×T_deplete) in: - I_min is the shortest allowed trigger interval for the device (e.g., 30 seconds), which is set by the maintenance personnel according to the device's processing capacity; - b is the frequency adjustment factor, with a value between 0.3 and 0.5, used to control the contraction speed; The max() function ensures that the interval does not fall below the device's safety lower limit.

[0039] Step S403: The device sets the calculated I as the countdown timer for the user's next risk control decision.

[0040] Step S404: It is particularly important to emphasize that between the arrival of two call detail records (CDRs), since the device cannot know the user's real-time consumption, T_deplete remains a constant value, and the trigger interval I also remains unchanged. The update of T_deplete only occurs after the new CDR arrives and the charge is completed—the device recalculates T_deplete based on the new remaining credit limit and the updated consumption rate, and I subsequently undergoes a step jump (jumping to a smaller or larger value, which manifests as a gradual decrease in the case of continuous user consumption).

[0041] Step S405: A typical step-by-step contraction path is as follows: - Initially: T_deplete = 600 seconds; I = 5 minutes (at this time, b is 0.5, I = 0.5 × 600 = 300 seconds = 5 minutes); - Upon arrival of a new call log: T_deplete is updated to 300 seconds; I = 2.5 minutes (stepwise descent); - After the call detail record arrives again: T_deplete is updated to 60 seconds; I = 30 seconds (stepwise decrease, reaching I_min); - Once I_min is reached, monitor continuously at the highest frequency (30 seconds) until the user is shut down or the risk control is lifted.

[0042] Step S406: It needs to be reiterated that each risk control judgment does not initiate any query to the operator. Instead, the device automatically triggers the billing engine locally to check whether "the user's remaining credit limit is negative after receiving call detail records and deductions up to the current moment." This is a purely internal calculation triggering mechanism that does not rely on any external interface.

[0043] Step 5: Multi-level pre-control response and disaster recovery mechanism like Figure 7 As shown, the multi-level pre-control response processing flow specifically includes the following sub-steps: Step S501: The active risk control trigger queue triggers the multi-level pre-control response module to perform risk control judgment according to the calculated time interval.

[0044] Step S502: The device reads the user's current remaining credit limit (i.e., the balance after all received call detail records have been deducted as of the current time) from the local billing database.

[0045] Step S503: The device determines whether the user has substantial outstanding fees (i.e., remaining balance < 0): - Scenario A (Payment in arrears): Execute step S504A. The device immediately sends a "pre-shutdown" or "QoS rate limiting and downgrading" command to the basic operator through the standard interface, interrupting the user's continued consumption of network resources. Record this control action and result, and exit this process.

[0046] - Scenario B (No outstanding fees): Proceed to step S504B. The device enters the disaster recovery assessment sub-process step S505B.

[0047] Step S505B: The device checks the time interval Δt between the last time the high-risk user's call detail record was received and determines whether the following conditions are met: Δt > a × D_predict(t); that is, whether the user's call detail record (CDR) has seriously timed out. Where a is the same security correction coefficient as in step S302.

[0048] Step S506B: If the call detail record (CDR) timeout condition is met, it indicates that there is an abnormal delay in the basic operator's CDR push, and the user is continuously consuming data without knowing the situation, posing a very high risk of overdue payment. The device triggers a "preventive shutdown" command, sends a shutdown request to the basic operator, and simultaneously sends a notification SMS to the user's mobile phone number (the content of which is: "Due to the device detecting that your account may have an overdue payment risk, temporary shutdown protection has been implemented. If the shutdown is accidental, please wait for the CDR to be synchronized before automatic reactivation").

[0049] Step S507B: The device initiates a background asynchronous reconciliation task and continues to wait for subsequent call detail records to arrive.

[0050] Step S508B: After the subsequent call detail record arrives, the device verifies the user's actual outstanding payment status: if no outstanding payment is verified, the device automatically triggers "fast reactivation without application," restores the user's service, and sends a reactivation notification SMS; if outstanding payment is verified, the service remains suspended.

[0051] Step S509B: If the call detail record has not timed out (i.e., it is still within the expected delay window), the device records the user's current security status and continues to monitor according to the adaptive trigger interval.

[0052] This embodiment provides an adaptive device for predicting overdue call detail records (CDRs), the device comprising: 1. Call Detail Record (CDR) Delay Analysis Module: Configured to monitor and receive each CDR pushed by the basic operator in real time, record the T_service end time and T_reception time of each CDR, calculate the delay Di~ = T_reception time – T_service end time, and store Di in the delay sample pool according to dimensions such as service type, province, and network standard; when it is necessary to predict the expected delay D_predict(t) at the current moment, take the set of delay samples that match the dimensions within the most recent time window from the sample pool, and use the weighted moving average algorithm to calculate D_predict(t) = Σ(Wi × Di) / ΣWi, where Wi is the weight coefficient, which decays over time.

[0053] 2. User Consumption Rate Estimation Module: Configured to extract resource consumption from the N most recently received call detail records (CDRs) for each currently active user, calculate the short-term average resource consumption rate R_consume = total consumption / total time span covered by the N CDRs; retrieve the user's current available balance B_avail from the MVNO's local billing database (if multiple resource types exist, calculate the comprehensive available balance based on resource stack priority); estimate the time required for the user to exhaust their resources T_deplete = B_avail / R_consume, and output T_deplete to the risk assessment model.

[0054] 3. Risk assessment model: Configured to receive D_predict(t) and T_deplete for each user, and execute the judgment condition T_deplete ≤ a × D_predict(t) for each active user, where a is the security correction coefficient, with a value range of 1.2~1.5; if the judgment condition is met, the user is admitted to the high-risk risk control dynamic trigger queue; if the judgment condition is not met, the user is filtered.

[0055] 4. Proactive Risk Control Trigger Queue: Configured to maintain an independent timer for each user entering the queue. When the timer reaches zero, a local risk control judgment process is triggered.

[0056] 5. Adaptive Trigger Interval Algorithm Module: Configured to dynamically calculate the trigger interval I = max(I_min, b × T_deplete) for the next judgment based on the user's latest T_deplete after each risk control judgment is completed or after each new call detail record arrives and the deduction is completed, where I_min is the shortest trigger interval allowed by the device, and b is a frequency adjustment factor with a value between 0.3 and 0.5; the calculated I is set as the countdown time for the user's next risk control judgment.

[0057] 6. Multi-level pre-control response module: Configured to be triggered at calculated time intervals, it reads the user's current remaining credit from the local billing database and determines whether there is substantial arrears (remaining credit < 0): If there is arrears, it immediately sends a pre-shutdown or QoS rate limiting and downgrading instruction to the basic operator; if there is no arrears, it enters the disaster recovery assessment sub-process—checking whether the time interval Δt between the user and the last received call detail record (CDR) satisfies Δt > a × D_predict(t). If it satisfies, it triggers preventive shutdown and sends a notification SMS, starts a background asynchronous reconciliation task to wait for subsequent CDRs to arrive and verify the restoration of service; if it does not satisfy, it continues to monitor according to the adaptive trigger interval.

[0058] Preferably, the device further includes a call detail record (CDR) timeout disaster recovery and self-healing mechanism: when it is determined that the CDR has seriously timed out and triggered a preventive shutdown, the device starts a background asynchronous reconciliation task to continuously wait for subsequent CDRs; after the subsequent CDRs arrive, the device verifies the user's actual arrears. If it is verified that there are no arrears, it automatically triggers rapid restoration; if it is verified that there are indeed arrears, it keeps the device in a shutdown state.

[0059] Preferably, the delay sample pool is classified and stored according to service type, province, and network standard. When making predictions, the call detail record (CDR) delay analysis module only uses the sample set that matches the current CDR dimension to be predicted.

[0060] Preferably, the value of the safety correction coefficient 'a' is dynamically adjusted according to the time period: a larger value is taken for periods with large fluctuations in prediction delay, and a smaller value is taken for periods with relatively stable prediction delay.

[0061] This invention provides a method and apparatus for adaptively predicting overdue call detail records (CDRs), which solves the problem of bad debts caused by virtual operators (MVNOs) continuing to use services despite overdue payments, resulting in "overdue payment and service suspension".

[0062] The above description is merely an embodiment of the present invention and is not intended to limit the scope of protection of the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for adaptively predicting overdue call detail records (CDRs), characterized in that, include: Call detail record (CDR) latency analysis steps: Monitor and receive each CDR pushed by the basic operator in real time, record the T_service end time and T_reception time of each CDR, calculate the latency Di = T_reception time - T_service end time, and store Di in the latency sample pool according to service type, province, and network standard. When it is necessary to predict the expected latency D_predict(t) at the current moment, retrieve the latency sample set that matches the dimensions within the most recent time window from the sample pool, and calculate D_predict(t) = Σ(Wi×Di) / ΣWi using a weighted moving average algorithm, where Wi is the weight coefficient that decays over time. User consumption rate estimation steps: For each currently active user, extract the resource consumption from the N most recently received call detail records (CDRs), calculate the short-term average resource consumption rate R_consume = total consumption / total time span covered by the N CDRs; retrieve the user's current available balance B_avail from the MVNO's local billing database; estimate the time required for the user to exhaust their resources T_deplete = B_avail / R_consume; Risk assessment steps: Receive D_predict(t) and T_deplete for each user. For each active user, execute the judgment condition T_deplete ≤ a×D_predict(t), where a is the security correction coefficient. If the judgment condition is met, the user is admitted to the high-risk risk control dynamic trigger queue. If the judgment condition is not met, the user is filtered out. Proactive risk control triggering steps: Maintain an independent timer for each user entering the high-risk risk control dynamic triggering queue, and trigger a local risk control judgment process when the timer reaches zero; Adaptive trigger interval calculation steps: After each risk control judgment is completed or after each new call detail record arrives and the billing is completed, the trigger interval for the next judgment is dynamically calculated based on the user's latest T_deplete, I = max(I_min, b×T_deplete), where I_min is the shortest trigger interval allowed by the device and b is the frequency adjustment factor; the calculated I is set as the countdown timer for the user's next risk control judgment; Multi-level pre-control response steps: Trigger risk control judgment according to the calculated time interval, read the user's current remaining credit from the local billing database, and determine whether the user has substantial arrears: If arrears have occurred, immediately send a pre-shutdown or QoS rate limiting and downgrading instruction to the basic operator; if no arrears have occurred, enter the disaster recovery analysis sub-process—check whether the time interval Δt between the user and the last received call detail record (CDR) satisfies Δt > a×D_predict(t). If it satisfies, trigger preventive shutdown and send a notification SMS, start the background asynchronous reconciliation task to wait for subsequent CDRs to arrive and verify the restoration of service; if it does not satisfy, continue monitoring according to the adaptive trigger interval.

2. The adaptive prediction method for overdue call detail records according to claim 1, characterized in that, In the bill delay analysis step, the weighted moving average algorithm adopts an exponentially weighted moving average, and the weight coefficient Wi = a×(t - t_i), where a is the attenuation factor, 0 < a < 1, t is the current moment, and t_i is the receiving moment of the i-th sample.

3. The adaptive prediction method for overdue call detail records according to claim 1, characterized in that, In the user consumption rate estimation step, the value of N ranges from 5 to 20; if the user has multiple types of resources, penetration calculation is performed according to the priority of the resource stack to obtain the comprehensive available balance.

4. The adaptive prediction method for overdue call detail records according to claim 1, characterized in that, In the risk assessment step, the value of the security correction coefficient a ranges from 1.2 to 1.5, and the value of a is dynamically adjusted according to the time period: a larger value is taken for the time period with large predicted delay fluctuation, and a smaller value is taken for the time period with relatively stable predicted delay.

5. The adaptive prediction method for overdue call detail records according to claim 1, characterized in that, In the adaptive trigger interval calculation step, the value of b ranges from 0.3 to 0.5; between the arrival of two bills, T_deplete remains a constant value, and the trigger interval I also remains unchanged; The update of T_deplete only occurs after a new bill arrives and the fee deduction is completed, and I will generate a step jump accordingly.

6. The method for adaptively predicting overdue call detail records according to claim 1, characterized in that, In the multi-level pre-control response step, when it is determined that a substantial arrearage has occurred, the current control action and result are recorded and the process is exited; After the preventive shutdown is triggered, a notification SMS is sent to the user's mobile phone number, and the content of the SMS includes "The device has detected that your account may have an arrearage risk, and temporary shutdown protection has been implemented. If the shutdown is mistaken, please wait for the bill to synchronize and the service will be automatically restored"; after the subsequent bill arrives, the actual arrearage situation of the user is verified. If it is verified that there is no arrearage, the application-free fast service restoration is automatically triggered and a service restoration notification SMS is sent. If it is verified that there is indeed an arrearage, the shutdown state is maintained.

7. The adaptive prediction method for overdue call detail records according to claim 1, characterized in that, It also includes a bill timeout disaster recovery self-healing step: when it is determined that the bill has not arrived after a serious timeout and preventive shutdown is triggered, a background asynchronous reconciliation task is started to continuously wait for subsequent bills; after the subsequent bill arrives, the actual arrearage situation of the user is verified. If it is verified that there is no arrearage, fast service restoration is automatically triggered. If it is verified that there is indeed an arrearage, the shutdown state is maintained.

8. The method for adaptively predicting overdue call detail records according to claim 1, characterized in that, The delay sample pool is classified and stored according to the dimensions of service type, province and network standard. When making predictions in the bill delay analysis step, only the sample set matching the dimensions of the current bill to be predicted is used; the value of the security correction coefficient a is dynamically adjusted according to the time period.

9. An apparatus for adaptively predicting overdue call detail records, used to implement the method of claim 1, characterized in that, includes: The bill delay analysis module is configured to real-timely monitor and receive each CDR bill pushed by the basic operator, record the T_service end time and T_receiving time of each bill, calculate the delay Di = T_receiving time - T_service end time, and store Di in the delay sample pool by classification according to the dimensions of service type, province and network standard; when it is necessary to predict the expected delay D_predict(t) at the current moment, the delay sample set within the latest time window and with matching dimensions is taken out from the sample pool, and the weighted moving average algorithm is used to calculate D_predict(t) = Σ(Wi×Di) / ΣWi, where Wi is the weight coefficient that decays with time; The user consumption rate estimation module is configured to extract resource consumption from the N most recently received call detail records (CDRs) for each currently active user, calculate the short-term average resource consumption rate R_consume = total consumption / total time span covered by the N CDRs; retrieve the user's current available balance B_avail from the MVNO's local billing database; estimate the time required for the user to exhaust their resources T_deplete = B_avail / R_consume, and output T_deplete to the risk assessment model. The risk assessment model is configured to receive D_predict(t) and T_deplete for each user. For each active user, it executes the judgment condition T_deplete≤a×D_predict(t), where a is the security correction coefficient, with a value range of 1.2~1.

5. If the judgment condition is met, the user is admitted to the high-risk risk control dynamic trigger queue; if the judgment condition is not met, the user is filtered. The proactive risk control trigger queue is configured to maintain an independent timer for each user entering the queue. When the timer reaches zero, a local risk control judgment process is triggered. The adaptive trigger interval algorithm module is configured to dynamically calculate the trigger interval I=max(I_min, b×T_deplete) for the next judgment based on the user's latest T_deplete after each risk control judgment is completed or after each new call detail record arrives and the deduction is completed. Where I_min is the shortest trigger interval allowed by the device and b is a frequency adjustment factor with a value between 0.3 and 0.

5. The calculated I is set as the countdown time for the user's next risk control judgment. The multi-level pre-control response module is configured to be triggered at calculated time intervals. It reads the user's current remaining credit from the local billing database and determines whether there is a substantial overdue payment. If there is an overdue payment, it immediately sends a pre-shutdown or QoS rate limiting and downgrading instruction to the basic operator. If there is no overdue payment, it enters the disaster recovery assessment sub-process—checking whether the time interval Δt between the user and the last received call detail record (CDR) satisfies Δt > a×D_predict(t). If it does, it triggers a preventive shutdown and sends a notification SMS, and starts a background asynchronous reconciliation task to wait for subsequent CDRs to arrive before verifying and restoring service. If it does not satisfy the condition, it continues to monitor according to the adaptive trigger interval.

10. The apparatus for adaptively predicting overdue call detail records according to claim 9, characterized in that, The multi-level pre-control response module is also configured to: record the control action and result and exit the process after determining that there is a substantial overdue payment; and send a notification SMS to the user's mobile phone number after triggering a preventive shutdown. The background asynchronous reconciliation task is started and continues to wait for subsequent call details. After the subsequent call details arrive, the actual outstanding amount of the user is verified. If it is verified that there is no outstanding amount, the quick reactivation without application is automatically triggered and a reactivation notification SMS is sent. If it is verified that there is indeed an outstanding amount, the user is kept in the suspended state.

Images