HK1070714B - System and methods providing secure delivery of licenses and content - Google Patents

Description

System and method for providing secure delivery of licenses and content

This application is a continuation of and claiming priority to a partial application of the application serial No. 09/717,614 filed by Nuttall at 11/21 in 2000, a divisional application serial No. 09/05506 filed by Nuttall at 3/4 in 1998, and is now us patent 6202056.

Technical Field

The present invention relates to computer networks for data transfer and monitoring the use of such data, for example in relation to calculation of fees for usage rights.

Background

Publishers of information in digital form desire to prevent unauthorized and uninvolved distribution or use of electronically published material. Electronically published material is typically distributed and rendered on computer-based systems in a digital form. Audio and video recordings, computer programs, books and multimedia are examples of works suitable for electronic publishing. Sales revenue for e-publishing companies and the information systems industry includes calculations based on the delivery of information in digital form, e.g., the sale of an audio CD in a retail market. The unaccounted distribution of any one work results in a reduction in publisher revenue and a reduction in royalty for the owner of the usage rights of the work. For example, a digital medium from which an audio recording CD can be copied to another from which the audio can be reproduced and played avoids payment for distribution from which copyright holders would be paid royalties on copyright.

Rights-holders of electronically published works also desire to prevent unauthorized and unaccounted distribution or use of such material. When a record of the distribution and use of a work is mastered by the publisher exclusively, the falsification of the record results in an increase in the publisher's profit and a loss of royalty revenue for the rights-holder.

Unauthorized and unaccounted distribution can be controlled by preventing unauthorized copying of the work onto a digital storage medium and unauthorized transmission of the work over a computer network. Unauthorized and unaccounted use can be controlled by preventing the storage of the work for reuse or monitoring the use of the stored copy.

Existing systems and methods for preventing the storage, transmission, and non-monitored use of digital works place a significant cost burden on consumers desiring access to the works in digital form. Without a system and method for providing an accurate basis for computer network operations for usage fees, the publication and use of ever-expanding digital works cannot be kept within policies regarding intellectual property protection, such as encouraging to authors and distributors.

Disclosure of Invention

A system for distribution and usage control of digital works includes a distribution and usage reporting mechanism for accurately calculating fees associated with such distribution and usage. The system operates according to a method for transmitting data from a content providing node to a content requesting node. The method comprises the following steps: (a) transmitting a first request to said content providing node, said first request notifying an authorized node; (b) receiving a permission from said authorizing node in response to said notification; (c) determining a file name in response to the permission; (d) transmitting a second request including the file name to the content providing node; (e) transmitting a first report to an event reporting node in response to receiving said permission; (f) receiving data from a file; (g) transmitting a second report to the event reporting node in response to receiving the file.

By obtaining permission without direct communication between the content requesting node and the authorizing node, manipulation of the authorizing node by the content requesting node is prevented. To receive unlimited authorization, the content requesting node has an incentive to manipulate the authorizing node. The content providing node has an incentive to maintain proper authorization because the revenue to the content providing node may be based on the number of authorized transfers.

Although a work may be identified in a request received at a content providing node, it is possible to prevent the content providing node from obtaining information about the file names that make up the work. The content providing node may have an incentive to provide free delivery of the work for other commercial and personal use; however, by determining the file name in response to the license and preventing access to the license from the content providing node, the content providing node cannot identify the specific file corresponding to a specific work.

By transmitting reports from the content requesting node to an event reporting node, modification of data transmission reports by the content providing node is prevented. Accurate records are provided, for example, regarding fees payable to the right owners of the work.

By transmitting a first report before data transfer and a second report after data transfer, the duration of data usage can be used as a basis, for example, for revenue to distributors and payment to rights-holders. The falsification of the usage duration by the content requesting node is prevented.

Drawings

Embodiments of the invention will hereinafter be described in detail with reference to the accompanying drawings, wherein like reference numerals denote like elements, and:

FIG. 1 is a block diagram of a network in one embodiment of the invention;

FIG. 2 is a data flow diagram of a portion of the network of FIG. 1, particularly the creation of content files at a content providing node;

FIG. 3 is a data flow diagram of a portion of the network of FIG. 1, particularly for satisfying a data transfer request;

FIG. 4 is a data flow diagram of a portion of the network of FIG. 1, particularly to effect payment, for example, to an owner of rights to the transferred data;

FIG. 5 is an output table of reports on lost transmissions;

FIG. 6 is a functional flow diagram of a portion of a method of acknowledging a request by an authorizing node;

FIG. 7 is a functional flow diagram of a portion of a method for creating a permit by an authorizing node;

FIG. 8 is a functional flow diagram of a portion of a method for a content requesting node to validate a license;

FIG. 9 is a functional flow diagram of a portion of a method of reporting the start of a data transfer by a content requesting node;

FIGS. 10 through 12 are functional flow diagrams of portions of a method of obtaining and using a content file and reporting a summary of a data transfer;

FIG. 13 is a storage diagram of one data structure of the mapped file of the present invention;

FIG. 14 is a storage diagram of one data structure for a content file header of the present invention;

FIG. 15 is a memory diagram of one data structure of the request of the present invention;

FIG. 16 is a memory diagram of one data structure of the license of the present invention;

FIG. 17 is a memory diagram of one data structure for the start report of the present invention;

FIG. 18 is a stored diagram of one data structure of the summary report of the present invention;

FIG. 19 is a memory diagram of one data structure of an access report of the present invention;

FIG. 20 is a memory diagram of one data structure of the debit report of the present invention;

FIG. 21 is a functional block diagram of a system according to various aspects of the present invention;

FIG. 22 is a functional flow diagram of a portion of a method of selling a license;

FIG. 23 is a functional flow diagram of a portion of a method of delivering a product;

FIG. 24 is a functional flow diagram of a portion of a method of detecting a security breach;

FIG. 25 is a functional block diagram of an architecture that includes a dataflow description according to various aspects of the present invention;

26A-26I show a memory map of a data structure used in the architecture of FIG. 25.

Detailed Description

Data transfer between computer systems in the present invention is illustrated using a communications network. The communication network of the present invention comprises at least one computer system at each of several network nodes. Sometimes each node is coupled by a connection in order to communicate with other nodes of the network. Each connection includes conventional types of computer communication technology such as local area, wide area, dedicated telephone or satellite services and includes conventional data communication hardware and software. Popular computer networks like the known internet, the world wide web and the National Information Infrastructure (National Information Infrastructure) are examples of such communication networks having node communications that may be in physically separate locations and addressable by node addresses, such as a Uniform Resource Locator (URL), a name from a Domain Name System (DNS) or an internet protocol address (IP).

The communication network 100 in fig. 1 includes computer systems that communicate for data transfer, each represented by a block. By illustrating the communication of messages with lines between one or more blocks, although one communication link between any two blocks is clearly sufficient for any number of message lines. The variations in the implementation of the present invention are independent of whether such a link is maintained continuously as a dedicated line, or for the duration of the message as in some public multiple access facilities.

Communication technology provides well-known mechanisms and computer software for messaging. The technique encompasses the message content data with other data, providing a mechanism for a variety of purposes including tracking messages, synchronizing devices, and ensuring accurate and secure delivery of message content data. In the following description, a digital work is transferred between nodes. Thus, the term "content" refers to a piece of digital work or a portion thereof.

