WO2003100556A2 - Cd media anti-piracy generation and management system and process - Google Patents

Abstract

A system and process that provides for the creation of media that contain mechanisms to prevent unauthorized copying, process security, and flexibility of use. In addition, the system provides methods to create/save a media image, read/write information to/from media, incorporate media-based copy protection mechanisms, incorporate file based validation in connection with a logical defect applied to the media, and embed encrypted information within the media. This embedded, encrypted information can be read and interpreted by replicator imaging, mastering, and external validation programs incorporating either the 'plug-ins' or directly coded methodologies/algorithms to prevent false 'failure' results or inability to produce the disk from the protected copy.

Description

APPLICATION FOR PATENT

TITLE: CD MEDIA ANTI-PIRACY GENERATION AND MANAGEMENT

SYSTEM AND PROCESS

SPECIFICATION

Field of the Invention

The system relates to the software, plugins, and tools granting the ability to generate and subsequently validate CD-R and CD-ROM media incorporating anti-copy protection features and/or unique serialization for each produced CD-R that is compatible with existing systems and that can be incoφorated into external systems. Further, the system allows for external CD-ROM (Replication) mastering software to function with non-serialized CD-R masters incorporating copy protection in order to allow mass production of protected media.

Background of the Invention

Impacts of Piracy

In a 2001 report, the Business Software Alliance (BSA) states, "Piracy is the most significant problem facing the software industry globally today." One particular market segment, the entertainment software industry, clearly illustrates the formidable economic hardships caused by piracy. The Interactive Digital Software Association (IDSA) states in a 2001 press release, "...our industry's piracy problems remain deeply entrenched and pervasive in far too many markets." The same press release cites from an IIPA (International Intellectual Properties Association) report, "...entertainment software industry losses in the 50 countries studied will once again exceed $3 billion," and continues, "... this $3 billion figure does not even include losses attributable to Internet piracy, nor losses in other major markets such as the U.S., Canada, Mexico, and much of Western Europe."

"The cost of worldwide piracy to the industry each year is staggering," states the IDSA in its 2000-2001 State of the Industry Report. In the same report, the IDSA reports total sales for the entertainment software industry for 2000 were just a shade over $6 billion. Relating the industry piracy data to the industry sales figures indicates that the costs to the industry due to piracy approach that of its overall revenue generation. For nearly every dollar of legitimately sold entertainment software, another dollar's worth is pirated.

Beyond just gaming software, roughly one in four (24%) of all software applications currently in use in the United States are the result of piracy (SIIA). Globally, that ratio is more than one in three (37%) (SIIA). As Bill Gates, founder of Microsoft, has written, "The software industry has struggled with piracy since the advent of the personal computer, but as recent controversy over file sharing systems such as Napster and Gnutella illustrate, piracy is now a serious issue for any individual or business that wants to be compensated for the works they create."

"Don't expect Microsoft to back away from its piracy crackdown. The vendor estimates that 250 million users worldwide run its Office suite, though only 140 million copies are paid for." (InformationWeek.com) This translates into a 44% piracy rate for MS Office suite products (110M used via piracy / 250M in total use).

Thirty percent of business users who electronically acquire software use methods that are deemed piracy (SIIA/KPMG); 21 - 36% of business subscribers of content allow unauthorized access (SIIA/KPMG); 50% who access, redistribute unauthorized content (SIIA/KPMG); 30% of all digital content and software available over the Internet is not authorized by the Intellectual Property (IP) owner (SIIA). Despite heavy resources being spent to educate and legally rectify such actions by the business community, real revenue losses to piracy of this type are rooted in corporate disregard for IP protection. This disregard is based on the prevalent attitude that the Internet is free.

According to the BSA - "Digital piracy poses one of the single greatest threats to the success of the information economy. It undermines the confidence that creators and consumers place in their commercial interactions over networks."

According to the Software and Information Industry Association (SIIA) - "The numerous ways in which software piracy occurs, the ease of duplication and the high quality of pirated software present a significant problem for the software industry. A program that reflects unprecedented technology, years of effort and millions of development dollars can be duplicated or illegally distributed in minutes with the touch of a button. Any personal computer (PC) user can duplicate a product priced from $20 to $20,000 for no more than the cost of a blank CD or at no cost, and that user can make one, a dozen or a thousand functional copies." Not only does piracy have a profound impact on the software industry itself, but to the surrounding economy as well. In it's November 2001 U.S. Software State Piracy Study, the BSA summarizes piracy's impact on the U.S. economy as related to the packaged software industry: $8.3 I B lost retail dollars ($2.6B for business software alone). 1 18,026 lost jobs within the U.S. economy. $5.67B lost wages for the U.S. economy. $1 .59B lost Federal and State tax revenues. Piracy results in fewer re-investment dollars for the industry to support further development and growth and have far-reaching downstream effects on related industries (e.g. retailing, packaging, Value Added Retailers (VARs), Original Equipment Manufacturers (OEMs), etc.).

The magnitude of piracy's impact on the software and information industry and the U.S. economy as a whole is reflected in a flurry of digital security-related actions by the U.S. Federal Government. Most notable in the myriad of federal actions and legislation are:

Presidential Directive 63 - implement critical infrastructure protection (both physical and cyber-based systems) against vulnerabilities to equipment failures, human error, natural causes, and physical/cyber attacks. Enacted because of increasing reliance on IT and cyber supported infrastructures that, if breached, could gravely affect the U.S. economy.

National Plan for Information System Protection - the immediate result of

Presidential Directive 63.

No Electronic Theft (NET) Act - closed the loophole in criminal law that allowed people to distribute copied software over the Internet. Amended the criminal copyright infringement statute making it a criminal offense to distribute unauthorized software for either financial or personal gain.

Trade-Related Intellectual Property Rights (TRIPs) Agreement - protects

Intellectual Property rights (copyrights, trademarks, geographical indications, industrial designs, patents, integrated circuit layouts, and undisclosed information such as trade secrets) and provides enforcement via the World Trade Organization

(WTO). Digital Millennium Copyright Act (DMCA) - implemented two World Intellectual Property Organization (WIPO) treaties requiring member countries to provide protection to works from other member countries or created by nationals of other member countries. Added language obligating member countries to prevent circumvention of technological measures used to prevent tampering. Homeland Security Plan - includes several cyber-related funding initiatives to secure government and private sector assets.

Expansion of Department of Justice Anti-cyber Crime Group - increased funding to bolster the Group's efforts to combat rising trends in cyber and digital-related crimes.

Such actions by the Federal Government have served to elevate the issue of piracy to one of national importance and lay the foundation for legal actions against those who engage in piracy.

Software Industry leaders are moving to dedicate vast resources to combating piracy through legal channels. Microsoft, for instance, has boosted the size of its anti-piracy team from a couple of people in 1988 to about 250 today (now headed by Microsoft's Chief Legal Council). About half are in marketing and communications, trying to win mind share by convincing people and governments from Chicago to Beijing that stealing software is a real crime. The other half are in the Anti-Piracy Group, recruited mainly in the past two years from the Federal Bureau of Investigation (FBI), the U.S. Drug Enforcement Administration (DEA), the U.S. Justice Department and other law-enforcement agencies around the world. (Newsweek)

Additionally, companies such as Microsoft support and fund external organizations such as the SIIA and BSA whose primary function is to monitor software piracy on a global scale and attack it through resource intensive legal means.

Software pirates are being arrested en masse: Pirates are also accused of using the proceeds of the software sales to fund terrorist organizations and organized crime, and impairing their home countries' ability to participate in foreign trade and investment markets. (Wired News)

Even with heightened awareness and a legal foundation from which to prosecute known pirates, global piracy rates only edged slightly lower (by 3.5%) from 1995-1999 (BSA, SIIA). This slight effect was attributed to better product distribution, availability, declining prices, and government participation. Still today, 54% of business users and 57% of consumers are unaware that any policies against redistribution of paid-for content and software are in place (SIIA/KPMG).

Piracy rates are again on the upswing, though, with increased global Internet access, internal networks, affordability and penetration of media burners, economic growth, pirate-led online auction sites (approximately 840,000 today) and popularity of online peer-to-peer networks (BSA, SIIA).

Additionally, piracy rates are negatively affected by a widening gap between original software retail cost and pirated version price, even as retail software prjces are declining. Pirated Windows XP software, for instance, sells for as little as $1.50 in Asian markets compared to the $199 list price for the home PC retail version (Newsweek). This price gap ratio is about 40: 1 for the software gaming industry.

And as widespread piracy is the software industry's single most significant trade barrier (over Vi of the U.S. industry's global revenues are derived from foreign sales), an ability to have collectable control of pricing abroad is of paramount importance to the industry.

