KR20240012210A - Method for processing request for subscription and method for adding function - Google Patents

Abstract

A subscription request processing method according to an embodiment includes receiving a subscription request for a product; Confirming conditions according to the subscription request from business rules; Confirming a plug-in class corresponding to the condition from the business rule; creating an object for the plug-in class; And it may include performing verification of the condition through an object for the plug-in class.

Description

How to process subscription requests and add functions {METHOD FOR PROCESSING REQUEST FOR SUBSCRIPTION AND METHOD FOR ADDING FUNCTION}

The disclosure relates to a method of processing subscription requests and a method of adding functionality.

Fintech is a compound word of financial and technology, and includes mobile payments and remittances, simple payments, personal asset management, crowd funding, and P2P (Peer-to-Peer). It refers to a new form of financial technology based on information technology (IT), such as loans and virtual currency. Recently, with the rapid development of network technology and mobile device-related technology such as smartphones, unlike traditional financial services that focused only on product development, launch, and operation by financial institutions such as banks, various companies such as IT companies and large corporations The company has become a fintech business and is providing fintech services tailored to user convenience and demand through smartphone applications and Internet web services.

However, fintech services to date have the problem that when changes occur, such as new or revised related laws or the addition of new products, developers must change the existing system in addition to adding functions and even perform regression testing. do.

One embodiment seeks to provide a method for processing subscription requests.

One embodiment seeks to provide a method of adding functionality.

A subscription request processing method according to an embodiment to solve this technical problem includes receiving a subscription request for a product; Confirming conditions according to the subscription request from business rules; Confirming a plug-in class corresponding to the condition from the business rule; creating an object for the plug-in class; And it may include performing verification of the condition through an object for the plug-in class.

The product is a newly released product, and the conditions for the product and the plug-in class corresponding to the conditions may be plugged into the business rule.

The conditions may include age for subscription, number of seats available for subscription, and cost base date.

The business rule may include mapping information for the condition and the plug-in class.

The step of performing the verification includes checking a condition value for the condition from the business rule; determining whether the subscription request satisfies the condition value; and approving subscription when the subscription request satisfies the condition value, and rejecting subscription when the subscription request does not satisfy the condition value.

A method of adding a function according to an embodiment includes maintaining information about conditions, condition values, and plug-in classes for a first product as business rules; Receiving information about conditions, condition values, and plug-in classes for a second product; storing information about conditions, condition values, and plug-in classes for the second product in the business rules; and upon receiving a subscription request for the second product, processing the subscription request based on conditions, condition values, and information about the plug-in class for the second product, and the first product is an existing product. And the second product may be a newly released product.

Processing the subscription request may include approving the subscription request if the subscription request satisfies all conditions for the second product, condition values, and information about the plug-in class.

A device according to an embodiment includes a processor and a memory connected to the processor, the memory is configured to store a program, and the processor is configured to execute the program. When the program is executed, the method described above is performed. Steps may be implemented.

A computer program recorded on a computer-readable storage medium according to one embodiment can cause the computer to execute the steps of the above-described method when the computer program is executed on a computer.

The financial system provided in the present invention does not change the existing system by using the plug-in function even if changes occur such as new or revised fintech-related laws or the addition of new products, and there is no need to perform regression testing. There is.

1 is a schematic block diagram of a financial system according to one embodiment.
Figure 2 is a diagram for explaining the operation of a banking system according to an embodiment.
Figure 3 is a flowchart for explaining the operation of a banking system according to an embodiment.
Figure 4 is a flowchart for explaining the operation of a banking system according to an embodiment.

Specific structural or functional descriptions of the embodiments according to the concept of the present invention disclosed in this specification are merely illustrative for the purpose of explaining the embodiments according to the concept of the present invention. They may be implemented in various forms and are not limited to the embodiments described herein.

