This application claims the benefit of priority to and incorporates by reference U.S. Provisional Application Ser. No. 60/493,608 filed Aug. 8, 2003.

BACKGROUND OF THE INVENTION1. Field of the Invention

The present invention relates to information distribution. More particularly, the invention relates to the usage of media with content for the distribution of remotely updateable information.

2. Description of the Prior Art

The distribution of multimedia content and other data has traditionally been achieved by using media, such as the floppy disk, magnetic tape or compact disc (CD), containing information supplied by the content provider. Typically, the media are pre-recorded with information from the content provider and, after being sent to the end user, the end user views the information by reading the media. The information is meant to be static for the end user, that is, after the information is pre-recorded onto the media, the information is not changed or updated by the content provider. Such change or update would be impractical, as it would require the end user to return the media to the content provider for updating.

For instance, a mail-order retail content provider might pre-record a sales catalog onto a CD and send the CD to a consumer. The consumer would then access the CD and shop for items in the retailer’s catalog. If the retailer were to update the catalog in any way (e.g., error connection, price update, cancelled inventory, etc.) the consumer’s CD would be out of date. For write-once media used for content distribution, such as standard CD and DVD, distributed information cannot be updated. The retailer would have to send the consumer a new CD with the new catalog information.

In the case of re-writable media (e.g., floppy disks, CD-RW, key-chain RAM, etc.), the update process is possible. The end user would return the re-writable media to the content provider and the content provider would over-write the old information with new information. However, due to economic constraints, information-containing media are typically distributed in large quantities. It would be impractical, if not impossible, for content providers to update their distributed re-writable media in this manner.

With the advent of the Internet and computer networking, data can be “downloaded”; that is, transferred from one computer to another computer over the network. The Internet and related browser applications simplified this process by allowing content to be served anywhere, anytime, by using HTTP (Hyper-Text Transport Protocol). In the early development and use of HTTP, most of the content on the Internet was “static” in that it was not based on a constantly updated information source, such as connected to live database. With the increased use of scripting and web-based database access/query technologies such CFML (Cold Fusion Markup Language), ASP (Active Server Pages), Perl (Practical Extraction and Report Language) PHP (PHP: Hypertext Preprocessor), and Java Servlets, the content served from one computer to another over the network can be “live” or “dynamic” in the sense that it can be updated in real-time via a database or other application program on the server. In this way, the end user potentially gets a new or different experience each time they are served content from a particular computer. For instance, a website with the weather forecast might change from hour-to-hour or minute-to-minute. Such information would not be useful if pre-recorded on a fixed media.

Therefore, what is needed is a method and system for continually distributing updateable content to an end user using media that contains static information, without requiring the content provider to re-write the media or to provide updated media to the end user.

SUMMARY OF THE INVENTIONA method and system for keying media allows for the distribution of updateable content to an end user. The media are any type of processor readable, portable apparatus that includes a preinstalled Keying Application and unique Source ID. A particular medium is provided to an end user and the end user runs the Keying Application on a network-connected display device, such as a computer or PDA. The Keying Application interacts with a Content Server via the network connection. The end user also interacts with the Content Server via the Keying Application. Through these interactions, the Content Server distributes specific updateable content to the Keying Application, which displays the specific content to the end user.

BRIEF DESCRIPTION OF THE DRAWINGSThese and other aspects of an embodiment of the present invention are better understood by reading the following detailed description of the preferred embodiment, taken in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates the Media Keying content distribution process according to an embodiment of the present invention;

FIG. 2 illustrates the initial interaction between the Keying Application and the Content Server according to an embodiment of the present invention;

FIG. 3 illustrates how the system delivers correct customized content through the Keying Application according to an embodiment of the present invention; and

FIG. 4 illustrates a system architecture according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTIONThe present invention will now be described in detail with reference to the drawings, which are provided as illustrative examples of the invention so as to enable those skilled in the art to practice the invention. Notably, the figures and examples below are not meant to limit the scope of the present invention. Where certain elements of the present invention can be partially or fully implemented using known components, only those portions of such known components that are necessary for an understanding of the present invention will be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the invention. Further, the present invention encompasses present and future known equivalents to the known components referred to herein by way of illustration.

