Server for an electronic distribution system and method of operating same

ES 2 592 903 T3

DESCRIPTION

Server for an electronic distribution system and its operating procedure

Cross reference to related cases

This application claims the benefit of US Provisional Application No. 60 / 172,318 entitled "System for Distributing Content Having Multilevel Security Protection" and US Provisional Application No. 60 / 172,319 entitled "System and Method for Digital Rights Management ”both filed on December 17, 1999.

Field of the invention

The present invention relates generally to the field of computing, and more particularly to the use of a server to distribute content in accordance with a digital rights management system.

Background of the invention

As the availability and use of palm-sized computers and electronic devices has increased, it has become common for documents to be transmitted and viewed electronically. With the improvement of communication through infrastructures such as the internet, there is enormous control to provide improved services and content to devices. Examples of services and content that may be provided are works of authorship, such as books or other textual material. Electronic distribution of text documents is both faster and cheaper than conventional distribution of paper copies. The same principle applies to non-text content, such as audio and video: electronic distribution of such content is generally faster and cheaper than providing such content on conventional media (eg, magnetic tape or optical disc). However, the low cost and instantaneity of electronic distribution, combined with the ease of copying electronic content, is contrary to the objective of controlled distribution in a way that protects the rights of the owners of the distributed works.

Once an electronic document is transmitted to one party, it can be easily copied and distributed to others without authorization by the owner of the rights in the electronic document, or sometimes even without the knowledge of the owner. This type of illicit document distribution can deprive the author or content provider of royalties and / or revenue. One problem with many current supply schemes is that they do not make provisions to protect property rights. Other systems try to protect property rights, but are nevertheless complicated and inflexible and make the display / reading of works of authorship (or otherwise present works of authorship, in the case of non-text content such as music, video, etc.) difficult for the buyer.

Therefore, in view of the above, there is a need for an improved digital rights management system that enables the provision of electronic works to buyers in a way that protects property rights, while also being flexible and user-friendly. . There is also a need for the system to provide flexible levels of security protection and to be operable on various customer platforms so that electronic content can be viewed / presented by its purchaser on each platform. The digital rights management system of the present invention advantageously provides solutions to the above problems that protects the intellectual property rights of content owners and allows authors or other content owners to be compensated for their creative efforts, while ensuring that buyers are not overwhelmed by the protection mechanism.

WO 96/42041 relates to the processing of service requests from a client to a server over a network. A client directs a service request to a first server that checks whether the service request requires a session identifier. If so, the first server redirects the service request from the client to an authorization server that issues a session identifier to be appended to the service request. The client receives and forwards the appended service request with the session identifier to the first server. Finally, the first server recognizes the session identifier and serves the request for the client.

Summary of the invention

It is the object of the invention to provide a simplified method and system for providing electronic content.

This object is solved by the invention as claimed in the independent claims.

Preferred embodiments are defined in the dependent claims.

A server architecture is provided that supports the distribution of protected content in a digital rights management ("DRM") system. The architecture includes an activation server arrangement and a distribution server arrangement. The architecture includes various security features that protect against unauthorized distribution or use of protected content, as well as software components that

ES 2 592 903 T3 implement the security features.

Based on the architecture provided, content can be protected on a plurality of levels, including unprotected, origin sealed, individually sealed (or “inscribed”), signed in origin, and fully individualized (or “proprietary”). . The “unprotected” content is delivered in a decrypted format. The "sealed of origin" and "individually sealed" content is encrypted and bundled with an encryption key that is cryptographically sealed with certain rights management data associated with the content, so that the key cannot be recovered if it has been modified. rights management data. The distinction between "origin" and "individual" stamping is that "individually sealed" content includes in the rights management data information relevant to the rightful owner (eg owner's name, credit card number, number receipt or transaction ID for the purchase transaction, etc.), so that this information cannot be removed from a working copy of the content, thus allowing the detection of unauthorized dealers. The type of particular information included is determined by the retailer of the copy. The "signed" content is cryptographically signed so that the presentation application can verify its authenticity, or the authenticity of its distribution channel. “Fully individualized” content is encrypted content provided with a decryption key that has not simply been sealed with rights management information, but has also been encrypted in a way that cannot be accessed in the absence of a “secure repository” and “ activation certificate ”, which are issued through the activation server provision only to a particular client or group of clients, thus limiting the use of such content to a finite number of installations.

The activation server arrangement includes one or more server computing devices that "activate" client computing devices by providing code and data to these devices, where the code and data are necessary to access "fully individualized" content in a given client device. In one example, the "data" includes an activation certificate that has a public key and an encrypted private key, and the "code" is a program (for example, a "secure repository") that accesses the private key in the activation certificate applying, in a secure way, the key necessary to decrypt the encrypted private key. Preferably, the key pair in the activation certificate is persistently associated with an authenticable "person," such that a device can be "activated" to read content that has been individualized for that person, but not content that has been " fully individualized ”for other people. As used herein, a "person" is a unique identifier that can be linked to a user and can be securely authenticated using an out-of-band procedure - for example, a form of username and password in a web browser. for use over a secure sockets layer (SSL) is an example embodiment of such a procedure. Furthermore, the activation server arrangement preferably provides a given activation certificate (i.e., an activation certificate that has a particular key pair) only after authenticating the credentials (e.g., a username and password) associated with a person. According to a feature of the invention, the number of devices that a particular person can activate can be limited by percentage and / or by number (for example, five activations in a first period of 90 days, followed by an additional activation each period of 90 days later, up to a maximum of ten activations), thus avoiding the unproven proliferation of devices where individualized content can be presented. As an example of using this technique, the protected content can be distributed as a file that includes content encrypted with a symmetric key, where the symmetric key itself is provided by a license construct embedded in the file in an encrypted form using the public key. of the certificate, thus making it necessary to have both the activation certificate and the accompanying secure repository before interfacing with the licensed content.

The distribution server arrangement includes one or more retail servers and one or more execution sites. Retail servers sell protected content (or otherwise designate users to receive protected content). The execution sites provide the actual content that has been sold through the retail servers. The operator of a retail server can be a different entity from the operator of an execution site, thus making it possible for a retail seller to sell protected content by simply signing an agreement in which an execution site will provide content sold by the seller. retailer. This allows the retailer to sell content without investing in the means to store or distribute the content. In one example, the retailer and the execution site agree on a secret (for example, a cryptographic key), and the retailer equips its server with software that uses the secret to create an encrypted instruction to provide the content to the buyer. The retailer may then allow the buyer to "execute" his purchase by providing an HTTP request to the buyer (for example, a POST request presented as a hyperlink on a "receipt" or "confirmation" web page), where the HTTP request contains the execution site address and the encrypted instruction. In the event that the content requires some level of individualization, the encrypted instruction may include the individualization information (for example, the name of the buyer, or, in the case of "fully individualized" content, the buyer's activation certificate). . The execution site receives the encrypted instruction when the buyer clicks the link, and the execution site uses the shared secret to decrypt the instruction and provide the content accordingly. A Component Object Model (COM) object can be provided to the retailer who creates the encrypted statement.

ES 2 592 903 T3

The runtime site can be organized as a runtime server plus one or more "download" servers and a content store. Content storage stores content to be distributed to consumers. The execution server maintains databases of information related to the execution of content orders, such as the physical location of content items and the secret (eg, the cryptographic key) necessary to decrypt instructions received from the retailer. The download servers perform the actual download of content to consumers / buyers of the content, as well as any preparation of the content that is necessary to meet the protection requirements associated with the content (for example, the download server may perform individualization of the content). contents). Each download server can have a cache, where the download server gets a copy of a content item from the content store (according to the location specified in the database of the executing server) the first time the server is requested. download server after processing a download of that item, where the download server caches the item for future downloads. The cache may have limits associated with it, and it may expire items out of the cache based on an algorithm such as a "least recently used" algorithm. The download server may also provide information regarding downloads that it processes to the execution server for log entry. The download server can provide this information in the form of messages through asynchronous messaging, such as MICROSOFT MESSAGE QUEUE (MSMQ). The runtime server can store the information in a "log database". Additionally, when updates are made to the information stored on the runtime server that affect the cached content item, the runtime server can use the messaging service to send messages to the various download servers indicating that the item it should be invalidated in the download server caches.

Other features of the invention are described below.

Brief description of the drawings

The above summary, as well as the following detailed description, are best understood when read in conjunction with the accompanying drawings. For the purpose of illustrating the invention, like reference numbers represent like parts throughout the various views of the drawings, it is understood, however, that the invention is not limited to the specific methods and instrumentalities disclosed. In the drawings:

Figure 1 is an exemplary electronic book (eBook) title file format;

Figure 2 is a block diagram showing an exemplary computing environment in which aspects of the present invention can be implemented;

Figure 3 is a block diagram of an embodiment of a first server architecture that implements aspects of a digital rights management system in accordance with the invention;

Figure 4 is a block diagram of an embodiment of a second server architecture that implements aspects of a digital rights management system in accordance with the invention;

Figure 5 is a block diagram illustrating certain interactions within a content provider server in accordance with aspects of the invention;

Figure 6 is a block diagram showing components of an asynchronous execution pipe in accordance with aspects of the invention;

Figure 7 is a flow chart illustrating the procedure for generating a license in accordance with aspects of the invention;

Figure 8 is a flow chart illustrating a client reader activation procedure in accordance with aspects of the invention; Y

Figures 9 and 10 are block diagrams illustrating an electronic commerce flow in accordance with aspects of the invention.

Detailed description of the invention

The present invention relates to a system for electronic content processing and delivery in which electronic content can be protected on multiple levels. A preferred embodiment of the invention is described, which refers to the processing and supply of electronic books, however, the invention is not limited to electronic books and can include all digital content such as video, audio, software executables, data, etc. .

General view

The success of the e-book industry will undoubtedly require providing the existing book-buying public with an engaging, safe, and familiar experience in obtaining all types of textual material. This material can include “free” or low-cost material that requires little copy protection, to “special quality” e-book titles ("e-books" herein) that require comprehensive rights protection. To enable a smooth transition from the current distribution and retail model for print books to an electronic distribution system, an infrastructure must exist to ensure a high level of copy protection for those publications that demand it, while supporting the distribution of titles that require lower levels of protection.

ES 2 592 903 T3

The Digital Rights Management (DRM) and Digital Assets Server (DAS) systems of the present invention advantageously provide such an infrastructure. The present invention makes purchasing an electronic book more desirable than "stealing" (eg, making an unauthorized copy of) an electronic book. The non-intrusive DRM system minimizes the risk of piracy, while increasing the likelihood that any piracy will be offset by increased sales / distribution of books in the form of e-books. Furthermore, the present invention provides retailers with a system that can be rapidly deployed at low cost.

The represented users of the DRM system are publishers and retailers, who use and / or deploy the DRM system to ensure the legitimacy of the content sold as well as copy protection. Exemplary users of the DRM system can be the traditional publisher, the "advanced" publisher, and the "hungry author." The traditional publisher is likely concerned about losing profits from their print book publishing operation to e-book piracy. The advanced publisher is not necessarily concerned about isolated incidents of piracy and may appreciate that the e-book trade will be more successful in a system where consumers develop purchasing habits. Meanwhile, the hungry author, who would like to collect money from the sale of his works, is more interested in attribution (for example, having the author's name permanently attached to the work).

As will be described in greater detail below, the DRM system of the present invention achieves its objectives by protecting jobs, while enabling their legitimate use by consumers, supporting various "levels" of protection. At the lowest level (“Level 1”), the content source and / or provider can choose not to protect using unsigned and unsealed (clear text) e-books that do not include a license. A next level of protection (“Level 2”) is “origin sealing”, which means that the content has been encrypted and sealed with a key, where the seal is done using a cryptographic hash of the e-book title metadata ( see below) and the key is required to decrypt the content. Origin stamping protects against tampering with the content or its attached metadata after the title has been sealed, since any changes to the metadata will render the title unusable; however, the stamp of origin does not guarantee authenticity of the title copy (that is, the stamp of origin does not provide a mechanism to distinguish legitimate copies from unauthorized copies). In the case of the "hungry author", the author's name can be included in the metadata for permanent attachment to the content, thereby satisfying the "hungry author" attribution goal. A next level of protection (“Level 3”) is “individually sealed” (or “enrolled”). An “individually sealed” title is an electronic book whose metadata includes information related to the legitimate purchaser (for example, the user's name or credit card number, the transaction ID or receipt number of the purchase transaction, etc. .), so this information is cryptographically linked to the content when the title is sealed. This level of protection discourages individuals from distributing copies of the title, as it would be easy to detect the source of an unauthorized copy (and any changes to the metadata, including buyer-related information, would make it impossible, or at least unlikely , that the required decryption key could be unsealed).

The next level of protection (“Level 4”) is “signed of origin”. Signed e-books of origin are titles that can be authenticated by a "reader" (which, as discussed more particularly below, is a user application that makes it possible to read e-books on a computing device, such as a PC, a laptop, a Personal Digital Assistant (PDA), PocketPC, or a specially built reading device). Authenticity can preferably be defined in three diversities: “signed tool”, which guarantees that the e-book title was generated by a reliable conversion and encryption tool; “Signed owner” which is a signed tool e-book that also guarantees the authenticity of the content in the copy (for example, the owner may be the author or another copyright holder); and “signed provider,” which is a signed tool e-book that confirms the authenticity of its provider (eg, publisher or retailer of the content). The “tool”, the owner and the provider can each have their own asymmetric key pair to facilitate the creation and validation of digital signatures of the information. A title can be both provider signed and origin signed, which facilitates authentication of the title distribution channel (for example, through a signature chain on the copy). The strongest level of protection is "fully individualized" or "proprietary only" ("Level 5"). "Fully individualized" titles can only be opened by authenticated reader applications that are "activated" for a particular user, thus protecting against portability of a title from a reader (or readers) from a person to a non-reader. registered for that person. For the reader of the present invention to open a protected title at Level 5, the reader must be "activated" (that is, the device in which the reader resides must have an activation certificate for a particular person, and a secure repository). The activation procedure is described in greater detail below with reference to Figure 8.

The systems of the present invention also define an architecture for sharing information between a reader, a content provider and a content source, how that information is used to "seal" titles at various levels, and how that information should be structured. The availability of these choices will allow content sources to pick and choose what content to sell to which users and use what protection (if any). The particular information can be used to sign and / or seal titles for use by a reader, and a compatible reader (which, in the case of level 5, can be a reader activated for a particular person) can unseal the title and make reading possible of the electronic book.

ES 2 592 903 T3

Electronic book file structure

The DRM system of the present invention protects content by incorporating it into a file structure, such as the exemplary structure shown in Figure 1. Referring to Figure 1, the electronic book contains content 16, which is text such as a book ( or any electronic content) that has been encrypted using a key (the “content key”), which itself has been encrypted and / or sealed. In a preferred embodiment, the key is a symmetric key 14A that is sealed with a cryptographic hash of metadata 12 or, in the case of level 5 titles, with the public key of the user's activation certificate. This key is stored as a separate stream in a sub-storage section of the e-book file (DRM storage 14 in the diagram) or, in the case of level 5 titles, in the license. (For level 5 titles, instead of storing the content key as a separate stream, stream 14A contains a license, which is a construct that defines the rights that the user can exercise after purchasing the title. titles that have a license, the content key is contained in the license). Also included in DRM storage 14 is source stream 14B, which may include the name of the publisher (or other content source), as well as exlibris stream 14C, which, for individually sealed titles (level 3 and / or level 5), includes the name of the consumer as provided by the retailer (which may be obtained, for example, as part of the commercial transaction to purchase an e-book 10, such as from the consumer's credit card information). The procedure for calculating the cryptographic hash that encrypts and / or seals the symmetric 14C key (or the procedure for using such a cryptographic hash to seal the key) is preferably a "secret" known only to trusted content preparation tools and presentation applications. reliable. Using a hash in this way can complicate / discourage manipulation with the metadata 12 contained with the e-book 10. It is noted that any procedure can be used to "seal" an e-book, as long as such a procedure provides some measure of tamper resistance for e-book 10.

