Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2001-04-05
2003-03-11
Choules, Jack (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C709S241000
Reexamination Certificate
active
06532465
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates in general to computational systems, i.e., computer-based processing systems implemented in logic including software, hardware and/or firmware. In particular, the present invention relates to computational systems for operating on externally-defined data content or data formats (hereinafter “externally-defined data”), such as records generated in a business environment, based on client-defined rules and metadata. The invention is particularly useful in developing and operating computational systems that are readily adapted to perform various functions in different operating environments, for example, billing programs that can be adapted for different business environments.
BACKGROUND OF THE INVENTION
In many cases, computing systems are required to operate on externally-defined data, e.g., business information, market information, scientific data, environmental data or other information having a content and/or format determined in relation to external or real world events. The computing systems perform operations on the externally-defined data that are as varied as the data and the environments associated with the data. These operations may depend, in part, on client-based rules, that is, rules defined by the client (e.g., party for whom the computing system was developed, or on whose behalf the computing system is operated) governing processing of the data. Accordingly, the computer systems and the algorithms implemented by the computer systems are typically developed on a case-by-case basis, and are limited to the specific application for which they were developed.
In recent years, programmers have devoted considerable effort to developing programs that are somewhat adaptable to different situations so as to reduce the need to create and reprogram source code. Some examples of such adaptable programming include configurable systems and object oriented programming (OOP). Configurable systems typically allow the user to select from various options, e.g., a menu of options, to customize the system for a given situation. The related configuration files may contain, for example, information regarding specific users, specific computers or specific programs related to the given situation. OOP generally involves programming using objects, i.e., self-contained software modules that can be used as independent building blocks. Each object includes the commands and data required to perform particular functions in response to appropriate messages from other objects or systems. Generally, new objects of a particular class inherit certain characteristics of the existing objects. These objects can be re-used or modified to address varying programming situations thereby reducing the need, in certain cases, to create software routines from scratch.
However, the degree of adaptability that is accommodated by such programming is generally somewhat limited. Configurable systems typically support only customization with respect to selected option types or from pre-programmed option fields. Similarly, objects in OOP can be used and reused as building blocks but generally only within specific operation contexts. As a result, even programmers taking advantage of the adaptability afforded by configurable systems and OOP are generally limited to writing application-specific programs. That is, at some point in such programs within the binary code, the engines that perform the various functions of the program include application-specific elements. Accordingly such engines, although perhaps providing significant adaptability, are application-specific engines and would require substantial code revision to be re-used in other applications.
The case of business software and particularly billing programs, is illustrative. These programs are designed to provide billing information for particular business environments where something is rated and billed. However, the specific business environments are as varied as the companies and industries in which they exist. The differences include, for example, industry-related factors and organization-related factors.
Among other things, industry-related factors may relate to the thing being billed and the format of available business records. By way of example, the thing being billed may be measured in minutes (e.g., of air time, on-line time, worker time spent on a project, etc.), volume or quantity of a material or commodity (cubic feet of natural gas, or kilowatt hours used, number of securities traded, etc.) or in terms of monetary units (size of transaction on which commission, royalty or service fee is due). The usage or other billing information may be provided in an industry standard or proprietary format, e.g., a call detail record or similar record of a telecommunication network. Accordingly, billing programs are generally designed on a case-by-case basis to handle particular types of data and specific data formats.
Organization-related factors relate to various billing rules that are specific to an organization or client. Examples include: billing rates that vary depending on time of day or day of the week; commission structures that vary depending on the type or size of the transaction, volume or commission sharing rules; company rules governing personal versus business expenses; internal bookkeeping rules concerning distribution of expenses and receipts as between departments or other units of an organization, etc. It is thus apparent that billing programs, in addition to addressing data types and data formats that vary from industry-to-industry (or company-to-company), must also address organization-related factors that vary from company-to-company. Similar variations are present in a wide-variety of other programming environments.
In the context of billing programs, companies generally use either an off-the-shelf billing program or have a program custom developed. Unfortunately, off-the-shelf programs generally have a limited ability to address industry-related and organization-related variations such as described above. Some of these available programs include a limited ability to customize user interface screens or billing reports, but the programs generally support only a small number of pre-defined business models corresponding to particular algorithms that are pre-coded into the programs.
Dissatisfied with the limitations of off-the-shelf programs, some companies have had billing programs custom-developed for particular applications so as to support externally-defined data according to client-defined rules. For example, a telecommunications company wishing to develop a billing program for use in billing its customers, might contract with an outside software developer. The developer would spend the time required to understand the data content and data format as received by the company. In the telecommunications industry, such data may be presented in the form of call detail records or similar records generated by a switch operator on a per call basis including, inter alia, time that the call started, time that the call terminated, the phone number called, and caller's phone number, the MIN/ESN or other information identifying the caller to be billed. In addition, the software developer would spend time learning the company's billing rules including different rates based on time of the day and day of the week, different rates depending on the customer's billing plan, different rates depending on the billing zones (e.g., area codes) of the call and variable rating as a function of call duration. Based on all of this information, the developer would then design a billing program, and write specific algorithms into code that take into consideration the relevant data, data formats and billing rules. After a preliminary version of the program is written into code, the code would generally be tested, revised, debugged and otherwise developed, typically during an extensive testing period, until the company had sufficient confidence in the program to implement it in the company's regula
Brown Rodney
Hartley Bruce
Locke Tony
Perkins Tony
Ricotta Frank
Blakely , Sokoloff, Taylor & Zafman LLP
Choules Jack
LandOfFree
Operational system for operating on client defined rules does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Operational system for operating on client defined rules, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Operational system for operating on client defined rules will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3012743