Network 100 includes content acquisition node 102, content management node 104, provider preparation node 106, content providing node 108, content requesting node 110, authorizing node 112, banking node 114, event reporting node 116, and reconciliation node 118.

In operation, once requested, content is delivered to potentially millions of possible content requesting nodes, the content is first received from a source and formatted for storage on potentially thousands of one or more content providing nodes. Initially, a content developer, publisher, or distributor provides digital works, such as multimedia files, to content acquisition node 102 for encoding in an efficient format for storage and access by content management node 104. When content becomes manageable by content management node 104, it is transmitted on line 130. Content from content management node 104 is transmitted on line 132 and then made unique to each content providing node 108 by being formatted by provider preparation node 106. Content providing node 108 sometimes receives content from provider preparation node 106 on line 134.

In a preferred embodiment with respect to the internet, to request a data transfer, a user or consumer uses a web browser, such as Microsoft internet explorer, at content requesting node 110, followed by an internet link (clicking on the displayed portion of the HTML file), resulting in the transmission of an HTTP formatted message on line 136 to content providing node 108. content providing node 108 forwards the request on line 138 to authorizing node 112. if the request is valid, authorizing node 112 creates a license and sends it on line 146 to content requesting node 110. a license is a message created to uniquely respond to a request from a particular content requesting node.using portions of the license, content requesting node 110 requests a particular file from content providing node 108 on line 136. in response, such particular file is transmitted on line 148 to content requesting node 108, the data transfer is completed.

Accounting for the transfer of such content includes, for example, receiving payment from a user of content requesting node 110, making payment to at least an operator of content providing node 108 for a publishing service, and making payment to one or more rights-holders of the content. The exact basis of these accounting transactions is the reconciliation of reports from the various network nodes reported at respective times during the data transfer process. For example, when authorizing node 112 receives the request and queries an access rights database on content managing node 104 via lines 140 and 142, content managing node 104 records the query and reports the record, sometimes on line 156, to reconciling node 118. With the identification of the content requesting node 110, the identification of the user, and knowledge of the price of the requested work with respect to the purpose of the request (e.g., copying or previewing), the authorizing node confirms a debit of the account held at banking node 114 via the message transmitted on line 144. Banking node 114 records the debit and reports the debit to reconciling node 118, sometimes on line 154. When the data begins to be transferred and at least some of the data has been transferred, the content requesting node 110 reports on line 150 to the event reporting node 116. Event reporting node 116 logs the event and reports the log to reconciling node 118, sometimes on line 152. By comparing reports received on lines 152, 154, 156 and possibly 158 (from content providing node 108), reconciling node 118 distinguishes valid, complete data transfers from incomplete transfers and interference events that can be indicative of an intent on the entire network 100. For each valid full transfer, reconciling node 118 assigns revenue generated from the debiting of the user account, as discussed above with reference to line 144. Reconciling node 118 then initiates the transfer of funds to banking node 114 in a message on line 160 for payment of, for example, issuance fees and royalties.

Each node of network 100 may represent more than one conventional computer system, particularly one that performs the methods of the present invention. Multiple computers or multiple data storage devices may be necessary to maintain the functionality of a particular node operating during network transmission peaks. Such multiple computers may be located in different physical locations, as long as only one network address (e.g., an IP address) is associated with a node.

A method of the invention for preparing content suitable for storage on a content providing node comprises separation of content and mapping information. When content is divided into several files in a conventional file storage system for convenience, the mapping information identifies the particular files from all the inventory on the storage system and the order in which they appear for the reconstruction of a particular work. The separation of content and mapping information facilitates security measures without unduly compromising the rapid delivery of a work or the performance of a work at a content requesting node.

For example, as shown in FIG. 2, the content acquisition node 102 (using conventional data formats and compression techniques) encodes contract terms relating to the work and encodes the work itself when the work is primarily an audio recording, the contract terms may additionally include album name, producer, trademark, publisher, mail order company, year of publication, bar code, album and song release level, song title, performer, author, composer, ISRC code for title, language, number of channels, duration, time at which the selection begins and ends, number of allowed copies, price for preview (listening), price for making copies, rights collection association, authorized release area, album cover photograph, liner logo, other graphics, music style, related countries, and graphics that may be displayed with the recording and text when the work is played, receiver processes 204 and 206 on the content manager node 104 (using conventional communications and data storage techniques), the encoded contract terms and content are received and stored on an access rights database (AADB)208 and a content master store (content masters store)210, respectively.

Upon identifying a particular content providing node 108, the work to be provided by that node is selected from content master store 210 and scrambled (scrambled) via process 204 (using conventional data security techniques). Scrambling is a preferred (although insufficient) form of encryption that ensures some security without unduly burdening the transfer of data or the use of the work when requested. The result of scrambling a work is to combine it with a header that includes cryptographic data from the rights database 208 to form one or more content files. The content file 217 is transmitted for storage on the memory 216 of the content providing node 108.

Process 212 prepares mapping file 218 for transfer and storage onto memory 216. The descriptors of the work, of the content files, and of the content providing node 108 are obtained from the AADB208 and formatted and encrypted by the process 212 (using conventional data formatting and encryption techniques). Some or all of the descriptors may be subject to strict encryption, alone or in combination. The image file allows the content file to be randomly located in memory 216 or at least unpredictable, substantially reducing the likelihood of unauthorized access given that system performance deteriorates because the content file 218 is encrypted on memory 216.

In a preferred example for audio recordings, the mapping file comprises a version number of a set of content files and a node address and pathname to the set of content files. The node address corresponds to the unique node address of the content providing node for which the content file is prepared. Each node address and path list is encrypted separately. Each content file of the set provides a different level of sound quality for the same audio material. Providing different levels of quality, for example, to meet the adaptation of audio fidelity to different content requesting nodes. FIG. 13 illustrates an example map file data structure 1300 instantiated in memory at provider preparation node 106. FIG. 14 illustrates a data structure 1400 of a header of an example content file instantiated in memory at provider preparation node 106.

For ease of access, the content file 217 and the mapping file 218 are organized on the storage 216 using a conventional file system such as a dictionary system, shaded (shaded) physical drive, or RAID system.

As indicated by the ellipses in fig. 2, many content acquisition nodes may provide content to content management node 104. Many content providing nodes may be provided with content files from content managing node 104. It is preferable to operate network 100 with physically independent nodes 104 and 106 due to different security and transport support requirements. In a variation, the functionality of the nodes 104 and 106 may be combined onto one node or with the content acquisition node 102.

Advantages of using the different methods of the present invention with respect to data transfer are (a) the cooperation of several network nodes, (b) the connection of a request through a registered node, (c) the creation of a license using data from multiple sources, (d) the use of encryption, the current time of day, or an encryption key based on a unique parameter of a node, and/or (e) the provision of unique structures and individual access to content files and mapping files. These features accomplish, among other things, acknowledging requests, acknowledging permissions, and acknowledging data transfer operations themselves. When the acknowledgement is unsuccessful, data transfer is stopped, maintaining the integrity of the network 100. Unauthorized copying, transmission, or use of a piece of digital work may compromise the integrity of the network 100.