In accordance with the present invention, the metadata 12 may include a copyright tag, which describes the rights granted to the user or purchaser by the content source (eg, publisher). As long as the label is present, the client (for example, device 90 or 92 shown in Figure 4) can render the text included on the label to a user. It will be appreciated that the act of reminding users of the copyright laws that apply to their e-books may serve to deter typical users from attempting to copy e-books.

DRM system architecture

As shown in Figure 2, an exemplary system for implementing the invention includes a general purpose computing device in the form of a personal computer or network server 20 or the like, including a processing unit 21, a system memory 22 , and a system bus 23 that couples various system components including system memory 22 to processing unit 21. The system bus 23 can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read-only memory 24 (ROM) and random access memory 25 (RAM). A basic input / output system (BIOS) 26, which contains the basic routines that help transfer information between items in the personal computer 20, such as during startup, is stored in ROM 24. The personal computer or network server 20 may further include a hard disk drive 27 for reading from and writing to a hard disk, not shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and a optical disc drive 30 for reading or writing to a removable optical disc 31 such as a CD-ROM or other optical media. The hard disk drive 27, the magnetic disk drive 28, and the optical disk drive 30 are connected to the system bus 23 via a hard disk drive interface 32, a magnetic disk drive interface 33, and an interface 34 optical drive, respectively. The drives and their associated computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the personal computer or network server. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 29, and a removable optical disk 31, it should be appreciated by one of ordinary skill in the art that other types of computer-readable media that can store data that are accessible by a computer, such as magnetic tapes, flash memory cards, digital video discs, Bernoulli cartridges, random access memory (RAM), read-only memories (ROMs) and the like can also be used in the exemplary operating environment.

A number of program modules can be stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24, or RAM 25, including an operating system 35 (for example, Windows® 2000, Windows NT®, or Windows 95/98), one or more application programs 36, other program modules 37, and program data 38. A user can enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and pointing device 42. Other input devices (not shown) may include a microphone, joystick, game controller, satellite disc, scanner, or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus 23, but they can be connected through other interfaces, such as a parallel port, games, universal serial bus (USB), or a 1394 high-speed serial port. A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the 47 monitor, personal computers typically

ES 2 592 903 T3 include other peripheral output devices (not shown), such as speakers and printers.

The personal computer or network server 20 may operate in a network environment using logical connections to one or more remote computers, such as a remote computer 49. The remote computer 49 may be another personal computer, another network server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements previously described in relation to the personal computer 20. although only a memory storage device 50 is illustrated in Figure 2. The logical connections depicted in Figure 2 include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are common in offices, enterprise-level computer networks, intranets, and the Internet.

When used in a LAN networking environment, the personal computer or network server 20 is connected to the local network 51 through a network interface or adapter 53. When used in a WAN networking environment, the personal computer or network server 20 typically includes a modem 54 or other means for establishing communications over the wide area network 52, such as the internet. Modem 54, which can be internal or external, is connected to system bus 23 via serial port interface 46. In a network environment, the program modules relative to the personal computer or network server 20, or portions thereof, may be stored in the remote memory storage device 50. It will be appreciated that the network connections shown are exemplary and that other means may be used to establish a communication link between the computers.

Server architecture

Referring now to Figure 3, a first exemplary server architecture 70 is illustrated that implements the DRM system of the present invention. Server architecture 70 is implemented and deployed in, for example, a retail / distribution site. In one embodiment of the invention, all components of the server architecture 70 are associated with a single party (e.g., a large electronic bookstore) that performs both retail sale of electronic books 10 and performs actual download of electronic books 10 to clients' reading devices. In another embodiment of the invention, the library servers 72 and the URL encryption COM object 74 are associated with one party (eg, an e-book retailer 10 that does not perform downloads), and the other components of the architecture Server 70 are associated with a second party (eg, a "run host"), which performs downloads of e-books 10 that are marketed / sold by the first party.

Features provided by server architecture 70 include: encryption of source e-books, conversion to target reader format, generation of license construct defining the rights granted to the user (in level 5 titles), content sealing before download in accordance with the requirements (for example, a level of protection) set by the provider of the publication and download of e-book titles. This server architecture also includes features that provide a flexible configuration that enables users of this technology (content providers, retailers) to scale their system according to their needs. These features include: dynamic resolution (via a database query) of file IDs to physical file locations, in-memory caching of popular downloads for superior efficiency and better performance (where the cache can expire items based on, for example, a least recently used function), and asynchronous recording of each downloaded file (also to a database) for later auditing / reporting and / or billing purposes. Other functions may be performed by the server architecture 70 in accordance with the present invention.

The library servers 72 are preferably MICROSOFT® Internet Information Servers (IIS) implemented on a network server, such as the computer 20 illustrated in Figure 2. The library servers 72 can communicate with users via web browsing software ( for example, providing web pages to view with a MICROSOFT INTERNET EXPLORER browser or a NETSCAPE NAVIGATOR browser). Through this communication, the bookstore servers 72 can allow users to make purchases of e-book titles, establish their affiliation relationship with the retailer, pay for their transactions, and access proof of purchase pages (receipts from the server side). The URL encryption object 74 may reside on the library servers 72. The URL encryption object 74 encrypts a set of parameters related to an electronic book that has been purchased from the bookstore server 72. The URL encryption object 74 may encrypt these parameters using a secret (eg, a symmetric cryptographic key) shared between the library server 72 and the web content server 76. For example, the parameters can include an identification of the purchased e-book, information about the purchase such as the name or credit card number of the buyer, or a transaction ID (for example, in the case of level 3 or 5 titles ), and a time stamp. It will be appreciated by those skilled in the art that the parameters listed above are exemplary, and different parameters could be used without departing from the scope of the invention. The encrypted parameters can be included in an HTTP request pointing to the web content server 76, so that the content server 76 can fulfill the purchase made at the library server 72. For example, after an e-book has been selected by a buyer, the bookstore server 72 could upload to the buyer's computing device a web page containing a link associated with a POST request, where the POST request points to a server. of content such as "www.content-provider.com", and

ES 2 592 903 T3 the body of the POST contains the encrypted parameters. In an alternative embodiment of the invention, the link provided on the web page could be associated with a GET request, such as "http://www.contentprovider.com/isapi/ds.dll?action=download&value=<encrypted parameters>" However, this alternative embodiment has the disadvantage that some browsers would put a limit on the acceptable size of a URL (eg 2 kilobytes), thus restricting the size of the encrypted parameters. Whatever type the HTTP request is associated with the link, the user could then follow the link to start the download. Since the parameters have been encrypted with a secret shared between the library server 72 and the content server 76, it is possible for the content server 76 to verify that the encrypted parameters originated from a legitimate library server 72 (for example, one for which the operator of the content server 76 has agreed to provide download services). If a timestamp is included, then the content server 76 may use the timestamp to ensure that the encrypted parameters were generated recently, thereby resisting "replay attacks" (ie, "parsing packets" from the HTTP request by someone who wants to download e-books that he or she has not legitimately purchased). The URL encryption object 74 is preferably implemented as a server-side COM object, and is preferably instantiated by Active Server Pages (ASP).

