EP1844385A2 - Appareils, procedes et systemes pour publicite, commerce electronique et interactions de clients en ligne a mise au point d'informations et imposition automatique integrees - Google Patents

Appareils, procedes et systemes pour publicite, commerce electronique et interactions de clients en ligne a mise au point d'informations et imposition automatique integrees

Info

Publication number
EP1844385A2
EP1844385A2 EP06718080A EP06718080A EP1844385A2 EP 1844385 A2 EP1844385 A2 EP 1844385A2 EP 06718080 A EP06718080 A EP 06718080A EP 06718080 A EP06718080 A EP 06718080A EP 1844385 A2 EP1844385 A2 EP 1844385A2
Authority
EP
European Patent Office
Prior art keywords
upuni
menu
items
menu items
target
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.)
Withdrawn
Application number
EP06718080A
Other languages
German (de)
English (en)
Inventor
David Sidman
Mark David Donoghue
Andrew E. Stevens
Haroon Elsarrag
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Content Directions Inc
Original Assignee
Content Directions Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Content Directions Inc filed Critical Content Directions Inc
Publication of EP1844385A2 publication Critical patent/EP1844385A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G06Q30/0273—Determination of fees for advertising
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/70—Information retrieval; Database structures therefor; File system structures therefor of video data
    • G06F16/74—Browsing; Visualisation therefor
    • G06F16/748—Hypervideo
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9558—Details of hyperlinks; Management of linked annotations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • the present invention relates generally to an apparatuses, methods and systems to access information across a communications network. More particularly, the disclosed invention relates to an apparatuses, methods and systems to Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactions (ISICI).
  • ISICI Customer Interactions
  • server refers generally to a computer, other device, software, and/or combination thereof that processes and responds to the requests of clients, often from across a communications network.
  • client generally refers to a computer, other device, software, user, and/or combination thereof that generates requests for service.
  • client and “user” are interchangeable, and are used as such throughout.
  • servers serve their information to requesting clients.
  • a computer, other device, software, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is commonly referred to as a "node.”
  • Networks are generally thought to facilitate the transfer of information from source points to destinations.
  • TCP/IP Transmission Control Protocol-Internet Protocol
  • DoD Department of Defense
  • TCP/IP was developed by a Department of Defense (DoD) research project to interconnect networks made by various and varying network vendors as a foundation for a network of networks, i.e., the Internet.
  • DoD Department of Defense
  • the development of TCP/IP was in part driven by a requirement by the DoD to have a network that will continue to operate even if damaged during battle, thus allowing for information to be routed around damaged portions of the communications network to destination addresses. Of course, if the source or destination address location itself is rendered inoperable, such delivery will not be possible.
  • the Internet is a packet-switched network and thus, information on the
  • IP addressing information called headers, which are used by routers to facilitate the delivery of the packets from a source to a destination across intermediary nodes on the Internet.
  • the packets Upon arrival at the destination, the packets are reassembled to form the original message, and any missing packets are requested again.
  • IP component of the protocol is responsible for routing packets of information based on a four byte addressing mechanism; the address is written as four numbers separated by dots, each number ranging from 0 to 255, e.g., "123.255.0.123". IP addresses are assigned by Internet authorities and registration agencies, and are unique.
  • the TCP portion of the protocol is used for verifying that packets of information are correctly received by the destination computer from the source, and if not, to retransmit corrupt packets.
  • Other transmission control protocols are also commonly used that do not guarantee delivery, such as User Datagram Protocol (UDP).
  • UDP User Datagram Protocol
  • Web Wide Web
  • Web WorldWideWeb.app
  • Web browsers were designed to facilitate navigation and access to information
  • information servers were designed to facilitate provision of information.
  • Web browsers and information servers are disposed in communication with one another through a communications network.
  • Information Servers function to serve information to users that typically access the information by way of Web browsers.
  • information servers typically provide information to users employing Web browsers for navigating and accessing information on the Web.
  • Microsoft's Internet Explorer and Netscape Navigator are examples of Web browsers.
  • navigation user interface devices such as WebTV have also been implemented to facilitate Internet navigation.
  • Many other navigation interfaces and devices also exist for navigating the Internet such as File Transmission Protocol (FTP), email interfaces (e.g., mailto:), search queries, database queries, scripts, Web Services (such as Microsoft's .NET or Sun Microsystems' SunONE), and the like.
  • FTP File Transmission Protocol
  • email interfaces e.g., mailto:
  • search queries e.g., database queries, scripts, Web Services (such as Microsoft's .NET or Sun Microsystems' SunONE)
  • Some of these interfaces are intended for use by human beings, and some are intended for use directly by machines, devices, software programs, and the like.
  • URL UNIVERSAL RESOURCE LOCATOR
  • An URL is an address that is typically embodied as a hyperlink in a Web page or is typed into a Web browser.
  • URLs for a given resource refer only to a location for that resource.
  • the reference to the location is achieved through the use of an unresolved IP address in conjunction with a directory path and file name; e.g., "http://www.aWebSite.com/aFolder/aFile.html”.
  • the URL directs the browser to connect to the computer named "www" in the domain "aWebSite.com,” and to request the file named "aFile.html” stored in directory "aFolder” at that computer.
  • the Corporation for National Research Initiatives has created and implemented a new means of naming and locating information, called the Handle System.
  • the Handle System is designed to improve upon or replace the current use of URLs.
  • the Handle System introduces a level of indirection to locating and distributing information over the Internet.
  • the Handle System is a general-purpose system for naming resources. Instead of being assigned a URL based on a particular resource's current network location, a resource may be assigned a Universal Name Identifier (UNI).
  • a UNI is a form of Universal Resource Identifier (URI).
  • URIs include both UNIs and URLs.
  • a UNI unlike a URL, serves and shall be regarded henceforth as a name for the resource that is persistent regardless of changes in the resource's location or other attributes.
  • URN Universal Resource Name
  • URN Universal Resource Name
  • a Handle is a type of URN.
  • a Digital Object Identifier (DOI) is a type of Handle.
  • various forms of UNIs include Handles, URNs, DOIs, and/or the like.
  • the various terms and/or forms of URIs will be used interchangeably throughout this document, and may be assumed to be interchangeable unless stated otherwise.
  • a Handle is a unique name, which is registered with the Handle System along with the current network location of the named resource. This location information commonly takes the form of a URL.
  • One common type of Handle is known as a Digital Object Identifier (DOI). Handles may be then distributed to users in lieu of a URL, and superficially appear to function similarly to a hyperlink.
  • DOI Digital Object Identifier
  • Handle When a user encounters a Handle, the user may select or enter the Handle much like a URL hyperlink, so long as the user's Web browser is capable of making Handle requests. Such an encounter triggers an automated process to look up a resource's current location.
  • the current location of the resource is associated with the resource's Handle in a directory made available by the Handle System, which in turn directs the user to the resource's current location.
  • the Handle System directory entry can be updated, thereby assuring a persistent association between a Handle and the resource it identifies.
  • An analogy can be made to the physical world: knowing only a URL for a given resource is akin to knowing only a person's street address, and not her name.
  • the Handle System allows resources to be permanently named by way of a Handle, and it allows the current network location of resources to be looked up based on that name in a Handle System directory.
  • Advertising technologies have been developed in an effort to capitalize on the Internet's ability to track end user behavior in ways not possible with traditional media: e.g., with television or print magazine ads, where there is no mechanism by which to measure the end user's actual interaction, or even to verify that the end user has seen the ad at all.
  • Companies have created “contextual ads” (such as Google's AdSense) which "read” the content of a Web page and then place certain ads on that page in response to the page's context (e.g., Google "Sponsored Links," which are selected and placed in a Web page in response to the particular subject-matter of the page).
  • DOIs Digital Object Identifiers
  • IP addresses and other location-based addressing schemes.
  • DOIs enable access to information over a communications network by providing a persistent identifier for information that may be regularly relocated.
  • DOIs overcome the limitations of network addressing schemes limited to addressing locations by providing a mechanism to associate identifiers with information through an added level of indirection instead of associating identifiers with locations.
  • DOIs provide a mechanism that allows for the association of an identifier with information instead of a location
  • DOIs in and of themselves do not provide for the access of multiple and/or varying instances of a piece of information in various locations, formats, or the access and/or tracking of various services associated with a given piece of information, based on various contexts of use.
  • a method for using at least one computer to generate a reference menu.
  • the method comprises receiving a request for a unique persistent universal name identifier (UPUNI) from a requesting client accessing content and generating an UPUNI menu from the UPUNI menu specification, wherein the UPUNI menu specification is used to specify values from UPUNI record information with which to populate the UPUNI menu.
  • UPUNI unique persistent universal name identifier
  • ISICI Integrated information-engineered and Self-Improving facility for advertising, e- commerce and online Customer Interactions
  • ASCUPURI Unique Persistent Universal Resource Identifiers
  • the ISICI includes a feedback loop enabling improvement of itself as driven by the actual interaction of end-users with the ISICI. Based on the tracking of actual end-user interaction with these menus, a feedback loop can be created such that the menus can be revised and improved based on the empirical tracking data that is fed back into a creation/maintenance cycle.
  • the disclosure of the ISICI provides numerous embodiments on how such tracked information may be fed back into the creation/maintenance cycle.
  • information may be fed back manually (i.e., based on human review of the tracking results and human judgment as to the most appropriate revisions to the menu and which revisions in turn may be implemented manually via the MultiLink editor), through an automated "assembly line" to revise/create a menu (i.e., so that on a going-forward basis, this system will automatically create and maintain different menus), fully automatically (for example, where the order of menu choices may be rearranged based on the relative popularity of the different menu choices, as captured by measuring actual user behavior in interacting with the menu), and/or the like.
  • These measurements of behavior may include tracking the click-through rates associated with various menu choices, tracking the subsequent behavior (e.g. post click-through) in terms purchasing or other transactions, tracking the measurements of the time spent by the user hovering over various menu choices, tracking the measurements of the frequency with which various menu choices are rolled over, and/or the like.
  • This feedback to the menu creation/maintenance cycle may also come from other sources besides the end user's behavior in interacting with the menus.
  • sources may include: independent metrics of the user's purchasing behavior (either subsequent to the user's click-through of the menus or entirely unrelated); independently- recorded user preference information (either individually or in aggregate); independently- recorded user information that is associated with a category of user (e.g., anonymized metrics profiling a type of user by income, interests, demographics, preferences, and/or the like — such an embodiment would not associate profiled information with any individual); metrics recorded by the site hosting the menu (e.g., profiling based on time of day, geographical location of site visitors, etc.), and/or the like.
  • independent metrics of the user's purchasing behavior either subsequent to the user's click-through of the menus or entirely unrelated
  • independently- recorded user preference information either individually or in aggregate
  • independently- recorded user information that is associated with a category of user e.g., anonymized metrics profiling a type of
  • the menu improvements driven by this feedback loop may include changes in the order of links on the menu, selective inclusion or suppression of different links (e.g., either centrally in the master control record controlling the menu universally, or solely in a locally-customized version of the menu on a particular web site), selective retrieval of data from back-end systems in order to populate the menus differently, the inclusion or suppression of graphics or video or other multimedia effects, and/or the like.
  • the menu improvements need not be limited to improvements to encourage purchasing behavior; nor does the system need to be limited to advertising- oriented applications at all. Any system that serves up information or otherwise services end users or even computer programs can utilize the present invention. An information system by which a city, state or federal government provides information to its citizens can utilize the present invention to continuously improve the menus based on measuring what kinds of information most citizens actually want in a given context.
  • a military system that serves up intelligence information or military logistics information could utilize the present invention to offer the most useful information and links based on external factors such as the elevation of a certain suspected terrorist onto a high-priority watch list, the elevation of a building or other physical asset onto a similar high-risk watch list due to intelligence gathered about a possible terrorist strike, sensor data monitoring enemy troop movements, and/or the like.
  • a bank or insurance company that wishes to help its customers or even its internal staff to navigate through complex and information-intensive processes can use source data ranging from user behavior to internal prioritizations of services it wishes to market.
  • FIGURE 1 is of a mixed data and logic flow diagram illustrating embodiments of a Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactions (ISICI);
  • ISICI Customer Interactions
  • FIGURE 2 is of a mixed data and logic flow diagram illustrating embodiments of an Autolinker
  • FIGURE 3 is of a mixed data and logic flow diagram illustrating embodiments of an IntraConnector
  • FIGURE 4 is of a logic flow diagram illustrating embodiments of a
  • FIGURES 5-6 are of diagrams illustrating embodiments of a MultiLink menu editor and personal DOI;
  • FIGURE 7 illustrates IP addressing mechanisms
  • FIGURE 8 illustrates the access of information through Digital Object
  • FIGURE 9 provides a schematic view of a Handle and an enhanced DOI grammar
  • FIGURE 10 provides an overview of the resolution mechanism for allowing users to access the desired information
  • FIGURE 11 provides an overview of the sequence of actions that a user performs to access information
  • FIGURE 12 provides an overview of some of the exemplary mechanisms for accessing information over a communications network by resolving a DOI to obtain the URL;
  • FIGURE 13 provides an overview of an exemplary DOI system
  • FIGURE 14 illustrates example advertisements served by an advertising
  • FIGURE 15 illustrates example MultiLink applications
  • FIGURE 16 illustrates example MultiLink applications and user interfaces
  • FIGURE 17 is of a mixed data flow diagram illustrating embodiments of a
  • FIGURE 18 is of a diagram illustrating graphical embodiments of a
  • FIGURE 19 is of a logic flow diagram illustrating embodiments of a MultiLink menu tracker
  • FIGURE 20 shows a MultiLink tracking user interface and tracking log
  • FIGURE 21 shows a purchase cycle
  • FIGURE 22 is of a block diagram illustrating embodiments of a Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactions controller;
  • FIGURE 1 is of a mixed data and logic flow diagram illustrating embodiments of apparatuses, methods and systems to Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactions (ISICI).
  • ISICI is comprised of three components: 1) creation and maintenance of MultiLink menus 181; 2) registration and updating of the underlying multilink records 182; and 3) distribution/syndication of the MultiLink menus 183.
  • the ISICI also features the tracking of syndicated MultiLink menus, which are fed back 140, 175 from the distribution/syndication component 183 to the creation/maintenance component 181 so that MultiLink menus may be optimized over time.
  • the Autolinker creates MultiLink DOIs in the first instance 120. Then these DOIs get deposited (i.e., registered) 130 into the global directory (e.g., the Handle System) 113. Then the MultiLink DOIs are ready to be invoked by links or other "requestors" out on the communications network (e.g., the Internet).
  • the Syndicator 135 is a mechanism for getting those links or requestors distributed out onto Web pages and other places. The Syndicator can provide filtering, modifying and/or otherwise customizing MultiLink Menus and data that are retrieved from those DOI records 113.
  • Autolinker automatically creates interlinked MultiLink menus of a user's (e.g., client's) information, services, transactions, etc. in connection with any target object or content.
  • the MultiLink menu comprises two components: a MultiLink DOI and, optionally, a menu specification describing the layout and items from the MultiLink DOI to be displayed in the menu. If no menu specification is provided, the full DOI MultiLink may be used as the specification for generating the menu.
  • These MultiLinks may point to a customer's site, or anywhere else. For example, the MultiLinks may point to various retailers for purchasing, to related information at other companies' sites, in other companies' systems, and/or the like.
  • customer metadata is employed by the Autolinker
  • the customer metadata may further target various objects, i.e., the metadata itself may contain DOIs.
  • the metadata may be obtained from a number for sources. Commonly, the metadata may be exported from a customer's database 119. The database may be queried for products, or other target objects for which the customer would like to create MultiLinked DOIs. For example, a publishing customer may query their own database selecting top selling books and accompanying information (e.g., title, author, year, best seller ranking, etc.) 175.
  • a hospital may query its own patient records and generate MultiLinks for each patient.
  • MultiLinked DOIs for hospital records
  • the costs for medical administration can be significantly lowered by having persistent and universally accessible references to patient and administrative records. Similar economies would apply to ancillary companies such insurance companies.
  • ancillary companies such insurance companies.
  • by providing a singular reference by way of a MultiLink healthcare providers, insurers and patients can all access electronic medical records and related account and insurance information all with a single reference. This will greatly cut down on clerical errors, administrative overhead costs in maintaining numerous duplicate and often inaccurate record copies.
  • a retailer may track Radio Frequency Identification (RFIDs) device activity.
  • RFIDs Radio Frequency Identification
  • each RFID is provided with a unique identifier and registered with the Handle system, thus, each RFID has its own DOI.
  • a retailer may register a block of DOIs and embed each of the RFIDs with any of the registered DOIs at the time of RFID manufacture.
  • the RFID numbers could be registered as DOIs at the time of RFID manufacture but not actually embedded into the RFIDs themselves; then when an RFID number is read by a reader device, the reader device could access the Handle System by formulating its Handle request using the RFID number which would have been registered previously as a DOI. As such, any system scanning for an RFID would obtain a DOI and access the Handle system.
  • the MultiLinks associated with the Handle System's DOI record could link the user or the reader device to any information relating to that RFID in a permanent, persistent and comprehensive manner.
  • the system at the point of access may modify the DOI MultiLink record in a transaction's sub-component of the RFID's DOI record that is modifiable by that party (e.g., the party has appropriate access control rights to make such edits); as such, a DOI record can provide full transactional tracking related to the item with the RFID.
  • the retailer may track DOI enabled RFEDs via its own system database 119; as such, the retailer may select RFID related fields for exporting; those fields may then be exported as metadata 105 for use by the Autolinker 120.
  • GPS information regarding RFID's transaction and/or whereabouts may be saved with each transaction.
  • This transaction and location based information may constitute a transaction and location history for the DOI enabled RFID.
  • the utility here is that a single identifier would be able to provide a total transaction and movement history regarding a particular item.
  • a number of formats may be used to encode the customer metadata such as Microsoft Excel, tab delineated fields and values, XML, and/or the like.
  • various databases allow for the export of selected database records into the various export formats as a metadata submission to the Autolmker 110.
  • a user may opt 110 to employ autolinking 120 or to generate MultiLinks manually with the Handle Editor 115.
  • the Handle Editor will be described in greater detail in Figures 5-6.
  • Autolinking 120 will be described in greater detail in Figure 2, but generally comprises establishing relationships between the MultiLink DOI and menu 122, constructing pointers for the MultiLink DOI record 124 and ultimately generating the MultiLink menu 126.
  • DOI MultiLink record 130 Once the metadata is put in the form of a DOI MultiLink record 130, it may be registered in a DOI directory 113 and thereafter identified and resolved and accessed via DOI resolution servers 133.
  • DOI resolution servers may be global servers accessible to the public at large, or they may be local servers on an intranet, and thus, only accessible to users and systems on the intranet.
  • local intranet administrators may modify and/or customize the local "master" DOI record, if they are the owner of that master record.
  • the local intranet administrator is not the owner of that "master" DOI record, then the local administrator still has the ability to modify, or cause local programs or systems to modify, the data or menus that are returned from the master DOI record, so that in the local environment it points to local resources or locally-specified resources instead of or in addition to the original creator's resources.
  • local intranet administrators may keep their locally-originating DOI requests from resolving to the global Handle Servers, and instead direct resolution to a local resolver.
  • a menu specification that may have been generated 126 by the Autolinker 126 would be supplied to the Syndicator 135 where it may be saved in the ISICI database.
  • such a database may be used to hold specific information necessary to drive customization of syndicated DOI Multilinks.
  • the Autolinker 120 requests that the Syndicator 135 generate a MuItiLink menu and the Autolinker then saves the menu as part of the DOI record MuItiLink 130.
  • the Syndicator 135 enables MuItiLink menus and navigation to references targeted by the menus.
  • An example MuItiLink menu is illustrated 175, in this case the MuItiLink menu is for a MuItiLink DOI of a book.
  • the MuItiLink menu has already been generated.
  • the MuItiLink' s DOI record has already been stored in the DOI directory 113.
  • a menu specification for the MuItiLink menu has been stored in the ISICFs database.
  • a reference to the MuItiLink menu is embedded into a Web page 140.
  • the reference code e.g., HTML code calling for a Javascript representation of the MuItiLink menu
  • An example embedded reference code may have the following form:
  • the Web page expects to obtain Javascript and the source is supplied with a reference to the Syndicator along with an associated DOI MuItiLink.
  • the request for the script is provided to the Syndicator 135, e.g., by way of a HTTP post request.
  • the Syndicator interprets the request for the MultiLink menu by parsing for the DOI MultiLink and the source of the request.
  • the Syndicator may then obtain the DOI MultiLink record 130 from the DOI directory 113.
  • the Syndicator may query its own internal database for a MultiLink menu specification for the MultiLink.
  • the MultiLink menu specification may be keyed on the DOI itself as it is a unique value. If no menu specification exists, then the Syndicator may generate its own menu specification. Syndicator operations will be described in greater detail in Figure 4.
  • the ISICI may then use the MultiLink DOI record and/or the MultiLink menu specification to generate the MultiLink menu for the MultiLink DOI, e.g., generating Javascript code. It should be noted that numerous user interface platforms other than Javascript and Web browsers may be employed to generate the MultiLink menu.
  • the Syndicator 135 Upon generating the MultiLink menu, the Syndicator 135 provides the MultiLink menu back to the requesting user's Web browser 140 where the menu is displayed 175. Once the menu is displayed by the user's Web browser, the user may traverse the menu with a cursor and engage selections. Any selections will result in a request for resolution from a respective DOI MultiLink reference to the references content target 155.
  • the user's interaction with the menu may be tracked.
  • the tracked information may be saved in a number of locations including the Web server hosting the web page 140, the Syndicator, the DOI resolution server, central tracking servers, and/or the like. This tracked information may then be used to affect and modify the creation/maintenance of MultiLink menus 107.
  • the information is fed back, and there is an option to manually edit 107 the MultiLink menu using the Handle Editor 115, or, employ the auto-linking feature 110 as have already been discussed. Details regarding tracking end-user information and how such information may be used to affect the creation and maintenance of MultiLink menus will be discussed in greater detail in Figures 16-20.
  • This feedback to the menu creation/maintenance cycle may also come from other sources besides the end user's behavior in interacting with the menus.
  • sources may include: independent metrics of the user's purchasing behavior (either subsequent to the user's click-through of the menus or entirely unrelated); independently-recorded user preference information (either individually or in aggregate); independently-recorded user information that is associated with a category of user (e.g., anonymized metrics profiling a type of user by income, interests, demographics, preferences, and/or the like — such an embodiment would not associate profiled information with any individual); metrics recorded by the site hosting the menu (e.g., profiling based on time of day, geographical location of site visitors, etc.), and/or the like.
  • independent metrics of the user's purchasing behavior either subsequent to the user's click-through of the menus or entirely unrelated
  • independently-recorded user preference information either individually or in aggregate
  • independently-recorded user information that is associated with a category of user e.
  • Javascript is used to generate a menu for each item in the menu specification. This may be achieved by creating rectangular primitives and labeling each with text from the specification, the rectangular primitives being displayed in the form of a drop-down menu 175. The rectangular primitives having coordinate bounding boxes which may be highlighted when a cursor enters within any particular rectangular label's perimeter. If a cursor's selection mechanism, e.g., a mouse button, is engaged within the boundaries of a particular rectangular label, the respective DOI MultiLink is understood to have been selected by the user, and the users Web browser is instructed, e.g., with Javascript, to access the target content 156. Numerous other menu format embodiments may be used.
  • MultiLink information may be displayed in any conceivable menu format, or not via a menu format at all. Instead, the menu may be displayed as individual links on a page. In such an embodiment, by employing "NoScript" tags within a Web page allows non- Javascript enabled browsers to display the links as individual links on the Web page instead of as a drop-down menu.
  • menu items may be represented as separate windows reflecting the destinations of all the MultiLink menu choices.
  • menu items may be channeled as input to a non-visible user interface such as a program intended to produce an audio rendering of the menu choices (e.g. to be used by a blind person), or to produce a rendering intended for use by a person with any other form of handicap.
  • the MultiLink menu information may not be displayed at all, or rendered in any way intended for a human being, but may be read as input by a local program, which in turn may then execute certain functions as a result of the provided information, e.g., to execute a transaction, verify identity, verify access rights, accept payment, or store or process the information for any other purpose.
  • the Syndicator is integrated into a content provider's server. This embodiment is similar to the previous example where the Syndicator was a separate server 135 from the content provider of the Web page 140. However, in this integrated embodiment, the Syndicator is running on the content provider's server, and to the user the transaction appears to be a simple request for a DOI MultiLink record from the DOI directory 113. However, in such an example, a Syndicator component is running at the content provider's server. This embodiment has several advantages. First, it can be faster as there is no need to access remote data.
  • a search engine may have a menu specification for a book that has an option of targeting "other places to buy," which may list Retailer A, Retailer A Subsidiary, and Retailer B.
  • Retailer A may have its own Syndicator at their Web server, and its menu specification will only have Retailer A and Retailer A Subsidiary under the "other places to buy" menu option.
  • a Syndicator may provide separate "customizations" or "renditions" of the same DOI MultiLink.
  • a Syndicator is provided as MultiLink server software, which both renders MultiLink menus via this drop-down menu presentation and permits customization of the menu beyond the default that is present in the master DOI record. It should be noted, if the MultiLink server software is right on the same server as is serving up the Web page that the DOI is on, then that Syndicator is local. If, instead, that MultiLink server software is being invoked from a separate server, then the "Syndicator" the server is remotely serving may provide the MultiLink menu and any customization out to the Web page server from where the DOI originated.
  • another embodiment has a single Syndicator servicing multiple entities with varying viewing or processing needs.
  • a ISICI may be used by an advertising provider.
  • Syndicator also determines from where the request originated. Then when the Syndicator looks up a menu specification, it further refines that query by retrieving a specific menu specification for the entity making the request. This allows for greater tailoring of MultiLink DOIs for a particular audience. For example, an advertising provider may get paid to advertise, promote and sell the works of a particular book author. When a user engages a MultiLink in the form of a banner ad, e.g., for an author's works, a MultiLink menu may be displayed showing the author's name, and "Books you can buy," which would provide a sub-menu listing the author's books.
  • the "Books you can buy” sub-menu would be pruned to only list children's books by the author. However, at a Web site for thriller movie enthusiasts, the "Books you can buy” sub-menu would only have that author's thriller titles. Determination of the requesting entity may be achieved in several ways.
  • the address from where the request originated is used as a basis for determining which menu specification is to be used.
  • the query for a menu specification is made with the DOI and the Web address from the requesting site.
  • the embedded code may specify the identity of the requesting content provider. The code itself may be a DOI identifying the requesting content provider and also may be used as part of a query for the menu specification.
  • the DOI MultiLink record has an entry for the MultiLink menu specification.
  • the DOI MultiLink record has an entry for the Javascript code to generate the MultiLink menu.
  • FIGURE 2 is of a mixed data and logic flow diagram illustrating embodiments of an Autolinker.
  • autolinking 120 generally is comprised of establishing relationships between the MultiLink DOI and menu 122, constructing pointers for the MultiLink DOI record 124 and ultimately generating the MultiLink menu 126.
  • the Autolinker may obtain metadata fields and values 205 from a variety of sources as has already been discussed 105 in Figure 1. At this point, the Autolinker checks to see if a menu specification was provided and/or exists. In one embodiment, the user supplying the data provides their own menu specification. The menu specification may also be in Microsoft Excel, tab delineated format, XML, and/or the like. Any format that can represent an outline hierarchy of specification field labels 270, 280, 275 and associated record field labels 289, values 291, and references 287 like what is illustrated in Figure 5 525 will suffice. In many cases, such a menu specification will be hand tuned. If a menu structure is available, the Autolinker obtains it 215. If a menu specification has not been provided, the Autolinker will attempt to generate a best guess menu structure 220.
  • the Autolinker when the Autolinker has nothing more than metadata fields and values 263, it will generate the menu specification from the metadata record field labels 289.
  • the Autolinker would take each metadata record field label 289 (e.g., Author, Title) and specify them as being at level one 270 of the menu structure specification fields 265.
  • level two of the menu structure specification fields 265 would come from the values 291 associated with the record field labels 289.
  • the field labels 289 from the metadata 263 are used to construct the level one menus 264, 266 of the MultiLink menu
  • the metadata record values 291 are used to construct the level two menus 268, 269 and those sub menus 268, 269 will be associated with their respective record references 287.
  • the Autolinker may obtain the Web site map, the main menu at a Web site, Really Simple Syndication (RSS) feed, and/or the like structure from a users Web page server. For example, the Autolinker may examine the metadata for the most frequently accessed Web site address 287 and download the Web site information.
  • RSS Really Simple Syndication
  • the Autolinker searches for HTML and/or XML tags in the Web page provided by the site for text matching "menu,” "site map,” and/or the like.
  • Web sites have a menu structure as an overall theme of their Web site and this structure may be suitable for menu specification structure 265.
  • a Web site may have a menu comprising "Home, Products, Support, Help.”
  • Each of those menus may have submenus as well, e.g., "Support” may have a "Contacts" menu item hierarchically subordinate to the "Support” menu.
  • the Autolinker would compare such Web site menus and submenus to all of its metadata fields 289.
  • the Autolinker would then create a specification 265 based on menu items from the Web site that match the metadata fields 289.
  • the menu specification will adopt the hierarchy of the Web site map structure and the menu specification 265 generated will have those matched fields as being a submenu; they will be a submenu either to a matching parent menu.
  • the Autolinker is given an RSS feed identifier.
  • an identifier may be supplied by crawling Web sites for RSS links.
  • the feed components are retrieved.
  • the components of the RSS feed are parsed.
  • retrieval and parsing may be obtained by using a scripting language such as PERL as such:
  • DocumentBuilderFactory factory DocumentBuilderFactory.newInstanceO
  • DocumentBuilder builder factory .newDocumentBuilderO;
  • the figure 253 goes on to show the Autolinker having constructed a
  • MultiLink menu from the live feed from a Web site, e.g., the New York Times. Should the user make a selection of one of the entries 253, they would be taken to the target of such a live feed 254.
  • the above RSS embodiment may also be applied to blogs, Web site root-level menus, and/or the like.
  • the Autolinker After the above RSS example embodiment and back to the discussion of Autolinker relationship generation 122, once the Autolinker generates a best guess menu specification 220, it obtains the specification of the menu structure 215. Having the menu specification 215 and the metadata fields 205, the Autolinker performs a match as between the two 225. Once the Autolinker identifies which metadata fields 205, 263 match 225 the menu specification fields 215, 265, then the Autolinker may begin pointer construction 124. [0075] Based on the matching fields 126, the Autolinker then searches the metadata database for field values 230.
  • a match will occur based on the author field as the Autolinker is interlinking all the books by the same author; thereafter, the Autolinker will find each title by the author to populate the menu 266.
  • the actual fields chosen for matching may depend on the menu specification and may comprise any number of metadata fields.
  • the Autolinker is searching based on the menu specification to populate menu submenus with metadata.
  • the metadata 105, 263, which may be stored in a database by the Autolinker, is searched by the Autolinker by using the matched menu specification fields 225.
  • the only common field as between the menu specification fields 265 and the metadata fields 263 are the "Title" fields 283, 281.
  • the menu specification 265 would define a menu with a root menu "Menu Type” that was provided as part of the specification and submenus 275, which are not shown in the graphical menu.
  • Another root menu is "Other Books By Author” 280, which contains the matching "Title” field 281. Based on this matched field 225, the Autolinker searches all records for all values and the result is the search returned values are shown as submenus 295.
  • the Autolinker obtains an associated reference pointer 287 which will form the basis of the MultiLink 240. Now that the Autolinker has pointers 240 for all the matched 225 field values 230, the Autolinker may commence with MultiLink creation 126. At this point a menu structure is populated 293, 295 based on the menu specification 265 and the matching field 289 values 291 from the metadata 263, however, the reference links for each menu item may not exist.
  • the case where reference pointers are provided 287 as part of the metadata 263 and used by the Autolinker to supply pointers 240 for the MultiLink menu has already been discussed. However, in many cases, such references will have to be created and/or supplied to further the creation of MultiLinks as they will not be supplied by the customer 105.
  • every menu item would be supplied with a tracking pointer 288 in addition to the target reference pointer.
  • the tracking pointer would be accessed to register how various MultiLink menus are accessed.
  • usage parameters 288 e.g., the end-user's IP address, the item being selected (e.g., DOI, menu item ID, sub menu item ID, etc.), passed over menu items, and/or the like
  • the tracking links create parameters that are appended onto the tracking address 288. These parameters may be used to assist in the tracking of end-user activities, hi one embodiment, the Autolinker will generate parameters that include a DOI, a menu specification ID, and a hierarchical tag for each menu item. For example:
  • the tracking server is "www.trackerserver.com”
  • the DOI being tracked is X
  • the DOFs menu specification has an ID of Y
  • the last tag refers to a menu selection.
  • the menu's first tier's menu selection "Author” 264 was selected and then its second menu item in the second tier "Dickens” 269 was selected, which resulted in the posting of the "...?menuTierClick:l:3" parameters to the tracking server.
  • the "1" represents the MultiLink menu's first selection item in the first tier of the menu hierarchy
  • the "3" represents the menu's third selection item in the second tier of the menu hierarchy.
  • the "hover:2" portion of the parameter may indicate that the user hovered two seconds prior to clicking on the third menu selection.
  • the "hover:4" portion of the parameter may indicate that the end-user hovered over the second menu item in the second menu tier for four seconds.
  • every single menu item will be given a code relative to its order in a given tier and any menu item in the hierarchy may be identified.
  • these menu selection IDs are stored as part of the menu specification.
  • the tracking links 288 will be discussed in greater detail in Figures 16-20.
  • media code 289 may be used where the supplied link
  • any tracking links 288 are embedded within multimedia objects that displayed 290 within menu items 295.
  • multimedia objects For example, Flash, animated gifs, video files, etc. may be used and displayed 290 within menu items thereby making the menu items more engaging 295.
  • a Flash animation may be embedded in a menu as such (see 1605 of Figure 16 for the accompanying example):
  • a video may be embedded in a menu as such (see
  • a menu item may assemble a composite of media and information as such (see 1615 of Figure 16 for the accompanying example):
  • the Autolinker has at least four ways of furthering the creation of MultiLinks, one of which 250 was already discussed 240. In the instances where the customer supplied reference links 287 with the metadata 263, the Autolinker may simply choose to use those supplied links to generate the DOI MultiLink record with appropriate references 250.
  • a customer's Web site and/or database structure is reverse engineered 245. This embodiment, generally, requires human analysis.
  • a Website's product querying format is discerned and used to find products.
  • USPTO United States Patent and Trademark Office
  • the United States Patent and Trademark Office (USPTO) government Web site e.g., www.uspto.gov, has a syntax that may be employed to find object targets.
  • a customer may simply provide a query Web page and/or query prompt into which metadata field values may be provided 255.
  • the query fields may be populated in a number of ways. In one embodiment, they are populated manually.
  • a Web browser's auto-fill functionality is filled through an API, and is engaged upon the Web page form being loaded.
  • the prompt and/or Web form is filled through interapplication communication via APIs.
  • a macro playback utility e.g.,
  • Quickeys may pull values from a file and repeatedly feed values into query fields and effect the forwarding and/or saving of reference links.
  • a scripting environment as provided via PHP, Javascript, Python, TCL, and/or the like may be employed to pull field values from a file and repeatedly feed the values into query fields and effect the forwarding and/or saving of reference links.
  • all of the field values for a given metadata record are put into a search prompt to generate a response 260.
  • the metadata values would be logically-OR'd so as to rank results with greater weight when more terms are encountered in the search.
  • the metadata values may be fed into a search engine, e.g., Goole.com, and the top link can be selected as a reference link 260.
  • FIGURE 3 is of a mixed data and logic flow diagram illustrating embodiments of an IntraConnector.
  • a portion 380 of Figure 3 shows a more localized variant of the system described in Figure 2.
  • the global DOI directory 113 is still available and distributed over numerous DOI resolution servers available from across a communications network; it serving to resolve DOIs from any requesting entity.
  • an intranet embodiment where a customer may have their own local DOI directory 305 running on local DOI server(s) 333 is shown.
  • the Local DOI server also acts and/or is connected to a communications gateway out providing access to a larger communications network, e.g., the Internet.
  • link creation 110 as provided by an Autolinker and/or Handle editor supplies DOIs to the local DOI directory 305 and not to the global directory 113.
  • the local DOI directory may make requests for DOI resolution from the larger global directory 113, and that larger global directory may provide results for that resolution request, nevertheless, should the global DOI directory 113 or any other entity make requests of the local DOI directory 305, the local DOI directory would not provide any resolution information.
  • users may wish to provide access to their intranet to the outside world and may enable outgoing resolution, either globally and/or by password and access control.
  • a component in the architecture is a master metadata repository 319.
  • the master metadata repository may be an enterprise content catalog.
  • the IntraConnector may be employed in any number of contexts and is not limited to the publishing field.
  • the IntraConnector may be used in any kind of company with any kind of information, including: product companies with product catalogs; healthcare companies (e.g., hospitals with patient-related information, case-related medication-related information, etc.); service companies with customer records; government agencies with any kinds of records; and/or the like.
  • the IntraConnector may also be deployed in situations where the information being interrelated spans multiple independent departments, divisions, companies, organizations, systems, technology platforms, or other interlinking targets.
  • IntraConnector may use the IntraConnector to interrelate internal information and yet combine in with external information that it wishes to associate with its internal information, or to otherwise make accessible to its users or programs. Examples include internal knowledge management applications, where an organization may want to interrelate internal information (e.g. documents used in the R&D process) and/or external information (such as external news and research relevant to this R&D activity, and/or competitor information).
  • a content catalog contains at least two types of information: unique identifiers for each content item in the catalog and metadata that describes each content item.
  • the MraConnect architecture may utilize an existing system that a content publisher already has in some form, e.g. a content catalog, and which the content publisher may wish to use it as the basis for the publisher's enterprise content integration (ECI) deployment.
  • ECI enterprise content integration
  • the master metadata repository may be based on an existing vendor-supplied system such as Canto Cumulus 175, Documentum, Vignette, Artesia TEAMS, etc.
  • This system may be hosted and operated within the customer's own control, or it may be provided on an Application Service Provider (ASP) basis.
  • ASP Application Service Provider
  • DAM document asset management
  • book publishers typically have product catalogs, title databases, or even systems that use ISBNs as the unique identifiers and contain various types of metadata about books. Users can search and browse these systems.
  • An example publisher has an array of database systems 119.
  • the product catalog may be built on a multi-user database and may have a Web browser-based user interface.
  • publishers might have one or more types of systems that store actual content, not just descriptions of it, such as departmental DAM systems, file servers, image libraries, and so on. They will also have back-office systems that track business aspects of content, such as author contracts, rights and permissions, royalties, sales, and marketing information.
  • the IntraConnector includes components that turn the publisher's product catalog into a Master Metadata Repository 319 for an ECI implementation, the components including: UI extensions to retrieve assets and metadata 371, DOIs stored in the master metadata repository 372, and the link creator 110 and connectors to their database systems 320 provide the intraconnections.
  • the IntraConnector adds DOIs to the entries in the publisher's content catalog and to create links from each DOI to all of the systems that store information about the asset that the DOI references.
  • the Autolinker may be supplied with actual links 250. Links can be simple URLs, or they can be invocations of complex scripts that make calls to a system's programming interface in order to retrieve information.
  • the IntraConnector includes a connector component 320 that implements the latter types of interfaces to commonly- available systems, such as relational databases, file servers, DAM systems, etc.
  • the Link Creator 110 component builds all of these links and stores them in a Local DOI Directory.
  • the link creator 110 may be either the Autolinker 120 and/or Handle editor 115; in addition, the link creator may employ DOI link creation for unique content.
  • a book publisher may have a title database that contains ISBNs. The publisher may store the actual book content in a DAM system and has separate systems for author contracts and sales tracking.
  • a DOI can be created from any type of preexisting identifier, and it can point to several different links in a DOI Directory.
  • the publisher could create a DOI from each ISBN in the title database. For each of those DOIs, it could have one link to the content in the DAM system, another to author contract info in the contract system, and a third to sales info in the sales tracking system. Examples of such DOIs are generally shown 370 in tabular form in Figure 3.
  • the DOI 342 is associated 343 with its three links 344 stored in a DOI directory 113. Once all of the links have been created, then users can go through an . extended user interface to follow the links to information in whichever systems they need, as has already been shown 175, 293, 295 in Figures 1-2 and will be discussed in greater detail in Figures 5-6.
  • the IntraConnector User Interface Extensions 371 enable the product catalog to go well beyond providing simple metadata search and browse functionality: by incorporating DOI MultiLink menus, they enable users to actually retrieve the assets and other types of metadata for a given content item by going through the links in the DOI directory 113, 305. This provides some of the functionality to turns a publisher's content catalog into an Enterprise Content Integration application, thereby dramatically increasing its functionality.
  • Other components of the IntraConnector include connectors 320. These are the "glue" that turn a DOI link into a working interface to a given system. For example, a connector 320 to a DAM system 322 would take as input the identifier that the DAM system uses to identify a content item internally and invoke the DAM system's API calls to retrieve that asset.
  • Figure 3 shows two different connectors used to implement the three links.
  • the first link uses a connector 343 for a DAM system (e.g., Artesia TEAMS, Documentum, QuarkDMS, Canto Cumulus 175 and/or the like) called "Virgo" that stores book content and identifies it by ISBN 346.
  • the argument RetrieveAsset to the connector tells it to retrieve the actual content identified by the given ISBN.
  • the second link invokes a connector for the Oracle relational database 347, which is presumed to be the platform on which the publisher has built its contract management system, which the publisher has named "Libra.”
  • the connector's argument RetrieveContractlnfo presumably developed specifically for this publisher's contract system, invokes the appropriate SQL queries to retrieve info about the contract for the author whose name is given for the book whose name is given. Note that the contract system doesn't store contracts by ISBN but rather by author and title, because a contract for a given author and title can cover multiple ISBNs.
  • the third link also invokes the Oracle connector 348, this time on the publisher's sales tracking system, which is called "Aquarius.” The sales tracking system uses ISBNs to identify products.
  • An IntraConnector may be implement some of the following mechanisms for a publisher.
  • a user may search and browse metadata in a master metadata repository 113 through its user interface 371.
  • the user may invoke the search and browse interface of the publisher's existing product catalog or other metadata repository.
  • the user can select/click on the asset's name or identifier to view a menu of options, which are DOI MultiLinks.
  • One of the options might be "Retrieve Asset.” If the user selects that option, then the DOI link associated with the "Retrieve Asset” function contains a call to the connector 320 for the publisher's DAM system (which is described in greater detail throughout Figure 3 360), along with the ID that the DAM system uses internally to identify the asset.
  • the asset's MIME type determines which application should be invoked on the user's machine to view, play, or edit the asset once it is retrieved. The user may then identify some content of interest and want to look at a preview or thumbnail of it. To do so, the user clicks on the asset's name or identifier to view a menu of options, which are DOI MultiLinks.
  • One of the options may be "View Thumbnail/Preview.” If the user selects that option, then the DOI link associated with the "View Thumbnail/Preview" function contains a call to the connector 320 for the publisher's DAM system, which stores preview or thumbnail renditions of assets, along with the ED that the DAM system uses internally to identify the asset.
  • the preview or thumbnail's MIME type determines which application should be invoked on the user's machine to view the preview or thumbnail. For example, if it's a GIF image thumbnail, then the user's browser could open a new small window displaying the thumbnail.
  • the link could be set up to invoke a "read-only" application on the user's machine instead of an editing application. Then, should a user care to identify some content of interest and wish to view the author's contract information, then the user may select/click on the asset's name or identifier to view a menu of options, which are DOI MultiLinks. One of the options may be "View Contract Info.” If the user selects that option, then the DOI link associated with the "View Contract Info" function contains a call to the connector 320 for the publisher's contract system, along with the ID that the contract system uses internally to identify the work. The connector 320 implementation invokes the user interface 371 of the contract system, passing it the ID of the contract to be viewed. In an alternative embodiment, the connector implementation may read information from the contract system and display it in the user's Web browser.
  • An example deployment 360 is generally shown comprising: customer environment assessment 330, Master Metadata Repository (MMR) selection 335, content integration setup 340, server installation 345, DOI and link creation 110, 350, and UI enhancement and system testing 355.
  • MMR Master Metadata Repository
  • Inventorying the systems 331 may include identifying the content catalog to be used as the Master Metadata Repository 319, asset repositories 119, including DAM systems 322, file servers, etc.
  • Other systems to be inventoried may include ancillary information systems, e.g., rights, permissions, contracts, sales, and marketing.
  • the level of manual link creation that will be required is determined by assessing the quality of the publisher's identifiers and metadata according to these criteria 332: quantity (i.e., is there enough metadata to identify assets and other product information on all relevant systems?); consistency (i.e., are the same terms used for the same purposes across systems?); and identity uniformity (i.e., do common identifiers or metadata keys identify the same things on different systems?).
  • quantity i.e., is there enough metadata to identify assets and other product information on all relevant systems?
  • consistency i.e., are the same terms used for the same purposes across systems?
  • identity uniformity i.e., do common identifiers or metadata keys identify the same things on different systems?.
  • MMR Master Metadata Repository
  • the publisher is assisted in identifying a system to be used as the MMR.
  • this is an existing system that the publisher uses to store and maintain key content and product information, such as a title database, product catalog, Web product catalog, or even an ERP system that stores product data.
  • Conforming to a set of architectural elements facilitates in the making of the MMR. Some of the architectural elements and considerations include: employing a relational or other multi-user database; employing a Web browser-based user interface; and having entries for most or all of the relevant content.
  • the MMR should be modified to store DOIs for each content item.
  • the Local DOI directory 305 may be built to understand a convention that turns ISBNs into DOIs in a fixed, predetermined way. For example, in one embodiment, the customer's organization is assigned a pool if DOIs for use. The customer would then create a numerical association table of ISBNs to the individual DOIs in the pool. In one embodiment, ISBNs would be sorted numerically and associated to the sorted pool of DOIs numerically.
  • the mtraConnector can help to modify a publisher's product catalog into an MMR. If the publisher does not have a satisfactory product catalog system, then one may be created based on a third party's Metadata Database (e.g., a DOI registration agency like Content Directions Inc., which it uses for registering its customers' DOIs in the Global DOI Directory).
  • a third party's Metadata Database e.g., a DOI registration agency like Content Directions Inc., which it uses for registering its customers' DOIs in the Global DOI Directory.
  • connectors 320 are created for linking DOIs with the publisher's asset repositories and ancillary information systems 119.
  • parameters for each system to be integrated are compiled. These parameters include: type of system (e.g., relational database, DAM system, file server, etc.); type of software (e.g., Oracle, Artesia, FTP server, etc.); server platform (e.g., local system name, operating system); conventions that the system uses to identify entries; and the action to be taken when the user invokes the link, such as retrieve data from specific fields.
  • type of system e.g., relational database, DAM system, file server, etc.
  • type of software e.g., Oracle, Artesia, FTP server, etc.
  • server platform e.g., local system name, operating system
  • conventions that the system uses to identify entries e.g., local system name, operating system
  • the action to be taken when the user invokes the link such as retrieve data from specific fields.
  • this information is automatically compiled by employing a standard connector for an Oracle database.
  • This connector can query for the overall topology of a customer's database system resulting in a complete entity-relationship topology including all tables, field names, and key fields.
  • the system observes where the greatest number of records exist through a record count and then employs the key field for that type of record for association with DOIs.
  • DOIs may be generated for each such key field.
  • a DOI field is added to the database table and associated DOIs are added directly to the database and thus may be found through database queries.
  • an intermediary table is created with the key field and a DOI field, and may be used to join and select records in the table responsible for the greatest number of records on the customer's database. Such information may then be used to instantiate connector code for each system.
  • server setup 345 in one embodiment, any machine that can run Java applications will work. However, any number of development frameworks may be used.
  • the server is loaded with a Local DOI Directory 305; connector code, instantiated for the publisher's specific systems according to the above parameters 320; Link Creator 110; and administrative tools.
  • DOI and Link Creation has been discussed already in Figure 2 and throughout.
  • the IntraConnector also may participate in link creation for asset repositories and ancillary information systems.
  • the Autolinker automates as much of the link creation as possible by finding correspondences between an entry in the Master Metadata Repository and entries in other systems - by matching pre-existing ID numbers or other keys (such as title and author).
  • the IntraConnector can assist publishers by providing results for manual review of DOIs and links for quality control purposes. Publishers with high quality, consistent metadata will find that the quality control task takes little time.
  • the IntraConnector may establish a maintenance schedule for the links.
  • Two regular basis maintenance activities may include: Link Harvesting (e.g., running the Link Creator periodically to search the MMR and other systems for new entries, and creating new DOIs and links accordingly); and Ping Testing (e.g., running a program periodically that tests all of the links to make sure they are still valid). Details regarding quality assurance and ping testing are described in US Patent Application Nos. 10/470,206 and 10/470,207 and are herein incorporated by reference.
  • an enhanced user interface i.e., the MultiLink menu 175, is available and in this case used by the IntraConnector as well.
  • the user interface of the MMR may also be enhanced 355 so that it allows users to navigate through DOIs to all other linked systems. If the MMR's user interface for searching and browsing is browser-based, then the IntraConnector adds DOI link menus as JavaScript code. The code retrieves the DOI from the DOI Directory and then displays the links in a menu format.
  • search results display 356 are modified so that when the user clicks on an entry in the results list, or mouses over it, a DOI link menu appears 357, allowing the user to navigate to the asset, to a preview or thumbnail, or to other information.
  • This intuitive user interface enhancement a type of "glue” that ties the IntraConnect system together from the user's perspective.
  • a publisher may wish to register some of the DOIs created as part of the process to the Global DOI Directory 113. For the content assets referenced by those DOIs, registration will enhance their discoverability and help the publisher implement a wide range of possible online content services — all of which would then be readily integrated into the publisher's content infrastructure.
  • FIGURE 4 is of a logic flow diagram illustrating embodiments of an
  • MultiLink syndication For MultiLink syndication to proceed, MultiLmks need to be generated 120. Generation of MultiLinks has already been discussed (e.g., the Autolinker) in Figures 1-2 and throughout 120. Once the MultiLinks are generated, they are stored in the Handle system 130. These may be stored in either or both a global DOI directory 113 or a local one 305. In the case of a local DOI directory, syndication may spread the links widely, but only people with access to the local system will be able to reference and/or otherwise access the referenced content assets.
  • Link generation and storage is an activity unto itself that may continue independently as long as there is a desire to generate MultiLinks for content assets; as such this may proceed 450, 120 as long as required and independent of the following components of syndication 450, 415, et seq.).
  • references to the MultiLinks may be generated 415.
  • scripts may be generated to provide a reference to the MultiLink.
  • the reference is generated by embedding a link to a Syndicator in a call for a script, e.g., Javascript. It should be noted that the Syndicator itself may be identified with a DOI.
  • an identifier of the MultiLink is put into the reference.
  • the reference may be embedded into content; for example it may be embedded as HTML into a Web page 420.
  • the references may be embedded into MIME and/or HTML formatted email.
  • the MultiLink references are embedded in content 420, when a user and/or system traverses upon the content with the reference, the retrieval and viewing of the content engages the embedded reference and accesses the Syndicator 425.
  • the Syndicator receives a request for the MultiLink reference and for a script to provide the MultiLink menu.
  • the Syndicator accesses the DOI directory for the referenced MultiLink 430.
  • the Syndicator requests the MultiLink record from the DOI directory.
  • the Syndicator determines if a menu specification is available for the MultiLink.
  • the Syndicator searches its own database for a MultiLink menu specification by employing the MultiLink DOI as a search query.
  • the menu specification may be augmented by making use of end-user activity tracking 467.
  • tracking statistics are captured dynamically and continuously and used to automatically augment menu specifications 467.
  • augmentation of menu specifications occurs periodically, e.g., updated at specified intervals with cron jobs. If the Syndicator finds a menu specification 466, then it retrieves the menu specification for the MultiLink 468, otherwise the Syndicator will generate a menu specification for the DOI record based on its hierarchical structure 470. The menu specification and generation was already discussed in Figure 2 220 and throughout. After the menu specification is generated it may be stored in the Syndicator's database.
  • the menu specification may be saved in the MultiLink record in the DOI directory along with the Javascript code required to render the MultiLink menu. This may be achieved by adding the entries into the MultiLink record for the menu specification and the Javascript code each, which will be shown in greater detail in Figures 5-6 and throughout.
  • the Syndicator will generate a MultiLink menu populated with the respective MultiLinks as specified by the MultiLink menu specification. This already has been discussed in Figure 2 277.
  • Javascript, Java, Python, Perl, and any number of scripting languages may be used to call upon graphics libraries to actually build and display a pop-up menu widget populated with menu items from the menu specification, responsive to user selections following the MultiLink references.
  • the scripting language call to a UI widget call for a menu the menu specification items are placed into the code calling for the widget so that the UI pop-up menu widget displays the items specified by the MultiLink menu specification.
  • HierMenus For example, HierMenus
  • Peter Belesis may be used to generate the popup as specified by the menu specification.
  • the code is provided back to the requesting client and the client's Web browser may then interpret the code and display the MultiLink menu with resolved targets 435. Should the user traverse the MultiLink menu and engage any of the MultiLink menu items 440, then the users Web browser will be instructed to traverse to the item's corresponding MultiLink reference, thereby, resulting in the Web browser displaying the target of the MultiLink 445. Should the user encounter more embedded MultiLink references 452, then they may continue traversing content 425, otherwise syndication of the MultiLink has been successfully achieved 486.
  • Another aspect of the Syndicator is its ability to generate MultiLinks and menus for wide distribution.
  • a user may have an "Add this Link to Your Site” menu item, which permits viral distribution of DOI MultiLinks by enabling any end user who encounters a DOI anywhere to simply "Add this Link” (see 667 of Figure 6) to their site by copying/pasting generated HTML (see 669 of Figure 6) to their own Web page.
  • the content itself may contain a DOI MultiLink, and therefore being capable of prompting the user to "Add this Link" to their site.
  • the "Add this Link” and/or “Email this DOI to a friend” options are generated as part of the MultiLink menu specification by default, and as such, every MultiLink would offer them as menu options.
  • these ad-hoc features can be utilized, i.e.: embedded within content itself (and/or its DRM wrapper) as just described; finding a DOI within search engine results; seeing a DOI on a Web site; receiving a DOI via a direct-marketing email; receiving a DOI via a hospital and/or doctor's notification (see 1505 of Figure 15); seeing a DOI within the "now playing" window of a music player or video player (see 1510 of Figure 15); embedding it in someone's contact info (e.g., within an email or within a document such as a resume or a proposal); receiving it via a personal email.
  • contact info e.g., within an email or within a document such as a resume or a proposal
  • FIGURES 5-6 are of diagrams illustrating embodiments of a MultiLink menu editor and personal DOI.
  • the figure shows a Web browser 501 viewing a Web page with an embedded MultiLink 514, 515.
  • the embedded code 514 actually results in the image 515 responsible for generating the MultiLink menu 510.
  • the MultiLink menu 510 will manifest itself as has already been described.
  • the makeup of the MultiLink menu is controlled in large party by the menu specification and the MultiLink's DOI record.
  • an Autolinker and/or the Syndicator may generate a MultiLink menu specification as needed.
  • a MultiLink editor may also generate a menu specification and in addition, it may modify the DOI MultiLink record in the DOI directory.
  • Figure 5 introduces a MultiLink editor 520 as accessed via a Web browser
  • the user engages the MultiLink editor 520 by directing their Web browser 520 to the appropriate location to edit a handle 577.
  • the MultiLink editor may be used to modify menu entries as driven by end-user tracking, by advertising placement, and/or the like. Allowing those responsible for the MultiLink menus to hand-edit the menus upon reflecting on tracking information will improve their efficacy.
  • the user may specify the handle record that they wish to edit by supplying a DOI 577.
  • the user Upon signing into the MultiLink editor (e.g., by supplying a username and password to gain access to DOI records in the DOI directory), the user supplies a DOI reference and the DOI directory will access the DOI MultiLink record and display it 525 in the Web browser.
  • the editor provides various facilities to edit and access 555 and make changes to 527, 540, 545 the constituent elements 530, 535 of the DOI MultiLink record 525.
  • MultiLink editor provides a mechanism, e.g., check boxes
  • the checkboxes 533 are all enabled by default, and as such, when an Autolinker, Syndicator, or the MultiLink editor are called upon to participate in generating a MultiLink menu, and if there is no MultiLink menu specification available, all entries in the MultiLink record 525 that have enabled checkboxes 533 will be used to generate the menu specification, while all unselected checkboxes 534 will not be a part of the menu specification.
  • every MultiLink record may have a master menu specification. It should be noted, that alternative and/or added menu specifications may simply be added as additional links into the MultiLink no different than adding a "Contact Info" 530 link.
  • the MultiLink editor provides a facility for access control 544.
  • MultiLink owners may limit access to certain links to certain groups. For example, certain links may only be accessed by the owner, other links accessed by groups known to the owner, and yet other links may be accessed by everyone. In one embodiment, this is achieved by providing a link entry specifying origin points that are allowed to access the link. For example, if a user wants all his friends at a particular company to have access to a link, then they might provide a domain of www.friendscompany.com as being the only origin point for which the link will be displayed.
  • a DOI directory and/or Syndicator when participating in the resolution of a MultiLink, it may determine that the request is, or is not coming from a point of origin for which a MultiLink should be viewed; and thus the menu specification may be edited on the fly disabling the entry for points of origin not specified in an access control field entry for a link.
  • an IP address may be used as the point of origin.
  • a user name and password may be associated with the link, and only those that can supply the username and password will have the link shown.
  • points of origin will be represented by personal DOIs.
  • Another embodiment may use digital certificates and/or keys as a basis for validation; details regarding such digital rights management (DRM) implementations are described in US Patent Application Nos.
  • a MultiLink record may represent a person by containing various links pointing to personal information.
  • personal DOIs may be specified as the points of origin for the access control, and users accessing the access controlled links that are known to be coming from points of origin specified in their personal DOIs may gain access.
  • this type of access control is important in the case of patient records, where patients want to control who has access to their medical information.
  • the personal DOI record 525 contains various links as supplied by the user to represent their person.
  • the MultiLmk editor 520 allows a user to edit any MultiLink record.
  • the editor 520 provides a mechanism to add new record fields 540 and field values 545. For example, should a user wish to add an entry showing their favorite law firm, they may add by specifying the new field name in the editor facility, e.g., textbox, 540. By entering a label 540 and no reference link, e.g., URL 541, the MultiLink editor will create field category with no values other than the provided label. As such, this can generate a first level menu item, under which submenus may appear.
  • the editor 520 provides a facility to enter subfields 545 and values 546.
  • the user entered “Morgan & Finnegan” as a label for a type of "Favorite Law Firm” and also provided a reference link “www.morganfinnegan.com” 546 for the entry.
  • the MultiLink editor 520 Upon receiving these entries, 540, 545, 546, and upon the user engaging a "Submit” button, the MultiLink editor 520 sends the supplied information to the DOI directory as an instruction to add the appropriate fields to the user's DOI MultiLink record.
  • the MultiLink editor 520 may manipulate the DOI MultiLink record 525 in a number of other ways as well. As has been mentioned, the editor 520 provides various facilities 555 to edit the record and any metadata. Should a user choose to edit the record 555, a number of options are provided 605, 615, 620, 625, 630.
  • the user may change the primary response page 605, add new items 615 and menus 620 to the record (as has already been discussed), reorder the record's values, and perform various other edits (e.g., cut, copy, paste) 630.
  • various other edits e.g., cut, copy, paste
  • the user may engage the option to reorder the record values 625 and will be presented with a facility to rearrange the value order 650.
  • By selecting the "Up” or "Down” buttons next to record values the record order and any subsequent menu specification and thus menu order will be affected.
  • a menu generated from the menu specification resulting from the DOI record will have the additions and proper menu item ordering 665.
  • FIGURE 18 shows a diagram illustrating graphical embodiments of a MultiLink menu editor.
  • This alternative embodiment shows the MultiLink menu editor 1805 and the construction of a resulting MultiLink menu 1810.
  • the editor allows for the creation of additional menu selection items 1825 in each menu tier 1830 of the menu hierarchy. Menu items may simply selected and the contents may be edited.
  • usage constraints may be placed on any given menu item 1835. For example, a menu item may be placed so that it will remain in its position for a specified duration (e.g., 250 impressions, 50 clicks, 2 months, etc.) 1835. In one such an example, once the menu item is viewed by 250 end-users or clicked 50 times, it will be removed from its position and replaced.
  • a specified duration e.g. 250 impressions, 50 clicks, 2 months, etc.
  • constraints are useful for advertising models and the rotation of advertising.
  • these constrains are added automatically in a "Constraints" field with the generation of a menu specification.
  • the Autolinker may set limits for impressions and click-throughs based on sponsorship of menu items. For example, advertisers might bid for placement of menu item ads, ad words, multimedia commercials, and/or the like. The Autolinker will be provided with menu items based on the advertiser's payments for ads. As tracking information is maintained, usage statistics may be compared against the usage constraints, which will cause a change in menu items. Rules may be established as to what happens when usage constraints are reached. In one embodiment, when usage constraints are reached, the menu item is removed from the MultiLink menu. In another embodiment, when usage constraints are reached, the menu item is moved to a less prominent location within the MultiLink menu hierarchy (e.g., it may be moved down and/or deeper within the hierarchy).
  • IP ADDRESSING [00117] Moving back from Figure 18 to Figure 7, users access communications networks through addresses. Addresses represent locations. Users traverse locations in a communications network hoping to find information.
  • a common communications addressing scheme employs the IP address.
  • the IP address may be likened to the real world by analogy to a street address.
  • the IP address itself is a sequence of numbers, e.g., 209.54.94.99, and commonly has an associated name, e.g., www.contentdirections.com.
  • a distributed database registry maintains the associated pairs of names and IP addresses and serves to resolve associated names into corresponding IP addresses.
  • DNS Domain Name Servers
  • IP addresses It is common for IP addresses to be embodied as Universal Resource
  • Locators that append even more navigation information into an address.
  • Users may employ software to access information stored at URLs through the use of HTTP.
  • HTTP HyperText Transfer Protocol
  • An example is when a user specifies "http://www.report.com /reports/1999/IncomeStatement.html" in a Web browser.
  • this further navigation information i.e., "/reports/1999/IncomeStatement.html” provides a specific storage location within a computer server.
  • This further navigation location may be likened to a real world address more specific than a street address that includes information such as a company name, department, and room number.
  • This further navigation location is typically not Handled or resolved by DNSs, but instead by an information server at the resolved TP address.
  • An Information Server is a means for facilitating communications between a communication network and the computer server at a particular IP address.
  • Commercial examples of an Information Server include Apache.
  • An Information Server may be likened to a mail department for a business that further routes correspondence to appropriate locations within the business.
  • FIGURE 7 illustrates IP addressing mechanisms; namely that they do not maintain an association with information as it moves across a communications networks.
  • Web page links generally employ HTTP, which in turn relies on IP addressing.
  • URL links simply point to a location on a communication network and are not necessarily associated with any specific information. For example, a URL link referencing www.news.com will have different information associated between the URL and the information made available at the www.news.com location as information at the location is updated daily. In many instances, locations themselves may disappear as companies move information, move their operations, go out of business, etc.
  • a report entitled “Company Sales for 1999” 722 existing at a location www.report.com/1999/Report.html 708 may be moved to www.report- archives.com/1999/Old-report.html 710, e.g., because the information was sold from one entity to another, archived, or for many other reasons.
  • the report at www.report.com/1999/Report.html 708 may have had 5 million Web pages and URL links referencing the location 744, and when users attempt to access the information they may well receive a "404 File not found" error 709 because that location no longer exists and/or no longer contains the desired information.
  • the error results because the DNSs were designed to always resolve users' requests to a location and because DNSs are not designed to maintain an association between URLs and a specific instantiation of information.
  • Figure 7 depicts a Web page 701, a user entered address
  • the DOI system needs to be able to resolve what the user of the DOI wants to access.
  • the technology that is used to manage the resolution of DOIs is better known as the "Handle System," and will be described in more detail below.
  • THE DOI HANDBOOK provides a general overview of basic DOIs. In a nutshell, the Handle System includes an open set of protocols, a namespace, and an implementation of the protocols.
  • the protocols enable a distributed computer system to store Handles (such as DOIs) of digital content and resolve those Handles into the information necessary to locate and access the content, to locate and access information related to the content, or to locate and access (i.e., provide an interface to) services associated with the content.
  • This associated information can be changed as needed to reflect the current state of the identified content without changing the DOI, thus allowing the name of the item to persist over changes of location and other state information.
  • the Handle System provides a general-purpose, distributed global naming service for the reliable management of information and services on networks over long periods of time.
  • source may comprise any identifiable content, source, information, services, transactions, and work of authorship, including articles, books, intangible objects, music albums, people, tangible physical objects, and/or the like further including selected discrete portions and/or combinations thereof.
  • the accessible information may be a URL to an application that initiates a service, a transaction, provides a selection mechanism, and/or the like.
  • the DOI may even be associated with information identifying a human being such as a social security number, telephone number, and/or the like.
  • metadata may be stored in a DOI record.
  • the metadata is stored directly in the DOI record as a handle value of a specified type, e.g., DC.Title. Such an embodiment may require the disabling of caching software so that multiple requests are sure to pull the correct value. Thereafter, the metadata may be retrieved by identifying the specified type through retrieval of the handle value.
  • metadata may be stored in a DOI record for any type of DOI, such as but not limited to: personal DOIs, DOI medical records, DOI RFIDs, publication metadata, digital rights management metadata, and/or the like may all use the DOI record as an actual repository of data.
  • a person may have several such universal personal identifiers.
  • a physician may have a universal physician identifier. This identifier may have a physician's employee number, license number, name, contact information, descriptive specialist information, social security number, and/or the like.
  • a patient may have a universal patient identifier having their name, contact information, medical record reference, list of allergies, list of medical conditions, social security number, and/or the like.
  • Such universal IDs would be very useful in allowing doctors and patients to provide a single identifier and not requiring them to repetitively fill out forms with their personal information.
  • a universal person identifier may take the form of a MultiLink with access controls.
  • a person may have their own general information, and information for contexts in which they need to present personal mtormation in different capacities and roles.
  • a universal person identifier can have the more general universal person identifier as one aspect of the MultiLink, and if the person is a physician, it may have the universal physician identifier information included in another aspect of the MultiLink. Further, the physician on occasion is also a patient, and as such may have the universal patient identifier included as another aspect of the MultiLink.
  • Access controls may be used to limit access to various component aspects of the MultiLink only to authorized users; access controls are described in greater detail in Figure 5 and throughout.
  • the physician may provide his own universal person identifier on a Web site and groups of people accessing it that are not the physician's employer will be limited in viewing only the more generalized universal personal identifier aspects of the MultiLink.
  • the physician uses the universal person identifier at work, the universal physician identifier components of the MultiLink may be accessed by such an authorized group.
  • the DOI may be associated with software modules, programming "objects," or any other network-based resource.
  • a software module programming "objects," or any other network-based resource.
  • DOI can be used to represent most anything including the online representation of physical products (e.g., items currently identified by UPC or bar codes).
  • DOIs could resolve to the manufacturer's catalog page describing or offering the product, or even, in a multiple-resolution scenario, offer all services related to the object such as where to go to get the item repaired; where to find replacement parts; what the new or replacement product is; what kinds of pricing or leasing options are available, etc.
  • DOIs include: representing different modules of software that may operate in distributed fashion across a communications network; telephone numbers for Voice-over-IP technology; gene sequences; medical records and/or other permanent records (DOIs will be especially useful with permanent records protected via encryption and/or other method that might invoke a certificate or decryption key); and/or the like.
  • Another example embodiment for a DOI is to represent the permanent location of a temporary and/or dynamic value such as, but not limited to a current stock quote; current bid and offer prices (for stocks and/or any other kind of auction and/or exchange); a company's current annual report (versus different DOIs for different prior-year annual reports); and/or the like.
  • DOIs Digital Object Identifiers
  • DOIs are associated with (i.e., are names for) information itself. DOIs are instances of “Handles” and operate within the framework of the "Handle system.” A DOI allows for access to persistently associated information.
  • the DOI is a string of characters followed by a separator further followed by a string of characters, e.g., 10.1065/abcl23def.
  • DOIs are names for information, which can be used to look up that information's location and other attributes, as well as related services. It is envisioned that information may be any information as well as any computer-readable files, including e-books, music files, video files, electronic journals, software, smaller portions and/or combinations of any of the aforementioned content as well. It should be noted that since the electronic content will be made available over a communications network, hereinafter this application refers to such available information as being published on a communications network.
  • a DOI is a permanent and persistent identifier given to a piece of information made available on a communications network and registered in an electronic form, so that even if the location (i.e., URL), format, ownership, etc. of the content or associated data changes, users will be able to access the associated data.
  • DOIs, or Handles may be distributed to users in lieu of a URL.
  • a user may access information associated with a particular DOI by selecting or entering the DOI in a Handle-enabled Web browser much like a URL hyperlink.
  • Many types of browsers may be enabled by way of browser plug-in software such as the Handle System plug-in available from www.cnri.org.
  • Such an attempt to access DOI associated information triggers an automated process to look up a resource's current location.
  • the current location of the resource is associated with the resource's DOI in a centrally managed directory made available by the Handle System, which in turn directs the user (i.e., the user's Web browser) to the resource's current location. This direction is often accomplished by returning a current URL associated with the selected DOI and corresponding information.
  • FIGURE 8 illustrates the access of information through DOIs in contrast to
  • the information (report of "Company Sales for 1999) 222 is given a DOI through a registration process.
  • users reference 844 the information using the DOI through Web pages 801, typed entry in a Web browser 802, documents 803, devices 804, barcodes 806, and/or the like.
  • users engage the DOI links 844 they are resolved in a centralized DOI directory 811 and the requesting users are given a URL link 744 to the information's 722 initial location (www.report.com/1999/Report.html) 708.
  • the publisher of the information 810 Upon the information being moved 834 from its initial location (www.report.com/1999/Report.html) 708 to a new location (www.report.com/1999/Archives.html) 710, the publisher of the information 810 would inform the DOI centralized directory 845 of the new location for the information by sending an updated URL 245 referencing the new location. Thereafter, if users 801-804 attempt to access the information through the DOI links 844, the DOI directory will properly provide the new location 710 by way of the updated URL 745.
  • DOIs may not only be used to identify information, but also smaller portions thereof.
  • DOI system it is possible for a book to have one DOI, while each of its chapters would have other unique DOIs to identify them; furthermore, each figure in the book may have yet other unique DOIs to identify them.
  • DOI system it is possible to identify information with variable granularity as desired by the content publishers.
  • the Handle System employs a pre-determined set of policies for efficient and user-friendly utilization thereof, some of which of which are listed below.
  • the use of the Handle System for DOI resolution should ideally be free to users, with the costs of operation of the system possibly borne by the publishers (or more generally, DOI owners or registrants). All DOIs are to be registered with a global DOI registry. Registrants are responsible for the maintenance of state data and metadata relating to DOIs that they have registered.
  • the syntax of the DOI follows a standardized syntax. In use, the DOI will be an opaque string (dumb number). DOI registration agencies will manage the assignment of DOIs, their registration and the declaration of the metadata associated with them.
  • FIGURE 9 provides a schematic view of a Handle 900.
  • a Handle 900 has two components, the prefix 901 and the suffix 902. The prefix 901 and the suffix 902 are separated by a forward slash 907.
  • the Handle 900 may incorporate any printable characters from almost every major language written or used today. There is no specified limitation on the length of either the prefix 901 or the suffix 902. As a result, it is envisioned that there are an almost infinite number of Handles available. It is important to ensure that the combination of the prefix 901 and the suffix 902 is unique for supporting the integrity of the Handle System. Thus, the DOI registration agency will award a unique prefix 901 to a publisher.
  • the registration agency may put the responsibility on these publishers for ensuring that the suffix 902 assigned is unique as well. This may be achieved with a registration tool running on the user's client computer system. In another embodiment, the registration agency will ensure that the suffix 902 is unique by applying various suffix generation algorithms as discussed throughout this disclosure.
  • the Registration Agency and the Handle System administrators will both verify uniqueness of any new Handle before depositing it in the Handle System.
  • the Registration Agency deposits DOI records with the Handle System.
  • the Handle System in turn services DOI resolution requests through a DOI directory.
  • the prefix 901 itself has two components separated by a prefix separator
  • the Handle 906 which is a period.
  • the first part of the Handle prefix is the Handle type 904.
  • the second part of the Handle prefix is the Handle creator 905.
  • the Handle type 904 identifies what type of Handle system is being used. When the Handle type 904 starts with a "10" the Handle is distinguished as being a DOI as opposed to any other implementation type of the Handle System.
  • a publishing company might have a single DOI prefix 901, or might have a different one for each of its journals, or one for each of its imprints.
  • a prefix 901 may be a simple numeric string, the scope of the Handle System is not limited thereby.
  • a prefix 901 may also utilize alphabetical characters or any other characters.
  • the suffix 902 is a unique string of alphanumeric characters, which, in conjunction with a particular prefix 901, uniquely identifies a piece of information. It should be appreciated that the combination of the prefix 901 for a publisher and the unique suffix 902 provided by the publisher avoids the need for the centralized allocation of DOI numbers.
  • the suffix 902 may be any alphanumeric string that the publisher chooses, so long as it is unique among all suffixes registered in conjunction with the publisher's prefix.
  • Figure 9 also provides a view of another embodiment of the DOI 990, in which a textbook's ISBN number serves as the suffix 902. Consequently, where it is convenient, the publisher of the underlying content may choose to select as the suffix 902 any other identification code accorded to the original piece of content.
  • Figure 9 further illustrates an enhanced DOI 910 grammar.
  • An enhancement to the DOI grammar is embodied as an enhanced prefix 911.
  • the enhanced prefix 911 is comprised of an enhancement grammar target 917 and enhancement separator 914, which is an "@" symbol, but it is understood any other character may be designated as the enhancement separator.
  • the enhancement grammar target 917 may itself be any string of characters other than the enhancement separator 914.
  • the enhancement grammar target 917 may be employed for the purpose of having the DOI 900 resolve to multiple versions of a specified information as will be described in greater detail throughout this disclosure.
  • the enhancement grammar target 917 may itself be further comprised of an enhancement grammar verb 912 and enhancement grammar target object 913 separated by an enhancement target separator 916, e.g., a period.
  • the enhancement target separator 916 may be designated as any character(s).
  • the enhancement grammar verb 912 acts as a modifier to select amongst a plurality of multiple resolution targets for a DOI
  • the enhancement grammar target object 913 is a value passed to the target object and/or a Handle system resolution server for further action.
  • a DOI 900 is merely an identification number that does not necessarily convey any information about its associated information. As a result, it is desirable to supplement the DOI with additional information regarding the addressed information to enable users to perform efficient and user-friendly searches for retrieving the desired content over a communications network.
  • the present invention provides for the use of metadata, which is descriptive data about the identified information. While metadata may be any data-structure that is associated with a DOI, according to one embodiment, the metadata will be comprised of a few basic fields that can accurately and succinctly identify the published information.
  • the metadata will comprise an identifier associated with the entity from a legacy identifier scheme such as the International Standard Book Number (ISBN) for a book, title of the published content, type of content being published (such as book, music, video, etc.), whether the content is original or a derivation, a primary author of the content, the role of the primary author in creating the content, the name of the publisher, and/or the like.
  • ISBN International Standard Book Number
  • the metadata will comprise an identifier associated with the entity from a legacy identifier scheme such as the International Standard Book Number (ISBN) for a book, title of the published content, type of content being published (such as book, music, video, etc.), whether the content is original or a derivation, a primary author of the content, the role of the primary author in creating the content, the name of the publisher, and/or the like.
  • ISBN International Standard Book Number
  • the DOI system envisions the use of different metadata for different types of content.
  • Metadata will be made available to any user of the DOI system to enable them to find the basic description of the entity that any particular DOI identifies. This basic description will allow the user to understand some basic things about the entity that published the content or the content itself.
  • the metadata allows for the recognition of the information identified by the DOI 900 as well as its unambiguous specification.
  • the metadata will also allow for the interaction between the information and other contents in the network (and with metadata about those entities).
  • FIGURE 10 provides an overview of the resolution mechanism for allowing users to access the desired information by merely providing the DOI to the DOI Handle system.
  • Resolution in the present context includes the submitting of an identifier to a network service and receiving in return one or more pieces of current information related to the identifier.
  • the user uses her Web browser 1001 client to point to content identified by a particular DOI 1002.
  • This DOI 1002 has only one URL associated with it, and must resolve to that URL.
  • the user is directed to URL 1003, where the desired content lies.
  • this mechanism allows the location of the information to be changed while maintaining the name of the entity as an actionable identifier. If the publisher changes the location of the content, the publisher must merely update the DOI' s entry in the Handle System database to ensure that the existing DOI 1002 points to the new location of the content. As a result, while the location of the content has changed, the DOI remains the same and users are able to access the content from its new location by using the existing DOI.
  • Figure 10 provides an overview of a DOI system where users may use a
  • DOI for resolving a request for one piece of content, out of a plurality of available identical copies of the same piece of content that are identified by the same DOI, as well as the location of data about the piece of content, and services associated with the content (such as purchasing the content).
  • the DOI 1030 may be structured to describe the type of service desired 1035.
  • the DOI system is able to resolve the particular piece of content 1040 that the user desires to access.
  • the format for storing multiple resolution options for a given DOI in the Handle System may be expressed as a hierarchical dropdown menu in the browser using DHTML and JavaScript.
  • FIG. 1043 An example of a MultiLink menu is shown 1043.
  • a multiple resolution hyperlink 1044 the user is presented with a list of link choices which can be one or more layers deep 1043.
  • the user has traversed two submenus to choose a link to buy the Microsoft Reader version of an ebook at Amazon.com.
  • this menu is a widget implemented with DHTML and JavaScript.
  • the widget is loaded with data obtained from the Handle System and converted into JavaScript data structure as is described in greater detail below.
  • the format of the Handle record is composed by the following five components:
  • MULTIRES Multiple resolution records are assigned two new Handle data type: MULTIRES and MULTIRES_MAP.
  • a given handle can have multiple MULTIRES values (differentiated by different index values), and can optionally have one MULTIRES_MAP.
  • Each MULTIRES value is comprised of two logical units delimited by an equal sign (ASCII 0x3 D): a label and a URL.
  • the label portion is used as the displayed text for the URL hyperlink, hi the case where a URL is not relevant (e.g., a submenu name), the URL portion is omitted.
  • the MULTIRES_MAP value describes the hierarchy of the menus and submenus defined by the MULTIRES values.
  • the MULTIRES_MAP value is comprised of recursive menu lists delimited by curly braces. The listed items are the indices of the MULTIRES values.
  • the creation of a MultiLink is achieved through a series of Web pages 1045-1070.
  • an owner for the MultiLink must be established 1045 by first entering owner/account information, which allows for the control/creation of the MultiLink. Then the user may enter metadata regarding the MultiLink, e.g., Title, Author, publication date, descriptions, etc. 1050. Next, the user may provide multiple resolution instances in a hierarchy 1055. For example, reviews of the work may resolve to one location 1056, while the ability to purchase the book may resolve elsewhere 1057. Once the MultiLink resolutions are populated and submitted, a MultiLink 1060 and menu are generated. The user may then view 1063 the metadata information 1065 and MultiLink DOI record as stored in the handle system directory 1070.
  • FIGURE 11 provides an overview of the sequence of actions that a user performs to access information, in accordance with the present invention.
  • the user launches the browser client 1100 on a computing device 1105, such as personal computer, personal digital assistant (PDA), and/or the like.
  • the user engages the browser 1100 to make a DOI query.
  • the DOI query is forwarded to the DOI Directory Server 1110 over a communications network.
  • the system of the DOI Directory Server 1110 examines the DOI against the entries stored therein and forwards the appropriate URL to the browser 1100 on the user's computer 1100, in a manner that is invisible to the user.
  • the browser is pointed to the desired content on a server with the appropriate publisher information 1120.
  • the publisher 1120 forwards the desired information to the user, which may be accessed in the browser client 1100.
  • Figure 11 continues to provide a more complete view of the sequence of actions that a user performs to access content information.
  • the user launches the browser client 1100 on a computing device 1105.
  • the user engages the browser 1100 to make a DOI query.
  • the DOI query is forwarded to the DOI Directory Server 1110 over the communications network.
  • the system of the DOI Directory Server 1110 examines the DOI against, the entries stored therein. As a result of the checking of the DOI against the entries stored in the DOI Directory Server 1110, the DOI Directory Server 1110 determines where the DOI must lead the user 1125.
  • the appropriate URL for the content is automatically forwarded to the user's browser 1100, without any intermediate intervention or action by the user.
  • the browser 1100 is pointed to the appropriate publisher 1120 whose server is addressed by the underlying URL.
  • the URL is used by the publisher's server 1120 to determine the exact location for content desired by the user, and the publisher's server 1120 forwards the appropriate content 1130 to the user.
  • FIGURE 12 provides an overview of some of the exemplary mechanisms for accessing information over a communications network by resolving a DOI to obtain the URL where the desired content is located, in accordance with the present invention.
  • the user may directly provide the DOI and the DOI system retrieves and forwards the appropriate content to the user by simply linking to the appropriate URL.
  • the user may provide information related to some of the fields included in the metadata, whereupon a DOI lookup service identifies the appropriate DOI, which in turn may be resolved to the desired content's location.
  • a search engine 12010 may be provided to a user.
  • the search engine is offered and disposed in communication with the registration agency's DOI and metadata database.
  • a search engine such as www.google.com may be adapted to submit queries to the registration agency's databases.
  • the user searches for the appropriate DOI by providing some identifying information to the search engine 12010.
  • the search engine 12010 uses the identifying information provided and searches a database of metadata to retrieve the DOI associated with the provided metadata information.
  • the search engine 12010 uses the identifying information provided and searches a database of metadata to retrieve the DOI associated with the provided metadata information.
  • the search may be presented with returned DOIs from the metadata database and/or URLs resolved from said returned DOIs.
  • the retrieved DOI is sent to the DOI directory 12011, which resolves the URL wherein the desired content is located by a publisher 12040.
  • the user's browser is pointed to the appropriate content 12060.
  • the user may provide the DOI 12015 in the address window 12020 of a browser 12025. If the user's Web browser is not capable of natively processing DOIs, then the DOI 12015 may contain the address of a proxy server for the DOI directory 12011, which in Figure 12 is "dx.doi.org.” As a result, the browser is pointed to the DOI directory 12011 located at dx.doi.org, which resolves the URL at which the desired content is located by a publisher 12040 and points the user's browser thereto.
  • the DOI may be embedded in a document or some form of information 12030, whereupon clicking the DOI directs the user to the appropriate DOI directory 12011, which determines the URL at which the desired content is located and points the user's browser thereto.
  • the DOI may be provided on a memory 12040, such as a CD-ROM or a floppy disk, whereupon the memory may automatically, or upon being activated, direct the user to the appropriate DOI directory 12011, which resolves the URL at which the desired content is located and points the user's browser thereto.
  • a memory 12040 such as a CD-ROM or a floppy disk
  • the memory may automatically, or upon being activated, direct the user to the appropriate DOI directory 12011, which resolves the URL at which the desired content is located and points the user's browser thereto.
  • the DOI may be provided in printed form to a user, who enters the DOI manually as above or by way of optical and/or mechanical peripheral input device.
  • Figure 12 provides an overview of another embodiment of the exemplary mechanisms for retrieving information over a communications network, whereupon the DOI system resolves a DOI to obtain the URL where the desired information is located.
  • a plurality of DOI directories 1210 exist as a distributed DOI directory and form a Handle System 1200.
  • the distributed DOI directory acts and responds to requests as if it were a singular directory 12011. Otherwise resolutions take place similarly as in Figure 12.
  • FIGURE 13 provides an overview of an exemplary DOI system, in accordance with the present invention, wherein the publishers, the DOI registration service and the Handle System collaborate together to create an efficient DOI system.
  • the prefix holder 1355 may submit information to a DOI registration service 1300 comprising a DOI 1342 and associated metadata 1366.
  • the prefix holder who has already been assigned a unique prefix 501 requests that a suffix 502 be assigned to a piece of content 1366.
  • the registration service 1300 is responsible for parsing and/or reformatting the user's streams of submitted information 1342, 1366 for subsequent deposit in a Handle system 1350 and/or metadata database 1310.
  • the scope of the content that can be addressed using a DOI is unlimited.
  • the content 1366 may comprise any information and work of authorship, including articles, books, music albums, or selected discrete portions thereof.
  • the publisher 1342 collects metadata for the content 1366.
  • the metadata may comprise the content's DOI 500, a DOI genre, an identifier, title, type, origination, primary agent, agent's role, and/or the like. It may also comprise listings of associated services having to do with the identified piece of content offered by various parties, such as the locations of Web pages where a piece of content may be purchased online.
  • the DOI 500 and the metadata are transmitted to the DOI registration service 1300.
  • the DOI registration service 1300 maintains a database of DOIs 500, metadata of all the registered content 1366, as well as the URL at which the content 1366 is located.
  • the DOI registration service 1300 forwards the metadata to a metadata database 1310, 2219 of Figure 22, which may or may not be integrally maintained by the DOI registration service 1300.
  • the DOI registration service 1300 may use the collected metadata for providing it to other data services 1320 or for providing value added resources 1330 to the users, m addition, the DOI registration service 1300 sends the appropriate DOI Handle data to the Handle System 1350, which. may comprise a plurality of DOI Directory Servers 1341.
  • FIGURE 14 illustrates example advertisements served by an advertising
  • a Syndicator may be used as an advertising provider.
  • Such an embodiment shows a series of Web pages 1411, 1422, 1433, 1444 in a Web browser window 501.
  • a user may conduct a search for information about aviation by entering search terms into a search query text box 1405 and submitting 1486 the search.
  • Some of the search results 1418 include MultiLinks 1410.
  • the MultiLink menus may pop up from text results 1410 or as part of a banner ad 1430, 1422.
  • users may procure MultiLink menu enabled sponsored links 1417, 1444.
  • a user procured a sponsored link from a search provider. For example, the user went to a search company Web page (e.g., Google), filled in their contact information and provided information specifying the sponsored link they would like. Normally, a user would specify certain keywords and provide a sponsored link and some accompanying text that would be displayed in response to a search for the specified keywords. This is extended by the Autolinker and/or MultiLink editor. MultiLinks for an advertised item would have already been created, e.g., by the Autolinker. Instead of providing a regular link, the user could specify a MultiLink.
  • a search company Web page e.g., Google
  • the user may employ the MultiLink editor to tailor a MultiLink menu as has already been discussed. As such, the user may now provide a MultiLink menu to the search company instead of a mere link, and this will result in premium sponsored links having MultiLink menus pop-up with more information when a user moves their cursor past 1410, 1417, 1445.
  • a results Web page 1444 will show results 1418 that include premium sponsored links 1417.
  • a MultiLink menu 1445 pops up and may be used to access more information.
  • the positioning and appearance of menu items may change based on end-user activity here as well.
  • the order of the cities 1447 may change as driven by the frequency of end-user payment, by advertisers paying for placement (e.g., Boston firms may pay more and their menu entry would move to the top).
  • advertisers paying for placement e.g., Boston firms may pay more and their menu entry would move to the top.
  • MultiLinks are so rich in information, and they are both inter and intra linked, any advertising links using MultiLinks will in many cases be found to be more relevant as search results. Such MultiLinks will have higher click- through rates than regular single-linking URLs, and thus would be more valuable in an advertising context.
  • FIGURE 15 illustrates example MultiLmk applications.
  • a MultiLmk advertisement may be placed contextually within other relevant content, such as within an article or a product review, a research study, a music Web site, and/or the like.
  • MultiLmk menus could be put in the order as driven by popularity of click-throughs by independent source data such as a song's current top-40 chart rating 1510, 667.
  • a DOI for "Boeing" is displayed within a Business Week article, driving the user back to McGraw-Hill's World Aviation Directory (i.e., the owner of the DOI) where the desired information may require a subscription or a pay-per-view transaction from the user 1515 .
  • McGraw-Hill's World Aviation Directory i.e., the owner of the DOI
  • a book review in Business Week may display the DOI for the book being reviewed, and the MultiLmk menu could refer the user to Amazon or other retailers for purchase.
  • the publisher itself (as the owner of this DOI)
  • Business Week by using the MultiLink Syndicator to modify the local appearance of that menu insofar as that menu appears within Business Week) may seek fees from the retailers for placement on the MultiLink menu.
  • the fees may take on a number of forms, such as on a referral-commission basis, on a flat placement fee basis and/or on any other basis including those described below and/or elsewhere.
  • MultiLink menus may employ end-user activity tracking to determine what ads are used most. Further, sponsored resources may be used to rotate particular sponsors in the MultiLink menus based on usage. As such, a Web site may increase ad revenues because the end-user tracking would expose winning ads more frequently and thus, the Web sites would earn more money as their click-through rates increased.
  • an advertisement may actually be placed on the
  • MultiLink menu for another item, in effect using the MultiLink menu in a similar way to a billboard as screen "real estate" and/or any other form of advertising inventory.
  • a user could move over a "Learn More" item having a MultiLink with sponsored resources 1530.
  • placement on the MultiLink menu could be offered to sponsoring advertisers for a fee, which could vary according to prominence of the fonts and colors on the menu, inclusion or exclusion of graphics or logos, or placement in terms of the order of menu choices.
  • Placement may also be rotated amongst different advertisers, with fees varying according to how frequently a given advertiser's link(s) would appear, or what times of day, in what contexts, in response to certain kinds of search queries by the user, according to the geographical location of the user, according to the language of the user, according to user profile information which had been previously stored or had been captured as part of a dialogue with the user, and/or the like.
  • the mechanism for populating sponsored links will be based on receiving payment from advertisers for a certain number of user impressions and for specified "key word" activities. As such, if a sponsor paid for 1,000 impressions related to "diabetes" keywords, then the Syndicator may vary the generation of menu specifications based on paid for links.
  • a placeholder tag is put into a MultiLink record, e.g., ⁇ Sponsored Link>, into which a sponsored link may be placed.
  • a ISICI may then issue a database query based on keywords associated with embedded MultiLinks in its content pages, wherein it selects for such keywords with paid for impressions.
  • the Syndicator may then insert the sponsor's link into the MultiLink placeholder.
  • the generation of the menu specification may be provided on demand with the most current advertisers selected from an advertising database.
  • a debit of impressions for the sponsored link may be recorded in the advertisement database, leaving the sponsor with, e.g., 999 impressions.
  • placement may be provided on the MultiLink menu to external organizations that represent online partners of the DOI owner, and which may link to related resources or products or services offered by the partner.
  • Placement could be granted on a flat-fee basis, or as part of a reciprocal linking arrangement, or as part of an arrangement whereby one or both parties may compensate each other via referral commissions for purchases made by visitors who arrived via the other party's MultiLink menu, on a per-click or per-visitor referral basis, and/or any other business arrangement. Fees could also vary according to all the embodiments and variations described previously and/or elsewhere in this document.
  • two parties are shown first with their own independent DOIs 1535, and then with interlinking between them 1537.
  • the Snapshot reports MultiLink menu 1535 is integrated into the, e.g., SRI' s, MultiLink menu as a sponsored link 1537. It should be noted that interlinking may take place with two or more parties.
  • an intermediary such as a retailer, distributor, aggregator or syndicator such as Dialog, Factiva, Lexis-Nexis, etc. could elect to display
  • DOI MultiLinks within its service thus enabling MultiLink-referred traffic back to the owner's site and/or to any other site designated by the owner, with a referral commission or other compensation being earned by the displayer of the MultiLink.
  • the intermediary may monetize its audience or user base to drive sales back to the DOI owner or its designated parties, thus benefiting from its role as a conduit.
  • a conduit site may display a DOI (e.g., for "William Clay Ford") owned by Thomson Gale, which would then direct users to saleable Gale products such as various Biography documents 1540.
  • MultiLinks have an impact upon "natural" search engine rankings, whether they are employed in advertisements or in any other context.
  • Many searching systems like Google, rank relevancy based on the number of links to a given content item.
  • they spider the Web they index Web pages and track the number of links to a given content item or Web page. This information is then used in their relevance-ranking algorithms so that when a user searches for a given tenn, the term is not only associated with the content item but is relevance-ranked according to (among other factors) the number of links which point to that item.
  • MultiLink DOIs provide interlinking between many related items, and when those items in turn interlink between many other related items (including potentially the original item), the net result is to boost the relevance ranking of the item within search results on search engines or other sites which provide search results.
  • the association per se of a user's search query with the particular item found may or may not require an independent association method such as between the DOI MultiLink and other words on the Web page on which it appears, or between the DOI MultiLink and keywords in the header or metatags of the Web page, or via any other mechanism by which a search becomes associated with a particular search result, but the ranking may be influenced by the interlinking of related items via the DOI MultiLink. Further, the more items are interlinked, the greater the ranking impact becomes.
  • DOI MultiLink is distributed to multiple locations on the Internet, instead of only on the owner's site, and regardless of whether this distribution is achieved via use of the MultiLink Syndicator or via manual ad-hoc postings on Web pages or via any other method, the ranking impact is further magnified by the presence of these multiple DOI MultiLinks in more locations.
  • the impact on search engine rankings can be estimated via a component of the Autolinker, wherein the number of interlinked items, and the degree to which they are interlinked, can be assessed to provide an estimate of the extent to which search engine rankings could be affected by the spidering of these MultiLinks by search engines.
  • an impact factor can be estimated.
  • This impact factor can then be further extrapolated to estimate the further impact accruing from the degree to which those DOIs may then become distributed around the Internet to be found by search engine spiders; the more places they are found, the greater the impact on rankings because each location represents yet another place in which the spiders will encounter a DOI, traverse all of its MultiLinks, encounter those DOIs, traverse all of their MultiLinks (including the original DOI), etc.
  • These estimates can also be used to help the DOI owner understand how it could better interlink related information.
  • identifying items which have very little interlinking associated with them (or none, as could be embodied in a "MultiLink orphan report"), which in turn could identify a failure of the DOI owner's categorization process, and as such, may highlight a weakness in the effectiveness or accuracy or completeness of its taxonomy, or other useful diagnostic conclusions.
  • This string will be used to select DOIs from the HANDLE table in the Oracle database where DOI LIKE '$prefix%'.
  • This option increases the amount of information which is output. You may use this option more than once to increase output.
  • a measure of the degree of interlinking may be obtained my comparing DOIs found through crawling against a database of (e.g., sponsored) DOIs.
  • the ISICI will crawl Web sites indexing their embedded DOIs. Then the results from crawling are compared to the index results in the database and also to sponsored links in that database. In so doing, the ISICI will count the number matches, missing and unknown DOIs.
  • matching and comparison may be achieved by comparing a fragment of a DOI to monitor the degree of matches for a family of DOIs. The ISICI may then compare found DOIs to any DOIs in the database or to any specified DOIs.
  • the ISICI performs such analysis for every DOI and stores it in an interlink/index and ranking table in the ISICI database 1519.
  • DOIs with a higher number of matching links are ranked higher than those with a lower amount.
  • a rankings report may be generated by selecting for the highest matched DOIs resulting in a report gauging the popularity of DOIs. Such reports may be automatically and/or periodically generated and sold. In another embodiment, such reports may be produced for sponsored links. Such statistical information may be sold separately and/or included as part of a service of sponsored links. Also, a rankings list may be provided periodically to the general public acting as a gauge of content popularity, i.e., a sort of Billboard top most popular list for DOIs and content.
  • Rankings may be limited to just music content, to personal DOIs identifying popular people, to services which identify the most popular service providers.
  • the ISICI may select only a single sector, e.g., law firms, and generate a popularity index for law firms.
  • the ISICI may limit its selection to the field of current movie releases.
  • selections may be limited to a certain category of products, e.g., automobiles.
  • the selections may be limited by time parameters. Selections on rankings may be made for a certain time period. As such, if the ISICI selects interlinking statistics for the automobile industry for the last 12 months, the rankings will be so limited. In another embodiment, if no time constraints are placed on such a selection, then popularity throughout time may be gauged.
  • maximizing search engine rankings may be achieved by assigning DOIs to the keywords and/or terms of a taxonomy and/or controlled vocabulary, and the MultiLinks may then be directed to any or all of the following or any other resources: other keywords of the taxonomy; all products or publications relating to those keywords; services associated with those keywords; vendors or retailers or other kinds of partners associated with those keywords; and/or the like.
  • a DOI assigned by a company to the term "avionics repair” is MultiLinked to all of the company's products across all its lines of business that are related to the term "avionics repair," whether these products are books, company database records in the World Aviation Directory, Business Week or AviationWeek articles, upcoming conferences, sponsored links such as already described above, and/or the like.
  • search results would come back from any search engine with MultiLinks weighted towards the top 1545 as there is a greater degree of interlinking.
  • the same taxonomy term and MultiLinks that would cause the term to rise higher in the search engine rankings could also be used to increase the value of placement of partner links on the MultiLink menu, even in contexts where the DOI appears other than within search engine results per se.
  • a company's DOI for "diabetes mellitus" could be seen contextually within a research study, wherein the MultiLink would drive users to the company's partners (e.g., WebMD, Atkins, the scientific journal literature provided by Ovid, etc.), where such placement on the menu is offered for a fee proportional to that term's ranking on search engines (or on any other basis, such as those described previously).
  • FIGURE 16 illustrates example MultiLink applications and user interfaces.
  • the navigation framework represented by a MultiLink has an underlying engine that creates, maintains, and centrally controls these links, either via a human editing process or more typically via an automated "assembly line" process that creates and maintains these menus based on product data fed by the advertiser.
  • MultiLink menus go even further than embodying information and links relating to the product or other subject of the ad; the menus can also include links that point deeply to back-end system data such as in-stock inventory information, local dealer information, special offers from various retailers of the product, and/or other kinds of information or transactions that require sophisticated integration with other online or offline systems. This capability also encompasses varying degrees of automated integration.
  • a MultiLink menu may contain a deep link pointing to back-end system information.
  • deep links may have been created by consultation with the target system's technology staff, database administrators, Web masters and/or the like; also, the deep links may be reverse-engineered through observation and deduction.
  • the MultiLink menu creation/maintenance system may actually retrieve information from the back-end system in advance of creating the menu itself.
  • the MultiLink's menu specification may be generated and or updated by retrieving information from a back-end system (e.g., current inventory information 1615, special pricing or bundling (see 1820 of Figure 18), coupons, rebates, and/or the like).
  • FIG. 16 shows a MultiLink menu with composite information detailing the inventory and price of specific automobiles 1615. An end-user may even enter form information right within a MultiLink menu 1625 without having to traverse the actual underlying target reference links contained within the MultiLink menu.
  • the MultiLink menu allows a user to navigate to the back- end system 1620 by selecting a menu selection 1621 targeting a reference address where the user may interact with the back-end system directly 1622.
  • FIGURE 17 is of a mixed data flow diagram illustrating embodiments of a MultiLink eco-system.
  • the ISICI allows for the creation and maintains of MultiLink menus 1705.
  • the creation of the MultiLink menus results in the registration of MultiLinks in an UPUNI global registry 1715.
  • Syndication of the MultiLink menus take place 1720 and as the MultiLinks and menus are propagated and displayed 1725 by end- users, a MultiLink tracker collects information about the end-users interaction with a given MultiLink menu 1735 and stores that tracking information in a MultiLink tracker database 1740.
  • This tracking information 1740 may be used by advertisers and other service providers 1750 to further refine, repair and/or otherwise service the MultiLink menus.
  • a quality assurance provider 1750 may use tracking information to assure MultiLink integrity 1707 as MultiLink menus are being maintained and/or created 1705. For example, if a particular MultiLink menu entry becomes very popular and the target reference of that menu entry becomes overwhelmed so that many users are denied access, the quality assurance service provider 1750 may repair the MultiLink menu 1755 specification by providing an updated target reference (e.g., providing a new target reference for an alternative server with greater capacity, providing an alternative menu entry, and/or the like).
  • an updated target reference e.g., providing a new target reference for an alternative server with greater capacity, providing an alternative menu entry, and/or the like.
  • an ad agency may use the tracking information
  • the MultiLink menu may include menu items that are all, partially or devoid of sponsored advertising.
  • a specified number of MultiLink menu item slots may be reserved for sponsored advertising. The number of item slots may be anywhere from none, to some, to all of the MultiLink menu items, hi such an embodiment, advertisers may bid for placement of their ads in the available spots.
  • the bidding and/or placement of ads is based on the context of: the other MultiLink menu items, the contents of the targets the MultiLink menu items, the contents of the cause of the MultiLink menu item (e.g., a hyperlink and/or its reference), the content of the end-user's current point of navigation (e.g., their currently displayed Web page), and/or the like.
  • the advertising slots may themselves be tracked.
  • the MultiLink tracker may allow for the determination of more effective placement of ads in a MultiLink menu.
  • slots devoted to MultiLink menu ads may work more effectively sprinkled throughout the MultiLink menu, while in other contexts ads may work better if featured in more prominent locations (e.g., at the top of the MultiLink menu).
  • the format of MultiLink menu ads may be refined through tracking. For example, in some contexts MultiLink menus that prominently express they are ads (e.g., by preceding any text in a MultiLink menu ad slot with "AD:”) may work better, while in other contexts having MultiLink menu ads that blend in with the remainder of the MultiLink menus may be more effective.
  • Multilink menu specification upon in response to tracking information from the MultiLink tracking database 1740.
  • a consulting industry may be engaged to provide marketing and product strategies as to how to best populate and design MultiLink menus 1705 as part of an overall marketing strategy 1760.
  • the marketing consultants will also benefit from the end-user tracking information stored in the database 1740.
  • a more streamlined view 1775 of the above described feedback loop demonstrates how each of the aforementioned components may generally interact with one another.
  • FIG. 1775 shows a continuous cycle of self-improvement 1775.
  • the feedback loop rotates counter-clockwise, starting at the top with "Consulting" 1760.
  • the consulting service begins the business process of working with clients to capture their product and marketing strategies and their understanding of their target customers' purchasing life-cycle.
  • the consultants can try to best gauge an initial seed of items to populate the MultiLink menu for a particular marketing campaign.
  • This initial seed may be used to actually create the MultiLink with the creation/maintenance component 1705 as has already been described (e.g., via a fully-automated, data-driven, "assembly line” process using the Autolinker, or whether via a manual creation process using the MultiLink editor, and/or the like).
  • the MultiLink server 1726 enables the display/clickless navigation the MultiLink menu.
  • the Syndicator 1720 distributes the links anywhere on the Web without requiring a local software install, yet still allows for individual local-site customization just as the MultiLink server does, e.g., when it is installed on a local site.
  • the quality assurance component 1755 checks the integrity of MultiLinks. At this point, the MultiLink tracker 1735 may track and report end-user behavior back to either the creation/maintenance component 1705 and/or to the consulting facility 1760.
  • FIGURE 19 is of a logic flow diagram illustrating embodiments of a
  • the MultiLink tracker may collect tracking information in at least two ways: receiving tracking information directly resulting from an end-user interaction with a MultiLink menu 1905 (i.e., clicking on a MultiLink menu item resulting in engagement of an HTTP post to the MultiLink tracker server address) 1905, spidering Web servers for usage logs 1915, and/or the like.
  • the MultiLink tracker employs a spider to retrieve the usage logs at Websites across the Internet 1915. In one embodiment this is achieved by spidering to every IP address to a statistics page (e.g., http://123.123.123.123/statistics). In another embodiment, arrangements are made with ISPs and host providers to transfer usage logs on a regular basis from FTP points.
  • the MultiLink tracker may begin analyzing the individual usage entries in the logs 1925. In one embodiment, the MultiLink tracker will analyze each log entry 1925 continuously (until it exhausts all entries in all Web logs). In another embodiment, the MultiLink tracker may process the logs at specified times (e.g., as initiated through cron jobs) 1925. Alternatively, the MultiLink tracker may receive tracking information directly from end-user actions 1905 (as has already been discussed in Figure 2).
  • the MultiLink tracker When the MultiLink tracker receives tracking information directly 1905, it may pass each end-user tracking item on to be analyzed on a continuous and dynamic basis 1925, or alternatively, the MultiLink tracker may store such tracking information (i.e., HTTP posts) in its own Web server log 1907, which may be processed along with other logs 1925.
  • tracking information i.e., HTTP posts
  • menu item numbers are used as parameters, as was already discussed in Figure 2, e.g.:
  • each such entry 1925 in the Web log is parsed (e.g., popping every
  • ASCII string that is separated by a carriage return and parsing for DOI 1930 and parameter values 1940 Numerous parameter values may be included and parsed such as: hover times, menu item selection values, menu specification ID, and/or the like.
  • the menu specification may be obtained 1935 and used as a dynamic template in parsing the parameters 1940.
  • the MultiLink tracker may save those parsed values to its database 1919.
  • FIGURE 20 shows a MultiLink tracking user interface and tracking log.
  • the MultiLink tracker database may be queried by individuals through a MultiLink tracker interface 1205.
  • the MultiLink tracker interface may provide SQL queries to the database to provide various activity tracking statistics 2030, 2035, 2040, 2050 for each MultiLink menu 2071 and its sub menu items 2072.
  • date ranges 2055 may be provided in the interface, which are then used to constrain the SQL select of data so that the various metrics are limited to that date range.
  • Various statistics like menu item roll-overs 2030, clicks 2035, click through percentages 2040 and average time spent on a menu subitem 2050 may be discerned. These tracking values come from Web logs.
  • DOI handle use may be tracked via a Web log 2080 that maintains the accessed DOI 2010, number of accesses 2015, title 2020 and other types of information.
  • the MultiLink tracker database may also be queried and accessed programmatically through HTTP requests that are parsed into SQL requests. For example:
  • a DOI "10.123/12345" would be used as the basis of a select command and the database would send back an HTTP post of all the matching database records to the requesting agent.
  • the amount of tracking information may be further limited with the addition of an optional "?statistic type" parameter.
  • the additional parameter might be "menultem:l:3,” which would return statistics only for the third item in the second tier menu for a given DOI.
  • Another search limiter is "clicked,” which would return only the total number of clicks for a given DOI.
  • various entities may make use of the tracking information from the MultiLink tracker database.
  • FIGURE 21 illustrates a purchase cycle.
  • the ISICI addresses the problem with prolonged purchase cycles and potential purchaser attrition.
  • the purchase cycle for high-engagement goods and/or services 2105 is depicted in a multi-tier chart 2105.
  • High-engagement purchases require a purchaser to make numerous decisions that are based on various objective and subjective factors. Examples of high- engagement purchase may include: automobiles, boats, homes, professional services (e.g., medical, legal, etc. services), stereo systems, televisions, and/or the like.
  • the figure illustrates that in the early stages 2110, purchasers may spend anywhere from 2-6 months deciding on just which segment they are interested in.
  • purchasers may spend several months deciding if they want an SUV, a mini- van, a station wagon, etc. After identifying a segment 2110, in a middle stage purchasers may then spend anywhere from an additional 1-3 months deciding on which brands they are interested in 2115. After that 2115, in a late purchasing stage, purchasers may spend from 1 week to 1 month deciding on specific products and/or features within a brand 2120. For example, if purchasers decide on buying a Dodge Crossfire automobile, they may need some time to decide if they want various options like a sunroof, a deluxe stereo package, a particular color, etc. Finally, in a last purchasing stage, purchasers may spend 1-2 weeks finding a transaction partner 2122.
  • the purchasers may go to several automobile dealers in order to make a purchase.
  • the number of potential purchasers 2111 decreases at each stage 2116, 2121, 2123 due to customer attrition. In many cases this attrition is caused by the loss of interest due to the long time involved in this multi-stage purchasing cycle.
  • the ISICI manages to compress the purchasing cycle down from months to moments.
  • a purchaser hovers over an ad that is MultiLink menu enabled they may obtain information about various market segments (e.g., numerous car types are available for the purchaser to examine under the line-up menu item) 1616, about the brand 1617, and even the inventory of various dealers 1615.
  • various market segments e.g., numerous car types are available for the purchaser to examine under the line-up menu item
  • the entire purchase cycle from first ad impression straight through purchase may be achieved by navigating a single menu.
  • advertisers may refine menu items and information that were favored by purchasers to further increase menu efficacy. Additional Tracker Embodiments
  • the ISICFs tracking services have the ability to quantitatively measure the effectiveness of the MultiLink menu by actually monitoring the results of end users' interactions with these menus.
  • the ISICI system can determine how many hits and unique visitors are driven to a given Web site via the MultiLink menus, as opposed to hits and visitors that arrived at that Web site any other way. This allows for precise monitoring of the menu's effectiveness by measuring the hits and visits that are specifically and directly attributable to the menu, rather than just circumstantially related as is the case with offline media advertising.
  • the target Web site has a shopping cart capable of recognizing and crediting a referral code, then the system can determine how many actual sales, subscriptions, or other commercial transactions were referred via that MultiLink menu.
  • the system can also measure the menu's rate of click-through and rate of sales conversion by comparing these eventual hits, visits and purchases against the original number of visitors who were exposed to the menu in the first place.
  • the MultiLink menu 's role in the new advertising model as has been described herein.
  • the ISICI can measure the effectiveness of a MultiLink menu as an actual expression of an advertiser's conception of the end user's decision-making process (e.g., where different branches and pathways of the menu correspond to different stages in the prospective customer's decision life-cycle, and where each stage of this life-cycle implies its own set of information needs).
  • the system can actually track the effectiveness of the marketer's conception of the life-cycle, as embodied in the menu, by empirically measuring the accuracy of its fit with actual customer behavior. As such, to some extent even a marketer's efficacy can be measured based on changes they effect on MultiLink menu ad campaign design.
  • Such measurement may be achieved by tracking the specific paths navigated by users through the menu.
  • the individual pathways on the MultiLink menu can be monitored and/or measured to determine effectiveness (e.g., whether or not the whole menu drives click-throughs and purchases may be measured as function of how the individual pathways on the menu).
  • the ISICI may monitor and separately measure each distinct pathway through the menu, and report back how many times users chose certain paths as compared with others.
  • the ISICI can track the user's behavior in interacting with the menu per se (i.e., even before choosing to click through any particular menu link), and/or 2) the system can track the end result of the user's interaction when the user actually clicks through a particular link and arrives at the target (e.g., Web page, shopping cart, query, and/or any other transaction).
  • the two approaches overlap in that they measure the same user behavior but from two different angles.
  • the two different ends of the user's click-through may be viewed as a) the menu end where the user begins by clicking away to the target site, and b) the target-site end where the user arrives.
  • the second "target tracking” approach tracks the user's arrival and subsequent behavior on the target site itself, but generally does not track what the user was doing on the menu prior to the click-through, at least until its information is integrated with the information captured by the "menu per se” approach. However, one exception occurs when by inferring the user's behavior on the menu prior to the click- through based on tracking statistics captured on the target site.
  • the tracking mechanisms themselves can be described more fully as follows:
  • a particular menu label can be associated with HTTP Post, so that any event associated with that menu label (e.g., a user clicking through it) can be recorded by a server which is the target of the HTTP Post, even while the user herself is actually sent on to the other target reference associated with that menu label (i.e., the target reference (e.g., a URL) is intended for the user to go it upon click-through).
  • the target reference e.g., a URL
  • each distinct click-through point on the menu i.e., each menu choice which is capable of sending a user off to a target reference (e.g., Web site, shopping cart, process, query, and/or any other transaction) can have a mechanism such as a referral code which would have been appended or pre- pended to the target reference in advance.
  • a referral code may be supplied during the creation/maintenance of MultiLink menus.
  • the referral code identifies the user unambiguously as having come not only from the MultiLink menu in general, but from a particular menu choice on the MultiLink.
  • results from the target-site-end can be integrated with the results of
  • these metrics may then be (automatically) funneled back into the menu creation/maintenance system 181 of Figure 1.
  • these metrics can be set up to automatically drive modifications to the menu itself going forward.
  • a rule may be created that changed the order of menu links once a day by shuffling them in order of actual popularity during the preceding day, or cumulatively.
  • the "Call Firm Now” 1446 of Figure 14 could place moved to the top of the menu if it proves the most popular.
  • the "Sponsored Resources" link on the menu 1530 of Figure 15 is an ad in its own right; the ad lives on the "real estate" of a MultiLink menu.
  • the menu can be filled with the link from a particular Sponsor, or rotated onto the menu more frequently than another Sponsor's link, if the first Sponsor turns out to draw greater click-through rates.
  • This MultiLink ad menu embodiment has the byproduct of maximizing ad revenue for the site hosting the menu because placing a more popular menu choice on the menu more frequently will draw greater click-through rates, and this is often a direct driver of the hosting site's ad revenues.
  • Another example rule is to drop a certain choices from the menu entirely if they are rarely interacted with (i.e., they were never clicked on (or even hovered over) within a one-month period).
  • Another example is a rule that took a menu choice from lower down in the hierarchy (e.g., the "Search Inventory” menu choice 1621 of Figure 16) and moving to the first level of the menu hierarchy 1633 if it proved to be popular.
  • changing menu position may be based on complex measurements like the ratio between hover time and click-throughs, the frequency with which a user clicks through certain menu choices after viewing a full-motion audio-accompanied video within the menu 1610 of Figure 16, and/or the like.
  • MultiLink menus can also be locally customized on a particular site. This may extend to specifying different referral codes that may also identify the referrals as coming from a particular instance of that menu on a particular site. For example, the same ad placed on one publisher Web site could be amended to include a referral code specific to that site, whereas the same ad placed on a different publisher's site may be amended to include a referral code specific to that site. [00210] As such, the ISICI tracking mechanisms can be elaborated with various rule sets specific to varying organizations.
  • affiliate networks This may become a basis for creating affiliate networks, where each affiliate can use an affiliate-specific referral codes to identify its own referrals, and thus, receive sales credit for its own sales referrals or even for simple click-throughs that might be compensated on a per-click basis.
  • affiliate-specific referral codes to identify its own referrals, and thus, receive sales credit for its own sales referrals or even for simple click-throughs that might be compensated on a per-click basis.
  • the same feature can also be used in a security/access control context, where only referrals from a certain trusted web site will be allowed to view confidential information on the target site such as medical patient records, military/intelligence information, or published content requiring subscriber status in order to view.
  • the source data that drives modifications of the menu need not be related at all to actual user behavior in connection with the menus.
  • a modification to place a certain model of car at the top of the list could be driven instead by independently-measured sales records indicating that this was a fast- selling model.
  • songs could be added or dropped from the menu, or their order changed, according to independent source data such as the songs' current top-40 chart rankings.
  • local dealer inventory information is actually retrieved from Chrysler's back-end systems and brought forward right into the menu upfront 1615 of Figure 16. Such information may be pulled selectively based on the sales performance of the individual dealers.
  • This source data may come from Chrysler's other back-end systems (e.g., its sales database), or even from the individual dealers' sales databases.
  • the local dealer information may be selected for display based entirely on the end users' behavior as measured through our tracking system itself, as has already been described.
  • Independent source data may be comprised from many other types of sources such as: demographic information about the users, either individually or in aggregate; user preferences and interests as recorded in other independent systems; geographical location of the user, time of day when the menu is being viewed; and/or the like.
  • the feedback mechanism allows MultiLink menus to become self- improving based on feedback from the real world. That feedback can drive changes in a sophisticated, information-engineered menu that may be an expression of the whole range of customer information needs required by a wide range of customers across a wide range of stages of their purchasing cycle. As such, that expression may become self-improving based on actual empirical information regarding its own effectiveness, and/or based on other independently-collected information that can make the menu more relevant and useful to the customer, as well as more effective for the advertiser. These self-improving modifications can either be fully-automated based on rules, or manually implemented based on human review of the data on user behavior and/or other source data.
  • the ISICI provides automated mechanisms to greatly assist the process.
  • the MultiLink editor permits updating of the MultiLink menu and then the posting of the updated record to the Handle System; it should be noted that any other "level of indirection" for updating, maintaining and/or serving the menus would serve equally well in principle, and is equally covered by the present invention, however, any other such alternative approaches may derive additional scalability and standards-based benefits from the Handle System.
  • the MultiLink editor may provide a visual indicator of the statistics indicating the relative popularity (e.g., impressions 1836, click throughs 1837, click-through rates, hover times, frequency of rollover, etc.) that has been recorded for these various menu choices. In this manner, the human editor has the empirical tracking data available right within the MultiLink editor where the changes are actually made.
  • the ISICI overcomes such limitations because all of the ads in every location may be controlled centrally every time they are loaded; therefore, a revision to a MultiLink menu propagates instantly out to all occurrences of the ad using the MultiLink menu on the Web.
  • MultiLink menus may be served through DoubleClick, et al.
  • MultiLinks can also be layered right on top of any existing ad format such as a banner, Rich Media ad, contextual ad (e.g., Google's Sponsored Links), contextual links (e.g., Vibrant Media), video files (e.g., Quicktime), and/or the like.
  • these other ad formats may serve as the delivery mechanism for MultiLink menus.
  • the MultiLink menus may be distributed through existing distribution methods in addition to and/or in place of the ISICI's call to a central directory such as the Handle System.
  • MultiLink menu enabled ads are engineered, informational, functional, navigable, and centrally controlled. Further, that central control is now augmented with a feedback loop that improves the menus based on empirical user behavior data as tracked from users' interactions with the menus.
  • This feedback may be achieved via human judgment based on this source data (e.g., where the menus are either modified manually, or the automated "assembly line" process is modified to apply different menu creation rules going forward based on human judgment), or the feedback improvements can be fully automated (i.e., become automatically self-improving) by allowed the data to drive changes in the menus directly, based on pre-stored business rules.
  • Example rules include: menu items that are tracked having greater numbers of selections are moved to the top of a menu; menu items that are tracked having greater durations of hover time from an end-user's cursor are moved to the top of menu; sponsored links with higher bids are placed higher in a menu; newer menu item entries are put higher in a menu (e.g., new product announcements); less frequent menu items are put to the top of a menu list to attempt to increase click throughs; mapping of outside lists are used to generate menu link orders (e.g., top-40 lists are used to rank menu items); and/or the like. [00219] Taken together, the integrated suite of services represented by the ISICI enables entirely new conceptual approaches to advertising and customer interaction online.
  • the MultiLink menu enabled ad not only enables the user to pick from a wide variety of choices in relation to an ad (e.g., instead of only a single link resulting in navigation to a splash/landing page), it also enables a fundamentally different approach to servicing users.
  • MultiLinks provide such a wide array of deep links to the user (e.g., MultiLink menus are limited only by the practicalities of screen size, and typically comprise at least 30-40 separate links, neatly unfolding via hierarchical drop-down menus), they expose the user to the entire universe of options available to them; it allows users to navigate through all the choices available at reference target (e.g., a Web site) simply via a mouse rollover, without having to click through from screen to screen on a potentially new and unfamiliar Web site. This "clickless navigation," which can be explored via rollover alone, radically reduces the amount of time required to bring a user directly to an offer, a shopping cart, or a related product.
  • reference target e.g., a Web site
  • This "clickless navigation" is superior to the traditional approach of clicking through a link (e.g., to an ad) to a Web site, then waiting for that page to load, reading the new choices on that page, clicking through to something else, determining that the click was in error and having to click back to follow another path incurring similar navigation load and re-display time penalties, etc.
  • the traditional process is rife with potential for frustration, errors, loss of customer attention, a delay for every single click (for a new page to load), and/or the like. MultiLink menus overcome all of these shortcomings.
  • MultiLinking presents the opportunity to service both a wider spectrum of customers, and a wider spectrum of stages in customers' purchasing cycles.
  • MultiLinks are able to service the entire spectrum of customers in all these stages of the purchasing cycle, and to do it all within a single menu. Hence the MultiLink menu compresses the purchase cycle.
  • the design and implementation heuristics for MultiLink menus may then becomes more subject to a company's marketing strategy whereby different customers in different stages of the cycle can be serviced appropriately, yet all via the same ad. This process can be facilitated via consulting services and sharing of best practices.
  • a MultiLink menu directly expresses the advertiser's marketing strategies with respect to its particular customers and the particular stages of their purchasing cycle.
  • the first menu choice “The Chrysler Story” 1606 expands to display a set of links oriented toward an early-stage customer just getting familiar with different brands.
  • the second choice “The Chrysler Difference” spawns a set of links supporting the choice of Chrysler versus other brands.
  • the third "The Chrysler Lineup" 1618 which is actually shown expanded in the figure, provides detail on the various Chrysler models; in addition, the MultiLink menu takes the user all the way to local dealer inventory information, which has been brought forward all the way from the back-end inventory systems of Chrysler and/or its dealer network, and displayed upfront on the MultiLink menu.
  • the system is self-improving because the user's behavior can be monitored and then fed back into the MultiLink creation/maintenance process going forward.
  • local dealers could be added or removed from the menu based on how many (or few) customers actually click on those particular dealers.
  • the source data that drives the modification of the menu can be another source entirely, such as Chrysler's own independent sales records indicating which dealers are turning over the highest volume of sales.
  • the source data that drives menu improvements can also be the tracking data that captures customers' actual behavior in interacting with the menus: e.g. changing the order of Chrysler models on the menu depending on which models are hovered on the longest, or adding or dropping certain sales incentives based on whether or not they actually draw user click-throughs.
  • MultiLink menus represent a new concept in advertising and indeed in
  • MultiLink drop-down menus are unobtrusive and customer friendly. MultiLink menus are non-disruptive to a user's browser state. They appear upon rollover and they disappear immediately when the user mouses away. The user finds them informative, useful and efficient, even before having to make a leap of faith by clicking through the ad.
  • the user only clicks through to particular links after already determining that this is where he/she really wants to go. Seeing the full range of choices in advance is like the seeing a glass door and simply deciding whether to go through it to what is already visible on the other side, versus seeing an opaque wooden door and having to make a leap of faith that there is something useful on the other side. This is a win/win, where the advertiser gets to expose the user to a wider variety of information and offers than before, yet it is the user who is empowered to navigate and choose.
  • MultiLink menus may use any number of vehicles for aiding in advertising, ecommerce and user interactions, including:
  • MultiLink-enabled Banner Ads i.e., display ads
  • display ads e.g., 1677 of Figure 16
  • MultiLink-enabled Sponsored Links e.g., Google AdSense or AdWords
  • MultiLink menus Placing of MultiLink menus into multimedia files, such as in video files, so when an end-user moves a cursor over the video file, the menu is engaged and the user may pause the video, and the MultiLink menu may further provide information about the scene, products, ads, etc., e.g.; on a home improvement video, Flash video may engage a MultiLink menu, which will have menu items about a product's specifications from the show, accessories, retailers that offer featured products for sale, etc.
  • FIGURE 22 is of a block diagram illustrating embodiments of an Integrated information-engineered and Self-Improving facility for advertising, e- commerce and online Customer Interactions (ISICI) controller 2201.
  • the ISICI controller 2201 may to add, edit, process, store, search, serve, identify, instruct, generate, match, provide and/or update MultiLink related data.
  • processors to process information; such processors are often referred to as central processing units (CPU).
  • CPU central processing units
  • a common form of processor is referred to as a microprocessor.
  • a computer operating system which, typically, is software executed by CPU on a computer, enables and facilitates users to access and operate computer information technology and resources.
  • Common resources employed in information technology systems include: input and output mechanisms through which data may pass into and out of a computer; memory storage into which data may be saved; and processors by which information may be processed.
  • information technology systems are used to collect data for later retrieval, analysis, and manipulation, commonly, which is facilitated through database software.
  • Information technology systems provide interfaces that allow users to access and operate various system components.
  • the ISICI controller 2201 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user input devices 2211; peripheral devices 2212; and/or a communications network 2213.
  • the ISICI controller may even be connected to and/or communicate with a cryptographic processor device 2228.
  • the ISICI controller may communicate with clients 2233 through the communications network.
  • the ISICI may be configured to serve multiple clients and/or users 2233.
  • the ISICI may be distributed to better serve ISICI demands and better balance load and/or service requests.
  • Networks are commonly thought to comprise the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology.
  • server refers generally to a computer, other device, software, and/or combination thereof that processes and responds to the requests of users; and is frequently accessed across a communications network. Servers serve their information to requesting "clients.”
  • client refers generally to a computer, other device, software, or combination thereof that is capable of processing and making requests and obtaining and processing any responses from servers.
  • client and “user” are interchangeable, and are used as such throughout.
  • a computer, other device, software, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is commonly referred to as a "node.”
  • Networks are generally thought to facilitate the transfer of information from source points to destinations.
  • a node specifically tasked with furthering the passage of information from a source to a destination is commonly called a "router.”
  • There are many forms of networks such as Local Area Networks (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc.
  • LANs Local Area Networks
  • WANs Wide Area Networks
  • WLANs Wireless Networks
  • the Internet is generally accepted as being an interconnection of a multitude of networks whereby remote clients and servers may access and interoperate with one another.
  • a ISICI controller 2201 may be based on common computer systems that may comprise, but are not limited to, components such as: a computer systemization 2202 connected to memory 2229.
  • a computer systemization 2202 may comprise a clock 2230, central processing unit (CPU) 2203, a read only memory (ROM) 2206, a random access memory (RAM) 2205, and/or an interface bus 2207, and most frequently, although not necessarily, are all interconnected and/or communicating through a system bus 2204.
  • the computer systemization maybe connected to an internal power source 2286.
  • a cryptographic processor 2226 may be connected to the system bus.
  • the system clock typically has a crystal oscillator and provides a base signal. The clock is typically coupled to the system bus and various clock multipliers that will increase or decrease the base operating frequency for other components interconnected in the computer systemization.
  • the clock and various components in a computer systemization drive signals embodying information throughout the system. Such transmission and reception of signals embodying information throughout a computer systemization may be commonly referred to as communications. These communicative signals may further be transmitted, received, and the cause of return and/or reply signal communications beyond the instant computer systemization to: communications networks, input devices, other computer systemizations, peripheral devices, and/or the like. Of course, any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various computer systems.
  • a global positioning system (GPS) receiver 2275 may be connected to the ISICI 2201; for example through the system bus 2204.
  • GPS global positioning system
  • a single GPS chip such as the Motorola Instant GPS chip may be employed to provide the ISICI 2201 with location awareness.
  • the CPU comprises at least one high-speed data processor adequate to execute component instructions for executing user and/or system-generated requests.
  • the CPU may be a microprocessor such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).
  • the CPU interacts with memory through signal passing through conductive conduits to execute stored instruction code according to conventional data processing techniques. Such signal passing facilitates communication within the ISICI controller and beyond through various interfaces. Should processing requirements dictate a greater amount speed, parallel, mainframe and/or super-computer architectures may similarly be employed. Alternatively, should deployment requirements dictate greater portability, smaller Personal Digital Assistants (PDAs) may be employed.
  • PDAs Personal Digital Assistants
  • the power source 2286 may be of any standard form for powering small electronic circuit board devices such as the following power cells: alkaline, lithium hydride, lithium ion, nickel cadmium, solar cells, and/or the like. Other types of AC or DC power sources may be used as well. In the case of solar cells, in one embodiment, the case provides an aperture through which the solar cell may capture photonic energy.
  • the power cell 2286 is connected to at least one of the interconnected subsequent components of the ISICI thereby providing an electric current to all subsequent components.
  • the power source 2286 is connected to the system bus component 2204.
  • an outside power source 2286 is provided through a connection across the I/O 2208 interface. For example, a USB and/or IEEE 1394 connection carries both data and power across the connection and is therefore a suitable source of power. Interface Adapters
  • Interface bus(ses) 2207 may accept, connect, and/or communicate to a number of interface adapters, conventionally although not necessarily in the form of adapter cards, such as but not limited to: input output interfaces (I/O) 2208, storage interfaces 2209, network interfaces 2210, and/or the like.
  • cryptographic processor interfaces 2227 similarly may be connected to the interface bus.
  • the interface bus provides for the communications of interface adapters with one another as well as with other components of the computer systemization.
  • Interface adapters are adapted for a compatible interface bus.
  • Interface adapters conventionally connect to the interface bus via a slot architecture.
  • Conventional slot architectures may be employed, such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and/or the like.
  • AGP Accelerated Graphics Port
  • Card Bus Card Bus
  • E Industry Standard Architecture
  • MCA Micro Channel Architecture
  • NuBus NuBus
  • PCI(X) Peripheral Component Interconnect Express
  • PCMCIA Personal Computer Memory Card International Association
  • Storage interfaces 2209 may accept, communicate, and/or connect to a number of storage devices such as, but not limited to: storage devices 2214, removable disc devices, and/or the like.
  • Storage interfaces may employ connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.
  • connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.
  • Network interfaces 2210 may accept, communicate, and/or connect to a communications network 2213.
  • Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring, wireless connection such as Bluetooth, Cellular, IEEE 802.11a-x, and/or the like.
  • a communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like.
  • Carrier mediums may include: cable, satellite, telephone, utility, and/or the like.
  • a network interface may be regarded as a specialized form of an input output interface.
  • multiple network interfaces 2210 may be used to engage with various communications network types 2213. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and/or unicast networks.
  • I/O 2208 may accept, communicate, and/or connect to user input devices 2211, peripheral devices 2212, cryptographic processor devices 2228, and/or the like.
  • I/O may employ connection protocols such as, but not limited to: Apple Desktop Bus (ADB); Apple Desktop Connector (ADC); audio: analog, digital, monaural, RCA, stereo, and/or the like; IEEE 1394a/b; infrared; joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; serial; USB; video interface: BNC, coaxial, composite, digital, Digital Visual Interface (DVI), RCA, RF antennae, S-Video, VGA, and/or the like; wireless; and/or the like.
  • ADB Apple Desktop Bus
  • ADC Apple Desktop Connector
  • audio analog, digital, monaural, RCA, stereo, and/or the like
  • IEEE 1394a/b infrared
  • joystick keyboard
  • midi optical
  • PC AT PC AT
  • PS/2 parallel
  • radio serial
  • USB video
  • a common output device is a television set 145, which accepts signals from a video interface.
  • a video display which typically comprises a Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) based monitor with an interface (e.g., DVI circuitry and cable) that accepts signals from a video interface, may be used.
  • the video interface composites information generated by a computer systemization and generates video signals based on the composited information in a video memory frame.
  • the video interface provides the composited video information through a video connection interface that accepts a video display interface (e.g., an RCA composite video connector accepting an RCA composite video cable; a DVI connector accepting a DVI display cable, etc.).
  • User input devices 2211 may be card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, mouse (mice), remote controls, retina readers, trackballs, trackpads, and/or the like.
  • Peripheral devices 2212 may be connected and/or communicate to I/O and/or other facilities of the like such as network interfaces, storage interfaces, and/or the like.
  • Peripheral devices maybe audio devices, cameras, dongles (e.g., for copyprotection, ensuring secure transactions with a digital signature, and/or the like), external processors (for added functionality), goggles, microphones, monitors, network interfaces, printers, scanners, storage devices, video devices, video sources, visors, and/or the like.
  • the ISICI controller may be embodied as an embedded, dedicated, and/or monitor-less (i.e., headless) device, wherein access would be provided over a network interface connection.
  • Cryptographic units such as, but- not limited to, microcontrollers, processors 2226, interfaces 2227, and/or devices 2228 may be attached, and/or communicate with the ISICI controller.
  • a MC68HC16 microcontroller commonly manufactured by Motorola Inc., may be used for and/or within cryptographic units. Equivalent microcontrollers and/or processors may also be used.
  • the MC68HC16 microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the 16 MHz configuration and requires less than one second to perform a 512-bit RSA private key operation.
  • Cryptographic units support the authentication of communications from interacting agents, as well as allowing for anonymous transactions.
  • Cryptographic units may also be configured as part of CPU.
  • Other commercially available specialized cryptographic processors include VLSI Technology's 33 MHz 6868 or Semaphore Communications' 40 MHz Roadrunner 184.
  • any mechanization and/or embodiment allowing a processor to affect the storage and/or retrieval of information is regarded as memory 2229.
  • memory is a fungible technology and resource, thus, any number of memory embodiments may be employed in lieu of or in concert with one another.
  • a ISICI controller and/or a computer systemization may employ various forms of memory 2229.
  • a computer systemization may be configured wherein the functionality of on-chip CPU memory (e.g., registers), RAM, ROM, and any other storage devices are provided by a paper punch tape or paper punch card mechanism; of course such an embodiment would result in an extremely slow rate of operation.
  • memory 2229 will include ROM 2206, RAM 2205, and a storage device 2214.
  • a storage device 2214 may be any conventional computer system storage. Storage devices may include a drum; a (fixed and/or removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., CD ROM/RAM/Recordable (R), Rewritable (RW), DVD R/RW, etc.); and/or other devices of the like.
  • a computer systemization generally requires and makes use of memory.
  • the memory 2229 may contain a collection of program and/or database components and/or data such as, but not limited to: operating system component(s) 2215
  • information server component(s) 2216 information server
  • user interface component(s) 2217 user interface
  • Web browser component(s) 2218 Web browser
  • database(s) 2219 cryptographic server component(s) 2220 (cryptographic server); Information Access Multiple Resolution Server (IAMRS) component(s); ISICI component(s) 2235; and/or the like (i.e., collectively a component collection).
  • IAMRS Information Access Multiple Resolution Server
  • non-conventional software components such as those in the component collection, typically, are stored in a local storage device 2214, they may also be loaded and/or stored, in full or in part, in memory such as: peripheral devices, RAM, remote storage facilities through a communications network, ROM, various forms of memory, and/or the like.
  • the operating system component 2215 is executable instruction code facilitating the operation of a ISICI controller.
  • the operating system facilitates access of 170, network interfaces, peripheral devices, storage devices, and/or the like.
  • the operating system may be a highly fault tolerant, scalable, and secure system such as Apple Macintosh OS X (Server), AT&T Plan 9, Be OS, Linux, Unix, and/or the like operating systems.
  • Apple Macintosh OS Microsoft DOS, Palm OS, Windows 2000/2003/3.1/95/98/CE/Millenium/NT/XP (Server), and/or the like.
  • An operating system may communicate to and/or with other components in a component collection, including itself, and/or the like. Most frequently, the operating system communicates with other program components, user interfaces, and/or the like. For example, the operating system may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses. The operating system, once executed by the CPU, may enable the interaction with communications networks, data, I/O, peripheral devices, program components, memory, user input devices, and/or the like. The operating system may provide communications protocols that allow the ISICI controller to communicate with other entities through a communications network 2213. Various communication protocols may he used by the ISICI controller as a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/or the like.
  • An information server component 2216 is comprised of stored instruction code signals that engage the CPU circuit components.
  • the information server may be a conventional Internet information server such as, but not limited to Apache Software Foundation's Apache, Microsoft's Internet Information Server, and/or the.
  • the information server may allow for the execution of program components through facilities such as Active Server Page (ASP), ActiveX, (ANSI) (Objective-) C (++), Common Gateway Interface (CGI) scripts, Java, JavaScript, Practical Extraction Report Language (PERL), Python, WebObjects, and/or the like.
  • the information server may support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), and/or the like.
  • FTP File Transfer Protocol
  • HTTP HyperText Transfer Protocol
  • HTTPS Secure Hypertext Transfer Protocol
  • SSL Secure Socket Layer
  • the information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components.
  • DNS Domain Name System
  • a request such as http://123.124.125.126/mylnformation.html might have the IP portion of the request "123.124.125.126” resolved by a DNS server to an information server at that IP address; that information server might in turn further parse the http request for the "/mylnformation.html” portion of the request and resolve it to a location in memory containing the information "mylnformation.html.”
  • other information serving protocols may be employed across various ports, e.g., FTP communications across port 21, and/or the like.
  • An information server may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like.
  • UDDI Universal Description, discover and Integration
  • WSDL Web Services Description Language
  • WSFL Web Services Flow Language
  • the information server communicates with the ISICI database 2219, operating systems, other program components, user interfaces, Web browsers, and/or the like.
  • Access to the ISICI database may be achieved through a number of database bridge mechanisms such as through scripting languages as enumerated below (e.g., CGI) and through inter-application communication channels as enumerated below (e.g., CORBA, WebObjects, etc.). Any data requests through a Web browser are parsed through the bridge mechanism into appropriate grammars as required by the ISICI.
  • the information server would provide a Web form accessible by a Web browser. Entries made into supplied fields in the Web form are tagged as having been entered into the particular fields, and parsed as such. The entered terms are then passed along with the field tags, which act to instruct the parser to generate queries directed to appropriate tables and/or fields.
  • the parser may generate queries in standard SQL by instantiating a search string with the proper join/select commands based on the tagged text entries, wherein the resulting command is provided over the bridge mechanism to the ISICI as a query.
  • the results are passed over the bridge mechanism, and may be parsed for formatting and generation of a new results Web page by the bridge mechanism. Such a new results Web page is then provided to the information server, which may supply it to the requesting
  • an information server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
  • GUIs Graphical user interfaces
  • a user interface component 2217 is comprised of stored instruction code signals that engage the CPU circuit components.
  • the user interface may be a conventional graphic user interface as provided by, with, and/or atop operating systems and/or operating environments such as Apple Macintosh OS, e.g., Aqua, Microsoft Windows (NT/XP), Unix X Windows (KDE, Gnome, and/or the like), mythTV, and/or the like.
  • the user interface may allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system facilities through textual and/or graphical facilities.
  • the user interface provides a facility through which users may affect, interact, and/or operate a computer system.
  • a user interface may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the user interface communicates with operating systems, other program components, and/or the like.
  • the user interface may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
  • a Web browser component 2218 is comprised of stored instruction code signals that engage the CPU circuit components.
  • the Web browser may be a conventional hypertext viewing application such as Apple Safari, Microsoft Internet Explorer, Mozilla Firefox, Netscape Navigator, and/or the like. Secure Web browsing may be supplied with 128bit (or greater) encryption by way of HTTPS, SSL, and/or the like.
  • Some Web browsers allow for the execution of program components through facilities such as Java, JavaScript, ActiveX, and/or the like.
  • Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices.
  • a Web browser may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like.
  • the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
  • information servers operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
  • a combined application may be developed to perform similar functions of both.
  • the combined application would similarly affect the obtaining and the provision of information to users, user agents, and/or the like from ISICI enabled nodes.
  • the combined application may be nugatory on systems employing standard Web browsers.
  • a mail server component 2221 is comprised of stored instruction code signals that engage the CPU circuit components.
  • the mail server may be a conventional Internet mail server such as, but not limited to sendmail, Microsoft Exchange, and/or the.
  • the mail server may allow for the execution of program components through facilities such as ASP, ActiveX, (ANSI) (Objective-) C (++), CGI scripts, Java, JavaScript, PERL, pipes, Python, WebObjects, and/or the like.
  • the mail server may support communications protocols such as, but not limited to: Internet message access protocol (IMAP), Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol (SMTP), and/or the like.
  • IMAP Internet message access protocol
  • POP3 post office protocol
  • SMTP simple mail transfer protocol
  • the mail server can route, forward, and process incoming and outgoing mail messages that have been sent, relayed and/or otherwise traversing through and/or to the ISICI.
  • Access to the ISICI mail may be achieved through a number of APIs offered by the individual Web server components and/or the operating system.
  • a mail server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
  • a mail client component 2222 is comprised of stored instruction code signals that engage the CPU circuit components.
  • the mail client may be a conventional mail viewing application such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla Thunderbird, and/or the like.
  • Mail clients may support a number of transfer protocols, such as: IMAP, Microsoft Exchange, POP3,
  • a mail client may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the mail client communicates with mail servers, operating systems, other mail clients, and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses. Generally, the mail client provides a facility to compose and transmit electronic mail messages.
  • a cryptographic server component 2220 is comprised of stored instruction code signals that engage the CPU circuit components 2203, cryptographic processor 2226, cryptographic processor interface 2227, cryptographic processor device 2228, and/or the like. Cryptographic processor interfaces will allow for expedition of encryption and/or decryption requests by the cryptographic component; however, the cryptographic component, alternatively, may run on a conventional CPU.
  • the cryptographic component allows for the encryption and/or decryption of provided data.
  • the cryptographic component allows for both symmetric and asymmetric (e.g., Pretty Good Privacy (PGP)) encryption and/or decryption.
  • PGP Pretty Good Privacy
  • the cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, password access protection, public key management, and/or the like.
  • the cryptographic component will facilitate numerous (encryption and/or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptic Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash function), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like.
  • digital certificates e.g., X.509 authentication framework
  • the ISICI may encrypt all incoming and/or outgoing communications and may serve as node within a virtual private network (VPN) with a wider communications network.
  • the cryptographic component facilitates the process of "security authorization" whereby access to a resource is inhibited by a security protocol wherein the cryptographic component effects authorized access to the secured resource.
  • the cryptographic component may provide unique identifiers of content, e.g., employing and MD5 hash to obtain a unique signature for an digital audio file.
  • a cryptographic component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like.
  • the cryptographic component supports encryption schemes allowing for the secure transmission of information across a communications network to enable a ISICI component to engage in secure transactions if so desired.
  • the cryptographic component facilitates the secure accessing of resources on ISICI and facilitates the access of secured resources on remote systems; i.e., it may act as a client and/or server of secured resources.
  • the cryptographic component communicates with information servers, operating systems, other program components, and/or the like.
  • the cryptographic component may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
  • a ISICI database component 2219 may be embodied in a database and its stored data.
  • the database is comprised of stored instruction code signals that engage the CPU circuit components; the stored instruction code portion configuring the CPU to process the stored data.
  • the database may be a conventional, fault tolerant, relational, scalable, secure database such as Oracle or Sybase.
  • Relational databases are an extension of a flat file. Relational databases consist of a series of related tables. The tables are interconnected via a key field. Use of the key field allows the combination of the tables by indexing against the key field; i.e., the key fields act as dimensional pivot points for combining information from various tables. Relationships generally identify links maintained between tables by matching primary keys. Primary keys represent fields that uniquely identify the rows of a table in a relational database. More precisely, they uniquely identify rows of a table on the "one" side of a one-to-many relationship.
  • the ISICI database may be implemented using various standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in (structured) files.
  • an object-oriented database may be used, such as Frontier, ObjectStore, Poet, Zope, and/or the like.
  • Object databases can include a number of object collections that are grouped and/or linked together by common attributes; they may be related to other object collections by some common attributes. Object-oriented databases perform similarly to relational databases with the exception that objects are not just pieces of data but may have other types of functionality encapsulated within a given object.
  • the ISICI database 2219 may be integrated into another component such as the ISICI component 2235.
  • the database may be implemented as a mix of data structures, objects, and relational structures. Databases may be consolidated and/or distributed in countless variations through standard data processing techniques. Portions of databases, e.g., tables, may be exported and/or imported and thus decentralized and/or integrated.
  • the database component 2219 includes several tables
  • a UNI (e.g., Handle, DOI and/or other UNIs) table 2219a includes fields such as, but not limited to: DOI, creator name, creator contact information, registration agency, and/or the like.
  • An URL table 2219b includes fields such as, but not limited to: DOI, multiple resolution identifier, URL, and/or the like.
  • a metadata table 2219c includes fields such as, but not limited to: DOI, multiple resolution identifier, URL, MultiLink menu specification, custom field 1, custom field 2, etc., and/or the like.
  • a multiple resolution table 2219d includes fields such as, but not limited to: DOI, metadata, and/or the like.
  • a RFID table 2219e includes fields such as, but not limited to: RFID number, DOI, multiple resolution identifier, GPS coordinates, transaction number, and/or the like.
  • a menu specification table 2219f includes fields such as, but not limited to: DOI, metadata, multiple resolution identifier, viewable entry, MultiLink menu specification, menu label, and/or the like.
  • An personal (DOI information) table 2219g includes fields such as, but not limited to: DOI, multiple resolution identifier, telephone number, Voice over IP ID (e.g., the ID user name and password), instant messenger ID (e.g., the ID user name and password), email, metadata, and/or the like.
  • a access control table 2219h includes fields such as, but not limited to: DOI, metadata, multiple resolution identifier, owner, users, control setting, and/or the like.
  • An interlink index table 2219i includes fields such as, but not limited to: DOI, metadata, multiple resolution identifier, sponsored link status, number of matched links, number of missing links, number of unknown links, popularity ranking, and/or the like.
  • a tracker table 2219i includes fields such as, but not limited to: IP address, DOI, multiple resolution identifier, number of times menu item is selected, amount of time menu item is considered, number of time menu item is passed over, and/or the like. All the tables may be related by (enhanced) DOI key field entries as they are unique.
  • user programs may contain various user interface primitives, which may serve to update the ISICI.
  • various accounts may require custom database tables depending upon the environments and the types of clients a ISICI may need to serve. It should be noted that any unique fields may be designated as a key field throughout.
  • these tables have been decentralized into their own databases and their respective database controllers (i.e., individual database controllers for each of the above tables). Employing standard data processing techniques, one may further distribute the databases over several computer systemizations and/or storage devices. Similarly, configurations of the decentralized database controllers may be varied by consolidating and/or distributing the various database components 2219a-i.
  • the ISICI may be configured to keep track of various settings, inputs, and parameters via database controllers.
  • a ISICI database may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the ISICI database communicates with a ISICI component, other program components, and/or the like. The database may contain, retain, and provide information regarding other nodes and data.
  • IAMRS Information Access Multiple Resolution Server
  • An IAMRS component 2225 is comprised of stored instruction code signals that engage the CPU circuit components.
  • the ISICI affects accessing, obtaining and the provision of information, and/or the like between nodes on a communications network.
  • the IAMRS has the ability to resolve UNIs to multiple instantiations.
  • the IAMRS acts as a lookup facility to create, maintain, and update associations between a given piece of information, its DOI, and its current locations.
  • the IAMRS coordinates with the ISICI database to identify nodes that may be useful for improving data transfer for requested information, for resolving to various formats of the requesting information, providing an enhanced mechanism to create queries regarding the information, and/or the like.
  • An IAMRS enabling access of information between nodes may be developed by employing standard development tools such as, but not limited to: C++, shell scripts, Java, Javascript, SQL commands, Web application server extensions, Apache modules, Perl scripts, binary executables, and/or other mapping tools, and/or the like.
  • the IAMRS server employs a cryptographic server to encrypt and decrypt communications.
  • the IAMRS may service requests, update association information for UNIs, and much more.
  • a ISICI module may communicate to and/or with other modules in a module collection, including itself, and/or facilities of the like. Most frequently, the IAMRS module communicates with a ISICI database, operating systems, other program modules, and/or the like.
  • the IAMRS may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses
  • An ISICI component 2235 is comprised of stored instruction code signals that engage the CPU circuit components. As such, the ISICI effects accessing, obtaining and the provision of information, services, transactions, and/or the like across various communications networks.
  • the ISICI component may further the provision of
  • a ISICI may have access to a MultiLink menu specification that details what appearance the MultiLink menu is to have for a particular requesting entity.
  • the disclosure teaches that multiple ISICI may each provide multiple views of a given MultiLink depending upon the requesting entity and/or the ISICFs needs.
  • a ISICI provides advertising views of MultiLinks that vary depending upon for whom the ad is being placed.
  • the ISICI is separate from the content provider, and facilitates requests for MultiLink menus apart from a content provider's Web page.
  • the ISICI is integrated into a content provider's system.
  • the ISICI provides an IntraConnect facility that limits access and reference to content within an organization.
  • the ISICI also teaches a MultiLink editor that allows the varying of MultiLink DOI records and menu specifications..
  • a ISICI component enabling access of information between nodes may be developed by employing standard development tools such as, but not limited to: (ANSI) (Objective-) C (++), Apache components, binary executables, database adapters, Java, JavaScript, mapping tools, procedural and object oriented development tools, PERL, Python, shell scripts, SQL commands, Web application server extensions, WebObjects, and/or the like.
  • the ISICI server employs a cryptographic server to encrypt and decrypt communications.
  • a ISICI component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the ISICI component communicates with a ISICI database, operating systems, other program components, and/or the like.
  • the ISICI may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
  • any of the ISICI node controller components may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/or deployment.
  • the component collection may be combined in any number of ways to facilitate deployment and/or development. To accomplish this, one may integrate the components into a common code base or in a facility that can dynamically load the components on demand in an integrated fashion.
  • the component collection may be consolidated and/or distributed in countless variations through standard data processing and/or development techniques. Multiple instances of any one of the program components in the program component collection may be instantiated on a single node, and/or across numerous nodes to improve performance through load-balancing and/or data-processing techniques. Furthermore, single instances may also be distributed across multiple controllers and/or storage devices; e.g., databases. All program component instances and controllers working in concert may do so through standard data processing communication techniques.
  • the configuration of the ISICI controller will depend on the context of system deployment. Factors such as, but not limited to, the budget, capacity, location, and/or use of the underlying hardware resources may affect deployment requirements and configuration. Regardless of if the configuration results in more consolidated and/or integrated program components, results in a more distributed series of program components, and/or results in some combination between a consolidated and distributed configuration, data may be communicated, obtained, and/or provided. Instances of components consolidated into a common code base from the program component collection may communicate, obtain, and/or provide data.
  • intra-application data processing communication techniques such as, but not limited to: data referencing (e.g., pointers), internal messaging, object instance variable communication, shared memory space, variable passing, and/or the like.
  • component collection elements are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other component elements may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), Common Object Request Broker Architecture (CORBA), process pipes, shared files, and/or the like.
  • API Application Program Interfaces
  • DCOM Component Object Model
  • CORBA Common Object Request Broker Architecture
  • a grammar may be developed by using standard development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing functionality, which in turn may form the basis of communication messages within and between components. Again, the configuration will depend upon the context of system deployment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Multimedia (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Human Computer Interaction (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne la mise en oeuvre d'appareils, de procédés et de systèmes dans un mécanisme intégré de mise au point d'informations automatiquement améliorées destiné à la publicité, au commerce électronique et à des interactions de client en ligne (ISICI). Dans un mode de réalisation, le ISICI est constitué de trois composants permettant: 1) de créer et de maintenir des composants de menu à liaisons multiples; 2) d'enregistrer et de mettre à jour des composants d'enregistrement sous-jacents à liaisons multiples; et 3) de distribuer et de rendre visible le composant de menus à liaisons multiples. Le ISICI permet de créer des menus à liaisons multiples. Ces menus peuvent apparaître sur des liaisons quelconques, dans des publicités, dans le commerce électronique, etc. Le ISICI fournit un mécanisme de suivi du comportement de clients utilisant le menu à liaisons multiples. Ces informations de suivi sont renvoyées au ISICI, ce qui lui permet de redéfinir la structure de menu en réponse au suivi d'utilisation réelle. En conséquence, le ISICI permet de comprimer le cycle d'achat passant de plusieurs mois à des moments, et/ou de servir une plus grande variété de clients potentiels qui sont déjà impliqués dans des étapes variées du cycle d'achat.
EP06718080A 2005-01-11 2006-01-11 Appareils, procedes et systemes pour publicite, commerce electronique et interactions de clients en ligne a mise au point d'informations et imposition automatique integrees Withdrawn EP1844385A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US64280905P 2005-01-11 2005-01-11
US72668905P 2005-10-14 2005-10-14
PCT/US2006/000965 WO2006076424A2 (fr) 2005-01-11 2006-01-11 Appareils, procedes et systemes pour publicite, commerce electronique et interactions de clients en ligne a mise au point d'informations et imposition automatique integrees

Publications (1)

Publication Number Publication Date
EP1844385A2 true EP1844385A2 (fr) 2007-10-17

Family

ID=36678160

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06718080A Withdrawn EP1844385A2 (fr) 2005-01-11 2006-01-11 Appareils, procedes et systemes pour publicite, commerce electronique et interactions de clients en ligne a mise au point d'informations et imposition automatique integrees

Country Status (5)

Country Link
US (1) US20100293221A1 (fr)
EP (1) EP1844385A2 (fr)
JP (2) JP2008530639A (fr)
SG (3) SG10201700044VA (fr)
WO (1) WO2006076424A2 (fr)

Families Citing this family (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8376829B2 (en) 2005-01-14 2013-02-19 Etasse Limited Slot machine game with respin feature which identifies potential wins
CA2615659A1 (fr) * 2005-07-22 2007-05-10 Yogesh Chunilal Rathod Systeme universel de gestion des connaissances et de recherche bureau
US9286388B2 (en) * 2005-08-04 2016-03-15 Time Warner Cable Enterprises Llc Method and apparatus for context-specific content delivery
US7673017B2 (en) 2005-09-06 2010-03-02 Interpolls Network Inc. Systems and methods for integrating XML syndication feeds into online advertisement
JP4706853B2 (ja) * 2006-03-30 2011-06-22 富士ゼロックス株式会社 画像処理装置および画像データ一覧表示方法
US20070256095A1 (en) * 2006-04-27 2007-11-01 Collins Robert J System and method for the normalization of advertising metrics
US9386327B2 (en) 2006-05-24 2016-07-05 Time Warner Cable Enterprises Llc Secondary content insertion apparatus and methods
EP2033156A4 (fr) * 2006-06-29 2012-09-19 Nielsen Media Res Inc Procédés et appareils pour surveiller un comportement de consommateur associé à des services web basés sur la localisation
US8690664B2 (en) 2006-09-25 2014-04-08 Etasse Limited Slot machine game with additional award indicator
US20080126954A1 (en) * 2006-09-29 2008-05-29 Nabble, Inc. Method and system for optimum placement of a thread in an online forum
US7908531B2 (en) * 2006-09-29 2011-03-15 Teradyne, Inc. Networked test system
US8521832B1 (en) 2006-10-04 2013-08-27 Yahoo! Inc. Mobile monetization
US8511565B2 (en) 2006-10-17 2013-08-20 Silverbrook Research Pty Ltd Method of providing information via context searching of a printed graphic image
US20080091521A1 (en) * 2006-10-17 2008-04-17 Yahoo! Inc. Supplemental display matching using syndication information
US8337292B2 (en) 2006-11-10 2012-12-25 Etasse Limited Slot machine game with side wager on reel order
US8886707B2 (en) 2006-12-15 2014-11-11 Yahoo! Inc. Intervention processing of requests relative to syndication data feed items
US8402163B2 (en) * 2007-02-21 2013-03-19 John Almeida Target advertising to a specific user offered through an intermediary internet service provider, server or wireless network
US8543925B2 (en) 2007-05-25 2013-09-24 Microsoft Corporation Contextually aware client application
US8639714B2 (en) * 2007-08-29 2014-01-28 Yahoo! Inc. Integrating sponsored media with user-generated content
US20090076916A1 (en) * 2007-09-17 2009-03-19 Interpols Network Incorporated Systems and methods for third-party ad serving of internet widgets
US9123079B2 (en) 2007-11-05 2015-09-01 Facebook, Inc. Sponsored stories unit creation from organic activity stream
US20120203831A1 (en) 2011-02-03 2012-08-09 Kent Schoen Sponsored Stories Unit Creation from Organic Activity Stream
US8799068B2 (en) 2007-11-05 2014-08-05 Facebook, Inc. Social advertisements and other informational messages on a social networking website, and advertising model for same
US9990652B2 (en) 2010-12-15 2018-06-05 Facebook, Inc. Targeting social advertising to friends of users who have interacted with an object associated with the advertising
US8702493B2 (en) 2007-11-09 2014-04-22 Etasse Limited Slot machine game with award based on another machine
US20090150261A1 (en) * 2007-12-08 2009-06-11 Allen Lee Hogan Method and apparatus for providing status of inventory
US20090158166A1 (en) * 2007-12-14 2009-06-18 Dewar Ami H Method, system, and computer program product for automatic rearrangement of modules based on user interaction
US8473194B2 (en) * 2008-01-03 2013-06-25 Groundspeak, Inc. System and method for conducting a location based search
US8036646B1 (en) * 2008-05-21 2011-10-11 Sprint Communications Company L.P. Right-sized multimedia content distribution over a cellular network
US8036690B1 (en) 2008-06-04 2011-10-11 Sprint Communciations Company L.P. Download prioritization for intelligent content distribution
US8549163B2 (en) * 2008-09-18 2013-10-01 Jonathan M. Urdan Passive parameter based demographics generation
AU2010202034B1 (en) 2010-04-07 2010-12-23 Limelight Networks, Inc. Partial object distribution in content delivery network
WO2010033938A2 (fr) * 2008-09-19 2010-03-25 Limelight Networks, Inc. Distribution de vignettes de serveur de flux de réseau de fourniture de contenus
AU2010276462B1 (en) 2010-12-27 2012-01-12 Limelight Networks, Inc. Partial object caching
US9519885B2 (en) * 2008-10-03 2016-12-13 The Curators Of The University Of Missouri System and method for linking a web-based resource with an electronic medical record
KR101183657B1 (ko) * 2008-12-22 2012-09-17 한국전자통신연구원 웹을 이용한 개인 지식 관리 시스템 및 방법
US9215423B2 (en) 2009-03-30 2015-12-15 Time Warner Cable Enterprises Llc Recommendation engine apparatus and methods
KR20120028885A (ko) 2009-05-08 2012-03-23 조켐 오와이 행동 및 상황 데이터 분석을 위한 시스템 및 방법
US8103553B2 (en) * 2009-06-06 2012-01-24 Bullock Roddy Mckee Method for making money on internet news sites and blogs
US8065193B2 (en) * 2009-06-06 2011-11-22 Bullock Roddy Mckee Method for making money on the internet
US10540665B2 (en) 2009-06-24 2020-01-21 Microsoft Technology Licensing, Llc Referral-based sponsorship of access to content item sets
US8719729B2 (en) * 2009-06-25 2014-05-06 Ncr Corporation User interface for a computing device
US8813124B2 (en) 2009-07-15 2014-08-19 Time Warner Cable Enterprises Llc Methods and apparatus for targeted secondary content insertion
US20110167080A1 (en) * 2009-07-24 2011-07-07 eFaqt B.V. Method and apparatus for guided learning of an information source
US8386482B2 (en) * 2009-09-02 2013-02-26 Xurmo Technologies Private Limited Method for personalizing information retrieval in a communication network
US10235462B2 (en) 2009-09-16 2019-03-19 International Business Machines Corporation Analyzing an interaction history to generate a customized webpage
US11727415B2 (en) * 2009-12-30 2023-08-15 Avery Dennison Retail Information Services Llc System for the merchandising and delivery of customized information related to a specific product of interest to a consumer
US20110239103A1 (en) * 2010-03-23 2011-09-29 Microsoft Corporation Detecting virality paths and supporting referral monetization
US20110264530A1 (en) 2010-04-23 2011-10-27 Bryan Santangelo Apparatus and methods for dynamic secondary content and data insertion and delivery
US20110302264A1 (en) * 2010-06-02 2011-12-08 International Business Machines Corporation Rfid network to support processing of rfid data captured within a network domain
US8271312B2 (en) 2010-08-25 2012-09-18 Hewlett-Packard Development Company, L.P. Introducing revenue-generating features
US20120050316A1 (en) * 2010-08-31 2012-03-01 Nokia Corporation Methods and apparatuses for enhancing wallpaper display
US20130283231A1 (en) * 2010-11-24 2013-10-24 Van Megchelen & Tilanus B.V. Method and System for Compiling a Unique Sample Code for an Existing Digital Sample
US9317621B2 (en) * 2011-01-06 2016-04-19 Microsoft Technology Licensing, Llc Providing deep links in association with toolbars
US20120246003A1 (en) * 2011-03-21 2012-09-27 Hart Gregory M Advertisement Service
US9262518B2 (en) * 2011-05-04 2016-02-16 Yahoo! Inc. Dynamically determining the relatedness of web objects
US8521655B2 (en) * 2011-06-06 2013-08-27 Bizequity Llc Engine, system and method for providing cloud-based business intelligence
US8943015B2 (en) 2011-12-22 2015-01-27 Google Technology Holdings LLC Hierarchical behavioral profile
US9110998B2 (en) * 2011-12-22 2015-08-18 Google Technology Holdings LLC Hierarchical behavioral profile
US9710844B2 (en) * 2012-05-02 2017-07-18 Sears Brands, L.L.C. Object driven newsfeed
JP6022215B2 (ja) 2012-05-31 2016-11-09 任天堂株式会社 投稿情報共有システム、情報処理システム、情報処理方法、プログラムおよびコンピュータプラットフォーム
JP6159511B2 (ja) * 2012-06-01 2017-07-05 任天堂株式会社 情報処理システム、情報処理装置および情報処理方法
JP6062722B2 (ja) 2012-11-16 2017-01-18 任天堂株式会社 情報処理システム、情報処理装置、情報処理方法、およびコンピュータプログラム
US10212986B2 (en) 2012-12-09 2019-02-26 Arris Enterprises Llc System, apparel, and method for identifying performance of workout routines
US9278255B2 (en) 2012-12-09 2016-03-08 Arris Enterprises, Inc. System and method for activity recognition
ES2805343T3 (es) * 2012-12-18 2021-02-11 Thomson Reuters Entpr Centre Gmbh Sistemas y procesos habilitados para dispositivos móviles para plataforma de investigación inteligente
US9215075B1 (en) 2013-03-15 2015-12-15 Poltorak Technologies Llc System and method for secure relayed communications from an implantable medical device
US10037262B2 (en) * 2013-04-01 2018-07-31 Infosys Limited Accelerated test automation framework
US10198743B2 (en) * 2013-04-09 2019-02-05 Excalibur Ip, Llc Detecting prohibited data use in auction-based online advertising
US9589291B1 (en) * 2013-09-25 2017-03-07 Amazon Technologies, Inc. Identifying matching items in an electronic catalog
CN107979592B (zh) * 2013-09-30 2020-06-30 腾讯科技（深圳）有限公司 一种发送业务请求消息的方法及装置
KR20170010752A (ko) * 2014-03-24 2017-02-01 브라이트에지 테크놀로지스 인코포레이티드 콘텐츠 관리 시스템
US20160342590A1 (en) * 2015-05-20 2016-11-24 Fti Consulting, Inc. Computer-Implemented System And Method For Sorting, Filtering, And Displaying Documents
KR101813901B1 (ko) * 2015-07-29 2018-01-03 성 완 김 광고 웹사이트를 이용한 온라인 광고 방법
US20170116047A1 (en) * 2015-10-25 2017-04-27 Khozem Z. Dohadwala Further applications of Reading State control - A method for repositioning reading material on electronic devices
US20170169443A1 (en) * 2015-12-10 2017-06-15 Taglynx, LLC Tag link creation and campaign tracking
US10291573B2 (en) * 2016-01-07 2019-05-14 Dell Products L.P. Workflow to distribute content across a plurality of social media platforms
US10453080B2 (en) 2016-01-27 2019-10-22 International Business Machines Corporation Optimizing registration fields with user engagement score
US10586023B2 (en) 2016-04-21 2020-03-10 Time Warner Cable Enterprises Llc Methods and apparatus for secondary content management and fraud prevention
JP6944170B2 (ja) * 2016-09-19 2021-10-06 コンテンツ ディレクションズ，インコーポレイテッド ディービーエー リンクストーム 境界上ウェブ・コンポジタの装置、方法、およびシステム
US10447642B2 (en) 2017-02-16 2019-10-15 Facebook, Inc. Techniques for augmenting entity references in a messaging system
US10659928B2 (en) * 2017-02-16 2020-05-19 Facebook, Inc. Techniques for communicating entity references in a messaging thread
US10484317B2 (en) 2017-02-16 2019-11-19 Facebook, Inc. Techniques for generating messages to entities referenced in a messaging thread
US20190018545A1 (en) * 2017-07-13 2019-01-17 International Business Machines Corporation System and method for rapid financial app prototyping
US11403849B2 (en) 2019-09-25 2022-08-02 Charter Communications Operating, Llc Methods and apparatus for characterization of digital content
US11430019B2 (en) * 2020-11-19 2022-08-30 Content Directions, Inc. Video advertisement augmentation with dynamic web content
US11669582B2 (en) * 2021-03-24 2023-06-06 Rookie Road, Inc. Systems and methods for automatic resource replacement
WO2024054214A1 (fr) * 2022-09-09 2024-03-14 Rakuten Mobile, Inc. Procédé de gestion de flux de travail, système, et produit programme d'ordinateur avec des caractéristiques de consignation, de débogage et de reprise en temps réel

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3502114B2 (ja) * 1992-10-14 2004-03-02 株式会社日立製作所 情報サービスシステム
US6018342A (en) * 1995-07-03 2000-01-25 Sun Microsystems, Inc. Automatically generated content-based history mechanism
US5848396A (en) * 1996-04-26 1998-12-08 Freedom Of Information, Inc. Method and apparatus for determining behavioral profile of a computer user
JP4196137B2 (ja) * 1998-09-09 2008-12-17 株式会社エクォス・リサーチ 目的地設定装置
JP2000148675A (ja) * 1998-11-09 2000-05-30 Nec Corp カスタマイズされた広告をｗｗｗ上で提供する装置及び方法
US6401096B1 (en) * 1999-03-26 2002-06-04 Paul Zellweger Method and apparatus for generating user profile reports using a content menu
JP3602455B2 (ja) * 2000-08-22 2004-12-15 株式会社ジャストシステム メニュー提供装置、並びにプログラム
JP2002132822A (ja) * 2000-10-23 2002-05-10 Nippon Telegr & Teleph Corp <Ntt> インターネット広告配信システム及びインターネット広告配信方法
JP2004530183A (ja) * 2001-01-25 2004-09-30 デービッド・シドマン 情報アクセスを実行する多重解決のための装置、方法及びシステム
US20020143623A1 (en) * 2001-03-29 2002-10-03 Dayley J. Don Method for personalized drive-thru service
US7334251B2 (en) * 2002-02-11 2008-02-19 Scientific-Atlanta, Inc. Management of television advertising
US7930206B2 (en) * 2003-11-03 2011-04-19 Google Inc. System and method for enabling an advertisement to follow the user to additional web pages
US20050108406A1 (en) * 2003-11-07 2005-05-19 Dynalab Inc. System and method for dynamically generating a customized menu page
US7472376B2 (en) * 2005-05-27 2008-12-30 Microsoft Corporation Method and system for customizations in a dynamic environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006076424A2 *

Also Published As

Publication number Publication date
US20100293221A1 (en) 2010-11-18
JP5355733B2 (ja) 2013-11-27
SG192498A1 (en) 2013-08-30
JP2008530639A (ja) 2008-08-07
SG10201700044VA (en) 2017-02-27
WO2006076424A3 (fr) 2008-08-14
SG158874A1 (en) 2010-02-26
WO2006076424A2 (fr) 2006-07-20
JP2012146319A (ja) 2012-08-02

Similar Documents

Publication Publication Date Title
US20100293221A1 (en) Apparatuses, Methods And Systems For Integrated, Information-Engineered And Self-Improving Advertising, E-Commerce And Online Customer Interactions
US20100281364A1 (en) Apparatuses, Methods and Systems For Portable Universal Profile
US11443358B2 (en) Methods and systems for annotation of digital information
US20150039442A1 (en) Multiple-Resolution, Information-Engineered, Self-Improving Advertising and Information Access Apparatuses, Methods and Systems
US8538821B2 (en) System and method for community aided research and shopping
US8271878B2 (en) Behavior-based selection of items to present on affiliate sites
US10043191B2 (en) System and method for online product promotion
US7013290B2 (en) Personalized interactive digital catalog profiling
CN101138002B (zh) 用于确定用户动作的系统和方法
US10354337B2 (en) Product content social marketplace catalog
US8473338B2 (en) Methods and systems to facilitate keyword bid arbitrage with multiple advertisement placement providers
US20090172021A1 (en) Recommendations based on actions performed on multiple remote servers
US20110055021A1 (en) Affiliate Network Hybrid Tracking System and Method
US20090171968A1 (en) Widget-assisted content personalization based on user behaviors tracked across multiple web sites
US20090171754A1 (en) Widget-assisted detection and exposure of cross-site behavioral associations
US20220092135A1 (en) Portable Universal Profile Apparatuses, Processes and Systems
US20090171755A1 (en) Behavior-based generation of site-to-site referrals
US20090319365A1 (en) System and method for assessing marketing data
EP2235858A1 (fr) Détection et exposition assistées par un gadget logiciel d&#39;associations comportementales
JP2008192144A (ja) 商品販売リンクを含むインターネット掲示文登録システム及びインターネット掲示文登録方法
US20130013429A1 (en) Systems, methods, and media for providing advertisements based upon relational data
JP5034049B2 (ja) アフィリエイト管理サーバ装置、アフィリエイト管理方法、およびアフィリエイト管理サーバプログラム
Yang Analysis of e-commerce sites using the 7C Framework, by developing a software tool
US12038994B2 (en) Integrated, information-engineered and self- improving advertising, e-commerce and online customer interactions apparatuses, processes and system
JP6909387B2 (ja) アフリエイター発信文書が表示された利用者端末において閲覧者が文書中の文字列を選択したことを契機にして広告主の商品データベース検索プロセスに誘導するアフィリエイトサービス

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070806

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

R17D Deferred search report published (corrected)

Effective date: 20080814

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 17/30 20060101AFI20081119BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120801