Since the embodiments according to the concept of the present invention can make various changes and have various forms, the embodiments will be illustrated in the drawings and described in detail in this specification. However, this is not intended to limit the embodiments according to the concept of the present invention to specific disclosed forms, and includes changes, equivalents, or substitutes included in the spirit and technical scope of the present invention.

Terms such as first or second may be used to describe various components, but the components should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another component, for example, a first component may be named a second component, without departing from the scope of rights according to the concept of the present invention, Similarly, the second component may also be referred to as the first component.

When a component is said to be "connected" or "connected" to another component, it is understood that it may be directly connected to or connected to the other component, but that other components may exist in between. It should be. On the other hand, when it is mentioned that a component is “directly connected” or “directly connected” to another component, it should be understood that there are no other components in between. Expressions that describe the relationship between components, such as “between”, “immediately between” or “directly adjacent to”, should be interpreted similarly.

The terminology used herein is only used to describe specific embodiments and is not intended to limit the invention. Singular expressions include plural expressions unless the context clearly dictates otherwise. In this specification, terms such as "include" or "have" are intended to designate the presence of a described feature, number, step, operation, component, part, or combination thereof, and one or more other features or numbers, It should be understood that this does not exclude in advance the possibility of the presence or addition of steps, operations, components, parts, or combinations thereof.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the technical field to which the present invention pertains. Terms as defined in commonly used dictionaries should be interpreted as having meanings consistent with the meanings they have in the context of the related technology, and unless clearly defined in this specification, should not be interpreted in an idealized or overly formal sense. No.

Hereinafter, embodiments will be described in detail with reference to the attached drawings. However, the scope of the patent application is not limited or limited by these examples. The same reference numerals in each drawing indicate the same members.

FIG. 1 is a schematic block diagram of a financial system according to an embodiment, and FIG. 2 is a diagram for explaining the operation of a banking system according to an embodiment.

Referring to FIG. 1 , the financial system 10 may include a first electronic device 100, a server 200, and a second electronic device 300. The financial system 10 is a platform that provides a seamless user experience (UX) and can operate so that contracts between customers and sellers are smoothly completed.

The first electronic device 100 can communicate with the server 200. The first electronic device 100 may be an electronic device used by a customer. For example, a customer may communicate with the server 200 through a browser, application, program, etc. of the first electronic device 100. The second electronic device 300 may be an electronic device used by a seller. The seller may communicate with the server 200 through a browser, application, program, etc. of the second electronic device 300. The first electronic device 100 and the second electronic device 300 may communicate through the server 200. That is, the seller and the customer can conclude a contract using at least one of the first electronic device 100, the server 200, and the second electronic device 300.

The first electronic device 100 and the second electronic device 300 may each be a personal computer (PC) or a portable electronic device having a display. Here, the portable electronic device includes a laptop computer, a mobile phone, a smart phone, a tablet PC, a mobile internet device (MID), a personal digital assistant (PDA), and an enterprise electronic device (EDA). It may be implemented as a wearable device such as a digital assistant, a smart watch, or a smart wrist band.

The server 200 communicates with the first electronic device 100 or the second electronic device 300 using a network, which is a connection structure that allows information exchange between nodes such as a plurality of devices and servers. , Examples of such networks include RF, 3rd Generation Partnership Project (3GPP) network, Long Term Evolution (LTE) network, 5th Generation Partnership Project (5GPP) network, World Interoperability for Microwave Access (WIMAX) network, Internet, LAN (Local Area Network), Wireless LAN (Wireless Local Area Network), WAN (Wide Area Network), PAN (Personal Area Network), VAN (Value Added Network), Bluetooth network, NFC network, satellite broadcasting network, Includes, but is not limited to, analog broadcasting networks, DMB (Digital Multimedia Broadcasting) networks, etc.

When the server 200 receives a request from the first electronic device 100 or the second electronic device 300, the server 200 extracts data from the database and sends it to the first electronic device 100 or the second electronic device 300. You can respond to Additionally, the server 200 may process (eg, calculate) the extracted data and transmit it to the first electronic device 100 or the second electronic device 300.