For example, as shown in FIG. 3, a data transfer begins at Content Requesting Node (CRN)110, where a consumer or service user obtains a catalog of titles, each title representing a digital work, Process 302 (using a conventional browser and operating system) identifies a title in response to user input, such as when AN on-screen cursor points to a portion of AN HTML page, a mouse-on-off ("click") and generates a message 303 in a conventional manner to Content Providing Node (CPN)108, Process 304 (using conventional HTTP messaging techniques) forwards request 305 to Authorizing Node (AN)112, FIG. 15 illustrates AN example request data structure 1500 instantiated in memory of authorizing node 112. in a variation, Process 304 determines the price billable for the type of request and title, and includes the price and price currency into the forwarded request, price information is stored in file 306, which can be edited by AN operator of content providing node 108 In a preferred embodiment, the confirmation payment process 310 obtains price information from each content file via the associated mapping file after confirmation of the request is determined.

Process 308 acknowledges requests that do not meet the predetermined criteria by denying further processing of the requests. In one variation, as shown in FIG. 6, process 308 includes starting the steps at step 600. In step 602, the node address of the Content Providing Node (CPN)108 is obtained from the access rights database (AADB) 208. At step 604, the CPN node address provided by the request 305 is compared to the CPN node address provided from the AADB 208. If a match is found, control passes to step 606, otherwise to step 608 where the request is ignored. At step 606, the node address of the calling page (including the connection from process 302) is compared to the CPN node address provided by AADB 208. If a match is found, the request is considered valid and control passes to process 310, otherwise to step 608 where the request is ignored.

Process 310 (using conventional database and communication techniques) confirms payment by the user by confirming that the user (via payment price process 310) has made an appropriate debit in the user's account. If a debit cannot be confirmed, request 305 is ignored. If the debit transaction is successfully confirmed, control passes to process 312.

Process 312 creates a license by combining information from more than one source. In one variation, as shown in FIG. 7, process 312 includes the steps beginning at step 700. At step 700, a mapping file 315 for the requested content is obtained from storage 216 on the requesting or content providing node 108. At step 704, the content providing node address, content price and price currency are obtained from the request 305. At step 706, the local date and time is obtained from the authorizing node 112. These data entries are arranged, for example, in the format of a data structure 1600 instantiated in memory of the authorizing node 112, as illustrated in FIG. 16. At step 708, some or all of the data in the license data structure 1600 is encrypted to provide a license 313. At step 710, license 313 is sent to content requesting node 110.