FIG. 1 illustrates the process 100 of using media keying to distribute updateable content according to an embodiment of the invention. As shown in FIG. 1, a content provider stores on, or uploads onto, a particular media a Keying Application and an associated Keying Application Source ID (block 110). One of ordinary skill in the art will easily understand that any type of media, volatile or non-volatile, can be used (e.g., floppy disk, magnetic tape, EEPROMS, CD, DVD, memory card, etc.), all of which are within the scope of the present invention. The Source ID may identify the distribution point of the media, or the identity/profile of an end user who will be given the media. For instance, with a department store content provider, one media that is distributed to customers of that store might contain a Source ID that identifies the customer as having shopped in the sporting goods section of the store. With this information encoded onto the media, the media becomes personalized from the standpoint that a specific demographic or profile is established in relation to those particular customers.

The media containing the Keying Application and Source ID may be produced locally, at the distribution site, or pre-produced in mass quantities. Further, the media may each be given a unique serial number. The store or merchant or content provider may then associate a particular serial number or group of serial numbers as related to a particular department within the store or to the store itself, or type of content, as desired. The Keying Application is discussed in greater detail below.

Once produced, the media can be distributed to end users (block 120). The media can be distributed via any means, such as regular mail, at a business site, in a mall kiosk, or, in the case of a mini wallet-sized CD, even handed out as a business card. When the end user has possession of the media, the media can be accessed using a media accessing/reading device, such as on a personal computer system, that is capable of accessing a network. The network device can access the media via any means available to it, such as a serial or parallel connection, a USB connection, a floppy disk drive, a CD drive, a DVD drive, and the like. The present invention is intended to encompass any device capable of accessing/reading the media and connected to the network (e.g., laptop computer, Personal Digital Assistant, cell phone, etc.). Upon accessing/reading the media, the Keying Application is launched by any suitable process, for example, either automatically or by user intervention, or a combination of user intervention and automation (block 130).

Launching the Keying Application starts a self-contained, user interface. This user interface is specific to the device upon which the media is accessed/read. For example, in the case of running the media on a personal computer system, the user interface may be a network browser or browser-like application, which eliminates the need for use of any other external programs (i.e., external to the Keying Application) to access the content. As additional examples, the Keying Application might be a text-based, prompt-and-respond user interface, or a GUI with user initiated hyperlinks. The Keying Application then checks to see whether the Content Server is available (block 135). The Content Server is a source of updateable information ultimately displayed to the user and may be one system or many systems distributed around a network. The process of checking the Content Server is illustrated throughout this disclosure as checking for the availability of an Internet connection; but it can also take other forms, such as checking an Internet connection, checking the operability of the Content Server itself or checking the connectivity/compatibility of the Content Server to the user’s device.

If the Content Server is not available, the Keying Application will determine whether the Content Server can possibly become available (block 137). For example, the Keying Application might check to see if the user’s system allows it to automatically establish the necessary network connection, and if so, attempt to make that connection. Further, the Keying Application might sequentially check the user’s system for various possible network connections (e.g., wired, wireless local area networks, wireless wide area networks, etc.) and select the most desirable connection based on predetermined criteria (e.g., maximum available bit rate, number of available connections, distance to nearest wireless access point, etc.). If the Content Server can possibly become available within a specific amount of time (i.e., the Keying Application times out after attempting to automatically connect via the user’s system) or through specific actions (e.g., automatically connecting on its own, prompting the user to connect, etc.), the Keying Application waits for the Content Server to become available (block 138). If the Content Server cannot become available within a specified amount of time or through specific actions, the Keying Application can take one of two courses of action. First, the Keying Application can simply terminate execution (block 139). This will end the user’s ability to view any of the distributed, updateable information. Second, the Keying Application can launch, as is typically the case today, predefined static content stored on the same medium as the Keying Application (block 139). The predefined static content is loaded onto the medium at production and does not require the Content Server connectivity for delivery. However, this predefined static content will not be updateable until after the Keying Application establishes Content Server connectivity.

