Manipulating and analyzing data using a computer system having a database mining engine resides in memory6029176Abstract According to a preferred embodiment of the present invention, a method and apparatus for quickly and easily retrieving, manipulating and analyzing large quantities of computer-based data relevant to television-viewing consumers is disclosed. The most preferred embodiment of the present invention is a computer-based decision support system that includes three main components: a data conversion mechanism; a database mining engine (DME) in conjunction with a customized database; and a customized user interface that provides access to the various features associated with the system. In addition, the various preferred embodiments of the present invention are available for use with any standard personal computer, making the system available to a much larger group of decision-making executives than ever before possible. The user interface, in conjunction with the DME, provides a unique and innovative way to store, retrieve and manipulate data. Claims I claim: Description BACKGROUND OF THE INVENTION
______________________________________
00529705129705139705149705159705169705179705180970512097
051309705140970515097051609705170970518
______________________________________
This calendar record indicates that the week of data included in the data set begins on May 12, 1997 and ends on May 18, 1997. Classification data record (record type 1). The classification data record describes each household in the sample in terms of income, education of the head of the household, time zone, etc. This record also specifies the age and gender of each household member and visitors to the household during the week. The Nielsen data file typically includes 5000 records per week. Example:
______________________________________
100040520200034117248342520222222213109605305
A01Q02Y03J04A00
______________________________________
The classification data record shown above describes household number 200034. It indicates that the household was added to the Nielsen sample on the 53.sup.rd day of 1996, that the household was in-tab for all seven days of the week, and that the household for the week includes four household members and one visitor. Each household data item in each classification record will be translated to binary form. The income indicator "5" in the record above, for example, is translated to the binary number "00100000." Similarly, the age and gender data for each person in the record is also translated to binary form and assigned to the corresponding attribute in an object created for the person. Program data lead record (record type 2). The program data lead record describes each quarter hour of programming broadcast during the week including program name, episode name, air date and time, program genre, etc. Typically, 1500 program data records are used to describe all programming broadcast in a given week. Example:
______________________________________
20453 1890800003020SEINF 052501SEINFELD2100NCS09480128599
______________________________________
The sample program data lead record shown above indicates, among other things, that the Seinfeld show airs on NBC at 2100 hours (9:00 PM), it's a situation comedy, and that the program run length is 30 minutes. Dates, times, and quarter hour values in the program data item are converted from an ASCII representation as shown above to a binary representation, and assigned to corresponding attributes in a program object. Program data continuation record (record type 3). Specifies those households and household members who were logged as viewing each quarter hour of network programming broadcast during the week as described by the program data lead record. There are 50,000 program data continuation records supplied in the Nielsen data per week. Example:
______________________________________
3045302000340000200034Y0302000740000200074X010200074I
020200251000200251T0102003410000200341M0102003820000200382X
010200382P02
______________________________________
This record indicates some of the households and people who were watching Seinfeld at 9:00 PM on NBC. As indicated by the 10 character string "200034000" (the "viewing event string") in the record, one of the households was number 200034. In that household, as indicated by a 10 character "200034Y03" viewing event string in the record, person number Y03 was also watching the program. Usage data lead record (record type 4). The usage data lead record identifies by sequence number each quarter hour during the broadcast week. There are 672 records per week contained in the Nielsen data files. Example: 400660205222200274804115 This usage data lead record assigns the sequence number 0066 to the quarter hour which begins at 10:00 PM on the 2.sup.nd day of the week (Monday). 2,748 households in the sample were using their televisions at that time, and 4,115 people were watching television in those households. The date/time in each usage data lead record is noted and used in reading each subsequent usage data continuation record. Usage data continuation record (record type 5). Specifies those households and household members who were logged as using the television during each quarter hour as noted by the usage data lead records. There are 200,000 usage data continuation records per week supplied in the Nielsen data files. Example:
______________________________________
5006602000340000200034Y030200034J0402000830000200083W
010200105000200105W010200105I0202002010000200201I
0402002510000200251U02
______________________________________
This usage data continuation record identifies some of the 2,748 households and 4,115 people in the sample who were watching television on the 2.sup.nd day of the week at 10:00 PM. One of the households was number 200034, as indicated by the 10 character viewing event string "200034000" in the record. In that household, person number Y03 was watching, as indicated by a 10 character "200034Y03" viewing event string in the record. The specific program being watched is not specified. It may have been a network program. Alternatively, it may also have been a cable channel or a broadcasting station unaffiliated with one of the networks. Two separate records are used to describe television viewing in the Nielsen data files, a program data record and a usage record. The program data record indicates all those persons and households in the sample who viewed a particular network program. Viewing of non-network programming is not indicated in the "program data" record. The "usage" record indicates television usage by person and household. With this data, to find all instances where sample members watched non-network programming, those instances in which the program data indicates the household members were watching network programming must be subtracted from the usage entries. The usage entries remaining after this subtraction are the non-network viewing entries. 2. Definitions Homes Base. Home base is defined as the total number of homes in the United States with one or more television sets. Approximately 95 million homes fall into this category. This figure, on a percentage basis, includes more than 98% of all homes. Prime Time. The federal government defines prime time as those evening hours during which the television networks are allowed to broadcast their programming. These hours are from 7:00 PM to 11:00 PM on Sunday, and from 8:00 PM to 11:00 PM otherwise. Households Using Television (HUTS). HUTS is the total number of homes with televisions turned on at a given time. During prime time this number is often over 60 million. The percentage of all homes with television sets which had those sets turned on is referred to as "percent HUTS" or "HUT rating." If the homes base was 95 million and HUTS was 60 million, then the HUT rating would be HUT rating=homes watching television/homes with television=60 million/95 million=63.2% HUTS. This value is consistently referred to as simply HUTS rather than percent HUTS or HUT rating. True HUTS (in millions of homes) is rarely used. This convention is adopted herein as well. In every case where the term "HUTS" is used, this will actually refer to HUT rating. HUT levels typically peak at over 60% during prime time and can be less than 20% between 7:00 and 10:00 a.m. during the summer. HUTS typically bottoms out at about 4:00 a.m. on weekdays at about 7%. Household Rating. Household rating is defined as the portion of all homes having televisions sets which had those sets tuned to a particular show. Thus if we assume that there are 95 million televisions in the nation and 15 million are tuned to a particular show then
______________________________________
rating = homes watching a show/homes base
= 15 million/95 million
= 15.8%
______________________________________
Demographic rating is similar to household rating, but is calculated using the number of people in a particular demographic group who saw the show divided by the number of people in the population for that demographic group. Share. Share is defined as the portion of homes with television sets on which were tuned to a particular show. If 60 million homes had televisions turned on, as in the example above, and 15 million were watching a particular show, then share=homes watching a show/homes watching television =15 million/60 million=25% Rating and share are related through HUTS. rating=HUTS.times.share=63.2%.times.25%=15.8% Homes Delivered. Advertising effectiveness is sometimes based on homes delivered to an advertiser. This value is defined as the rating for a show multiplied by the total number of homes with television sets. The homes delivered for a show with a 15.8% rating would be
______________________________________
homes delivered = homes base .times. rating
= 95 million .times. 15.8%
= 15.0 million
______________________________________
This is equivalent to the total number of homes with their television sets turned on multiplied by the share. Assuming that 60 million homes were watching the show
______________________________________
homes delivered
= homes base .times. HUTS .times. share
= 95 million .times. 63.2% .times. 25%
= 15.0 million
______________________________________
Special rules defined by Nielsen apply for computing these types of household-based measurements for households with multiple television sets during those times when the television sets in the household arc tuned to different channels. See Nielsen Media Research [1994] for a detailed description of these rules. Viewers Per Viewing Household (VPH). VPH is defined as the number of viewers of television averaged over all households watching television and varies by half-hour and by show. Some shows tend to have larger groups of people watching than other shows. This number by definition is never less than one, and is rarely over two. Impressions. Advertisers often speak in terms of impressions. An impression is defined as one person viewing either one show or one advertisement one time. It can be calculated using homes delivered and VPH. Assuming that for a particular show, the average number of people watching per home is two, then impressions is the product of homes delivered and VPH.
______________________________________
impressions
= homes delivered .times. VPH
= homes base .times. rating .times. VPH
= 95 million .times. 15.8% .times. 2 = 30.0
______________________________________
million
3. Detailed Description As explained above, a computer-based system 100 according to a preferred embodiment of the present invention includes three main components: a database mining engine (DME) in conjunction with a DME database; and a user interface which controls the system and allows a user to manipulate and analyze the data in the DME database by using the DME. Taken together, these components offer a powerful tool for manipulating and analyzing Nielsen viewer data for decision-making purposes. Further, since the various embodiments of the present invention are designed to be used in a computer-based environment, a suitable computer system is necessarily a part of the present invention. Each of these main components will now be described in greater detail. Computer System Referring now to FIG. 1, a computer-based system 100 for data manipulation and analysis in accordance with a preferred embodiment of the present invention includes an IBM PC compatible computer. However, those skilled in the art will appreciate that the methods and apparatus of the present invention apply equally to any computer system, regardless of whether the computer system is a complicated multi-user computing apparatus or a single user device such as a personal computer or workstation. Computer system 100 suitably comprises a Central Processing Unit (CPU or processor 110), main memory 120, a memory controller 130, an auxiliary storage interface 140, and a terminal interface 150, all of which are interconnected via a system bus 160. Note that various modifications, additions, or deletions may be made to computer system 100 illustrated in FIG. 1 within the scope of the present invention such as the addition of cache memory or other peripheral devices. FIG. 1 is presented to simply illustrate some of the salient features of computer system 100. Those skilled in the art will recognize that there are many possible computer systems which will be suitable for use with the present invention. Processor 110 performs computation and control functions of computer system 100, and comprises a suitable central processing unit (CPU). Processor 110 may comprise a single integrated circuit, such as a microprocessor, or may comprise any suitable number of integrated circuit devices and/or circuit boards working in cooperation to accomplish the functions of a processor. Processor 110 suitably executes an object-oriented computer program 122 within main memory 120. Auxiliary storage interface 140 allows computer system 100 to store and retrieve information from auxiliary storage devices, such as magnetic disk (e.g., hard disks or floppy diskettes) or optical storage devices (e.g., CD-ROM). One suitable storage device is a direct access storage device (DASD) 170. As shown in FIG. 1, DASD 170 may be a floppy disk drive which may read programs and data from a floppy disk 180. It is important to note that while the present invention has been (and will continue to be) described in the context of a fully functional computer system, those skilled in the art will appreciate that the mechanisms of the present invention are capable of being distributed as a program product in a variety of forms, and that the present invention applies equally regardless of the particular type of signal bearing media to actually carry out the distribution. Examples of signal bearing media include: recordable type media such as floppy disks (e.g., disk 180) and CD ROMS, and transmission type media such as digital and analog communication links, including wireless communication links. Memory controller 130, through use of a processor (not shown) separate from processor 110, is responsible for moving requested information from main memory 120 and/or through auxiliary storage interface 140 to processor 110. While memory controller 130 is shown as a separate entity for purposes of explanation, those skilled in the art understand that, in practice, portions of the function provided by memory controller 130 may actually reside in the circuitry associated with processor 110, main memory 120, and/or auxiliary storage interface 140. Terminal interface 150 allows system administrators and computer programmers to communicate with computer system 100, normally through programmable workstations. Although the system 100 depicted in FIG. 1 contains only a single main processor 110 and a single system bus 160, it should be understood that the present invention applies equally to computer systems having multiple processors and multiple system buses. Similarly, although the system bus 160 of the preferred embodiment is a typical hardwired, multidrop bus, any connection means that supports bi-directional communication in a computer-related environment could be used. Main memory 120 suitably contains an operating system 122, a graphical user interface 125, a Database Mining Engine (DME) database 126, a Database Mining Engine (DME) 127, and a data conversion mechanism 128. Operating system 122 in memory 120 is used to control the functional operation of system 100. Graphical user interface 125 in memory 120 provides access for a user of system 100, allowing the user to access the various features of system 100. DME database 126 is a customized version of a previously created database that is optimized for access by DME 127 via graphical user interface 125. DME 127 is a specialized database management system (DBMS) which is optimized to search, manipulate, and analyze person-by-person records in a database format. DME 127 uses a set of filters to access the data contained in DME database 126 to formulate responses to queries from a user of system 100. Although shown as separate components for this example, the various components shown in memory 120 may alternatively be individual parts of a single software program. The various components loaded into memory 120 are typically loaded into memory 120 from a secondary storage location such as DASD 170. The term "memory" as used herein refers to any storage location in the virtual memory space of system 100. It should be understood that main memory 120 does not necessarily contain all parts of all mechanisms shown. For example, portions of operating system 122 may be loaded into an instruction cache (not shown) for processor 110 to execute, while other files may well be stored on magnetic or optical disk storage devices (not shown). In addition, although Database Mining Engine (DME) 127 is shown to reside in the same memory location as DME database 126 and operating system 122, it is to be understood that main memory 120 may consist of multiple disparate memory locations (e.g. backside cache, look-aside cache, etc.). 1. Introduction The following section describes some of the most salient features of DME database 126, DME 127, and the associated techniques and tools used in preparing the Nielsen television-related viewing data (Nielsen data) for use in system 100. In order to more quickly and efficiently process the large volume of data contained in the Nielsen data files, the generally accepted concepts of database design and manipulation so prevalent today must be discarded or modified. This is simply because the various relational and hierarchical database models in use today are too unwieldy for manipulating large data files with any significant speed, absent very specialized and expensive computer hardware. The unique format of DME database 126, combined with the functional aspects of DME 127, overcomes several limitations of conventional database and data processing techniques which tend to reduce the performance of most data analysis systems to unacceptable levels. Although the various preferred embodiments of the present invention are presented and described in the context of television viewing, other types of data may be manipulated and analyzed in a similar fashion. It should be noted that the concepts and techniques of the present invention are equally applicable to tracking and analyzing the behavior of a sample population for visitors to web pages on the World Wide Web. Similarly, information about the readership populations for magazines and newspapers could also be manipulated and analyzed by applying various preferred embodiments of the present invention. Indeed, any advertising firm/agency, business, or other organization that wishes to track large quantities of information regarding various sample populations can successfully implement the various techniques and methods described herein. A system 100 according to various preferred embodiments of the present invention has the following significant advantages: the ability to add, on a weekly basis, large quantities of data to the existing user databases; a way to easily move relevant portions of existing databases from location to location (such as from a central server to a laptop computer); the ability to retrieve large blocks of data from the database, organize the data in memory, and analyze the data; the ability to filter the data according to user selected demographic criteria; and retrieve information for the same sample members across multiple weeks. The various capabilities listed above are a direct product of the unique design of DME database 126 and the techniques associated with manipulating the data contained in DME database 126. The design of D)ME database 126 is performance driven and, for at least one preferred embodiment, is specifically designed to efficiently access the Nielsen data. Using most standard computers, the performance of a general purpose DBMS will typically be inadequate for interactive analysis when manipulating the hundreds of Mbytes of data that comprise the Nielsen data. Recognizing this, a custom DBMS (i.e. DME database 126 and DME 127) can be created to take advantage of the specific characteristics of the data (in this case, television viewing data prepared by Nielsen). The organization and manipulation methods and techniques for accessing DME database 126 are described below. 2. Detailed Description of DME Database DME Database Organization A DME database 126 according to a preferred embodiment of the present invention is capable of spanning many weeks and is composed of .tvd discrete files, one file corresponding to each week of the Nielsen data. The name assigned to each of the files in DME database 126 is the date of the Nielsen data contained within that file. For example, data for the week ending Jul. 28, 1997 is contained in a file with the name 19970728.tvd. TVD is an acronym for Television Viewing Data and is used to identify all files with a format suitable for use with the present invention. To add an additional week of Nielsen data to DME database 126, the .tvd file that contains that week's viewing data is simply placed into the directory for DME database 126 along with all other .tvd files. This feature of the present invention makes it very easy to keep DME database 126 up to date. A user or system administrator can create a copy of all or a selected portion of DME database 126 by copying some or all of the .tvd files to another memory storage location, and then, by using a command that can be accessed through graphical user interface 125 described below, direct system 100 to access the new database location. No other database installation process is required. DME Database File Format The .tvd data files contained in DME database 126 can be considered object-oriented for several reasons. First, the various components of the Nielsen data are treated as a group of various objects, i.e. a household object, a person object, a television program object, etc. Accordingly, all of the data for each discrete object, such as a household, person, or television program object, is located contiguously in the .tvd file. For example, the data describing a particular person's age, gender, and person number are physically adjacent in the individual database file, rather than as columns in a relational table. In addition, the length and relative byte position of each data element for each object in the database file is the same as the required length and byte position of those same data elements in memory 120. Further, the relative positions of data in the file and in memory 120 are the same. A region of memory 120 is allocated for loading sets of person objects (or program objects, or household objects). Memory 120 is sized according to the type of object being loaded and number of objects in the collection. Given this memory allocation, the data is loaded in a binary fashion from the Nielsen data file into memory 120. During this loading process, data attributes are ignored. The first byte of person object data for the person collection in the file, for example, is loaded into the first byte of allocated memory. The second byte of data is then loaded into the second byte of allocated memory, etc. This process is both fast and reliable. It is important to note that the data are not loaded as objects, but once the data is loaded into memory 120, system 100 can operate on the data as objects. Third, data items are retrieved from the database as objects and collections of objects, rather than as discrete data elements which are assembled into objects in memory. Finally, the data for similar objects, such as people in the same household, or programs of the same day, are also located contiguously in the file. This unique database structure allows for binary data transfer of large blocks of objects from disk to memory 120. The objected-oriented database management software (DME 127), requires memory based data objects for processing and can begin operating on the .tvd data immediately after retrieval from DME database file 126. DME Database File Creation Although the data received from Nielsen is very valuable for analysis and advertising purposes, the format of the data does not readily lend itself to quick and efficient manipulation. For this reason, the various preferred embodiments of the present invention will read the data from the magnetic tapes supplied by Nielsen, reformat it, and store it in DME database 126 using .tvd files. The data conversion process is detailed in FIG. 2. Referring now to FIG. 2, a process 200 in accordance with a preferred embodiment of the present invention for converting data from a first data format (i.e., the Nielsen format) to a second format (i.e., the .tvd format) is illustrated. As shown in FIG. 2, process 200 generally involves organizing the Nielsen data from the standard Nielsen format into the format required for object-oriented processing, then writing this memory data in binary form to individual .tvd files within DME database file 126. The basic steps for this process are: allocate blocks of memory 120 (step 210); assign these memory blocks to arrays of objects, such as arrays of person objects or program objects (step 220); read the data supplied by Nielsen and assign values to the object data elements in memory, such as age, or program name (step 230); and, write the blocks in binary form from memory 120 into a newly created DME database .tvd file (step 240). It is important to note that there is no requirement to locate all blocks of memory 120 in a contiguous fashion. Blocks of memory 120 may be allocated as needed, where needed to accommodate the Nielsen data. Referring now to FIG. 3, a process 300 in accordance with a preferred embodiment of the present invention for accessing DME 127 is illustrated. When the data in DME database 126 is being used for analysis, the direction of data transfer is reversed. First, blocks of memory 120 are allocated and the blocks of memory 120 are assigned to arrays of objects (step 310); the blocks of data are read from the .tvd data files in DME database 126 in binary form into the allocated memory blocks (step 320); and then DME 127 can access the television viewing data. This type of data retrieval is not possible using conventional database systems because the binary representation of the data in a typical database is typically not the same as the data in memory 120. As explained above, for the various preferred embodiments of the present invention, the data storage format is identical. Note, however, that if the structure of the various data objects in DME database 126 is modified to accommodate expanded types of analysis, then the .tvd database files also need to be modified to reflect those changes. As noted above, data is binary loaded from database file 126 into memory 120. Portions of memory 120 are sized according to the type of object being loaded and the number of objects in the collection. Using a database that is composed of 52 discrete weekly .tvd files, the assumed size of person objects in each of the 52 files is identical. Person objects in collections loaded from the week 1 file are the same size as person objects from the week 10 file. For example, if the size of person objects in the Nielsen data is expanded by adding additional attributes, such as an occupation attribute or a head-of-household flag, this change would also need to be reflected in the size of the person objects in each of the 52 weeks of data. All 52 files would need to be recreated with the newly resized person objects. The design of DME database 126 does not provide the data type independence of many commercially available database management systems in which the representation of the data in the database is independent of the representation of the data in memory. However, by mirroring the data in both locations, a significant speed advantage is recognized. As previously mentioned in the Overview section, the records in the Nielsen data files are converted for use with the preferred embodiments of the present invention. Each of the six supplied files plays a part in creating DME database 126 and the following conversion details are performed by DME 127. Once again, information in the calendar record is read but is not entered into the TVD database file. The data in the calendar record is used only to validate dates in other record types. Each household data item in each classification record is translated to binary form as described in the section "Sample Filtering". This binary form of the data item is then assigned to the corresponding attribute in the household object created for the household. The income indicator "5" in the record above, for example, is translated to the binary number "00100000." Similarly, the age and gender data for each person in the classification record is also translated to binary form and assigned to the corresponding attribute in the person object created for the person. As Household and Person objects are created, they are added to their respective Group collections. Each program data item in each program data lead record is assigned to the corresponding attribute in the program object created for the program. Dates, times, and quarter hour values in the program data item are converted from an ASCII representation as shown above in the Overview section to a binary representation, and assigned to the corresponding date/time attributes in the program object. As Program objects are created, they are added to the Program Group collection. Prior to the step in the creation of DME database 126 where the program data continuation records arc read, a Viewing Index is created, as described in the section "Viewing Data", and illustrated in the figure showing "Database Structure". After creating the Viewing Index, for each network viewing event in each program data continuation record, the Household or Person object referred to in the event is found in the Household Group or Person Group collections. As described in the section "Viewing Data," the memory location in the viewing data memory for this household/person and date/time is identified, and a notation is made indicating that the household/person viewing the network program at the indicated date/time. The date/time in each usage data lead record is noted and used in reading each subsequent usage data continuation record. Using the date/time from the usage lead record, for each viewing event in each usage data continuation record, the Household object or Person object referred to in the event is found in the Household Group or Person Group collections. As described in the section "Viewing Data", the memory location in the viewing data memory for this household/person and date/time is identified. At this point a notation may be made to the record, conditioned on the presence or absence of a preexisting notation: 1) If a notation has already been made in this location based on a viewing event string in a Program Data Continuation record indicating that the household or person was watching network television, then no further notation is made. It can be assumed that the usage viewing event refers to this network viewing. 2) If no notation is found, then it can be assumed that the household or person was viewing non-network television, and a notation is made accordingly. After processing all Nielsen data records for a given week, the resulting memory objects are written to disk as a TVD database file. Each memory location is written in binary form in sequence: first the viewing index is written. This index includes the offset value described in the section "Viewing Data". Following the index, all household objects are written, followed by all person objects, and program objects. Finally, the actual viewing data is written, all in binary form. As described above, in the Nielsen data files, two separate records are used to describe television viewing. One is a program data record, and the other is a usage record. The program data record indicates all those persons and households in the sample who viewed a particular network program. Viewing of non-network programming is not indicated in the "program data" record. The "usage" record indicates television usage by person and household. With this record arrangement, to find all instances where sample members watched non-network programming, those instances in which the program data indicates the household members were watching network programming must be subtracted from the usage entries. The usage entries remaining after this subtraction are the non-network viewing entries. Data Conversion Mechanism Referring now to FIG. 4, a sample data conversion mechanism 128 and process adapted for use with the present invention are illustrated. A data conversion mechanism according to a preferred embodiment of the present invention is a computer-implemented process for converting person-by-person media-related data from a first data format to a second data format. The data conversion mechanism will use Processor 110 to execute the process and memory 120 as a storage location in order to convert the data. The process of creating a .tvd data file for DME database 126 is one of reorganizing a weekly set of data as delivered by Nielsen in computer memory in the form required for object-oriented processing, then writing this memory data in binary form to DME database file 126. Referring now to FIG. 4, the steps for performing data conversion via process 400 are described. 1) Allocate blocks of memory 120 which are sufficiently large to accommodate the data in the week being processed, and assign these memory blocks to arrays of household objects 454, person objects 456, program objects 458, and viewing data 460. Because it is unknown at this stage of the process exactly how many programs, households, etc. are include in the Nielsen data for the week, it is likely that portions of each of these memory blocks 120 will not be used, and will not be written to the completed .tvd database file 126. 2) Read all classification records. a) Read a classification record from Nielsen data 430. b) Select the next household object in the household object array 454 for this data. c) Translate to binary form the household attributes in the classification record. Each household data item in each classification record is translated to binary form as described in the section "Sample Data Filtering" below. This binary form of the data item is then assigned to the corresponding attribute in the household object selected for that given household. The income indicator "5" in the record above, for example, is translated to the binary number "100100000". d) Increment the household object array counter in Household Group 440 to indicate that the household has been added to household object array 454. e) For each person in the classification record, select the next person object in person object array 456. f) Translate to binary form the person attributes of age and gender data, and assign to the corresponding attribute in the person object selected for the person. g) Increment the person object array counter in Person Group 442 to indicate that the person has been added to person object array 456. 3) Assemble current viewing catalog (step 410). a) Allocate a block of memory 120 which is sufficiently large to accommodate viewing catalog 452 for the current week. b) For each household in household object array 454, locate the entry for the household in the viewing catalog for the previous week. i) If an entry exists in the viewing catalog for the previous week, then make an entry for the household in the same position in the viewing catalog for the current week. ii) If an entry does not exist in the viewing catalog for the previous week, then make a new entry for the household at the end of the viewing catalog for the current week. iii) Assign an entry in the viewing data 460 region of memory 120 for the household. Indicate this entry position in viewing catalog 452 for the current week. c) For each household member in the person object array, locate the entry for the person in the viewing catalog for the previous week. i) If an entry exists in the viewing catalog for the previous week, then make an entry for the person in the same position in the viewing catalog for the current week. ii) If an entry does not exist in the viewing catalog for the previous week, then make a new entry for the person at the end of the viewing catalog for the current week. iii) Assign an entry in the viewing data memory region for the person. Indicate this entry position in the viewing catalog for the current week. d) Entries are not made in the viewing catalog for those who are not members of households (visitors). Thus, for each person in the person object array who is not a member of a household, assign an entry in the viewing data memory region for the visitor. Indicate this entry position in the person object. 4) Read all program data records (both the lead and the continuation records) from Nielsen data 430. a) For each classification lead record, select the next program object in the program object array for this program data. b) Assign data items in the program data lead record to the program object selected for the program. Dates, times, and quarter hour values in the program data item are converted from an ASCII representation to a binary representation, and assigned to the corresponding date/time attributes in the program object. c) Increment the program object array counter in the Program Group to indicate that the program has been added to the program object array. d) For each program data continuation record, locate the Household or Person object referred to in the viewing event in the Household Group or Person Group collections. e) As described in the section "Viewing Data in the DME Database", identify the memory location in the viewing data memory for this household/person and date/time using the newly assembled current week viewing catalog for households and household members. f) Enter in the viewing data memory location a notation indicating that the household/person viewed the network program at the indicated date/time. 5) Read all usage data records (both the lead and the continuation records). a) For each usage lead record, identify the date and time of the quarter hour viewing event for the lead record. This date/time is used in reading each subsequent usage data continuation record. b) For each Household or Person in each usage continuation record, locate the Household or Person object in the Household Group 440 or Person Group 442 collections. c) As described in the section "Viewing Data in the DME Database", identify the memory location in the viewing data memory for this household/person and date/time using newly assembled current week viewing catalog 452 for households and household members. d) Enter in the viewing data memory location a notation indicating that the household/person viewed the television at the indicated date/time. This notation is conditional on the presence of a preexisting notation: i) If a notation has already been made in this location based on a viewing event string in a Program Data Continuation record indicating that the household or person was watching network television, then no further notation is made. We assume that the usage viewing event refers to this network viewing event. ii) If no notation is found, then we assume that the household or person was viewing non-network television, and a notation is made accordingly. 6) Write the allocated blocks of memory 120 onto disk in binary form into a newly created .tvd database file 490 located in DME database 126. In all cases, except as noted, the blocks of data are appended contiguously to .tvd file 490. a) Write header text which identifies the file for those users who attempt to edit, type or print .tvd file 490. b) Write a file format version number which can be read by DME 127. c) Write five long integers to .tvd file 490, each initially have a value of zero. These values are used to note the offset position in the database file of each of the arrays of objects and data. Each of these values will be updated (as noted below) with an actual offset value. d) Write the viewing catalog 452 to .tvd file 490. i) Write the length of viewing catalog 452 ii) Write the portion of viewing catalog 452 which has been used. Note the offset position from the beginning of the file of this catalog. iii) Write the offset value to the first offset position as described in (c) above. e) Write the portion of household object array 454 to .tvd file 490. i) Write the number of entries in household object array 454. ii) Write the portion of household object array 454 which has been used. Note the offset position from the beginning of the file of this catalog. iii) Write the offset value to the second offset position as described in (c) above. f) Write the portion of the person object array 456 to .tvd file 490. i) Write the number of entries in the person object array 456. ii) Write the portion of the person object array 456 which has been used. Note the offset position from the beginning of the file of this catalog. iii) Write the offset value to the third offset position as described in (c) above. g) Write the portion of the program object array 458 to .tvd file 490. i) Write the number of entries in the program object array 458. ii) Write the portion of the program object array 458 which has been used. Note the offset position from the beginning of the file of this catalog. iii) Write the offset value to the forth offset position as described in (c) above. h) Write the portion of the viewing data 460 to the file. i) Write the number of entries in the viewing data. ii) Note the offset position from the beginning of the file of this data. iii) Write the offset value to the fifth offset position as described in (c) above. iv) For each of the 28 periods of 6 hours each, write the portion of the viewing data 460 which has been used. 7) Close .tvd database file 490. 8) Write current viewing catalog 452 to a separate file for use in assembling the viewing catalog for the next week. Although the example presented above specifically references person-by-person media-related data for network broadcasting, cable television network data can be added to the database file using similar techniques. In addition, similar database files can be created for other media types using similar techniques. Sample Data Filtering Using DME Database One significant advantage of the preferred embodiments for DME database 126 is the very fast access to the data for purposes of filtering data according to custom queries. Users will typically want to analyze the viewing behavior of selected demographic groups of people or households in the Nielsen sample for purposes of analyzing behavior and targeting desired consumer groups for advertising campaigns. The Nielsen data contains various data elements that can be used for filtering. These elements include: age; gender; income; level of education; profession; hours of weekly television viewing; and the ages of family members that live in the household. This data can be used to identify and select various consumer groups for purposes of analysis and formulating advertising campaigns. For example, a system user might wish to select all women between the ages of 18 and 49 who live in households with children, and having incomes greater than $40K per year. Rather than use mathematical relations in a database management system to make this sample selection, the data in DME database 126 is organized so that the selection can be made using Boolean logic, which is relatively fast to compute using most typical computer systems. Referring now to FIG. 5, the data elements for representing the age of the sample audience members, for example, are not stored as integers, but are stored as a 16 bit field where each bit represents one of the available age ranges. The first several age ranges are assigned bits in the field according to the table shown in FIG. 5. Additional age ranges can be represented in a similar manner. Given this structure, filtering the data contained in DME database 126 for age-specific criteria is a simple Boolean mathematical exercise. To select sample members based on age, graphical user interface 125 utilizes a 16 bit age selection mask with the required bits set to indicate the desired age range. If, for example, the user wanted to analyze sample members in the 12-20 age range, then the age selection mask would be 8H+10H+20H=38H (hex), or 0000000000111000 (binary). To determine whether or not a particular sample member represented in DME database 126 is in the desired age range, DME 127 performs a logical "and" operation using the member's age field and the age-appropriate selection mask. In the C programming language, this procedure may be represented as "PersonAge & AgeSelectionMask." If the person were actually in the age range of 15-17, then the values would be
______________________________________
0000000000010000 (age of audience member)
+ 0000000000111000 (age selection mask)
0000000000010000
______________________________________
Which would result in a value of TRUE for the operation, thereby indicating that the person is in the requested age range. Other similar operations can be envisioned to create filter masks for other demographic information contained in DME database 126. Given this structure, a sample selection based on multiple demographic fields would combine similar elements for those fields. For example, in the C programming language, a selection based on age, income, and education could be represented as shown immediately below. ((PersonAge & AgeSelectionMask) && (HouseholdIncome & HouseholdIncomeSelectionMask) && (HouseholdEduc & HouseholdEducSelectionMask)) By providing the appropriate mask for the desired demographic characteristics, DME database 126 can be quickly and efficiently screened to locate the sample audience members who fit the desired criteria. This kind of Boolean computation can be executed very quickly on a digital computer. Alternatively, although not preferred, a more conventional approach for a similar selection might be the expression shown immediately below. if (PersonAge>=LowerSelectionAge && PersonAge<=UpperSelectionAge && HouseholdIncome>=LowerSelectionIncome && HouseholdIncome<=UpperSelectionIncome && HouseholdEduc>=LowerSelectionEduc && HouseholdEduc<=UpperSelectionEduc) The above expression is much more time consuming to evaluate in a computer by virtue of the fact that it is longer and the math operations (such as ">=") are more time consuming for processor 110 to evaluate than simple logical operations (such as "&") are to evaluate. Viewing Data in tihe DME Database The Nielsen person-by-person data provides "viewing data" for any given week. The viewing data indicates the viewing choices made by sample households and mcmbers living in the sample households for the midpoint of every 15 minute period during the week. For example, for the week of Sep. 22, 1997, the data may indicate that the viewing selection made by person number 2 in household number 200011 at 8:08 PM on September 24; the midpoint of the 8:00 PM to 8:15 PM quarter hour. The viewing options for this person include at least three distinct options: 1) watching one of the broadcast networks--ABC, CBS, Fox, or NBC; 2) watching non-network programming such as unaffiliated stations or cable; or 3) turning the television off, i.e. not watching television. As Nielsen makes other notational options available, such as including the Warner Brothers Network, these new options can also be noted in the data structure without modification. If a person was not watching television during a given quarter hour, then no viewing records are present in the Nielsen data for that quarter hour. In addition, if the person was not in-tab for that quarter hour, then the data delivered by Nielsen indicates that condition as well. In DME database 126, the sample viewing data provided by Nielsen for a given week requires about 7 Mbytes of storage space. In order to conserve memory space during subsequent processing and analysis, it is desirable to avoid allocating memory for an entire week of data when a user requires access to only some small portion of it. Therefore, a week of Nielsen viewing data is divided into 28 blocks of about 250 Kbytes each, with each block representing six viewing hours during the week for all households and people in the sample. The broadcasting week begins at 6:00 AM on Monday morning. Thus, the first block of viewing data begins at 6:08 AM on Monday and ends at 11:53 AM. Similarly, the second block begins at 12:08 PM and ends at 5:53 PM, etc. Each of these 28 blocks for a given week contains all of the viewing data for a six-hour period either for all sample households and members. Thus, if a system user requested viewing data for a particular member of the sample at a specific time, then the appropriate block of data in DME database 126 will be retrieved from DME database 126 and loaded into memory 120. This block will be the block that contains all the viewing data for a six-hour period (including the requested time) for all members of the sample audience. Alternatively, the broadcast week could have been subdivided into a greater or lesser number of blocks by selecting an alternative size for each of the blocks. This memory management procedure is consistent with anticipated mode of system use for a typical user. Typically, if a user requests a type of analysis which requires viewing data for a given sample member at a particular time, then the desired analysis will generally also require viewing data for many or most other members of the sample audience for the selected time and for adjacent times. Thus, all necessary data is efficiently loaded as a single block from DME database 126 into memory 120. This is a more efficient process than would otherwise be required using conventional database management systems which repeatedly return to the database file for more data for other sample members or for other times in an iterative fashion. Referring now to FIG. 6, a simplified graphical representation of the data contained in a .tvd file as stored in DME database 126 is shown. The data in FIG. 6 represents a total of 7 households, with 17 members residing in those households, and 3 visitors. The indices in each of the arrays indicate a relationship to the data contained in other arrays, and the viewing status elements in the viewing data arrays are typical for actual members of the sample audience. Although somewhat involved, FIG. 6 presents a useful example of how the actual database arrays relate to each other. Note that in an effort to avoid too much confusion in the figure, not all of the possible relationship arrows are included. The arrows in FIG. 6 indicate some of these index relationships between various data elements. Normal programming practice in C++ suggests the use of memory pointers rather than indices to relate one object to another. However, as explained above, it is unknown where in memory 120 the allocated blocks will be located after they are retrieved from DME database 126. So, using the various preferred embodiments of the present invention, pointers cannot be used to access database 126. The indices are used in place of pointers to indicate an offset into each block of data. Each cell 651 in a block of viewing data 650 indicates a television viewing status element for one member of the Nielsen sample, or for one household, for the mid-point of one quarter hour time period 651. If, for a particular record in the viewing data, the person or household is watching one of the viewing options (such as ABC, CBS, Fox, NBC, one of the cable networks, or non-network programming), it is indicated. If the member was not watching television, then cell 651 is blank. Also indicated is whether or not the sample member is out-of-tab (shown in as an "O" in each out-of-tab cell.) DME database 126 includes a viewing catalog data structure 640 that relates person and household objects to viewing data 650. The data for each household and person includes an index value 641 indicating the position in viewing catalog 640 for that person. So, to retrieve viewing data for one member of the Nielsen sample for a single quarter hour period, DME 127 will perform the following tasks. First, DME 127 will allocate a block of memory 120 for all person objects for the desired week, and loads all person data objects from disk into the allocated block of memory 120. Next, DME 127 allocates a block of memory 120 for all household objects for the week, and loads all household data objects from disk into memory 120. Then, DME 127 will allocate a block of memory 120 for viewing data 650 and load the desired six-hour block of viewing data 650 into this block of memory 120. Once viewing data 650 is loaded into memory 120, DME 127 will allocate a small block of memory 120 and loads viewing catalog 640 into this block of memory 120. Next, DME 127 will locate the person object in memory 120 for the requested member of the sample and move to the position in the viewing catalog as indicated by the catalog index value in the person object. Then, DME 127 moves to the appropriate record in the viewing data as indicated by the viewing index value in the viewing catalog. Finally, DME 127 can move along the record in viewing data 650 to the desired time during the six hour time block and retrieve the viewing indicator. For example, to find out what person #4 in household #200143 was watching at 8:23 PM, DME 127 will search through the array of person objects 630 until it finds person #4 in household #200143. In searching for this particular person, the household number of each person is found by reading the household index number, which, in this case, is 6, and then reading the household number for array element number 6 in the household objects array 610. After finding the person, the catalog index number is read, which, in this case is 27. Then, the 27.sup.th element of viewing catalog 640 is read for the viewing index, which is 25. Next, the 25.sup.th element in the person viewing data array is accessed. Finally, by referencing the appropriate cell, this element indicates that at 8:23 PM the person was watching non-network television. There are at least two important reasons for redirecting the viewing data locations through viewing catalog 640 rather than indicating the location of viewing data with viewing data block 650 directly from household objects array 610 and person objects array 630. First of all, by redirecting the data lookup through viewing catalog 640, viewing catalog 640 can remain consistent from one week to the next. "Consistent" in this context means that the various entries in viewing catalog 640 are in the same relative position from week to week. The entry for person #1 in household #200143, for example, is always six positions following the entry in viewing catalog 640 for person #1 in household #200113. Given a consistent viewing catalog 640, it is only necessary to load a single person objects array 630 or one household objects array 610 from a single week in order to retrieve data spanning multiple weeks. The catalog index values in these arrays can be used with a viewing catalog 640 from any week of data. Second, in order to maintain consistency between weeks in viewing catalog 640, when members drop out of the sample, empty space will remain in viewing catalog 640. Viewing catalog 640 is not compressed to eliminate the spaces, as indicated by the empty cells shown in viewing catalog 640 at positions 15, 16, and 19-22. But, because of the indirection in the viewing index, these spaces are not necessary in the viewing data, thus reducing the memory requirements for the data. DME 127 can also be used to review the viewing habits of person #1 in household #200143 over a period of several weeks. As indicated earlier, for the week shown in FIG. 6, the catalog index number for of person #1 in household #2001432, and the viewing index number is 22. For the week shown in FIG. 6 viewing index number 22 is used to retrieve the viewing information. However, in order to analyze what this same person was watching during the following week, there is no need to load another array of person objects 630 and find the catalog index value for this person for the next week. The catalog index values remain the same for all members of the sample from one week to the next. This person's catalog index value is still 25. So, DME 127 loads viewing catalog 640 for the next week and retrieves the viewing index value from catalog index position 25. This viewing index value may not be 22 as it was in the first week. If there is no viewing index value in viewing catalog 640 at position 25 for the next week, we know that this person was dropped from the sample, and that there is no viewing data contained in viewing data block 650 for the person during that week. In summary, the use of viewing catalog 640 eliminates two time and memory consuming tasks in retrieving viewing data which spans days or weeks. First, there is no need to load person and household objects for multiple weeks. Second, the need to search through multiple person or household arrays for sample members is also eliminated. The above described architecture for DME database 126 is not absolutely essential for the implementation of graphical user interface 125. However, because of the significant speed advantages afforded by this structure, it is the most preferred embodiment for storing Nielsen data for use with the present invention. Future advances in computer hardware may make it possible to implement the present invention using conventional database management techniques. However, the specific database design of the present invention will still provide a significant speed advantage over other database structures presently known. Referring now to FIG. 7, three viewing catalogs 640 for three consecutive weeks are shown (week 1, week 2, and week 3). In the week following that shown in FIG. 6, the first three households (up through household #200045) are dropped from the sample. As shown in FIG. 7, viewing catalog 740 has blank spaces in cells 0-7. There is no viewing data for these households. Therefore, it is no longer necessary to store cells 0-7 in the database, as indicated by the dashed lines in FIG. 7. For week 2, viewing catalog 640 will begin with the cell that corresponds to cell #8 of the previous week, together with the absolute cell position of this first cell. The number of the first valid cell in the viewing catalog is referred to as the catalog offset (in this case, 8). To extend the example, if households #200071 and #200102 are dropped in week three, then the cells which correspond to cells 0-14 of week 1 will be blank. Recognizing that cells 15, and 16 were already blank, the first valid cell for week three is #17. This is illustrated in FIG. 7 for viewing catalog 640 for week 3. Similarly, only those cells of viewing catalog 640 beginning with cell 17 along with this offset number are stored. From week to week, the index to viewing data for each sample member is stored in the corresponding cells of viewing catalog 640 as shown in FIG. 7. For example, the catalog index for week 1 for person #3 in household number 200143 is 26, for week 2 it is 18, and for week 3 it is 9. Note that the viewing catalog index values (the numbers down the left hand side of each viewing catalogs 640) change from week to week, but the relative positions of the cells do not. Using the catalog index for any weeks, along with the appropriate catalog offset values, DME 127 can compute the catalog index value for any week in DME database 126. This capability allows DME 127 to avoid needlessly searching through person object arrays or household object arrays for other weeks that include the sample member of interest. For example, it will be fairly simple to retrieve the viewing data for person #3 in household number 200143 for all of the above weeks. Although any week could be used as the starting point, for illustrative purposes week 2 is selected. In week 2 the catalog index for person #3 in household number 200143 is 18. The catalog index for any other week is a combination of this catalog index and offsets for the two weeks, as calculated below. Catalog Index n=Catalog Index 0+Offset 0-Offset n Therefore, the catalog index value for week 1 is: Catalog Index 1=18+8-0=26 and for week 3 the catalog index value is: Catalog Index 3=18+8-17=9 The calculation of the catalog index value can be seen in FIG. 7. Now, using a combination of the viewing catalogs 640 and catalog offsets for several weeks, the viewing information for a selected person in the Nielsen sample can be quickly accumulated. First, the viewing catalog index number for the desired person is retrieved from any one of the weeks of interest. Then, each of the viewing catalogs 640, along with the associated catalog offset for the catalog, is successively loaded for person #3 in household number 200143, along with the viewing data for the associated week. Then, by comparing the catalog offset, the viewing index, and catalog values, one of the following conclusions will be reached. If, for any given week, the calculated catalog index is less than the catalog offset for that week, then the desired person has been dropped from the sample. Additionally, if the location in the viewing catalog for the catalog index plus the catalog offset is blank, then the desired person has been dropped from the sample. Finally, if the calculated catalog index is greater than the size of the viewing catalog, then, for that specific week, the person has not yet been added to the sample. Most types of analysis dealing with advertising and broadcasting require retrieval of media exposure data for demographically related groups of people, not just individuals as in the example above. For example, it might be desirable to know what people in the 18-49 age group were watching at time 1 during week 1, time 2 during week 2, and at time 3 during week 3. DME database 126 is designed so as to be particularly well suited for these types of queries. This is illustrated in the following pseudo-code shown immediately below.
______________________________________
1) load the person and household objects for week 1
2) for each of three weeks
3) load the viewing catalog
4) load the catalog offset
5) load the viewing data
6) next
7) for each person in week 1
8) if this person is in the selected demographic group
9) for each week n
10) calculate the catalog index
11) retrieve the viewing data for time n
12) if this person is not in-tab or in the sample
13) go to the next person
14) end if
15) next
16) add results to summary values
17) end if
18) next
19) return the summary values
______________________________________
Viewing catalog 640 will not grow indefinitely because viewing catalog index positions are assigned to households and people in the order in which they are added to the Nielsen sample. Therefore, the sequence in which they are dropped from viewing catalog 640 will be in approximate chronological order. The sample members that are most likely to be dropped from the sample are at the top of the catalog index because they have been in the sample the longest. User Interface Graphical user interface 125 provides access to DME 127 and, by extension, to DME database 126 via DME 127. There are several unique characteristics available in conjunction with user interface 125 that are especially advantageous for analyzing Nielsen data. Each of these specific features is explained below. Referring now to FIG. 8, a method 800 for using a preferred embodiment of the present invention to access the television viewing data is described. System users can gain insight into how audiences make television viewing decisions by using the system to interactively browse through the viewing data. To use the system, a person typically iterates through the steps illustrated in FIG. 8. The user formulates a question or hypothesis about audience viewing behavior (step 810). The user composes a query based on the question or hypothesis using graphical tools supplied user interface 125 (step 820). The user submits the query to the DBMS (step 830). DME 127 selects a subset of the audience sample based on demographic choices the user made in composing the query (step 840). DME 127 computes/tabulates the results (step 850) and returns the results to system 100 (step 860). Then, user interface 125 of system 100 presents the query results in graphical and/or tabular form to the user (step 870). The user then examines the results, and in doing so, may formulate new questions or hypotheses about viewing patterns and decisions (step 890). In this case and based on these new hypotheses, the user may return to step 810 to compose one or more new queries. Referring now to FIG. 9, sample cross tabulation information for the hit television program "Friends" is shown. This type of graphical presentation for media-related data is not readily available for general use in the market today. Typically, this type of information is only available by contacting organizations that specialize in producing it. However, with the various preferred embodiments of the present invention, this type of information can be made readily available to a large audience. Another feature of graphic user interface 125 is the ease of selecting desired demographic information. Demographic groups can be selected by adjusting the length and position of a series of graphical bars, in which the position of each bar represents the selected range for a single demographic attribute. The user clicks on the numerical values indicating the selected range of values. The bar position is adjusted to reflect this selection. In addition, a user of system 100 can immediately access a variety of useful media-related person-by-person information by merely clicking on a single icon. Similarly, referring now to FIG. 10, a user may "click" a mouse on the defection icon and generate the line graph shown in FIG. 11. The icon-driven graphical user interface 125 provides single click access to very sophisticated types of information. Anywhere on any screen where a program names or data is displayed, the user may retrieve more detailed information on a given program by selecting the program name or data region using the mouse. For example, the pie chart shown in FIG. 12 represents audience flow for a series of programs, then the user may select any one of the titles to show other information about that episode of the program such as total ratings, or share. Alternatively, if a user selects a program as described above, the system could be configured to display historical ratings trends. Finally, the user can customize the system to determine that information that is displayed when the user selects an item. Some useful items that can be accessed via user interface 125 are explained briefly below. Program Lists. Using a variety of interactive mechanisms, a user can assemble lists of program episodes. Analysis can then be performed on these lists. Program Schedule Data Dynamics. A user can select a program schedule for display, and then select other data elements for display in the context of the schedule. The user can, for example, select for display the programming schedule for NBC for all Monday evenings between two dates. The user then could select for display adjacent to the name of each of the programs the retention or lead-in value for the program. A computer system 100 for data manipulation and analysis in accordance with a preferred embodiment of the present invention employs a unique user interface 125 which, in conjunction with DME 127, can retrieve the Nielsen data from DME database 126 and then present the data in graphical and tabular forms to system users. The various embodiments of user interface 125 are designed to be easy to use and intuitively simple. This allows broadcasting and advertising professionals to understand the viewing patterns of the television audience with little or no formal training. System users are often interested in the television viewing behavior of particular demographic groups. They may, for example, be interested only in adults in the age range of 18 to 49 years old who live in the northeast United States, and who live in households with incomes greater than $40,000 per year. The data analysis system of the present invention is designed to provide convenient isolation of these types of demographic groups in the sample, and the necessary tools for analyzing their viewing habits. The techniques described can be used in a variety of environments. We have discussed applying them to broadcasting applications, but they are equally effective in being applied to point-cast and multi-cast applications such as over the Internet, and cable systems. All that is required is exposure data and processing time. The ability to gather exposure data will only improve as electronic media becomes more popular. It is likely that data for larger sample sizes will be available, the data will be cheaper to accumulate, and more data will be available. This would suggest the need for better mechanisms for analyzing the data as described herein. While the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention. Accordingly, the invention should not be limited to the specific embodiments shown herein.
|
Same subclass Same class Consider this |
||||||||||