For instance, graphics software giant Adobe Systems may decide to leave the Chinese market and other Asian regions due to rampant piracy there, according to Adobe CEO Bruce Chizen. Chizen said in the article that it can cost up to $750,000 to produce a Chinese-language version of a product, and extensive piracy makes it difficult for Adobe to recoup those costs. (ZDNet) The severe market impacts and the awareness of those impacts have spurred a surge of interest in relatively low-cost technology-driven solutions to manage piracy.

Beyond the obvious negatives, software piracy does perform an invaluable service to most, if not all, companies within the industry. A software application's user base cannot be measured only by units and licenses sold as, in many cases, the number of illegitimate users approach or even outnumber legitimate users. The value of a broad and expanding application user base (whether legitimate or illegitimate purchasers) lies in its ability to generate new, legitimate sales.

A study published in the Journal of Marketing argues that more than 80% of legitimate software sales, within particular market segments, result from or are positively influenced by products that have been pirated.

Pirated software clearly holds significant value to its original manufacturer/publisher: o Piracy expands company, brand, and specific product user bases. o Piracy acts as a strong marketing vehicle, significantly extending the exposure of the company, brand, and product, o Piracy can serve to provide 'trial' versions to potential and future legitimate purchasers.

Piracy is a global multi-billion dollar issue for software manufacturers of all types. As pirated products directly and indirectly lead to as much as 80% of legitimate sales in particular market segments, the desire on the part of the industry is to manage the issue to its economic advantage. Altogether or virtually eliminating the issue would only serve to eliminate extended product user bases and, hence, a substantial source of revenue. Within the industry, though, needed piracy management features are highly variable based on market segments, competitive landscapes, and prevailing marketing strategies. The clear need is for an effective, affordable, and flexible solution that maximizes, on a company specific level, the formidable economic opportunities afforded through piracy management.

Creation of "Protected" Distribution Media

Various problems can occur when a company endeavors to utilize an "anti-copy" protection. Many times, the protections employed create problems for the end users as they are not compatible across the majority of the drives or devices, resulting in frustrated and sometimes hostile customers towards both the purchased product and the company itself. Many protections require that they be employed ONLY at the facility producing the final CD media, whereby the software producer does not actually get to see or test the "final" product until after the protection has been employed, as well as potentially thousands of CDs have already been produced. If there is a problem with testing of the protection, the disks already produced must be destroyed resulting in a loss of revenue prior to the product even being distributed, as well as additional loss of time to market for the product.

An additional problem facing the software producer who wishes to distribute their software on CD media is that the majority of the physical media protections that are out there are extremely restrictive in how the protection can be applied. It is either "good" or "bad," with no opportunity for the software producer to modify the actions taken by the system in case an unauthorized attempt to use is detected. An example of this situation would be where a company wishes to eliminate the basic consumer complaint that they have a "right" to make an archival copy, and that if something happens to the original, it is simply too much of a hassle with the software's producing company to get a replacement. Therefore, the system developed must allow the software producer to give the ability to a user, for example, to run a program from either the original OR the copy, however they can not install from the copy.

Providing the ability to uniquely serialize each individually produced CD-R allows for tracking of each individually produced copy of the application. Even if the application is to be eventually replicated (mass produced), initial "beta test" copies can be sent out, granting the software producer the ability to identify and track any initial attempts to distribute the software in an unauthorized fashion.

An additional issue facing software producers is with regards to the requirements for specific expensive hardware required in order to produce the required protection. This situation also applies to the mass duplicators and replicators who many times are required to make a costly investment in a protection technology for additional or specialized hardware, only to have to archive, or in some cases discard, the technology and hardware from the investment when the "next version" of the protection is delivered or available.

Still an additional issue facing those seeking protection technologies is the lack of overall options granted by the software protection solutions. For example, if a company offers a protection, it typically cannot be combined with, nor is it compatible with another type of protection. Therefore, the solution does not solve the specific need of the software producer.

Summary of the Invention

The present invention is a software solution that provides new and unique solutions to the problems previously described. It does this through innovative and new forms of file-based validation in connection with a logical defect applied to the media, with the capability to embed a unique serial number to CD-Rs that are produced. These items are listed as follows:

CD-R Local Mastering

The ability for the software producer to create an internal "Final" version/copy of the software as applied to the CD-Media is preferable, as the protected CD Media and application can be tested prior to delivery to the replicator for final creation of the CD-ROMs (Glass Master and subsequent stamped replicas). Some customers do not ship a physical disk, but rather transmit an image of the final disk electronically to the replicator, who utilizes that image directly. Therefore, the system has the ability to create and save an image. This image, for the purposes of security, is stored in a manner that it is not only a proprietary format, but has an optional password protection to prevent its utilization by an unauthorized entity. This image can be opened and used by the replicator's local copy of the system to open the image and produce a local physical master.

The system also has the ability to produce CD-Rs in a low-volume environment, whereby each CD-R is to be uniquely serialized. It therefore has the ability to import compatible serial numbers and utilize these for each disk, or "batch" of disks produced.

The system also has the capability to validate the file content of a produced CD (either a locally produced CD-R or a final replicate CD-ROM) to either another CD, a structure content from the hard drive, or from the original saved image itself. Since the validation is concerned with the content of the disk itself, the validation holds true even if the disk has been completely "remastered" to where the physical positions in relation to the CD and/or order of the files as written to the CD have changed. It is only required that the file structure be the same.

The System also has the ability to embed encrypted information that can be read and interpreted by replicator imaging, mastering, and external validation programs incorporating either the "plug-ins" or directly coded methodologies/algorithms to prevent false "failure" results or inability to produce the disk from the protected copy. This also acts as a "failsafe," as replicator software will not image or master from a protected CD unless either the plug-ins or methodologies have been incorporated/enabled. This prevents inadvertent mastering of replicate CDs without the protection, resulting in unusable replicates that must subsequently be destroyed and replaced, sometimes at considerable expense and loss of time/revenue.

The system entails a methodology that creates an unprotected "intermediate" master, and utilizes that to produce the "final" master CD-R. In addition to the software producer's original application and/or content/data, the intermediate master contains a series of "standard" files that vary depending upon the options that the software producer has chosen to employ. These files serve as physical "placeholders," but in the data area of the CD, as well as within the CD's file structure itself, providing no impact to the CD with the exception of specific areas based on requirements. Regardless, there is no physical change to order, physical position, or content of the original software application. Also, there is never a change to the intermediate master file structure.

Plug-ins and Direct Integration

The present invention approaches the issue of dealing with external software in two ways. CD imaging, mastering, copy, and validation software that will work with the invention's protection can be enabled either by "plugins" to the existing software in conjunction with the applicable technical requirements of the specific application, or by working with the individual application producer to allow them to directly integrate the required methodologies and algorithms directly within the code of their application.

These plugins and algorithms have the ability to decrypt, interpret, and subsequently report back to the individual application information regarding the protection employed that enables the system to perform the required task at hand.

Recording in "Disk-At-Once" (commonly referred to as DAO) mode writes the entire disk in a single step. The commonly used "Track-At-Once" (commonly referred to as TAO) mode writes each track independently, which requires link blocks between each of the tracks. Older CD-Recorder models forced a two (2) second pause (pre-gap) between the individual tracks whereas the newer models allow adjusting of the pause length in TAO mode reducing the number of link blocks to a minimal amount.