The server 200 includes a cloud, a router, auth middleware, etc middleware, a rest API, a data pre-processor, and a worker thread ( worker thread), etc.

The server 200 may store the seller's banking system (banking system) 250. Since the banking system 250 performs large-scale, high-capacity calculations, the server 200 can distribute and store the banking system 250 and support the banking system 250 to perform distributed processing.

The seller may use the second electronic device 300 to upload the banking system 250 to the server 200 and provide the banking system 250 to the customer. The banking system 250 may perform services according to requests from the first electronic device 100 or the second electronic device 300.

The banking system 250 may include a plurality of components for performing a contract. For example, the banking system 250 includes customer information management, contract information management, account information management, balance management, transaction history management, interest calculation, fee calculation, product information inquiry and verification, financial work function, accounting standards, and preprocessing function. , may include components that perform functions such as post-processing functions, service performance functions, credit screening functions, and document management. Here, the banking system 250 includes a contract component, and the contract component can check the consistency of product conditions by performing a plug-in condition verification class.

When a new function occurs, the contract component can add a class to handle the new function. New features may arise due to factors such as laws, policies, business practices, and new product launches.

New laws and policies can result in new capabilities such as verification, processing, and reporting. For example, if there is a change in access to customer information and the recording and management of provided information due to the Personal Information Protection Act, the contract component can change the class or add a new class. As another example, if new accounts are limited to multiple accounts within one month to prevent cannon accounts, the contract component can change the class or add a new class.

When business processing rules such as a new interest calculation method or a new fee reduction system occur, the contract component can change the class or add a new class.

Additionally, when a product with a new concept of product condition processing method, such as swing conditions or offset interest calculation, appears, the contract component can change the class or add a new class.

In this way, the banking system 250 changes or adds classes through the contract component when a new function occurs, so the existing system is not changed and regression testing may be unnecessary. Accordingly, the banking system 250 can have reduced response costs, increased response speed, reduced risks due to changes, and improved operation quality.

Referring to Figure 2, banking system 250 may be a configurable and pluggable system. The banking system 250 may receive input, perform decisions and calculations with reference to business parameters and rules, and transmit output. At this time, business parameters and rules may be configurable, and architecture and design patterns used for decisions and calculations may be pluggable.

Plug-in usage functions may include input attribute verification, extension code, service verification, conditional business rules, tax calculation, interest calculation, and balance update.

Input property verification may be an extension to the function for verifying service input items.

The extension code can be a code query function for the catalog ledger.

Service verification may be a common verification rule for each customer or channel for contract-related services.

Conditional business rules may be business processing rules according to product conditions.

Tax calculation may be a tax calculation function to be performed at the time of interest calculation.

Interest calculation may be a class function performed for each interest calculation type at the time of interest calculation.

Balance update may be a function that performs balance update according to the balance type parameter.

A contract may refer to an agreement between a customer and a seller based on a product or service. That is, the contract may include at least one product and/or at least one service. The banking system 250 may have different contract information and different business processing rules (or functions) for different contracts. The banking system 250 can define and manage different classes for each type of a plurality of contracts. Each product or each service may include at least one condition representing business characteristics. For example, conditions may include the age at which subscription is possible, which defines the age range at which subscription is possible for a specific product, whether early withdrawal is possible, (in the case of savings products) the limit of the accumulated amount, the accumulation cycle, etc.

The banking system 250 can perform contracts using a data model and a class model.

Regarding the data model, expansion of the product range (launch of new types of products) should not result in changes to the contract model; All types of contracts should be managed by a single data model; It should be possible to manage additional information without changing the data model.

The data model uses a database and may include a contract model.