Once the Content Server is available, the Keying Application interacts with the Content Server (block 140). This interaction can take the form of the Content Server delivering custom content to the user based upon the Source ID or presenting the user with interactive content requiring responses back and forth between the Content Server and the user. The interaction can also include functions such as browsing, multi-media playing, forms processing, or any functionality that is possible via network communication. Thus, at block 150, dynamic content which is customizable based at least in part upon the Source ID, can be delivered to the end user from the content server. This interaction is discussed in further detail below with reference to FIG. 3. Content may include, for example, directories and catalogs of goods and services.

FIG. 2 illustrates the initialization of interaction between the Keying Application and the Content Server according to an embodiment of the present invention. As shown in FIG. 2, the Keying Application, when launched, first checks for the presence of an Internet connection (block 210). As previously discussed, this check might include other or additional Content Server connectivity checks. If the Internet connection is not available, the Keying Application checks whether the system or device upon which it is running allows for automatically establishing an Internet connection; that is, whether an Internet connection can be made available (block 225). If the Keying Application can automatically establish an Internet connection, it does so (block 229) and continues operation. If an Internet connection is not available and cannot automatically be established, the Keying Application will attempt to establish a connection using the host machine’s settings, or notify the user that a connection is needed for distribution of the updateable content (block 227).

If an Internet connection is, or can be made, available, the Keying Application sends its Source ID to the Content Server (block 230). This allows a single Content Server to serve many different Keying Applications, with the Source ID being used as a differentiator, along with the unique User ID (discussed below), to separate what updateable content is distributed to which end user. This also allows this embodiment to distribute different content based on Source ID to a single user (based on unique User ID), as well as one content to multiple end users, while eliminated duplicative content distribution to users. For example, a single user may receive two different media, each with a different Source ID, yet serviced by the same Content Server. When accessed, each of the two media will launch its Keying Application and connect to the same Content Server. However, each Keying Application will initiate distribution of a different type or category of content from the Content Server because of the different Source IDs.

The Keying Application next checks to see whether a unique User ID is locally present (block 240) on the system and/or media currently being used for access. A unique User ID would be locally present if the user had previously established one through access of similar media to that currently being run. A unique User ID would not be locally present if this media access were the first for this user on this system, or if one previously established had been deleted from the system. If a User ID it is not locally present, the Content Server can create one and send it to the Keying Application (block 260). If the media containing the Keying Application is non-recordable, the Keying Application would record the received User ID on the local system or device running the Keying Application (block 270). Alternatively, or additionally, the Keying Application might record the received unique User ID on the media itself. The saved User ID might be in the form of a cookie or shared object, for example, and be saved on the media itself, in system memory (e.g., hard drive), or other non-volatile memory device or location.

Once the unique User ID is present to the local system, the Keying Application retrieves the User ID locally and sends it to the Content Server (block 250). Using this unique User ID, along with the previously transmitted Source ID, the Keying Application then interacts with the Content Server to deliver custom content to the user (block 280). In addition to the delivery of dynamic content, the Content Server uses the User ID identifier embedded in all communication with the Keying Application to record user data such as content seen or items purchased, user interface behaviors such as mouse and keyboard activity, and how long the user spends interacting with or reading specific content. These additional uses for the User ID are subject to appropriate privacy considerations.

FIG. 3 illustrates the interaction between the Content Server and the user according to an embodiment of the present invention. As shown in FIG. 3, the Content Server constantly attempts to link multiple User ID identifiers together in order to maintain data integrity and deliver the desired customized content to the user. This is done by comparing data between multiple User ID identifier sets. The same Keying Application, different Keying Applications with separate Source IDs, browsers, browser-like applications, or any other means of data collection may have collected the data considered for the current User ID.

A User, by using the Keying Application running on the local system or device, interacts with the Content Server (block 310). During interaction with the user, data is collected from the user (block 320) that the Content Server uses to determine the User ID uniqueness of the current user. Data fields determined to be unique to a user, or linking data, could be any collected data, such as a social security number, email address, names, passwords, etc. (block 330). The linking data could be one piece of data (e.g., social security number) or a combination of data (e.g., first name combined with last name and a mailing address) that would be unique to the user. When multiple User IDs are determined to be from the same user (block 340), the data from the other User IDs (i.e., those not in use during the current interaction between the Keying Application and the Content Server) are combined with the current User ID (block 350). The combined data from the multiple User IDs are referenced in the creation of customized content by the Content Server (block 360). The customized content derived from the combined data of the multiple User ID data sets are then delivered to the Keying Application (block 370), which displays the content to the user (block 380).