However, with TAO it is generally not possible to define the data that is written in the pre-gaps, however, it is this feature which makes audio CD recording (as well as within the audio portion of mixed mode CDs) that allows for hidden bonus tracks or track intros in pre-gaps that is common on commercially produced CDs, which is typically "missed" by many audio track recorders on the market.

Commercially available products for the imaging or copying of CDs perform "corrections" and in some cases completely rewrite whole sectors such as the last session lead- out of the disk.

In order to maintain the primary methodology of the system and to ensure and support the integrity of the system, the present invention comprises it's own internal CD-R read and write components, that have the ability to create an image and write that image without altering the contents of the CD in any fashion. To this end, the read/write components create an exact logical duplicate image of the original CD, and have the ability to create an exact logical duplicate from this image. These components allow the system to maintain its inherent methodology, while at the same time being powerful enough to have specific functional capabilities at a sector-by-sector level.

Brief Description of the Drawings

FIG. 1 depicts the initial "Splash Screen" of the product; FIG. 2 depicts the Main Options Screen " of the product;

FIG. 3 is a flowchart depicting the primary options from the Main Options Screen of the product;

FIG. 4 is a flowchart depicting the CD validation command flow of the product; FIG. 5 depicts a media protection validation failure result screen of the product; FIG. 6 depicts a media protection validation acceptance result screen of the product; FIG. 7 depicts a serialized media protection validation failure result screen of the product; FIG. 8 depicts a serialized media protection validation acceptance result screen of the S product;

FIG. 9 is a flowchart depicting the existing image burn command flow of the product; FIG. 10 depicts the existing image burn screen of the product; FIG. 1 1 depicts an example of user authentication keys;

FIG. 12 is a flowchart depicting the standard file creation command flow of the product; FIG. 13 depicts the existing image burn screen of the product; FIG. 14 depicts the changes in the CD image created by the protection process; FIG. 15 is a flowchart depicting the remastering process command flow of the product; FIG. 16 is a flowchart depicting the flow of the creation of a single protected CD-R utilizing the system;

FIG. 17 is a flowchart depicting the flow of the creation of multiple protected CD-Rs utilizing the system;

FIG. 18 is a flowchart depicting the flow of the creation of a protected CD-R for use as a master during replication utilizing the system;

FIG. 19 is a flowchart depicting the flow of the creation of a protected CD-R with electronic transmission of the CD-R image to the replicator utilizing the system; FIG. 20 depicts the primary remastering process screen of the product;

FIG. 21 is a flowchart depicting the content comparison command flow of the product;

FIG. 22 depicts the primary content comparison screen of the product where comparison is from existing structure;

FIG. 23 depicts the primary content comparison screen of the product where comparison is from CD;

FIG. 24 is a flowchart depicting the serial number import command flow of the product;

FIG. 25 depicts the primary serial number import screen of the product;

FIG. 26 depicts the serial number import screen of the produc- where successful import has been accomplished;

FIG. 27 depicts the serial number import screen of the product where import has not occurred due to error;

FIG. 28 is a flowchart depicting the replication process utilizing plug-ins;

FIG. 29 is a table depicting the ident file information records for a single ident file;

FIG. 30 is a table depicting the ident file information records for multiple ident files; and

FIG. 31 is a flowchart depicting the recursive logic for the reading of ident file records.

Those skilled in the art will recognize that the figures shown here represent just one method of providing the intended spirit of the invention. Accordingly, significant deviations from the figures are considered to be within the scope of the invention, and nothing herein shall be considered to limit the scope of the invention as dependent in the claims.

Detailed Description of Preferred Embodiment

The following terms are used in this application. Burned -The act of using a laser (via hardware device; e.g.: CD "Burner") to physically burn data onto a CD-R media disk in a manner that complies with existing industry standards. CD-R - A CD media that allows for a local user to permanently "burn" data using a laser beam recorder directly to the CD media. Typically used for "masters" prior to creating CD-ROMs, or for local consumer data recording in their homes. CD-R recorders are commonly sold in most electronic/computer retail stores. CD-ROM - A CD media format that requires special equipment not commonly available to the end user whereby the information is physically "stamped" into the media rather than "burned" as with a CD-R. This type of media is most common on mass distribution copies.

Final Master - A CD-R created by the software from an intermediate master whereby the information in the included "standard" files has been replaced, as well as copy protection being applied as required.

Ident File - A file residing on a produced CD that contains information regarding the protection, as well as other information regarding the remastering that may be applicable to replicators and validation software. Information is maintained in an encrypted proprietary format.

Intermediate Master - A CD-R, produced by the local software manufacturer that contains, in addition to their own product/software application and supporting files, "standard" files required by the software to be present in order to generate the "Final" master. The data in these files at this time is not relevant to the operation, as the data within these files is modified directly during the mastering process.

Physical Sector - A "0" based system, whereby the first 2352 byte block of data contained within a raw ISO image file is considered to be physical sector "0," whereby each 2352 byte block thereafter to be considered sequentially higher sectors.

Product - Refers to software distributed via CD-Based media.

Logs - Activity log features that have been integrated within the system.

SmarteCD™ Media - A preferred embodiment of the CD based media disk that contains one or more Smarte Solutions™ protections or information options of the present invention. A

SmarteCD™ is the byproduct of the SmarteMaster™ system.

The present invention, currently marketed in its preferred embodiment under the trademark as the Smarte Solutions™ SmarteMaster ^{I M} software, targets software and content distributors utilizing CD-R and CD-ROM media for distribution of their products. The system has mechanisms in place that enable software manufacturers to create CD media that has dynamic anti-copy features, as well as information regarding the applied protections in an encrypted format on the CD itself, enabling it to be utilized as a master for a replication process. Since the disk to be used for mastering during the replication process already has embedded copy protection, without a deliberate enablement of the Plug-in, the replicator will be unable to utilize the disk as the software will fail. This prevents inadvertent mastering and subsequent replication of CD-ROMs that would have to be destroyed due to failure to implement the required copy protection.

In addition to the application of copy protection, the software has other features. These initial options that the user is presented with after the initial "splash screen" are displayed in FIG. 1. The options available to the user for the software are as shown in FIG. 2. A flowchart depicting these options is shown in FIG. 3.

The first option available to the user is the ability to validate that a protected CD-R or CD-ROM has the copy protection embedded properly, as well as additionally validate that a compliant serialized CD has a valid/proper serial number on it. The command option layout is as shown in FIG. 4.

For Option 2-3-1 , validation includes the requirement that the CD being validated incorporates the compliant serialization and therefore the CD will fail validation if an invalid or missing serial number condition exists, regardless of whether or not the CD has the proper copy protection applied. Option 2-3-2 is therefore given for those CD's that incorporate the protection, but are not serialized. In both cases, the copy protection must be present, and the user must specify the path and name of the target file.

The results of the validation are displayed to the user. For validation of media protection only, a "failure," or CD in which the validation fails or determines that the CD is not an original CD is as displayed in FIG. 5. An acceptance of the validation of the CD is as shown in FIG. 6. Where the CD itself has been serialized, a validation failure is as shown in FIG. 7, and a validation acceptance is as displayed in FIG. 8.

The next option available to the user is that of creating a CD-R from a preexisting image. When a CD-R is mastered initially, the user is given the option to "save" an image of the CD in order to make copies at a later time, as well as allow the user to send the image to a replicator electronically. This image is saved in a proprietary format, which can be protected by a password, and subsequently decoded and used to create a physical copy of the original physical master using this option. If a password was used to protect the image, then the user will automatically be prompted to enter it. If the password is not entered correctly, the image will not be decoded. The basic command options for this function are as shown in FIG. 9. The initial screen displayed to the user from which they select the image is as shown in FIG. 10. The next option for the user of the software is the core functionality of the system itself, which is the ability to create a protected final master from an intermediate master, however, prior to performing this function, the user must create an "Intermediate" Master disk from which the software can remaster into a "Final" master.