A contract model can be designed using Arrangement Basic, Arrangement Conditions, Arrangement Relations, and Others. Here, the contract basic unit can manage common basic information of the contract. Multiple contracts may have common basic information. The contract conditions unit can manage product condition information for the product to be concluded. The contract relationship unit can manage information such as the relationship between the concluded contract, the relationship with the owner of the concluded contract, and the relationship with the accounting department of the concluded contract. Other information units can manage additional information resulting from other business processes.

The contract model allows flexible management of additional information, such as additional information due to the launch of a new product, additional information due to the addition of other tasks, and additional relationship information due to the addition of other areas, and does not involve changes to the model.

In the class model, when a new type of contract is added, there should be no impact on the existing system. Even if management information and processing functions change significantly due to the release of products of different types from existing ones, the class model allows new requirements to be accommodated without affecting the existing system by newly defining and managing contract types for the corresponding types of products. It may be possible.

Contracts managed in the class model can be broadly divided into structural contracts, virtual contracts, and general contracts.

A structural contract is a contract that provides a structure for a specific product, and the contract class can provide the function of providing the information necessary to conclude a specific product. The structural contract may include product condition information, contractual relationship information, contract additional information, etc. required for the new product. This information can be stored in a database as product information and business rule information. For example, relationship information that needs to be managed in a specific product can be registered through the contract relationship information work rules, and information other than the basic contract information that needs to be managed in a specific product can be registered through the contract additional information work rules.

Business rules may include meta-information and service input item verification rules. Meta information may include information about all items used in the banking system 250, such as customer ID, account number, etc. Additionally, meta information may include basic verification information according to each type of information (number, text, code, etc.). Service input item verification rules may include verification rules other than the verification rules provided in meta information for items used in a specific service.

A virtual contract is a contract used to virtually calculate interest rate information to be applied based on customer and product information when a customer signs a specific product, such as interest rate consultation. Information on the consultation time of virtual contracts is not physically loaded into the contract ledger of the database.

An actual contract is a contract that a customer actually uses when concluding a contract for a specific product, and can be defined and managed as several types of contract classes depending on the characteristics of the product. Depending on the product characteristics, the information that must be managed may be different and the business functions that must be processed are different, so classes can be defined according to the type characteristics of the product. The contract type mapped to the product may be stored in the database as business rule information. In other words, the banking system 250 can create an object with a contract class appropriate for the product through business rule information inquiry at the time of actual contract creation.

Additionally, the class model must be able to manage the conditions and contract rule information of different products without changing the system. For example, when a new product is launched, in the class model, a product condition rule that defines a new class for the new condition rule; Extended property rules that define new classes when new extended properties are treated with new handling rules; When a service needs to handle a new condition rule, the developer plugs in a new class for the new condition rule; Contractual relationship rules that define the type of contractual relationship to be handled by the product; Contractual relationship rules that define the types of relationships to be handled between contracts by the product; and contract product rules that define the contract type by product (e.g., normal, transactional, etc.).

A seller may sell financial products or financial services to customers through the banking system 250 of the server 200. For example, a financial product may refer to a product that accrues interest among products handled by a seller. Received products may incur interest on receipt, and loan products may incur loan interest. Financial services may be services that incur fees. Financial products or financial services may include deposits, savings, loans, transfers, deposits and withdrawals, currency exchange, Automated Teller Machine (ATM), issuance of certificates, guarantees, trade finance, etc. That is, the seller may be a commercial bank, national bank, local bank, internet bank, savings bank, securities company, insurance company, credit card company, capital, cooperative, fund management company, or asset management company.

A customer and a seller may enter into a contract using at least one of the first electronic device 100, the server 200, and the second electronic device 300. Customers and sellers can enter into contracts face-to-face or non-face-to-face. For example, in the case of a face-to-face contract, the customer can visit the branch where the seller is located and conclude the contract. The seller may use the second electronic device 300 to access the banking system 250 of the server 200 and process a contract. In the case of a non-face-to-face contract, the customer can use the first electronic device 100 to access the banking system 250 of the server 200 and process the contract without having to face the seller.

