Cryptography – Video cryptography – Copy protection or prevention
Reexamination Certificate
1997-06-10
2001-02-06
Cangialosi, Salvatore (Department: 2746)
Cryptography
Video cryptography
Copy protection or prevention
Reexamination Certificate
active
06185306
ABSTRACT:
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent & Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
The present invention is directed to a method of transmitting “triggering data” over a network to cause video and/or audio information data on a Internet Web Page.
The Internet is a conglomeration of computer networks that are linked together. Each network of the Internet may have one or more servers, and an operating system that may be different from that of others in the Internet. To link one network to another, and in order to overcome these operating differences between computer networks, the Internet system utilizes hardware and software devices called: bridges, routers, and gateways, all of which adapt the information being sent on one network to the operating and protocol requirements of the receiving network. For example, a gateway will connect, or “splice” a network operating on the Novell protocol to a network that operates on a DECnet or SNA protocol.
There are currently more than 10,000 computer networks that are linked together, worldwide, which together constitute the “Internet”. Because they do not all operate on the same operating system, and because of different protocols, the data sent from one host computer of one network to a receiving computer of another network—which may be many thousands of miles away from the host computer—may take a relatively long time, since the gateways, bridges and routers must conform or adapt the protocol of the sending host computer to the receiving computer's protocol.
In addition to the time-delays associated with protocol variances, the Internet when connecting to an end-user via Plain Old Telephone Service (POTS), has a maximum data-transmission capacity of 3.6 kbytes per second, which is not enough for sending video images in real time.
The Internet system utilizes two types of file-transfer protocols (FTP) for copying a file from a host computer to the receiving computer: ASCII and binary. An ASCII file is a text file, while every other kind of file is binary. ASCII files are transmitted in seven-digit ASCII codes, while the binary files are transmitted in binary code. Because all data stored in computer memory is stored in binary format, when one sends a file in the Internet, it is sent in binary format. However, as discussed above, owing to the data-transmission constraints imposed by the Internet system because of the differing operating systems, and a multitude of gateways, routers, and bridges, the file data must be sent out in packets of a size no greater than 1536 bytes.
Since the size of just a thirty-second video may be as great as 2.5 megabytes, it may take up to one-half hour or more to send a thirty-second video over the Internet from a host computer to a receiving computer. Presently, there are compression techniques that compress the files in order to reduce this playback-time, which data is decompressed at the receiving computer. An example of such a system is VDOLive, manufactured by VDOnet Corp. of Santa Clara, Calif. However, these compression-systems still send the data in binary format, requiring packet-data sizes of no greater than 1536 bytes. Thus, even with these compression-systems, the length of time to receive a thirty-second video over the Internet after being buffered in the user's computer is near real time, but is unstable, choppy and drops as much as 96% of the video data over a conventional phone line.
In the Internet, there is an electronic-mail delivery system called E-mail. The E-mail system utilizes addresses to direct a message to the recipient, with each address having a mailbox code and a daemon, with the mail box and daemon being separated by the symbol @. In the E-mail delivery system, all of the messages or “mail” are routed through selected routers and gateways, until it reaches what may be called a “post office” that services the recipient to whom the electronic mail is to be delivered. The “post office” is a local server. The need for these local “post offices” is because there is every reason to assume that the recipient-computer, to which the mail is being sent, is either not powered up, or is performing a different task. Since most computers in the Internet are not multi-tasking machines, such as, for example, computers running on the DOS operating system, if such a computer be engaged in performing a task, it is not possible for it to receive the E-mail data at that time. Thus, the local “post office” or server stores the message until such a time as it may be delivered to the end-user to whom it is intended.
In the E-mail system, there has really been only one format standard for Internet messages. A variation has been the MIME version, which stands for Multipurpose Internet Mail Extensions, which defines a new header-field, which is intended for use to send non-text messages, such as multimedia messages that might include audio or images, by encoding the binary into seven-digit ASCII code. Before MIME, the limitation of E-mail systems was the fact that it would limit the contents of electronic mail messages to relatively short lines of seven-bit ASCII. This has forced users to convert any non-textual data that they may wish to send into seven-bit bytes representable as printable ASCII characters before invoking a local mail UA (User Agent, a program with which human users send and receive mail). Examples of such encodings currently used in the Internet include pure hexadecimal, uuencoded, the 3-in-4 base 64 scheme specified in RFC 1421, the Andrew Toolkit Representation [ATK], and many others. Even though a user's UA may not have the capability of dealing with the non-textual body part, the user might have some mechanism external to the UA that can extract useful information from the body part. Moreover, it does not allow for the fact that the message may eventually be gatewayed back into an X.400 message handling system (i.e., the X.400 message is “tunneled” through Internet mail), where the non-textual information would definitely become useful again. With MIME, video and/or audio data may be sent using the E-mail system. MIME uses a number of header-fields, such as “Content-Type” header field, which can be used to specify the type and subtype of data in the body of a message and to fully specify the native representation (encoding) of such data; “text” Content-Type value header field, which an be used to represent textual information in a number of character sets and formatted text description languages in a standardized manner; “multi-part” Content-Type value, which can be used to combine several body parts, possibly of differing types of data, into a single message; “application” Content-Type value, which can be used to transmit application data or binary data, and hence, among other users, to implement an electronic mail file transfer service; “message” Content-Type value, for encapsulating another mail message; “image” Content-Type value, for transmitting still image (picture) data; “audio” Content-Type value, for transmiting audio or voice data; “video” Content-Type value, for transmitting video or moving image data, possibly with audio as part of the composite video data format; “Content-Transfer-Encoding” header field, which can be used to specify an auxiliary encoding that was applied to the data in order to allow it to pass through mail transport mechanisms which may have data or character set limitations. Two additional header fields may be used to further describe the data in a message body: The “Content-ID” and “Content Description” header fields.
However, there are considerable drawbacks and deficiencies in transmitting video images and/or audio data over the Internet using E-mail's MIME. Firstly, there is often considerable time delays,
Feng Jie
Mages Kenneth G.
Cangialosi Salvatore
Hamman & Benn
HyperLOCK Technologies, Inc.
LandOfFree
Method of secure server control of local media via a trigger... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method of secure server control of local media via a trigger..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of secure server control of local media via a trigger... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2564000