Prior to the creation of an intermediate master, the user must decide on what features of the system are to be employed. If the CD is to have "copy protection," then a "target" file must be added to the remainder of the user's application, data, and support files to be written to the CD-R. If a compliant serial number is to be used, a serial number file must be added. If a clear "text" label file is to be used to indicate to an automated reader/printer combination unit text that must be printed on the outside of each individual or batch of CD's, then a "Label Content File" must be added. Examples of the use of serialization would be to uniquely identify each individual CD-R for application license management, or for unique user authentication "keys," that can be tied to an individual user for the purposes of user authentication. An example of a "key" of this type is as displayed in FIG. 11.

If the CD is to be used as a master for a replicator to create CD-ROM's, then an ident file must be added. In addition to this, if there are sufficient options that warrant more than nine (9) individual references within the ident file, then additional ident files must be added.

The prerequisite to add these files is based on the methodology employed by the software, to where the structure of the CD itself remains completely unaltered, and the protection and data are added to the image directly, as opposed to adding additional sessions, or altering the final size or number of sessions originally created by the software manufacturer at the time they created the intermediate master. Under this methodology, the only limitation as to the creation of the intermediate master other than the required "standard" files is that the format of the CD be in a 2352 byte sector format that is the current standard for the industry, and is automatically utilized by virtually all CD-R software sold/used today to burn CD-Rs from local machines.

A detailed description of these requirements is available to the user within the program itself at all stages up to the point of committing to the final master physical creation process as well as from the Main Option screen.

Re-Mastering A CD with options requires that the user first create an intermediate master that contains the complete application, as well as any additional files required for the specific options to be employed. Pre-Burn requirements specifically relate to "standard" files that must be included with the intermediate master prior to incorporation of the options. These file requirements will vary depending upon what methodology/option the user intends to utilize. Some of the options do not require physical files to be burned to the intermediate master, while others may have requirements beyond just the individual CD itself.

Obtaining the "Standard" Files

The ability to create the "standard" files that are required is given from the Main Options Screen displayed in FIG. 2. The command process options for the creation of "Standard Files" are displayed in FIG. 12. The user can create some or all of these files on their hard drive for utilization with the intermediate masters. The user screen for the selection of which files to create is displayed in FIG. 13.

The following are the intermediate master requirements for utilization of the various options:

Copy Protection Methodology #1:

A file exactly of 46,291 bytes in length (as reported by DOS/Windows™ - Actual, not "used") must be included on the intermediate master. It is irrelevant as to the path/filename of the file as it resides on the master, however this path must be known, as it must be entered from the option screen. The content of this file is also irrelevant, as any content within the file will be inaccessible in the final master.

Leaving Open/Forcing Closed:

If this option is available, it refers to allowing the CD to be left "open" for additional/subsequent writes, or optionally to protect the CD from being written to (additional sessions) in the future. Note that some software may be unable to write to this CD even if left open if copy protection methodology #1 has been employed. There are no "file" requirements regarding this option.

# of Copies to Burn:

This allows the user to burn multiple copies from a process, instead of having to go through the entire process for each individual CD. While there are no specific "file" requirements pertaining to this option, refer to specific additional requirements with regards to serialization if serialization is to be employed. Serialization: The user must have previously imported, and have enough unused serial numbers in the system to enable the total number of copies to be burned. Individual serial number import files are issued only from a central source at an entity to ensure that they are globally unique across all applications and utilizations. In order to use serialization, the user must copy the following file: "MMCDVAL1.MCD" to the ROOT directory of the CD. If the user chooses to have 5 (five) copies of the content serial number for survivability, then the following files must also be copied to the root directory as well: "MMCDVAL2.MCD"; "MMCDVAL3.MCD"; "MMCDVAL4.MCD"; and "MMCDVAL5.MCD." These will be modified by the system as needed in order to provide the unique serialization from the available serial numbers, but MUST exist prior to serialization being employed. In a multi-session environment, it is irrelevant in which session they are added, provided that they are added to the root directory of the CD.

For those users that plan to "print" a serial number on^' the CD itself utilizing a programmable printer that can read content, the system can make available the serial number to print externally (an algorithmic variant of the encrypted serial number in the 5 content files) in a clear text format. In order for this to occur, the following file: SSCDVAL.LBL must be copied to the ROOT directory of the CD. The individual content of this file will be modified by the system. The output within this file will be a simple text file that can be read by programmable printers and subsequently be able to print a unique serial number for each CD.

Fail-Safe

The "Fail-Safe" mechanism is only applicable when preferred copy protection methodologies have been employed. This provides an identification file to the end replicator that allows the "Protected" master to be mastered at their facility, instead of "failing" during the mastering process due to the inherent copy protection. This helps to prevent inadvertent errors in replication, such as replicating without the protection, thereby producing useless disks ("coasters"). In order for this to occur, the following file MUST be added to the ROOT directory of the CD: "SSICDVAL.DAT." The present invention must modify this file's content and name/attributes as required. This file is referred to as the "Ident" file.

File/Structure Layout

The layout of the files/data on the intermediate master, as well as the modification performed during the mastering process is displayed in FIG. 14. To reiterate, the only part of the image that is altered is only those areas of the image that are specific to the preferred protection technology, and therefore, outside of the 2352 byte sector format requirement, there are no other format, size, or mode restrictions placed on the user in the creation of the CD-R intermediate master. This includes multi-session and mixed data/audio mode CD-Rs as well.

In order to create the required "standard" files for use with the intermediate master, an option is available from the Main Options selection screen that takes the user to the standard file creation option screen. From this screen, the user selects which files they want to create, the path to create them to, as well as specifying naming requirements for the files themselves where applicable, as with the case target file. At the user's option, however, the target file itself can be renamed at anytime to suit the individual need/application. The other "standard" files must remain as named.

The basic flow for the command process of remastering is as displayed in FIG. 15. From the Main Options Screen, the user selects the option "Re-Master a CD with Smarte Solutions Options." The information and requirements regarding the intermediate master previously note are displayed to them [2-5-1 ].

The general flow of the creation of a single protected CD-R is displayed in FIG. 16. The general flow of the creation of multiple serialized protected CD-Rs is displayed in FIG. 17. The general flow of the creation of a protected CD-R for use as a master for replication (mass production) is displayed in FIG. 18. The general flow of the creation of a protected CD-R for use as a master for replication (mass production) where the image of the CD is electronically transmitted rather than shipping of the physical produced master is displayed in FIG. 19.

At this point, the user can create the intermediate master using his or her own local software. If they have already created the intermediate master, and are sure that it meets the requirements for the options they intend to implement, they can proceed to the next step.

At this point, they are instructed to place the intermediate master in the drive, and the system reads the intermediate master to determine if it does in fact have the required files needed [2-5-2-2]. At this time, based on the preferred software evaluation of the intermediate master, software displays to the user the options that are available to them regarding the specific CD. The user's options at this point are as follows:

"Review Intermediate Master Requirements in Relation to Options" [2-5-3-1].

This option displays for the user the same information that they were presented with when they initially selected the option to perform the re-mastering process, without forcing them to go back to the beginning of the process. In this manner, if the user feels that a particular option should be available that is not, they can refer back to this information without having to interrupt the current mastering process, forcing a complete re-evaluation of the intermediate master. An example of the basic screen is as displayed in FIG. 20.

"Add^" [2-5-3-3] and "Remove*-" [2-5-3-4]

