Data processing: software development – installation – and managem – Software program development tool – Managing software components
Reexamination Certificate
2000-06-14
2004-05-25
Nguyen-Ba, Antony (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Managing software components
C717S162000, C717S169000, C717S175000, C719S332000
Reexamination Certificate
active
06742176
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to software that employs plugin components. More particularly it relates to such software used to manage, modify, and reproduce media resource data from files, streaming sources, and other sources.
2. Background
Digital audio player software application manages audio data from various sources such as serial, file, and streaming data via networks, disk storage, optical storage, etc. and compressed (or uncompressed) according to various different protocols. The application also outputs such files to various different output devices, such as visual output software or hardware, hardware digital-audio converters (DACs), files, broadcast systems, etc. To provide flexibility, the application is designed to accept plugin software components to provide for feature upgrades. For example, a plugin might be added to permit audio data to be visualized during simultaneous playback in a way that is similar to a visual light show that might be employed at a dance hall or concert. The visual output might be applied to a projector, a computer screen, or an external light array. Plugins, in addition to permitting output to varying devices, may also allow modification of sound files such as alternative file formats, resampling, sound effects and distortions, etc. Such modifications, of course, may be inherent in certain types of output conversions as well.
The invention may be used in the environment of digital audio players. Currently, media players employ plugin technology that allows features to be upgraded using modular components that can selectively replace existing components or add new features to an existing program. Plugin technology is usually associated with the Internet, for example it is used to provide web browsers with the new capabilities, such as for reproducing media files, viewing 3-D interactive media, playing sound and video files, performing calculations, etc.
One example of a program that uses plugin technology is a streaming media player that runs on PCs. Features may be added by installing new plugin components. For example, the ability to view animations that respond to music could be added to a streaming media player application that reproduces sound from compressed audio files. Another way that such an application could be enhanced is by adding a plugin that is capable of reading a new source file format.
Referring to
FIG. 1
, an example architecture for a streaming or file media player is Winamp by Nullsoft, Inc. The system hosts plugins for audio decoding
120
which may be any of various different formats such as MP3
120
. In this architecture, the system accepts a request from a user interface for a particular file and based upon the extension (e.g., WAV, MP3, etc.) it passes it to a plugin that has been registered to handle that format. The plugin then reads the file from the resource and decodes it to generate the output audio (e.g., pulse code modulated) stream to an output device
130
. This arrangement requires that the system designer know in advance the capabilities of each plugin. The structure is monolithic and therefore does not allow reading, file format handling, and decoding functions to be upgraded without a new monolithic plugin.
Referring to
FIG. 2
, a more flexible architecture is exemplified by DirectShow® by Microsoft®. In this architecture, the host system selects a file reader plugin based on the requirements of the resource selected by the user. This is done dynamically through a file selection user-interface (UI) that permits the user to select a file to be played. The selection is based on the match between the selected resource and the available reader plugins. Two examples are shown, an Internet file reader
200
for http files and a local file reader
205
for local (e.g., disk) files. The output of the selected file reader (the local file
205
, in this case) is connected to the input of an appropriate decoder. Here again, one of a variety of plugins may be available such as for DIS audio format files
215
, for MP3 files, and for WAV files. The output of the selected decoder is then applied to the output device.
The selection of decoder in the above system occurs as follows. A convention is established whereby each decoder provides to the system a bitmask the system then uses to test the data stream. A predefined amount of data is applied to the bitmask and if the result is a particular predefined sequence (e.g., all “1” s or all “0 ” s), the plugin is accepted to decode the data. As a result, if there are any errors in the file or substantial misalignment between the data stream and bitmask, the test will fail.
Note that in both of the above architectures, there may be more than one output in the resulting stream. For example, a decoder plugin could produce audio and video streams.
The architecture of
FIG. 2
overcomes the inflexibility of that of
FIG. 1
, but is incapable of handling files packaged in any form other than one that can be decoded directly into an audio stream by a monolithic decoder plugin. Such file formats may even have been used to embed multiple files in a single wrapper such as a ZIP file and such an architecture has no mechanism for dealing with such cases. Also, the host system must make decisions as to which inputs and outputs to connect. A plugin may offer different features from those the host system has been programmed to recognize, such as an ability to handle an unknown file format, the ability to correct errors in certain types of files, the ability to generate outputs that the host does not recognize, etc. This limits ability of the host to take advantage of plugin's capabilities without changes to the host system and its ability to manage media files embedded in non-media-file formatting or encrypted.
Another issue that arises in connection with plugin architectures is security. For example, a user may be authorized to play a file, but not authorized to reproduce it. Or the user may be allowed to reproduce it, but only in a certain format. These rights may arise in connection with a prior payment or simply by virtue of the media type. In prior art systems, security is administered by the host system. This requires the host recognize when a security situation exists with a plugin that is going to be used and responding to it. This also limits the variations on the options available when new plugins offer new ranges of features.
In any plugin architecture, it is necessary to authenticate components. This kind of security is intended to insure that unauthorized things do not happen such as the introduction of viruses. The technology for authenticating plugin components is mature and outside the scope of this document. In the area of media reproduction, modification, and playback, there is an entire realm of uses that media authors and vendors would permit, if plugin components were restricted to interacting in only predefined ways. For example, a user could pay a very low price for an audio file if the seller were assured that the file could only be played once. A consumer could have a tremendous library of music instantly at his disposal, paying only for the use of the volumes in the library. This kind of scheme might be readily implementable in a native application. But in an application that admits all manner of plugin components it presents a formidable problem. How does the native application insure that plugin components will not behave in an unauthorized way? One way is to fall back on a gate-keeping function of the host system, which gave rise to the authentication systems that are in use today. The user or the application either permits a plugin to operate in the application or not. That is, the developer provides mechanics in the player that will either accept or reject a plugin based on the identity and authentication of the plugin. A common example of this is web browser plugins. Often users are queried as to whether the plugin should be accepted or not. The issue of whether the user has rights to disto
Adatia Al-Riaz
McCann Andrew
Million Tony
Vinen Nicholas
Fish & Richardson P.C.
Lycos, Inc.
Nguyen-Ba Antony
LandOfFree
Secure flexible plugin software architecture does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Secure flexible plugin software architecture, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Secure flexible plugin software architecture will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3258523