If a failure occurs during the contract, the server 200 can transfer the contract to another backup (back-up) server. Disruption can refer to hardware failure or software failure caused by reasons such as fire or war. The backup server can directly take over and perform the work of the server 200. Accordingly, the financial system 10 can provide continuous UX to customers and sellers. The backup server may be placed in a physically different location from the server 200.

Figure 3 is a flowchart for explaining the operation of a banking system according to an embodiment.

Referring to FIG. 3, the banking system 250 may receive a subscription request (S310). The subscription request may be a subscription request for a product or service transmitted from the first electronic device 100 or the second electronic device 300.

The banking system 250 can check the conditions to be verified through business rules according to the subscription request (S320). That is, the banking system 250 can check the list of conditions that require verification in the product or service for which a subscription request has been received. There may be more than one condition that requires verification, and may include age for subscription, number of seats for subscription, etc.

The banking system 250 can check the plug-in class name corresponding to the verification target condition through the business rule and create a plug-in class object (S330). Business rules may include mapping information of conditions and plug-in classes corresponding to the conditions. The banking system 250 may create a plug-in class object based on mapping information. A plug-in class object may be an object for verifying whether a condition is met.

The banking system 250 may perform plug-in class verification (S340). In other words, the plug-in class object can determine whether the customer satisfies the condition.

Below, the operation of the banking system 250 will be described using a specific situation as an example.

As shown in Table 1, Ordinary Deposit A product and Ordinary Deposit B product have the same product conditions (i.e., verified with the same plug-in class), but may have different product condition values.

Ordinary Deposit A product and Ordinary Deposit B product can have the same condition R0001 and condition N0001. Here, condition R0001 may indicate the age at which subscription is possible, and condition N0001 may indicate the number of seats available for subscription. In other words, for Ordinary Deposit A product, the subscription age is limited to 18 to 30 years old and one account per person, while for Ordinary Deposit B product, there is no age limit for subscription (0 to 999 years old) and up to two accounts per person are possible. You can.

Business rules may include a list of conditions that must be verified when signing up for a product, such as condition R0001 and condition N0001. Additionally, the business rule may further include plug-in mapping information corresponding to these conditions. For example, the business rule may include condition R0001 and mapping information of a plug-in class that verifies whether a product can be subscribed to according to the age of the subscribed customer. The business rule may include condition N0001 and mapping information of a plug-in class that verifies the number of subscription accounts for the corresponding product by a subscribed customer.

As an example, the banking system 250 may receive a request from customer A, aged 37, that he or she wants to subscribe to the general deposit A product (S310). The banking system 250 can check the verification target conditions R0001 and N0001 by referring to the business rules for the ordinary deposit A product (320). The banking system 250 may check the plug-in class name corresponding to the verification target conditions R0001 and N0001 and create a plug-in class object by referring to the mapping information of the business rule (S330). The banking system 250 may perform plug-in class verification (S340). That is, in relation to condition R0001, the banking system 250 can check the age information of customer A to confirm that he is 37 years old, and determine whether it is included in the condition value of the general deposit A product. The banking system 250 may determine that since customer A is 37 years old, it is not included in the condition value (18 to 30) of the product. In relation to condition N0001, the banking system 250 can check the number of times Customer A has subscribed to this product, confirm that it is the first subscription (0 times), and determine that it is less than the product's condition value (1). The banking system 250 may reject Customer A's request to sign up for Ordinary Deposit A because Customer A satisfied condition N0001 but did not meet condition R0001.