These two options refer to the user's ability to select the target file that is to be corrupted. Under the protection methodology, the target file's only specific requirements are that it be 46291 bytes in length, and reside in a directory structure less than 8 deep (standard operating system CD-R requirements) where it can be accessed by the operating system in a normal manner. The session that the file is burned to the CD, as well as the physical position on the CD itself, are irrelevant to the process or methodology. The name of the file, including the file extension, and the path that the file resides in are completely up to the user, allowing them to either segregate the file, or make it more difficult to spot by giving the file a name similar to other files within the same directory. Since there is always the possibility that there may be a file on the CD of 46291 bytes in length that is not intended for protection, the system recurses the file structure and lists those files, which meet the requirements. A listing of these files is presented to the user entitled "Available Files," while a second list is presented, initially empty, which is entitled "Files to Protect."

It is also at this point that the user specifies the total number of CD-Rs to burn during this session. The user also selects whether or not (if available based on condition of the intermediate master) whether compliant serialization is to be applied. Also, depending on whether or not the proper standard files are present on the intermediate master, an option to create four additional serialized files for "survivability" will exist.

As with the serialized files, if the user selects the option to apply serialization and the proper standard file exists on the intermediate master then the user is also given the option to include a clear text "variant" of the encrypted serial number in a "Label Content" file. This file can be used by more advanced CD Reader/Printer combination units that can use this file to determine physical print content to be added to the existing printing either taking place at the same time or supplemental to a prior printing operation.

In addition, if multiple CDs are to be created and the user has selected serialization as an option, the user is also given the option to either retain the same serial number for all copies, or to uniquely serialize each individual copy produced, provided that they have enough remaining serial numbers in the system to cover the quantity they are burning.

If the disk is to be utilized as a "master" for replication purposes, then the user will select the option to create a "Mastering Failsafe," which is the screen term for the ident file. As with serialization and the copy protection itself, a "standard" ident file must exist on the intermediate master in order for the ident file information to be applied in the final master.

Once the user has finished selecting their options, there are several paths that the system can take at this point, depending upon options and customized options for the individual customer that have been enabled.

If, due to the number of options and/or individual custom reporting requirements within the ident file, multiple ident files are required, then the system will next ask the user to select and/or specify the required "linking" ident files.

The system then displays a summary of all selected options regarding the final master to be produced, as well as gives the user final options to utilize "Customer Specific" options and to save an image of the final master.

For security purposes, the image file itself is maintained in a "proprietary" format. That can also be "locked" with a password. The purpose of this is NOT to "protect" the image from the user, as the image is decrypted and visible during the mastering process. It is saved in this manner to prevent it from being utilized to create unauthorized copies from other software, as well as the password helps serve to protect the file from unauthorized use by parties with legitimate access to the software.

This feature permits the proprietary image to be sent electronically to another source for validation, rather than rely on the physical shipment of an actual CD-R. In addition, it allows the original user who performed the remastering process to save the image so that additional copies may be created at a later time, without having to perform the entire remastering process from "scratch." If the option to save the image file is selected, the user is asked to specify the file name and select the path under which the file will be saved.

At this point, the user will select the command to proceed to the next step. If there are no customer specific options available, or the user has selected not to utilize them, then the system will move to the final mastering Process. If there are customer specific requirements, options, or actions that are available and the user has selected the option to utilize these, the system will present these to the user at this point. The specific customer requirements are not necessarily limited to scope or functionality, but would be such that they either directly or indirectly affect the physical process, the information retained within the ident file, or the logistics of the operation in some manner external to the system itself. An example of this would be a customer having a proprietary or internal validation software that creates an image or validation file that is proprietary to them. Since their software will utilize this format to validate the final master's content or disk itself, a customer specific option may be developed that would interpret the original created image and record in a "customized" format within the ident file itself the information that links the actual CD-R content to the relevant information required by the customer's own proprietary image.