Process 314 validates the permit by terminating the permit of the transaction that does not meet the predetermined criteria. In one variation, as shown in FIG. 8, process 314 includes the steps beginning at step 800. At step 802, the encrypted portion of the license is decrypted. At step 804, the syntax of each content file location (content.cpn. node address.pathname) is checked. Several pathnames in the license provide ready access to content files that match the sound quality level specified in the request 305 (see fig. 15). If the syntax check fails, control passes to step 810 to terminate the transaction. Otherwise control passes to step 806 where the content requesting node address provided in license 313 is compared to the node address of content requesting node 110. If not, control is transferred to step 810. If there is a match, control passes to step 808 to compare the current date and time on the content requesting node with the datetime value marked on the license 313(AN. If the current time is more than a predetermined amount (e.g., 5 minutes) after an. Otherwise, control passes to step 812 and, where appropriate, to process 316.

The process 316 reports the start of a data transfer between the content providing node 108 and the content requesting node 110. The generation of the report may occur before the actual start of the data transfer and at an initial stage of the data transfer. A start report is made to one or more event reporting nodes specified by a list on the content providing node 108. The report is sent on a separate port by message packet techniques to avoid collisions with the data transfer itself that may be ongoing on another port. Both ports may share the same communication hardware such as a dedicated line to an internet service provider, as is well known in TCP/IP applications. Parallel ports may be arranged on two or more hardware communication links for configuration with other communication hardware and software.

In one variation, as shown in FIG. 9, the process 316 includes the steps beginning at step 900, at step 902, one or more event reporting node addresses and the content management node address are obtained from the list 318 on the content providing node 108, at step 904, a port is opened for each event reporting node on the list 318, in a preferred embodiment, ports 1000-1016 are used, although other port numbers may be used equivalently by the communication software on the content requesting node 110, after attempting to pair it with a communication, if no event reporting node successfully responds, the transaction is terminated or continued without the ability to generate a report, at step 906, a next port number from the range 1000-1016 is used, a port is opened for reporting to the content management node 104, at step 908, FIG. 17 illustrates a start report data structure 1700 instantiated in memory at content requesting node 110. for data structure 1700, such data includes a content requesting node address, a user name and password, a price, a currency, and a specified sound quality, at step 910, data from license 313 is added to the start report data structure, for data structure 1700, such data includes a location of a content file suitable for specifying a sound quality level, i.e., a corresponding content, CPN, node, address, quality, level, at step 912, data from the content file header is added to the start report data structure, at step 1700, such data includes a title, artist, copyright, duration, ID, code, type (ISRC, ISWC, etc.), ID, code, number, content providing node address, and a number of files (consecutive numbers assigned by encoding process 202), the data structure 1700 includes values describing the transaction code reported from the same user, the current date and time, an encryption key unique to the content requesting node, and a number that locates the content requesting node 110 and the country in which it is located.

Process 320 obtains and uses the requested content file. After the process 320 receives the content file header, the transaction may be terminated if the contents of the header do not compare favorably with the license. In one variation, a summary report is prepared before the data transfer of all requested files is complete. Other requirements for the file may be made in response to receiving an acknowledgement that a summary report has been received by the event reporting node. In a second variation, the duration of usage of a file is measured and reported in a summary report that is prepared and sent after all files have been received or usage is determined to be sufficiently complete. In the latter case, as shown in FIG. 10, process 320 includes the steps beginning at step 1000. At step 1002, a port is opened for the transfer of the content provider node file (in addition to the port opened for reporting described above). At step 1004, a header of the requested content file is obtained. The pathname of this content file is obtained in the license 313 for a corresponding sound quality of the content requesting node 110. After decrypting the pathname itself, the header of the specified content file is decrypted at step 1006. If, at step 1008, the content providing node address in the obtained content file header does not match the licensed content providing node address, the transaction terminates at step 1010. Otherwise, control flows to step 1012.

For example, many times the price of a preview of a work (as if listening to a portion of an audio work) is less than the price of making a copy of the limited use work, if both the requested and the permitted usage patterns indicate that a copy is to be made, then control is passed to 1202 on FIG. 12, otherwise, control is passed to 1102 of FIG. 11, steps 1102 to 1108 obtain all subsequent blocks of the requested content file, after each block is received, the digital work is executed according to the data in the respective block. For example, when an audio file is received, a recovery is made and the resulting data can be played without interruption.

At step 1110, information from several sources is combined to form a summary report. One of the purposes of the summary report is to indicate the purpose of the reconciliation, the duration of time the digital work was performed. FIG. 18 illustrates a summary report data structure 1800 instantiated in memory at content requesting node 110. For summary report 328, data entries from start report structure 1700 (having the same name) are formatted in summary report data structure 1800. At step 1112, the summary report is sent to one or more event reporting nodes through the ports opened in steps 902 and 904. The transaction is completed at step 1114.

If, at step 1012, a copy of the work has been licensed, control passes to step 1202. At step 1202, a destination file is opened on the content requesting node 110 for receiving the digital work. At step 1204, an encryption key is prepared using conventional data security techniques. At step 1206, the content file header is obtained and written to the target file. Each block of the requested content file is obtained, encrypted, and written to the target file, steps 1208 through 1214. At step 1216, the destination file is closed. The transaction is completed at step 1218.

Sometimes reports are generated by different nodes for checking the integrity of the network 100 and allocating revenue received by debiting the user's account, as described for process 310 with reference to fig. 3. Five reports are provided in the network 100. Access reports 332 are provided by content management node 104 from queries of the AADB initiated by authorizing node processes 308-312. FIG. 19 is a memory diagram illustrating a data structure 1900 of an access report record in memory of content management node 104 or reconciling node 118. The report 342 is provided by the banking node 104 from the debit transaction requested by the process 310 through the authorizing node 112. Fig. 20 is a stored diagram of one data structure of a debit report record, illustrated in memory at a banking node 114 or reconciling node 118. Reports 326 and 328 provide the start and summary information, respectively, from content requesting node 110. Data structures 1700 and 1800 correspond to a single record of the start report and summary report, respectively, instantiated in memory at reconciling node 118. Finally, report 336 describes what content files were sent and when, and may be generated by content providing node 108.

Each report consists of a number of records, each record having a number of fields (fields). Because these records have some fields in common, the comparison (collation) of data in identical fields provides the basis for distinguishing valid complete transactions from interrupted and unauthorized transactions. For example, an access report record 1900, debit report record 2000, start report 1700, and summary report 1800 each include a log value: track field of request. By noting whether all four records have the same value for this tracking field received at reconciling node 118, network integrity and allocation of funds can be reliably concluded.

One method for reconciling reports for the present invention includes an adjustment to high volume event report processing. In addition, reconciliation reports may be used to identify nodes that have suspicious operations and thus provide a way to detect unauthorized copying and use of digital works.

In conjunction with the operation of the AADB208, unauthorized use may be blocked. For example, if unauthorized transactions frequently involve the same content providing node address, the node address may be deleted from the list of registered content providing nodes by an appropriate operation on AADB 208. When a content requesting node makes a request through a link at the address of the content providing node that made the mistake, the request will be denied at the authorizing node.

An example of a reconciliation method of the present invention is illustrated in FIG. 4. event reporting node 116 receives start report 326 and summary report 328 from a plurality of content providing nodes at high transmission levels. each report is recorded as an event by process 402 using conventional database techniques. the recorded events are temporarily stored in event database 404. synchronization of multiple parallel event reporting nodes may result in additional database transactions by event reporting node 116 as recorded in event database 404.

Records from event database 404 are sometimes provided to reconciliation node 118. Process 406, using conventional database techniques, performs a comparison of records having one or more respective field values that are the same. In one variation, the tracking field is used only. Table 502 in FIG. 5 is an identification of the results of the reconciliation combined with several reports being reconciled. If reports a 332, B342, C326, D328, and possibly E336 have been recorded for a given tracking field value (or at a given time, date, content requesting node, and content providing node), then a set of messages completes a normal request and payment because it can be inferred that the data transfer has been successfully completed. Revenue is distributed by process 408 following the identification of such a reconciliation result.

If, on the other hand, one or more expected reports are not received in time to check for a given common field value, then it can be suspected that software has been manipulated at one or more nodes of network 100, compromising the integrity of the network. Due to the large number of content requesting nodes and the lack of physical control that can protect the software manipulation on such nodes, it is likely that at least some of the failures to receive all of the expected reports may be the result of the content requesting node software being manipulated. Some or all of the requested data transfers may have been successful in the cases of 508 and 510; however, the allocation of revenue may not be justified when there also remains a possibility that a user of the individual content requesting node may insist that the debiting on his account is reversed.

In accordance with conventional banking messaging and database techniques, revenue allocation is accomplished by process 408 generating a request for funds transfer through process 410 on banking node 114.

As described above, the network 100 overcomes the problems of the prior art and provides a basis for accurately calculating the revenue allocations for the rights-holders of digital works stored on the system of the present invention or transmitted in accordance with the method of the present invention. These and other benefits are provided with less system performance degradation than heretofore possible.

In various embodiments of the present invention, the particular data transfer is performed on one or more interfaces to prevent unauthorized access to the system sending the data. The access may be to read data from the sender, to change data stored by the sender (e.g., to overwrite data, modify data, or modify a reference to data), or to execute a program on a processor of the sender. According to aspects of the present invention, data transfer across such an interface is conditionally permitted according to a protocol. Such a transfer, referred to herein as a protected transfer, includes any transfer that provides a barrier to unauthorized access by ignoring information that, if relevant to the transfer, would facilitate further access. For a receiver or receiving process, when the source identification is not apparent, the protected transfer is an anonymous transfer from the point of view of the receiver or receiving process.

For example, license 313 is transmitted across an interface that includes a network connection between nodes 112 and 110 illustrated by line 146 and a protocol that is conditional upon the protocol, the protocol including the necessary events, particularly receipt of request 315 and confirmation of payment by process the network connection (line 146) is active for transmission (e.g., sending license 313) without the necessary action by the receiver of the license (e.g., node 110), as discussed above; the permission is transferred anonymously; the transfer of the license is conditionally upon receiving a request 315 that includes information (such as the network address of the content requesting node 110) for ease of sending the license, transferring each of these aspects of the license to the content requesting node 110 is one aspect of the interface between the nodes 112 and 110 and constitutes a barrier to unauthorized access to the sender through processing at the receiver node 110. The network address of node 112, the network node address of the sender (e.g., a firewall system as part of node 112 or indirect addressing of the network node address used by node 112), the identity of process 312, or the identity of the port and connection used in the transfer.

A protocol includes any system for maintaining and changing states on one side of an interface based on an ordered sequence of states and predetermined criteria for state changes. Monitoring the detected event by the process or circuit supporting the protocol; comparing the event to criteria for a change in state from one current state to the next state of the sequence; and changing the held state to a next state in response to detecting an event that must be pre-owned. The sequence may define multiple paths into or out of a particular state, each path being associated with a respective criterion.

The use of a port by a process (e.g., an application, an operating system, or any of the processes described with reference to network 100 and system 2500) on each side of the interface may affect the transfer of data across an interface. The ports may be integral to the process or to a separate functional entity. A port is a process or mechanism that provides or receives data across an interface (e.g., via a connection, bus, or dedicated channel) according to a protocol by detecting events, maintaining state, and changing state in response to detected events.

By eliminating the interface between the subsystem storing the data and the subsystem desiring access to the data, the data may be made secure from unauthorized access. The cancellation may include preventing a connection from being established, disconnecting a bus, or blocking a signal path. Where there is a potential for abuse of an interface, the risk of unauthorized data transfer across the interface may be reduced by adding a protocol to the interface (e.g., requiring transfer through a port), restricting state transitions in the protocol used for the interface, and/or using the protected transfer described above. For example, the detection of a particular event on a port of an interface (such as known security intrusion techniques) may result in a denial of access, while a large number of complex events (such as the ability to provide the correct identification of node addresses, ports, subsystems and processes associated with or present at the interface, the identification of a receiver or sender, a representation of a credential of a receiver or sender and the process of a receiver or sender) may be set to be suitable criteria for obtaining a state of entry permission for the transfer.

A system for data transfer may include a public network according to various aspects of the invention. The use of a public network, such as the internet, simplifies data communication between any number of subsystems. For example, the system 2100 of fig. 21 includes a multi-subsystem facility 2102, a public network 2112, a banking subsystem 2132, a retail subsystem 2136, and a consumer subsystem 2138. The banking subsystem 2136 and the retail subsystem are combined for data transfer via private network 2134. The multi-subsystem facility 2102 includes a private network 2110 coupled to each of the grouping subsystem 2104, the delivery subsystem 2106 and the security management subsystem 2108. Each subsystem may include one or more conventional computer systems (e.g., servers or workstations) having data stored thereon.

Each illustrated subsystem performs a subset of the functions of system 2100. Additional subsystems may be added in alternative implementations; and, the appropriate combination of functions may be performed on fewer physical subsystems that do not violate the above-described data transfer types. For example, alternative implementations of system 2100 are possible including any number of subsystems of the same functional type operating in parallel (e.g., for redundancy) at each illustrated subsystem, or at the same or different locations (e.g., for additional capabilities or specialization). Alternative implementations may include different subsystems in a multi-subsystem facility 2102 and include zero or any number of such facilities. In another alternative implementation, retail subsystem 2136 is also connected to private network 2110 and may be part of an enlarged multi-subsystem facility.

System 2100 facilitates delivery of digital products (e.g., digital works) to consumer subsystem 2138 while maintaining security of data stored on various other subsystems, including delivery subsystem 2106 and security management subsystem 2108. for example, consumer subsystem 2138 may order a product to retail subsystem 2136 via data transfer 2122. retail subsystem 2136 may communicate with bank subsystem 2132 to ensure payment for the ordered product. security management subsystem 2108 may transmit a permit to consumer subsystem 2138 to regulate access to the product by consumer subsystem 2138. furthermore, products prepared for delivery by grouping subsystem 2104 may be delivered to consumer subsystem 2138 via delivery subsystem 2106 after the permit.

The above discussion of the operation of the system 2100 without significant disruption to commercial value ensures the security of data held by the various subsystems of the system 2100 through the combined advantages of several aspects of system organization and operation. For example, data on other subsystems is made immune to processes from consumer subsystem 2138 by several means: (1) the transaction 2122 does not communicate information with the retail subsystem 2136 that results in the identification of the multi-subsystem facility 2102, its subsystems, or the banking subsystem 2132; (2) there is no interface between consumer subsystem 2138 and bank subsystem 2132; (3) there is no interface between the consuming subsystem 2138 and the grouping subsystem 2104; (4) issuing a grant via a guard transfer 2124; (5) delivering the product via a protective transport 2126; (6) the license does not include sufficient information to use the product without restriction.

The functionality discussed above with reference to system 2100 enables implementation of computer network 100 as one particular application of system 2100. Although not necessarily all nodes or unique network addresses as described above for each subsystem of system 2100, the subsystems in such an implementation may correspond to nodes as follows. The grouping subsystem 2104 may include the content requesting node 102, the content managing node 104, and the provider preparation node 106, including the processes and data storage functions discussed above with reference to these nodes. Delivery subsystem 2106 may include storage 216, list 318, send process 322, and report process 334 described above. Security management subsystem 2108 may include authorization node 112 and reconciliation node 118, including the processes and data storage functions discussed above with reference to these nodes. Banking subsystem 2132 may include banking node 114, including the processes and data storage functions discussed above with reference to that node. Retail subsystem 2136 may include file 306, form request process 304 and event reporting node 116 as well as its processes and data storage functions. Consumer subsystem 2138 may include content requesting node 110, including the processes and data storage functions discussed above with reference to that node. The method performed by system 2100 may include the execution of some of the parallel operations discussed above with reference to network 100.

System 2100 performs one such method, which includes selling a license (e.g., 2200 in fig. 22), delivering a product (e.g., 2300 in fig. 23), and detecting a breach in security (e.g., 2400 in fig. 24). In order to collaborate across different interfaces of the system 2100, each method includes a representation of a protocol. A method of selling licenses begins with a consumer requesting a catalog (2202), or in any conventional manner, indicating interest in a product through the cooperation of the consuming subsystem 2138, data transfer 2122, and retail subsystem 2136. The catalog is provided (2204) and the sale of licenses to consumers is closed (2204) in any suitable conventional manner by the cooperation of the retail subsystem 2136, data transfer 2122 and consumer subsystem 2138. Payment is sufficiently guaranteed to have been verified in any suitable manner (e.g., by debit, credit card, voucher, or gift certificate) through the cooperation of retail subsystem 2136, private network 2134, and bank subsystem 2132. If payment is not sufficiently warranted (2208) the method terminates without a transfer permit. Otherwise, a license is issued 2210 to the consumer via the cooperation of the security management subsystem 2108, the protected data transfer 2124, and the consumer subsystem 2138. In response to receipt of the license, the consumer stores the license in any suitable manner (2212), the storage being performed by consumer subsystem 2138. For example, the license may be stored in a secure registry through consumer subsystem 2138. The license may be transmitted in an encrypted format. The license in either encrypted or clear format may be encrypted prior to storage.

A method for delivering a product begins with a user requesting a licensed product (2302) through cooperation of a consumer subsystem 2138, a data transfer 2122, and a retail subsystem 2136, a delivery subsystem 2106 notices in any conventional manner (e.g., notification from retail subsystem 2136 to delivery subsystem 2106, polling through delivery subsystem 2106, or as a result of batch processing) that delivery has been requested, the delivery subsystem provides the requested product (2304) to a consumer through cooperation of a protection transfer via delivery subsystem 2106, protection transfer 2126, and consumer subsystem 2138, the consumer stores the product (2306), performs storage through consumer subsystem 2138, the product is preferably transferred in a secure format (e.g., promiscuous, encrypted, or data streaming), the product can be stored in a secure register, any time after being licensed, the consumer may use the product (2308) in a secure manner-use is accomplished at least through consumer subsystem 2138-use may require further delivery (e.g., repeating the operations discussed above with reference to 2304 and 2306) -after use, the product may again be stored (2306) -accounting of use may be accomplished in any suitable manner prior to, during, or after use.

A method for detecting security breaches begins by accepting reports of various types of received data. At least two types of received reports are received. According to various aspects of the invention, any combination of two or more of the following reports may be received for each business activity involving any consumer. The report may be received directly from the subsystem that received the data; or received after any subsystems have passed or accumulated. Preferably, the report does not create the need for any interfaces that are not already part of the license and the product delivery methods described above. The following types of reports may be received: (a) receipt of a request for a license (2204), such as through retail subsystem 2136; (b) receipt (2212) of a permit, such as a report to retail subsystem 2138; (c) receipt of a request (2302) for a product to be delivered, as received by retail subsystem 2136; (d) receipt of a notification that product delivery has begun (2304), such as a report to retail subsystem 2136; or (e) receipt of a notification that product delivery has been completed (2304), such as a report to retail subsystem 2136. For each report received at the appropriate time period, it is determined whether the report is part of a report tuple (e.g., a combination) (2406). This analysis of the reports may be done in whole or in part at the retail subsystem to ensure that consumer complaints with respect to data transfer can be easily diagnosed; and/or may be done in whole or in part at the security management subsystem 2108 to ensure that violations of permitted deliveries and uses can be easily investigated. If a mismatch report persists (2408) after analysis (2404), or if an incomplete tuple persists (2410) after analysis (2404), a security breach may be noted or reported in any conventional manner (2412).

As described above, the functions of the various subsystems of system 2100 may be performed in combination. The functional grouping of functions of system 2100 is preferably adapted to scale (scaling) sensitivity (e.g., to avoid network and computational delays) as well as scale data storage capacity (e.g., physical location of storage devices). However, if the transfer is not secured across the interface, the interface between processes performing a particular function may be omitted.

The structure of the system is the plan by which the system functions enable the responsibility of particular processes, particularly the efficient execution of the system functions and the efficient communication between processes. When an implementation of the system is developed, expanded, the system architecture is systematically adopted. For example, the system architecture 2500 of fig. 25, includes a grouping function 2501, a security management function 2502, a retail function 2503, a banking function 2504, a delivery function 2505, and a consumer function 2506. Data transfer between the grouping function 2501 and the security management function 2502 passes across the interface 2515. Data transfer between the grouping function 2501 and the delivery function 2505 passes across the interface 2516. Data transfer between security management function 2502 and retail function 2503 passes over interface 2531. Data transfer between the security management function 2502 and the consumer function 2506 passes over the interface 2530. Data transfer between the security management function 2502 and the delivery function 2505 passes over the interface 2529. Data transfer between retail function 2503 and banking function 2504 passes over interface 2545. Data transfer between retail function 2503 and consumer function 2506 passes over interface 2546. Data transfer between the consumer function 2506 and the delivery function 2505 passes over the interface 2556.

Where no data is being transferred across an interface between two groups of functions, the interface may be implemented by hosting the two groups on separate servers or on an operating system that does not allow communications between processes to exist or be ignored.

Any conventional protocol may be used when implementing an interface with a port as described above. For clarity, ports are omitted from fig. 25, but may be used as appropriate to govern any of the data transmission channels or interfaces described above. The number of ports included in one implementation according to system architecture 2500 may be reduced from that indicated by the functional groupings illustrated in FIG. 25, for example, by hosting any convenient functionality on a common host, where there is no need to establish an interface between functions. For example, if the functionality of packet subsystem 2104 and delivery subsystem 2106 are hosted on a server, interface 2516 may be omitted, and a common port supporting a network protocol appropriate for private network 2110 may be used for transferring data across interfaces 2515 and 2529; however, a separate port is recommended for protected data transfer 2565 (implementation 2126) across interface 2566. The security management function 2505 may be hosted along with other functions, but a separate port is recommended for protected data transfer 2525 across the interface 2530 (implementation 2124).

The process described with reference to FIG. 25 can be implemented in any conventional computer technology, including a multitasking environment, where the process produces output as long as enough input is received. The interactive process communication may include remote procedure calls, polling, interrupts, or other process or thread planning techniques. . The data store may use any conventional technique including, for example, a hierarchical or relational database, a document object model, or a markup language (e.g., XML).

Grouping functionality 2501 includes defining product processes 2509, establishing rights processes 2511, and issuing product processes 2513. Data relating to these functions, including authorization transparency, product definitions, and licensing terms, is stored in memory 2508. The memory 2508 includes data (also referred to as content) for the product. The data may be stored in an unencrypted (transparent) format. A product is any form of data. A product may include content from any conventional source and combined in any conventional manner. Examples of products include an executable file of a computer program, a database, a composition printed with text, a novel with artistic graphics, a newspaper subscription, a digitized song singing, an animated cartoon with audio and video, a movie with commercial breaks and subtitles, a raw or unanalyzed data stream derived from telemetry instrumentation in real time, an interactive guide for distance learning. Some of these products are delivered as a whole unit prior to use. Others are used by delivering edges in a data stream format.

A define product process 2509, which defines a product by identifying a file of a memory 2508 of the product desired to be built, as input by an operator; specifying a product identifier; and stores the aforementioned information retrievable by the product identifier to memory 2508 as a definition of a product (e.g., a first master copy). Following operator input and in response to receiving a particular product identifier 2510 from the define product process 2509, the establish rights process 2511 defines any conventional rights for using and/or configuring a product. Rights include pricing and distribution controls, and may be defined as rules using any suitable rights grammar, preferably an industry standard expression language. The rights to a particular product may be stored in memory 2508 as license terms retrievable by product identification. Rights and product definitions (e.g., including title, author, description) are transmitted to the publishing catalog information process 2519 via data transfer across interface 2515.

The architecture 2500 supports the delivery of products from numerous sites with grouping functionality to numerous sites with delivery functionality.an operator's input to the published product process 2513 can define a specific delivery site to which a product (e.g., a second master copy) is published.the published product process 2513 can encrypt or promiscuous transfer of the contents of the published product in any suitable conventional manner before the corresponding data is transferred across the interface 2516. the form selected is typically decryptable by the decryption process 2558. the key used to encrypt each delivery site or type of product or both can be unique.A key can be issued by the process 2521 and stored in the memory 2518 in any conventional manner. Published as databases having different file organizations).

The security management functions include a publishing catalog information process 2519, a publishing key process 2521, a publishing license process 2523, a schedule delivery process 2526, and an assembly report process 2528. Data associated with these functions is stored in memory 2518, including product descriptions, product licenses, keys, schedules, and delivery records. The delivery record includes a record of software delivery (e.g., software issued to the consumer subsystem in order to maintain delivery security), a record of approved delivery, and a record of delivered products. Records are retrieved in any conventional manner for access by processes 2519-2528 and for security breaches to be ascertained.

Architecture 2500 supports the distribution of product information (e.g., title, description, price, age, product identification) from a myriad of security management-enabled sites to a myriad of retail-enabled sites. The publishing directory information process 2519 distributes data that is sometimes received (2512) from the grouping function. Information for keeping a retailer's inventory up to date is distributed via data transfer 2520 to the retail site identified by operator input or schedule designation stored in memory 2518. Information may be communicated across interface 2531 to a retail site in any suitable form, including, inter alia, encryption (e.g., when the information is deemed sensitive to competition).

In response to receiving authorization to issue a license (2532), the publishing license process 2523 requests (2522) and obtains (2524) one or more keys from the publishing key process 2521. The lifetime, product identification and other fields of the license are encrypted using one or more keys before delivery to a consumer. For transmissions such as 2514 and 2565, the product is encrypted using an additional and preferably different key. The data (e.g., license) encrypted with the primary key may be encrypted with a secondary key that is preferably different from the primary key.

In response to receiving a request 2543 made by the create delivery process 2542, the schedule delivery process 2526 determines an appropriate date and time to initiate delivery of the requested product. The plan may give priority to predetermined requests, products, consumers, age and type of network load. Schedule delivery process 2526 may maintain a queue for each priority and arbitration among the queues to choose to pull one queue to provide delivery product request 2527 to delivery function 2505. Request 2357 crosses interface 2529 and may be subject to passing through a port at the interface in order to improve security.

When a request 2527 has been made, schedule delivery process 2526 reports status 2544 to establish delivery process 2542. In response to receiving a report from delivery product process 2563 (e.g., delivery start, delivery end, delivery interrupt), schedule delivery process 2526 may report the same (2544) to setup delivery process 2542.

The build delivery process 2542 may periodically provide reports 2547, in raw or tuple form, to the assembly reporting process 2528. The compile report process 2528 analyzes the reports for any implied breach in usage rights and reports the results to the operator. The assembly reporting process 2528 maintains delivery records in memory 2518 and responds to operator input for the representation of the summary, or query analysis based on the delivery records using any conventional database analysis and representation techniques. In an alternative implementation, the compilation reporting process 2528 may direct the banking function to make royalty payments for delivery and use of the processed work, as various products over a period of time.

The retail functions include a hold catalog process 2534, a sell permit process 2536, a guarantee payment process 2539, and a set up delivery process 2542. Data associated with these functions is stored in memory 2518, including catalogs, periodic product subscriptions (e.g., newspapers), and transaction records.

The keep catalog process 2534 receives updates 2520 and stores current catalog information (e.g., including numerous catalogs appropriate for different types of consumer requests) in memory 2533. for a license based on any form of usage rights that are priced in the catalog, the catalog information is sufficient to end a sale.

The sell license process 2536 receives a request to purchase a license from the order license process 2582 and, in response, requests (2537) and receives (2535) a catalog information request to complete the sale of the requested and possibly related license. Sales may include returning a license (2581) for credit or in place of any other license (e.g., expansion or compression usage rights for the same or a different product). The sales license may receive a purchase confirmation and proceed to collect payment when a purchase confirmation request is provided to the consumer.

Payment process 2539 receives authorization (2538) from sales approval process 236 to prepare a financial transaction resulting from a sales activity (e.g., purchase or refund). The assurance payment process 2539 submits one or more financial transactions 2540 (e.g., debit, credit, transfer) to the transparent transaction process 2550 and receives confirmation 2541 of successful reconciliation of an account. In response to receiving such confirmation, the payment process 2539 is assured of notifying (2532) the issue license process 2523 to issue a license as described above. Without confirmation from the transparent transaction process 2550, the issue will not be granted because no request for the issue license 2532 will be transmitted across the interface 2531.

The establish delivery process 2542 receives requests for licenses and product delivery. In response to receiving the request for operating software from the registry process 2572, the setup delivery process 2542 notifies the schedule delivery process 2526 to initiate the requested delivery. Operating software may be required and delivered using the same request and delivery paths discussed herein for the product. In particular, delivery of the software may include protection transfer 2565 as described above. In response to receiving a request to deliver a product from order product process 2578, build delivery process 2542 notifies schedule delivery process 2526 to initiate the requested delivery.

The establish delivery process 2542 receives the various reports (2577, 2580, 2544) as described above with reference to method 2400. Establishing a delivery process may perform any method (e.g., 2400) to determine and report an indication of appropriate and inappropriate delivery to the security management function 2502. To develop advances, develop consumer needs, or promote products, information relating to the appropriate delivery is reported to the operator or traditional retail process.

The banking functions include a transparent transaction process 2550. Accounting tables and transaction records are stored in data store 2551. Banking functions may be implemented through any conventional financial clearing institution's network. The account information may be distributed among a variety of commercial banking institutions, each providing a portion of the banking functions shown.

The delivery functions include a keep inventory process 2555, a read process 2556, a decrypt process 2558, an encrypt process 2561, and a deliver product process 2563. Data relating to these functions is stored in memory 2554, including the product in encrypted form, an index based on the identity of the product. Keeping inventory receives products that are issued to it by the grouping function, i.e., the issue products process 2513. The products may be stored in memory 2554 for security, easy access, and maintenance, in any suitable conventional manner.

In response to receipt of a request 2527 for delivery of a product, the read process 2556 accesses the product inventory on the memory 2554 to obtain the product to support the requested delivery mode (e.g., download in its entirety, streaming at a specified data rate, or broadcast or multicast to multiple consumers). then, the access read process queries access to the product (or portion) 2557 through the decryption process 2558 so that the encryption and security functions imposed by the issuing product process 2513 can be eliminated.A read process provides the decryption and encryption processes 2558 and 2561 with the key provided in the request 2527. transparent content 2559 is provided by the decryption process 2558 to the encryption process 2561. the encryption process 2561 encrypts the transparent content to provide encrypted content 2562. the delivery product process 2563 receives the encrypted content 2562 and provides it to the administrative product copy process 2583 through a protected transfer. at the time of starting and completing delivery, delivery product process 2563 may provide report 2564 to schedule delivery process 2526 delivery product process may also report receipt of request 2527 to deliver a product delivery product process may include a port to any conventional communication protocol, including wired and wireless protocols.

The consumer functions include a registry process 2572, an administrative licensing process 2574, an order product process 2578, an administrative product copy process 2583, and an order licensing process 2582. Data associated with these functions is stored in memory 2570, including the consumer's keys and secure registrations. The consumer's key may be a simple symmetric key or may be the public key of a public/private dual key system issued by the issue key process 2521. The secure registration includes subscription permissions, subscription content, and information necessary to use the content that has been delivered to the consumer.

A computer (e.g., a personal computer, personal digital assistant, wireless device, telephone, laptop, or workstation), after installing and configuring software, may form a consumer substation with system 2500 in order to perform the functions described herein. Such software may include: a proper operating system (e.g., to ensure that security functions are not breached); access software for connecting and browsing a public network (e.g., a conventional web browser for browsing and shopping over the internet); software for full access to the registry and package to establish a secure package, a secure registry and a secure manager; special purpose software for using the delivered product (e.g., word processor for using text-based products, media player for using audio and video products, online decryption/encryption software for using products in a cryptographic form); keys stored in the registry or using a secure package, e.g., for requesting other functions of the system 2500; tamper-resistant software to make unauthorized analysis and modification of installation configuration difficult; and tamper evidence software that detects and reports attempts to analyze and modify (e.g., replace) installation configuration components including secure packaging, secure registration, licensing, and products. Such software may cooperate with hardware (e.g., circuit components, smart cards, or read-only media) that forms part of the installation configuration. Such software and hardware and performs appropriate conventional functions in addition to those described herein in cooperation with consumer functions 2506.

The following processes may be implemented in cooperation with a browser to simplify shopping and product usage by providing a user with a unified interface that hides the details of the communication methods discussed above.

The registration process 2572 makes requests for addition and updating of software configurations for the consumer subsystem when a timer expires automatically or when user input. The registration process 2572 provides a request 2573 to establish a delivery process to initiate delivery or updating of the software.

In response to the user input, the subscription license process 2582 makes a request 2581 to purchase a license. The request may be the result of a purchase or may initiate a purchase by the consumer. Shopping includes presentation of directory descriptions in response to any conventional query specified by a consumer's substation. Such a request initiates the sale for the issuance of a license as described above. By providing the permission via a protected transfer, the user's security attack is likely to be ineffective because the user is not provided with enough information to search for additional information that may assist in the security attack.

The manage permissions process 2574 receives a permission via protection send 2525 and reports this receipt to the establish delivery process 2542 (2577).

In response to user input, the order product process 2578 requests (2576) and obtains (2575) usage rights and product descriptions from the manage licensing process 2574, representing a result of a query on the current licensed product that has not been delivered. A request for delivery of a product (2579) preferably includes a copy of a license granting permission to receive the right to the product. The permission is forwarded by retail function 2503 and then by security management function 2502, once executed by delivery function 2505, may be implemented using any conventional indirect addressing technique, including implementation according to an internet protocol (e.g., HTTP) or conventional firewall design.

Table 1 describes fields used in the data structure illustrated in fig. 26. The data structure of fig. 26 may be represented in memory or in a message using any conventional technique. Each data structure implements combinations among the function flag values described in the table (e.g., each combination is a tuple).

TABLE 1

The invention has been described with reference to the preferred embodiments thereof. Several variations and modifications are also described and suggested. Those skilled in the art will readily recognize variations and modifications that can be made thereto without departing from the spirit and scope of the invention as defined by the appended claims.

Claims (32)

1. A method, comprising:

receiving a request for a product from a requesting node, the request received by a providing node;

providing the request from the providing node to the authorizing node;

receiving a license from the authorizing node in response to the request, transmitting first electronic digital data in a first protected transfer to deliver the license to the requesting node;

transmitting second electronic digital data in a second protected transmission to deliver the product to the requesting node identified by the license;

preventing the requesting node from identifying the authorizing node;

receiving at least two reports of a plurality of reports during a time period, wherein the plurality of reports includes a permit request report, a permit delivery report, a product delivery request report, a product delivery start report, and a product delivery completion report;

classifying the report as a tuple of related reports;

determining whether there is a mismatch in the particular report;

determining whether a particular tuple is incomplete; and

providing notification of a security breach based on at least one of whether the particular report does not match and whether the particular tuple is incomplete.

2. The method of claim 1, wherein the requesting node and the providing node communicate via a public network without a firewall between the providing node and the public network.

3. The method of claim 1, wherein:

the first delivery system transmitting the permission responsive to the public network link to the requesting node; and

the second delivery system transmits the product responsive to the public network link to the requesting node.

4. The method of claim 1, wherein a portion of the license is encrypted.

5. The method of claim 1, wherein the request for the product includes at least a portion of the license.

6. The method of claim 1, wherein each request is received via a public network link.

7. The method of claim 1, wherein the product comprises at least one of a digital work, a file, an audio recording, a video recording, an executable program, a document, a multimedia program, and content.

8. The method of claim 1, wherein the step of transmitting the second digital data comprises: the product is downloaded in its entirety.

9. The method of claim 1, wherein the step of transmitting the second digital data comprises: the product was discharged.

10. The method of claim 1, wherein the step of transmitting the first digital data comprises:

detecting a prerequisite event, the event being receipt of a notification that payment for the license has been guaranteed by the providing process; and

third electronic digital data is transferred across the interface and from the port according to a protocol that refuses entry into a state of transferring the license until the event is detected.

11. The method of claim 1, wherein the step of transmitting the second digital data comprises:

detecting a prerequisite event, the event being at least one of receiving a notification, receiving at least a portion of the license, receiving a key for encrypting the product, and determining a network address for delivering the product; and

third electronic digital data is transmitted across the interface and from the port according to a protocol that refuses entry into a state of delivery of the product until the event is detected.

12. A system, comprising:

means for receiving a request for a product from a requesting node, the request received by a providing node;

means for providing the request to an authorizing node;

means for receiving permission from the authorizing node in response to the request;

means for transmitting first electronic digital data in a first guard transfer to deliver the permission to the requesting node;

means for transmitting second electronic digital data in a second protected transmission to deliver the product to the requesting node identified by the license;

means for preventing the requesting node from identifying the authorizing node;

means for receiving at least two reports of a plurality of reports during a time period, wherein the plurality of reports includes a permit request report, a permit delivery report, a product delivery request report, a product delivery start report, and a product delivery completion report;

means for classifying the report as a tuple of related reports;

means for determining whether there is a mismatch in a particular report;

means for determining whether a particular tuple is incomplete; and

means for providing a notification of a security breach based on at least one of whether the particular report does not match and whether the particular tuple is incomplete.

13. The system of claim 12, wherein the requesting node and the providing node communicate via a public network without a firewall between the providing node and the public network.

14. The system of claim 12, wherein:

the first means for delivering transmits the permission responsive to the public network link to the means for receiving; and

the second means for delivering transmits the product responsive to the public network link to the means for receiving.

15. The system of claim 12, wherein a portion of the license is encrypted.

16. The system of claim 12, wherein the request for the product includes at least a portion of the license.

17. The system of claim 12, wherein each respective request is received via a public network link.

18. The system of claim 12, wherein the product comprises at least one of a digital work, a file, an audio recording, a video recording, an executable program, a document, a multimedia program, and content.

19. The system of claim 12, wherein said means for transmitting second digital data comprises: means for downloading the product in its entirety.

20. The system of claim 12, wherein said means for transmitting second digital data comprises: means for discharging the product.

21. The system of claim 12, wherein said means for transmitting the first digital data comprises:

means for detecting a prerequisite event, the event being receipt of a notification that payment for the license has been guaranteed by the providing process; and

means for transferring third electronic digital data across the interface and from the port in accordance with the protocol that refuses entry into a state of transferring the permission until the event is detected.

22. The system of claim 12, wherein said means for transmitting second digital data comprises:

means for detecting a prerequisite event, the event being at least one of receiving a notification, receiving at least a portion of the license, receiving a key for encrypting the product, and determining a network address for delivering the product; and

means for transferring third electronic digital data across the interface and from the port according to a protocol that refuses entry into a state of transmitting electronic digital data of the product until the event is detected.

23. A method for reducing the risk of unauthorized access to an electronic digital data product, the method comprising:

receiving a request for a product from a requesting system, the request received by a delivery system;

providing the request to an authorizing node;

receiving permission from the authorizing node in response to the request;

transmitting first electronic digital data in a first guard transfer to deliver the license to the requesting node;

transmitting second electronic digital data in a second protected transmission to deliver the product to the requesting node identified by the license;

preventing the requesting system from identifying the authorizing node;

receiving at least two reports of a plurality of reports during a time period, wherein the plurality of reports includes a permit request report, a permit delivery report, a product delivery request report, a product delivery start report, and a product delivery completion report;

classifying the report as a tuple of related reports;

determining whether there is a mismatch in the particular report;

determining whether a particular tuple is incomplete; and

providing notification of a security breach based on at least one of whether the particular report does not match and whether the particular tuple is incomplete.

24. The method of claim 23, wherein:

the delivery system transmitting the permission responsive to the public network link to the receiving system; and

the second delivery system transmits the product responsive to the public network link to the receiving system.

25. The method of claim 23, wherein a portion of the license is encrypted.

26. The method of claim 23, wherein the request for the electronic digital data product includes at least a portion of the license.

27. The method of claim 23, wherein each request is received via a public network link.

28. The method of claim 23, wherein the product comprises at least one of a digital work, a file, an audio recording, a video recording, an executable program, a document, a multimedia program, and content.

29. The method of claim 23, wherein the step of transmitting the second digital data comprises: the product is downloaded in its entirety.

30. The method of claim 23, wherein the step of transmitting the second digital data comprises: the product was discharged.

31. The method of claim 23, wherein the step of transmitting the first digital data comprises:

detecting a prerequisite event, the event being receipt of a notification that payment for the license has been guaranteed by the providing process; and

electronic digital data is transferred across the interface and from the port according to a protocol that refuses entry into the state of transmitting the licensed electronic digital data until the event is detected.

32. The method of claim 23, wherein the step of transmitting a portion of the electronic digital data product comprises:

detecting a prerequisite event, the event being at least one of receiving a notification, receiving at least a portion of the license, receiving a key for encrypting the product, and determining a network address for delivering the product; and

electronic digital data is transferred across the interface and from the port according to a protocol that refuses entry into a state of transferring electronic digital data of the electronic digital data product until the event is detected.