US20090063846A1 - Systems and methods for prevention of peer-to-peer file sharing - Google Patents
Systems and methods for prevention of peer-to-peer file sharing Download PDFInfo
- Publication number
- US20090063846A1 US20090063846A1 US12/055,225 US5522508A US2009063846A1 US 20090063846 A1 US20090063846 A1 US 20090063846A1 US 5522508 A US5522508 A US 5522508A US 2009063846 A1 US2009063846 A1 US 2009063846A1
- Authority
- US
- United States
- Prior art keywords
- content
- encryption
- digital content
- eax
- algorithm
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/142—Network analysis or design using statistical or mathematical methods
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/18—Protocol analysers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/02—Capturing of monitoring data
- H04L43/028—Capturing of monitoring data by filtering
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/16—Threshold monitoring
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/03—Protocol definition or specification
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Definitions
- the field of the invention relates to distribution of content over a network or stored on electronic media, and more particularly to systems and methods of protecting content from unauthorized distribution.
- the rightful owners and distributors of digital content have resorted to a variety of technological methods to prevent copying.
- software manufacturers have tried embedding secret codes into the distribution media (e.g. CD-ROMs or floppy disks), in sectors of the distribution media that are not easily accessed by users.
- the software is configured to check for the existence of the secret code, and if the code is not present, the software fails to execute. Since the sectors of the distribution media are not easily accessible, the secret codes are difficult to copy.
- modern copying techniques are able to defeat this scheme by making an exact duplicate of the entire CD-ROM or floppy disk, including the secret codes. Also, this scheme can frustrate end users who wish to make legitimate copies of the software, for example for backup purposes.
- decryption systems however all suffer from a significant drawback. Since the code that is used to implement the decryption routines is installed onto the end user's device, either as a hardware component (such as on a VCR or DVD player) or as a software module (such as on a computer), this code is fairly easily accessible to the end user. Those seeking to defeat the encryption scheme can therefore more easily reverse-engineer the encryption algorithm, and more easily break the encryption system. Furthermore, once the encryption algorithm is broken, then all content encrypted with the algorithm can then be made accessible merely by distributing a single decoder program. Since most content providers only distribute a single encryption algorithm with their various content, once this algorithm is broken, all of the content is unprotected.
- an encryption or decryption algorithm is generated on demand by a content provider.
- an encryption or decryption algorithm is provided on demand to a content user.
- an encryption or decryption algorithm is requested by a content user every time the content user wishes to access the encrypted content.
- an encryption or decryption algorithm code is automatically generated on demand by the content provider, using a protocol description.
- the decrypted content is re-encrypted after being accessed, using a different encryption algorithm than the decrypted content was originally encrypted in.
- encryption and decryption algorithms are represented as programmably configurable protocol descriptions.
- the decryption and encryption algorithms are stored in volatile memory on the end user's device, and are deleted after use.
- computer executable code is automatically generated by using a programmably configurable protocol description to configure a protocol parsing engine.
- FIG. 1 depicts a system for securely distributing digital content, in accordance with an embodiment of the invention.
- FIG. 2 depicts a content provider of an embodiment of the invention.
- FIG. 3 depicts a content user of an embodiment of the invention.
- FIG. 4 depicts a computer within a content provider of an embodiment of the invention.
- FIG. 5 depicts a media reader within a content user of an embodiment of the invention.
- FIG. 6 is a flowchart of a method of operating a content provider to respond to a purchase request from a content user.
- FIG. 7 is a flowchart of a method of operating a content user to purchase content.
- FIG. 8 is a flowchart of a method of operating a content provider to allow encrypted content to be played by a content user.
- FIG. 9 is a flowchart of a method of operating a content user to play encrypted content.
- FIG. 10 is a flowchart of a method of operating a content provider to allow an encrypted content item to be copied by a content user.
- FIG. 11 is a flowchart of an alternate method of operating a content provider to allow an encrypted content item to be copied by a content user.
- FIG. 12 is a flowchart of a method of operating a content user to copy an encrypted content item.
- FIG. 13 is a flowchart of an alternate method of operating a content user to obtain a copy of a content item.
- a system 5 for securely distributing digital content includes a content provider 10 , one or more content users 20 , and a network 30 .
- the content provider 10 may be any provider of digital content who wishes to keep that content secure.
- the content provider 10 may be a record company, a movie distribution company, a computer software company, a video rental company, or the like.
- the content provider 10 may also be a computer or other similar electronic device or collection of devices operated by any of the above enumerated entities.
- the content user 20 may be any user of digital content, including both natural persons and electronic devices, either being operated by natural persons or operating independently.
- the network 30 may be any means of establishing communications between the content provider 10 and the content user 20 , for the purpose of transferring content between the content provider 10 and the content user 20 .
- the network 30 may be a series of linked computers such as the Internet.
- the network 30 may be a direct connection between the content provider 10 and the content user 20 , such as a wired telephone connection or a wireless link.
- the content provider 10 and the content user 20 may both reside on the same computer, and the network 30 may be a data path within that computer between the content provider 10 and the content user 20 .
- the content provider 10 of an embodiment includes a computer 12 , data storage 14 , and a communications link 16 .
- the computer 12 may be any type of computing device that is capable of receiving and processing requests to access digital content.
- the computer 12 may be a personal computer, a network of personal computers, a server in a client/server model, a mainframe computer, etc.
- the data storage 14 may be any form of volatile or non-volatile storage medium that is capable of storing digital data.
- the data storage 14 may be a hard disk, a RAM memory, a RAID array, a WORM drive, an optical disk, a floppy disk, etc.
- the communications link 16 may be any type of communication device that allows digital data to be transferred into and out of the content provider 10 .
- the communications link 16 may be a network interface card such as an Ethernet card installed in the computer 12 , a telephone coupling such as a modem, a wireless radio or cellular telephone coupling, a pager network coupling, a fibre optic channel coupling, etc.
- the content user 20 of an embodiment includes a media reader 22 , a data storage 24 , a communications link 26 , and a content display 28 .
- the media reader 22 may be any device capable of processing and reading digital media.
- the media reader 22 may be a personal computer, an MP3 player, a CD player, a DVD player, etc.
- the data storage 24 may be any form of volatile or non-volatile storage medium that is capable of storing digital data.
- the data storage 24 may be a hard disk, a RAM memory, a RAID array, a WORM drive, an optical disk, a floppy disk, etc.
- the communications link 16 may be any type of communication device that allows digital data to be transferred into and out of the content user 20 .
- the communications link 26 may be a network interface card such as an Ethernet card installed in the media reader 22 , a telephone coupling such as a modem, a wireless radio or cellular telephone coupling, a pager network coupling, a fibre optic channel coupling, etc.
- the content display 28 may be any device capable of receiving digital content and displaying it, either in digital or analog or some other format.
- the content display 28 may be an audio speaker or speaker system, a video monitor, a television set, etc.
- the computer 12 includes several modules. These modules may be implemented in either software, hardware, firmware, or some combination of software, hardware and firmware.
- the modules in the computer 12 include a request processor 40 , billing module 41 , a logging module 42 , an algorithm generator 43 , a key generator 44 , a code generator 45 , an encryption module 46 and a protocol parsing engine 47 .
- the modules of computer 12 may also be distributed among multiple computers 12 , as desired for more efficient operations.
- the request processor 40 receives requests from the content users 20 , manages the flow of data between the other modules of the computer 12 , and causes outgoing messages and content to be sent to the content users 20 .
- the billing module 41 receives billing information from the content users 20 and interfaces with financial services providers such as banks, credit card companies, etc., in order to ensure that content users 20 have made any necessary payments in order to access the digital content being protected by the system 5 .
- the logging module 42 receives logging requests from the request processor 40 , and logs the requests and any other desired information, such as keys or algorithms used to protect content, the status of any request, historical information about the content users 20 , and the like, into the data storage 14 .
- the algorithm generator 43 , key generator 44 , code generator 45 , encryption module 46 and protocol parsing engine 47 work in combination to provide the desired security to protect the digital content being managed by the content provider 10 .
- Many of the elements of and principles behind these modules are discussed in full detail in co-pending U.S. patent application Ser. No. 10/272,471, now U.S. Pat. No. 6,651,102, which reference is hereby incorporated herein by reference, in its entirety. Further elements and principles behind these modules are discussed in full detail in U.S. Pat. No. 6,493,761, U.S. Pat. No. 6,266,700, U.S. Pat. No. 6,000,041, U.S. Pat. No. 5,781,729, and U.S. Pat. No. 5,793,954, all of which are hereby incorporated herein by reference, in their entirety.
- the protocol parsing engine 47 is configured to perform a protocol parsing function, using one or more programmably configurable protocol descriptions.
- the protocol parsing engine 47 may be configured to perform data modifications such as encrypting and decrypting data, as discussed in U.S. Pat. No. 6,651,102.
- the protocol parsing engine 47 may be configured to gather statistics, perform routing functions, or modify text formats, as discussed in the various other US Patent references incorporated by reference.
- the protocol parsing engine 47 uses these programmably configurable protocol descriptions, along with common control logic, to perform the various functions specified by the protocol descriptions. This allows the protocol parsing engine 47 to be re-configured entirely through user input, without the need for hardware or software system modifications.
- system 5 in accordance with an embodiment of the invention may be configured and reconfigured in a highly efficient and cost-effective manner to implement numerous different functions, and to accommodate substantial application or task modifications, such as the use of different types of data processors, different encryption schemes, different encryption algorithms and keys, different key lengths, etc., without requiring substantial system changes.
- the protocol parsing engine 47 retrieves input data from either an input data file or a streaming data source such as a network data transmission stream.
- the input data is typically organized as a series of protocols, such as network transmission protocols.
- the protocol parsing engine 47 then parses this data, according to the programmably configurable protocol description which was used to configure the protocol parsing engine 47 . For example, if the protocol parsing engine 47 is configured with a data modification protocol, then the protocol parsing engine 47 will parse the input data and modify the input data according to the data modification protocol. Thus if the data modification protocol is an encryption protocol, the protocol parsing engine 47 will encrypt the data.
- the protocol parsing engine 47 will decrypt the data. If the protocol parsing engine 47 is configured with a programmably configurable protocol description that includes functions which generate executable code for performing some or all of the configured functions, then the protocol parsing engine 47 will parse the input data using the executable code generated for the protocol parsing engine 47 by the protocol description.
- the algorithm generator 43 generates encryption algorithms, either as a stand-alone process, or with the assistance of an administrator. Examples of the encryption algorithms which may be generated by the algorithm generator 43 are the encryption algorithms discussed in U.S. Pat. No. 6,651,102, for example at FIGS. 5-7. Content providers may already have implemented encryption policies or encryption schemes which specify the general parameters for the encryptions to be applied to their data, such as number of transformations, type of transformations, as well as specific algorithms which the content provider prefers. All of this provider-specific customization may be represented in the algorithms generated by the algorithm generator 43 , merely by modifying the number of or ordering of the steps of the algorithm, or the values used in the steps of the algorithm, as well as by changing the actual types of modifications to be used in the algorithm.
- the algorithm generator 43 may be automated, by, for example, instructing the algorithm generator 43 to select the values used in the steps of the algorithm at random, or to re-order the steps of the algorithm according to some configured policy. These algorithms are then expressed as protocol descriptions, to be provided to the protocol parsing engine 47 .
- the key generator 44 generates keys to be used with the algorithms generated by the algorithm generator 43 . These keys may, for example, be used as described in U.S. Pat. No. 6,651,102, along with the algorithms described in that patent, to encrypt or decrypt data.
- the keys may be generated according to the content provider's key generation policy, which may specify, for example, key lengths or other key requirements such as requiring certain characters in the key, or forbidding certain characters. These keys may be expressed as protocol descriptions, or they may be used by or incorporated into the algorithm generated by the algorithm generator 43 .
- the key generator 44 may be a separate module, or the key generator 44 may be incorporated into the algorithm generator 43 .
- the encryption module 46 takes the algorithm and key generated by the algorithm generator 43 and key generator 44 , and supplies them to the protocol parsing engine 47 , thus configuring the protocol parsing engine 47 to encrypt the input data.
- the encryption module 46 also collects the input data, such as music or video files, from the data storage 14 , and supplies the input data to the protocol parsing engine 47 .
- the code generator 45 takes a the algorithm and key generated by the algorithm generator 43 and key generator 44 , uses the algorithm and key to generate executable code for the parsing process, and supplies the generated code to the protocol parsing engine 47 , or to the communications link 16 , for provision to the security manager 52 on the content user 20 .
- the protocol description for the algorithm and/or key includes, for example, functions that create executable code that when executed will encrypt or decrypt a data file.
- the protocol description specifies a segment of executable code for each of the possible data manipulation operations that can be specified in a data manipulation protocol description, such as the data manipulation protocol descriptions of FIGS. 5-7 of U.S. Pat. No. 6,651,102.
- the protocol parsing engine 47 When the protocol description including the executable code is used to configure the protocol parsing engine 47 , or the security manager 52 , the protocol parsing engine is configured such that, when supplied with a music, video or other content file, it will modify the data in the content file according to the protocol description.
- the protocol description may also include standardized code routines that are desired to be included into all executable code created by the protocol description. Examples of these standardized code routines would be input/output routines, standardized mathematical computation routines, data cleanup routines, etc.
- the media reader 22 includes several modules. These modules may be implemented in either software, hardware, firmware, or some combination of software hardware and firmware.
- the modules in the media reader 22 include a request generator 51 , a security manager 52 , and a media processor 53 .
- the request generator 51 is responsible for making requests to the content provider 10 for access to content.
- the request generator 51 may be implemented in a variety of different manners, depending upon the nature of the media reader 22 .
- the request generator 51 may be a web browser.
- the request generator 51 may be a code routine installed in the firmware of the media player, which responds to a user's activation of a Play button or other such feature of the portable media player.
- the request generator 51 may be activated by a user of the media reader 22 , or the request generator 51 may be activated by other internal processes running on the media reader 22 .
- the request generator 51 sends information to the content provider 10 such as information specifying the identity of the media reader 22 , billing information for any charges that the content provider 10 may require, or information about the particular content requested by the media reader 22 .
- the security manager 52 is responsible for receiving content from the content provider 10 .
- the security manager 52 also manages decrypting encrypted content, and encrypting decrypted content as needed to provide protection to the content from the content provider 10 while allowing the content user 20 to use the content.
- the security manager 52 receives encrypted content from the content provider 10 .
- the security manager 52 also receives executable encryption and decryption modules from the content provider 10 , and executes those modules on decrypted or encrypted content. To further preserve the security of the content provided by the content provider 10 , the security manager 52 deletes the executable encryption and decryption modules once those modules have finished operations. Deleting these modules prevents them from being accessed by malicious users of the media reader 22 .
- the media processor 53 is responsible for processing the decrypted media files created by the security manager 52 , and sending the appropriate signals to the content display 28 , to display the content.
- the media processor may include, for example, a digital/analog converter, as well as any other circuitry useful in playing video or audio signal data.
- the system 5 for securely distributing digital content is used according to various methods, depending on the particular function being performed.
- the functions the system 5 is capable of performing are customer purchases of digital content, customer playing of digital content, and customer copying of digital content. All of these functions are performed while maintaining the security of the digital content from unauthorized copying or playing.
- a method of operating a content provider 10 to respond to a purchase request from a content user 20 is shown in FIG. 6 .
- the method begins at step 610 when the content provider 10 receives a purchase request from the content user 20 .
- the purchase request is received over the communications link 16 , from the network 30 .
- the purchase request is routed from the communications link 16 to the request processor 40 in the computer 12 .
- the request processor 40 routes the request to the billing module 41 to process the content user's payment information.
- the billing module 41 rejects the purchase request and the request processor 40 advises the content user 20 that the purchase request has been rejected.
- the rejected purchase request is also sent to the logging module 42 to record the rejected request in the content provider's logs. This information may be useful if the content provider wishes to investigate the logs for patterns of potentially fraudulent conduct, or for other reasons the content provider 10 wishes to learn about the history of requests made to the content provider 10 .
- the request processor 40 routes the purchase request onward through the modules of the computer 12 at the content provider 10 .
- the algorithm generator 43 generates a new encryption algorithm.
- this encryption algorithm may be based upon any security policies or schemes the content provider 10 desires to use, depending on the level of security the content provider 10 wishes to implement.
- every new purchase request triggers the creation of a new encryption algorithm to be assigned to the specific content being purchased.
- the content provider 10 may develop a pool of encryption algorithms and select one or more algorithms from this pool for use with the newly purchased content. This alternative solution trades off some loss in security for a simpler operation of the system.
- the corresponding decryption algorithm may also be generated at this time, if necessary.
- the decryption algorithm is easily derived from the encryption algorithm, for example by running the steps of the encryption algorithm in reverse order. For some algorithms, running the steps of the encryption algorithm again, on encrypted content, results in decryption of the content.
- a key for the generated algorithm is created by the key generator 44 .
- the key generator 44 may be a separate module from the algorithm generator 43 , or it may be incorporated into the algorithm generator 43 .
- every new purchase request triggers the creation of a new encryption key to be assigned to the specific content being purchased.
- content provider 10 may develop a pool of keys and select one or more keys from this pool for use with the newly purchased content.
- an encryption algorithm may be re-used by multiple purchasers of content, with each purchaser being assigned a different key.
- Either or both of the encryption algorithm and the key may be selected, at least in part, based on information provided by the content user 20 .
- the customer's name, address, credit card number, or a user-selected ID number may be used to partially or fully select the algorithm and key to be used.
- an algorithm and key may be selected without using any information from the content user 20 , and instead the algorithm and key are selected using some internal policies, or random selection.
- the logging module 42 stores an encryption ID in the data storage 14 at the content provider 10 .
- the encryption ID may comprise the actual algorithm and key themselves, or the encryption ID may comprise some other information sufficient to identify which specific algorithm and key was generated for the newly purchased content. For example, if the algorithm and key are randomly generated, then the encryption ID may be the randomly generated number that was used to select the algorithm and key.
- the request processor 40 retrieves the newly purchased content from the data storage 14 , or from any other data storage where the newly purchased content may be stored, and hands the content off to the encryption module 46 .
- the encryption module 46 provides the encryption algorithm and encryption key generated above for the newly purchased content to the protocol parsing engine 47 , thereby configuring the protocol parsing engine 47 to encrypt input data according to the encryption algorithm and encryption key provided.
- the code generator 45 generates executable code for any functions specified in the protocol descriptions for the algorithm and key generated above as having executable code for them. The encryption module 46 then provides to the protocol parsing engine 47 these executable code modules, to streamline the encryption process.
- the newly purchased content is provided to the protocol parsing engine 47 as input data, and the newly purchased content is thereby encrypted.
- the encrypted content is then sent to the content user 20 , along with an identifier identifying the encrypted content.
- This identifier may be the encryption ID discussed above, if that encryption ID cannot be reverse-engineered or otherwise inspected to extract the encryption algorithm or key. Alternatively the identifier may be some other sequence of data that identifies the specific copy of the content being sent to the content user 20 .
- This identifier is also stored in the data storage 14 by the logging module 42 , at step 675 .
- the encryption algorithm and key are both generated on the fly and provided to the configurable protocol parsing engine 47 , those skilled in the art will appreciate that the algorithm, the key, and the key length can all be changed each and every time that a content user 20 purchases new content. This allows each copy of each content item sold by the content provider 10 to be encrypted not only with a unique key, but with a unique encryption algorithm, including algorithms with different key lengths.
- a method of operating a content user 20 to purchase content is shown in FIG. 7 .
- the method begins at step 710 , where the request generator 51 at the content user 20 generates a request to purchase content.
- the request generator 51 is a web browser
- the content user 20 enters information such as the title, author, or publisher of desired content.
- the content user 20 may conduct other activities such as searches for desired content, or reading reviews of content, in addition to requesting the content.
- the content user 20 locates the desired content and is ready to purchase it, then at step 720 the content user 20 provides billing information, such as a credit card number, to the request generator 51 .
- the request generator 51 then forwards all of this information on to the content provider 10 , via the communications link 26 and on to the network 30 .
- the content user 20 receives the purchased content, in encrypted form as discussed above, from the content provider 10 .
- the encrypted content is stored in the data storage 24 , at step 740 , where it is made available for future requests to play or copy the content, as will be discussed in detail below.
- FIG. 8 A method of operating a content provider 10 to allow encrypted content to be played by a content user 20 is shown in FIG. 8 .
- the method begins at step 810 when the content provider 10 receives a request to play encrypted content from a content user 20 , via the network 30 and communications link 16 .
- the request processor 40 receives the play request, and validates the request at step 820 .
- the request is validated by, for example, comparing an identifier provided by the content user 20 with the corresponding identifier created when the encrypted content was initially purchased by the content user 20 . This corresponding identifier is stored at the content provider 10 , as discussed at step 675 of FIG. 6 .
- a billing procedure similar to that discussed at steps 620 - 625 of FIG. 6 is followed as part of the validation step. If the content provider 10 cannot validate the play request, then at step 830 , the play request is rejected, and the rejection is conveyed back to the content user 20 . At step 840 , the rejected request is sent to the logging module 42 , for logging in the data storage 14 . This allows the content provider 10 to keep track of the history of play requests, should the content provider 10 wish to investigate possible fraud attempts or other such issues.
- the play request is sent to the logging module 42 for logging in the data storage 14 .
- the logging module 42 looks up the encryption ID for the encrypted content that is the subject of the play request, in the data storage 14 .
- the encryption ID is used, at step 865 , to retrieve the corresponding decryption algorithm and key for the encrypted content, to allow the encrypted content to be decrypted.
- the algorithm and key may be retrieved in a variety of ways. For example, if the encryption ID itself contains the decryption algorithm and key, then the algorithm and key are retrieved from the encryption ID itself.
- the encryption ID is used to locate the decryption algorithm and key stored in the data storage 14 .
- the encryption ID is a seed value for a random selection routine that can be used to generate the decryption algorithm and key
- the decryption algorithm and key are retrieved by providing the encryption ID as a seed to the random selection routine, which results in the decryption algorithm and key being re-generated on demand.
- the same seed value will generate both an encryption algorithm and key, as well as the corresponding decryption algorithm and key.
- the re-generated decryption algorithm and key will be identical to the previously created decryption algorithm and key.
- This alternative embodiment realizes a savings in storage space needed to store all of the algorithms and keys, at the possible tradeoff of increased response time to regenerate algorithms and keys. Note, however, that as the library of generated algorithms and keys becomes larger, regenerating algorithms and keys may eventually be faster than searching for them in the library of generated algorithms and keys.
- the decryption algorithm and key are passed on to the code generator 45 .
- the code generator 45 uses the decryption algorithm and key to generate an executable code module to allow the security manager 52 on the content user 20 to decrypt the encrypted digital content. Details of the code generation process are discussed below.
- the code generator 45 can generate code specific to the architecture of the particular media reader 22 at the content user 20 , if the play request (or the prior purchase request) contained information sufficient to identify the architecture. For example, if the play or purchase request indicates that the media reader 22 is a Windows/DOS personal computer, then the code generator 45 generates an executable code module for the Windows/DOS architecture.
- the code generator 45 If the play/purchase request indicates that the media reader 22 is an Apple Macintosh personal computer, then the code generator 45 generates an executable code module for the Macintosh architecture. Similarly, if the play/purchase request indicates that the media reader 22 is an iPod device, or a CD player, or an MP3 player, the code generator 45 generates the appropriate executable code module.
- the executable code module is only capable of decrypting content that uses the exact decryption algorithm and key provided to the code generator 45 . Therefore the executable code module cannot be used by malicious content users 20 as a universal decoder, as long as the content provider 10 has encrypted its content using a variety of different algorithms, as discussed above. In embodiments where every content item sent out from the content provider 10 is encrypted with a different algorithm and key, the executable code module can only be used on the specific content item for which it is intended. Once the executable code module is created by the code generator 45 , then at step 880 the executable code module is sent to the content user 20 , via the communications link 16 and network 30 .
- a method of operating a content user 20 to play encrypted content is shown in FIG. 9 .
- the method begins at step 910 , where the request generator 51 at the content user 20 generates a request to play content stored in encrypted form on the content user 20 .
- the request generator 51 is a web browser
- the content user 20 enters information such as the identifier associated with the encrypted content, which was previously provided to the content user 20 when the content user 20 purchased the content item. If there is a charge associated with playing the content item, then at step 915 the content user 20 provides billing information, such as a credit card number, to the request generator 51 .
- the request generator 51 then forwards all of this information on to the content provider 10 , via the communications link 26 and on to the network 30 .
- the content user 20 receives a response back from the content provider 10 .
- the request is either denied, if the content provider 10 was unable to validate the request (or process payment if any was required), or the request is accepted and an executable decryption code module is returned to the content user 20 .
- the module is provided to the security manager 52 , at step 930 .
- the executable decryption code module is stored in volatile memory on the media reader 22 at the content user 20 .
- Limiting the executable decryption code module to volatile storage helps enhance the security of the system 5 , since it is much more difficult for malicious content users 20 to obtain a copy of the executable decryption code module, to possibly inspect or reverse-engineer.
- the security manager 52 then retrieves the encrypted content item from the data storage 24 , or other location where the encrypted content item is stored. Finally, the security manager 52 uses the encrypted content item as input data to the executable decryption code module, and creates a decrypted version of the content item. This decrypted version of the content item is also preferably stored in volatile storage, to minimize the potential for malicious content users 20 to obtain a copy of the decrypted content item. If the content item is too large to be easily stored in volatile memory, then the content item can be decrypted in pieces, each piece being stored in volatile memory until the piece is processed, and then the piece is deleted and replaced with a successive piece of the decrypted content item.
- the security manager 52 decrypts, or begins decrypting, the content item to be played, at step 940 the decrypted portion of the content item is provided to the media processor 53 for processing.
- the media processor 53 processes the decrypted content item and routes the output to the content display 28 at step 950 , where the content is enjoyed by the content user 20 or others.
- the decrypted content item or portion thereof is deleted from the media reader 22 , thereby preserving security of the content item and maintaining the integrity of the system 5 .
- FIG. 10 A method of operating a content provider 10 to allow an encrypted content item to be copied by a content user 20 is shown in FIG. 10 .
- the method begins at step 1010 when the content provider 10 receives a request to copy encrypted content from a content user 20 , via the network 30 and communications link 16 .
- the request processor 40 receives the copy request, and validates the request at step 1020 .
- the request is validated by, for example, comparing an identifier provided by the content user 20 with the corresponding identifier created when the encrypted content was initially purchased by the content user 20 . This corresponding identifier is stored at the content provider 10 , as discussed at step 675 of FIG. 6 .
- a billing procedure similar to that discussed at steps 620 - 625 of FIG. 6 is followed as part of the validation step. If the content provider 10 cannot validate the copy request, then at step 1030 , the copy request is rejected, and the rejection is conveyed back to the content user 20 . At step 1040 , the rejected request is sent to the logging module 42 , for logging in the data storage 14 . This allows the content provider 10 to keep track of the history of copy requests, should the content provider 10 wish to investigate possible fraud attempts or other such issues.
- the copy request is sent to the logging module 42 for logging in the data storage 14 .
- the logging module 42 looks up the encryption ID for the encrypted content that is the subject of the copy request, in the data storage 14 .
- the encryption ID is used, at step 1065 , to retrieve the corresponding decryption algorithm and key for the encrypted content, to allow the encrypted content to be decrypted.
- the algorithm and key may be retrieved in a variety of ways, as discussed above for retrieving algorithms and keys for play requests.
- the algorithm generator 43 In response to the validated copy request, the algorithm generator 43 generates a new encryption algorithm to be used to encrypt the copy, once it is made. The algorithm generator 43 performs this step in a manner similar to generating new encryption algorithms for newly purchased content, as discussed for step 630 of FIG. 6 .
- a key for the generated algorithm is created by the key generator 44 .
- the key generation step proceeds similarly to that at step 635 of FIG. 6 above.
- the logging module 42 stores a new encryption ID in the data storage 14 at the content provider 10 for the new copy. This step is performed in a manner similar to step 640 of FIG. 6 above.
- the decryption algorithm and key are passed on to the code generator 45 .
- the code generator 45 generates an executable code module to configure the security manager 52 at the content user 20 to decrypt the encrypted content item to be copied. This process is performed in a manner similar to step 870 of FIG. 8 above.
- the code generator 45 then generates an executable code module to configure the security manager 52 at the content user 20 to encrypt the new copy of the content item that is about to be created. This process is performed in a manner similar to step 870 of FIG.
- the executable encryption code module will encrypt rather than decrypt the content item provided as input.
- FIG. 11 An alternative method of operating a content provider 10 to allow an encrypted content item to be copied by a content user 20 is shown in FIG. 11 .
- This method performs the copying and encryption steps at the content provider 10 instead of at the content user 20 .
- Security is thereby enhanced, at a tradeoff of increased network bandwidth usage, increased demand on the computer 12 at the content provider 10 , and increased storage requirements for the data storage 14 , since it must store a master copy of all content ever sold, not just a current catalog of content for sale.
- the method begins at step 1110 when the content provider 10 receives a request to copy encrypted content from a content user 20 , via the network 30 and communications link 16 .
- the request processor 40 receives the copy request, and validates the request at step 1120 .
- the request is validated by, for example, comparing an identifier provided by the content user 20 with the corresponding identifier created when the encrypted content was initially purchased by the content user 20 .
- This corresponding identifier is stored at the content provider 10 , as discussed at step 675 of FIG. 6 . If there is a charge for copying previously purchased content, then a billing procedure similar to that discussed at steps 620 - 625 of FIG. 6 is followed as part of the validation step.
- the copy request is rejected, and the rejection is conveyed back to the content user 20 .
- the rejected request is sent to the logging module 42 , for logging in the data storage 14 . This allows the content provider 10 to keep track of the history of copy requests, should the content provider 10 wish to investigate possible fraud attempts or other such issues.
- the copy request is sent to the logging module 42 for logging in the data storage 14 .
- the algorithm generator 43 in response to the validated copy request, the algorithm generator 43 generates a new encryption algorithm to be used to encrypt the copy, once it is made.
- the algorithm generator 43 performs this step in a manner similar to generating new encryption algorithms for newly purchased content, as discussed for step 630 of FIG. 6 .
- a key for the generated algorithm is created by the key generator 44 .
- the key generation step proceeds similarly to that at step 635 of FIG. 6 above.
- the logging module 42 stores a new encryption ID in the data storage 14 at the content provider 10 for the new copy. This step is performed in a manner similar to step 640 of FIG. 6 above.
- the request processor 40 retrieves the content to be copied from the data storage 14 , or from any other data storage where the content to be copied may be stored, and hands the content off to the encryption module 46 .
- the encryption module 46 provides the encryption algorithm and encryption key generated above for the content to be copied to the protocol parsing engine 47 , thereby configuring the protocol parsing engine 47 to encrypt input data according to the encryption algorithm and encryption key provided.
- the code generator 45 generates executable code for any functions specified in the protocol descriptions for the algorithm and key generated above as having executable code for them. The encryption module 46 then provides to the protocol parsing engine 47 these executable code modules, to streamline the encryption process.
- the content to be copied is provided to the protocol parsing engine 47 as input data, and the content to be copied is thereby encrypted.
- the encrypted content is sent to the content user 20 , along with an identifier identifying the encrypted content.
- This identifier may be the encryption ID discussed above, if that encryption ID cannot be reverse-engineered or otherwise inspected to extract the encryption algorithm or key. Alternatively the identifier may be some other sequence of data that identifies the specific copy of the content being sent to the content user 20 .
- This identifier is also stored in the data storage 14 by the logging module 42 , at step 1197 .
- the encryption algorithm and key are both generated on the fly and provided to the configurable protocol parsing engine 47 , those skilled in the art will appreciate that the algorithm, the key, and the key length can all be changed each and every time that a content user 20 makes a copy of content. This allows each copy of each content item sold by the content provider 10 to be encrypted not only with a unique key, but with a unique encryption algorithm, including algorithms with different key lengths.
- a method of operating a content user 20 to copy an encrypted content item 20 is shown in FIG. 12 .
- the method begins at step 1210 , where the request generator 51 at the content user 20 generates a request to copy content stored in encrypted form on the content user 20 .
- the request generator 51 is a web browser
- the content user 20 enters information such as the identifier associated with the encrypted content, which was previously provided to the content user 20 when the content user 20 purchased the content item. If there is a charge associated with copying the content item, then at step 1215 the content user 20 provides billing information, such as a credit card number, to the request generator 51 .
- the request generator 51 then forwards all of this information on to the content provider 10 , via the communications link 26 and on to the network 30 .
- the content user 20 receives a response back from the content provider 10 .
- the request is either denied, if the content provider 10 was unable to validate the request (or process payment if any was required), or the request is accepted and an executable decryption code module and executable encryption code module are returned to the content user 20 .
- the modules are provided to the security manager 52 , at step 1230 .
- the executable decryption and encryption code modules are stored in volatile memory on the media reader 22 at the content user 20 .
- the security manager 52 then retrieves the encrypted content item from the data storage 24 , or other location where the encrypted content item is stored. The security manager 52 uses the encrypted content item as input data to the executable decryption code module, and creates a decrypted version of the content item. This decrypted version of the content item is also preferably stored in volatile storage, to minimize the potential for malicious content users 20 to obtain a copy of the decrypted content item. If the content item is too large to be easily stored in volatile memory, then the content item can be decrypted in pieces, each piece being stored in volatile memory until the piece is processed, and then the piece is deleted and replaced with a successive piece of the decrypted content item.
- the decrypted content item is copied by the media processor 53 , at step 1240 .
- the decrypted copy is also preferably stored in volatile memory, such as the RAM of the media reader 22 , as discussed above.
- the decrypted copy is then provided as input to the executable encryption code module, at step 1250 . This results in a newly encrypted copy of the content item being created, using the new algorithm and key contained in the executable encryption code module. Thus the original and the copy both remain on the content user 22 , but they are both encrypted, using different algorithms and keys.
- the encrypted copy may now be freely distributed to another content user 20 , or burned into a CD-ROM or DVD media disk, or the like, without fear that the content user 20 will be able to create further unencrypted copies.
- the second content user 20 may still play the copy of the content, by making his own play request to the content provider 10 .
- the executable encryption and decryption code modules and the decrypted content are all deleted from the memory they were stored in.
- FIG. 13 An alternative method of operating a content user 20 to obtain a copy of a content item is shown in FIG. 13 .
- This method performs the copying and encryption steps at the content provider 10 instead of at the content user 20 .
- Security is thereby enhanced, and processing resources at the content user 20 are conserved, at a tradeoff of increased network bandwidth usage, increased demand on the computer 12 at the content provider 10 , and increased storage requirements for the data storage 14 , since it must store a master copy of all content ever sold, not just a current catalog of content for sale.
- the method is treated identically to a purchase of new content, except that an identifier is sent to the content provider 10 to establish that the content user 20 is already in possession of a copy of the content item.
- This information may be used by the content provider to, for example, make billing decisions (i.e. billing a content user 20 at a lower rate, or dispensing with billing entirely, for copies of content that the content user 20 already owns).
- the method begins at step 1310 , where the request generator 51 at the content user 20 generates a request to copy an identified content item.
- the content user 20 provides billing information if required by the content provider 10 .
- the request generator 51 then forwards all of this information on to the content provider 10 .
- the content user 20 receives the copied content, in encrypted form as discussed above, from the content provider 10 .
- the encrypted content is stored in the data storage 24 , at step 740 , where it is made available for future requests to play or copy the content.
- this alternate embodiment combines a copy request with every play request, creating true one-use copies of content items.
- the x86 processor provides 8 32-bit general-purpose registers: EAX, EBX, ECX, EDX, EBP, ESP, ESI, and EDI.
- the low 16 bits of the 32-bit general-purpose registers can be referenced independently as AX, BX, CX, DX, BP, SP, SI, AND DI.
- Each byte of the first four 16 bit registers can be referenced independently as AH, BH, CH, DH for the high bytes, and AL, BL, CL, DL for the low bytes.
- Code can be optimized and memory accesses performed by the processor can be minimized by making assumptions and pre-assigning both meanings and values to registers that will apply to all generated code. The following discussions assume that:
- the code in Table 1 is an example of code used by the code generation routines below, to send the actual lines of generated code to an output buffer, which may be a data file or may be some other output processing routine.
- the routine in Table 2 below generates optimized code for extracting values for user defined protocol fields.
- the routine uses data from a protocol record to select which of the code templates included in the routine to send to the output buffer.
- the code templates are combined with data from the protocol record to generate customized code. Only the portion of the code that generates extraction code for fields that are aligned on an 8-bit boundary in memory is shown. The code for extracting values for fields that are not aligned has been removed because it is not used in any of the included examples.
- the code in Table 3 below uses the code from Table 2 to generate the code in Table 4 below, showing all 36 possible values with a length that is a multiple of 8 bits and is aligned on an 8-bit boundary in memory within a 64 bit field.
- the code in Table 3 creates a series of fields containing field values, via the nested loops (fshr, fshl). The field values are used as input to the code in Table 2, to generate the output of Table 4.
- the generated code is presented in Table 4 below.
- the field value extraction code shown below is code that, when executed on input data, will pull out a field value from within that input data, according to the field length and field location within the data as specified by the generated code.
- the comments in the code in Table 4 uses the following nomenclature for the 36 generated code examples:
- the above code comment will extract an 8-bit value, located at bits 11-15, from a 64-bit field.
- [esi+4294967295] is equivalent to [esi ⁇ 1] in the generated code samples of Table 4.
- the bswap instruction changes the order of bytes in a 32 bit word (4 bytes) from 4321 to 1234 in the referenced register and is an instruction provided by the x86 architecture.
- byte order that data is transmitted on most networks is backwards from the order that the x86 architecture stores it in memory. This makes the bswap instruction necessary in instances where the byte order is important, such as when a filter criteria specifies a range of values. In the case of a filter criteria that only specifies a single value, the comparison value can be swapped as the code is generated to eliminate the bswap instruction.
- the class definition in Table 6 is derived from the stats class defined in U.S. Pat. No. 5,793,954, which is incorporated by reference herein. This class definition uses the code routine in Table 5 above. Only the portions required to illustrate the code generation examples are included.
- the following tables present the code generation routines, sample input data for the code generation routines, and resulting generated code output, used to generate code for a data filtering function.
- This data filtering function is a further example of the sort of functions that code can be generated for, according to an embodiment of the invention.
- Data filtering is one of the functions frequently performed by protocol analyzers, such as the configurable protocol analyzers discussed in the incorporated US Patent references mentioned above.
- protocol analyzers such as the configurable protocol analyzers discussed in the incorporated US Patent references mentioned above.
- Those skilled in the art will appreciate that all of the functions of a protocol analyzer may be implemented in code generation routines of an embodiment of the invention.
- an entire protocol analyzer specially configured to suit a particular design, may be created by applying a user-configured protocol as an input to a protocol parsing engine that has been configured with a protocol or protocols as discussed herein.
- OutputCompareMinV(CurrProt->pname( ), CurrField->name( ), “ &&”, CriteriaIdx, RangeIdx, Size, minvalue); OutText(“ jb Chan%uCrit%uRange%u”, ChannelIdx, CriteriaIdx, (protocol *)(RangeIdx+1)); ⁇ if (CurrRange->nxtidx ! (CriteriaIdx+1)) ⁇ OutputCompareMaxV(CurrProt->pname( ), CurrField->name( ), “
- the length of the IP_V4 protocol header is variable (20 bytes are always there and up to 40 bytes of options may be added in 4 byte increments). This means that there are 11 possible header sizes (20, 24, 28, . . . 60).
- the generated code automatically accounts for this possibility by extracting the actual header length from the header contained in the input data, and adding it to all subsequent filtering checks. To do this filtering the more traditional way with content addressable memory (CAM) would require the user to enter all eleven possibilities into the CAMs.
- CAM content addressable memory
- the code generation routines discussed above can be altered to issue commands to automatically program the CAMs with the required values and masks after the filter has been configured by specifying protocols, fields, and (un)acceptable ranges (criteria) of values. This is intuitively more obvious and easier for a typical user to use.
- the code generated by applying the input data of Tables 12 and 13 to the code generation routines of Table 11 are shown below in Tables 14-16.
- routines to generate code for every function performed by the protocol description it would possible to generate code that could first filter network frames, then parse frames containing any pre-configured protocols and fields while also generating code for gathering statistics, verifying checksums and CRCs, varying field values/recomputing checksums and CRCs, and performing routing (route table lookups). Also, by adding additional code generation support routines it would be possible to create a system/application that could generate code that implements an entire protocol or even an entire switch and/or router, all from user configured protocols, fields, filters, lookups, varies, checksums, CRCs, statistics, and route tables.
- switches/routers have two paths through the hardware/software.
- a system/application that could generate code to implement the “fast path” code can be produced. This would allow the switch/router owner to configure/tailor(reprogram) the “fast path” protocols and features supported, in the field.
Abstract
A secure digital content delivery system includes a content provider and a content user. The content provider delivers encrypted content to the content user in response to delivery requests. The content provider generates encryption algorithms on the fly and encrypts the content prior to delivery, using a different encryption algorithm and key for each content delivery. The content user subsequently requests access permission from the content provider, to access the encrypted content. The content provider grants access by generating an executable decryption module on the fly and providing the executable decryption module to the content user. The content user decrypts the content and accesses it on the fly, using the executable decryption module. The accessed content is then re-encrypted using a different encryption algorithm and key, to preserve the integrity of the secure content delivery system. The content delivery system uses a programmably configurable protocol parsing engine to encrypt and decrypt content.
Description
- This is a continuation-in-part of application U.S. Ser. No. 10/272,471, filed on Oct. 15, 2002, which issued as U.S. Pat. No. 6,651,102 on Nov. 18, 2003, which is a continuation-in-part of application U.S. Ser. No. 09/898,852, filed on Jul. 3, 2001, which issued as U.S. Pat. No. 6,493,761 on Dec. 10, 2002, which is a continuation-in-part of application U.S. Ser. No. 09/113,704, filed on Jul. 10, 1998, which issued as U.S. Pat. No. 6,266,700 on Jul. 24, 2001, which is a continuation of U.S. Ser. No. 09/080,325, filed on May 15, 1998, which issued as U.S. Pat. No. 6,000,041 on Dec. 7, 1999, which is a continuation of U.S. Ser. No. 08/888,875, filed on Jul. 7, 1997, which issued as U.S. Pat. No. 5,781,729 on Jul. 14, 1998, which is a continuation of U.S. Ser. No. 08/575,506, filed on Dec. 20, 1995, which issued as U.S. Pat. No. 5,793,954 on Aug. 11, 1998, the disclosures of which are expressly incorporated herein by reference.
- A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the xerographic reproduction by anyone of the patent document or the patent disclosure in exactly the form it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
- The field of the invention relates to distribution of content over a network or stored on electronic media, and more particularly to systems and methods of protecting content from unauthorized distribution.
- With the burgeoning growth of the Internet, there is an ever-increasing amount of content being distributed over the Internet. As technology progresses, consumers are demanding that more content be made available in digital form, to take advantage of the improved sound and visual quality provided by digital recordings. Digital content such as music, movies, software, and the like are rapidly becoming the most popular types of files being transmitted across the Internet.
- Unfortunately, much of this digital content transmission is being done without the authorization of the rightful owners of the content. Since modern computer technology allows digital content to be easily and cheaply copied, with no loss in the quality of the original recording, it has become very easy to create perfect copies of digital content. Now that any personal computer, for example, can make a perfect copy of digital content, it has become very easy for people to make unauthorized copies of digital content, potentially costing the legitimate owners of the digital content millions or even billions of dollars of lost revenue.
- In response to all of this unauthorized copying, the rightful owners and distributors of digital content have resorted to a variety of technological methods to prevent copying. For example, software manufacturers have tried embedding secret codes into the distribution media (e.g. CD-ROMs or floppy disks), in sectors of the distribution media that are not easily accessed by users. The software is configured to check for the existence of the secret code, and if the code is not present, the software fails to execute. Since the sectors of the distribution media are not easily accessible, the secret codes are difficult to copy. However, modern copying techniques are able to defeat this scheme by making an exact duplicate of the entire CD-ROM or floppy disk, including the secret codes. Also, this scheme can frustrate end users who wish to make legitimate copies of the software, for example for backup purposes.
- Various forms of encryption have also been tried, wherein the digital content is stored in an encrypted format, with a variety of hardware or software systems being installed on the end-user's equipment, to decrypt and play the content. For example, manufacturers have tried to install decryption chips into consumer electronics such as videocassette recorders/players, CD players, DVD players, etc. Alternatively, on computerized content playback systems, the decryption routines are provided as computer software, for example in a .DLL or other code file installed on the playback system when the system is manufactured. This code file is accessed by the computer application that is seeking to decrypt the encrypted content, and once the content is decrypted, it is then played, or copied.
- These decryption systems, however all suffer from a significant drawback. Since the code that is used to implement the decryption routines is installed onto the end user's device, either as a hardware component (such as on a VCR or DVD player) or as a software module (such as on a computer), this code is fairly easily accessible to the end user. Those seeking to defeat the encryption scheme can therefore more easily reverse-engineer the encryption algorithm, and more easily break the encryption system. Furthermore, once the encryption algorithm is broken, then all content encrypted with the algorithm can then be made accessible merely by distributing a single decoder program. Since most content providers only distribute a single encryption algorithm with their various content, once this algorithm is broken, all of the content is unprotected. Since the decryption routines are installed on the end user's device, the routines are difficult to change, should the content provider wish to implement a different encryption/decryption algorithm. Thus, there is a need for an improved system of preventing unauthorized copying of digital content, while still facilitating legitimate use and copying of the digital content.
- In an aspect of an embodiment of the invention, an encryption or decryption algorithm is generated on demand by a content provider.
- In another aspect of an embodiment of the invention, an encryption or decryption algorithm is provided on demand to a content user.
- In another aspect of an embodiment of the invention, an encryption or decryption algorithm is requested by a content user every time the content user wishes to access the encrypted content.
- In another aspect of an embodiment of the invention, an encryption or decryption algorithm code is automatically generated on demand by the content provider, using a protocol description.
- In another aspect of an embodiment of the invention, the decrypted content is re-encrypted after being accessed, using a different encryption algorithm than the decrypted content was originally encrypted in.
- In another aspect of an embodiment of the invention, encryption and decryption algorithms are represented as programmably configurable protocol descriptions.
- In another aspect of an embodiment of the invention, the decryption and encryption algorithms are stored in volatile memory on the end user's device, and are deleted after use.
- In another aspect of an embodiment of the invention, computer executable code is automatically generated by using a programmably configurable protocol description to configure a protocol parsing engine.
- In order to better appreciate how the above-recited and other advantages and objects of the present inventions are obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof, which are illustrated in the accompanying drawings. It should be noted that the components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like reference numerals designate corresponding parts throughout the different views. However, like parts do not always have like reference numerals. Moreover, all illustrations are intended to convey concepts, where relative sizes, shapes and other detailed attributes may be illustrated schematically rather than literally or precisely.
-
FIG. 1 depicts a system for securely distributing digital content, in accordance with an embodiment of the invention. -
FIG. 2 depicts a content provider of an embodiment of the invention. -
FIG. 3 depicts a content user of an embodiment of the invention. -
FIG. 4 depicts a computer within a content provider of an embodiment of the invention. -
FIG. 5 depicts a media reader within a content user of an embodiment of the invention. -
FIG. 6 is a flowchart of a method of operating a content provider to respond to a purchase request from a content user. -
FIG. 7 is a flowchart of a method of operating a content user to purchase content. -
FIG. 8 is a flowchart of a method of operating a content provider to allow encrypted content to be played by a content user. -
FIG. 9 is a flowchart of a method of operating a content user to play encrypted content. -
FIG. 10 is a flowchart of a method of operating a content provider to allow an encrypted content item to be copied by a content user. -
FIG. 11 is a flowchart of an alternate method of operating a content provider to allow an encrypted content item to be copied by a content user. -
FIG. 12 is a flowchart of a method of operating a content user to copy an encrypted content item. -
FIG. 13 is a flowchart of an alternate method of operating a content user to obtain a copy of a content item. - Turning to
FIG. 1 , in accordance with an embodiment, a system 5 for securely distributing digital content includes acontent provider 10, one or morecontent users 20, and anetwork 30. Thecontent provider 10 may be any provider of digital content who wishes to keep that content secure. For example, thecontent provider 10 may be a record company, a movie distribution company, a computer software company, a video rental company, or the like. Thecontent provider 10 may also be a computer or other similar electronic device or collection of devices operated by any of the above enumerated entities. Thecontent user 20 may be any user of digital content, including both natural persons and electronic devices, either being operated by natural persons or operating independently. Thenetwork 30 may be any means of establishing communications between thecontent provider 10 and thecontent user 20, for the purpose of transferring content between thecontent provider 10 and thecontent user 20. For example, thenetwork 30 may be a series of linked computers such as the Internet. Alternatively, thenetwork 30 may be a direct connection between thecontent provider 10 and thecontent user 20, such as a wired telephone connection or a wireless link. Alternatively, thecontent provider 10 and thecontent user 20 may both reside on the same computer, and thenetwork 30 may be a data path within that computer between thecontent provider 10 and thecontent user 20. - Turning to
FIG. 2 , thecontent provider 10 of an embodiment includes acomputer 12,data storage 14, and acommunications link 16. Thecomputer 12 may be any type of computing device that is capable of receiving and processing requests to access digital content. For example, thecomputer 12 may be a personal computer, a network of personal computers, a server in a client/server model, a mainframe computer, etc. Thedata storage 14 may be any form of volatile or non-volatile storage medium that is capable of storing digital data. For example, thedata storage 14 may be a hard disk, a RAM memory, a RAID array, a WORM drive, an optical disk, a floppy disk, etc. The communications link 16 may be any type of communication device that allows digital data to be transferred into and out of thecontent provider 10. For example, the communications link 16 may be a network interface card such as an Ethernet card installed in thecomputer 12, a telephone coupling such as a modem, a wireless radio or cellular telephone coupling, a pager network coupling, a fibre optic channel coupling, etc. - Turning to
FIG. 3 , thecontent user 20 of an embodiment includes amedia reader 22, adata storage 24, acommunications link 26, and acontent display 28. Themedia reader 22 may be any device capable of processing and reading digital media. For example, themedia reader 22 may be a personal computer, an MP3 player, a CD player, a DVD player, etc. Thedata storage 24 may be any form of volatile or non-volatile storage medium that is capable of storing digital data. For example, thedata storage 24 may be a hard disk, a RAM memory, a RAID array, a WORM drive, an optical disk, a floppy disk, etc. The communications link 16 may be any type of communication device that allows digital data to be transferred into and out of thecontent user 20. For example, the communications link 26 may be a network interface card such as an Ethernet card installed in themedia reader 22, a telephone coupling such as a modem, a wireless radio or cellular telephone coupling, a pager network coupling, a fibre optic channel coupling, etc. Thecontent display 28 may be any device capable of receiving digital content and displaying it, either in digital or analog or some other format. For example, thecontent display 28 may be an audio speaker or speaker system, a video monitor, a television set, etc. - Turning to
FIG. 4 , thecomputer 12 includes several modules. These modules may be implemented in either software, hardware, firmware, or some combination of software, hardware and firmware. The modules in thecomputer 12 include arequest processor 40,billing module 41, alogging module 42, analgorithm generator 43, akey generator 44, acode generator 45, anencryption module 46 and aprotocol parsing engine 47. The modules ofcomputer 12 may also be distributed amongmultiple computers 12, as desired for more efficient operations. - The
request processor 40 receives requests from thecontent users 20, manages the flow of data between the other modules of thecomputer 12, and causes outgoing messages and content to be sent to thecontent users 20. Thebilling module 41 receives billing information from thecontent users 20 and interfaces with financial services providers such as banks, credit card companies, etc., in order to ensure thatcontent users 20 have made any necessary payments in order to access the digital content being protected by the system 5. Thelogging module 42 receives logging requests from therequest processor 40, and logs the requests and any other desired information, such as keys or algorithms used to protect content, the status of any request, historical information about thecontent users 20, and the like, into thedata storage 14. - The
algorithm generator 43,key generator 44,code generator 45,encryption module 46 andprotocol parsing engine 47 work in combination to provide the desired security to protect the digital content being managed by thecontent provider 10. Many of the elements of and principles behind these modules are discussed in full detail in co-pending U.S. patent application Ser. No. 10/272,471, now U.S. Pat. No. 6,651,102, which reference is hereby incorporated herein by reference, in its entirety. Further elements and principles behind these modules are discussed in full detail in U.S. Pat. No. 6,493,761, U.S. Pat. No. 6,266,700, U.S. Pat. No. 6,000,041, U.S. Pat. No. 5,781,729, and U.S. Pat. No. 5,793,954, all of which are hereby incorporated herein by reference, in their entirety. - Briefly summarizing the operation of these modules, the
protocol parsing engine 47 is configured to perform a protocol parsing function, using one or more programmably configurable protocol descriptions. For example, theprotocol parsing engine 47 may be configured to perform data modifications such as encrypting and decrypting data, as discussed in U.S. Pat. No. 6,651,102. Alternatively, theprotocol parsing engine 47 may be configured to gather statistics, perform routing functions, or modify text formats, as discussed in the various other US Patent references incorporated by reference. - The
protocol parsing engine 47 uses these programmably configurable protocol descriptions, along with common control logic, to perform the various functions specified by the protocol descriptions. This allows theprotocol parsing engine 47 to be re-configured entirely through user input, without the need for hardware or software system modifications. Thus, those skilled in the art with the benefit of this disclosure and the disclosures of the US patents incorporated by reference will appreciate that the system 5 in accordance with an embodiment of the invention may be configured and reconfigured in a highly efficient and cost-effective manner to implement numerous different functions, and to accommodate substantial application or task modifications, such as the use of different types of data processors, different encryption schemes, different encryption algorithms and keys, different key lengths, etc., without requiring substantial system changes. - The
protocol parsing engine 47 retrieves input data from either an input data file or a streaming data source such as a network data transmission stream. The input data is typically organized as a series of protocols, such as network transmission protocols. Theprotocol parsing engine 47 then parses this data, according to the programmably configurable protocol description which was used to configure theprotocol parsing engine 47. For example, if theprotocol parsing engine 47 is configured with a data modification protocol, then theprotocol parsing engine 47 will parse the input data and modify the input data according to the data modification protocol. Thus if the data modification protocol is an encryption protocol, theprotocol parsing engine 47 will encrypt the data. Similarly, if the data modification protocol is a decryption protocol, then theprotocol parsing engine 47 will decrypt the data. If theprotocol parsing engine 47 is configured with a programmably configurable protocol description that includes functions which generate executable code for performing some or all of the configured functions, then theprotocol parsing engine 47 will parse the input data using the executable code generated for theprotocol parsing engine 47 by the protocol description. - The
algorithm generator 43 generates encryption algorithms, either as a stand-alone process, or with the assistance of an administrator. Examples of the encryption algorithms which may be generated by thealgorithm generator 43 are the encryption algorithms discussed in U.S. Pat. No. 6,651,102, for example at FIGS. 5-7. Content providers may already have implemented encryption policies or encryption schemes which specify the general parameters for the encryptions to be applied to their data, such as number of transformations, type of transformations, as well as specific algorithms which the content provider prefers. All of this provider-specific customization may be represented in the algorithms generated by thealgorithm generator 43, merely by modifying the number of or ordering of the steps of the algorithm, or the values used in the steps of the algorithm, as well as by changing the actual types of modifications to be used in the algorithm. Once an algorithm or scheme has been formulated, then thealgorithm generator 43 may be automated, by, for example, instructing thealgorithm generator 43 to select the values used in the steps of the algorithm at random, or to re-order the steps of the algorithm according to some configured policy. These algorithms are then expressed as protocol descriptions, to be provided to theprotocol parsing engine 47. - The
key generator 44 generates keys to be used with the algorithms generated by thealgorithm generator 43. These keys may, for example, be used as described in U.S. Pat. No. 6,651,102, along with the algorithms described in that patent, to encrypt or decrypt data. The keys may be generated according to the content provider's key generation policy, which may specify, for example, key lengths or other key requirements such as requiring certain characters in the key, or forbidding certain characters. These keys may be expressed as protocol descriptions, or they may be used by or incorporated into the algorithm generated by thealgorithm generator 43. Thekey generator 44 may be a separate module, or thekey generator 44 may be incorporated into thealgorithm generator 43. - The
encryption module 46 takes the algorithm and key generated by thealgorithm generator 43 andkey generator 44, and supplies them to theprotocol parsing engine 47, thus configuring theprotocol parsing engine 47 to encrypt the input data. Theencryption module 46 also collects the input data, such as music or video files, from thedata storage 14, and supplies the input data to theprotocol parsing engine 47. - The
code generator 45 takes a the algorithm and key generated by thealgorithm generator 43 andkey generator 44, uses the algorithm and key to generate executable code for the parsing process, and supplies the generated code to theprotocol parsing engine 47, or to the communications link 16, for provision to thesecurity manager 52 on thecontent user 20. The protocol description for the algorithm and/or key includes, for example, functions that create executable code that when executed will encrypt or decrypt a data file. For example, the protocol description specifies a segment of executable code for each of the possible data manipulation operations that can be specified in a data manipulation protocol description, such as the data manipulation protocol descriptions of FIGS. 5-7 of U.S. Pat. No. 6,651,102. When the protocol description including the executable code is used to configure theprotocol parsing engine 47, or thesecurity manager 52, the protocol parsing engine is configured such that, when supplied with a music, video or other content file, it will modify the data in the content file according to the protocol description. The protocol description may also include standardized code routines that are desired to be included into all executable code created by the protocol description. Examples of these standardized code routines would be input/output routines, standardized mathematical computation routines, data cleanup routines, etc. - Turning to
FIG. 5 , themedia reader 22 includes several modules. These modules may be implemented in either software, hardware, firmware, or some combination of software hardware and firmware. The modules in themedia reader 22 include arequest generator 51, asecurity manager 52, and amedia processor 53. - The
request generator 51 is responsible for making requests to thecontent provider 10 for access to content. Therequest generator 51 may be implemented in a variety of different manners, depending upon the nature of themedia reader 22. For example, if themedia reader 22 is a personal computer, therequest generator 51 may be a web browser. If themedia reader 22 is a portable media player therequest generator 51 may be a code routine installed in the firmware of the media player, which responds to a user's activation of a Play button or other such feature of the portable media player. Therequest generator 51 may be activated by a user of themedia reader 22, or therequest generator 51 may be activated by other internal processes running on themedia reader 22. Therequest generator 51 sends information to thecontent provider 10 such as information specifying the identity of themedia reader 22, billing information for any charges that thecontent provider 10 may require, or information about the particular content requested by themedia reader 22. - The
security manager 52 is responsible for receiving content from thecontent provider 10. Thesecurity manager 52 also manages decrypting encrypted content, and encrypting decrypted content as needed to provide protection to the content from thecontent provider 10 while allowing thecontent user 20 to use the content. Thesecurity manager 52 receives encrypted content from thecontent provider 10. Thesecurity manager 52 also receives executable encryption and decryption modules from thecontent provider 10, and executes those modules on decrypted or encrypted content. To further preserve the security of the content provided by thecontent provider 10, thesecurity manager 52 deletes the executable encryption and decryption modules once those modules have finished operations. Deleting these modules prevents them from being accessed by malicious users of themedia reader 22. - The
media processor 53 is responsible for processing the decrypted media files created by thesecurity manager 52, and sending the appropriate signals to thecontent display 28, to display the content. The media processor may include, for example, a digital/analog converter, as well as any other circuitry useful in playing video or audio signal data. - Turning to
FIGS. 6-13 , the system 5 for securely distributing digital content is used according to various methods, depending on the particular function being performed. Among the functions the system 5 is capable of performing are customer purchases of digital content, customer playing of digital content, and customer copying of digital content. All of these functions are performed while maintaining the security of the digital content from unauthorized copying or playing. - A method of operating a
content provider 10 to respond to a purchase request from acontent user 20 is shown inFIG. 6 . The method begins atstep 610 when thecontent provider 10 receives a purchase request from thecontent user 20. The purchase request is received over the communications link 16, from thenetwork 30. The purchase request is routed from the communications link 16 to therequest processor 40 in thecomputer 12. Atstep 620, therequest processor 40 routes the request to thebilling module 41 to process the content user's payment information. Atstep 625, if the content user's payment information is not successfully processed and payment is not made, then atstep 627 thebilling module 41 rejects the purchase request and therequest processor 40 advises thecontent user 20 that the purchase request has been rejected. The rejected purchase request is also sent to thelogging module 42 to record the rejected request in the content provider's logs. This information may be useful if the content provider wishes to investigate the logs for patterns of potentially fraudulent conduct, or for other reasons thecontent provider 10 wishes to learn about the history of requests made to thecontent provider 10. - If the payment is successfully processed, the
request processor 40 routes the purchase request onward through the modules of thecomputer 12 at thecontent provider 10. Atstep 630, in response to the successful purchase request, thealgorithm generator 43 generates a new encryption algorithm. As discussed above, this encryption algorithm may be based upon any security policies or schemes thecontent provider 10 desires to use, depending on the level of security thecontent provider 10 wishes to implement. In an embodiment, every new purchase request triggers the creation of a new encryption algorithm to be assigned to the specific content being purchased. Alternatively, thecontent provider 10 may develop a pool of encryption algorithms and select one or more algorithms from this pool for use with the newly purchased content. This alternative solution trades off some loss in security for a simpler operation of the system. The corresponding decryption algorithm may also be generated at this time, if necessary. Alternatively, for many encryption/decryption schemes, the decryption algorithm is easily derived from the encryption algorithm, for example by running the steps of the encryption algorithm in reverse order. For some algorithms, running the steps of the encryption algorithm again, on encrypted content, results in decryption of the content. - Once the encryption algorithm is generated by the
algorithm generator 43, then at step 635 a key for the generated algorithm is created by thekey generator 44. As noted above, thekey generator 44 may be a separate module from thealgorithm generator 43, or it may be incorporated into thealgorithm generator 43. In an embodiment, every new purchase request triggers the creation of a new encryption key to be assigned to the specific content being purchased. Alternatively,content provider 10 may develop a pool of keys and select one or more keys from this pool for use with the newly purchased content. As a further alternative, an encryption algorithm may be re-used by multiple purchasers of content, with each purchaser being assigned a different key. These alternative solutions trade off some loss in security for a simpler operation of the system. - Either or both of the encryption algorithm and the key may be selected, at least in part, based on information provided by the
content user 20. For example, the customer's name, address, credit card number, or a user-selected ID number may be used to partially or fully select the algorithm and key to be used. Alternatively, an algorithm and key may be selected without using any information from thecontent user 20, and instead the algorithm and key are selected using some internal policies, or random selection. - Once the encryption algorithm and encryption key have been generated, then at
step 640 thelogging module 42 stores an encryption ID in thedata storage 14 at thecontent provider 10. The encryption ID may comprise the actual algorithm and key themselves, or the encryption ID may comprise some other information sufficient to identify which specific algorithm and key was generated for the newly purchased content. For example, if the algorithm and key are randomly generated, then the encryption ID may be the randomly generated number that was used to select the algorithm and key. - At
step 650, therequest processor 40 retrieves the newly purchased content from thedata storage 14, or from any other data storage where the newly purchased content may be stored, and hands the content off to theencryption module 46. Atstep 660, theencryption module 46 provides the encryption algorithm and encryption key generated above for the newly purchased content to theprotocol parsing engine 47, thereby configuring theprotocol parsing engine 47 to encrypt input data according to the encryption algorithm and encryption key provided. Additionally, thecode generator 45 generates executable code for any functions specified in the protocol descriptions for the algorithm and key generated above as having executable code for them. Theencryption module 46 then provides to theprotocol parsing engine 47 these executable code modules, to streamline the encryption process. Atstep 665, the newly purchased content is provided to theprotocol parsing engine 47 as input data, and the newly purchased content is thereby encrypted. Once the content is encrypted, then atstep 670 the encrypted content is then sent to thecontent user 20, along with an identifier identifying the encrypted content. This identifier may be the encryption ID discussed above, if that encryption ID cannot be reverse-engineered or otherwise inspected to extract the encryption algorithm or key. Alternatively the identifier may be some other sequence of data that identifies the specific copy of the content being sent to thecontent user 20. This identifier is also stored in thedata storage 14 by thelogging module 42, atstep 675. - Since the encryption algorithm and key are both generated on the fly and provided to the configurable
protocol parsing engine 47, those skilled in the art will appreciate that the algorithm, the key, and the key length can all be changed each and every time that acontent user 20 purchases new content. This allows each copy of each content item sold by thecontent provider 10 to be encrypted not only with a unique key, but with a unique encryption algorithm, including algorithms with different key lengths. - A method of operating a
content user 20 to purchase content is shown inFIG. 7 . The method begins atstep 710, where therequest generator 51 at thecontent user 20 generates a request to purchase content. Where therequest generator 51 is a web browser, thecontent user 20 enters information such as the title, author, or publisher of desired content. Thecontent user 20 may conduct other activities such as searches for desired content, or reading reviews of content, in addition to requesting the content. Once thecontent user 20 locates the desired content and is ready to purchase it, then atstep 720 thecontent user 20 provides billing information, such as a credit card number, to therequest generator 51. Therequest generator 51 then forwards all of this information on to thecontent provider 10, via the communications link 26 and on to thenetwork 30. Atstep 730 thecontent user 20 receives the purchased content, in encrypted form as discussed above, from thecontent provider 10. The encrypted content is stored in thedata storage 24, atstep 740, where it is made available for future requests to play or copy the content, as will be discussed in detail below. - A method of operating a
content provider 10 to allow encrypted content to be played by acontent user 20 is shown inFIG. 8 . The method begins atstep 810 when thecontent provider 10 receives a request to play encrypted content from acontent user 20, via thenetwork 30 and communications link 16. Therequest processor 40 receives the play request, and validates the request atstep 820. The request is validated by, for example, comparing an identifier provided by thecontent user 20 with the corresponding identifier created when the encrypted content was initially purchased by thecontent user 20. This corresponding identifier is stored at thecontent provider 10, as discussed atstep 675 ofFIG. 6 . If there is a charge for playing previously purchased content, then a billing procedure similar to that discussed at steps 620-625 ofFIG. 6 is followed as part of the validation step. If thecontent provider 10 cannot validate the play request, then atstep 830, the play request is rejected, and the rejection is conveyed back to thecontent user 20. Atstep 840, the rejected request is sent to thelogging module 42, for logging in thedata storage 14. This allows thecontent provider 10 to keep track of the history of play requests, should thecontent provider 10 wish to investigate possible fraud attempts or other such issues. - If the validation request is successful, then at
step 850, the play request, or the identifier in the play request, is sent to thelogging module 42 for logging in thedata storage 14. Once the play request is validated, then atstep 860 thelogging module 42 looks up the encryption ID for the encrypted content that is the subject of the play request, in thedata storage 14. The encryption ID is used, atstep 865, to retrieve the corresponding decryption algorithm and key for the encrypted content, to allow the encrypted content to be decrypted. The algorithm and key may be retrieved in a variety of ways. For example, if the encryption ID itself contains the decryption algorithm and key, then the algorithm and key are retrieved from the encryption ID itself. If the decryption algorithm and key are stored elsewhere in thedata storage 14, indexed by the encryption ID, then the encryption ID is used to locate the decryption algorithm and key stored in thedata storage 14. Alternatively, in embodiments where the encryption ID is a seed value for a random selection routine that can be used to generate the decryption algorithm and key, then the decryption algorithm and key are retrieved by providing the encryption ID as a seed to the random selection routine, which results in the decryption algorithm and key being re-generated on demand. Depending on the particular encryption/decryption scheme implemented by thecontent provider 10, the same seed value will generate both an encryption algorithm and key, as well as the corresponding decryption algorithm and key. - Since the seed value is the same as the original seed value used to create the decryption algorithm and key initially, the re-generated decryption algorithm and key will be identical to the previously created decryption algorithm and key. This alternative embodiment realizes a savings in storage space needed to store all of the algorithms and keys, at the possible tradeoff of increased response time to regenerate algorithms and keys. Note, however, that as the library of generated algorithms and keys becomes larger, regenerating algorithms and keys may eventually be faster than searching for them in the library of generated algorithms and keys.
- Once the proper decryption algorithm and key for the content to be played have been recovered, then at
step 870 the decryption algorithm and key are passed on to thecode generator 45. Thecode generator 45 uses the decryption algorithm and key to generate an executable code module to allow thesecurity manager 52 on thecontent user 20 to decrypt the encrypted digital content. Details of the code generation process are discussed below. Thecode generator 45 can generate code specific to the architecture of theparticular media reader 22 at thecontent user 20, if the play request (or the prior purchase request) contained information sufficient to identify the architecture. For example, if the play or purchase request indicates that themedia reader 22 is a Windows/DOS personal computer, then thecode generator 45 generates an executable code module for the Windows/DOS architecture. If the play/purchase request indicates that themedia reader 22 is an Apple Macintosh personal computer, then thecode generator 45 generates an executable code module for the Macintosh architecture. Similarly, if the play/purchase request indicates that themedia reader 22 is an iPod device, or a CD player, or an MP3 player, thecode generator 45 generates the appropriate executable code module. - The executable code module is only capable of decrypting content that uses the exact decryption algorithm and key provided to the
code generator 45. Therefore the executable code module cannot be used bymalicious content users 20 as a universal decoder, as long as thecontent provider 10 has encrypted its content using a variety of different algorithms, as discussed above. In embodiments where every content item sent out from thecontent provider 10 is encrypted with a different algorithm and key, the executable code module can only be used on the specific content item for which it is intended. Once the executable code module is created by thecode generator 45, then atstep 880 the executable code module is sent to thecontent user 20, via the communications link 16 andnetwork 30. - A method of operating a
content user 20 to play encrypted content is shown inFIG. 9 . The method begins atstep 910, where therequest generator 51 at thecontent user 20 generates a request to play content stored in encrypted form on thecontent user 20. Where therequest generator 51 is a web browser, thecontent user 20 enters information such as the identifier associated with the encrypted content, which was previously provided to thecontent user 20 when thecontent user 20 purchased the content item. If there is a charge associated with playing the content item, then atstep 915 thecontent user 20 provides billing information, such as a credit card number, to therequest generator 51. Therequest generator 51 then forwards all of this information on to thecontent provider 10, via the communications link 26 and on to thenetwork 30. - At
step 920, thecontent user 20 receives a response back from thecontent provider 10. The request is either denied, if thecontent provider 10 was unable to validate the request (or process payment if any was required), or the request is accepted and an executable decryption code module is returned to thecontent user 20. Assuming that the executable decryption code module is returned to thecontent user 20, the module is provided to thesecurity manager 52, atstep 930. In an embodiment, the executable decryption code module is stored in volatile memory on themedia reader 22 at thecontent user 20. Limiting the executable decryption code module to volatile storage helps enhance the security of the system 5, since it is much more difficult formalicious content users 20 to obtain a copy of the executable decryption code module, to possibly inspect or reverse-engineer. Thesecurity manager 52 then retrieves the encrypted content item from thedata storage 24, or other location where the encrypted content item is stored. Finally, thesecurity manager 52 uses the encrypted content item as input data to the executable decryption code module, and creates a decrypted version of the content item. This decrypted version of the content item is also preferably stored in volatile storage, to minimize the potential formalicious content users 20 to obtain a copy of the decrypted content item. If the content item is too large to be easily stored in volatile memory, then the content item can be decrypted in pieces, each piece being stored in volatile memory until the piece is processed, and then the piece is deleted and replaced with a successive piece of the decrypted content item. - Once the
security manager 52 decrypts, or begins decrypting, the content item to be played, atstep 940 the decrypted portion of the content item is provided to themedia processor 53 for processing. Themedia processor 53 processes the decrypted content item and routes the output to thecontent display 28 atstep 950, where the content is enjoyed by thecontent user 20 or others. Once the content item is finished being displayed, or for streaming content items such as audio files, once a portion of the content item stream is finished being displayed, then atstep 960 the decrypted content item or portion thereof is deleted from themedia reader 22, thereby preserving security of the content item and maintaining the integrity of the system 5. - A method of operating a
content provider 10 to allow an encrypted content item to be copied by acontent user 20 is shown inFIG. 10 . The method begins atstep 1010 when thecontent provider 10 receives a request to copy encrypted content from acontent user 20, via thenetwork 30 and communications link 16. Therequest processor 40 receives the copy request, and validates the request atstep 1020. The request is validated by, for example, comparing an identifier provided by thecontent user 20 with the corresponding identifier created when the encrypted content was initially purchased by thecontent user 20. This corresponding identifier is stored at thecontent provider 10, as discussed atstep 675 ofFIG. 6 . If there is a charge for copying previously purchased content, then a billing procedure similar to that discussed at steps 620-625 ofFIG. 6 is followed as part of the validation step. If thecontent provider 10 cannot validate the copy request, then atstep 1030, the copy request is rejected, and the rejection is conveyed back to thecontent user 20. Atstep 1040, the rejected request is sent to thelogging module 42, for logging in thedata storage 14. This allows thecontent provider 10 to keep track of the history of copy requests, should thecontent provider 10 wish to investigate possible fraud attempts or other such issues. - If the validation request is successful, then at
step 1050, the copy request, or the identifier in the copy request, is sent to thelogging module 42 for logging in thedata storage 14. Once the copy request is validated, then atstep 1060 thelogging module 42 looks up the encryption ID for the encrypted content that is the subject of the copy request, in thedata storage 14. The encryption ID is used, atstep 1065, to retrieve the corresponding decryption algorithm and key for the encrypted content, to allow the encrypted content to be decrypted. The algorithm and key may be retrieved in a variety of ways, as discussed above for retrieving algorithms and keys for play requests. - Once the decryption algorithm and key are retrieved, then at
step 1070, in response to the validated copy request, thealgorithm generator 43 generates a new encryption algorithm to be used to encrypt the copy, once it is made. Thealgorithm generator 43 performs this step in a manner similar to generating new encryption algorithms for newly purchased content, as discussed forstep 630 ofFIG. 6 . Once the encryption algorithm is generated by thealgorithm generator 43, then at step 1075 a key for the generated algorithm is created by thekey generator 44. The key generation step proceeds similarly to that atstep 635 ofFIG. 6 above. Once the encryption algorithm and encryption key have been generated, then atstep 1080 thelogging module 42 stores a new encryption ID in thedata storage 14 at thecontent provider 10 for the new copy. This step is performed in a manner similar to step 640 ofFIG. 6 above. - Once the proper decryption algorithm and key for the content to be copied have been recovered, and the new encryption algorithm and key for the new copy have been created, then at
step 1090 the decryption algorithm and key are passed on to thecode generator 45. Thecode generator 45 generates an executable code module to configure thesecurity manager 52 at thecontent user 20 to decrypt the encrypted content item to be copied. This process is performed in a manner similar to step 870 ofFIG. 8 above. Thecode generator 45 then generates an executable code module to configure thesecurity manager 52 at thecontent user 20 to encrypt the new copy of the content item that is about to be created. This process is performed in a manner similar to step 870 ofFIG. 8 above, except that the executable encryption code module will encrypt rather than decrypt the content item provided as input. Once the two executable code modules are created by thecode generator 45, then atstep 1095, the executable code modules are sent to thecontent user 20, via the communications link 16 andnetwork 30. - An alternative method of operating a
content provider 10 to allow an encrypted content item to be copied by acontent user 20 is shown inFIG. 11 . This method performs the copying and encryption steps at thecontent provider 10 instead of at thecontent user 20. Security is thereby enhanced, at a tradeoff of increased network bandwidth usage, increased demand on thecomputer 12 at thecontent provider 10, and increased storage requirements for thedata storage 14, since it must store a master copy of all content ever sold, not just a current catalog of content for sale. - The method begins at
step 1110 when thecontent provider 10 receives a request to copy encrypted content from acontent user 20, via thenetwork 30 and communications link 16. Therequest processor 40 receives the copy request, and validates the request atstep 1120. The request is validated by, for example, comparing an identifier provided by thecontent user 20 with the corresponding identifier created when the encrypted content was initially purchased by thecontent user 20. This corresponding identifier is stored at thecontent provider 10, as discussed atstep 675 ofFIG. 6 . If there is a charge for copying previously purchased content, then a billing procedure similar to that discussed at steps 620-625 ofFIG. 6 is followed as part of the validation step. If thecontent provider 10 cannot validate the copy request, then atstep 1130, the copy request is rejected, and the rejection is conveyed back to thecontent user 20. Atstep 1140, the rejected request is sent to thelogging module 42, for logging in thedata storage 14. This allows thecontent provider 10 to keep track of the history of copy requests, should thecontent provider 10 wish to investigate possible fraud attempts or other such issues. - If the validation request is successful, then at
step 1150, the copy request, or the identifier in the copy request, is sent to thelogging module 42 for logging in thedata storage 14. Then atstep 1160, in response to the validated copy request, thealgorithm generator 43 generates a new encryption algorithm to be used to encrypt the copy, once it is made. Thealgorithm generator 43 performs this step in a manner similar to generating new encryption algorithms for newly purchased content, as discussed forstep 630 ofFIG. 6 . Once the encryption algorithm is generated by thealgorithm generator 43, then at step 1165 a key for the generated algorithm is created by thekey generator 44. The key generation step proceeds similarly to that atstep 635 ofFIG. 6 above. Once the encryption algorithm and encryption key have been generated, then atstep 1170 thelogging module 42 stores a new encryption ID in thedata storage 14 at thecontent provider 10 for the new copy. This step is performed in a manner similar to step 640 ofFIG. 6 above. - At
step 1180, therequest processor 40 retrieves the content to be copied from thedata storage 14, or from any other data storage where the content to be copied may be stored, and hands the content off to theencryption module 46. Atstep 1190, theencryption module 46 provides the encryption algorithm and encryption key generated above for the content to be copied to theprotocol parsing engine 47, thereby configuring theprotocol parsing engine 47 to encrypt input data according to the encryption algorithm and encryption key provided. Additionally, thecode generator 45 generates executable code for any functions specified in the protocol descriptions for the algorithm and key generated above as having executable code for them. Theencryption module 46 then provides to theprotocol parsing engine 47 these executable code modules, to streamline the encryption process. Atstep 1193, the content to be copied is provided to theprotocol parsing engine 47 as input data, and the content to be copied is thereby encrypted. Once the content is encrypted, then atstep 1195 the encrypted content is sent to thecontent user 20, along with an identifier identifying the encrypted content. This identifier may be the encryption ID discussed above, if that encryption ID cannot be reverse-engineered or otherwise inspected to extract the encryption algorithm or key. Alternatively the identifier may be some other sequence of data that identifies the specific copy of the content being sent to thecontent user 20. This identifier is also stored in thedata storage 14 by thelogging module 42, atstep 1197. - Since the encryption algorithm and key are both generated on the fly and provided to the configurable
protocol parsing engine 47, those skilled in the art will appreciate that the algorithm, the key, and the key length can all be changed each and every time that acontent user 20 makes a copy of content. This allows each copy of each content item sold by thecontent provider 10 to be encrypted not only with a unique key, but with a unique encryption algorithm, including algorithms with different key lengths. - A method of operating a
content user 20 to copy anencrypted content item 20 is shown inFIG. 12 . The method begins atstep 1210, where therequest generator 51 at thecontent user 20 generates a request to copy content stored in encrypted form on thecontent user 20. Where therequest generator 51 is a web browser, thecontent user 20 enters information such as the identifier associated with the encrypted content, which was previously provided to thecontent user 20 when thecontent user 20 purchased the content item. If there is a charge associated with copying the content item, then atstep 1215 thecontent user 20 provides billing information, such as a credit card number, to therequest generator 51. Therequest generator 51 then forwards all of this information on to thecontent provider 10, via the communications link 26 and on to thenetwork 30. - At
step 1220, thecontent user 20 receives a response back from thecontent provider 10. The request is either denied, if thecontent provider 10 was unable to validate the request (or process payment if any was required), or the request is accepted and an executable decryption code module and executable encryption code module are returned to thecontent user 20. Assuming that the executable decryption and encryption code modules are returned to thecontent user 20, the modules are provided to thesecurity manager 52, atstep 1230. In an embodiment, the executable decryption and encryption code modules are stored in volatile memory on themedia reader 22 at thecontent user 20. Limiting the executable decryption and encryption code modules to volatile storage helps enhance the security of the system 5, since it is much more difficult formalicious content users 20 to obtain a copy of the executable decryption and encryption code modules, to possibly inspect or reverse-engineer them. Thesecurity manager 52 then retrieves the encrypted content item from thedata storage 24, or other location where the encrypted content item is stored. Thesecurity manager 52 uses the encrypted content item as input data to the executable decryption code module, and creates a decrypted version of the content item. This decrypted version of the content item is also preferably stored in volatile storage, to minimize the potential formalicious content users 20 to obtain a copy of the decrypted content item. If the content item is too large to be easily stored in volatile memory, then the content item can be decrypted in pieces, each piece being stored in volatile memory until the piece is processed, and then the piece is deleted and replaced with a successive piece of the decrypted content item. - Once the encrypted content item is decrypted, or as it is decrypted, the decrypted content item is copied by the
media processor 53, atstep 1240. The decrypted copy is also preferably stored in volatile memory, such as the RAM of themedia reader 22, as discussed above. The decrypted copy is then provided as input to the executable encryption code module, atstep 1250. This results in a newly encrypted copy of the content item being created, using the new algorithm and key contained in the executable encryption code module. Thus the original and the copy both remain on thecontent user 22, but they are both encrypted, using different algorithms and keys. The encrypted copy may now be freely distributed to anothercontent user 20, or burned into a CD-ROM or DVD media disk, or the like, without fear that thecontent user 20 will be able to create further unencrypted copies. Thesecond content user 20 may still play the copy of the content, by making his own play request to thecontent provider 10. Atstep 1260, the executable encryption and decryption code modules and the decrypted content are all deleted from the memory they were stored in. - An alternative method of operating a
content user 20 to obtain a copy of a content item is shown inFIG. 13 . This method performs the copying and encryption steps at thecontent provider 10 instead of at thecontent user 20. Security is thereby enhanced, and processing resources at thecontent user 20 are conserved, at a tradeoff of increased network bandwidth usage, increased demand on thecomputer 12 at thecontent provider 10, and increased storage requirements for thedata storage 14, since it must store a master copy of all content ever sold, not just a current catalog of content for sale. From the point of view of thecontent user 20, the method is treated identically to a purchase of new content, except that an identifier is sent to thecontent provider 10 to establish that thecontent user 20 is already in possession of a copy of the content item. This information may be used by the content provider to, for example, make billing decisions (i.e. billing acontent user 20 at a lower rate, or dispensing with billing entirely, for copies of content that thecontent user 20 already owns). - The method begins at
step 1310, where therequest generator 51 at thecontent user 20 generates a request to copy an identified content item. Atstep 720 thecontent user 20 provides billing information if required by thecontent provider 10. Therequest generator 51 then forwards all of this information on to thecontent provider 10. Atstep 730 thecontent user 20 receives the copied content, in encrypted form as discussed above, from thecontent provider 10. The encrypted content is stored in thedata storage 24, atstep 740, where it is made available for future requests to play or copy the content. - It is possible that someone will make copies of an encrypted content item and distribute those copies. Each of these users may then make play requests, asking for permission to play their illicit copy. This can be easily thwarted, however, by using the methods discussed above to change the algorithm and key associated with any content item, each time a-play request is made. With such a scheme, the
first content user 20 to request to play any particular encrypted copy will be accepted, and his copy of the encrypted content will be re-encrypted after it is played. Allsuccessive content users 20, however, will be rejected, since either their identifiers will no longer match the identifier on file (which was changed when thefirst content user 20 made a play request) or else the encrypted file will not be able to be unencrypted, since the decryption algorithm and key were changed by thefirst content user 20 when he made the first play request. Effectively, this alternate embodiment combines a copy request with every play request, creating true one-use copies of content items. - A detailed discussion of the use of the protocol description to generate executable code will now be presented. To aid in understanding these examples, a framework within the instruction set of the target machine and language will be defined. The following discussion assumes that the target machine is an x86 style Intel processor and the target language is the x86 assembly language. It is possible to produce code (programming instructions) for virtually any processor or other programmable device. For instance, the example code detailed below could be changed to output machine code directly so that it is ready to be executed without needing to be assembled first. Additionally, the filtering code examples shown below could be modified to produce programming instructions/configuration information suitable for the content addressable memory typically used to perform rudimentary frame filtering in many network switches and routers.
- The x86 processor provides 8 32-bit general-purpose registers: EAX, EBX, ECX, EDX, EBP, ESP, ESI, and EDI. The low 16 bits of the 32-bit general-purpose registers can be referenced independently as AX, BX, CX, DX, BP, SP, SI, AND DI. Each byte of the first four 16 bit registers can be referenced independently as AH, BH, CH, DH for the high bytes, and AL, BL, CL, DL for the low bytes.
- Code can be optimized and memory accesses performed by the processor can be minimized by making assumptions and pre-assigning both meanings and values to registers that will apply to all generated code. The following discussions assume that:
- 1. The ESI register will contain a pointer to the start of the protocol header currently being parsed (i.e. code being generated for); therefore ESI=ParsePtr as that term is used in U.S. Pat. No. 6,651,102 and the other US Patents incorporated by reference herein.
- 2. 64-bit values returned from any operation will be contained in EDX:EAX, where EDX contains the upper 32 bits and EAX contains the lower 32 bits.
- 3. 32-bit values returned from any operation will be contained in EAX, the contents of EDX are undefined.
-
TABLE 1 Basic Generated Code Output Routine. U32 NextLabelNumber = 0; // For generating Label Names char codebuf[262144]; void OutText(char *Instruction, U32 v1, U32 v2, protocol *p, field *f, char *Comment) { if (Instruction != “”) sprintf(&codebuf[strlen(codebuf)], Instruction, v1, v2, p); // Output user supplied instruction and 1,2, or 3 values else { sprintf(&codebuf[strlen(codebuf)], “;\n”); // Output newline character if (p != 0 && p->pname( ) != “”) sprintf(&codebuf[strlen(codebuf)], “; (%s)”, p- >pname( )); // Output protocol name if (f != 0 && f->name( ) != “”) sprintf(&codebuf[strlen(codebuf)], “->(%s)”, f->name( )); // Output field name if (Comment != “”) sprintf(&codebuf[strlen(codebuf)], “%s”, Comment); // Output any supplied comment sprintf(&codebuf[strlen(codebuf)], “\n;”); // Output newline character } sprintf(&codebuf[strlen(codebuf)], “\n”); // Output newline character } - The code in Table 1 is an example of code used by the code generation routines below, to send the actual lines of generated code to an output buffer, which may be a data file or may be some other output processing routine.
- The routine in Table 2 below generates optimized code for extracting values for user defined protocol fields. The routine uses data from a protocol record to select which of the code templates included in the routine to send to the output buffer. The code templates are combined with data from the protocol record to generate customized code. Only the portion of the code that generates extraction code for fields that are aligned on an 8-bit boundary in memory is shown. The code for extracting values for fields that are not aligned has been removed because it is not used in any of the included examples.
-
TABLE 2 Example Field Value Extraction Code Generation Routine // // esi - ParsePtr // edx:eax - extracted field value // void field::GenerateFieldExtractionCode(protocol *p, U32 IncludeUpper32) { U32 BitLen = 64 − fshr, FirstBit = fshl, LastBit = fshl + BitLen − 1; U32 HiMask = (U32) ((0xffffffffffffffff<<fshl)>>(fshr+32)), LoMask = (U32) ((0xffffffffffffffff<<fshl)>>fshr); // U64 Msk = (0xffffffffffffffff<<fshr)>>fshl; if (BitLen == 0) return; sprintf(&codebuf[strlen(codebuf)], “;\n;..........<<%u >>%u::%u\n;..........0x%08X%08X\n;\n”, fshl, fshr, BitLen, (U32) (Msk>>32), (U32)Msk&0xffffffff); // // Optimized extraction cases done first // if (BitLen <= 8) // Len <= 8 bits ? { if (FirstBit/8 == LastBit/8) // All bits in one byte ? { if (IncludeUpper32) OutText(“ xor edx, edx”); OutText(“ xor eax, eax”); OutText(“ mov al, BYTE PTR [esi+%u]”, p- >swap( ) ? fdwoff+fshl/8 : fdwoff+(fshr−fshl)/8); if (((fshl+BitLen)&7) != 0) OutText(“ shr al, %u”, (fshr− fshl)&7); // Signed case ... use sar if ((fshl&7) != 0) OutText(“ and al, BYTE PTR %02xH”, LoMask); return; } } else if ((fshl&7) == 0) // Does this field start on a BYTE boundary? { if (fshr == 48) // WORD ?? { if (IncludeUpper32) OutText (“ xor edx, edx”); OutText(“ xor eax, eax”); if (p->swap( )) { OutText(“ mov ah, BYTE PTR [esi+%u]”, fdwoff+fshl/8); OutText(“ mov al, BYTE PTR [esi+%u]”, fdwoff+fshl/8+1); } else OutText(“ mov ax, WORD PTR [esi+%u]”, fdwoff+fshl/8); return; } else if (fshr == 40) // BYTE AND WORD ? { if (IncludeUpper32) OutText(“ xor edx, edx”); if (p->swap( )) { OutText(“ mov eax, DWORD PTR [esi+%u]”, fdwoff+fshl/8−1); OutText(“ bswap eax”); OutText(“ and eax, DWORD PTR %09xH”, LoMask); } else { OutText(“ mov eax, DWORD PTR [esi+%u]”, fdwoff+(fshr−fshl)/8); OutText(“ and eax, DWORD PTR %09xH”, LoMask); } return; } else if (fshr == 32) // DWORD ? { if (IncludeUpper32) OutText(“ xor edx, edx”); if (p->swap( )) { OutText(“ mov eax, DWORD PTR [esi+%u]”, fdwoff+fshl/8); OutText(“ bswap eax”); } else OutText(“ mov eax, DWORD PTR [esi+%u]”, fdwoff+(fshr−fshl)/8); return; } else if (fshr == 24) // BYTE AND DWORD ? { OutText (“ xor edx, edx”); if (p->swap( )) { OutText(“ mov eax, DWORD PTR [esi+%u]”, fdwoff+fshl/8+1); OutText(“ mov dl, BYTE PTR [esi+%u]”, fdwoff+fshl/8+0); OutText(“ bswap eax”); } else { OutText(“ mov eax, DWORD PTR [esi+%u]”, fdwoff+(fshr−fshl)/8); OutText(“ mov dl, BYTE PTR [esi+%u]”, fdwoff+(32+fshr−fshl)/8); } return; } else if (fshr == 16) // WORD AND DWORD ? { OutText(“ xor edx, edx”); if (p->swap( )) { OutText (“ mov eax, DWORD PTR [esi+%u]”, fdwoff+fshl/8+2); OutText(“ mov dl, BYTE PTR [esi+%u]”, fdwoff+fshl/8+1); OutText(“ mov dh, BYTE PTR [esi+%u]”, fdwoff+fshl/8); OutText(“ bswap eax”); } else { OutText(“ mov eax, DWORD PTR [esi+%u]”, fdwoff+(fshr−fshl)/8); OutText(“ mov dx, WORD PTR [esi+%u]”, fdwoff+(32+fshr−fshl)/8); } return; } else if (fshr == 8) // BYTE AND WORD AND DWORD ? { if (p->swap( )) { OutText(“ mov edx, DWORD PTR [esi+%u]”, fdwoff+fshl/8−1); OutText(“ mov eax, DWORD PTR [esi+%u]”, fdwoff+fshl/8+3); OutText(“ bswap edx”); OutText(“ bswap eax”); OutText(“ and edx, DWORD PTR %09xH”, HiMask); } else { OutText(“ mov eax, DWORD PTR [esi+%u]”, fdwoff+(fshr−fshl)/8); OutText(“ mov edx, DWORD PTR [esi+%u]”, fdwoff+(32+fshr−fshl)/8); OutText(“ and edx, DWORD PTR %09xH”, HiMask); } return; } else if (fshr == 0) // DWORD AND DWORD ? { if (p->swap( )) { OutText(“ mov edx, DWORD PTR [esi+%u]”, fdwoff+0); OutText(“ mov eax, DWORD PTR [esi+%u]”, fdwoff+4); OutText(“ bswap edx”); OutText(“ bswap eax”); } else { OutText(“ mov eax, DWORD PTR [esi+%u]”, fdwoff+0); OutText(“ mov edx, DWORD PTR [esi+%u]”, fdwoff+4); } return; } } // // Unoptimized cases removed...field does not start on a byte boundary // } - The code in Table 3 below uses the code from Table 2 to generate the code in Table 4 below, showing all 36 possible values with a length that is a multiple of 8 bits and is aligned on an 8-bit boundary in memory within a 64 bit field. The code in Table 3 creates a series of fields containing field values, via the nested loops (fshr, fshl). The field values are used as input to the code in Table 2, to generate the output of Table 4.
-
TABLE 3 Routine to Create Sample Fields to Generate Code For for (int r=56; r>=0; r−=8) // fshr { for (int l=r; l>=0; l−=8) // fshl { // // Construct a field entity of length (64−r) // with its first bit located “l” bits from the left of a 64 bit field // and with its last bit located “l” − (64 − “r”) bits from the right of a 64 bit field // field ff(“IHL”, // field name l, // bits to shift left r, // bits to shift right 64−r, // field bitsize 0, // pointer to any associated lookup class 0 // pointer to any associated statistics class ); ff.GenerateFieldExtractionCode(&p, TRUE); } } // // Save generated text to file “c:\pa_mdi\ASM” // FILE *TxtFile; if ((TxtFile = fopen(“c:\\pa_mdi\\ASM”, “wt”) )!= NULL) { fwrite(codebuf, 1, strlen(codebuf), TxtFile); fclose(TxtFile); } - The generated code is presented in Table 4 below. The field value extraction code shown below is code that, when executed on input data, will pull out a field value from within that input data, according to the field length and field location within the data as specified by the generated code. The comments in the code in Table 4 uses the following nomenclature for the 36 generated code examples:
-
;..........<<48 >>56::8 // Shift left 48 bits; Then shift Right 56 bits to produce ;..........0x000000000000FF00 // an 8 bit value right justified in a 64 bit field - For example, the above code comment will extract an 8-bit value, located at bits 11-15, from a 64-bit field.
- Note that [esi+4294967295] is equivalent to [esi−1] in the generated code samples of Table 4. Also note the bswap instruction changes the order of bytes in a 32 bit word (4 bytes) from 4321 to 1234 in the referenced register and is an instruction provided by the x86 architecture. Also note that byte order that data is transmitted on most networks is backwards from the order that the x86 architecture stores it in memory. This makes the bswap instruction necessary in instances where the byte order is important, such as when a filter criteria specifies a range of values. In the case of a filter criteria that only specifies a single value, the comparison value can be swapped as the code is generated to eliminate the bswap instruction.
-
TABLE 4 Example Generated Field Value Extraction Code for Common Cases // // Generated code for 36 possible aligned cases // ; ;..........<<56 >>56::8 ;..........0x00000000000000FF xor edx, edx xor eax, eax mov al, BYTE PTR [esi+7] ; ;..........<<48 >>56::8 ;..........0x000000000000FF00 ; xor edx, edx xor eax, eax mov al, BYTE PTR [esi+6] ; ;..........<<40 >>56::8 ;..........0x0000000000FF0000 ; xor edx, edx xor eax, eax mov al, BYTE PTR [esi+5] ; ;..........<<32 >>56::8 ;..........0x00000000FF000000 ; xor edx, edx xor eax, eax mov al, BYTE PTR [esi+4] ; ;..........<<24 >>56::8 ;..........0x000000FF00000000 ; xor edx, edx xor eax, eax mov al, BYTE PTR [esi+3] ; ;..........<<16 >>56::8 ;..........0x0000FF0000000000 ; xor edx, edx xor eax, eax mov al, BYTE PTR [esi+2] ; ;..........<<8 >>56::8 ;..........0x00FF000000000000 ; xor edx, edx xor eax, eax mov al, BYTE PTR [esi+1] ; ;..........<<0 >>56::8 ;..........0xFF00000000000000 ; xor edx, edx xor eax, eax mov al, BYTE PTR [esi+0] ; ;..........<<48 >>48::16 ;..........0x000000000000FFFF ; xor edx, edx xor eax, eax mov ah, BYTE PTR [esi+6] mov al, BYTE PTR [esi+7] ; ;..........<<40 >>48::16 ;..........0x0000000000FFFF00 ; xor edx, edx xor eax, eax mov ah, BYTE PTR [esi+5] mov al, BYTE PTR [esi+6] ; ;..........<<32 >>48::16 ;..........0x00000000FFFF0000 ; xor edx, edx xor eax, eax mov ah, BYTE PTR [esi+4] mov al, BYTE PTR [esi+5] ; ;..........<<24 >>48::16 ;..........0x000000FFFF000000 ; xor edx, edx xor eax, eax mov ah, BYTE PTR [esi+3] mov al, BYTE PTR [esi+4] ; ;..........<<16 >>48::16 ;..........0x0000FFFF00000000 ; xor edx, edx xor eax, eax mov ah, BYTE PTR [esi+2] mov al, BYTE PTR [esi+3] ; ;..........<<8 >>48::16 ;..........0x00FFFF0000000000 ; xor edx, edx xor eax, eax mov ah, BYTE PTR [esi+1] mov al, BYTE PTR [esi+2] ; ;..........<<0 >>48::16 ;..........0xFFFF000000000000 ; xor edx, edx xor eax, eax mov ah, BYTE PTR [esi+0] mov al, BYTE PTR [esi+1] ; ;..........<<40 >>40::24 ;..........0x0000000000FFFFFF ; xor edx, edx mov eax, DWORD PTR [esi+4] bswap eax and eax, DWORD PTR 000ffffffH ; ;..........<<32 >>40::24 ;..........0x00000000FFFFFF00 ; xor edx, edx mov eax, DWORD PTR [esi+3] bswap eax and eax, DWORD PTR 000ffffffH ; ;..........<<24 >>40::24 ;..........0x000000FFFFFF0000 ; xor edx, edx mov eax, DWORD PTR [esi+2] bswap eax and eax, DWORD PTR 000ffffffH ; ;..........<<16 >>40::24 ;..........0x0000FFFFFF000000 ; xor edx, edx mov eax, DWORD PTR [esi+1] bswap eax and eax, DWORD PTR 000ffffffH ; ;..........<<8 >>40::24 ;..........0x00FFFFFF00000000 ; xor edx, edx mov eax, DWORD PTR [esi+0] bswap eax and eax, DWORD PTR 000ffffffH ; ;..........<<0 >>40::24 ;..........0xFFFFFF0000000000 ; xor edx, edx mov eax, DWORD PTR [esi+4294967295] bswap eax and eax, DWORD PTR 000ffffffH ; ;..........<<32 >>32::32 ;..........0x00000000FFFFFFFF ; xor edx, edx mov eax, DWORD PTR [esi+4] bswap eax ; ;..........<<24 > 32::32 ;..........0x000000FFFFFFFF00 ; xor edx, edx mov eax, DWORD PTR [esi+3] bswap eax ; ;..........<<16 >>32::32 ;..........0x0000FFFFFFFF0000 ; xor edx, edx mov eax, DWORD PTR [esi+2] bswap eax ; ;..........<<8 >>32::32 ;..........0x00FFFFFFFF000000 ; xor edx, edx mov eax, DWORD PTR [esi+1] bswap eax ; ;..........<<0 >>32::32 ;..........0xFFFFFFFF00000000 ; xor edx, edx mov eax, DWORD PTR [esi+0] bswap eax ; ;..........<<24 >>24::40 ;..........0x000000FFFFFFFFFF ; xor edx, edx mov eax, DWORD PTR [esi+4] mov dl, BYTE PTR [esi+3] bswap eax ; ;..........<<16 >>24::40 ;..........0x0000FFFFFFFFFF00 ; xor edx, edx mov eax, DWORD PTR [esi+3] mov dl, BYTE PTR [esi+2] bswap eax ; ;..........<<8 >>24::40 ;..........0x00FFFFFFFFFF0000 ; xor edx, edx mov eax, DWORD PTR [esi+2] mov dl, BYTE PTR [esi+1] bswap eax ; ;..........<<0 >>24::40 ;..........0xFFFFFFFFFF000000 ; xor edx, edx mov eax, DWORD PTR [esi+1] mov dl, BYTE PTR [esi+0] bswap eax ; ;..........<<16 >>16::48 ;..........0x0000FFFFFFFFFFFF ; xor edx, edx mov eax, DWORD PTR [esi+4] mov dl, BYTE PTR [esi+3] mov dh, BYTE PTR [esi+2] bswap eax ; ;..........<<8 >>16::48 ;..........0x00FFFFFFFFFFFF00 ; xor edx, edx mov eax, DWORD PTR [esi+3] mov dl, BYTE PTR [esi+2] mov dh, BYTE PTR [esi+1] bswap eax ; ;..........<<0 >>16::48 ;..........0xFFFFFFFFFFFF0000 ; xor edx, edx mov eax, DWORD PTR [esi+2] mov dl, BYTE PTR [esi+1] mov dh, BYTE PTR [esi+0] bswap eax ; ;..........<<8 >>8::56 ;..........0x00FFFFFFFFFFFFFF ; mov edx, DWORD PTR [esi+0] mov eax, DWORD PTR [esi+4] bswap edx bswap eax and edx, DWORD PTR 000ffffffH ; ;..........<<0 >>8::56 ;..........0xFFFFFFFFFFFFFF00 ; mov edx, DWORD PTR [esi+4294967295] mov eax, DWORD PTR [esi+3] bswap edx bswap eax and edx, DWORD PTR 000ffffffH ; ;..........<<0 >>0::64 ;..........0xFFFFFFFFFFFFFFFF ; mov edx, DWORD PTR [esi+0] mov eax, DWORD PTR [esi+4] bswap edx bswap eax - As a second example of a code generation routine, the routine in Table 5 below generates code that adds the value extracted from a field (contained in edx:eax) to a global variable. If the field length is <=32 bits, it generates code to skip the second add if there is no carry bit after the first add. This can be seen in the different code generated for Table 8 and Table 9. This is an advantage because one add instruction is faster than two add instructions. Especially since the first add instruction pairs with the jnc instruction and is executed in one processor clock cycle.
-
TABLE 5 Standard Code Generation Routine to Add EDX:EAX to a Memory Location // // Perform *value += edx:eax(extracted field value); // void Add64To64BitMemValue(U64 *sum, protocol *p, field *f) {// 3/2/8 or 2/3/6 insts/clocks/bytes OutText(“ add DWORD PTR %09xH, eax”, (U32)sum); if (f->bitlen( ) <= 32) // Value in edx:eax <= 32 bits (i.e. edx == 0) so done if no carry OutText(“ jnc NC%u”, NextLabelNumber); OutText(“ adc DWORD PTR %09xH, edx”, (U32)((char *)sum + 4)); if (f->bitlen( ) <= 32) // Value in edx:eax <= 32 bits (i.e. edx == 0) so done if no carry OutText(“NC%u:”, NextLabelNumber++); } - The class definition in Table 6 is derived from the stats class defined in U.S. Pat. No. 5,793,954, which is incorporated by reference herein. This class definition uses the code routine in Table 5 above. Only the portions required to illustrate the code generation examples are included.
-
TABLE 6 Class Definition Showing Collect and Generate Collect Code Routines class sum_stats: public stats { public: // // Add field value to sum of previous values // void collect (U64 oldval, U64 newval) { sum += oldval; } // // Inputs: edx:eax = extracted field value // Outputs: sum += extracted field value // Registers Modified: None // void sum_stats::GenerateStatsCollectCode(protocol *p, field *f) { OutText(“”, 0, 0, p, f, “- >sum_stats::collect(edx:eax)”); // Output protocol->field-> sum_stats::collect(edx:eax) Add64To64BitMemValue(&sum, p, f); } // // Data Representation protected: U64 sum; // Pointer to U64 variable for summing U32 row; // for displays }; - The code in Table 7 below was used as input data, to generate the examples shown in Tables 8 and 9.
-
TABLE 7 Input Data for Code Generation Routines sum_stats sum_tst(“codegen”); protocol p(“IP_V4”, “IPFILE”); CPa_mdiApp::CPa_mdiApp( ) { codebuf[0] = 0; field fff(“IHL”, 0, 24, 40, 0, 0); // define 40 bit field at (<<0 >>24) 0xFFFFFFFFFF000000 sum_tst.GenerateStatsCollectCode(&p, &fff); field ffff(“IHL”, 0, 32, 32, 0, 0);// define 32 bit field at (<<0 >>32)0xFFFFFFFF00000000 sum_tst.GenerateStatsCollectCode(&p, &ffff); } -
TABLE 8 Generated Code for an Extracted Field Value of Less Than or Equal to 32 Bits ; ; (IP)->(IHL)->sum_stats::collect(edx:eax) for <= 32 bit values ; add DWORD PTR 0008875c0H, eax jnc NC0 adc DWORD PTR 0008875c4H, edx NC0: -
TABLE 9 Generated Code for an Extracted Field Value of Greater Than 32 Bits ; ; (IP)->(IHL)->sum_stats::collect(edx:eax) for > 32 bit values ; add DWORD PTR 0008875c0H, eax adc DWORD PTR 0008875c4H, edx - The following tables present the code generation routines, sample input data for the code generation routines, and resulting generated code output, used to generate code for a data filtering function. This data filtering function is a further example of the sort of functions that code can be generated for, according to an embodiment of the invention. Data filtering is one of the functions frequently performed by protocol analyzers, such as the configurable protocol analyzers discussed in the incorporated US Patent references mentioned above. Those skilled in the art will appreciate that all of the functions of a protocol analyzer may be implemented in code generation routines of an embodiment of the invention. Thus, an entire protocol analyzer, specially configured to suit a particular design, may be created by applying a user-configured protocol as an input to a protocol parsing engine that has been configured with a protocol or protocols as discussed herein.
-
TABLE 10 Class Definitions for Code Generation Routines for Filtering Function //////////////////////////////////////////////////////////////// //////////////// // Filter Channel NEW Criteria Class // Consists of: // Index - Index # of this filter channel criteria // ChPtr - Pointer back to filter channel of this criteria // Ranges - Pointer to lookup class containing criteria values // Ptl - Pointer to associated protocol class // Fld - Pointer to associated protocol field class // pi - Ptl's index in stack for Configuration/Display purposes only // fi - Fld's index in protocol for Configuration/Display purposes only //////////////////////////////////////////////////////////////// //////////////// class newcrit // Filter Channel Criteria Class { public: // // Constructor // newcrit(U32 Sz=MAX_FILTERS) : Index(0), MaxRanges(20), NumRanges(0), PtlIdx(0), FldIdx(0), ChanPtr(0), PtlPtr(0), FldPtr(0), NextCrit(0) { /*Ranges = new verify[MaxRanges = max(2, Sz)];*/ } // // Overloaded Indexing Operator // inline verify * operator[ ] (U32 index) { index = min(index, MaxRanges−1); NumRanges = max(NumRanges, index+1); return(&Ranges[index]); } // // Member Functions // // void UpdateRangeAt(U32 Idx, U32 NxtIdx, U64 minval, U64 maxval, U32 OkBits, newchannel *c, protocol *p, field *f) { verify *rPtr= &Ranges[Idx]; NumRanges = max(NumRanges, Idx+1); rPtr->prot = (protocol *)FILTER_FRAME; rPtr->nxtidx = NxtIdx; rPtr->minval = minval; rPtr->maxval = maxval; rPtr->okbits = OkBits; rPtr->show = TRUE; ChanPtr = c; PtlPtr = p; FldPtr = f; // NextCrit = ?; } /////////////////////////////////////////////////////////////// // Data Field Access Routines /////////////////////////////////////////////////////////////// // U32 critIndex( ) const { return Index; } void critIndex(U32 i) { Index = i; } // U32 critMaxRanges( ) const { return MaxRanges; } void critMaxRanges(U32 i) { MaxRanges = i; } // U32 critNumRanges( ) const { return NumRanges; } void critNumRanges(U32 i) { NumRanges = i; } // U32 critPtlIdx( ) const { return PtlIdx; } void critPtlIdx(U32 i) { PtlIdx = i; } // U32 critFldIdx( ) const { return FldIdx; } void critFldIdx(U32 i) { FldIdx = i; } // verify *critRanges( ) { return &Ranges[0]; } // void critRanges(verify *p) { Ranges = p; } // newchannel *critChanPtr( ) const { return ChanPtr; } void critChanPtr(newchannel *p) { ChanPtr = p; } // protocol *critPtlPtr( ) const { return PtlPtr; } void critPtlPtr(protocol *p) { PtlPtr = p; } // field *critFldPtr( ) const { return FldPtr; } void critFldPtr(field *p) { FldPtr = p; } // newcrit *critNextCrit( ) const { return NextCrit; } void critNextCrit(newcrit *p) { NextCrit = p; } // // //////////////////////////////////////////////////////////////// /////////////// private: U32 Index; // Zero-based index number for this filter criteria U32 MaxRanges; // Size of currently allocated array U32 NumRanges; // Number of filled-in ranges U32 PtlIdx; // protocol's index in stack for Configuration/Display purposes only U32 FldIdx; // field's index in protocol for Configuration/Display purposes only verify Ranges[20]; // Pointer to an Array of valid ranges newchannel *ChanPtr; // Pointer to Associated Filter Class protocol *PtlPtr; // Required for Configuration/Display purposes only field *FldPtr; // Required for Configuration/Display purposes only newcrit *NextCrit; // Pointer to next criteria in chain (if any) }; // //////////////////////////////////////////////////////////////// ///////////////////////////////// // // //////////////////////////////////////////////////////////////// ///////////////////////////////// // class newchannel { public: // // Constructors // newchannel(char *fname=“”, char *cname=“”, U32 Sz=MAX_FILTERS) : FramesAccepted(0), FrameBitsAccepted(0), MaxCrits(20), NumCrits(0), NextCriteriaIndex(0), row(0), Enable_flag(1), ChannelName(0), FiltFileName(0) { // Criteria = new newcrit[MaxCrits = max(2, Sz)]; // if (fname != (char *)NULL && (FiltFileName = new char [strlen(fname)+1]) != (char *)NULL) strcpy(FiltFileName, fname); // if (cname != (char *)NULL && (ChannelName = new char [strlen(cname)+1]) != (char *)NULL) strcpy(ChannelName, cname); } // // Copy constructor !!! // newchannel(const newchannel& c); // // Overloaded Indexing Operator // inline newcrit * operator[ ] (U32 index) { index = min(index, MaxCrits−1); NumCrits = max(NumCrits, index+1); return(&Criteria[index]); } inline const newcrit * operator[ ] (U32 index) const { return(&Criteria[min(index, MaxCrits−1)]); } // // Member Functions // inline U32 chanNumCrits( ) const { return NumCrits; } inline void DisableChannel( ) { NextCriteriaIndex = NumCrits; } inline void Update(verify *v, U32 intf); // inline U32 NciValue( ) { return(NextCriteriaIndex); } inline void NciValue(U32 value) { NextCriteriaIndex = value; } // char *cname( ) const { return ChannelName; } void cname(char *cname) { if (ChannelName != (char *)NULL) { delete [ ]ChannelName; ChannelName = (char *)NULL; } if (cname != (char *)NULL && (ChannelName = new char [strlen(cname)+1]) != (char *)NULL) strcpy(ChannelName, cname); } // char *fname( ) const { return FiltFileName; } void fname(char *fname) { if (FiltFileName != (char *)NULL) { delete [ ]FiltFileName; FiltFileName = (char *)NULL; } if (fname != (char *)NULL && (FiltFileName = new char [strlen(fname)+1]) != (char *)NULL) strcpy(FiltFileName, fname); } ////////////////////////////////////////////// // private: U64 FramesAccepted; // Number of Frames Accepted by this channel U64 FrameBitsAccepted; // Number of Bits Accepted by this channel U32 MaxCrits; // Size of currently allocated array U32 NumCrits; // Number of filled-in ranges U32 NextCriteriaIndex; // Index of next channel criteria to be applied U32 row; // for stats displays U32 Enable_flag; // 1=Rx, 3=Disabled newcrit Criteria[20]; // Pointer to array of channel criteria char *ChannelName; // Pointer to name of channel char *FiltFileName; // Filter File Name }; // //////////////////////////////////////////////////////////////// ///////////////////////////////// // class NewFilters { public: // // Constructors // NewFilters(U32 Sz=MAX_FILTERS): MaxChans(20), NumChans(0), FilterStat(PASS_FRAME) { // Chans = new newchannel[MaxChans = max(2, Sz)]; } // // Overloaded Subscript Operator // inline newchannel* operator[ ] (U32 index) { index = min(index, MaxChans−1); NumChans = max(NumChans, index+1); return(&Chans[index]); } inline const newchannel* operator[ ] (U32 index) const { return(&Chans[min(index, MaxChans−1)]); } // // Member Functions // // Number of Configured Filters U32 entries( ) const { return(NumChans); } void clear( ) { NumChans = 0; } // // Chans pointer newchannel *ChansPtr(void) { return(Chans); } // // U32 FrameFilterStatus( ) const { return(FilterStat); } void FrameFilterStatus(U32 Status) { FilterStat = Status; } // // Generate code for this filter channel void GenerateFilterCode(void); // //////////////////////////////////////////////////////////////// /////////////// private: U32 MaxChans; // Size of currently allocated array U32 NumChans; // Number of filled-in ranges U32 FilterStat; newchannel Chans[20]; // Pointer to Configured Filters Table }; -
TABLE 11 Code Generation Routines for Filtering Function void protocol::GenerateFilterHeaderLenCode( ) { U32 HeaderLen=0; OutText(“ ; Add Number of any optional bytes in after processing %s”, (U32)protocol_name); switch(hlfield->protlen( )) { // Compute Header Length Here case 3: HeaderLen += hlfield->bitlen( ); case 2: HeaderLen += (hlfield->offset( ) * BITS_PER_BYTE); case 1: switch(hlfield->hdlen( )/BITS_PER_BYTE) { case 0: break; case 1: case 2: case 4: case 8: OutText(“ lea ecx, DWORD PTR [ecx+eax*%u−%u]”, hlfield->hdlen( )/8, num_bits/8 − HeaderLen); break; default:OutText(“ mov edx, OFFSET FLAT %u”, hlfield->hdlen( )/8, num_bits/8); OutText(“ imul eax, edx”); if ((HeaderLen−num_bits/8) != 0) OutText(“ add eax, %u”, HeaderLen−num_bits/8); break; } break; default:OutText(“; ERROR!!!!: (%s)->GenerateHeaderLenCode( ): ->protlen( ) is %u”, (U32)protocol_name, hlfield->protlen( )); return; // This is an illegal case } } // // // static void OutputCompare(char *p, char *f, char *op, U32 Idx, U32 RngIdx, U32 Sz, U64 MinV) { char *reg, *xH, *ldr, sptr[256]; U64 V; switch(Sz) { case 1: reg = “al”; xH =“ BYTE PTR %03xH ” ; V = (U8)MinV; break; case 2: reg = “eax”; xH = “DWORD PTR %05xH ” ; V = bswap((U16)MinV); break; case 3: reg = “eax”; xH = “DWORD PTR %09xH” ; V = wswap((U32)MinV); break; case 4: reg = “eax”; xH = “DWORD PTR %09xH” ; V = wswap((U32)MinV); break; case 5: case 6: case 7: case 8: break; } if (Idx == 0) { if (RngIdx == 0) ldr = “if (”; } else ldr = “ ”; // sprintf(sptr, “ cmp %s, %s ; %s%s->%s == 0x%X%s”, reg, xH, ldr, p, f, (U32)MinV, op); OutText(sptr, (U32)V); } // // // static void OutputCompareMinV(char *p, char *f, char *op, U32 Idx, U32 RngIdx, U32 Sz, U64 MinV) { char *reg, *xH, *ldr, sptr[256]; switch(Sz) { case 1: reg = “al”; xH =“ BYTE PTR %03xH ”; (U8)MinV; break; case 2: reg = “eax”; xH = “DWORD PTR %05xH ” ; (U16)MinV; break; case 3: reg = “eax”; xH = “DWORD PTR %09xH” ; (U32)MinV; break; case 4: reg = “eax”; xH = “DWORD PTR %09xH” ; (U32)MinV; break; case 5: case 6: case 7: case 8: break; } ldr = “ (”; if (Idx == 0) { if (RngIdx == 0) ldr = “if ((”; } sprintf(sptr, “ cmp %s, %s ; %s%s->%s >= 0x%X%s”, reg, xH, ldr, p, f, (U32)MinV, op); OutText(sptr, (U32)MinV); } // // // static void OutputCompareMaxV(char *p, char *f, char *op, U32 Idx, U32 Sz, U64 MaxV) { char *reg, *xH, *ldr, sptr[256]; switch(Sz) { case 1: reg = “al”; xH =“ BYTE PTR %03xH ”; (U8)MaxV; break; case 2: reg = “eax”; xH = “DWORD PTR %05xH ” ; (U16)MaxV; break; case 3: reg = “eax”; xH = “DWORD PTR %09xH” ; (U32)MaxV; break; case 4: reg = “eax”; xH = “DWORD PTR %09xH” ; (U32)MaxV; break; case 5: case 6: case 7: case 8: break; } ldr = “)”; sprintf(sptr, “ cmp %s, %s ; %s%s->%s <= 0x%X%s%s”, reg, xH, “ ”, p, f, (U32)MaxV, ldr, op); OutText(sptr, (U32)MaxV); } // // Generates code (Routine) that implements all configured filters on an interface // The generated code expects the following inputs: // esi - ParsePtr // The generated code produces the following outputs: // eax - updated frame filter status // // // THE FOLLOWING CODE ASSUMES FILTER CRITERIA ARE IN MONOTONICALLY INCREASING OFFSET ORDER (i.e. sorted by protocol, field) // void NewFilters::GenerateFilterCode(void) { char *ldr; OutText(“;”); OutText(“; Generated Filtering Code”); OutText(“;”); OutText(“ xor edx, edx ; Bits correspond to Filter/Receive Channels”); for (U32 ChannelIdx=0; ChannelIdx<NewFilts->entries( ); ChannelIdx++) { // For each filter channel U32 OptionalOffset = 0; U32 FixedOffset = 0; U64 ValueMask = 0xffffffffffffffff; newchannel *CurrChannel = NewFilts->operator[ ](ChannelIdx); protocol *OldProt, *CurrProt; OutText (“;;;;;;;;;;;;;;;;;;; FilterChannel%u ;;;;;;;;;;;;;;;;;”, ChannelIdx); OldProt = CurrChannel->operator[ ](0)->critPtlPtr( ); for (U32 CriteriaIdx=0; CriteriaIdx<CurrChannel- >chanNumCrits( ); CriteriaIdx++) { // For each criteria in each filter channel U32 RangeIdx; newcrit *CurrCriteria = CurrChannel- >operator[ ](CriteriaIdx); field *CurrField = CurrCriteria->critFldPtr( ); CurrProt = CurrCriteria->critPtlptr( ); // // Add standard protocol header length to FixedOffset if this is the last field in the current protocol // if (CurrProt != OldProt) FixedOffset += (OldProt->numbits( )/8); // // Create Indexed Label for Each Criteria Processed // OutText (“Chan%uCrit%u:”, ChannelIdx, CriteriaIdx); for (RangeIdx=0; RangeIdx<CurrCriteria->critNumRanges( ); RangeIdx++) { // For each range in each criteria in each filter channel verify *CurrRange = CurrCriteria- >operator[ ](RangeIdx); U64 minvalue=CurrRange->minval, maxvalue=CurrRange- >maxval; // // Is criteria value a range or single value? // U32 HasRanges = (minvalue != maxvalue); // // Generate Range Comparison Code // U32 Size = CurrField- >GenerateFilterExtractionCode(HasRanges, ValueMask, FixedOffset, OptionalOffset); OutText(“Chan%uCrit%uRange%u:”, ChannelIdx, CriteriaIdx, (protocol *)RangeIdx); if (HasRanges == FALSE) { // Single value comparison if ((U32)CurrRange->prot == FILTER_FRAME) { if (CurrRange->nxtidx != (CriteriaIdx+1)) { // This an “OR” condition ... and the filter is a match if (((RangeIdx+1) == CurrCriteria- >critNumRanges( )) &&((CriteriaIdx+1) == CurrChannel- >chanNumCrits( ))) ldr = “)”; else ldr = “ ||”; OutputCompare(CurrProt->pname( ), CurrField->name( ), ldr, CriteriaIdx, RangeIdx, Size, minvalue); if (CurrRange->nxtidx == CurrChannel- >chanNumCrits( )) // Filter Channel Satisfied here OutText“ je Chan%uMatch”, ChannelIdx); else OutText(“ je Chan%uCrit%uRange%u”, ChannelIdx, CurrRange->nxtidx); } else { // This is an “AND” condition if (((RangeIdx+1) == CurrCriteria- >critNumRanges( )) &&((CriteriaIdx+1) == CurrChannel- >chanNumCrits( ))) ldr = “)”; else ldr = “ &&”; if ((RangeIdx+1) == CurrCriteria- >critNumRanges( )) // Last Range in Criteria ? { OutputCompare(CurrProt->pname( ), CurrField->name( ), ldr, CriteriaIdx, RangeIdx, Size, minvalue); OutText(“ jne Chan%uNoMatch”, ChannelIdx); } else { OutputCompare(CurrProt->pname( ), CurrField->name( ), ldr, CriteriaIdx, RangeIdx, Size, minvalue); OutText(“ je Chan%uCrit%uRange%u”, ChannelIdx, CriteriaIdx, (protocol *)(RangeIdx+1)); } } } else // PASS_FRAME { if (CurrRange->nxtidx != (CriteriaIdx+1)) { // This an “OR” condition ... and the filter is a match OutputCompare(CurrProt->pname( ), CurrField->name( ), “ &&”, CriteriaIdx, RangeIdx, Size, minvalue); OutText(“ je Chan%uMatch”, ChannelIdx); } else { // This is an “AND” condition ... OutputCompare(CurrProt->pname( ), CurrField->name( ), “ &&”, CriteriaIdx, RangeIdx, Size, minvalue); OutText(“ jne Chan%uFilter”, ChannelIdx+1); } } } // Single value comparison else { // Range of Values if ((U32)CurrRange->prot == FILTER_FRAME) { // FILTER_FRAME if (CurrRange->nxtidx != (CriteriaIdx+1)) { // This an “OR” condition ... and the filter is a match if (((RangeIdx+1) == CurrCriteria- >critNumRanges( )) &&((CriteriaIdx+1) == CurrChannel- >chanNumCrits( ))) ldr = “)”; else ldr = “ ||”; OutputCompareMinV(CurrProt->pname( ), CurrField->name( ), “ &&”, CriteriaIdx, RangeIdx, Size, minvalue); OutText(“ jb Chan%uCrit%uRange%u”, ChannelIdx, CriteriaIdx, (protocol *)(RangeIdx+1)); OutputCompareMaxV(CurrProt->pname( ), CurrField->name( ), “ ||”, CriteriaIdx, Size, maxvalue); OutText(“ jbe Chan%uMatch”, ChannelIdx); } else { // This is an “AND” condition ... if (((RangeIdx+1) == CurrCriteria- >critNumRanges( )) &&((CriteriaIdx+1) == CurrChannel- >chanNumCrits( ))) ldr = “)”; else ldr = “ &&”; OutputCompareMinV(CurrProt->pname( ), CurrField->name( ), “ &&”, CriteriaIdx, RangeIdx, Size, minvalue); OutText(“ jb Chan%uNoMatch”, ChannelIdx); OutputCompareMaxV(CurrProt->pname( ), CurrField->name( ), “ &&”, CriteriaIdx, Size, maxvalue); OutText(“ ja Chan%uNoMatch”, ChannelIdx); } } // FILTER_FRAME else { // PASS_FRAME if (CurrRange->nxtidx != (CriteriaIdx+1)) { // This an “OR” condition ... and the filter is a match OutputCompareMinV(CurrProt->pname( ), CurrField->name( ), “ &&”, CriteriaIdx, RangeIdx, Size, minvalue); OutText(“ jb Chan%uNoMatch”, ChannelIdx); } else { // This is an “AND” condition ... OutputCompareMinV(CurrProt->pname( ), CurrField->name( ), “ &&”, CriteriaIdx, RangeIdx, Size, minvalue); OutText(“ jb Chan%uCrit%uRange%u”, ChannelIdx, CriteriaIdx, (protocol *)(RangeIdx+1)); } if (CurrRange->nxtidx != (CriteriaIdx+1)) { OutputCompareMaxV(CurrProt->pname( ), CurrField->name( ), “ ||”, CriteriaIdx, Size, maxvalue); OutText( “jbe Chan%uMatch”, ChannelIdx); } else { OutputCompareMaxV(CurrProt->pname( ), CurrField->name( ), “ ||”, CriteriaIdx, Size, maxvalue); OutText( “ja Filter%u”, ChannelIdx+1); } } // PASS_FRAME } // Range of Values } // For each range in each criteria in each filter channel // // Look for every protocol with a Header Length field that may indicate optional bytes // if (CurrProt->HlField( )) { if (CriteriaIdx<(CurrChannel->chanNumCrits( )−1)) { OutText(“ ; Extract Header Length Field in %s”, (U32)CurrProt->pname( )); CurrProt->HlField( )- >GenerateFilterExtractionCode(CurrProt, FALSE); CurrProt->GenerateFilterHeaderLenCode( ); } OptionalOffset = TRUE; } // // Save previous protocol so can add fixed header length to filtering process // OldProt = CurrProt; } // For each criteria in each filter channel // // Generate Channel Index Return Value // OutText(“Chan%uMatch:”, ChannelIdx); OutText(“ or edx, %09xH ; Index of Channel/Filter Number”, 1<<ChannelIdx); // Frame Status that doesn't match this filter // if (USER WANTS 1st MATCH) // OutText(“// jmp FilteringDone”); OutText(“Chan%uNoMatch:”, ChannelIdx); // } // For each filter channel // OutText(“ mov eax, edx ; Bits correspond to Filter/Receive Channels”); } - The code in Table 12 below was used as input data to generate the example executable code in Table 14 below:
-
TABLE 12 Input Data for Code Generation Routines for Filtering Function NewFilters NewFilter, *NewFilts = &NewFilter; p.protname(“ETHERII”); e = ListPtr->find(&p)->prot( ); p.protname(“IP_V4”); i = ListPtr->find(&p)->prot( ); p.protname(“TCP”); t = ListPtr->find(&p)->prot( ); p.protname(“LLC1”); l1 = ListPtr->find(&p)->prot( ); p.protname(“LLC2”); l2 = ListPtr->find(&p)->prot( ); p.protname(“pether”); m = ListPtr->find(&p)->prot( ); newchannel *Chnl0 = NewFilts->operator[ ](0), *Chnl1 = NewFilts- >operator[ ](1), *Chnl2 = NewFilts->operator[ ](2); //if (e->typ == 0x0800 && IP->Port == 0x06 && TCP->SrcPort == 0x0017) Chnl0->operator[ ](0)->UpdateRangeAt(0, 1, 0x00000800, 0x00000800, ALLNUMBERS, Chnl0, e, e->operator[ ](2)); Chnl0->operator[ ](1)->UpdateRangeAt(0, 2, 0x00000006, 0x00000006, ALLNUMBERS, Chnl0, i, i->operator[ ](8)); Chnl0->operator[ ](2)->UpdateRangeAt(0, 3, 0x00000017, 0x00000017, ALLNUMBERS, Chnl0, t, t->operator[ ](0)); //if (e->typ == 0x0800 || ((e->typ >= 0x002e && e->typ <= 0x05dc) && ((l1->L1 >= 0x06060300 && l1->L1 <= 0x060603ff) || ((l1->L1 == 0xAAAA0300) && (l2->L1 == 0x00000800))))) Chnl1->operator[ ](0)->UpdateRangeAt(0, 3, 0x00000800, 0x00000800, ALLNUMBERS, Chnl1, e, e->operator[ ](2)); Chnl1->operator[ ](0)->UpdateRangeAt(1, 1, 0x0000002e, 0x0000005dc, ALLNUMBERS, Chnl1, e, e->operator[ ](2)); Chnl1->operator[ ](1)->UpdateRangeAt(0, 3, 0x06060300, 0x060603ff, ALLNUMBERS, Chnl1, l1, l1->operator[ ](0)); Chnl1->operator[ ](1)->UpdateRangeAt(1, 2, 0xaaaa0300, 0xaaaa0300, ALLNUMBERS, Chnl1, l1, l1->operator[ ](0)); Chnl1->operator[ ](2)->UpdateRangeAt(0, 3, 0x00000800, 0x00000800, ALLNUMBERS, Chnl1, l2, l2->operator[ ](0)); //if ((e->daddr[2] == 0x1122 || e->saddr[2] == 0x0049) && e- >typ == 0x0800) Chnl2->operator[ ](0)->UpdateRangeAt(0, 2, 0x00001122, 0x00001122, ALLNUMBERS, Chnl2, m, m->operator[ ](2)); Chnl2->operator[ ](1)->UpdateRangeAt(0, 2, 0x00000049, 0x00000049, ALLNUMBERS, Chnl2, m, m->operator[ ](5)); Chnl2->operator[ ](2)->UpdateRangeAt(0, 3, 0x00000800, 0x00000800, ALLNUMBERS, Chnl2, m, m->operator[ ](6)); - The code of Table 12 above translates to the more readable table of filter channels, criteria, and ranges for each example, in Table 13 below.
-
TABLE 13 Input Data for Code Generation Routines for Filtering Function, Table Form Nxt Even/ Curr Criteria Range Criteria Min Max Odd/All Protocol Curr Field Channel Idx Idx Idx Idx Value Value Bits Ptr Ptr // Example 1 (Channel 0) 0 0 0 1 0x800 0x800 All ETHERII type 0 1 0 2 0x6 0x6 All IP_V4 Protocol 0 2 0 3 0x17 0x17 All TCP SourcePort // Example 2 (Channel 1) 1 0 3 0 0x800 0x800 All ETHERII type 1 0 1 1 0x2e 0x5dc All ETHERII type 1 1 0 3 0x060 0x060 All LLC1 LLC1 60300 603ff 1 1 1 2 0xaaaa 0xaaaa All LLC1 LLC1 0300 0300 1 2 0 3 0x800 0x800 All LLC2 LLC2 // Example 3 (channel 2) 2 0 0 2 0x1122 0x1122 All pether Dadr2 2 1 0 2 0x49 0x49 All pether Sadr2 2 2 0 3 0x800 0x800 All pether TypeLen - In this example, one of the advantages of using the protocol description to generate filtering code is apparent. The length of the IP_V4 protocol header is variable (20 bytes are always there and up to 40 bytes of options may be added in 4 byte increments). This means that there are 11 possible header sizes (20, 24, 28, . . . 60). The generated code automatically accounts for this possibility by extracting the actual header length from the header contained in the input data, and adding it to all subsequent filtering checks. To do this filtering the more traditional way with content addressable memory (CAM) would require the user to enter all eleven possibilities into the CAMs. The code generation routines discussed above can be altered to issue commands to automatically program the CAMs with the required values and masks after the filter has been configured by specifying protocols, fields, and (un)acceptable ranges (criteria) of values. This is intuitively more obvious and easier for a typical user to use. The code generated by applying the input data of Tables 12 and 13 to the code generation routines of Table 11 are shown below in Tables 14-16.
-
TABLE 14 Generated Code for Filtering Function, Example 1 ; ; Generated Filtering Code ; xor edx, edx ; Bits correspond to Filter/Receive Channels ;;;;;;;;;;;;;;;;;;; FilterChannel0 ;;;;;;;;;;;;;;;;; ; ; if (ETHERII->type == 0x800 && ; IP_V4->Protocol == 0x6 && ; TCP->SourcePort == 0x17) Chan0Crit0: xor eax, eax mov ax, WORD PTR [esi+12] Chan0Crit0Range0: cmp eax, DWORD PTR 00008H ; if (ETHERII->type == 0x800 && jne Chan0NoMatch Chan0Crit1: xor eax, eax mov al, BYTE PTR [esi+23] Chan0Crit1Range0: cmp al, BYTE PTR 006H ; IP_V4->Protocol == 0x6 && jne Chan0NoMatch ; Extract Header Length Field in IP_V4 ; ;..........<<4 >>60::4 ;..........0x0F00000000000000 ; ; Extract IP_V4 Header Length Field xor eax, eax mov al, BYTE PTR [esi+0] and al, BYTE PTR 0fH ; Account for any optional bytes in IP_V4 header after processing IP_V4 lea ecx, DWORD PTR [ecx+eax*4−20] Chan0Crit2: xor eax, eax mov ax, WORD PTR [esi+ecx+34] Chan0Crit2Range0: cmp eax, DWORD PTR 01700H ; TCP->Source Port == 0x17) jne Chan0NoMatch Chan0Match: or edx, 000000001H ; Index of Channel/Filter Number Chan0NoMatch: -
TABLE 15 Generated Code for Filtering Function, Example 2 ; ;if (ETHERII->type == 0x800 || ; (ETHERII->type >= 0x2e && ETHERII->type <= 0x5dc && ; ((LLC1->LLC1 >= 0x06060300 && LLC1->LLC1 <= 0x060603ff) || ; (LLC1->LLC1 == 0xaaaa0300 && LLC2->LLC2 == 0x800)))) ; ;;;;;;;;;;;;;;;;;;; FilterChannel1 ;;;;;;;;;;;;;;;;; Chan1Crit0: xor eax, eax mov ax, WORD PTR [esi+12] Chan1Crit0Range0: cmp eax, DWORD PTR 00008H ; if (ETHERII->type == 0x800 || je Chan1Match xor eax, eax mov ah, BYTE PTR [esi+12] mov al, BYTE PTR [esi+13] Chan1Crit0Range1: cmp eax, DWORD PTR 0002eH ; (ETHERII->type >= 0x2E && jb Chan1NoMatch cmp eax, DWORD PTR 005dcH ; ETHERII->type <= 0x5DC) && ja Chan1NoMatch Chan1Crit1: mov eax, DWORD PTR [esi+14] bswap eax Chan1Crit1Range0: cmp eax, DWORD PTR 006060300H ; (Llc1->LLC1 >= 0x6060300 && jb Chan1Crit1Range1 cmp eax, DWORD PTR 0060603ffH ; Llc1->LLC1 <= 0x60603FF) || jbe Chan1Match mov eax, DWORD PTR [esi+18] Chan1Crit1Range1: cmp eax, DWORD PTR 00003aaaaH ; Llc1->LLC1 == 0xAAAA0300 && jne Chan1NoMatch Chan1Crit2: mov eax, DWORD PTR [esi+22] Chan1Crit2Range0: cmp eax, DWORD PTR 000080000H ; Llc2->LLC2 == 0x800) jne Chan1NoMatch Chan1Match: or edx, 000000002H ; Index of Channel/Filter Number Chan1NoMatch: -
TABLE 16 Generated Code for Filtering Function, Example 3 ; ; if ((pether->Dadr2 == 0x1122 || ; pether->Sadr2 == 0x49) && ; pether->TypeLen == 0x800) ; ; ;;;;;;;;;;;;;;;;;;; FilterChannel2 ;;;;;;;;;;;;;;;;; Chan2Crit0: xor eax, eax mov ax, WORD PTR [esi+4] Chan2Crit0Range0: cmp eax, DWORD PTR 02211H ; if (pether->Dadr2 == 0x1122 || je Chan2Crit2Range0 Chan2Crit1: xor eax, eax mov ax, WORD PTR [esi+10] Chan2Crit1Range0: cmp eax, DWORD PTR 04900H ; pether->Sadr2 == 0x49 && jne Chan2NoMatch Chan2Crit2: xor eax, eax mov ax, WORD PTR [esi+12] Chan2Crit2Range0: cmp eax, DWORD PTR 00008H ; pether->TypeLen == 0x800) jne Chan2NoMatch Chan2Match: or edx, 000000004H ; Index of Channel/Filter Number Chan2NoMatch: mov eax, edx ; Bits correspond to Filter/Receive Channels - By adding routines to generate code for every function performed by the protocol description, it would possible to generate code that could first filter network frames, then parse frames containing any pre-configured protocols and fields while also generating code for gathering statistics, verifying checksums and CRCs, varying field values/recomputing checksums and CRCs, and performing routing (route table lookups). Also, by adding additional code generation support routines it would be possible to create a system/application that could generate code that implements an entire protocol or even an entire switch and/or router, all from user configured protocols, fields, filters, lookups, varies, checksums, CRCs, statistics, and route tables.
- Typically, switches/routers have two paths through the hardware/software. A “fast path” for operations that are performed often, and a slower “normal path” for operations that are performed infrequently and are not time critical. Using the principles discussed above, a system/application that could generate code to implement the “fast path” code can be produced. This would allow the switch/router owner to configure/tailor(reprogram) the “fast path” protocols and features supported, in the field.
- In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. For example, the content protection system could be used to protect content other than digital content, such as analog content; or the code generation routines could be used to generate other types of code, such as source code, machine language, or even English or other human-readable language code or documentation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than restrictive sense, and the invention is not to be restricted or limited except in accordance with the following claims and their legal equivalents.
Claims (20)
1. A method of securely distributing digital content, comprising:
receiving a content distribution request from a content user;
retrieving a digital content item in response to the content distribution request;
generating a first encryption algorithm for encrypting the digital content item;
configuring a protocol parsing engine to encrypt the digital content item, using the first encryption algorithm;
encrypting the digital content item using the configured protocol parsing engine; and
transmitting the encrypted digital content item to the content user.
2. The method of claim 1 , further comprising generating a first encryption key.
3. The method of claim 2 , wherein the configuring step further comprises using the first encryption key.
4. The method of claim 1 , further comprising recording an encryption identifier adapted to identify the first encryption algorithm.
5. The method of claim 1 , wherein the first encryption algorithm is different from a second encryption algorithm, the second encryption algorithm being a previously generated encryption algorithm used to encrypt a second digital content item transmitted to a second content user.
6. The method of claim 1 , wherein generating the encryption algorithm comprises retrieving the encryption algorithm from a pool of encryption algorithms.
7. A method of securely accessing encrypted digital content, comprising:
requesting from a content provider access to encrypted digital content;
receiving decryption information from the content provider;
decrypting the encrypted digital content using the decryption information;
accessing the decrypted digital content; and
deleting the decryption information.
8. The method of claim 7 , wherein the encrypted digital content is stored locally.
9. The method of claim 7 , wherein the decryption information comprises an executable decryption code module.
10. The method of claim 9 , wherein the executable decryption code module is created on demand by the content provider.
11. The method of claim 10 , wherein the executable decryption code module is created by a protocol description configured to generate executable code.
12. The method of claim 7 , wherein the received decryption information is stored in volatile memory.
13. The method of claim 7 , wherein the decrypted digital content is stored in volatile memory.
14. The method of claim 7 , further comprising deleting the decrypted digital content once it has been accessed.
15. The method of claim 7 , further comprising receiving encryption information from the content provider and re-encrypting the decrypted digital content, using the encryption information.
16. The method of claim 15 , wherein the encryption information is different from second encryption information used to initially encrypt the decrypted digital content.
17. A method of providing secure access to encrypted digital content, comprising:
receiving a request to access encrypted digital content;
retrieving a decryption algorithm for decrypting the encrypted digital content;
configuring a protocol description to generate a code module for decrypting the encrypted digital content, using the decryption algorithm;
generating the code module for decrypting the encrypted digital content, using the configured protocol description;
transmitting the code module to the content user.
18. The method of claim 17 , wherein the code module comprises an executable code module.
19. The method of claim 17 , wherein the request to access encrypted digital content comprises an identifier identifying the digital content.
20. The method of claim 19 , wherein retrieving the decryption algorithm comprises regenerating a decryption algorithm, based on the identifier.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/055,225 US20090063846A1 (en) | 1995-12-20 | 2008-03-25 | Systems and methods for prevention of peer-to-peer file sharing |
Applications Claiming Priority (8)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/575,506 US5793954A (en) | 1995-12-20 | 1995-12-20 | System and method for general purpose network analysis |
US08/888,875 US5781729A (en) | 1995-12-20 | 1997-07-07 | System and method for general purpose network analysis |
US09/080,325 US6000041A (en) | 1995-12-20 | 1998-05-15 | System and method for general purpose network analysis |
US09/113,704 US6266700B1 (en) | 1995-12-20 | 1998-07-10 | Network filtering system |
US09/898,852 US6493761B1 (en) | 1995-12-20 | 2001-07-03 | Systems and methods for data processing using a protocol parsing engine |
US10/272,471 US6651102B2 (en) | 1995-12-20 | 2002-10-15 | Systems and methods for general purpose data modification |
US10/715,954 US20040139211A1 (en) | 1995-12-20 | 2003-11-17 | Systems and methods for prevention of peer-to-peer file sharing |
US12/055,225 US20090063846A1 (en) | 1995-12-20 | 2008-03-25 | Systems and methods for prevention of peer-to-peer file sharing |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/715,954 Continuation US20040139211A1 (en) | 1995-12-20 | 2003-11-17 | Systems and methods for prevention of peer-to-peer file sharing |
Publications (1)
Publication Number | Publication Date |
---|---|
US20090063846A1 true US20090063846A1 (en) | 2009-03-05 |
Family
ID=24300598
Family Applications (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US08/575,506 Expired - Fee Related US5793954A (en) | 1995-12-20 | 1995-12-20 | System and method for general purpose network analysis |
US08/888,875 Expired - Fee Related US5781729A (en) | 1995-12-20 | 1997-07-07 | System and method for general purpose network analysis |
US09/080,325 Expired - Fee Related US6000041A (en) | 1995-12-20 | 1998-05-15 | System and method for general purpose network analysis |
US09/113,704 Expired - Fee Related US6266700B1 (en) | 1995-12-20 | 1998-07-10 | Network filtering system |
US12/055,225 Abandoned US20090063846A1 (en) | 1995-12-20 | 2008-03-25 | Systems and methods for prevention of peer-to-peer file sharing |
Family Applications Before (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US08/575,506 Expired - Fee Related US5793954A (en) | 1995-12-20 | 1995-12-20 | System and method for general purpose network analysis |
US08/888,875 Expired - Fee Related US5781729A (en) | 1995-12-20 | 1997-07-07 | System and method for general purpose network analysis |
US09/080,325 Expired - Fee Related US6000041A (en) | 1995-12-20 | 1998-05-15 | System and method for general purpose network analysis |
US09/113,704 Expired - Fee Related US6266700B1 (en) | 1995-12-20 | 1998-07-10 | Network filtering system |
Country Status (8)
Country | Link |
---|---|
US (5) | US5793954A (en) |
EP (1) | EP0868799B1 (en) |
AT (1) | ATE290278T1 (en) |
AU (1) | AU719679B2 (en) |
DE (1) | DE69634415D1 (en) |
HK (1) | HK1011590A1 (en) |
IL (1) | IL124990A (en) |
WO (1) | WO1997023076A1 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130016733A1 (en) * | 1997-02-18 | 2013-01-17 | Berman Stuart B | Methods and apparatus for fibre channel interconnection of private loop devices |
US8521905B2 (en) | 2011-12-22 | 2013-08-27 | Telefonaktiebolaget L M Ericsson (Publ) | System for flexible and extensible flow processing in software-defined networks |
US8711860B2 (en) * | 2011-12-22 | 2014-04-29 | Telefonaktiebolaget L M Ericsson (Publ) | Controller for flexible and extensible flow processing in software-defined networks |
US8718064B2 (en) | 2011-12-22 | 2014-05-06 | Telefonaktiebolaget L M Ericsson (Publ) | Forwarding element for flexible and extensible flow processing software-defined networks |
US20150262239A1 (en) * | 2014-03-13 | 2015-09-17 | Gary Goralnick | Advertising-integrated car |
US10176517B2 (en) * | 2014-03-13 | 2019-01-08 | Gary Goralnick | Advertising-integrated car |
US10936701B2 (en) * | 2016-01-26 | 2021-03-02 | Twentieth Century Fox Film Corporation | Method and system for conditional access via license of proprietary functionality |
US11017110B1 (en) * | 2018-10-09 | 2021-05-25 | Q-Net Security, Inc. | Enhanced securing of data at rest |
US11216575B2 (en) | 2018-10-09 | 2022-01-04 | Q-Net Security, Inc. | Enhanced securing and secured processing of data at rest |
Families Citing this family (163)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU6623196A (en) * | 1995-07-25 | 1997-02-26 | British Telecommunications Public Limited Company | Telecommunications network interface |
US20040139211A1 (en) * | 1995-12-20 | 2004-07-15 | Nb Networks | Systems and methods for prevention of peer-to-peer file sharing |
US5793954A (en) * | 1995-12-20 | 1998-08-11 | Nb Networks | System and method for general purpose network analysis |
US6651102B2 (en) * | 1995-12-20 | 2003-11-18 | Nb Networks | Systems and methods for general purpose data modification |
AU744884B2 (en) * | 1995-12-20 | 2002-03-07 | Nb Networks | System and method for general purpose network analysis |
US6493761B1 (en) * | 1995-12-20 | 2002-12-10 | Nb Networks | Systems and methods for data processing using a protocol parsing engine |
US20040167857A1 (en) * | 1995-12-20 | 2004-08-26 | Nb Networks | Systems and methods for prevention of peer-to-peer file sharing |
DE19625196A1 (en) * | 1996-06-24 | 1998-01-02 | Godi Meyer Gizella | Data archiving system |
US5881242A (en) * | 1997-01-09 | 1999-03-09 | International Business Machines Corporation | Method and system of parsing frame headers for routing data frames within a computer network |
IT1290935B1 (en) * | 1997-02-17 | 1998-12-14 | Algotech Sistemi S R L | EQUIPMENT AND METHOD FOR DETECTION AND INTERPRETATION OF APPLICATION PROTOCOLS OF NETWORK DATA TRANSMISSION SYSTEMS. |
US6311215B1 (en) * | 1997-03-25 | 2001-10-30 | Intel Corporation | System for dynamic determination of client communications capabilities |
US6032203A (en) * | 1997-04-07 | 2000-02-29 | General Electric Company | System for interfacing between a plurality of processors having different protocols in switchgear and motor control center applications by creating description statements specifying rules |
US6732191B1 (en) | 1997-09-10 | 2004-05-04 | Schneider Automation Inc. | Web interface to an input/output device |
US7058693B1 (en) | 1997-09-10 | 2006-06-06 | Schneider Automation Inc. | System for programming a programmable logic controller using a web browser |
US7035898B1 (en) | 1997-09-10 | 2006-04-25 | Schneider Automation Inc. | System for programming a factory automation device using a web browser |
US20020152289A1 (en) * | 1997-09-10 | 2002-10-17 | Schneider Automation Inc. | System and method for accessing devices in a factory automation network |
US20020091784A1 (en) * | 1997-09-10 | 2002-07-11 | Baker Richard A. | Web interface to a device and an electrical network control system |
WO1999014891A2 (en) * | 1997-09-12 | 1999-03-25 | Communication & Control Electronics Limited | Development and test tools for communication system |
US6216152B1 (en) * | 1997-10-27 | 2001-04-10 | Sun Microsystems, Inc. | Method and apparatus for providing plug in media decoders |
IL136219A0 (en) * | 1997-11-20 | 2001-05-20 | Xacct Technologies Inc | Network accounting and billing system and method |
US5978045A (en) * | 1997-11-24 | 1999-11-02 | Sony Corporation | Effects processing system and method |
US6108800A (en) * | 1998-02-10 | 2000-08-22 | Hewlett-Packard Company | Method and apparatus for analyzing the performance of an information system |
US7162510B2 (en) * | 1998-03-16 | 2007-01-09 | Schneider Automation Inc. | Communication system for a control system over Ethernet and IP networks |
US6330614B1 (en) * | 1998-03-20 | 2001-12-11 | Nexabit Networks Llc | Internet and related networks, a method of and system for substitute use of checksum field space in information processing datagram headers for obviating processing speed and addressing space limitations and providing other features |
US7333484B2 (en) * | 1998-08-07 | 2008-02-19 | Intel Corporation | Services processor having a packet editing unit |
US7133400B1 (en) * | 1998-08-07 | 2006-11-07 | Intel Corporation | System and method for filtering data |
IT1302430B1 (en) | 1998-08-12 | 2000-09-05 | Alasi Di Arcieri Franco & C S | APPARATUS FOR THE CONTROL AND CERTIFICATION OF THE DIMATERIAL DELIVERY OBJECT OF ELECTRONIC COMMERCE AND FOR THE CONTEXTUAL |
IT1302431B1 (en) * | 1998-08-12 | 2000-09-05 | Alasi Di Arcieri Franco & C S | NETWORK ACCESS CONTROL DEVICE THROUGH FAST RECOGNITION OF APPLICATION FRAMES THAT SATISFY A SET OF RULES |
US6799211B1 (en) * | 1998-08-25 | 2004-09-28 | Mci Communications Corporation | Management of multiple non-standard networks and systems with smart agents |
US6493342B1 (en) * | 1998-09-11 | 2002-12-10 | Teledesic Llc | Method of data transmission in a data communication network |
US6233626B1 (en) * | 1998-10-06 | 2001-05-15 | Schneider Automation Inc. | System for a modular terminal input/output interface for communicating messaging application layer over encoded ethernet to transport layer |
US6560611B1 (en) * | 1998-10-13 | 2003-05-06 | Netarx, Inc. | Method, apparatus, and article of manufacture for a network monitoring system |
US6560235B1 (en) * | 1998-11-16 | 2003-05-06 | Woodhead Industries, Inc. | Universal communication system |
CA2351175C (en) | 1998-11-24 | 2016-05-03 | Niksun, Inc. | Apparatus and method for collecting and analyzing communications data |
US6347382B1 (en) * | 1998-11-30 | 2002-02-12 | Advantest Corp. | Multi-port device analysis apparatus and method |
US20020188720A1 (en) * | 1998-12-28 | 2002-12-12 | William F. Terrell | Method and apparatus for dynamically controlling the provision of differentiated services |
US6853867B1 (en) | 1998-12-30 | 2005-02-08 | Schneider Automation Inc. | Interface to a programmable logic controller |
US6356950B1 (en) * | 1999-01-11 | 2002-03-12 | Novilit, Inc. | Method for encoding and decoding data according to a protocol specification |
US6606301B1 (en) | 1999-03-01 | 2003-08-12 | Sun Microsystems, Inc. | Method and apparatus for early random discard of packets |
US6453360B1 (en) | 1999-03-01 | 2002-09-17 | Sun Microsystems, Inc. | High performance network interface |
US6389468B1 (en) | 1999-03-01 | 2002-05-14 | Sun Microsystems, Inc. | Method and apparatus for distributing network traffic processing on a multiprocessor computer |
US6650640B1 (en) | 1999-03-01 | 2003-11-18 | Sun Microsystems, Inc. | Method and apparatus for managing a network flow in a high performance network interface |
US6356951B1 (en) * | 1999-03-01 | 2002-03-12 | Sun Microsystems, Inc. | System for parsing a packet for conformity with a predetermined protocol using mask and comparison values included in a parsing instruction |
US6483804B1 (en) | 1999-03-01 | 2002-11-19 | Sun Microsystems, Inc. | Method and apparatus for dynamic packet batching with a high performance network interface |
US7243143B1 (en) | 1999-03-25 | 2007-07-10 | Nortel Networks Limited | Flow probe connectivity determination |
US20020091636A1 (en) * | 1999-03-25 | 2002-07-11 | Nortel Networks Corporation | Capturing quality of service |
US6751663B1 (en) | 1999-03-25 | 2004-06-15 | Nortel Networks Limited | System wide flow aggregation process for aggregating network activity records |
US6625657B1 (en) | 1999-03-25 | 2003-09-23 | Nortel Networks Limited | System for requesting missing network accounting records if there is a break in sequence numbers while the records are transmitting from a source device |
US7167860B1 (en) | 1999-03-25 | 2007-01-23 | Nortel Networks Limited | Fault tolerance for network accounting architecture |
US6643705B1 (en) * | 1999-03-29 | 2003-11-04 | Microsoft Corporation | Routing of electronic messages using a routing map and a stateful script engine |
US6789116B1 (en) * | 1999-06-30 | 2004-09-07 | Hi/Fn, Inc. | State processor for pattern matching in a network monitor device |
CN1293478C (en) * | 1999-06-30 | 2007-01-03 | 倾向探测公司 | Method and apparatus for monitoring traffic in a network |
US6742045B1 (en) * | 1999-07-02 | 2004-05-25 | Cisco Technology, Inc. | Handling packet fragments in a distributed network service environment |
US7620980B1 (en) * | 1999-07-21 | 2009-11-17 | Sun Microsystems, Inc. | Secure data broker |
US7342897B1 (en) * | 1999-08-07 | 2008-03-11 | Cisco Technology, Inc. | Network verification tool |
US6598034B1 (en) | 1999-09-21 | 2003-07-22 | Infineon Technologies North America Corp. | Rule based IP data processing |
SE9904685D0 (en) * | 1999-12-17 | 1999-12-17 | Switchcore Ab | A programmable packaged decoder |
US7009973B2 (en) * | 2000-02-28 | 2006-03-07 | Broadcom Corporation | Switch using a segmented ring |
US6601184B1 (en) | 2000-03-14 | 2003-07-29 | Novell, Inc. | System crash network access |
US7035934B1 (en) * | 2000-03-23 | 2006-04-25 | Verizon Corporate Services Group Inc. | System and method for improving traffic analysis and network modeling |
EP1139603A1 (en) | 2000-03-27 | 2001-10-04 | Tektronix, Inc. | Method and Apparatus for data analysing |
US7116672B1 (en) * | 2000-04-07 | 2006-10-03 | Cisco Technology, Inc. | Method and apparatus for reducing flooding in bridged networks |
US6931444B2 (en) * | 2000-06-12 | 2005-08-16 | Amdocs (Israel) Ltd. | System, method and computer program product for reading, correlating, processing, categorizing and aggregating events of any type |
DE50013466D1 (en) * | 2000-06-19 | 2006-10-26 | Tektronix Berlin Gmbh & Co Kg | Decoding device for the analysis of communication protocols |
US20040073617A1 (en) | 2000-06-19 | 2004-04-15 | Milliken Walter Clark | Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail |
US7519737B2 (en) * | 2000-07-07 | 2009-04-14 | Schneider Automation Inc. | Input/output (I/O) scanner for a control system with peer determination |
US7181487B1 (en) | 2000-07-07 | 2007-02-20 | Schneider Automation Inc. | Method and system for transmitting and activating an application requesting human intervention in an automation network |
US7032029B1 (en) | 2000-07-07 | 2006-04-18 | Schneider Automation Inc. | Method and apparatus for an active standby control system on a network |
IT1320572B1 (en) * | 2000-08-01 | 2003-12-10 | Cselt Centro Studi Lab Telecom | CIRCUIT GENERATOR MODULE FOR THE ANALYSIS OF DATA INCELLED BIT STRINGS, METHOD FOR THE GENERATION OF SUCH CIRCUIT TYPE |
EP1179916B1 (en) * | 2000-08-09 | 2006-08-30 | Tektronix Berlin GmbH & Co. KG | Apparatus for analysing digital data |
US6618823B1 (en) * | 2000-08-15 | 2003-09-09 | Storage Technology Corporation | Method and system for automatically gathering information from different types of devices connected in a network when a device fails |
US20020167967A1 (en) * | 2000-09-06 | 2002-11-14 | Schneider Electric | Method for managing bandwidth on an ethernet network |
US7028204B2 (en) * | 2000-09-06 | 2006-04-11 | Schneider Automation Inc. | Method and apparatus for ethernet prioritized device clock synchronization |
US7023795B1 (en) | 2000-11-07 | 2006-04-04 | Schneider Automation Inc. | Method and apparatus for an active standby control system on a network |
US7797431B2 (en) * | 2001-02-09 | 2010-09-14 | Willard Case | Enhanced data exchange and functionality control system and method |
US7249190B2 (en) * | 2001-02-09 | 2007-07-24 | Comlet Technologies, Llc. | Enhanced data exchange and presentation/communication system |
US20020157041A1 (en) * | 2001-04-23 | 2002-10-24 | Bennett David Charles | Protocol parser-code generator |
US20020156886A1 (en) * | 2001-04-23 | 2002-10-24 | Krieski William George | Protocol monitor |
US7451110B2 (en) * | 2001-05-18 | 2008-11-11 | Network Resonance, Inc. | System, method and computer program product for providing an efficient trading market |
US7464154B2 (en) * | 2001-05-18 | 2008-12-09 | Network Resonance, Inc. | System, method and computer program product for analyzing data from network-based structured message stream |
US7936693B2 (en) * | 2001-05-18 | 2011-05-03 | Network Resonance, Inc. | System, method and computer program product for providing an IP datalink multiplexer |
US7124299B2 (en) * | 2001-05-18 | 2006-10-17 | Claymore Systems, Inc. | System, method and computer program product for auditing XML messages in a network-based message stream |
CN1146270C (en) * | 2001-06-27 | 2004-04-14 | 华为技术有限公司 | Method for automatically obtaining IP address of equipment |
US7149189B2 (en) * | 2001-07-17 | 2006-12-12 | Mcafee, Inc. | Network data retrieval and filter systems and methods |
US7162698B2 (en) * | 2001-07-17 | 2007-01-09 | Mcafee, Inc. | Sliding window packet management systems |
US6835704B2 (en) * | 2001-09-14 | 2004-12-28 | Clean Control Corporation | Surfactant-free cleaning compositions and processes for the use thereof |
US7401326B1 (en) | 2001-10-24 | 2008-07-15 | Finisar Corporation | Compiling protocol analysis code using protocol database |
US7813346B1 (en) | 2001-11-21 | 2010-10-12 | Juniper Networks, Inc. | Filter-based forwarding in a network |
US6604139B1 (en) | 2001-12-14 | 2003-08-05 | Networks Associates Technology, Inc. | Voice protocol filtering system and method |
US20030115350A1 (en) * | 2001-12-14 | 2003-06-19 | Silverback Systems, Inc. | System and method for efficient handling of network data |
US6970823B1 (en) | 2001-12-14 | 2005-11-29 | Networks Associates Technology, Inc. | System, method and computer program product for monitoring voice application calls over a network |
US6814842B1 (en) | 2001-12-14 | 2004-11-09 | Networks Associates Technology, Inc. | System and method for organizing objects of a voice call in a tree representation |
US20030126269A1 (en) * | 2001-12-31 | 2003-07-03 | Globespanvirata Incorporated | System and method for automatically configuring a protocol line trace filter |
FR2834848B1 (en) * | 2002-01-15 | 2005-02-04 | France Telecom | METHOD FOR OBSERVING A COMMUNICATION NETWORK AND SYSTEM FOR IMPLEMENTING SAID METHOD |
WO2003067382A2 (en) * | 2002-02-04 | 2003-08-14 | Intel Corporation | Service processor having a queue operations unit and an output scheduler |
US6760845B1 (en) | 2002-02-08 | 2004-07-06 | Networks Associates Technology, Inc. | Capture file format system and method for a network analyzer |
US6874089B2 (en) | 2002-02-25 | 2005-03-29 | Network Resonance, Inc. | System, method and computer program product for guaranteeing electronic transactions |
US7769997B2 (en) | 2002-02-25 | 2010-08-03 | Network Resonance, Inc. | System, method and computer program product for guaranteeing electronic transactions |
US7240213B1 (en) | 2002-03-15 | 2007-07-03 | Waters Edge Consulting, Llc. | System trustworthiness tool and methodology |
EP1347599B1 (en) | 2002-03-22 | 2005-07-20 | Tektronix Berlin GmbH & Co. KG | Protocol analyzer and method for decoding data based on a protocol description |
US20030195973A1 (en) * | 2002-04-11 | 2003-10-16 | Raymond Savarda | Methods, systems, and computer program products for processing a packet with layered headers using a data structure that positionally relates the layered headers |
KR100497357B1 (en) * | 2002-06-26 | 2005-06-23 | 삼성전자주식회사 | Header compressed and packet multiplexed apparatus and method in the network environment based on IP |
US20040004956A1 (en) * | 2002-07-03 | 2004-01-08 | Agilent Technologies, Inc. | Apparatus and method for routing information from a telecommunications network |
FR2842970B1 (en) * | 2002-07-29 | 2005-03-18 | Qosmos | METHOD OF RECOGNIZING AND ANALYZING PROTOCOLS IN DATA NETWORKS |
US7428218B2 (en) * | 2002-08-01 | 2008-09-23 | Teradyne, Inc. | Flexible approach for representing different bus protocols |
US7562156B2 (en) * | 2002-08-16 | 2009-07-14 | Symantec Operating Corporation | System and method for decoding communications between nodes of a cluster server |
JP3757917B2 (en) * | 2002-08-20 | 2006-03-22 | 日本電気株式会社 | Packet transfer device, packet transfer method resolution server, DNS server, network system, and program |
US7936688B2 (en) * | 2002-09-16 | 2011-05-03 | Jds Uniphase Corporation | Protocol cross-port analysis |
US20040093413A1 (en) * | 2002-11-06 | 2004-05-13 | Bean Timothy E. | Selecting and managing time specified segments from a large continuous capture of network data |
US20040098611A1 (en) * | 2002-11-06 | 2004-05-20 | Bean Timothy E. | Optimizing retrieval of requested data from a remote device |
US20040133733A1 (en) * | 2002-11-06 | 2004-07-08 | Finisar Corporation | Storing, retrieving and displaying captured data in a network analysis system |
WO2004048892A1 (en) * | 2002-11-22 | 2004-06-10 | Reduct | Method for determining a track of a geographical trajectory |
FR2848044B1 (en) | 2002-11-28 | 2005-04-01 | Qosmos | METHOD AND COMPUTER SYSTEM FOR TRIGGERING ACTION ON DIGITAL COMMUNICATION DATA |
GB0229647D0 (en) * | 2002-12-19 | 2003-01-22 | Zarlink Semiconductor Ltd | Packet classifer |
US7130987B2 (en) * | 2003-01-24 | 2006-10-31 | Mistletoe Technologies, Inc. | Reconfigurable semantic processor |
US7424571B2 (en) * | 2004-07-27 | 2008-09-09 | Gigafin Networks, Inc. | Array machine context data memory |
US7415596B2 (en) * | 2003-01-24 | 2008-08-19 | Gigafin Networks, Inc. | Parser table/production rule table configuration using CAM and SRAM |
US20050216770A1 (en) * | 2003-01-24 | 2005-09-29 | Mistletoe Technologies, Inc. | Intrusion detection system |
US20050281281A1 (en) * | 2003-01-24 | 2005-12-22 | Rajesh Nair | Port input buffer architecture |
US20040158630A1 (en) * | 2003-02-12 | 2004-08-12 | Chang Tsung-Yen Dean | Monitoring and controlling network activity in real-time |
US20040210664A1 (en) * | 2003-04-17 | 2004-10-21 | Schneider Automation Inc. | System and method for transmitting data |
WO2004099970A1 (en) * | 2003-05-08 | 2004-11-18 | Endace Technology Limited | Data transmission processing system and method |
US7119808B2 (en) * | 2003-07-15 | 2006-10-10 | Alienware Labs Corp. | Multiple parallel processor computer graphics system |
US20050013181A1 (en) * | 2003-07-17 | 2005-01-20 | Adelmann Todd C. | Assisted memory device with integrated cache |
US7251722B2 (en) * | 2004-05-11 | 2007-07-31 | Mistletoe Technologies, Inc. | Semantic processor storage server architecture |
US7493481B1 (en) * | 2004-05-17 | 2009-02-17 | Netxen, Inc. | Direct hardware processing of internal data structure fields |
US7398356B2 (en) * | 2004-07-22 | 2008-07-08 | Mistletoe Technologies, Inc. | Contextual memory interface for network processor |
US20060026377A1 (en) * | 2004-07-27 | 2006-02-02 | Somsubhra Sikdar | Lookup interface for array machine context data memory |
US7451268B2 (en) * | 2004-07-27 | 2008-11-11 | Gigafin Networks, Inc. | Arbiter for array machine context data memory |
US20070019661A1 (en) * | 2005-07-20 | 2007-01-25 | Mistletoe Technologies, Inc. | Packet output buffer for semantic processor |
US20070022479A1 (en) * | 2005-07-21 | 2007-01-25 | Somsubhra Sikdar | Network interface and firewall device |
US7881332B2 (en) * | 2005-04-01 | 2011-02-01 | International Business Machines Corporation | Configurable ports for a host ethernet adapter |
US7697536B2 (en) * | 2005-04-01 | 2010-04-13 | International Business Machines Corporation | Network communications for operating system partitions |
US7508771B2 (en) * | 2005-04-01 | 2009-03-24 | International Business Machines Corporation | Method for reducing latency in a host ethernet adapter (HEA) |
US7706409B2 (en) * | 2005-04-01 | 2010-04-27 | International Business Machines Corporation | System and method for parsing, filtering, and computing the checksum in a host Ethernet adapter (HEA) |
US7492771B2 (en) * | 2005-04-01 | 2009-02-17 | International Business Machines Corporation | Method for performing a packet header lookup |
US20060221953A1 (en) * | 2005-04-01 | 2006-10-05 | Claude Basso | Method and apparatus for blind checksum and correction for network transmissions |
US7903687B2 (en) * | 2005-04-01 | 2011-03-08 | International Business Machines Corporation | Method for scheduling, writing, and reading data inside the partitioned buffer of a switch, router or packet processing device |
US7804787B2 (en) * | 2005-07-08 | 2010-09-28 | Fluke Corporation | Methods and apparatus for analyzing and management of application traffic on networks |
US20070016906A1 (en) * | 2005-07-18 | 2007-01-18 | Mistletoe Technologies, Inc. | Efficient hardware allocation of processes to processors |
US20070022225A1 (en) * | 2005-07-21 | 2007-01-25 | Mistletoe Technologies, Inc. | Memory DMA interface with checksum |
US20070022275A1 (en) * | 2005-07-25 | 2007-01-25 | Mistletoe Technologies, Inc. | Processor cluster implementing conditional instruction skip |
US8031706B2 (en) * | 2005-10-31 | 2011-10-04 | Agere Systems Inc. | Circuitry for determining network operations in a network device by addressing lookup tables with contents of protocol header fields |
US7685271B1 (en) * | 2006-03-30 | 2010-03-23 | Symantec Corporation | Distributed platform for testing filtering rules |
WO2008001038A1 (en) * | 2006-06-28 | 2008-01-03 | British Telecommunications Public Limited Company | Method and apparatus for converting messages |
US20100085891A1 (en) * | 2006-12-19 | 2010-04-08 | Andreas Kind | Apparatus and method for analysing a network |
US8521868B2 (en) * | 2008-10-15 | 2013-08-27 | International Business Machines Corporation | Platform-level indicators of application performance |
WO2011105892A1 (en) * | 2010-02-24 | 2011-09-01 | Eonic B.V. | Wideband analog recording method an circuitry for wideband analog data recorder |
US8705533B1 (en) * | 2010-12-10 | 2014-04-22 | Juniper Networks, Inc. | Fast packet encapsulation using templates |
US8151341B1 (en) * | 2011-05-23 | 2012-04-03 | Kaspersky Lab Zao | System and method for reducing false positives during detection of network attacks |
US9374265B1 (en) | 2012-10-02 | 2016-06-21 | Microsemi Storage Solutions (U.S.), Inc. | GFP frame filter |
US9825884B2 (en) | 2013-12-30 | 2017-11-21 | Cavium, Inc. | Protocol independent programmable switch (PIPS) software defined data center networks |
ES2870577T3 (en) * | 2014-05-30 | 2021-10-27 | Huawei Tech Co Ltd | Package editing procedure and related device |
US10616380B2 (en) * | 2014-06-19 | 2020-04-07 | Cavium, Llc | Method of handling large protocol layers for configurable extraction of layer information and an apparatus thereof |
US9742694B2 (en) | 2014-06-19 | 2017-08-22 | Cavium, Inc. | Method of dynamically renumbering ports and an apparatus thereof |
US10050833B2 (en) | 2014-06-19 | 2018-08-14 | Cavium, Inc. | Method of reducing latency in a flexible parser and an apparatus thereof |
US9628385B2 (en) | 2014-06-19 | 2017-04-18 | Cavium, Inc. | Method of identifying internal destinations of networks packets and an apparatus thereof |
US9635146B2 (en) | 2014-06-19 | 2017-04-25 | Cavium, Inc. | Method of using bit vectors to allow expansion and collapse of header layers within packets for enabling flexible modifications and an apparatus thereof |
US9531848B2 (en) * | 2014-06-19 | 2016-12-27 | Cavium, Inc. | Method of using generic modification instructions to enable flexible modifications of packets and an apparatus thereof |
US9961167B2 (en) | 2014-06-19 | 2018-05-01 | Cavium, Inc. | Method of modifying packets to a generic format for enabling programmable modifications and an apparatus thereof |
US9606781B2 (en) | 2014-11-14 | 2017-03-28 | Cavium, Inc. | Parser engine programming tool for programmable network devices |
TWI685243B (en) * | 2018-10-09 | 2020-02-11 | 孕龍科技股份有限公司 | Method for displaying bus packet format of logic analyzer |
US20230319168A1 (en) * | 2022-04-01 | 2023-10-05 | Nxp B.V. | Hardware ethernet header verification |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6012086A (en) * | 1997-06-24 | 2000-01-04 | Sony Corporation | Internet event timer recording for video and/or audio |
US6493761B1 (en) * | 1995-12-20 | 2002-12-10 | Nb Networks | Systems and methods for data processing using a protocol parsing engine |
US7120604B2 (en) * | 1997-03-26 | 2006-10-10 | Sony Corporation | Method of controlling digital content distribution, a method of reproducing digital content, and an apparatus using the same |
US7680912B1 (en) * | 2000-05-18 | 2010-03-16 | thePlatform, Inc. | System and method for managing and provisioning streamed data |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS62197850A (en) * | 1986-02-26 | 1987-09-01 | Mitsubishi Electric Corp | Controller for local area network |
US5062055A (en) * | 1986-09-02 | 1991-10-29 | Digital Equipment Corporation | Data processor performance advisor |
US5121342A (en) * | 1989-08-28 | 1992-06-09 | Network Communications Corporation | Apparatus for analyzing communication networks |
EP0558505B1 (en) * | 1990-10-05 | 2000-01-26 | Microsoft Corporation | System and method for information retrieval |
US5210530A (en) * | 1991-01-04 | 1993-05-11 | Codex Corporation | Network management interface with internal dsd |
JPH05114905A (en) * | 1991-04-08 | 1993-05-07 | Digital Equip Corp <Dec> | Message processing filtering using single address and protocol table bridge |
EP0689748B1 (en) * | 1993-03-20 | 1998-09-16 | International Business Machines Corporation | Method and apparatus for extracting connection information from protocol headers |
US5442639A (en) * | 1993-10-12 | 1995-08-15 | Ship Star Associates, Inc. | Method and apparatus for monitoring a communications network |
JPH08180006A (en) * | 1994-12-22 | 1996-07-12 | Hitachi Ltd | Network interface and computer network system |
US5796954A (en) * | 1995-10-13 | 1998-08-18 | Apple Computer, Inc. | Method and system for maximizing the use of threads in a file server for processing network requests |
US5764899A (en) * | 1995-11-13 | 1998-06-09 | Motorola, Inc. | Method and apparatus for communicating an optimized reply |
US5826030A (en) * | 1995-11-30 | 1998-10-20 | Excel Switching Corporation | Telecommunication switch having a universal API with a single call processing message including user-definable data and response message each having a generic format |
US5793954A (en) * | 1995-12-20 | 1998-08-11 | Nb Networks | System and method for general purpose network analysis |
-
1995
- 1995-12-20 US US08/575,506 patent/US5793954A/en not_active Expired - Fee Related
-
1996
- 1996-12-13 AT AT96945102T patent/ATE290278T1/en not_active IP Right Cessation
- 1996-12-13 AU AU13550/97A patent/AU719679B2/en not_active Ceased
- 1996-12-13 WO PCT/US1996/020779 patent/WO1997023076A1/en active IP Right Grant
- 1996-12-13 IL IL12499096A patent/IL124990A/en not_active IP Right Cessation
- 1996-12-13 EP EP96945102A patent/EP0868799B1/en not_active Expired - Lifetime
- 1996-12-13 DE DE69634415T patent/DE69634415D1/en not_active Expired - Lifetime
-
1997
- 1997-07-07 US US08/888,875 patent/US5781729A/en not_active Expired - Fee Related
-
1998
- 1998-05-15 US US09/080,325 patent/US6000041A/en not_active Expired - Fee Related
- 1998-07-10 US US09/113,704 patent/US6266700B1/en not_active Expired - Fee Related
- 1998-12-08 HK HK98112919A patent/HK1011590A1/en not_active IP Right Cessation
-
2008
- 2008-03-25 US US12/055,225 patent/US20090063846A1/en not_active Abandoned
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6493761B1 (en) * | 1995-12-20 | 2002-12-10 | Nb Networks | Systems and methods for data processing using a protocol parsing engine |
US7120604B2 (en) * | 1997-03-26 | 2006-10-10 | Sony Corporation | Method of controlling digital content distribution, a method of reproducing digital content, and an apparatus using the same |
US6012086A (en) * | 1997-06-24 | 2000-01-04 | Sony Corporation | Internet event timer recording for video and/or audio |
US7680912B1 (en) * | 2000-05-18 | 2010-03-16 | thePlatform, Inc. | System and method for managing and provisioning streamed data |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130016733A1 (en) * | 1997-02-18 | 2013-01-17 | Berman Stuart B | Methods and apparatus for fibre channel interconnection of private loop devices |
US9137177B2 (en) | 1997-02-18 | 2015-09-15 | Emulex Corporation | System and method for interconnecting physical channels |
US8902911B2 (en) * | 1997-02-18 | 2014-12-02 | Emulex Corporation | System and method for interconnecting ethernet and fibre channel |
US8718064B2 (en) | 2011-12-22 | 2014-05-06 | Telefonaktiebolaget L M Ericsson (Publ) | Forwarding element for flexible and extensible flow processing software-defined networks |
US8711860B2 (en) * | 2011-12-22 | 2014-04-29 | Telefonaktiebolaget L M Ericsson (Publ) | Controller for flexible and extensible flow processing in software-defined networks |
US9077668B2 (en) | 2011-12-22 | 2015-07-07 | Telefonaktiebolaget L M Ericsson (Publ) | Flexible and extensible flow processing in software-defined networks |
US8521905B2 (en) | 2011-12-22 | 2013-08-27 | Telefonaktiebolaget L M Ericsson (Publ) | System for flexible and extensible flow processing in software-defined networks |
US20150262239A1 (en) * | 2014-03-13 | 2015-09-17 | Gary Goralnick | Advertising-integrated car |
US9646326B2 (en) * | 2014-03-13 | 2017-05-09 | Gary Goralnick | Advertising-integrated car |
US10176517B2 (en) * | 2014-03-13 | 2019-01-08 | Gary Goralnick | Advertising-integrated car |
US10936701B2 (en) * | 2016-01-26 | 2021-03-02 | Twentieth Century Fox Film Corporation | Method and system for conditional access via license of proprietary functionality |
US11017110B1 (en) * | 2018-10-09 | 2021-05-25 | Q-Net Security, Inc. | Enhanced securing of data at rest |
US11216575B2 (en) | 2018-10-09 | 2022-01-04 | Q-Net Security, Inc. | Enhanced securing and secured processing of data at rest |
US11853445B2 (en) | 2018-10-09 | 2023-12-26 | Q-Net Security, Inc. | Enhanced securing and secured processing of data at rest |
US11861027B2 (en) | 2018-10-09 | 2024-01-02 | Q-Net Security, Inc. | Enhanced securing of data at rest |
Also Published As
Publication number | Publication date |
---|---|
DE69634415D1 (en) | 2005-04-07 |
AU1355097A (en) | 1997-07-14 |
US6266700B1 (en) | 2001-07-24 |
IL124990A0 (en) | 1999-01-26 |
HK1011590A1 (en) | 1999-07-16 |
EP0868799B1 (en) | 2005-03-02 |
AU719679B2 (en) | 2000-05-18 |
IL124990A (en) | 2002-02-10 |
EP0868799A4 (en) | 1999-03-17 |
ATE290278T1 (en) | 2005-03-15 |
EP0868799A1 (en) | 1998-10-07 |
US6000041A (en) | 1999-12-07 |
US5793954A (en) | 1998-08-11 |
WO1997023076A1 (en) | 1997-06-26 |
US5781729A (en) | 1998-07-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20090063846A1 (en) | Systems and methods for prevention of peer-to-peer file sharing | |
US11727376B2 (en) | Use of media storage structure with multiple pieces of content in a content-distribution system | |
US9071423B2 (en) | Identification of a compromised content player | |
JP4039489B2 (en) | Information protection method and system for multimedia contents | |
US7376624B2 (en) | Secure communication and real-time watermarking using mutating identifiers | |
US7440574B2 (en) | Content encryption using programmable hardware | |
US20050119967A1 (en) | Information processing device and method, program storage medium and program | |
US20010016836A1 (en) | Method and apparatus for distributing multimedia information over a network | |
US20040125957A1 (en) | Method and system for secure distribution | |
US20050193205A1 (en) | Method and system for session based watermarking of encrypted content | |
US20050021783A1 (en) | Information processing apparatus and method | |
US20050044046A1 (en) | Information processing device and mehtod, information providing device and method, use right management device and method, recording medium, and program | |
WO2006118896A2 (en) | Method and apparatus for detecting the falsification of metadata | |
US20060161502A1 (en) | System and method for secure and convenient handling of cryptographic binding state information | |
JP2001273713A (en) | Delivery of digital data and security holding system of playback | |
JP2008529044A (en) | Secure encryption system, apparatus and method | |
US20040139211A1 (en) | Systems and methods for prevention of peer-to-peer file sharing | |
US20200019677A1 (en) | Monitoring Playback of Media Content, Including Copyrighted Items | |
US20040167857A1 (en) | Systems and methods for prevention of peer-to-peer file sharing | |
EP1474908A2 (en) | METHOD AND SYSTEM FOR SECURELY TRANSMITTING AND DISTRIBUTING INFORMATION AND FOR PRODUCING A PHYSICAL INSTANTIATION OF THE TRANSMITTED INFORMATION IN AN INTERMEDIATE&comma; INFORMATION&minus;STORAGE MEDIUM | |
KR20020029802A (en) | Business method and instrument for providing encrypted moving file and computer readable medium having stored thereon computer executable instruction for performing the method | |
JP3002184B1 (en) | Content utilization device and recording medium recording content utilization program | |
US20050125356A1 (en) | Method and apparatus for decrypting encrypted data by suing copy control information and computer readable recording medium for storing program for implementing the apparatus and method | |
CN112804252B (en) | User management system | |
Touimi et al. | Enhanced security architecture for music distribution on mobile |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: KNOBBE, MARTENS, OLSON & BEAR, LLP, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:NB NETWORKS;REEL/FRAME:025103/0297 Effective date: 20090818 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |