PRODUCTION OF CUSTOMIZED COMPACT DISCS
Field of the Invention This invention relates to the field of data recording, in particular for recording music on writeable compact discs. It also relates to the operation of fault correcting and scalable data networks used to transmit and record large quantities of digital data.
Background of the Invention A small industry has grown up providing to the public socalled *one off compact discs which contain music tracks that have been selected by the purchaser. In order to make such industry profitable where there is no mass production of identical CDs, it is essential to efficiently interact with many customers to determine which music tracks each one desires on their CD, to efficiently access the desired music, to convert it to a format suitable for recording on a writeable CD ROM disc, to 'burn", i.e. record, the music on the writeable CD ROM disc, and then to package the disc in a format that is attractive to the customer and which provides the information that the customer requires to understand what is on the disc and how to access it. Furthermore it is necessary to efficiently account for royalties owed to the content owners, i.e. the copyright proprietary, and to accomplish billing the customer and maintaining records of
accounts . All of these steps are inherent in the business of marketing customized CDs and there are several companies that entered this business after the writeable CD became available. Patents have also been issued describing the opportunities made apparent by the existence of the writeable CD. US patent 5,592,511, for example, envisioned a system in which music content transmitted from central depositories by satelliteβlink would be integrated with other content supplied by the customer delivered to the customer. Although this patent indicated the possibility of building a business around the one of a kind CD its business model was impractical in the extreme. Basically it left to the reader of the patent the need to solve formidable problems of dealing with large blocks of data and in particular had no discussion of how the very significant problem of dealing with errors arising during the preparation of the final product would be solved. It's hint at an implementation failed to address problems inherent in computer systems that shut down at various points, problems that multiply as one attempts to enlarge the system and actually build an efficient business supplying large numbers of customers.
Brief Description of the Invention It is an object of the present invention to provide a system which is operated at a single site or over an Internet to
interface with a mass of individual customers and manufacture and account for a customized CD, in which a system is used that recovers from failures of components as it transmits the music or other content from a large capacity storage medium to the CD ROM writer, i.e. the burn-in unit. It is a further object of the invention to provide an assembly system which permits the handling of orders from multiple customers in parallel, allowing different tasks to complete at different rates, brings together the information and content necessary to complete a task, without confusion of the information and content of different customers, and which is tolerant of the failure of performance with respect to one customer without interrupting the performance with respect to other customers and which provides for the recovery with respect to the failed performance. The invention is achieved by utilizing the recovery capabilities of a packetized network system. In particular, each task to be performed is monitored by parameters stored in a database, and each item of information necessary to transmit from one location to another is managed in packets having headers that contain status information upgraded as tasks are completed. This status information is communicated to the database, which can provide a central monitoring function. But, in addition, during the processing of the information, the headers of the data packets arriving at processing locations allows the efficient organization of the workload at such a location. Faults in the
arriving data are noted and the system bypasses such data and refers for correction and further processing without interfering with the flow of fault-free data, thereby allowing the system to continue in operation, and to correct the faulty data. The system is also constructed in such a manner that it can be enlarged, i.e. scaled up, by the addition of hardware components without having to modify the data network communicating with the hardware .
Brief Description of the Drawings Figure 1 is a schematic representation of the network of the present invention and representative hardware elements. Figure 2 is a schematic representation of the order processor portion of the present invention. Figure 3 is a schematic representation of the extraction agent portion of the present invention. Figure 4 is a schematic representation of the assembly agent portion of the present invention. Figure 5 is a schematic representation of the printing agent portion of the present invention. Figure 6 is a schematic representation of the network topology of the present invention. Figure 7 is a schematic representation of the TCP/IP network portion of the present invention.
Detailed Description Of A Pref«»r- g Embodiment The preferred embodiment of the invention is described for a system to produce and distribute customized audio compact discs, i.e. CDS having sound tracks selected from a preexisting library, which may itself exist on mass produced CDs. The term CD is used generically to also include DVD discs, laser discs or other digital or optical recording media. The same system may be used to provide other multimedia content onto the customized compact disc, or onto other media. The term *multimedia content" is meant to include audio, video, graphic, text or any other content. The data recorded is not necessarily restricted to digital information. Thus, for example, the invention could be used for the production of customized laser discs having video content, even though the information stored on laser discs is in fact analog video information. The invention provides a system for managing the huge amounts of audio data or other multimedia content, on the order of a gigabyte as determined by the capacity of the storage media, that must be efficiently and accurately transferred from the library to the output disc, and other details involved in providing an attractive CD product, while at the same time being fault tolerant and able to efficiently recover from the failure of its components. A preferred embodiment will be described in connection with the figures. The system for producing and distributing customized CDs comprises a group of hardware elements that are linked by a
communications network that carries information as data packets, some of which carry the large data files and others of which coordinate the various tasks involved in assembling and producing the compact disk product, or which carry both types of data. Large volume files comprising the content of the sound tracks or other multimedia data are thus transmitted over the network in data packets. The data packets have header fields that are used to control the flow of status information and content. A complete set of the header fields for the data packets is shown in Table I, below. It should be understood that it is not necessary or desired that each packet should include all the header fields. In order to minimize bandwidth overload of the network each packet utilizes only so many of the header fields as are necessary to monitor the status of each packet. Certain of the fields comprise header tokens. A token may be a flag used to indicate the status of an operation. In general, a token is any means used to indicate the status of a packet and may include a bit flag, the status of any flip-flop or multistate device or any logical or data information stored in a read/write memory, to keep track of the status of any aspect of the data in an associated packet. The preferred tokens in the present invention are data stored in header fields of network data packets in order to identify the present operation in which the data packet is participating or, if not subject to a present operation, the last operation that has been completed or the next operation to be
performed. In this manner, tokens allow each data packet to have identify its current status in the procedure for creating a customized CD. Tokens which indicate that processing is occurring under the control of a particular component of the overall system are said to be 'locked" by that component. When that component has completed its processing of the data of the particular packet, it so-indicates by altering the token so that another component may commence its processing of the data in that packet, which is termed *unlocking" the token. The next component which commences processing than again locks the token. The hardware elements of the system, as shown in Figure 1, comprise the Web server 1, Order Processor 2_, Extraction Agent 2/ Assembly Agent 19, and Printing Agent 2 , all networked to the central database 5. The Extraction Agent 7 controls an Application Programming Interface 9. which is the hardware interface to a sound file library stored on hard discs H, CD jukeboxes 3_, or other library elements 15., which may include manual library elements to supplement those that are automated for infrequently requested library elements that do not justify the overhead of automation. The hard discs may be removable or nonremovable components of a large disc array. One embodiment is commercially available as a RAID (*Random Array of Inexpensive Discs"). The CD jukeboxes are available as Plextor Jukeboxes for audio CDs. The other library elements may comprise individual computers having one or more CD or DVD drives. The Assembly
WO 00/42606 PCT/TJSOO/00592
Agent 19 controls an Application Programming Interface 21 to hardware elements for writing the sound files onto a CD and printing its label. Such a hardware element may be a Rimage producer 2Z> which is a commercially available component for burning CD' s 2 , and printing content information on the non- reading surface of the CD. The header fields are shown in Table I divided into three groups reflecting the one to many relation of the header information in the various packets. The Order Header has the key field *order_id", which is a sequentially generated value uniquely identifying a particular customer order. There is a one to many relationship between the Order Header and the Item Headers, which are associated with each disc to be produced in response to an order from a customer. Each Item Header has a key containing the order_id field value and a field *custom_cd_order_id" . The Item Header key fields uniquely determine a particular disc to be produced. Similarly, there is a one to many relationship between each Item Header and the Detail Headers associated with each individual audio track on the produced disc. The key fields of the Detail Header contain the fields of the Item Header as well as the fields song_id and cd_sequence_order, which uniquely identifies the sound track in the library and its position (first, second, etc.) on the customized CD. Table I lists a sufficient set of headers. In that table, v
designates headers that are affected by verification (before order processing) from the web site, o designates headers affected by the order processor which places a lock code when it takes control of the order. All subsequent activity is controlled by lock codes. As long as the code is locked, control belongs to the element placing the lock, a designates codes accessed by the assembly agent, p designates codes accessed by the Printing Agent, m designates codes assigned by manual packaging. * designates a key code.
Table I
Orders for one or more customized compact discs having sound tracks or other multimedia data selected by the customer are received during interaction of the user with the producer' s web site 1. Information identifying the order, customer information, billing details, shipping details, information necessary to confirm the order such as an e-mail address for the customer are obtained at the web site (server) 1. This information is sent to the central database 5, termed the Orders Database, which verifies the information in the order for internal consistency and credit worthiness. To do so, the Orders Database interfaces through a data access layer 6 with payment authorization systems 8.. The Orders Database transfers a data packet, which includes a
verified order token, to the Order Processor 3. The Order Processor 3 is a digital computer having an internal memory and network and database software. The Order Processor is programmed to validate the information received from the Web Site by checking the header fields filled in by the Web Site for format consistency. These fields are indicated in Table I by the letter v preceding the field name. The Order Processor then creates extraction requests, which identify the sound track and its library location. To perform this function, the Order Processor contains a database associating each sound track in the library with its physical location in the library. Alternatively to the use of a Web Site, the orders may be received on paper, in which case they are entered into the Order Processor, or input into the order processor in an electronic data interchange format (EDI) . The Order Processor as shown in Figure 2 queries a central database 5 for information it needs to establish the next order_id and for information on the location of each requested sound track in the library. The Order Processor then stores the information in the header fields identified in Table I by the letter *o" to the left of each header field, and places a lock code on the order in the field custom_cd_order_lock_code . A lock code identifies the hardware element that is authorized to perform functions on the data identified in the header. All subsequent activity is governed by lock codes.
The lock code is an important feature in the ability of the system to recover from crashes. In effect, each hardware element may operate independently upon those data packets which it has locked by inserting its lock code into the appropriate field. In the event that one hardware element has failed, the others may continue to operate upon the data they have locked and to pass packets on to the next hardware element in the processing sequence until the defective element creates a backlog. Where there are redundant hardware elements, the failure of one element permits work flow to continue, except for the work which the defective element has locked. Upon repair of the defective element (or reassignment of its locked data packets to a similar hardware element) the work which needs to be completed is identified by the lock codes for the work locked by the repaired element. Therefore, the work resumes with a minimum of interruption. Although the lock code has been described as a field element in a data base header, it is just one example of a locking mechanism. The term *locking mechanism" as used in this application is to be understood as encompassing any mechanism or method whereby access to a data packet by a processing component is restricted or allowed. For example, a routine that recognizes some property of the data within a packet and applies a criteria for allowing access to that packet comprises a locking mechanism. An example that could constitute a locking mechanism might be a
routine that recognizes the content of a packet from the format of the data contained in the packet or from headers integrally associated with the data. The central database retains information on the lock code status of each packet and controls the flow of information in the system. It is the only centrally critical component of the preferred embodiment of the system. In an alternative embodiment within the scope of this invention, the central database may be made to play a lesser role by having each hardware component direct data packets to the next element in the production sequence when it is ready to release its lock code. After the order processor 3 has released its lock code, and communicated that to the central database 5, control then passes to the Extraction Agent depicted in Figure 3. When the Extraction Agent is free to work on another data packet it queries the central database 5. for a data packet that the Order Processor has unlocked, and it locks that data packet with the Extraction Agent's lock code. The Extraction Agent's role is to extract the sound tracks or other multimedia data from the library and to place it in a song queue. This is done in a manner that is device independent with respect to the devices comprising the library. To maintain device independence, the Extraction Agent interfaces with an Application Programming Interface (API) 9 that deals with the hardware specific requirements of the library media. Those media may comprise hard
discs 11, jukeboxes of CDs 13, or other storage media for sound tracks or other multimedia data 15. The Extraction API 9_, under the control of the Extraction Agent 1_, extracts a sound track from the library and stores it in a song queue buffer or production cache H, which may be a 70 gigabyte (and expandable) redundant array of inexpensive discs. The song queue buffer or production cache is a temporary storage media. The temporary storage media may comprise one or moreβ drive storage media, or other storage media such as flash memories or RAMs. When this is accomplished the relevant header fields labeled *a" in Table I are filled in, and the Extraction Agent records this in the central database and releases its lock code. The Assembly Agent 19, depicted in Figure 4, queries the central database for headers which have been released by the Extraction Agent. Where such a header exists the Assembly Agent controls the process of recording the sound tracks or other multimedia data onto the end-product CD 24. and printing information on the surface of the CD (such as a name selected by the user and the names of the sound tracks or other multimedia data) . The Assembly Agent 9 interfaces with an Assembly API 21to again maintain device independence. The Assembly API 21 accommodates the hardware requirements needed to burn (i.e. write) the CD and to print the information on the surface of the CD. When the Assembly Agent has completed its process it releases its lock on the header and communicates this to the
central database. The next stage takes place when the Printing Agent 23., depicted in Figure 5, seeks from the central database the identity of a task released by the Assembly Agent. The Printing Agent then places its lock on the header and proceeds to prepare at a print station 26 the jewel case, invoice, letter to the customer, and if requested a gift card. Then the Printing Agent fills in the header elements, which are marked *p" in Table I, releases its lock, and so informs the central database. The final stage is the Shipping Agent 5. This may involve automated or entirely manual operations such as packaging, applying postage, and shipping. It should be understood that the system as described has as one of its advantages that it is scalable. Each of the hardware elements may be replicated as often as necessary to handle the volume of data traversing the network. As shown in Fig. 6, the network topology of the present invention is configured into two networks, a TCP/IP network 27 and a CD-Production Network 29 interfaced by a router 3_1. The network portion 27 (see Figure 7) preferably utilizes the TCP/IP format and services the Web Site 1, Central Database 5, and otherwise connects into network elements that interface with the customers and staff supporting the system. The router 3_1 may include a firewall for security to protect the other network portion 29, which utilizes both TCP/IP and IPX/SPX formats in order to more efficiently handle the large
data files associated with sound tracks or other multimedia data. The TCP/IP format also permits the network portion 29 to be distributed among remote sites, such as over the Internet, which utilizes the TCP/IP protocol. Fig. 1 includes a depiction of the CD Production Network 29. Network 29 may be a multi 100 Base T Ethernet network. On the network may be a multiplicity of Extraction Agents running multiple jukeboxes, and multiple Assembly Agents running Ri age units that burn the CD's, as well as several Manual Extraction Agents (which supplement the automated extraction elements) . These manual elements are essentially a library that is available for 'sneaker net" integration into the work flow, i.e. they are brought by hand into a terminal that is on the CD Production network. The system described in this preferred embodiment is capable of handling the production of 5,000 customized CD's per day utilizing 200 ports on the CD Production network. It is conveniently expandable to at least 50,000 CDs per day output by utilizing 2100 ports, although there is no theoretical limit to the expandability of this system. As shown in Fig. 1, the system's operation can also be improved by the monitoring of the demand for space on the song queue buffer ,17. The monitoring takes place by noting the volume of the request made by data packets as they are unlocked by the order processor and the volume of requests that have been