As another example, the banking system 250 may receive a request from customer A, who is 37 years old, to subscribe to general deposit product B. The banking system 250 can check the verification target conditions R0001 and N0001. The banking system 250 may check the plug-in class name corresponding to the verification target conditions R0001 and N0001 and create a plug-in class object by referring to the mapping information of the business rule (S330). The banking system 250 may perform plug-in class verification (S340). That is, in relation to condition R0001, the banking system 250 can check the age information of customer A to confirm that he is 37 years old, and determine whether it is included in the condition value of the general deposit A product. The banking system 250 may determine that Customer A is included in the condition value (0 to 999) of the product because his or her age is 37 years old. In relation to condition N0001, the banking system 250 can check the number of times Customer A has subscribed to this product, confirm that it is the first subscription (0 times), and determine that it is less than the condition value (2) of the product. The banking system 250 may approve Customer A's request to subscribe to Ordinary Deposit B because Customer A satisfies condition N0001 and Condition R0001.

In other words, it can be seen that although the ordinary deposit A product and the ordinary deposit B product have the same product conditions, the banking system 250 outputs different verification results due to differences in product condition values.

In this situation, the Ordinary Deposit C product may be released with the same conditions as the Ordinary Deposit B product but with the addition of a new condition, L0001. Ordinary Deposit B products and Ordinary Deposit C products may include product conditions as shown in Table 2.

In other words, there is no age limit for regular deposit B products (0 to 999 years old), and up to two accounts per person can be used. The Ordinary Deposit C product has no age limit for subscription (0 to 999 years old), allows up to 2 accounts per person, and is a product that requires a cost price, so the cost date can be “Friday of the last week of March, June, and September” . In other words, the Ordinary Deposit C product may further include condition L0001, which is the cost base date.

The banking system 250 may add subscription service verification target condition L0001 to the business rule. Additionally, the banking system 250 may add mapping information of the plug-in class corresponding to condition L0001 to the business rule. The plug-in class corresponding to condition L0001 can calculate the cost date and register it as a plan.

This time, the banking system 250 may receive a request from customer A, who is 37 years old, to subscribe to the regular deposit C product. The banking system 250 can check the verification target conditions R0001, N0001, and L0001. The banking system 250 may check the plug-in class name corresponding to the verification target conditions R0001, N0001, and L0001 and create a plug-in class object by referring to the mapping information of the business rule (S330). The banking system 250 may perform plug-in class verification (S340). That is, in relation to condition R0001, the banking system 250 can check customer A's age information to confirm that he is 37 years old, and determine whether it is included in the condition value of ordinary deposit C product. The banking system 250 may determine that Customer A is included in the condition value (0 to 999) of the product because his or her age is 37 years old. In relation to condition N0001, the banking system 250 can check the number of times Customer A has subscribed to this product, confirm that it is the first subscription (0 times), and determine that it is less than the condition value (2) of the product. Regarding condition L0001, the banking system 250 can query the condition value “Friday of the last week of March, June, and September” to calculate the next cost date and then register it in the account. The banking system 250 can approve Customer A's request to subscribe to Ordinary Deposit C because Customer A satisfies condition N0001, condition R0001, and has also processed condition L0001.

In other words, even if a product with additional conditions for the existing ordinary deposit B product is released, the banking system 250 can perform functions for the new product by adding only conditions, condition values, and mapping information without changing the existing system. .

Figure 4 is a flowchart for explaining the operation of a banking system according to an embodiment.

Referring to FIG. 4, the banking system 250 may maintain information about the first product (S410). Information about the first product may include information about the condition, condition value, and plug-in class for the first product. The banking system 250 may maintain information about the first product as business rules. The first product may represent an existing product. That is, information about existing products may be stored in the business rules of the banking system 250.

The banking system 250 may receive information about the second product (S420). Information about the second product may include information about conditions, condition values, and plug-in classes for the second product. The second product may be a newly released product.

The banking system 250 may store information about the second product (S430). For example, banking system 250 may plug in information about a second product. That is, the banking system 250 may create a plug-in class to perform verification for the second product, and add conditions and condition values for the second product and mapping information for the plug-in class to the business rule.