When the mastering process starts, the image is "modified" as required, any "customer specific" requirements are performed the CD-R is burned (multiple CD's burned if required). If the image was to be saved, then the image file is saved. In the case where multiple CD's are burned and no serialization is used, or where a single serial number is used for the "batch," the same image is utilized for all of them. In the case where multiple uniquely serialized CDs are burned, then it is imperative to retain all of the data for each individual image. However, since a single image may be up to 700MB in size, this would rapidly deplete any existing hard drive or storage device capacity.

This issue is resolved by utilizing the system methodology. Under this methodology, only the individual sectors applicable to the process are overwritten with the remainder of the image left untouched. For uniquely serialized CDs run in a single batch, only the individual sectors containing the serialized data themselves are changed, and therefore, with the exception of the primary image itself, only these varying sectors themselves need to be retained. In this manner, when this image is opened and used to create a CD-R, if individual serialization has been utilized, the system will ask the user to specify the individual serial number they want to create an image of. Since the individual sector information for each serial number used is stored (2352 bytes as opposed to potentially 700MB for each serial number used), under this methodology the sector in the primary image is simply replaced/overwritten with the data of the applicable sector containing the desired serial number. In addition to this is also the optional "Label Content" file, whose sectors are also saved under this scenario. Since it is not practical to work from the proprietary/encrypted image, a temporary non- proprietary image and supporting files are utilized during the mastering process. These files are deleted from the system after the mastering process has been completed. It is not the intention of the system to protect the file data from the user creating the master, but to simply protect it from outside sources not authorized to work with it, however, the system does take steps to make it difficult to get this data in it's raw form.

The image from the intermediate master CD can not be used directly to make a valid CD that will function as intended. Therefore, the changes to the intermediate file master are performed immediately prior to the start of the burning session. Immediately following the last CD to be burned, the image is saved in the proprietary format, with any original information deleted from the system immediately following this. In addition, where possible, an exclusive system "lock" regarding access to the file itself is enabled. While this is not designed to be "hack-proof," it is designed to hinder or prevent the vast majority of users from being able to get to a "raw" copy of the image file itself.

Once a final master has been created, there is an inherent need to ensure the quality of master that has been produced. To this end, the system incorporates the ability to validate the file content as burned to the CD. The user can compare either between two CDs, or in cases where the contents/structure on the CD was burned from an existing structure/content on a hard drive, the system has the capability to recurse through the hard drives structure and perform the file content comparison as well.

This option is available to the user from the main options screen. The command options flow is displayed in FIG. 21. Once the user has selected this command, the comparison options screen is presented, and the user is given the option to either compare from an existing structure on an available hard drive, or directly from another CD.

Once the user has selected the source for the comparison and specified the drive in which the CD to be compared is located, they select the command option to start the process. Once the process is started, the system recurses through the directory and file structure on either the hard drive or CD specified that holds the information that the target CD will be compared to, and creates a temporary list on the local hard drive of all files, including path in relation to the indicated starting position, or "root directory." Once this listing is completed, the system then uses this list to retrieve each recorded file individually, and directly compares the contents of each file in a binary mode (compares the actual individual character rather than the representation of the character - e.g.: case sensitive). There are two modes of comparison given, whereby the first compares the contents of the file in "blocks" of data, while the second mode retrieves each individual character one character at a time. The advantage of the "block" method is that it is inherently faster than the individual character method, while the individual character method is more accurate for a testing perspective, not because there is any difference in the binary comparison results, but because the system is forced to read from the drive for each character, and therefore is more likely to locate an error based on a physical anomaly if one should exist.

The system, under both methods, in addition to reporting variances in content of the files, will also report whether files are missing, or whether and I/O error occurs on either the file being compared, however, since the initial file "test list" is created from the target source, ONLY those files in the target source are compared, and if there is an "extra" file on the target CD, it will not be validated or even checked. For example, some CD burning software adds one or more additional information or identification files to the CD. Since the purpose of the comparison check is purely to ensure that the intended files have been recorded correctly to where the intended content is not corrupt, these extra files are never noted by the system, unless they exist on the hard drive directory or on the CD used to create the initial comparison listing.

The results of the comparison testing are then displayed to the user. The results are also stored in a text file, and the user has the option of recording every file checked, or simply just the errors noted. Regardless, a summary of the results is maintained.

The following result conditions, with specific respect to the preferred options are noted as follows:

Where the ident file on the disk or structure being compared is a "standard" file, and is being compared to an intermediate master, there should be no variance reported, however, when compared to a final master, an error indicating a content variance in this file will be reported. This is normal as the final mastering process purposely modifies the contents of this file. If the error received however indicates an I/O or readability error the disk must be remastered, as this is indicative of a failed process. This condition is the same for all files specific to options whereby a "standard" file is eventually changed during the final mastering process, including serialization and serialization label content files. In addition, on a final master, the specified "Target" file should always report an I/O error. This is a desired feature of the protection, however, any file reporting an I/O error other than the applicable target file is an indication that the final master was not created properly.

An example of the user screen displayed during the content verification process from an existing structure to a CD is shown in FIG. 22. An example of the user screen displayed during the content verification process from a CD to another CD is shown in FIG. 23. Note also that this functionality is not limited to only produced CD's, but can be used to validate content for normal CD-R creation externally to the product as well.

During the process, the user is given the option to save a protected/proprietary image of the final master for either later use or for electronic transmission to another source. The source, upon receiving this image can utilize it to create a duplication of the master that was produced previously provided the following conditions are met:

The user has a valid image file set that has been unaltered.

The user knows the password (if the file is "locked") to unlock the file.

The user has a licensed version of the software.

The user has the "physical" token or key required to unlock the file set if this requirement has been entered.

The option to perform this operation is given from the Main Options selection screen. Once the user selects this option, they are presented with the processing screen for this process. Once the process is started and the user has specified the required information, as well as placed a blank CD in the applicable CD-R drive, the system decrypts the image file (as a temporary file) and creates the duplicate master. Note that the original remastering options are not available to the user, as the user is not permitted to alter the image once it has been finalized. Note also, if there were originally multiple uniquely serialized CDs created at the time that the applicable image file set was saved, then the user must select which individual serial number of the total list provided that want to re-create. Once the user has confirmed their desired options based on what is available from the system, they are instructed to insert a blank CD-R in their burn drive. Confirming the insertion of the CD starts the process of burning of the duplicate CD from the image. Once the process has been completed, the decrypted (temporary) CD image is overwritten and deleted from the system. The original encrypted file remains untouched.

The individual read/write components are unique in that they provide the following capabilities to the software: Ability to custom address specific sectors with errors and handle exceptions (with regards to A-Time, Q-Channel, and P-Channel).

Ability to define override data for individual logical block addresses.

In addition to the unique functionality of these components, these components are consistent with specific industry functionality such as:

"Burn-Proof Technology

Full control over length and contents of pre-gaps (pause areas between tracks). Pre-gaps may be completely omitted, for example in order to divide live recordings into individual tracks.

Control over sub-channel data such as: Catalog number

Copy, pre-emphasis, 2-/4- channel flags I SRC code Index marks

Support for exact audio, data, and mixed mode (by session)

Individual tracks may be composed of different audio files supporting nondestructive cut.

Accepts WAVE and RAW audio files.

CD-TEXT reading and writing with drives that support it. In addition to this, these components are designed to be as industry compatible as possible, working across SCSI, IDE, and USB interface type devices.

An entity, preferably a central entity or one of their authorized representatives, must originally generate serial numbers used by the system in order to maintain a true uniqueness for each batch produced in a global methodology. In this manner, regardless of the system producing the CDs, no two serialized CDs ever produced should ever be the same, unless created by the software itself by the original software producer in accordance with the functionality and restrictions of the system.

The user receives the serial number file(s) from the entity, preferably Smarte Solutions or one of their designated affiliates, and copies the file to a drive where the system has access to it. From the Main Options screen of the system, the user selects the option to import a serial number file. The command options flow for this process is displayed in FIG. 24. An example of the screen displayed prior to the start of import is displayed in FIG. 25. Once the process is started, the system validates the structure of the file, the integrity to ensure the data has not been tampered with, and whether or not the file has been previously imported, regardless of whether it has been renamed or not. Provided that the file import validations have been met, the information from the file is imported, and those serial numbers become available for use by the System. If multiple files are to be imported, an option to start the process for another import file is given following each successful serial number file import. An example of the system screen displayed to the user following a successful import process is shown in FIG. 26. An example of the system screen displayed where the import file has been determined to be invalid, corrupt, or duplicated is displayed in FIG. 27.

The serial number itself is a 220 character "intelligent" encrypted file that allows the individual CD to be tracked not only be serial number, but date of generation and individual generation site. Encryption follows the proprietary random based encryption methods, and is fully decipherable only by the local serial number generator system, however the system can decipher enough of the serial number to ensure that it is a valid number.

The target file used by the system may reside anywhere within the standard path requirements of the CD (no more than 8 subdirectories in depth, and may carry any name within the naming convention restrictions of the Windows™ 32-bit operating systems (Windows™ 95, 98, ME, 2000 Variants, NT, and XP). Note that this methodology and target file can be utilized in Windows™ 3.x 16 bit and 32-bit operating environments utilizing the standard DOS "8.3" naming conventions. This target file is corrupted by the system during the final mastering process. The detail regarding the target file and the corruption is as follows:

Prevents most CD Burner copy software from outright duplication of the CD, however does not prevent "re-mastering" of the contents of the CD. Regardless of whether or not serialization is included, all compliant CD's maintain a media manipulation technique in order to verify whether or not the disk is an original, or a "copy." Details of this protection are as follows: o A file is "corrupted" at the beginning in order to drive an I/O error from the operating system. The defect is of sufficient size as to cause difficulties in casual copying practices, as will always generate a failure if a "pre-recording" test phase is initiated. o The defect itself is specific to a standard "File," NOT a physical location on the CD media itself. The validation software looks for the file, NOT the defect, o The CD's TOC is unaware of the defective area, and reports correctly the files size, etc. o The defect created MUST be such that the targeted area is unreadable (none or bad media format) such that it drives a system I/O error.

^■ File size will always be: 46291 Bytes (as reported by TOC)

^■ Original content of this file is IRRELEVANT o Defect Specifics

^■ Defect BEGINS at the first byte position of the target file REGARDLESS OF POSITION OF THE FILE ON THE CD.

^■ Defect Length: 2 - 18 Sectors in Length

^■ Defect essentially destroys the front end of the file on the CD.

While the system has the capability to corrupt multiple target files on the disk, typically it is sufficient to corrupt only a single file.

The system, prior to distribution, is "hard coded" with a unique value for each individual copy produced. This also allows hard coded options specific to particular customer to be permanently "turned on" or "turned off' within the application itself. To further protect the security of the system, no copy is distributed without first undergoing protection via third party anti-hacking/anti-piracy application encryption and protection.

Once the user has a finished master, this master (or a copy of the master if the user has used the option to create multiple copies either during initial remastering or subsequently from the saved image) can be sent to a replicator for mass production of the media on CD-ROM. In addition, if the replicator themselves have a licensed version of the system, the user can transmit the system saved image electronically to the replicator, who can utilize the system to generate a physical master from the image. Optionally, this image can be locked from unauthorized use with a password.

The replicator, utilizing imaging and encoding software enabled with technology of the present invention, either through plug-ins or direct implementation of the methodology, can use this physical master throughout their process. Replicator software not enabled with either the plugins or direct implementation of the technology will fail when attempting to utilize this physical master due to the protection employed. This functions as a type of "failsafe," which prevents inadvertent mastering of the disk without the required protection. Since the application itself will dynamically check for this protection, any disks produced without this protection would have to be subsequently destroyed. This failsafe methodology prevents this from occurring. The basic process flow for the mastering process for a replicator using a plug-in is displayed in FIG. 28.

The initial step during a mass production process for the replication of CD-ROM media is that of imaging. In a manner similar to the way that the system itself creates an image, the replicator must create an image of the disk. The replicator's imaging software however, will fail to produce an image, as it will interpret the existing copy protection as "bad media." To allow this process to occur, the plugin interprets the ident file on the physical disk and reports back to the imaging system which physical sectors it needs to either "skip" or ignore depending on the individual imaging software. This allows the imaging software to produce an image and proceed to the next step in the process. Depending on the individual imaging software, the plugin may produce a text based "list," send the information directly back to the software, or allow the imaging software to directly interpret and read the ident file on the physical master itself. At this point, if the system itself is designed to use such text "lists," the plug-in may also create another listing for use during the next phase of the process.

The next step in the process is for the replicator to encode the image to a glass master. It is from the glass master that a physical "stamper" is produced which embeds the CD-ROMs during the mass production stage.

Typically, at this point, the imaging software has "corrected" or interpolated data for the sectors it was previously instructed to "skip" or ignore. If the image were to be encoded to the glass master at this point it would not contain the protection required, so instructions are given to the encoding software at this point regarding specific sectors, enabling it to re-apply the original protection to the indicated sectors. As with the imaging phase, this may be done by producing (or utilizing a previously generated) a text based "list, send the information directly back to the software, or allow the encoding software to directly interpret and read the ident file on the physical master itself. The encoding software reports back to the system as required producing an acceptable glass master. From this point in the mass production cycle, the process is unaltered, including the process in which the physical glass master and subsequent "stamper" are created.

Once the "stamper" has been created, for Quality Control purposes, some mastering systems allow for validation of the "stamper." As with the imaging process, the same technique is used to instruct the validation system which sectors to "skip" or ignore. If the methodologies and plug-ins were not employed at this phase, a false "bad media" error would be reported when the validation reached the portion of the "stamper" containing the copy protection. Again, as with the imaging phase, this may be done by producing (or utilizing a previously generated) a text based "list," send the information directly back to the software, or allow the validation software to directly interpret and read the ident file which also now resides on the physical "stamper" itself.

At a predetermined point following the start of the production of the actual CD-ROMs, one or more of the produced disks are validated for quality control purposes. As with the imaging process, the same technique is used to instruct the validation system which sectors to "skip" or ignore. If the methodologies and plug-ins were not employed at this phase, a false "bad media" error would be reported when the validation reached the portion of the CD-ROM containing the copy protection. Again, as with the imaging phase, this may be done by producing (or utilizing a previously generated) a text based "list," send the information directly back to the software, or allow the validation software to directly interpret and read the ident file, which also now resides on the CD-ROM itself.

Custom, or individual customer software information requirements may also be contained within the ident file, and this information can be made available in the same manner as with the imaging system.

In addition to mass production via the replication process of CD-ROMs, the technology can be employed for smaller scale runs via specialized duplication equipment enabled with the protection technology. In order for this to occur, the duplication equipment must have the capability to either itself read and subsequently burn copies in a specialized "RAW" mode, or to directly incorporate read/write utilities. Since not all RAW mode readers and writers create and subsequently produce an "exact" image, the entity may need to qualify the system prior to its use. For the duplication process, there is no glass master or stamper required/produced. CD-Rs produced using specialized duplication equipment may still be subject to the same quality control validation requirements. As with the replication imaging process, the same technique is used to instruct the validation system which sectors to "skip" or ignore. If the methodologies and plug-ins were not employed at this phase, a false "bad media" error would be reported when the validation reached the portion of the CD-R containing the copy protection. Again, as with the imaging phase, this may be done by producing (or utilizing a previously generated) a text based "list," send the information directly back to the software, or allow the validation software to directly interpret and read the ident file which also resides on the CD-R itself.

The ident file itself is designed so that it never exceed 2048 bytes in size so that it can be completely retained within a single sector on the CD. There can be a maximum of 9 total informational records and one ending record within a single ident file. If additional information records are required, then the last two records are reserved as "link" records, which direct the applicable system or plugin to the "next" ident record that contains additional information. When a file contains "link" type records, there may be a maximum of eight (8) informational records, as link records are always supplied in pairs (two separate records). The basic layout of the ident file where a single ident file is required is depicted in FIG. 29. The basic layout of multiple ident files where a multiple ident files are required is depicted in FIG. 30. The ident file itself has the following features:

Information contained within this file is encoded/encrypted in a "non-standard" format, such that it is protected from cracking but can be "decrypted" via required tools and mechanisms.

Information is retained such that future variations or methodologies may be recorded, in a manner that "down" versions may recognize an upgraded reference, even though it may not be able to perform the functions required.

Information contained is such that future variations may be "stacked," or "mixed," as well as references to multiple variations of current and future protections may be recorded.

Information is such that a single "block'Vfile is contained within a single physical sectors user data block on the CD, with the size of the file remaining consistent. Information is such that the structure and methodology allows for multiple files to be stacked together, in the event that additional (more that 8) separate references to individual protections are required.

Applies a solution to the use of ambiguous spaces following the file name in the link record path/file name data to prevent abnormal truncation of data by C, C+,

C++, and Visual C (and related) programming languages.

This file is a readable data file (data encrypted) that contains the information regarding the current, as well as future versions of the protection of the present invention. It acts as an information file for mastering house software to derive information regarding employed protections on the supplied master disk. This file can also be interpreted as well by quality control in order to determine whether "defects" are intentionally produced or not.

Initially, the "usable" content of this file will be small, but must be variable in order to maintain future variations of protections that may be employed. Currently, only the file based "defect" is produced, however as protection methodologies evolve and expand, this file needs to be able to evolve as well, but in a manner that can be consistently read, allowing both backwards AND forwards (identification) compatibility to our tools.

The Attribute Setting of such ident file(s) will always be set to H+ (Hidden). The originating file name/path itself will ALWAYS be: "ssifsdat.sys" All jump files must follow the "8.3" naming convention (no extended file names), with total filename and path (allowing for double backslash characters within the string to avoid "escape" character difficulties) must be equal to or less than 98 characters (bytes) total.

Since the base unit involved is the physical sectors on the CD, that measurement is utilized to provide the basis for compatibility. Additionally, the second unit utilized by system to determine position within a CD is that of the "ATIME," which is indicative of minutes, seconds, and a subdivision of "frames" within each second (typically 75 per second). The ATIME information must therefore also be maintained within the records. This consists of a series of records, fixed length, that are managed initially via VB "Random/Binary Access," as well as a simplified variant of EDI methodologies, and subsequently encrypted using internal routines/algorithms. Since BOTH Joliet and ISO structures must be dealt with potentially, it is not practical to attempt to maintain within the ident file record itself file/pathname, as that, in itself, could potentially take up more than 2000 bytes for just the first record.

This file, for practical purposes, is designed to be less than 2048 in ALL cases, to prevent having to cross/append multiple sectors, although it is envisioned that we may have to eventually do this. Therefore, based on the subsequently defined record size, the file size will be 2000 characters or less. Since the unused portion of the file is populated with random characters (ASCII 33-254), it also makes attempting to break the file's encryption "pattern" virtually impossible without knowing the format to begin with where additional encryption of the records is utilized.

If there were previously 9 records and another is added, then the protection reference record in the ninth position is moved to the first record position of the linked file, as the last two "records" are utilized to indicate the linked file.

Typically, a total of 8 separate protection references may be made within each ident file (9 provided there are ONLY 9 references and NO "jumps" to another file), with no inherent internal limit to the number of ident files that can be chained together in series.

Once a "Link Record" (or Link Record "set) has been read, all remaining data within the record is ignored and the read process is considered to be complete. Following a "Link Record," the remaining space, if any, within the file, are filled with random numeric characters.

The basic read process (file access based) is displayed in FIG. 31.

The first character of the record, regardless of the reference, will ALWAYS be used to identify the TYPE of record, and subsequently, the layout of the information within the record itself. With the exception of the "0" type records ("Link" type) there is no specific order required or determined for the records based on record type.

The actual format of the information maintained within the record is up to the developer, however the following information must be maintained: Record Type "0" (Link Record) o Record Type indicator: ALWAYS "0" [Link Record Value = "0"] o Link Record Type Indicator:

■ "0" - Indicates Ending Record

■ " l " - Indicates Additional File - File Path Reference ^■ "2" - Indicates Additional File - Physical Sector Reference o If the Link Record Type Indicator is "0":

^■ Random Characters - (Chr: 033 - 126) to Fill Record o If the Link Record Type Indicator is "1 ":

^■ Path and Name of Next Link File Padded to the Right of Applicable Data with ASCII 065 ("?") o If the Link Record Type Indicator is "2":

^■ Physical Sector Containing Data for "linked" record

- ATIME of Sector Containing Data for "linked" record (MM:SS:FF)

^■ Random Characters - (Chr: 033 - 126) to Fill Record

Record Type "1 " (Smarte Solutions Protection Type "1" Indicator Record) o Record Type indicator: ALWAYS "1 " o First Physical Sector of Corruption o First Physical ATIME of Corruption (MM:SS:FF) o Last Physical Sector of Corruption o Last Physical ATIME of Corruption (MM:SS:FF) o Mode Value o Random Characters - (Chr: 033 - 126) to Fill Record Record Type "S" (Image Content Change Sector "Skip" Indicator Record) o Record Type indicator: ALWAYS "S" o First Physical Sector of Content Change o First Physical ATIME of Content Change (MM:SS:FF) o Last Physical Sector of Content Change o Last Physical ATIME of Content Change (MM:SS:FF) o Mode Value o Random Characters - (Chr: 033 - 126) to Fill Record Record Type "P" (Proprietary/Custom Information Indicator Record) o Record Type indicator: ALWAYS "P" o Secondary Record Identification indicator: Varies on Application o Remainder of data is custom to the individual/custom data required to be reported or maintained. With Regards to the record type "P," custom formats for customers will be retained and distributed to applicable customers as required in a separate technical bulletin. Since individual Customers/Vendors may have proprietary information requirements above and beyond the "standard" information presented in the other records, a record has been created to enable this information to be passed. In a typical scenario, unless this information is being purposely sought after, upon recognition of the "P" type record, the information in this record should be ignored. The information contained in this record will have custom formats and additional data obfuscation applied for each individual customer. This information is maintained as confidential between the entity and the individual customer.

Note that a "01 " and "02" (first two characters of the record) will ALWAYS be paired together while the file based protection identification methodology is maintained. A "02" record will always follow a "01 " type record where both are recorded, however, depending upon future protection methodologies employed in the recording of link file data, a "01 " record may not be present. For "linking" purposes, however, a "02" type record will ALWAYS be present.

If the applicable system requires a physical sector reference instead of a file based reference, then the "01 " record would be ignored. Likewise, if a file based system reads a "01 " record, it would immediately "jump" to the indicated file, and the physical sector reference type record "02" is ignored/not read.

If during the read, a "00" record is read, termination of the read/evaluation occurs. Where a "01 "/02" record combination occurs within the record, there will be no "00" record. A "00" record will ALWAYS indicate that the reading/evaluation process has been completed.

It is also NOT a requirement that a single file be "filled" (i.e.: all 8 protection record references used) prior to initiating a "jump" to another file.

Following either a record "00" or "02" type record, the remainder of the file itself is filled with random characters, which are also encrypted in the same manner as that of the "actual" records. Note: This is for information only, as this is performed during generation, however not a requirement during decrypt/read.

For the Mastering Intermediate to Final Master Content Change Skip Record, the information contained is in a similar manner to that of Record type "1 ," however the purpose of these records is slightly different. During the re-mastering process, certain content on the CD is "manually" changed. The primary example of this is the content of the ident file itself, which is changed DURING the mastering of the final CD. The purpose of this listing allows other software and systems to identify, whereby data comparisons are being made, which sectors are INTENTIONALLY changed during the mastering process (in addition to the copy protection listed in the type "1 " records). This allows, for example, comparison software to prevent false evaluation results as a result of these sectors. These records detail the applicable sectors for, but not limited to, the following: ident file, unique serial number content and/or serial number label content files. This also includes sectors that are known to be changed as a result of replicator requirements. For example, in some cases, replication software cannot resolve correctly the last sector (uncorrupted) of the target file, so the data within this sector is replaced with "good" data, resulting in a content change, even though there is no net effect to the protection or the application.

In addition to these "standard" record types, there exists the requirement for specific types of reporting either for individual customers or replication/verification software/systems, which may require "special" information to be recorded that could not be determined from the existing listed information. An example of this would be a proprietary CD image/CRC generator.

With regards to "P" records, they are always "supplemental," never direct replacement of information within the image.

Unlike common protection utilities, the protection itself is designed to work in a variety of scenarios, leaving the decision of "what to do" when an unauthorized copy is detected completely up to the software producer. The methodology for validation of the protected media can be integrated directly into the original application by way of utilizing a "Dynamic Link Library" (DLL) that the original program calls from its source code. In this manner, the application developer can then decide from within the program itself what to do if an unauthorized copy is detected. Another option is for the developer to obtain and integrate this validation source code directly into their application. Another avenue available to the developer is to utilize an "anti-hacking" wrapper package that protects their application that directly incorporates the validation methodology.

Although the present invention has been described with reference to the preferred embodiments, those skilled in the art will recognize that modifications and changes may be made in the form of detail without departing from the scope and spirit of the invention. The foregoing disclosure and description of the invention are illustrative and exemplary thereof. Various changes in configurations, substitution, expansion, modification, rearrangement, omission, deletion, or similar systems and processes are considered to be within the scope of the invention. Having described the invention above, it is intended that all variations within the scope and spirit of the claims should be embraced thereby.

Claims

CLAIMSWhat is claimed is:

1. A system for the production of copy protected CD-R, CD-ROM, or Programmable CD- ROM media, comprising: at least one media recorder capable of applying a logical defect having an integrity to the media; and at least one validator capable of verifying the integrity of the logical defect.

2. The System of Claim 1, further comprising an embedding component capable of embedding encrypted information that can be read and interpreted by replicator, imaging, mastering, and external validation programs.

3. The System of Claim 2, wherein the replicator, imaging, mastering, and external validation programs are not capable of imaging or mastering from a media containing the logical defect.

4. The System of Claim 1, wherein the System comprises at least one plug-in capable of interfacing the System with existing software.

5. The System of Claim 1, wherein the recorder is capable of embedding a unique serial number in each media.

6. The System of Claim 1, further comprising read/write components capable of creating an exact logical duplicate image of the media and creating an exact logical duplicate from this image.

7. The System of Claim 1, wherein the recorder is capable of creating copy protected CD-R media.

8. The System of Claim 1 , wherein the system is capable of providing data content verification at the conclusion of a remastering process.

9. The System of Claim 1 , further comprising a security architecture capable automatically encoding an image of the protected media using unique hashing routines.

10. The System of Claim 1, wherein the System is capable of interfacing with external or third party imaging systems.

1 1. The System of Claim 1 , wherein the System is capable of producing uniquely serialized media capable of interfacing with external or third party glass master encoding systems.

12. The System of Claim 1, wherein the System is capable of interfacing with external or third party quality control validation systems.

13. The System of Claim 1 , wherein the System is capable of interfacing with and retaining customized information data for external or third party custom systems.

14. A process for producing copy protected CD-R, CD-ROM, or Programmable CD-ROM media, which comprises the steps of: applying at least one logical defect having an integrity to the media; and verifying the integrity of the logical defect.

15. The Process of Claim 14, which further comprises the Step of: embedding at least one unique serial number to the media.

16. The Process of Claim 14, which further comprises the Step of: testing the media prior to delivery.

17. The Process of Claim 14, which further comprises the Steps of: creating an image of the media; and transmitting the image electronically to a replicator.

18. The Process of Claim 14, wherein at least one Step occurs using a plug-in to interface with third party software.

19. The Process of Claim 14, which further comprises the Step of: creating an intermediate master of the media containing at least one placeholder.

20. The Process of Claim 14 which further comprises the Step of: incorporating read and write components that have the ability to create an image and write that image with selective alteration of the contents of the media.