SMART SUBSCRIBER CONVERSION MANAGEMENT SYSTEM

Abstract

This invention relates to a system (1) that enables the determination of payment type or product type change by analyzing the payment type and product type change requests of mobile subscribers in the telecommunications sector according to their subscription information, billing status, active package and campaign records and operator rules.

Description

1 TARIFF SMART SUBSCRIBER CONVERSION MANAGEMENT SYSTEM Technical Area This invention relates to payment types and product types for mobile subscribers in the telecommunications sector. Change requests include subscription information, billing status, active package, and Payment type is determined by analyzing campaign records and operator rules. It relates to a system that enables the identification of product type changes. Previous Technique Today, telecommunication systems include prepaid / postpaid options for subscribers. This payment type includes voice, data, short message and M2M (Machine to Machine – Product type conversion processes (Machine-to-Machine Communication); 15 Jobs defined in subscription management, service authorization and billing systems It is carried out according to the rules. Transformation decisions in existing systems. Since regulations are mostly issued with fixed decision rules and operator approvals, A decision appropriate to the context was made by analyzing the campaign conditions and product transition rules. It cannot be produced. Also, a rollback feature allows for reverting erroneous conversions. Verifiable blockchain for transformation decisions through acquisition mechanism Erroneous conversions and billing discrepancies occur because records cannot be created. Deficiencies manifested as insufficient oversight and increased operational costs. It is emerging. Therefore, considering the studies and shortcomings in the current technique... when considered, the payment type for mobile subscribers in the telecommunications sector and product type conversion processes; subscriber status, billing information, campaign managed according to definitions, service usage authorizations, and operator rules. It appears that a system providing this is needed. 30 2 United States Regulation US2023156455A1, which is included in the known state of the art. The patent document describes how users can access smart contracts on a blockchain network. Automatic management of subscription offers for your devices and selected enabling subscription information to be securely provided to devices remotely. A system is being discussed. In this invention, only the boot profile 5 enabling user devices to remotely retrieve operational subscription profiles. The aim is to provide blockchain messages containing information about the user's device. This information is transmitted to the smart contract. The smart contract receives data from different mobile network operators. It enables the collection of subscription offers selected by the user. Supply data is generated based on the subscription offer. The 10 generated... Once the data is verified, it is remotely transmitted to the device. The system is eUICC-based. It supports the configuration of devices via OTA (Over-the-Air). It also supports IoT. decentralized structure for creating subscriptions for devices It enables its realization. The invention, based on the logic of auction or marketplace. This makes it possible to evaluate offers from different operators. Smart 15 contracts regulate the exchange of data between device owners, manufacturers, and mobile operators. It manages existing subscriptions to different operators securely. It supports relocation and reconstruction. Brief Description of the Invention 20 The purpose of this invention is to convert prepaid card payments from mobile subscribers to postpaid lines, postpaid from line to prepaid card or voice, data, M2M (Machine to Machine) products in the form of communication) and IoT (Internet of Things). In requests for changes between payment types; the subscriber's current payment type, product type, 25 billing status, active packages, campaigns, commitments, service authorizations, and changing payment type or product type using operator rules determining the conditions for implementation, payment type, product type in the changes, Updating package and service information, details of the updates performed If a difference occurs or the conversion is cancelled, the payment type, product type, 30 Records created before the package and service information conversion process 3 Summary of the decision regarding the change, recreated and implemented using and The goal is to create a system that records the time of the process. Detailed Description of the Invention The "Smart Subscriber Transformation" carried out to achieve the purpose of this invention. The "Management System" is shown in the attached diagram; Figure 1. Schematic view of the system described in the invention. The parts shown in the figure are individually numbered, and the corresponding numbers correspond to these numbers. given below: 1. System 2. Application 15 3. Database 4. Conversion management server 5. Blockchain server Payment type and product type for mobile subscribers in the telecommunications sector: 20 Change requests include subscription information, billing status, active package, and Payment type is determined by analyzing campaign records and operator rules. The invention was developed to enable the identification of product type changes. system (1); - the user's smartphone, tablet computer, desktop computer or portable 25 an electronic device in the form of a computer that automatically processes data. running applications and / or software that function and produce meaningful results, creating a request for a change of payment type or product type, user approval, and the receipt of the rollback request, the conversion result, and information about the transactions performed. At least one application configured to display the information (2), 30 4 - Payment type, product type, billing status, and outstanding balance information for mobile subscribers. Active package, campaign, commitment, service authorization, product type conversion restrictions, Regulation texts, operator rules, historical conversion records, rollback at least one configured to store records and blockchain record references database (3) and 5 - data received via application (2) request for change of payment type or product type (3) registered subscription information, billing status, active package, campaign, Analysis using service authorizations, regulatory texts, and operator rules. to create a conversion plan regarding payment type or product type changes. at least one conversion management server configured to (4), 10 - Decision summary transmitted by the conversion management server (4), pre-transaction status summary, target status summary, timestamp, transaction ID, and rollback reference save the records of the conversion processes in an unalterable way and later... at least one blockchain server configured to prevent its modification (5) It includes. 15 The application (2) in the system (1) that is the subject of the invention, the user's prepaid card to postpaid even product types ranging from postpaid to prepaid or voice, data, M2M and IoT. a request to change payment type or product type to switch between them 20 the ability for the user to enter approval or undo request for the conversion process, The generated request, user approval, and undo request are managed by conversion management. can transmit to the server (4) and by the conversion management server (4) Acceptance or rejection status of the submitted payment type or product type change, Payment type or product type, conversion completion status, return 25 Information on the completion status of the acquisition process and the transaction time. It is configured to provide at least one interface that allows it to be viewed. The database (3) in the system (1) which is the subject of the invention, prepaid cards of mobile subscribers or current payment type in invoice form, invoice period, outstanding balance status, 30 past payment behavior, credit or risk classification, balance, and payment type. Change history data; current product type including voice, data, M2M and IoT, Service authorizations, access profiles, network policy definitions, and product type-dependent settings. Product type conversion constraints; active campaign, contract, package, discount, partnership usage rights and commitment information; telecommunications regulations, public authority decisions, internal operator business rules, campaign conditions and product 5 texts defined in natural language relating to their dependencies; through the application (2) Payment type or product type change transmitted to conversion management server (4) requests, user approvals, and rollback requests; conversion management server Rule objects created by (4) are JSON (JavaScript Object Notation – JavaScript Object Representation) or DSL (Domain-Specific Language) (Language) based decision diagrams, state-transition matrices, prerequisite-postrequisite tables, prohibited passage lists, contradiction scores, confidence coefficients, executable transit plans, return conditions, checkpoints, reverse procedures definitions and transaction IDs; type of payment made or type of product Changes transaction logs, rollback logs, pre-transaction and transaction 15 post-status summaries, decision summary hash (cryptographic hash value) values, to keep records of timestamps and transaction IDs It is being structured. The system in question (1) includes the transformation management server (4), application (2) 20 the request for change of payment type or product type submitted via, user approval and To receive the refund request, the existing payment type, product type, registered in the database (3), billing status, outstanding debt information, past payment history, credit or risk classification, balance, active package, campaign, contract, discount, shared usage Rights, commitments, service authorization, access profile, network policy definitions, product type 25 Conversion constraints, past conversion records, and rollback records are requested. It is structured for use in analyzing the change. Transformation management server (4), telecommunication regulations taken from database (3), public authority decisions, operator internal business rules, campaign conditions and product texts defined in natural language relating to their dependencies; text decomposition, semantics 30 by processing through decomposition, entity extraction, and rule normalization operations 6 Converting rule objects into executable rule objects, executing the generated rule objects in the LLM by processing in a decision engine based on the Large Language Model. JSON (JavaScript Object Notation) or DSL Domain-Specific Language (DSL) based decision schemas, situation- transition matrices, prerequisite-postrequisite tables, prohibited transition lists, and return 5 It is structured to create the conditions for acquisition. Transformation management The server (4) creates rule objects and the payment type, product type, of the subscriber. Analyzing billing status, package, campaign, commitment, and service authorization data. This allows for changes to the requested payment type or product type. to determine if there are any discrepancies, to establish the sequence of actions to be followed, and to identify 10 incompatible elements. by identifying regulations, campaigns, or operator rules that produce results to determine the rule to be applied and the payment type, product for the approved change This will be done in the type, package, campaign, service authorization and billing information. update steps and the rollback to be applied for each update step It is structured to create a transformation plan that includes the steps. 15 The conversion management server (4) processes the subscriber according to the conversion plan created. payment type, product type, package, campaign, service authorization and billing information operator's subscriber management, service and product identification (Provisioning), product authorization, campaign management, and billing in that order. To carry out the update, each step of the process included in the transformation plan is 20. Before implementation, the subscriber's payment type, product type, package, campaign, and service authorization will be checked. and billing information records at that moment as a checkpoint. to create, track completed transaction steps with transaction IDs, transaction Failure to complete any of these steps may result in problems with different operator infrastructures. If there is a discrepancy between the updated records or if the user returns 25 If a purchase request is created, Saga Pattern (Saga Pattern – Multi-Step Process) Compensating Transaction for each transaction step using the Management Pattern method By using a (Compensatory Process), the completed process steps are sequenced from the last process to the first. to get back to the process, the payment type, product type and resulting from the conversion to communicate the conversion status to the application (2) and pre-transaction status summary, decision 30 7 hash, target status summary, timestamp, transaction ID on the blockchain It is configured to transfer to the server (5). The blockchain server (5) in the system in question (1) can be accessed remotely from any remote application (2), database (3), conversion management using communication protocol 5 to communicate with the server (4) and exchange data through this communication It is configured to carry out the conversion. The blockchain server (5) created by the management server (4) in such a way as not to contain personal data the transmitted pre-transaction status summary, decision regarding payment type or product type change The hash includes the target status summary, timestamp, transaction ID, and rollback 10. to obtain the reference, these received data are the blockchain record of the same transformation process. to store it in an unalterable way, once the record is created by preventing changes to records, refunds can be obtained through changes to payment type or product type. It is configured to preserve the integrity of the records related to the retrieval process. Industrial Application of the Invention Thanks to the system (1) which is the subject of the invention, mobile subscribers in the telecommunications sector From prepaid to postpaid, from postpaid to prepaid, or voice, data, M2M and IoT. Requests to switch to different line products in this form; the subscriber's current line type, open 20 debt status, active packages, campaigns, commitments, service authorizations, and operator Evaluation using the transit restrictions determined by [the relevant authority], deemed appropriate. Updating billing, package and service information in the specified order during transitions, If an error occurs during the process or the transition is cancelled, the change will be made. Restoring the information to its pre-processing state and the decision, timing, and process related to the transition 25 and the retrieval information must be recorded in a way that prevents subsequent alteration. is provided. Around these basic concepts, the invention is called “Smart Subscriber Conversion Management System (1)” It is possible to develop a wide variety of applications related to this invention, and the invention is presented here in 30 It cannot be limited to the examples given; it is essentially as stated in the claims.

Claims

8 REQUESTS 1. Payment type and product type for mobile subscribers in the telecommunications sector. Change requests include subscription information, billing status, active package, and Payment type 5 was determined by analyzing campaign records and operator rules. or enabling the identification of product type changes; - the user's smartphone, tablet computer, desktop computer or run on an electronic device in the form of a portable computer, an application that automatically processes data and produces meaningful results and / or execution of software, payment type or product type changes 10 the creation of the request, user approval and cancellation request the receipt of the conversion result and information about the transactions performed at least one application configured to enable display (2), - Payment type, product type, billing status, and outstanding balance for mobile subscribers. Information, active package, campaign, commitment, service authorization, product type conversion 15 restrictions, regulatory texts, operator rules, historical conversion records, to store retrieval records and blockchain record references containing at least one structured database (3) and - Change of payment type or product type received via application (2) request registered subscription information, billing status, 20 in the database (3) active package, campaign, service authorizations, regulatory texts and operator analyzing using the rules, payment type or product type change at least one transformation structured to create a related transformation plan management server (4), - Decision summary transmitted by the conversion management server (4), 25 before the transaction Status summary, target status summary, timestamp, transaction ID, and rollback. save the reference in an unchangeable way and the conversion processes at least configured to prevent subsequent alteration of records a payment system characterized by a blockchain server (5) (1). 9 2. The user can switch between prepaid and postpaid lines, postpaid and prepaid lines, or voice services. data, M2M and IoT product types are being transitioned towards the ability to create a request to change payment type or product type, payment type or conversion process to carry out a product type change The user can enter confirmation or a cancellation request, and the created request is 5 user approval and rollback request to the conversion management server (4) to transmit and sent by the transformation management server (4) Acceptance or rejection of a change in payment type or product type. the type of payment made or the type of product, the completion of the conversion status, completion status of the rollback process and transaction time 10 to provide at least one interface that allows it to view its information a structured application (2) as in Claim 1 system (1).

3. The current payment type for mobile subscribers, whether prepaid or postpaid, is 15 billing period, outstanding balance, past payment history, credit or risk classification, balance and payment type change history data; voice, The current product types are data, M2M, and IoT, and services depend on the product type. permissions, access profiles, network policy definitions, and product type conversion restrictions; active campaign, contract, package, discount, shared usage right and 20 commitment information; telecommunications regulations, public authority decisions, internal operator business rules, campaign conditions and product texts defined in natural language relating to their dependencies; application (2) payment type or product transmitted to the conversion management server (4) type change requests, user approvals and rollback requests; 25 rule objects generated by the transformation management server (4), JSON or DSL-based decision diagrams, state-transition matrices, prerequisite-postrequisite tables, prohibited crossing lists, contradiction points, confidence levels, feasible transition plans, return conditions, checkpoints, reverse transaction definitions, and transaction IDs; 30 Transaction records of changes made to payment type or product type, recovery records, pre- and post-transaction status summaries, decision The summary records hash values, timestamps, and transaction IDs. the above is characterized by the database structured to hold (3) a system like any of the requests (1).

4. Changes in payment type or product type transmitted via Application (2) to obtain the request, user approval and cancellation request, in the database (3) Registered current payment type, product type, billing status, outstanding debt information, past payment behavior, credit or risk classification, balance, assets package, campaign, contract, discount, shared usage right, commitment, service 10 Authorization, access profile, network policy definitions, product type conversion The requested restrictions, past conversion records, and rollback records transformation structured for use in analyzing change any of the above requests characterized by the management server (4) a system like one of them (1). 15 5. Telecommunication regulations taken from the database (3), public authority decisions, internal operator business rules, campaign conditions and product texts that describe their addictions in natural language; text fragmentation, 20 from semantic parsing, entity extraction and rule normalization operations converting the created rule into executable rule objects by passing it through by processing objects in an LLM-based decision engine using JSON or DSL-based decision diagrams, state-transition matrices, prerequisite-postrequisite tables, to create prohibited crossing lists and conditions for repatriation 25 characterized by the configured transformation management server (4) a system like any of the above requests (1).

6. The created rule objects specify the subscriber's payment type, product type, and billing. By analyzing status, package, campaign, commitment and service authorization data The requested payment type or product type change can be implemented within 30 days. to determine if it is not, to create the sequence of actions to be taken, and to connect them 11 regulations, campaigns, or operator rules that produce incompatible results by identifying and determining the rule to be applied and the appropriate change Billing based on payment type, product type, package, campaign, and service authorization. the steps to be taken to update the information and each update The transformation plan, which includes the undo steps to be implemented in response to step 5 with the transformation management server (4) configured to create a system like any of the above characterized claims (1).

7. According to the conversion plan created, the subscriber's payment type, product type, package, 10 The campaign, service authorization, and billing information are provided to the operator's subscriber. management, service and product identification, product authorization, campaign To manage and update the billing process according to the order of operations. Before each step included in the conversion plan is implemented, the subscriber's Payment type, product type, package, campaign, service authorization and billing 15 to create the records of their information at that moment as a checkpoint, Tracking completed transaction steps using transaction IDs, transaction Failure to complete any of the steps, different operator inconsistencies may occur between updated records in their infrastructure or If a rollback request is created by the user, Saga Pattern 20 Compensating Transaction for each transaction step is completed using this method. Reversing the process steps from the last step to the first step, conversion The resulting payment type, product type, and conversion status are applied. (2) transmit and pre-transaction status summary, decision summary hash, target status summary, timestamp, to transmit the transaction ID to the blockchain server (5) 25 characterized by the configured transformation management server (4) a system like any of the above requests (1).

8. Using any remote communication protocol, the application (2), data base (3) communicates with the transformation management server (4) and these 30 established structured to exchange data over communication channels 12 from the above requests characterized by the blockchain server (5) a system like any other (1).

9. Transformation management server (4) will not contain personal data The pre-transaction status summary, generated and transmitted, is based on payment type or product type 5. Summary of decision changes includes hash, target status summary, and timestamp. Obtaining the transaction ID and rollback reference, and using this data in the same way. immutably within the blockchain record of the conversion process to store, to prevent modification of records after they have been created by blocking the refund process through a change in payment type or product type. with blockchain server (5) configured to maintain record integrity a system like any of the above characterized claims (1). 20 30

Images