When the banking system 250 receives a subscription request for a second product, it may process the subscription request based on information about the second product (S440). Specifically, if the subscription request for the second product satisfies all of the conditions, condition values, and information about the plug-in class for the second product, the banking system 250 may approve the subscription request. If the subscription request for the second product does not meet any one of the conditions, condition values, and information about the plug-in class for the second product, the banking system 250 may reject the subscription request.

The device described above may be implemented with hardware components, software components, and/or a combination of hardware components and software components. For example, devices and components described in embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), etc. , may be implemented using one or more general-purpose or special-purpose computers, such as a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. A processing device may execute an operating system (OS) and one or more software applications that run on the operating system. Additionally, a processing device may access, store, manipulate, process, and generate data in response to the execution of software. For ease of understanding, a single processing device may be described as being used; however, those skilled in the art will understand that a processing device includes multiple processing elements and/or multiple types of processing elements. It can be seen that it may include. For example, a processing device may include multiple processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are possible.

Software may include a computer program, code, instructions, or a combination of one or more of these, which may configure a processing unit to operate as desired, or may be processed independently or collectively. You can command the device. Software and/or data may be used on any type of machine, component, physical device, virtual equipment, computer storage medium or device to be interpreted by or to provide instructions or data to a processing device. , or may be permanently or temporarily embodied in a transmitted signal wave. Software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., singly or in combination. Program instructions recorded on the medium may be specially designed and configured for the embodiment or may be known and usable by those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. -Includes optical media (magneto-optical media) and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. Examples of program instructions include machine language code, such as that produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

As described above, although the embodiments have been described with limited examples and drawings, various modifications and variations can be made by those skilled in the art from the above description. For example, the described techniques are performed in a different order than the described method, and/or components of the described system, structure, device, circuit, etc. are combined or combined in a different form than the described method, or other components are used. Alternatively, appropriate results may be achieved even if substituted or substituted by an equivalent.

Therefore, other implementations, other embodiments, and equivalents of the claims also fall within the scope of the following claims.

Claims (9)

Receiving a subscription request for a product;
Confirming conditions according to the subscription request from business rules;
Confirming a plug-in class corresponding to the condition from the business rule;
creating an object for the plug-in class; and
performing verification of the condition through an object for the plug-in class;
How to handle subscription requests, including. According to paragraph 1,
The above product is a newly released product,
The conditions for the product and the plug-in class corresponding to the conditions are plugged into the business rules,
How to process subscription requests. According to paragraph 1,
The above conditions are:
Including age available for subscription, number of seats available for subscription, and cost base date,
How to process subscription requests. According to paragraph 1,
The above business rules are:
Containing mapping information for the conditions and the plug-in class,
How to process subscription requests. According to paragraph 1,
The step of performing the verification is,
Confirming a condition value for the condition from the business rule;
determining whether the subscription request satisfies the condition value; and
approving subscription if the subscription request satisfies the condition value, and rejecting subscription if the subscription request does not meet the condition value;
Method for processing subscription requests, including. maintaining information about conditions, condition values, and plug-in classes for the first product as business rules;
Receiving information about conditions, condition values, and plug-in classes for a second product;
storing information about conditions, condition values, and plug-in classes for the second product in the business rules; and
Upon receiving a subscription request for the second product, processing the subscription request based on conditions, condition values, and information about the plug-in class for the second product.
Including,
The first product is an existing product, and the second product is a newly released product.
How to add features. According to clause 6,
The step of processing the subscription request is,
Approving the subscription request if the subscription request satisfies all conditions, condition values, and plug-in class information for the second product.
Method for adding features, including . Comprising a processor and a memory connected to the processor,
The memory is configured to store a program,
the processor is configured to execute the program,
When the program is executed, the steps of the method of any one of claims 1 to 7 are implemented. A computer program recorded on a computer-readable storage medium,
A computer program recorded on a computer-readable storage medium, wherein, when the computer program is executed on a computer, the computer program causes the computer to execute the steps of the method of any one of claims 1 to 7.

Images