The content servers 76 are preferably IIS servers implemented on a network server (preferably different from the library server 72). Like the library server 72, the content server 76 may be implemented on a computer such as the computer 20 shown in Figure 2. A download server ISAPI extension 78 is provided, which is an IIS extension DLL that preferably handles incoming requests to content servers 76. The ISAPI DLL 78 is responsible for validating download requests, retrieving the appropriate e-book file 10 from content storage 80 via content storage extension module 88, selling copies individually, returning e-book titles 10 to end users, and record the transaction in the execution database 84 by means of an asynchronous messaging module. The standalone MICROSOFT Message Queue (MSMQ) client 86 is an exemplary asynchronous messaging module that can be used in the server architecture 70 (and the server architecture 70 'depicted in Figure 4 and discussed below). Although the use of Microsoft's MSMQ technology for asynchronous communication of your messages from server to server (MSMQ client 86) is preferred, it will be appreciated by those skilled in the art that any store-and-forward messaging technology can be used. In accordance with one aspect of the server architecture 70 (and architecture 70 '), such resilient messaging technology can be used to achieve high degrees of reliability and scalability, since all server-to-server messaging that does not require time-consuming communications real is carried out using an asynchronous communications pipeline.

The content storage 80 is preferably a large network connected file system or database management system (or a plurality of such file systems or database management systems). The content storage 80 serves as a repository for LIT titles (electronic books 10) used by the download server ISAPI 78 when fulfilling orders for the electronic books 10. The content store 80 preferably exposes a Universal Naming Convention (UNC) path that can be accessed via the download server ISAPI 78. For security reasons, it is preferred that the content storage or storages 80 exist behind a firewall and are not directly exposed to the internet. Content encryption and management tool 82 is a component that performs functions such as converting content to LIT format (eg, electronic book 10), encrypting and sealing each electronic book title in content storage 80. Content encryption and management tool 82 also updates execution database 84 with the physical location of each LIT file in content storage 80, which is mapped to its unique ID in execution database 84. Tool 82 accepts clear text source files (LIT, OEB, HTML, etc.) and generates encrypted LIT files that are source sealed (for example, level 2), for later retrieval via download server ISAPI 78 .

Referring now to Figure 4, a second server architecture 70 'in accordance with the present invention is illustrated. The server architecture 70 'is a distributed model, and includes three data centers: a retail site 71, a DRM and execution site 73, and an activation site 75. As with the server architecture 70, content retailing and content order fulfillment can be done by a single party, or a first party can retail e-books 10 while a second party fulfills orders for e-books 10 that they were marketed for the first part. In the latter scenario, the sale site 71 is associated with the first party and the DRM and execution site 73 is associated with the second party. Within the architecture of Figure 4, it is preferred that all web server based applications are clustered behind a virtual IP address, and that the content servers are doubly hosted. It is also preferred that the activation servers 94 rely on the MICROSOFT® PASSPORT ™ membership system to associate certificates with end-user persons, as will be described below (although PASSPORT is merely exemplary of a namespace authority that may used for this purpose).

The following is a brief description of the components of the server architecture. The library servers 72 associated with the sales site 71 are network servers implemented on a computer such as computer 20. Preferably, the library servers 72 are running WINDOWS® 2000 Advanced Server running IIS. As in architecture 70, these servers host the commercial website that allows users to

ES 2 592 903 T3 perform actions such as making purchases of e-book titles, establishing your affiliation relationship with the retailer, paying for your transactions, and / or accessing proof of purchase pages (server-side receipts). The URL encryption object 74 is provided for integration into the retailer site 71. As in the server architecture 70, the URL encryption object 74 of the server architecture 70 'can be implemented as a server-side COM object installed on the library servers 72 and instantiated by ASP pages, and can encrypt parameters related to the purchase of an electronic book 10 so that the content server 76 can validate the encrypted parameters, authenticate the seller using a shared secret (for example, a symmetric key used to encrypt parameters), prevent replay attacks, and determine content to download to end users.

The content / download server (s) 76 are preferably WINDOWS® 2000 Advanced Servers running IIS. The content / download servers 76 host the main components of the DAS runtime application, including the download server ISAPI extension 78, the content storage extension module 88, the license server module 77, and the client. 86 pipe run.

As noted above, the download server ISAPI extension 78 is preferably an IIS extension DLL that handles incoming requests to content servers 76. You are responsible for validating each download request, individually stamping copies (when required), requesting a license for fully individualized copies (i.e. level 5) of e-books, returning e-book titles to end users, and registering the download transaction in a database, such as log database 91.

The content storage extension module 88 is preferably a DLL that is responsible for determining the physical location in the content storage 88 of each of the LIT files (e-books) being downloaded, based on a combination of parameters ( for example, book ID and book ID type parameters) included in the download request (that is, the encrypted parameters appended in the URL). The extension module 88 also retrieves, from the execution database 89, configuration information (for example, the licensee's private key and public key certificate, a list of supported retailers and their symmetric keys, etc.) Required to initialize the download server ISAPI extension DLL 78.

The license server module 77 is a subcomponent of the download server ISAPI extension DLL 78. It is responsible for generating and sealing licenses for LIT level 5 protected files. As will be described more fully below, a license is a construct that defines the rights that the user can exercise after the purchase of an e-book title. The license server module 77 also validates the activation certificate of the user to whom the e-book is being downloaded and signs each license with the execution center provider's private key, which later allows the reader 90 or 92 to authenticate the channel distribution when the downloaded LIT file is accessed on that reader. Exemplary readers are fully described in Agent's Docket No. MSFT-0123, filed concurrently herewith, which is incorporated herein by reference in its entirety.

The runtime client 86 is preferably a standalone MICROSOFT® Message Queue (MSMQ) client, which is available with the WINDOWS® 2000 Server family of products. This component implements the asynchronous communication pipeline between the download server ISAPI 78 and the runtime database 89. ISAPI 78 records each downloaded transaction via a message posted to local MSMq client 86 on each content server 76, which in turn will store and forward such message in a resilient form to a similar MSMQ client 86 hosted on server 84 of execution. This pipeline will also be used to invalidate entries cached in an ISAPI RAM cache (located on content servers 76), by messages that are published from the execution server 84 to the ISAPI DLL 78 using the same set of MSMQ clients hosted locally.

As in the server architecture 70, the content storage 80 of the server architecture 70 'is preferably a large network attached file system or database management system. Serves as a repository for LIT titles used by download server ISAPI 78 when requests are fulfilled. This server preferably runs WINDOWS® 2000 Advanced Server and exposes a UNC path that can be accessed by the download server ISAPI DLL. This can be accomplished through a configuration application provided through the DAS. It is also preferred that the content storage 80 exists behind a firewall and is not exposed to the web.

The execution server 84 is preferably a WINDOWS 2000 Advanced Server running MICROSOFT® SQL 7.0 (or later). This server hosts a runtime database 89, a log database 91, a runtime client 86, and a runtime COM object 87. The execution database 84 houses tables that map the combination of a "book ID" and "book ID type" to the physical location of each LIT file in content storage 80. Database 84 also contains information about each LIT file that may be required for execution, such as book title, book author, DRM protection level, and / or suggested retail price. The full range of information may vary according to the business rules / practices of each execution venue (for example, the entity that operates the

ES 2 592 903 T3 content server 76), but preferably the information includes those items listed above. A command line script can be provided that creates the necessary tables and stored procedures for this database, as well as adding sample entries that can be used as reference by the execution center when designing your content management procedures.

The log database 91 is used to record each download transaction from the download server ISAPI DLL 78 (for later billing / reporting where applicable). The runtime client 86 is preferably a separate MICROSOFT® Message Queue (MSMQ) client that exists on the content / download servers 76, as described above. The execution pipeline object 87 is preferably a COM object that is activated by the separate MSMQ client hosted on the execution server 84 each time an incoming message is written to the input queue on this server. The execution pipeline object 87 extracts the log information from each MSMQ message and writes it to the log database 91, where it can later be used by the report scripts. Additionally, the execution pipeline object 87 will be triggered by changes to the execution database 89 and will push any update / delete information to the various independent MSMQ clients 86 hosted on the download servers 76.

The content management tool 82 is responsible for managing the information stored in the execution database 89. When LIT files are added to content storage 80, this tool writes the appropriate fields to execution database 89 (for example, the book ID to physical location mapping) so that storage extension module 88 content can find the requested LIT files later. Similarly, should any change be made (for example, a DRM level change in a LIT file) this tool provides the interface from which those responsible for the content management function within the execution center (i.e. human content managers) would carry out these tasks.

The execution centers 73 can complete the content management task by creating a set of ASP pages which, using conventional IIS COM objects, write all the relevant information to the execution database 89 and place the incoming LIT file (already encrypted as a sealed copy of origin) on a rendering server 83, which would mimic the directory structure of production content storage 80. From there, the LIT files would be replicated automatically using, for example, the Site Server 2000 content replication server, to the production content storage server. The rendering server 83 is not necessarily required to implement the DAS system, but is an advantageous approach to replicating LIT files from the executing partner's network to the production content storage servers using tools such as the content replication server. (CRS) from MICROSOFT®.

The activation servers 94 perform the function of providing each client reader (eg, PC reader 90 or specialized reader device 92) with a unique secure repository and activation certificate. An exemplary secure repository, and systems and procedures for providing the same, are disclosed in Mandatory File No. MSFT-0126, concurrently filed therewith, which is expressly incorporated herein by reference in its entirety. The secure repository and activation certificate associate the activated reader with an online person (for example, a MICROSOFT® PASSPORT ™ ID) to ensure that users will be able to read their legitimately acquired titles in all cases of readers who own or that they have activated for themselves (but not on readers not activated, or readers not activated for that person) - assuming they activate their readers using the same user ID and password each time.

The activation server 94 includes a PASSPORT object 96 and an activation server ISAPI extension DLL 98. The PASSPORT object 96 provides the required interfaces on PASSPORT ™ servers that authenticate end users using, for example, their hotmail accounts (and other PASSPORT credentials). In accordance with aspects of the present invention, this object advantageously associates the activation certificate with a person, rather than a single PC, thus allowing each person to use multiple readers to read level 5 titles. While it will be appreciated that linking level 5 titles to a "person" allows for wider use of level 5 titles than if they were attached to a single device, defining a person in terms of an established namespace authority such as PASSPORT servers It also serves the purpose of limiting the unrestricted use of level 5 titles that may otherwise exist if users were allowed to use an arbitrary label to function as a person. In the case of PASSPORT credentials, personal information related to a particular user is associated with those user's PASSPORT credentials, possibly ranging from the user's email account to their credit card number. Therefore, a user is unlikely to share their PASSPORT ID and password with a large group of people, thus ensuring that the person for whom a reader is activated is associated with a particular user (or possibly a family. sharing a single PASSPORT account). Although a PASSPORT server is an exemplary namespace authority that can provide this advantageous feature, it will be appreciated that other namespace authorities could be used without departing from the spirit and scope of the invention. In such an alternative embodiment, the PASSPORT object 96 could be replaced with a different object that communicates with the alternative namespace authority.

ES 2 592 903 T3

The activation server ISAPI extension DLL 98 performs tasks associated with the activation procedure on the front-end activation servers, including receiving a hardware ID loaded by the reader client, creating a unique machine ID based on the hardware ID, post a request to the secure repository server (s) 100, sign each unique secure repository received from the secure repository server (s) 100, generating and (optionally) encrypting the activation certificate, updating the activation database 102, and downloading both the secure repository and the activation certificate to the reader client. The activation procedure is more particularly described below with reference to Figure 8.

The secure repository servers 100 are preferably independent servers located behind a firewall in a data center. They are accessed by activation servers 94 to generate individualized secure repositories for each reader that is activated. These servers are preferably specialized, and preferably run a WINDOWS® 2000 or WINDOWS NT® service that exposes a connector interface to the activation servers 94. The secure repository service binds a separate executable for each published unique machine ID and passport ID combination. The task of preparing an individualized secure repository is, in many cases, computationally intensive. Therefore, in a preferred embodiment there are a sufficient number of secure repository servers 100 to provide secure repositories to readers in real time (eg, a few seconds per trigger), taking into account the expected volume of trigger traffic.

The activation database 102 is preferably a MICROSOFT® SQL 7.0 based server that stores activation information related to each end user of reader 90 or 92 (based on their PASSPORT ™ IDs). Such information may include: Machine ID, the number of activated readers, the date of first activation, the Product ID (PID) for each of the reader installations, your PASSPORT ™ profile information, and so on. This information is used to ensure that users are not abusing the system, to help users recover from hard drive failures, and to help allow users to continue reading the content they have purchased after a hardware upgrade. For example, the number of activated readers and the date of the first activation associated with a particular PASSPORT credential could be used to impose a limit on the number of activations (for example, no more than five activations for a given person in the first 90 days after the first activation, with an additional activation allowed every 90 days thereafter, up to a total of 10 activations). Imposing such a limit (or some other type of limit) has the effect of preventing the proliferation of unverified readers activated for a single person (which, in the worst case, could result in a level 5 title being readable on millions of reader devices, thereby defeating the goal of controlling the distribution of valuable content). Additionally, the other information in the activation database 102 enables users to use level 5 titles after a hardware upgrade (or after a hard drive failure), without having to re-download titles or licenses. In this case, all a user needs to do is activate the reader on the upgraded (or repaired) hardware with the same PASSPORT ™ ID.

The activation database server 102 is preferably located behind a firewall and is only accessible by the front-end activation IIS servers on the same private network where the secure repository servers are located. A replica of the activation database 102 can be accessed via offline scripts to generate reports of the number of activations per day, week, month, average activations per PASSPORT ™ ID, and so on.

Receipt infrastructure

As briefly described above, the server architecture of the present invention includes a URL encryption object 74, which encrypts certain parameters related to the sale of an electronic book 10, where the encrypted parameters are included in a URL. The following is a more detailed overview of the use of the URL encryption object 74.

The URL encryption object 74 facilitates a decoupling of the e-book seller (eg, the retailer) from the entity that actually provides the LIT file to the buyer (eg, an execution venue). The URL encryption object 74 performs this function by encrypting information related to the purchased e-book with a secret (eg, symmetric key 75), which is shared between the execution center and the retailer. In an exemplary scenario, the retailer enters into a business relationship (for example, a contract) with an execution venue, in which the execution venue agrees to provide content download services for the retailer who does not actually have a stock. electronic e-books or server devices required to download e-books to a large number of buyers. As part of this relationship, the vendor and the execution venue agree on a secret symmetric key 75, which will be used by the URL encryption object 74 on the retailer's site, and by the ISAPI extension DLL 78 on the execution center site. Essentially, the retailer uses the URL encryption object 74 and the secret symmetric key 74 to encrypt information related to the purchase of an e-book, and includes this encrypted information as a parameter to a URL pointing to the execution center site. . The URL is then presented in the buyer's browsing software as a "receipt page", where the "receipt" is a hyperlink to the URL invoking the download from the execution center. When the user follows the link, the execution center receives the encrypted parameter and decrypts it using the shared secret symmetric key 75. Since the parameter is

ES 2 592 903 T3 encrypted, any secret information that needs to be exchanged between the retailer and the execution site can be provided securely in encrypted form to the buyer's site, since the buyer does not know the symmetric key 75 (and presumably, other eyes hidden on the web also do not have access to the symmetric key 75). Furthermore, when the execution venue decrypts the encrypted information to obtain the information necessary for the download, the appropriate decryption of the information authenticates the "receipt" as having been generated by a legitimate retailer, since presumably none other than the Retailer has the symmetric key 75 necessary to properly create the encrypted parameter. It should be noted that the symmetric key 75 is merely exemplary of the type of secret that could be shared between a retailer and an execution venue to allow this manner of communication. In an alternative embodiment, asymmetric key pairs could be used, or the retailer and the execution venue could agree on an encryption procedure without a secret key.

Figure 5 depicts the use of the URL encryption object 74 to create the encrypted parameter. The URL encryption object 74 encrypts the URL parameter using a symmetric key 75 (the URL "secret") that is shared between the download server ISAPI 78 and the URL encryption object 74 on the retail server. . In a hosted scenario, where an execution center provides the download of LIT files marketed by a large number of retail sites, a symmetric key 75 is provided to each retailer as they sign a contract with the execution center 73 . It is important to note that this symmetric key 75 may be unique per retailer 71. The execution center 73 may store the keys for each retailer in the execution database 89. It should be noted that the symmetric key 75 used for URL parameter encryption is different from the symmetric keys 14A generated by the content encryption and management tool 82 to encrypt the LIT files.

A single exported procedure in the URL encryption object 74 ("Encrypt ()"), creates the encrypted URL parameters. Preferably the Encrypt () procedure takes the following parameters to embed itself in the encrypted large binary object that will be used in the URL:

Transaction ID (TransactionID) - a string that uniquely identifies each transaction at the library site 72;

Book ID (BookID) - a unique identifier, which is used by the download server 76 to locate the appropriate LIT file by the content extension module 88 (which looks up the book ID in the execution database 84) ;

Book ID Type (BookIDType) - identifies what type the ID is (for example ISBN, DOI, PATH, etc.). The URL encryption object 74 preferably does not validate this field, or its relation to the ID. The download server ISAPI 78 will subsequently use this field as an additional input parameter for the search performed by the content storage extension module 88;

Username (UserName) - a string containing the name of the rightful owner of the purchased e-book. This string preferably maps to the consumer listed on the credit card used for the business transaction, although this is left as policy to be established by the content source (eg publisher) in accordance with the execution venue. This string is the name that will be used later by the download server ISAPI 78 to individually stamp the titles (that is, to generate the bookplate). It will be remembered that individualized titles (for example, level 3 and level 5) incorporate the username into the LIT file and bind that name to the decryption key, so that the source of unauthorized content distribution can be detected. Therefore, it is preferred that the buyer's name comes from a reliable source (such as the user's credit card), rather than an unverifiable source (such as user input). Although the above example assumes that a name will be inserted in this field, the actual contents of the bonnet are determined by the retailer, and could contain any information (for example, credit card number, transaction ID, receipt ID, etc. .) preferably information that relates to the purchase or the buyer to allow the surveillance and tracking of the copy;

PASSPORT ID - the ID of the person associated with the user, which is provided by the user during activation. This field is later used by the content server to compare with the activation ID in the activation certificate. It should be noted that, although the PASSPORT ID is contained in the activation certificate, that ID is not uploaded to the library server 72 during the purchase transaction. Instead, the activation procedure, in addition to inserting the PASSPORT ID into the activation certificate, also stores the PASSPORT ID in the registry on the user's computing device, and is the instance of the PASSPORT ID registry that provided to library server 72; Y

Security Level (SecurityNivel) - this string indicates what level of DRM this particular publication requires. This will later be converted to a number and marked in the title metadata 12 by the download server ISAPI 78;

Optionally, the following input parameters can also be included with a request:

Cost - the price that the merchant (ie, retailer 71) paid for that e-book title at the time the title was sold to the consumer;

MSRP - publisher's recommended price at the time the title was sold;

Price - the price for which the e-book title was sold. This is an optional parameter, and if present it will be used by the download server for logging purposes and potentially for purposes

ES 2 592 903 T3 billing;

Friendly Filename (FriendlyFileName) - this string is used by the download server when setting the filename for the LIT file being downloaded by the response HTTP header; Y

Customer ID (CustomerID) - a unique identifier for the end user purchasing the e-book title. The merchant (ie, retailer 71) may require this information as part of the reports it receives from the execution center.

The above list of parameters is extensible and should not be construed as limiting the full set supported by the URL encryption object 74. Additional attribute-value pairs may be added, since the URL encryption object 74 will encrypt the entire set of passed values ​​and return them to the calling function.

Preferably, the URL encryption object 74 adds a time and version stamp. The timestamp is the string that preferably contains a representation of the number of nanoseconds passed since 1601 (in GMT system time) on the local machine where the URL encryption object 74 is installed. This value can be used by the download server to calculate a time to live (TTL) to prevent replay attacks (that is, someone stealing a URL and replaying it to download a book. The version field is a decrypted string that identifies the version of the URL encryption object 74 that created the large binary encrypted object in the URL.

After the retailer 71 gets the encrypted string back from the URL encryption object 74, the retailer 71 creates a POST request pointing to the download server 76 for execution. The encrypted binary large object returned by URL encryption object 74 is included in the body of each POST. In addition to the encrypted parameters, retailers may need to provide a Retailer ID (RetailerID) in the URL that identifies the retailer. This can be used by the download server ISAPI DLL 78 to map the input request to the appropriate URL symmetric key 75 for decryption in case multiple vendors are supported by a single download server site 76. This is an optional field and if not provided, the download server ISAPI DLL 78 at the execution site 73 will later use its default symmetric key 75 provided during configuration to decrypt the URLs.

Therefore, in accordance with the above, assuming an input to URL encryption object 74 such as:

TransactionId = R6RAKHAL9TS 12JTG00QP9ESTQ4 & BoókId = 044021145X & BookIdT ype = ISBN & Usemame = Pavel + Zeman & SecurityLevel = 3

The COM object encryption 74 may return the following binary large object encrypted: LCfsQCLuMg9UZtWxldYTfw% 2BzMtjXAN% 2BiU0YHaomrY3ydXhw3p9TlwZuH% 2BFEHTEP687Nq17wbMMwnbtHAkljkKhKS% 2BYKwgHj7% 2FNr% 2BvBD50APwq MbvN3saNBrPxG8s1ziU1iX% 2F% 2BSS% 2FttA% 2F4GZjRMo5uXWM% 2BZr5dYHk SfWfBBC0iH7uLFolylz8LSI = & Version = 1.0

The URL of the URL Encryption Object 74 encodes the encrypted large binary object so that it conforms to the HTTP standard required for ANSI URLs. The URL encryption object 74 accepts both Unicode and UTF-8 strings, and handles UTF-8 conversion from Unicode internally. Optionally, the URL encryption object 74 uses UTF-8, if provided, which reduces the size of the resulting encrypted final escaped binary large object for non-Unicode input by about one half. The URL encryption object 74 preferably computes a cryptographic hash of the data to be encrypted prior to encrypting such data, and includes the hash with (eg, in front of) the encrypted and encoded data. This hash can then be used for comparison by the download server to verify that the decrypted data has not been tampered with between the retail site and the download server. For example, the full parameter (for example, to be included in the body of a POST request), can be read:

VALUE = & Hash = bCt / xn41fTJw7cPQjstge-i-6Lifc = & Data = zAybPKW123 d2O + ... encoded_data_continue ... MSSD8Eyw == & Version = 1.5

The download server ISAPI 78 is responsible for individualizing and downloading e-book titles to end users. Also, the analysis and validation of each URL generated by the URL encryption object 74 is performed by the download server ISAPI DLL 78. This includes decrypting the URL using the appropriate symmetric key 75, which can be a default key or, in the case where a retailer ID is provided, a string resulting from a database query using the storage plug-in. of content. The download server ISAPI DLL 78 also resolves the book ID and book ID type mapping from the URL passed to a file sharing location preferably by an extension module. The extension module retrieves that information from the database

ES 2 592 903 T3 execution and enables content providers to add their own mapping database and naming convention rules.

The download server ISAPI 78 also determines the level of DRM protection required for downloading the requested LIT file. The level will be determined based on an indication from the DRM level execution database 89 for the title being downloaded. For example, if the URL created by the retailer defines a lower DRM level than specified in the execution database, an error message will be returned to the retailer 71. Also, ISAPI will capture e-book title to download from content storage 80 in a local memory cache, if not cached, remove symmetric key 14A (see Figure 1) from LIT file before cache it locally on the IIS server, and cache the 14A key in memory for future use.

In the case of DRM level 3 titles, the download server ISAPI 78 inserts the user name from the encrypted URL large binary object in the LIT file as a separate stream, re-slices the metadata with the contents of this new flow, seals the symmetric key 14A with the newly calculated cryptographic hash, and re-inserts the newly sealed symmetric key into the LIT file for download. In the case of DRM level 5 titles, the download server ISAPI generates a license XML structure (in addition to the above mentioned level 3 actions), seals the symmetric key with the public key from the activation certificate of the end user, and embed the license in the LIT file.

The download server ISAPI 78 also downloads the LIT file to the end user, frees the temporary storage used during LIT file individualization, and records each download request in either a local file on the IIS server or in the database. 91 log, using the asynchronous execution pipeline discussed below. This can be done by posting a message to the local MSMQ client resident on each download server 76.

The download server ISAPI extension DLL 78 responds to a set of commands defined by the "? Action =" parameter. Preferably, there are two actions supported by the download server ISAPI 78: download and verify. The download action is the command that causes ISAPI 78 to follow the steps identified in Figure 7 and return an e-book title to the user. The verify action is used to request that ISAPI 78 verify that a given book ID exists in content storage 80 and is ready for download. The most common command (download) might look like the following URL:

http: //content-provider.com/isapi/ds.dll? action = download & value = ...

The / isapi / parameter in the URL indicates the virtual root where ISAPI 78 was installed. In this example ISAPI 78 is named ds.dll (download server DLL). The ISAPI 78 name is followed by the action, which is followed by the relevant parameters to carry out that action (the "value" parameter in the example above). In these examples, the relevant parameters comprise the encrypted large binary object generated by the URL encryption COM object 74.

Each download request will include, in the body of the POST, the URL for the error handling page on the retailer's site 71. The download server 76 uses this URL every time an error occurs and redirects the client to that page, with the error code tagged in the request string. In the event of an error, sellers can provide an HTMl UI, a support number, an email link, or troubleshooting instructions. In accordance with one aspect of the present invention, the download server ISAPI DLL 78 preferably is error-free, but instead redirects users to the required error handling URL from the POST request.

From a data center operability and management standpoint, ISAPI 78 will expose performance counters (ie, PerfMon counters) and WINDOWS NT® events. These are typical WINDOWS® 2000 and WINDOWS NT® operational practices for data center deployment and management of server components. WINDOWS® 2000 and WINDOWS NT® events are logged each time an error occurs. Some of the key events that are preferably recorded by ISAPI 78 are:

Fail to initialize - any missing configuration and / or required environment settings that caused the ISAPI to fail on load;

Failed to connect to content store - either the UNC path returned by the content store plug-in was invalid or the content store 80 and / or network path to it is down. In either case, ISAPI must log an error so that data center operators can take appropriate action;

Illegal URL request - this event should be logged every time a URL request does not conform to the expected format or has not been encrypted using the symmetric key 75 shared between ISAPI 78 and URL COM object 74. Ideally, the full URL should be posted to the event, along with the source IP, for auditing purposes;

Failed to locate a LIT file - the path in the request was invalid or the LIT file is lost from the destination share;

ES 2 592 903 T3

Failure to cache LIT file - this can occur if content server 76 hosting ISAPI 78 runs out of memory, or if a network problem occurred during file transmission from content store 80;

Bookplate Failure - This event must be logged each time ISAPI 78 is unable to carry out individual stamping of the title. The nature of the error must be included in the event itself, for later debugging;

Title download failed - this event should be logged whenever a download fails (timeout, or connection interrupted, etc.); Y

Startup / Shutdown Events - whenever ISAPI 78 is (un) loaded, it should log an information event for this point, so that there is proper visibility. There may be cases when an ISAPI 78 is downloaded through IIS and data center operators need to restart IIS or even WINDOWS NT® to access the content server 76 back to a fully operational state.

The download server ISAPI 78 also preferably exposes the following performance counters:

Total download requests - measured in unique requests accepted since the last server startup; Total Successful Downloads - measured on unique requests fulfilled since the last server startup;

Download requests / s - number of unique incoming requests / s;

Successful downloads / s - measured in unique requests filled per second;

Pending download requests - total number of requests that have been processed at any given time;

Failed download requests - total number of failures since last server startup;

Average request processing time - measured in milliseconds, it reflects the average time that ISAPI is taking to process incoming requests; Y

Last Request Processing Time - measured in milliseconds, reflects the time it took for ISAPI to process your most recent request;

Combined, WINDOWS NT® events and PerfMon counters will allow a host of existing data center management and monitoring suites to manage ISAPI 78 during system deployment.

Asynchronous execution pipe

The asynchronous execution pipeline performs asynchronous logging of download requests to the log database 91 and asynchronous invalidations of cached entries using the ISAPI DLL on the download servers. The asynchronous pipeline server accomplishes these tasks by taking advantage of the existing store and forward functionality provided by the MICROSOFT® Message Queue (MSMQ) component of Windows® 2000.

The architecture for the execution pipeline is shown in Figures 4 and 6. The execution pipeline object 87 is executed by the MSMQ activation service and writes to the log database each time an incoming message appears in the local MSMQ client 86 input queue. Preferably, the execution pipeline object 87 is implemented as a COM object. The cache update agent 85 has an associated executable that is generated by an SQL trigger each time an update or clear operation takes place in the execution database 89. The download server ISAPI extension DLL 78 will both read and write to / from the local MSMQ independent client 86.

A registration function is preferably executed in the registration database 91 to persist all the parameters that are passed in the body of each POST request for downloads. The execution pipeline object 87 cOm is instantiated at the execution server 84 as each individual log message arrives in the local MSMQ independent client 86 input queue at the execution server 84. The schema of the registry database 91 is described in more detail below. Information from the body of each POST request to the download servers 76 is converted into an MSMQ message format and posted to the local MSMQ client 86 input queue on the execution server 84.

The MSMQ client 86 on the execution server 76 then grabs this message packet and invokes, via the MSMQ trigger service, the execution pipeline COM object 87, which converts the message to database format and writes to the database, using a Data Source Name (DSN) on the execution server 84 that summarizes the name, location, and registration credentials for the registration database from the COM object.

As the content management tool 82 updates and / or clears records from the execution database 89, a cache update agent executable 85 is triggered by the SQL server (using SQL update / clear triggers conventional). The cache update agent 85 performs a similar function to the runtime COM object 87, but in the opposite direction. Since update and clear operations on the runtime database 89 may require cache updates in the front-end download server ISAPI DLLs 78, this agent will form an MSMQ message and publish it through the client 86 separate MSMQ to all download servers 76 (runtime server 84 should have a list of all download servers 76 installed).

ES 2 592 903 T3

Upon receiving the cache update message, the MSMQ client 86 on the download server 76 calls a function in the ISAPI extension DLL 78 to update the cache. This action removes the cache entry. The next time a request is received for this particular book ID, the download server 76 will again request the execution database 84 and then update the cache with the new LIT file and its relevant attributes. The size of the cache for the download server 76 is determined by the amount of free memory on the physical server. It is preferred that the ISAPI DLL 78 allocate up to 80% of the available memory on the server.

License generation

Licenses are preferably generated for all signed and fully individualized titles (ie level 5). The original publication can also be accompanied by a license that constitutes the original signature, thus ensuring the authenticity of the electronic book that has been purchased by the consumer. Licenses can be delegated and the license chain preferably originates with the publishing providers (ie authors and publishers) and ends with the purchasing consumer. According to the present invention, rights can preferably be delegated by licensees but not by consumers. An end user license is typically generated at the time of download. In some cases, the retailer will name the rightful owner of the e-book (in the case of individual stamping) in the license, which is subsequently exposed via the UI (via a 90 or 92 reader feature) when consumers open their e-books .

Referring now to Figures 4 and 7, the procedure flow of the license generation procedure is illustrated. In step 110, the procedure begins and the request (eg, the request embedded in the encrypted URL large binary object) is parsed for attributes (step 112). If the application is well formed in step 114, then it is determined whether the application is for a level 5 license (step 118). If not, then in step 116, an error is returned and the procedure stops.

If it is determined at step 118 that the request is for a level 5 license, then it is determined at step 120 whether user principles were provided. If provided, then the principles are made persistent in a local database at step 130. If not, then at step 122, it is determined whether the user principles can be retrieved from a local database. If not, they are captured from the registration server in step 124, and if they are successful (step 126), the data is persisted in the local database in step 130. If the request to capture the data from the server Registration failed at step 126, then an event is logged (step 128), and the procedure ends at step 146.

If at step 122, the user principles can be retrieved from the local database, then processing continues at step 132, where the symmetric key is encrypted with the user's public key from the certificate. Step 132 is also performed after the user's principles are persisted in the local database at step 130. Processing then continues to step 134, where it is determined whether the license is individualized. Step 134 is also where processing continues if at step 118 it is determined that the application is not for a level 5 license.

If in step 134 the license is individualized, the name of the user is included in the license as the rightful owner. Processing continues at step 136 where the license XML structure is completed with the user's name and signed. If in step 134, the license is not individualized, the next procedure continues in step 138 where the XML structure of the license is completed (without the user's name) and signed. At step 140 it is determined whether the license generation was successful. If so, then the performance counters are updated and the license XML file is returned (step 144), and if not, an event is logged and an error is returned (step 142). Processing is then completed at step 146.

Once a download has started to the execution center 73 (i.e. users have placed an order and then clicked on the link to download), in the case of a fully individualized title the ISAPI DLL 78 of download server preferably publishes a request to license module 77 to generate a single license for the e-book title being downloaded. The download request URL must provide, as part of the encrypted parameters, information so that each license can be individually sealed by the license module. These parameters include, for level 5 copies, the encrypted activation certificate downloaded to the end user during activation of their reader software. A licensed e-book cannot be opened unless the required license is present and available to the reader.

After users purchase their e-book devices or download the reader software 90, 92 from the internet, they will be encouraged to activate their readers the first time they are launched (for example, immediately after the configuration of the reader application. laptop / desktop). Activation enables the reader software to purchase completely individualized level 5 protected copies. The procedural flow of the reader activation, the end-user experience, and the client-server interactions that take place will now be described.

ES 2 592 903 T3

Every time reader 90 or 92 is launched, it checks to see if it has been activated. If not, the reader will present a dialog box reminding the user that they will not be able to obtain special titles that require full individualization for distribution unless the user activates the reader. Users can activate the reader from any retail website, while shopping with a separate browser, or from a reader's “built-in bookstore” feature (which enables communication with bookstore sites using the reader software itself instead general purpose scanning software). Still further, the reader can be activated from within a merchant site, while shopping within the reader's built-in library feature. This activation scenario can occur if, for example, the user declined to activate the reader during the first launch and now wants to purchase a fully individualized title (level 5 protected), which requires activation.

Assuming that the user has agreed to activate the reader as mentioned above, the procedure that follows will include the following steps, as illustrated with respect to Figures 4 and 8.

In step 150, the reader client opens the integrated library feature and connects, via the secure connection layer (SSL), to the activation servers 94, where users are asked to log in using, in this example, their credentials. PASSPORT ™ (step 152). If the user does not have a PASSPORT ™ account, he / she will be provided with a link to sign up for one (step 154). It is preferred that the URL to the activation server 94 is permanently pre-recorded in an Activation ActiveX control using an SSL connection so that the client can guarantee that the servers are truly the activation servers 94.

Once the user's PASSPORT ™ credentials have been authenticated (step 156), a request is made to a PASSPORT ™ API for the user's alias and email address (step 158). Subsequently, in steps 160-162, the activation servers 94 will request that the client (via ActiveX control) upload a unique hardware ID (for example, which, as noted above, can be inferred from hardware components in the user's computing device that substantially unambiguously identify the user's computing device). Next, it is determined in step 164 whether this is a new activation for the reader (as opposed to a "recovery" of a previous activation).

If it is determined to be a new activation in step 164, then the procedure continues to step 168 to determine if an activation limit has been reached. If the limit has been reached, then an error message is presented at step 172, preferably including a support phone number. The procedure below ends at step 198. According to a feature of the present invention, users can be limited in terms of the number of activations they can perform, and / or the frequency at which they can perform them (i.e., how many different readers can they activate to read level 5 titles purchased under a given person). In the example in Figure 8, users are limited to five activations in 90 days after the first activation of the reader. This allows users to activate their own readers, while avoiding abuse of the DAS system. An example of the type of abuse that prevents such a limit would be a book club that purchased an e-book with its PASSPORT account and allowed thousands of its members to activate their readers with the book club's PASSPORT credentials. The limit on activations may also allow additional activations as time passes - for example, an additional activation for each 90-day period after the first 90 days, up to a limit of 10 total activations. It will be appreciated that these limits are merely exemplary, and any limit can be used in the activations without departing from the spirit and scope of the invention.

If the user has not activated all five readers in the first 90 days (or has reached a different applicable activation limit), an activation page is presented on the user's device (step 170). When the user returns to the form, the activation servers determine if the form is complete (step 174); if the form is not complete, the procedure returns to step 170 to resubmit the form until the user completes the form. Next in step 176, it is determined whether this activation is a recovery. If it is not a retrieval, then a new record is created for the user and reader and the number of activated readers for that user is increased (step 180). A pre-generated secure repository key pair is retrieved from a database (step 182) and activation certificates are also generated (step 184). The activation keys, user ID and machine ID are persisted in a database in step 186. In one example, each user (that is, person, as identified by, for example, the PASSPORT account) is assigned a pair of activation keys that are used in the activation certificate for each reader that the user activates, in case where the symmetric key 14A of the level 5 titles is encrypted with the public key in the activation key pair at the time the title is prepared for that user by the execution site 73. In a further refinement of that example, each reader device is equipped with an individualized unique secure repository that has a unique key pair associated with it, where the activation certificate for a given device contains its private key in an encrypted form using the public key associated with the secure repository. In this way, to present a level 5 title it is necessary that both the secure repository and the activation certificate are present, since the secure repository uses its private key to decrypt the private key of the activation certificate, which, in turn , is then used to decrypt the e-book title symmetric key 14A, which, in turn, is used to decrypt the e-book title content stream 16. Processing continues at step 188.

ES 2 592 903 T3

If, in step 176, it is determined that this activation is a recovery, then (in step 178) activation certificates are generated with the information that was stored in step 186, and processing continues in step 188.

In step 188, the activation servers generate and digitally sign an executable individualized secure repository (linked to the downloaded machine ID) and an activation certificate (linked to the user's PASSPORT ™ ID). The executable secure repository and the activation certificate are then downloaded to the client (steps 188 and 190). The activation certificate is encrypted (for privacy reasons) and is later uploaded by the client to the download server to prepare fully individualized copies (level 5 protected titles). The user's PASSPORT ™ ID can be encrypted and marked in the PC's registry as part of this download, for upload during business transactions. This procedure can ensure that the PASSPORT ™ ID included in the URL to download matches that of the activation certificate that is included in the body of the Post, to avoid content theft.

At step 192 it is determined whether the download was successful. If not, an event is logged and the download is attempted again (steps 194 and 192). If the download was successful, then at step 196, the user is provided with a "congratulations page" and the activation is reported as complete. The "congratulation page" may also provide a link to redeem free promotional books at this time, as a way to encourage users to activate their readers. This link can take advantage of a procedure exposed by the Activation ActiveX control to return the user to a library page in the reader. The procedure below ends at step 198.

It is preferred that once the reader connects to the activation servers 94, that the servers 94 control the entire user experience via ASP and HTML pages. These pages preferably conform to conventional specification, and will use the provided java script and style guide procedures to ensure a seamless experience that is consistent with the "look and feel" of the reader's user interface.

Part of the activation procedure for the open platform reader (for example, a reader software application installed on a PC) is the secure repository individualization and subsequent download. As discussed in greater detail in Mandatory File No. MSFT-0126, filed concurrently herewith and incorporated herein by reference in its entirety, a server component is provided (for example, server 100 of secure repository, shown in Figure 4) which is responsible for individualizing secure repository software modules for each reader instance for open platforms (for example, laptop and desktop computers). The unique secure repository hides the cryptographic keys used in the procedure to unseal and decrypt the LIT level 5 files, as well as ensuring that the decrypted level 5 content does not escape from the controlled system, and, since it is individualized for a particular hardware resists portability and, if broken, its individualization resists using the same breaking techniques in a different secure repository installed on different hardware.

As noted above, one aspect of resisting DRM abuse is limiting the number of activations that any particular user can have with a single PASSPORT ™ ID. If this number is not limited, rogue users can sign up for a “public domain” PASSPORT ™, then share the credentials for that account with all their friends (or worse, post it on the web), along with all e-books they have bought. This will quickly create a chain of piracy, since any user who activated the reader with the "public domain" PASSPORT credentials could then read individualized level 5 titles for that "public domain" account.

Therefore, according to one feature of the invention, it is desirable to have activation "quotas" that allow users to activate readers on multiple devices they own (eg, laptop, desktop, pocket PC, electronic book, etc. .) as well as allowing them to activate new devices as they upgrade their hardware, reformat their hard drives, etc., without allowing untested and unlimited activations of readers for the same PASSPORT credentials. Past experience with user behavior suggests that legitimate users activate one reader (or a small number of readers) initially, and then may activate new readers occasionally but are not likely to activate new readers as often as every day or every week. . To enable these legitimate uses of the activation system, while avoiding abuse, the number of activations for a given user (a Passport ™ ID) will be periodically increased, up to a defined maximum (which will be, for example, five activations initially) . As the user activates new devices, their quota of available activations decreases. As time passes, the number is increased, at a suggested frequency of, for example, an additional activation every 90 days (from the date of the first activation) until the number reaches 10. This type of limit will allow Users activate readers (or reactivate, that is, old readers on devices with reformatted hard drives) at a reasonable frequency, and it will resist abuse of the system by "hackers."

Activation servers 94 enforce the activation limit by storing, in activation database 102, a list of all activations that have been requested by a given PASSPORT ™ ID, along with their date stamps. If a re-activation request is made, the quota is not affected, as long as the ID of the

ES 2 592 903 T3 machine (for example, the unique number that links the secure repository to the hardware that houses the reader) is the same (since this would not result in theft, since the same PC is being activated again).

E-commerce procedure flow

An overview of the basic procedure by which e-book titles are obtained and delivered online is now described with reference to Figure 9. Using a browser or the "library pages" or reader 90 or 92, the user chooses book or books through mechanisms that the retail site implements (step 200). The user then pays for the titles, if payment is required (step 202). The transaction concludes in step 204 with a receipt page (that is, an order setup or "thank you" page) that contains links (POST requests) to download each purchased title (that is, URLs that contain the address of the content server 76, plus encrypted information created by URL encryption object 74). For completely individualized copies (level 5), a client-side script will fill the body of the POST with the activation certificate, preferably using the COM object implemented by the reader that obtains the necessary activation certificate or relevant information from it.

After clicking any of the links in step 206, the browser initiates a download from the content servers 76 (via the download server ISAPI DLL 78). For individually stamped copies (exlibris (eg, level 3)), the download server 76 adds the consumer's name to the title metadata and reseals the symmetric key 14A using a new cryptographic hash resulting from the new metadata, which now includes the username. For completely individualized copies (level 5) a license is generated and embedded in the LIT file, in addition to the booklet that is being created. This license contains the symmetric 14A key that encrypted the LIT file "sealed" with the public key in the activation certificate. When the download is complete (step 208), the download server 76 records the transaction and, at the client, the reader is automatically launched (step 210). The title can be moved to a "My Library" folder (for example, on a PC using one of the MICROSOFT WINDOWS operating systems, such a folder could be called C: \ MyLibrary, and would be reserved for the storage of LIT files). The e-book opens to its cover page and the name of the rightful owner is presented under the name of the author.

The electronic commerce procedure is further detailed in Figure 10 with specific reference to the components of the DAS system. In step 1, the client 90 or 92 makes a POST request to the download server ISAPI DLL 78. The body of this post request will contain, at a minimum, the encrypted large binary object generated by the URL encryption object 74. For fully individualized copies (protected level 5) this post request will also contain the activation certificate required when the XrML license is sealed (see below).

During stage 2, ISAPI 78 extracts, from the body of the POST, the vendor ID, which is required to capture the symmetric key 75 associated with this vendor to decrypt the URL. It then decrypts and validates the download request. If the request is invalid and / or the calculated TTL has expired (for example, a possible replay attack), the download server can redirect the browser back to the bookstore site. The library site 71 should always be encapsulated in the HTTP REFERRER server variable. During this stage, an optional friendly filename can be provided by the encrypted large binary object. This string, when returned, will be used by ISAPI as the filename when the LIT title is downloaded to the end user.

In step 3, the ISAPI 78 for the book ID and the type of book ID to the content storage extension module, which then returns the physical location of the LIT file in the content storage based on any of an entry memory cache (if the LIT file being requested has been previously downloaded) or a search in the execution database 89.

In step 4, if the book ID is not found in the local memory cache of the ISAPI 78, the LIT file is retrieved from the content storage 80 and copied to the local memory cache of the ISAPI. When ISAPI caches LIT files locally, it strips the LIT files of their symmetric 14A keys and stores them in a separate cache cube, indexed by their respective ID, which can increase security.

In stage 5, ISAPI 78 will carry out some of these possible stages according to the level of DRM required for the LIT file that is being downloaded:

If the request is for a DRM level 1 file, or the LIT file is not sealed at source in content storage 80, ISAPI preferably returns an error, indicating that the appropriate error condition (invalid request or invalid title in content storage, respectively).

For sealed titles of origin (level 2), ISAPI will return the file to the end user, without any processing done on the file. This is similar to downloading any other static file.

For individually sealed titles (level 3), the username will be inserted into a new stream in the LIT file, the metadata marked with level 3 (for use by the client 90 or 92 reader), the new metadata will be sliced, and the symmetric key 14A used to encrypt the LIT file is sealed with the new crypto hash value

ES 2 592 903 T3 calculated.

For fully individualized titles (level 5), ISAPI 78 will publish, in addition to generating the aforementioned functions for level 3, a request to the license module 77, which will generate a large binary license XrML object, sign it with the certificate execution center, it will seal it with the end user activation public key, and return it to embed it in the LIT file.

For both levels 3 and 5, all processing takes place in the temporary memory space created during stage 4. This memory space will be discarded later by ISAPI, when the download is complete.

In step 6 the ISAPI DLL returns the LIT file to the IIS server 76 for download. If, during step 3, the content storage plug-in returned a "friendly name" string, this value is used in the HTTP header as the filename to be stored on the user's machine.

In step 7 the LIT file is downloaded through the IIS to the end user through HTTP. When the download is complete, IIS will call ISAPI DLL 78 again to report that the pending request was satisfied and the connection was closed. ISAPI 78 will then purge all temporary memory used during step 5.

In step 8, the ISAPI DLL 78 will use the asynchronous execution pipeline (via the local MSMQ standalone client 86) to record the transaction in the logging database 91 for later reporting and / or billing. This pipeline is also used to invalidate cache entries in the ISAPI memory asynchronously, such that any modification to content storage 80 made by the content management tool 82 will cause the ISAPI to invalidate the cached data and fall back to the extension modulus 88 (and subsequently content store 80) to retrieve the LIT file for the invalidated cache entry.

Once the e-book title has been downloaded to the client (after step 7), the reader client can be launched. This is made possible by a LIT file extension association for the reader. The reader can move the file into the local library folder (eg “C: \ MyLibrary”) and open the book on its cover page, which for level 3 titles, clearly identifies the owner above the name from the author.

Content management functionality

One of the stages in securing the content in a DRM environment is the pre-encryption of the source files (LIT files) using the symmetric keys 14A generated by the encryption tool. This procedure enables the download server 76 to seal the symmetric key 14A in accordance with the requirements of each DRM level. The execution center 73 is responsible for populating the content store 80 in accordance with its existing cataloging coding infrastructure. The execution center 73 is also responsible for communicating the book ID, the book ID type, and its associated metadata to the retail resellers that host the bookstores that point to the content provider's site for fulfillment.

In accordance with a feature of the present invention, there may be independence between the download server 76 and the content storage servers 80 of the execution center. Each book ID / book ID type pair that comes from the URL provided by the retailers 71 will be resolved into a physical path to a LIT file by the content storage extension module 88, which can be customized by each center 73. execution. This provides maximum flexibility and scalability of the content storage repository as well as the download server ISAPI DLL 78.

A bookstore (retailer) database is populated with the book IDs generated by a tool for managing the LIT files of a particular content provider data center. This procedure is supposed to take place asynchronously and by contractual agreement between the retailer 71 and the content provider (execution center) hosting the content servers 76. These IDs will be provided to the download server ISAPI DLL 78 via the URL (in the encrypted portion of the URL).

Design Considerations

Exemplary schemas for the various tables used in DAS databases are described below. Exemplary schemes are not to be construed as limiting the present invention, as other schemes are possible.

Execution database

There are three tables in the exemplary execution database. They include a Product_DAS (DAS_Product) table that contains all the information required to process a download request, a Vendors_Minoristas_Registrados_DAS (DAS_Registered_Retailers) that contains all the information about the retailers that are allowed to satisfy titles using this DAS execution facility, and a DAS_Licensee_Configuration (DAS_Licensor_Config) containing the required Licensee License provided by Microsoft for each DAS Installation Partner. There are no required relationships between these

ES 2 592 903 T3 tables; however, if table relationships are required, then each table's unique identifiers (primary keys) are used.

Product_DAS table

<td colspan="2">DAS_BookID_Path_Mapping_ID</td><td>int</td><td>not null IDENTITY (1,1),</td>

<td>BookID</td><td>varchar (256)</td><td>not null,</td><td>- example "0-201-63446-5"</td>

<td>BookIDType</td><td>varchar (32)</td><td>not null,</td><td>- example "ISBN"</td>

<td>Title</td><td>varchar (256)</td><td>not null,</td><td>- example "Tarzan of the monkeys"</td>

<td>Publisher</td><td>varchar (256)</td><td>not null,</td><td>- example "Ballantine Books"</td>

<td>UNCPath</td><td>varchar (256)</td><td>not null,</td><td>- example "\\ Store \ tarzan.lit"</td>

<td>Price</td><td>varchar (32)</td><td>not null,</td><td>- example "6.59"</td>

<td>PriceStructur</td><td>varchar (32)</td><td>not null,</td><td>- example "Retail"</td>

<td>Currency</td><td>varchar (10)</td><td>not null,</td><td>- example "USD"</td>

<td colspan="2">SecurityLevel varchar (32)</td><td>not null,</td><td>- example "5"</td>

<td colspan="2">DateUpdated datetime null</td><td>DEFAULT (getDate ()),</td><td>- last time row was updated</td>

<td>DateCreated</td><td>datetime null</td><td>DEFAULT (getDate ())</td><td>- time when row was created</td>

DAS_Registered Retailers Table

This table contains the retailer ID and secret string that is used when calculating the symmetric key 75 used to encrypt / decrypt the URLs for execution. Each string must match the string used by the retailer when the encrypted URL COM object is installed, since that is how each download request is authenticated.

(

DAS_Registered_Retailers_ID int

<td>RetailerID</td><td>varchar (256)</td>

<td>RetailerName</td><td>varchar (256)</td>

<td>RetailerDesc</td><td>varchar (4096)</td>

<td>SharedSecret</td><td>varchar (256)</td>

<td>DateUpdated</td><td>datetime null</td>

<td>DateCreated</td><td>datetime null</td>

not null IDENTITY (1,1), not null, - example “Retailer-111-888” not null, - example “Barnes &amp; Noble” not null, - example “Book retailer” not null, - - example “Making_eBooks_Happen” DEFAULT (getDate ()),

DEFAULT (getDate ())

Table Configuration_Licensetario_DAS

This table contains the configuration settings for the download server license component. When the server starts, the licensee certificate and licensee private key are read from this table and used to generate level 5 licenses for LIT files. It is preferred to store this information on the SQL server as the data is too large to be stored in the local registry of the download server, and due to security concerns that the private key of the retailers can be compromised if it is stored in a flat file. It also allows easy changes to the download server configuration parameters, since DAS partners only have to modify this table in the execution database 89 and all download servers will catch the change (via the pipeline and messaging component asynchronous execution), which simplifies management.

DAS_Licensor_Config_ID LicensorCertificate

LicensorPrivateKey

DateUpdated

DateCreated int varchar (4096) not null IDENTITY (1,1), not null, - licensee's certificate signed varbinary (350) not null, - binary form of licensee's private key datetime null DEFAULT (getDate ()), datetime null DEFAULT (getDate ())

ES 2 592 903 T3

Registration database

The log database 91 is used to log all download requests. As the download servers process requests, the asynchronous execution pipeline (based on the MICROSOFT® Message Queue Server) is used to write, via a COM object resident on the execution database server, each message from the execution database server. queue in the DAS_Reg (DAS_Log) table. This will allow DAS sites to audit their performance, and determine how many downloads took place, and when, and what are the most frequently downloaded titles, etc. This table can also be used for billing purposes. The registration database comprises a single table (DAS_Record) containing all transaction log recordings from the downloaded titles.

(

<td>DAS_Log_ID</td><td>int</td><td colspan="2">not null IDENTITY (1,1),</td>

<td>BookId</td><td>varchar (64)</td><td>not null,</td><td>- example "0-201-63446-5"</td>

<td>BookIdType</td><td>varchar (32)</td><td>not null,</td><td>- example "ISBN"</td>

<td>SecurityLevel</td><td>varchar (32)</td><td>not null,</td><td>- example "5"</td>

<td>NameOfFile</td><td>varchar (256)</td><td>not null,</td><td>- example "Alice30.lit"</td>

<td>CustomerID</td><td>varchar (256)</td><td>not null,</td><td>- example "34235433"</td>

<td>UserName</td><td>varchar (256)</td><td>not null,</td><td>- example "Pavel Zeman"</td>

<td>TransactionId</td><td>varchar (256)</td><td>not null,</td><td>- example "123-456-789"</td>

<td>License</td><td>varchar (4096)</td><td>null,</td><td>- only for level 5 content</td>

<td>- license text</td><td></td><td></td><td></td>

<td>RetailPrice</td><td>varchar (32)</td><td>null,</td><td>- example "6.59 $"</td>

<td>Cost</td><td>varchar (32)</td><td>null,</td><td>- example "5.59 $"</td>

<td>MSRP</td><td>varchar (32)</td><td>null,</td><td>- example "7.59 $"</td>

<td>DownloadAgent</td><td>varchar (256)</td><td>null,</td><td>- example "Mozzilla"</td>

<td>IPAdress</td><td>varchar (32)</td><td>null,</td><td>- example “123,456,789,000</td>

<td>DateLogged</td><td colspan="2">datetime null DEFAULT (getDate ())</td><td></td>

)

Activation database

The activation database 102 houses all the information required to activate readers as well as configuration information to operate the activation servers. There are five tables in the activation database. The Key_Pairs table supports the key pairs used when generating activation certificates. The Users table holds the PASSPORT ™ credentials for each activated user, along with the key pair ID (link in the Key_pairs table) and date of first activation. User_Devices (UsersDevices) is a list of all hardware IDs (that is, machine IDs) activated by all users. To identify which machine is being referenced, this table has a primary key constraint on User_Number (UserNum) (an internal representation of each user in the Users table) and machine_ID (MachID) (the calculated machine ID). The key_pair_table (KeyPtr) tracks the number of key pairs used from the Key_pair table. It also points to the next available key pair to use. The AS_DB_Configuration (AS_DB_Config) supports configuration items for the database and activation servers 94.

Key_pairs table

<td>ID_Key_Pair</td><td>int</td><td>not null UNIQUE IDENTITY (1,1</td>

<td>PublicKey</td><td>KeyValue</td><td>not null,</td>

<td>PublicKeyXML</td><td>KeyValue</td><td>not null,</td>

<td>PrivateKey</td><td>KeyValue</td><td>not null,</td>

<td>BinaryPrivateKey</td><td>BinKeyValue</td><td>not null,</td>

<td>AssignedToReader</td><td>Tinyint</td><td>null DEFAULT (0),</td>

/ * link to

User_devices.User_device_ID * /

DateAssigned

DateCreated

Smalldatetime smalldatetime null DEFAULT (NULL), null DEFAULT (getDate ())

ES 2 592 903 T3 (continued)

Users table

<td>UserNum</td><td>int</td><td>not null UNIQUE IDENTITY (1,1</td>

<td>FullName</td><td>varchar (60)</td><td>null,</td>

<td>E-mail</td><td>varchar (60)</td><td>null,</td>

<td>UserId</td><td>varchar (60)</td><td>not null PRIMARY KEY,</td>

<td>DateMade</td><td>smalldatetime</td><td>null DEFAULT (getDate ()),</td>

<td>ID_KeyPair</td><td>int</td><td>not null</td>

User Device Table

UsersDeviceNum MachId

UserNum DateRegistered ID_KeyPair TimesRegistered int not null UNIQUE IDENTITY (1,1), varchar (255) not null, int not null, smalldatetime null DEFAULT (getDate ()), int not null, int null DEFAULT (0),

CONSTRAINT PC_UNQ PRIMARY KEY (UserNum, MachId)

Key_pair table

NextKeyToUse ⁾ int not null

AS_DB Configuration Table / * when number of free keys falls below this number a scheduled GenKey job adds keys * /

MinKeysAvailable int not null, / * user initially was able to activate these many PCs * /

MaxPCperUser int not null, / * if user reached the previous limit, but this period has elapsed since his last Activation, user can add one more * /

GrantExtraPCPeriodlnDays int not null, / * to avoid DOS attacks (denial of service) by re-activating the same PC over and over again, this can be set in production to a low value (eg 3) but the test can be set to high for stress tests * /

MaxSamePCregistrations int not null)

DRM storage in LIT files

Each LIT file is in effect a small filesystem, consisting of a collection of storage elements and their associated streams. At the root of every LIT file is a specialized storage object for DRM. The DRM storage object sub-streams will vary depending on the DMR level by which the LIT file was distributed. In a LIT level 5 protected file, a data store contains the actual content of the e-book and a storage of DRM_store

ES 2 592 903 T3 (DRMStorage) contains all DRM-specific binary data. The DRM_store storage will include the Validation_stream (ValidationStream), DRM_stream (DRMSource), and DRM_Sealed (for source and individually sealed copies) streams. For fully individualized titles, the LIT file will also include the license flow, which includes an end user license (EUL).

License format

Below is a sample license, which is used for each fully individualized title download. The license is a construction that defines the rights that the user can exercise after purchasing the title, in addition to defining the requirements to unseal the symmetric key to exercise these rights. Examples of "rights" that could be represented in the license are presenting the content (for example, in the example of text content, reading it on a PC monitor), printing the content, or copying and pasting portions of the content. It is noted that the exemplary license format is not intended to limit the scope of the present invention as other license formats that have more or less information are possible, as other licenses have license information in different formats.

It is preferred that the language chosen to represent a license is XML, and the license format is based on the Extended Rights Markup Language (XrML) specification. This is a well known markup language to describe usage rights in a flexible way. XrML also provides great interoperability and can allow any technology investment made in components that generate and manage these licenses to be leveraged over the long term. In a preferred embodiment, only what is stated in the license is granted to the license - that is, if a right is not expressly granted, it is denied. However, it will be appreciated by those skilled in the art that other provisions are possible, such as where a default set of rights is assumed unless expressly denied or modified by the license.

The top-level tags in a collapsed format are as follows:

ES 2 592 903 T3 &lt;? Xm1 version = 1.0?&gt;

&lt;! DOCTYPE XrML SYSTEM xrml.dtd&gt;

- &lt;XrML&gt;

- &lt;BODY type = LICENSE version = 2.0&gt;

&lt;ISSUED&gt; 2000-01-27T15: 30 &lt;/ISSUED&gt; + &lt;DESCRIPTOR&gt;

- &lt;i- - -&gt;

- &lt;! - Licensed book -&gt;

- &lt;1— === i ==========

--&gt;

+ &lt;WORK&gt;

Components of the book

A chapter, and an image with summary value

Rights to use the book

- ...

— &gt;

- &lt;! - Book Licensee -&gt;

- &lt;!— —

ES 2 592 903 T3 + &lt;LICENSOR&gt;

- &lt;!- ------ —

--&gt;

- &lt;! - Book Licenses _ &lt;i— ---------------- ------ _ -&gt;

+ &lt;LICENSEDPRINCIPALS&gt;

&lt;/BODY&gt;

- &lt;l-_, τ —--- ---- ^ 77 --- ---- - = -&gt;

- &lt;! - Signature of the license body -&gt;

- &lt;!-- ' -==»--—--.......- ...... — -- &gt;

+ &lt;SIGNATURE&gt;

&lt;/XrML&gt;

The first line of the XrML structure above defines the language version of XML used to create the XrML license. The second line specifies the name of the DTD file used to parse the CAVIL file. The BODY tag provides the type of license, the version of the XrML specification used when the license was generated, and the date when it was issued. It is also the meta-tag for the entire license, which has the following subsections:

WORK, LICENSOR (LICENSEE), LICENSEDPRINCIPALS (REPRESENTED WITH LICENSE), and SIGNATURE (SIGNATURE). WORK contains all the semantic information about the license, including the rights (RIGHTS) of use. The contents of this field (including the labels) constitute the data that was sliced ​​and signed. LICENSOR contains information that belongs to the entity that issued the license, usually a 10 retailer. LICENSEDPRINCIPALS contains a series of represented parties that must be authenticated when the rights of use specified in a license are exercised. SIGNATURE contains the hash / summary of the LICENSEBODY as well as information about how the hash was created, including the algorithm used. It also includes the DIGEST encoded according to the algorithm named by the licensee when the license is issued. The DIGEST and SIGNATURE 15 tags provide the authentication information used to validate the entire license in a way that it cannot be tampered with.

BODY label structure

The main tag of an XrML license construct is the BODY tag, which contains the following tags:

ES 2 592 903 T3

- &lt;BODY type = LICENSEⁿ version = 2.0 "&gt;

&lt;ISSUED&gt; 2000-01-27T15: 30 &lt;/ISSUED&gt;

- &lt;DESCRIPTOR&gt;

- cOBJECT type = self-proving-EUL&gt;

&lt;ID type = '' MS-GUID&gt; 7BD394EA-C841-434d '

A33F-5456D5E2AAAE &lt;/ID&gt;

&lt;/OBJECT&gt;

&lt;/DESCRIPTOR&gt;

- &lt;j - -----... ......... '-&gt;

- &lt;! - Licensed book&gt;

-

- &lt;WORK&gt;

- cOBJECT type =ⁿBOOK-LIT-FORMAT&gt;

cID type = ISBN^M&gt; 8374-39384-38472 &lt;/ID&gt;

&lt;NAME&gt; A book of Jamesc / NAME&gt;

c / OBJECT&gt;

cCREATOR type = author&gt; James the firstc / CREATOR&gt;

&lt;CREATOR type = author&gt; James the seCondc / CREATOR&gt;

- cOWNER&gt;

- cOBJECT type = Person&gt;

cID type = US-SSN&gt; 103-74-8843c / ID&gt; cNAME&gt; Mike the man &lt;/NAME&gt;

cADDRESS type = email&gt; mike@man.comc/ADDRE SS&gt;

c / OBJECT&gt;

- cPUBLICKEY&gt;

&lt;ALGORITHM&gt; RSA-512 &lt;/ALGORITHM&gt;

- &lt;PARAMETER name = public exponent&gt;

ES 2 592 903 T3 &lt;VALUE encoding = integer32&gt; 65537 &lt;/ VAL UE&gt;

&lt;/ PARAMETE R&gt;

- &lt;PARAMETER name = '* modulus'^,&gt;

&lt;VALUE encoding = base64 size = 512&gt; u + aEb / WqgyO + aDjgYL xwrktqFDR4HZeIeRlg + G5vmKNZRt 9FH4ouePWz / AJYnn2NdxoJ6mcHAQ

Ve6D roj 2fxA = = &lt;/ VALUE&gt; &lt;/PARAMETER&gt;

&lt;/PUBLICKEY&gt;

&lt;/OWNER&gt;

. &lt;1— - ---- --------- wr-n—&gt;

- &lt;! - Components of the book

-

- -m-. _ .-. 1 -.- ,. = -&gt;

- &lt;PARTS&gt;

- &lt;WORK&gt;

- &lt;OBJECT type = Chapter&gt;

&lt;ID type = ”relatÍve&gt; O &lt;/ID&gt;

&lt;NAME&gt; Chapter 1 &lt;/NAME&gt;

&lt;/OBJECT&gt;

&lt;/W0RK&gt;

₌ &lt;W0RK&gt;

- &lt;OBJECT type = Image ''&gt;

&lt;ID type = '' relative&gt; l &lt;/ID&gt;

&lt;NAME&gt; Image 1: Photon Celebshots Dogs &lt;/NAME&gt;

&lt;/OBJECT&gt;

- &lt;DIGEST sourcedata = LicensorMeta&gt;.

&lt;ALGORITHM&gt; SHA1 &lt;/ALGORITHM&gt;

- &lt;PARAMETER name = codingtype&gt;

ES 2 592 903 T3 &lt;VALUE encoding = string&gt; surfacecoding &lt;/VALUE&gt;

&lt;/PARAMETER&gt;

&lt;VALUE encoding = base64 "size = 160ⁿ&gt; OtSrhD5GrzxMeFEm8q 4pQI CK WHI = &lt;/ VALU E&gt;

&lt;/DIGEST&gt;

&lt;/WORK&gt;

&lt;/PARTS&gt;

- &lt;!— ============—&gt;

- &lt;! - Rights of use of the book&gt;

- &lt;!— — . ....... - ---------—&gt;

- &lt;RIGHTSGROUP name = Matn Rights&gt; &lt;DESCRIPTION&gt; Some desc &lt;/DESCRIPTION&gt;

- &lt;BUNDLE&gt;

- &lt;TIME&gt;

&lt;FROM time = 2000-01-27T15: 30 /&gt; &lt;UNTIL time = 2000-01-27T15: 30 /&gt; &lt;/TIME&gt;

- &lt;ACCESS&gt;

- &lt;MAIN sequence = 2&gt;

- &lt;ENABLINGBITS type = sealeddes-key&gt;

&lt;VALUE encoding = base64 “size = 512&gt; lnHtn / t2dp3u + ZqLkbd7MK0K4xR4YdSX aEvuk2Loh9ZRJEcPzCw + x M7zbPrJb6ESj70 + B2fWTcx xDD + 6WUB / Lw = = &lt;/ VALU

E&gt;

&lt;/ENABLINGBITS&gt;

&lt;/MAIN&gt;

&lt;/ACCESS&gt;

&lt;/BUNDLE&gt;

ES 2 592 903 T3

- &lt;RIGHTSUST&gt;

- &lt;VIEW&gt;

₂ &lt;ACCESS&gt;

&lt;MAIN sequence = 2&gt;

&lt;enablingbits type = sealed-des-key&gt; &lt;VALUE encoding = base64. size = 512&gt; lnHtn / t2d p3u + ZqLkbd7MK0K4x R4YdSXaEvuk2Loh9Z RJEcPzCw + xM7zbPrJb 6ESj70 + B2fWTcxxDD + 6WUB / Lw = = &lt;/ VAL UE&gt;

&lt;/ENABLINGBITS&gt; &lt;/PRINCIPAL&gt; &lt;PRINCIPAL sequence = 3 /&gt; &lt;/ACCESS&gt;

&lt;ACCESS&gt;

&lt;PRINCIPAL ty pe = l ¡censor&gt; 2 &lt;ENABLINGBITS type = seaied-des-key&gt; &lt;VALUE encoding = base64 size = 512&gt; lnHtn / t2d p3u + ZqLkbd7MK0K4x R4YdSXaEvuk2Loh9Z RJEcPzWCw + xM7zbPrJb B2 6WcUB / xM7zbPrJb xM7zbPrJb + xM7zbPrJb B2 = = &lt;/ EU VAL&gt;

&lt;/ENABLINGBITS&gt; &lt;/PRINCIPAL&gt; &lt;/ACCESS&gt;

&lt;/VIEW&gt;

ES 2 592 903 T3

- &lt;PRINT maxcount = *^,5&gt;

z &lt;fee&gt;

- &lt;MONETARY&gt;

- &lt;PERUSE value = 5.OO&gt;

cCURRENCY ísocode = USD /&gt; &lt;/PERUSE&gt;

- &lt;ACCOUNT&gt;

&lt;ACCOUNTFROM id = BA-02340928392 /&gt; cHOUSE td =^,,XYZ url = '' http: // somehous e.com/payme.asp'· /&gt; &lt;/ACCOUNT&gt;

&lt;/MONETARY&gt;

&lt;/FEE&gt; _Ξ &lt;TRACK&gt;

&lt;PRO VIDERIM AM E&gt; etracker &lt;/PROVIDERNAME&gt; &lt;PROVIDERID id =^,,US1023 type = Tracker ID /&gt;

- &lt;PARAMETER name = tracking address&gt; &lt;VALUE encoding = '' urr&gt; http: // so metrackingservice / trackm e.aspx / VALUE&gt; &lt;/PARAMETER&gt;

- &lt;PARAMETER name = tracking support address&gt; cVALUE encoding = url&gt; http: // 5O metra cki ngse rvice / su ppo rt me.aspx / VALUE&gt; &lt;/PARAMETER&gt;

ES 2 592 903 T3 &lt;/TRACK&gt;

cTERRITORY&gt;

cLOCATION country =^Hus state = CA city = "EI Second postalcode = 90245 /&gt;

cLOCATION country = jp /&gt; c / TERRITORY&gt;

&lt;/PRINT&gt;

c / RIGHTSLIST&gt;

&lt;/RIGHTSGROUP&gt;

&lt;/WORK&gt;

- &lt;!— - — &gt;

- &lt;1--. Book Licensee -&gt;

- &lt;¡----- - —, - --------—&gt;

- &lt;LICENSOR&gt;

- cOBJECT type = Main-Certificate&gt;

&lt;ID type = MS-GUID&gt; 7BD394EA-C841-434dA33F-5456D5E2AAAEc / ID&gt;

cNAME&gt; Barnes and Noblec / NAME&gt;

c / OBJECT&gt;

_z cPUBLICKEY&gt;

c A LGORITH M&gt; RSA-512 c / ALGO RITHM&gt;

cPARAMETER name = public exponent ”&gt; cVALUE encoding = integer32&gt; 65537 c / VALUE&gt; c / PARAMETER&gt;

CPARAMETER name = modulus&gt; cVALUE encoding = base64 size = 512&gt; u + a Eb / WqgyO + aDjgYLxwrk tqFDR4HZeIeRlg + G5vmKNZRt9FH4oueP Wz / AJYnn2NdxoJ6mcIIAQVe6Droj&gt; =

c / PARAMETER&gt;

c / PUBLICKEY&gt;

c / LICENSOR&gt;

ES 2 592 903 T3

- &lt;!— ---=— &gt;

-

- &lt;LICENSEDPRINCIPALS&gt;

_z &lt;MAIN · »

- "OBJECT type = program"&gt;

«ID type = msprogid&gt; XrM L. i nterpreter &lt;/ 1D&gt;

&lt;NAME&gt; DRPL INTERPRETER «/ NAME&gt; &lt;/OBJECT&gt;

- «AUTHENTICATOR type = drm-module- verifier&gt;

&lt;1D type = mlcrosoftprogid&gt; ms.drm.authenticode «/ ID&gt; &lt;NAME&gt; DRMAuthenticode &lt;/NAME&gt;

₂ &lt;AUTHENTICATIONCLASS&gt;

«VERSIONSPAN min = 2.0 max = 3.4 ° /&gt;

«VERSION&gt; 5.0 &lt;/ VERSION&gt;

&lt;S ECU RITYLE VEL&gt; 5 &lt;/ S ECU RITYLE VEL&gt;

&lt;/AUTHENTICATIONCLASS&gt;

- &lt;VERIFICATIONDATA type = signaturekey&gt;

- &lt;PUBLICKEY&gt;

&lt;ALGORITHM&gt; RSA512 &lt;/ALGORITHM&gt;

- &lt;PARAMETER name = public exponent&gt;

"VALUE encoding = integer32ⁿ&gt; 65 537 &lt;/VALUE&gt;

&lt;/PARAMETER&gt;

- «PARAMETER name = modulus * '&gt;

ES 2 592 903 T3 &lt;VALUE encodíng = base64 size = “512&gt; u + aEb / Wqgy O + aDjgYLxwrktqFDR4HZe IeRlg + G5vmKNZRt9FH4o uePWz / AJYnn2NdxoJ6mcII EJ2 / VALE6Dro&gt;

&lt;/PARAMETER&gt;

&lt;/PUBLICKEY&gt; &lt;/VERIFICATIONDATA&gt; &lt;/AUTHENTICATOR&gt;

&lt;/MAIN&gt;

- &lt;MAIN&gt;

- &lt;OBJECT type = ”MS Ebook Device&gt; &lt;ID type = INTEL SN&gt; Intel PII 92840AA9-39849-00 &lt;/ID&gt;

&lt;NAME&gt; Johns Computer &lt;/NAME&gt; &lt;/OBJECT&gt;

_Σ &lt;AUTH ENTIC ATO R type =^,,drminternalce rtve ri fy-p rog ra m&gt;

&lt;ID type = '' microsoft-progid&gt; 2323-2324abcd-93al &lt;/ID&gt;

- &lt;AUTHENTICATIONCLASS&gt;

&lt;VERSION&gt; lx-2.5 &lt;/VERSION&gt; &lt;/AUTHENTICATIONCLASS&gt;

- cVERIFICATIONDATA type = authenticode- named-root&gt;

- &lt;PUBLICKEY&gt;

&lt;ALGORITHM&gt; RSA512 &lt;/ALGORITHM&gt;

_z &lt;PARAMETER name = public exponent ”&gt;

&lt;VALUE encoding = integer32&gt; 65 537 &lt;/VALUE&gt;

&lt;/PARAMETER&gt;

ES 2 592 903 T3

- &lt;PARAMETER name = modulus ''&gt;

&lt;VALUE encoding = base64ⁿ . size = 512&gt; u + aEb / Wqgy

O + aDjgYLxwrktqFDR4HZe

IeRlg + G5vmKNZRt9FH4o uePWz / AJYnn2NdxoJ6mcII AQVe6Droj2fxA = = &lt;/ VALU E&gt;

&lt;/PARAMETER&gt;

&lt;/PUBLICKEY&gt; &lt;/VERIFICATIONDATA&gt;

- &lt;VERIFICATIONDATA&gt;

- &lt;PARAMETER name = bbid&gt;

&lt;VALUE in coding = ”stri ng °&gt; xxzzy &lt;/ VAL UE&gt;

&lt;/PARAMETER&gt;

- &lt;PUBLICKEY&gt;

&lt;ALGORITHM&gt; RSA512 &lt;/ALGORrTHM&gt;

- &lt;PARAMETER name = '' public exponent&gt;

&lt;VALUE encoding = ”integer32&gt; 3 &lt;/ VALUE&gt;

&lt;/PARAMETER&gt;

- &lt;PARAMETER name = modulus&gt;

cVALUE encodlng = base64

Size = 90&gt; 33845URT2039 87 = = &lt;/VALUE&gt; &lt;/PARAMETER&gt;

&lt;/PUBLICKEY&gt; &lt;/VERIFICATIONDATA&gt; &lt;/ AUTH E NTICATOR&gt;

&lt;/MAIN&gt;

- &lt;MAIN&gt;

ES 2 592 903 T3

- &lt;OBJECT type = application&gt;

&lt;ID type = ”MS PROGIDⁿ&gt; 43984938476jshd &lt;/ID&gt;

&lt;NAME&gt; MS Book Reader 2.0 &lt;/NAME&gt;

&lt;/OBJECT&gt;

- &lt;AUTHENTICATOR type = drm (nternal-digest- program “&gt;

&lt;ID type = "microsoft-progid&gt; 2323-2324abcd-93al &lt;/ID&gt;

- &lt;AUTHENnCATlONCLASS&gt;

&lt;VERSION&gt; 1 .x-2.5 &lt;/ VERSION&gt;

&lt;/AUTHENTICATIONCLASS&gt;

- cVERIFICATIONDATA type = authenticode- named-root&gt;

- &lt;DIGEST&gt;

&lt;ALGORITHM&gt; MD5 &lt;/ ALGORIT

HM&gt;

&lt;VALUE encoding = base64 size = 90&gt; bXlwYX N zd 29y ZA = = &lt;/VALUE&gt;

&lt;/DIGEST&gt;

&lt;/VERIFICATIONDATA&gt;

&lt;/ AÜTHENTICATOR&gt;

&lt;/MAIN&gt;

&lt;/ LÍCENSEDPRINCIPALS&gt;

&lt;/BODY&gt;

License authenticity

As mentioned above, the secure reader repository authenticates a license using the SIGNATURE and DIGEST tags. This is so that the client software can validate that the content being presented is 5 from a trusted source. A more detailed example of these tags is provided below:

- &lt;! - ----------- —.r. --- ..... =

Signature of the license body

ES 2 592 903 T3

--&gt; .

- &lt;SIGNATURE&gt;

- &lt;DIGEST&gt;

&lt;ALGORITHM&gt; SHA1 &lt;/ALGORITI-IM&gt;

- &lt;PARAMETER name =ⁿcodingtype&gt;

&lt;VALUE encod¡ng = string&gt; surfacecoding &lt;/VALUE&gt;

&lt;/PARAMETER&gt;

&lt;VALUE encoding = "base64 size = 160^,,&gt; OtSrhQ5GrzxMeFEm8q4pQICKW

HI = &lt;/VALUE&gt;

&lt;/DIGEST&gt;

&lt;VALUE encoding = base64 size = 512&gt; A7qsNTFT2roeL6eP + IDQFwjIz5XSFBV + NBF0eNa7de + lD6n + MPJa3J7ki8Dmwmuu / pBciQ nJ4xGaqRZ5AYoWRQ = = &lt;/VALUE&gt;

&lt;/SIGNATURE&gt;

DRM system content source scenarios

The source content is preferably distributed in an open electronic book (“OEB”) format, which will later be personalized by the retailer to each target reader. The OEB format is specified in the document titled Open eBook ™ Publication Structure 1.0, dated September 16, 1999, which is available at http://www.openebook.org/specification.htm and is expressly incorporated herein document by reference in its entirety.

Content source scenarios

Within the context of the DRM system, e-book content sources (authors and / or publishers) are expected to provide either open (ie, unsealed) or sealed copies that are ready for sale. To be distributed via the server described below, publishers must provide copies that have been sourced at a minimum, or alternatively, publishers can optionally provide source OEB / HTML files that the merchant / distributor will encrypt and store for execution. Content sources may also provide a separate file (e.g. XML, text, database script, etc.) that will provide merchant specific information about each title being distributed that will be used by the merchant / distributor to populate your execution databases. Such information may include the desired DRM level, price, advance, etc.

Since there is an expectation that a trust relationship between publishers and retailers is preferably maintained on a contractual rather than technological basis, it is generally not necessary to encrypt and / or seal titles between publishers and merchants / distributors. Such a relationship provides for easier deployment. If, however, added security is of interest, the present invention provides titles that can be encrypted when transferred between publishers and merchants / distributors.

In accordance with the present invention, publishers can distribute content to retailers by supplying a portable mass storage medium (CD, DVD, etc.); secure FTP servers on any of the publisher's or merchant / distributor's site; Secure HTTPS (SSL) on any of the publisher or merchant / reseller site; and secure specialized network connections between publisher and merchant / distributor sites.

ES 2 592 903 T3

Merchant / Reseller Scenarios

Several non-limiting distribution scenarios will now be described. The scenarios are intended to provide customer sales examples, and are not intended to limit the present invention as other scenarios are possible.

Sales of stamped copies of origin

After the purchasing customer has selected the titles he / she wishes to purchase and decides to complete an order, the merchant will process the order in accordance with its existing procedures (eg credit card validation, billing, etc.). This can include requiring users to authenticate themselves (for those who require a membership record from their clients) or simply filling out an order form. The merchant will then generate and download a receipt (electronic proof of purchase) to the purchasing customer. As indicated above, it is preferred that the electronic receipt includes all the information required to enable the user to subsequently download the titles that he has purchased through a mechanism such as a URL that points to the content server 76 and contains the generated encrypted large binary object. using the URL encryption object. Once the user clicks on the URL included in the electronic receipt to download the purchased title, the server listed at that URL (that is, the execution or content server) downloads the referenced title for the buyer. The content / download servers 76 can validate that the request was in fact made by the user attempting to download the title.

As mentioned above, original stamped copies may improperly include the name of the publisher and / or author and any other rights that have been delegated to the merchant as part of the distribution procedure. The dealer / distributor uses tools to encrypt the title with a symmetric key 14A provided through these tools. These same tools will encrypt the symmetric key 14A with a cryptographic hash of the title metadata and embed the encrypted symmetric key 14A in a separate stream in the title. When the reader software opens these titles, it will apply the same algorithm used by the tool to decrypt the symmetric key and then use it to decrypt the content. It is noted that titles purchased in this way can be easily redistributed by end users (for example, by publishing the LIT file on the Web, or by burning it to magnetic disc 29 or optical disc 31 and sending the disc to another user ); therefore it is recommended that the merchant provide warnings regarding illegal distribution on each receipt. Owners of titles sold in this manner are encouraged to include copyright information as part of the publication.

Sales of individually stamped copies

Similar to source stamped copies, individually stamped copies (e.g. level 3) require the retailer to name the rightful owner of the title in the metadata, and then stamp the symmetric key 14A used for content encryption / decryption with a new cryptographic hash of the new metadata, which now includes the owner's name. This advantageously makes the metadata tamper resistant, since any attempt to change the metadata (for example, removing the name of the rightful owner so that the rightful owner could distribute the copies and escape detection) could cause any attempt to unsealing the symmetric key 14A would fail as it would result in the wrong cryptographic hash. However, like unsigned and unstamped copies, and like source stamped copies, these titles do not provide any proactive copy protection; instead, individually stamped copies protect the owner's rights in works based on the deterrent effect that a user whose name is attached to the copy and who participated in the illegal distribution of the copy could easily be discovered.

In the scenario, the retailer usually provides the customer's name, as it appears on their credit card, as a parameter in each download URL included in the receipt page / email (i.e. proof of purchase). This information is used by the download servers 76 during execution to add the user's name to the metadata. The use of the name associated with a credit card is preferred, since assuming that the credit card is not stolen, it is a reliable source of the user's name; if the name provided by the retailer is based on, that is, user input, there is a greater danger that the user would enter a false name that would not serve the purpose of linking the user's real name to the copy.

Sales of signed copies

Signed copies (eg level 4) are titles that include a digital signature, which was provided by the content source (author and / or publisher) at the time the title was generated. This is the mechanism used to provide authenticable copies, having the data in the LIT file (or a portion of it) signed by various entities in the distribution chain. Level 4 can be combined with other levels - for example, it is possible to combine signature of origin with either Level 3 or Level 5 individualization to create a title that is both authenticable and copy-resistant (or, in the case of Level 3 , Copy “deterrent”).

ES 2 592 903 T3

Fully individualized copy sales

Fully individualized copies differ from individually sealed titles in that at run time, the merchant / distributor must always seal the license by encrypting the 14A key symmetric to the end-user public key in the end-user authentication certificate. The authenticity of the public key is confirmed by the activation certificate, which is signed by the activation servers 94. A merchant can request the signed activation certificate the first time a private consumer purchases any fully individualized title. Optionally, merchants could request such a certificate on each transaction, if the user does not have an affiliation or other relationship with the merchant. The encrypted activation certificate is provided to a retailer through a client component of the DRM system, which can be scripted through any web page. This certificate is encrypted to protect customer privacy as well as to reduce the risk of replay attacks and / or hacking. Merchants are preferred to store the encrypted activation certificate on their sites for future transactions.

Titles sold as fully individualized copies may be opened only to the purchasing consumer's reader (s) and may not be openly distributed. As part of the procedure of selling fully individualized titles, merchants can detect whether the end-user reader has been activated, which is a requirement for downloading such titles. If a merchant detects that a reader is not activated, the merchant can warn the reader that activation is necessary to open a fully individualized title. In the case where the merchant does not store an activation certificate for the particular user, it would not even be possible to provide a completely individualized title for that user. In the case where the merchant stores the activation certificate, the merchant can, for example, detect that the reader installed on the user's device through which the user is buying the title has not been activated (although that user may have other activated readers), in which case the merchant can provide the title to the user, but can warn the user that they must activate the new device to use the title on that device (submitted, of course, to any applicable activation limits).

It is noted that the above examples have been provided purely for the purpose of explanation and are not to be construed as limiting the present invention in any way. Although the invention has been described with reference to the various embodiments, it is understood that the words used herein are words of description and illustration, rather than words of limitations. Furthermore, while the invention has been described herein with reference to particular means, materials, and embodiments, the invention is not intended to be limited to the particular details disclosed herein; instead, the invention extends to all functionally equivalent structures, procedures, and uses, as they are within the scope of the appended claims. Those skilled in the art, having the benefit of the teachings of this specification, can make numerous modifications thereto and changes can be made without departing from the scope of the invention in its aspects.