FIG. 4 illustrates a system view of an embodiment of the present invention. A media writer 410 can be used at a production facility or at the distribution site itself to write/record both the Keying Application and the unique Source ID onto the media of choice. This creates a medium 420 with a Keying Application that can be provided to an end user. The medium 420 may be, for example, a mini-CD/DVD or full-size CD/DVD, depending upon the implementation and use. However, one of ordinary skill in the art will recognize that the media 420 could be any of a wide variety of storage devices. The media 420 is distributed to the end user (not shown) by direct (e.g., from the vendor, marketer, or retailer) or indirect (e.g., mail or kiosk) means. The end user would then access/read the media 420 using any kind of local device or system 430. The only constraints on the local user system 430 are that it be capable of reading/accessing the media, running/displaying the Key Application and maintaining a network connection. Such local user systems are well-known in the art and will not be further described herein.

The local user 430 would then launch the Keying Application found on media 420. Assuming that a Network connection 440 is available, the Local User System 430 will interact with Content Server 450 via the Keying Application. Network connection 440 (as well as Network connections 470 Network connections 480) may be Internet connections or Intranet connections within an organization, or any other communication channel such as a cellular or other wireless connection.

Content Server 450 is a computer system or other information processing device that is available to the user through Network connection 440. Content Server 450 may contain one or more applications designed to access a Content Database 460, to which it is connected, access zero to many Administrator Systems 475 through Network connection 470, and zero to many Remote Systems 485 through Network connections 480. The Network connections 440, 470, 480 can be same or different types of connections. The Content Server 450 can compose and serve customer content to the Local User System 430 determined by data and parameters stored in Content Database 460, or the zero to many Remote Systems 485, or a combination of them. For instance, a Content Server 450 can be a computer administered by Linux running an Apache web server in conjunction with Perl, PHP, and C++ applications.

The Content Database 460 can be any program, parts of a program, or system that stores and qeuries data accessible by applications running on Content Server 450. For instance, Oracle, MySQL, SQL Server, an DB2 are common 3rd party content databases that could be used. Another instance of Content Database 460 could be an applications written in VBScript that queries and stores data using text and binary files on a hard drive. Another instance of Content Database 460 could be parts of an application (e.g., objects, functions, pieces of embedded code, etc.) residing on Content Server 450 that manage the querying and storing of data. The Content Database 460 may reside on the same system as the Content Server 450 or reside separately and communicate to the Content Server 450 through the Network connection 455, or other suitable connection.

Administrator Systems 470 can be any number of administrative systems that pass parameters to Content Server 450, which in turn stores the parameters locally or in Content Database 460. These parameters determine which content is presented to local user system 430, how content is assembled, and how the Keying Application displays the content (i.e., the look & feel). For instance, an Administrator System 475 could be a store owner in a remote location who uses a browser connected to the Internet (i.e., Network connection 470) to modify how inventory items are displayed to Local User System 430. An application residing on Content Server 450 receives the parameters and stores them in Content Database 460.

Remote Systems 485 can be any number of data sources that send and/or receive data to/from Content Server 450 for storage in Content Database 460. For instance, a store’s inventory data residing on a remote system is periodically synchronized with the information stored in Content Database 460, which are then queried by Content Server 450 and sent to the Local User System 430 for display. Remote System 485 can also be any number of data sources that send and/or receive data to/from Content Server 450 for direct real time access by Local User System 430. For instance, Content Server 450 using XML or another communication protocol could query a National Weather Service Remote System 485 for the most current weather conditions pertinent to Local User System 430. After receiving the weather data transmission from the National Weather Service Remote System 485, Content Server 450 formats the data to be useable by the Keying Application, which receives and displays the data on Local User System 430.

Although the present invention has been particularly described with reference to embodiments thereof, it should be readily apparent to those of ordinary skill in the art that changes and modifications in the form and details thereof may be made without departing from the spirit and scope of the invention. For example, those skilled in the art will understand that variations can be made in the number and arrangement of components illustrated in the above block diagram. It is intended that the appended claims include such changes and modifications.