| Communication point relationship scheduling -> Monitor Keywords |
|
|
  Communication point relationship schedulingUSPTO Application #: 20060184586Title: Communication point relationship scheduling Abstract: According to various embodiments of the invention, an architecture is provided for a data processing system. The elements of the architecture can be managed separately. For example, the architecture can be organized around eight subject areas, such as account, party, communication point, presentation instrument, rules, balances, transactions, and product. Relationships between each of the subject areas as well as between sub-types of each subject area can be established to provide flexibility in the management of the data. (end of abstract)
Agent: Townsend And Townsend And Crew, LLP - San Francisco, CA, US Inventors: Michael B. Grear, Gretchen L. Donlin, Margaret Ann Henry-Saal, Patricia L. Melanson USPTO Applicaton #: 20060184586 - Class: 707200000 (USPTO) Related Patent Categories: Data Processing: Database And File Management Or Data Structures, File Or Database Maintenance The Patent Description & Claims data below is from USPTO Patent Application 20060184586. Brief Patent Description - Full Patent Description - Patent Application Claims
CROSS-REFERENCES TO RELATED APPLICATIONS [0001] This application is a continuation-in-part of U.S. patent application Ser. No. 10/972,172, filed on Oct. 22, 2004, entitled "System For Maintaining Communication Point Data," a continuation-in-part of U.S. patent application Ser. No. 10/971,831, filed on Oct. 22, 2004, entitled "System For Maintaining Party And Communication Point Data," and a continuation-in-part of U.S. patent application Ser. No. 10/972,093, filed on Oct. 22, 2004, entitled "System For Maintaining Party Data." This application also claims the benefit under 35 USC .sctn. 119(e) of U.S. Patent Application No. 60/547,651, filed on Feb. 24, 2004, entitled "System And Method For Transaction Processing," as well as the benefit under 35 USC .sctn. 119(e) of U.S. Patent Application No. 60/567,891, filed May 3, 2004, entitled "System And Method For Transaction Processing." [0002] This application is related to the following U.S. patent applications: U.S. patent application Ser. No. ______, filed on a date even herewith by Grear et al., Attorney Docket Number 020375-048850US, entitled "Communication Point Bulk Mail," and U.S. patent application Ser. No. ______, filed on a date even herewith by Grear et al., Attorney Docket Number 020375-048860US, entitled "Communication Point Delivery Instructions." This application hereby incorporates by reference herein the content of each of the aforementioned applications in their entirety and for all purposes. FIELD OF THE INVENTION [0003] Embodiments of the invention relate generally to systems managing certain types of Databases, and more particularly the structure and configuration of such Databases. BACKGROUND [0004] Credit card transaction management and administration is an example of a processing system that has traditionally relied on storing a great deal of information with a single identifier used as a reference. For example, a credit card account typically includes information about the customer, the account, the billing address, the formal transaction information, and the credit card and physical credit card characteristics. All of this is handled from the perspective of a single account, so that the credit card company can track transactions for a particular customer. Thus, this results in a very static data processing system that is inflexible which makes it difficult to effect changes as the business it services evolves. Furthermore, the handling of this information is typically specific to a particular line of business within an industry such as a revolving credit product for the financial services industry. It is not readily aligned with a totally different service model, such as one's utility billing system, insurance claim payment processing system, phone billing system, or cable billing system. [0005] Thus, a third party which handles the processing of transactions for a variety of different industries or services must create independent systems for handling each service's transactions. There currently appears to be no unique system which is capable of flexibly handling different types of services, such as credit card processing, healthcare claim payment, and utility bill processing, in the same processing system. Again, the static and inflexible nature of the current processing systems prevent this. [0006] In addition, because the account information, party information, communication point information and presentation instrument information for a credit card system, for example, is referenced by a single identifier, it is quite difficult, if not impossible, under present systems, to manage the individual areas of account information, party information, communication point information or presentation instrument as independent data. Once again, the inflexible nature of a single reference to the data prevents this from happening. [0007] As another example of the inflexibility of current systems, it is not easy to modify existing systems to add multiple parties and the requisite roles they play to an account and utilize multiple presentation instruments for access to that account. Again, this is difficult due to the fact that once an account is created under the static formatting of a particular account--such as the formatting of a Mastercard Gold Card with a single customer--it is extremely difficult to modify that record to reflect change--such as a second party, playing a previously unsupported role, on the account--without restructuring the processing system (underlying data structures and program code). [0008] Another example of the inflexibility of credit card systems is that customers are typically prevented from playing dual roles in an account, such as the role of guarantor and authorized user. Instead, the credit card account is typically configured to identify one party as the authorized user and a different party as the guarantor. Once again, this prevents the flexibility that might be desired in certain circumstances. [0009] Yet another example of the rigidity of current systems is that, for products offered by a bank, for example, which offers different credit card lines as well as brokerage accounts and mortgages, each of those individual accounts is typically processed separately, under separate systems. It is not possible to easily combine those systems at a later point in time under a master account which could be tailored to the services desired by a particular customer. [0010] As yet another example, the static nature of current systems makes it difficult, if not impossible, to modify the mailing contact points for an individual during different times of the year. For example, a credit card statement is typically mailed to a home residence of the customer who is financially responsible for the account. Current systems do not provide the flexibility to allow a customer to designate varying locations during the year to which statements should be sent. This is due to the fact that only a single address is currently associated with a credit card account, for example, without the flexibility to designate different contact points throughout the year. To include such information would require a complete reworking of the credit card processing system because the credit card processing system operates by referring to all account information using a single reference identifier. [0011] Thus, as can be seen from the above examples, current processing systems for service industries are typically configured in a static and inflexible way so as to effectively prevent the efficient management of information for an account. Other examples addressed by present embodiments of the invention will be apparent from the following specification. [0012] Thus, there is a need for a data processing system which can handle the processing of data for service industries in a more flexible manner. For example, there is a need for a data processing system and requisite data architecture that can easily adapt to changing business requirements and is not tightly coupled with a specific aspect of any one service or any one industry. SUMMARY [0013] According to various embodiments of the invention, a method of storing data for communicating with a party based on a defined relationship is described. Data is stored which identifies one or more communication points, each point stored as a separate set of data. Data is stored which identifies one or more parties, each party stored as a separate set of data. A set of party data is linked with a set of communication point data, using a link. A relationship between the party and the communication point is defined, and the relationship is associated with the link for a specified period of time. The relationship may be home, work, employer, branch, headquarter, department, vacation, or return address. [0014] The set of party data may be associated with other sets of communication point data, using other links. Similarly, the set of communication point data may be associated with other sets of party data, using other links. Various relationships may be associated with each other link. A relationship may be associated with a link for a specified, or recurring, period of time. The period of time may be indefinite, as well. Different identifiers may also be used to identify and link the sets of party, communication point, and account data. The identifiers may also be stored independently. [0015] Other embodiments include a system of storing data for communicating with a party over different time periods. The system includes a communication point database for storing data identifying a number of communication points, each communication point stored separately. A party database stores a set of data identifying a party. A first link defines a first relationship between the party and a first communication point, and a second link defines a relationship between the party and a second communication point. The first link and the second link are stored separately from each other, and separately from the communication point database and party database. The links may be further associated with an account from a separate account database. Again, different identifiers may also be used to identify and link the sets of party, communication point, and account data. The identifiers may also be stored independently. BRIEF DESCRIPTION OF THE DRAWINGS [0016] FIG. 1A is a block diagram illustrating the architecture of a data processing system for managing service industry data according to one embodiment of the invention. [0017] FIG. 1B illustrates a data processing system for implementing the architecture shown in FIG. 1A. [0018] FIG. 1C illustrates a block diagram of a computing system for implementing any of the computer processing systems in the embodiments of the invention described herein. [0019] FIGS. 2A and 2B illustrate a flowchart for implementing a method of processing data for a service business according to one embodiment of the invention. Continue reading... Full patent description for Communication point relationship scheduling Brief Patent Description - Full Patent Description - Patent Application Claims Click on the above for other options relating to this Communication point relationship scheduling patent application. ###  How KEYWORD MONITOR works... a FREE service from FreshPatents1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored. 3. Each week you receive an email with patent applications related to your keywords. Start now! - Receive info on patent apps like Communication point relationship scheduling or other areas of interest. ### Previous Patent Application: Communication point delivery instructions Next Patent Application: Contact merge auto-suggest Industry Class: Data processing: database and file management or data structures ### FreshPatents.com Support Thank you for viewing the Communication point relationship scheduling patent info. IP-related news and info Results in 1.04415 seconds Other interesting Feshpatents.com categories: Qualcomm , Schering-Plough , Schlumberger , Seagate , Siemens , Texas Instruments , |
||
