[go: up one dir, main page]

WO2002010962A1 - Systeme, procede et produit programme d'ordinateur pour appareil, systeme d'exploitation et messagerie multimedia interactive reseau, neutre et securisee - Google Patents

Systeme, procede et produit programme d'ordinateur pour appareil, systeme d'exploitation et messagerie multimedia interactive reseau, neutre et securisee Download PDF

Info

Publication number
WO2002010962A1
WO2002010962A1 PCT/US2001/023713 US0123713W WO0210962A1 WO 2002010962 A1 WO2002010962 A1 WO 2002010962A1 US 0123713 W US0123713 W US 0123713W WO 0210962 A1 WO0210962 A1 WO 0210962A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
client
data
content
story
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.)
Ceased
Application number
PCT/US2001/023713
Other languages
English (en)
Inventor
Daniel H. Illowsky
Michael L. Wenocur
Robert W. Baldwin
David B. Saxby
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.)
Storymail Inc
Original Assignee
Storymail 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
Priority claimed from US09/912,941 external-priority patent/US20020165912A1/en
Priority claimed from US09/912,905 external-priority patent/US20030041110A1/en
Priority claimed from US09/912,715 external-priority patent/US20030009694A1/en
Priority claimed from US09/912,936 external-priority patent/US20020194483A1/en
Priority claimed from US09/912,773 external-priority patent/US20020196935A1/en
Priority claimed from US09/912,901 external-priority patent/US20020199001A1/en
Priority claimed from US09/912,772 external-priority patent/US20020178360A1/en
Priority claimed from US09/912,885 external-priority patent/US20030023960A1/en
Priority claimed from US09/912,860 external-priority patent/US20020199096A1/en
Priority to AU8467401A priority Critical patent/AU8467401A/xx
Application filed by Storymail Inc filed Critical Storymail Inc
Publication of WO2002010962A1 publication Critical patent/WO2002010962A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • This invention pertains generally to systems and methods for providing security for communication of electronic messages, interactive sessions, software downloads, software upgrades, and other content from a source to a receiving device as well as signals used for such communications; and more particularly to systems, methods, signals, device architectures, data formats, and computer program structures for providing authentication, integrity, confidentiality, non-repudiation, replay protection, and other security properties while minimizing the network bandwidth, computational resources, and manual user interactions required to install, enable, deploy and utilize these security properties.
  • Each of these protocols requires a large amount of software code and data memory to implement and the steps needed to enroll or register to use these systems are time consuming and in other ways annoying to users.
  • a system that needed to implement all of these protocols would be very difficult to implement on a device with limited memory and computing resources, and very annoying to the users.
  • Electronic mail commonly referred to as e-mail
  • e-mail is broadly acknowledged as the "killer" application of the Internet and is a major contributor to its growth, but in a number of ways e-mail is stuck in the past.
  • Most e-mail messages particularly in a business or other commercial environment but also frequently in personal or non-commercial environments as well, have a predetermined intent, goal, or other purpose directed at achieving some particular result or response from the e-mail receiver.
  • Once a message is composed and published it is generally expected that the intent and quality of presentation of the message will be preserved.
  • e-mail was exclusively or primarily symbol or text based, maintaining the goal or intent of the message was relatively strait forward.
  • the message was well authored so as to present the desired intent and the message was received, it was likely that the receiver would having sufficient intelligence, appreciate the intent of the message.
  • e-mail may frequently include non-symbolic or non-textual information, for example, digital images or pictures, graphics, digital audio, video, and the like.
  • these non-symbolic content enhancements are provided as attachments to the basic message.
  • the intent of the message or the reason for sending the message will be partially or even entirely lost unless the non-symbolic portion, such as a video attachment, is also viewed by the receiver.
  • Whether the content enhancements are ever seen or heard by the e-mail recipient may be functions of the recipients hardware, software, programmed preferences, sophistication, as well as other tangible and intangible factors.
  • the e-mail author, sender, or forwarder may typically not know these tangible or intangible factors for any particular recipient.
  • One problem, for example, with conventional approaches used to generate and distribute e- mail is related to the fact that content in e-mail messages is typically not adjusted to the hardware capabilities of an e-mail client that will actually receive the content. If the content of the e-mail is not generated to be compatible with the hardware capabilities of a particular e-mail client, the desired intent of the message may be completely lost.
  • Such hardware and/or software capabilities include, for example, audio capabilities, motion video capabilities, microprocessor type, the amount of memory that is available to store and/or execute the e-mail content, display monitor screen size, and display monitor characteristics, which in turn depend on both the logical circuitry (provided by a video adapter) of the display monitor and display monitor screen size, and the like.
  • an e-mail publisher sends an e-mail advertisement message that consists of a color motion video of a diamond ring. If the message is received by an e-mail client that does not have required hardware for computing graphical transformations, for example, a graphics accelerator card, the recipient of the message will not be able to view the motion video portion of the message, and a necessary component of the message will have been lost, the motion video.
  • an e-mail client that does not have required hardware for computing graphical transformations, for example, a graphics accelerator card
  • client device types will be able to receive, format, and display or present each and every one of tb,e information items included in an e-mail message. Equally clearly, other client device types would be unable to present any but the minimum set of information items, and likely none of the information items unless only the minimum compatible information items was actually communicated.
  • a cellular telephone having only one or a few lines of monochrome display, a low-end Personal Data Assistant (PDA),. or the like information appliance having limited display and/or limited multimedia presentation capabilities would only be able to display small amounts of text or limited monochrome graphics. Therefore, while it would be desirable to generate and distribute optimized e-mail messages that include content that is compatible with all e-mail enabled client hardware configurations, this has not been achieved in practice.
  • PDA Personal Data Assistant
  • e-mail is not typically authored to take into account the hardware, software, and user preference attributes of the e-mail recipient. Only where a user has subscribed to some service where the content is authored specifically for a particular intended recipient or group of recipients may the content sometimes be tailored to match these attributes. For electronic messages sent to a large number of intended recipients, such as for a mass consumer advertising campaign, where no knowledge of the users' hardware, software, or preference attributes is available, conventional systems and methods do not facilitate providing an optimized e-mail communication that maintains the intent of the message.
  • the publisher in this example above for the diamond ring generated the e-mail content with a least common denominator approach that incorporated only that content that is compatible with the hardware of all e-mail clients, for example, textual content
  • the level of quality that may have been desired to show the advertisers products in a positive light would also be lost with respect to an e-mail client that does have the necessary hardware capability to view the motion video. All recipients would merely receive a text message saying for example, "Three Carat Diamond Ring, $1595.00 at Joe's Jewelry Store", rather than at least some potential buyers viewing a multi-media presentation on the ring and other attributes of Joe's Jewelry Store.
  • the extra information may take up a significant amount of limited memory resources of the receiving device, and/or, depending on the communication channel connection characteristics of the client device, may slow down the speed at which the message is received by the device.
  • the user may simply prefer not to receive advertisements or other e-mail having multi-media or rich media content.
  • e-mail messages are not typically generated such that an e-mail client's network connection characteristics are considered. As a result, the presentation of the e-mail message may be compromised.
  • network connection characteristics include, for example, nominal speed or bandwidth of network connections, latencies, throughput, and other contemporaneous communication link/channel attributes.
  • e- mail messages are typically generated in a manner that is insensitive to individual user preferences.
  • preferences include, for example, preferred language, security level, physical disability requirements, content layout, demographic information, and the like.
  • a user may be a predominantly Spanish-speaking individual who prefers to receive information, for example, text and audio, in the Spanish-language where possible, rather than in for example the English language.
  • the recipient will not be able to understand the message without additional assistance, for example, with assistance by a language interpreter. Even if the message might be understood by the recipient, it may fail to make the desired impression on the recipient.
  • the recipient also may not be able to fully understand the message without additional assistance, for example, having the message translated into a Braille or an audio format. As illustrated in both of these example, if the e-mail is generated in a manner that is insensitive to individual user preferences, the full impact and intent of the message is generally lost.
  • an e-mail client device that has received an e-mail may forward the e- mail to additional e-mail enabled devices, and they in turn may forward the message to other e-mail clients, and the like.
  • Each of these additional e-mail clients may have similar, narrower, or broader hardware capabilities, network connection characteristics, and corresponding user preferences as compared to the capabilities, characteristics and preferences of a forwarding e-mail client.
  • e- mail messages are generated in a manner such that the respective content of the e-mail is optimized and compatible with the respective hardware capabilities, connection characteristics, and user preferences associated with all e-mail clients, regardless of whether the e-mail client received the message directly from the publisher or from an intermediary by way of forwarded e-mail.
  • a recipient must perform an number of time consuming navigational and procedural steps. For example, at step 1 , the recipient must point her browser to the on-line retailer's web site on the world wide web (www). At step 2, the recipient must select the items of interest and be sure not to use a particular payment method (1 -click ), but instead place the selected items in the shopping cart. At step 3, the recipient must select a "checkout" button.
  • step 4 the recipient must wait until prompted by the retailer's web site to type in the numbers of the provided gift certificate claim code to generate an order form to complete the transaction.
  • the recipient of a targeted promotion must be connected to the internet to respond to the promotion.
  • an e-mail recipient will download e-mail from an internet connected device to a non-internet connected device for example, a handheld PDA, for later perusal at a location that may not have convenient internet access.
  • a non-internet connected device for example, a handheld PDA
  • the recipient must be connected to the internet because there are no procedures for the recipient to navigate the steps outlined in the promotion without connecting to the retailer's web site.
  • a targeted promotion would include interactive controls and content that is generated such that it is optimized and compatible with the respective hardware capabilities, connection characteristics, and user preferences associated with all e-mail clients.
  • Such interactive controls would allow a recipient of a targeted promotion to respond to it without needing to undertake time consuming navigational and procedural steps either to generate an order or to obtain additional information that relates to the promotion.
  • these labors will be moot if the targeted message is forwarded to a device that has different such capabilities, characteristics, and preferences than the device for which the original e-mail message was composed. It is also advantageous that the message be composed automatically without human intervention, and that the message ultimately received by a recipient substantially match hardware, software, and user preference attributes of each individual client device and user.
  • an author desires to compose a message, for example, with a similar intent but that is targeted to a different audience than a prior targeted message
  • the author would typically be required to generate individual messages that not only conform to the different audience, but that also conform to the such capabilities, characteristics and preferences discussed above. For example, it may frequently be desirable to alter the content of an e-mail message to take advantage of a particular cultural context or to avoid .particular language .or .stereotypes that .may .be detrimental to the intent of the message.
  • the receiver identifies themselves with the Armenian-American community it may be advantageous to frame an advertisement so that it is well received by that member of the Armenian-American community and uses for example video images showing Armenian-American's enjoying the product and Armenian music as the background.
  • the receiver when marketing the same products to an individual identifying himself or herself with the Irish-American community, it may be advantageous to show Irish-Americans enjoying the product and traditional Irish music in the background.
  • the e-mail not only be optimized for the user's normal hardware, software, communications channel and other attributes if such are known to the e-mail author, but most desirably to the actual attributes at the time the e-mail message is received by the recipient.
  • system architectures and program and data structures coupled or used together with appropriate security protocols, procedures, methods, and that provide the desired functionality in a secure manner and desirably do so in an architecture-neutral operating -system neutral, and transport layer neutral environment.
  • the invention provides numerous innovations and enhancements over conventional systems and methods, and where implemented in whole or in part as a computer program (for example, as software, firmware, a combination of software, firmware and/or hardware) also provides computer program and computer program product as well as various articles of manufacture.
  • a computer program for example, as software, firmware, a combination of software, firmware and/or hardware
  • the invention provides a system, device, method, computer program and computer program product for a hardware architecture neutral and operating system neutral and network transport neutral method for authorizing a specific user the right to access a specific resource such as an e-mail message or a promotional coupon.
  • the invention provides a system, device, method, computer program and computer program product for a hardware architecture neutral and operating system neutral and network transport neutral method for representing a digital certificate that enables at least encryption and digital signatures using substantially less storage and bandwidth than conventional digital certificates.
  • the invention provides a system, device, method, computer program and computer program product for a hardware architecture neutral and operating system neutral and network transport neutral method for implementing two or more security protocols such as 1) secure interactive sessions, 2) secure unidirectional messaging, 3) secure software downloading, 4) secure software upgrading, and 5) secure issuing of digital certificates, using a common set of data formats, algorithms, subroutines, and methods.
  • the invention provides a system, device, method, computer program and computer program product for a hardware architecture neutral and operating system neutral and network transport neutral method for secure interactive sessions using less software code and network bandwidth than conventional systems.
  • the invention provides a system, device, method, computer program and computer program product for a hardware architecture neutral and operating system neutral and network transport neutral method for secure unidirectional messaging using less software code and network bandwidth than conventional systems.
  • the invention provides a system, device, method, computer program and computer program product for a hardware architecture neutral and operating system neutral and network transport neutral method for secure certificate issuing using less software code and network bandwidth than conventional systems.
  • the invention provides a system, device, method, computer program and computer program product for a hardware architecture neutral and operating system neutral and network transport neutral method for secure response session using less software code and network bandwidth than conventional systems.
  • the invention provides a system, device, method, computer program and computer program product for a hardware architecture neutral and operating system neutral and network transport neutral method for secure unidirectional response message using less software code and network bandwidth than conventional systems.
  • the invention provides numerous innovations and enhancements over conventional systems and methods, and where implemented in whole or in part as a computer program (for example, as software, firmware, a combination or software, firmware, and/or hardware) also provides computer program and computer program product as well as various articles of manufacture. Furthermore each of the innovations provides and/or supports one or more business models and methods of during business particularly when the innovations contribute to a generated revenue stream (either directly or indirectly) and fosters relationships between consumers and/or businesses.
  • the invention provides a system, device, method, computer program, and computer program product for a hardware architecture neutral computer program language and structure and method for execution.
  • the invention further provides a system, device, method, computer program, and computer program product for autonomous generation of customized file having procedural and data elements from non-procedural flat-file descriptors.
  • the invention further provides a system, device, method, computer program, and computer program product for intelligently scaling message procedural/data sets to adapt the procedural/data sets to receiver attributes and maintain message intent.
  • the invention further provides a system, device, method, computer program, and computer program product for an intent preserving message adaptation and conversion system and method for communicating with sensory and/or physically challenged persons.
  • the invention further provides a system, device, method, computer program, and computer program product for searching and selecting data and control elements in message procedural/data sets for automatic and complete portrayal of message to maintain message intent.
  • the invention further provides a system, device, method, computer program, and computer program product for adapting content for sensory and physically challenged persons using embedded semantic elements in a procedurally based message file.
  • the invention further provides a system, device, method, computer program, and computer program product for forward and backward content based version control for automated autonomous playback on client devices having diverse hardware and software.
  • the invention further provides a system, device, method, computer program, and computer program product for reducing unauthorized access by procedural messages executing in a computer system to computer system or memory or programs or data stored therein.
  • the invention further provides a system, device, method, computer program, and computer program product for self-directed loading of an input buffer with procedural messages from a stream of sub-files containing sets of logical files.
  • the invention further provides a system, device, method, computer program, and computer program product for device-neutral procedurally-based content display layout and content playback.
  • the invention further provides a system, device, method, computer program, and computer program product for thin procedural multi-media player run-time engine having application program level cooperative multi-threading and constrained resource retry with anti-stall features.
  • the invention further provides a system, device, method, computer program, and computer program product for streaming multimedia-rich interactive experiences over a communications channel.
  • the invention further provides a system, device, method, computer program, and computer program product for cooperative application-level multi-thread execution including instruction retry feature upon identifying constrained system resource.
  • the invention provides various signals, such as signals in the form of digital bit sequences, for providing such communication either with or without security features.
  • FIG. 1 is a diagrammatic illustration showing a block diagram that illustrates aspects of an exemplary system, according to one embodiment ofthe present invention
  • FIG. 2 is a diagrammatic illustration showing block diagram that illustrates aspects of an exemplary sender/publisher of content, according to one embodiment of the present invention
  • FIG. 3 is diagrammatic illustration showing an enumerated list that illustrates aspects of an exemplary Extensible Markup Language (XML) document from a sender/publisher, according to one embodiment of the present invention
  • FIG. 4 is a diagrammatic illustration showing block diagram that illustrates aspects of an exemplary sending story server, according to one embodiment of the present invention
  • FIG. 5 is a diagrammatic illustration showing block diagram that illustrates aspects of an exemplary story enabled client, according to one embodiment of the present invention
  • FIG. 6 is a diagrammatic illustration showing block diagram that illustrates aspects of an exemplary procedure, according to one embodiment of the present invention
  • FIG. 7 is a diagrammatic illustration showing block diagram that illustrates aspects of an exemplary procedure, according to one embodiment of the present invention
  • FIG. 8 is a diagrammatic illustration showing block diagram that illustrates aspects of an exemplary Story Compiler implemented on a computer, according to one embodiment of the present invention
  • FIG. 9 is a diagrammatic illustration showing block diagram that illustrates aspects of an exemplary procedural layout of rectangles on a virtual display screen, according to one embodiment of the invention.
  • FIG. 10 shows an exemplary embodiment of a Message ID according to the invention.
  • FIG. 11 is a diagrammatic illustration illustrating steps for creating an embodiment of a message tag from a message ID.
  • inventive system system architecture, and method are now described so that the security features which jnay advantageously be used with such system, system architecture, and method will be more readily understood. It will be apparent to those workers having ordinary skill in the art in conjunction with the description provided herein, that the inventive security apparatus, data structures, instructions, codes, methods and other aspects may be utilized with StoryMailTM type features as well as with other non-StoryMail systems and methods. Exemplary system architectures and methods are therefore described first, followed by a more detailed description of other security features of the invention. Other aspects of the invention are described in the related applications which are hereby incorporated by reference.
  • storymail or StoryMail may be used to conveniently describe certain types of structures, files, or operations, it will be appreciated that structures, files, or operations that do not formally or exactly satisfy the Storymail criteria but that provide Storymail-like or would otherwise operate with the inventive element may also or alternatively be used.
  • a story as the term is used in this description generally refers to a single, author once, play everywhere file or data/command structure that is interactive either on-line or off-line and that can be used to distribute rich multimedia messages or other rich-media content to all e-mail enabled clients.
  • “stories” are described elsewhere in the detailed description.
  • e-mail is used here because it represents a form of electronic communication that is known in the art, but it will be appreciated that the inventive system, method, software, business and operating model pertain to much more than what is normally envisioned for conventional e-mail systems and methodologies.
  • inventive e-mail enhancement, extension, or replacement contemplates some generalized electronic content that is directed to one, a plurality, or a multitude of recipients.
  • a story is a single, author once, play everywhere file or data/command structure that is interactive either on-line or off-line that can be used to distribute rich multimedia messages or other rich-media content to all e-mail enabled clients.
  • stories can be used to distribute and coordinate e-commerce transactions, order fulfillment, meeting scheduling, advertisements, catalog item descriptions, customized catalogs and brochures, holiday greeting cards, electronic storybooks, driving directions, vacation slide and picture shows, surveys, real-estate walk thru, medical care pamphlets, pharmaceutical information pamphlets, recipes, business presentations, party invitations, instructional manuals, entertainment, and numerous other applications, particularly where the message consists of more than merely a text or symbolic message.
  • exemplary applications include, for example, surveys, forms, contracts.
  • Story content creation is advantageously automated and dynamically adaptive, because a story is optimized over a plurality of variables to selectively communicate elements of an e-mail message to e- mail client devices and users.
  • variables include, for example, client device hardware capabilities, network connection characteristics and user preferences. This is accomplished from a standpoint, for example, of CPU speed, display type, screen size, the existence of and or attributes of audio and/or video capabilities, data scalability, language, use of or not use of audio or visual content, nominal speed or bandwidth of all ofthe communication links and protocols, and the like.
  • a final story is not generated until substantially all such relevant e-mail client information is determined during the time of connection of the client device.
  • the system and procedure of the present invention is contrary to other prevailing trends (which attempt to pre-form content so that is available as early as possible) in that StoryMail actually delays composition of the final message until it is ready to be received. For example, if it is determined that an e-mail client cannot view motion video but can display text and play audio, the story will be generated such that it does not include motion video, laut.rather.lextual.and/or.audio elements that com unicate the intent of the e-mail publisher within the capabilities of the e-mail client.
  • a client device may be capable of receiving and rendering a very rich message
  • the then prevailing communication channel is only supporting low-speed or low- bandwidth communication
  • a story is generated such that the richness of the message is reduced so that the message is optimized for the attributes of the client device and the user preferences at that moment in time.
  • the message may be optimized or nearly optimized to be received within any time constraints that may be imposed; however, unlike systems and methods that must satisfy real-time or near real time constraints, the story need not provide real-time delivery, as it is intended to be a messaging and communication system, method, and operating model, rather than a real-time rich-media broadcast or streaming system.
  • a story is a fully aware e-mail message that is optimized to substantially deliver the intent of an e-mail publisher across the broad range of all e-mail client architectures.
  • a story may further be optimized to comply with a predefined set of user defined preferences, making each story beneficially configurable for physically challenged individuals.
  • contextual logical elements included as may be needed to insure that the intent of the message may be easily understood in text or audio only representations.
  • An example of such contextual logical element would be a text element that provides an overview of what is on the screen to be rendered as text or audio in cases where some or all of the screen's visual elements can not be seen by the recipient on the receiving device.
  • all logical elements have corresponding semantic information so that it can be known or determined which elements to use under varying circumstances.
  • the aforementioned contextual logical text element would have associated semantic flags packaged with it inside a story indicating that the element contains text providing an overview of the elements displayed on a screen for use when it is known that the recipient cannot view the screen.
  • an audio representation either recorded or generated by a text to speech engine may provide audio information backup - contextual information, or semantic information rather than text.
  • the inventive system, method, and operating model are designed to interface with a peripheral device that generates a Braille or other tactilely sensible indicia corresponding to the story.
  • This peripheral device may either be linked to a conventional client device, such as a computer, or integrated within the device. Using semantics, there is always an alternative sensory presentation mode.
  • stories are self contained and lightweight, meaning that stories have relatively small memory and processor requirements and can be played on client devices the types and sophistication of which are virtually unlimited.
  • a story is self contained because in at least one embodiment, a story is actually a single file that is made up of a number of component logical files.
  • Each component file encapsulates, for example, one or more of computer program instructions, control information, user input forms, validation procedures, and/or multimedia content.
  • Each component, logical .file is respectively compressed. and all of the component logical files are combined, packaged, compressed again to generate the single story file.
  • a story is lightweight not only because when it is executed, or played, a story's contents are selectively and sequentially decompressed. But also because a story only includes those elements that are optimized and compatible with the e-mail client's hardware capabilities and network connection characteristics, making stories lightweight (thin) enough to run on inexpensive information appliances or other devices.
  • one of the great advantages of the StoryMail system is its ability to support the hardware capabilities and network connection characteristics of virtually any client device.
  • a story can even be played on a client device that is not multimedia enabled because a story always has a set of text that describes, or narrates any non-textual element of the story.
  • the story also contains semantic flags indicating the circumstances under which to render all text or non-textual elements.
  • a story according to embodiments of the invention is reliable because it is played in a novel run-time environment, wherein, unlike an HTML Web page where there may be links to other servers to provide further information, a story is a self-contained unit.
  • the novel run-time environment is largely deterministic because of the self contained cooperative multitasking system employed in the playback engine and the explicit input buffer coding instructions with fixed size memory buffers. So if it runs correctly one time on one device it will almost certainly run correctly most of the time on all devices.
  • a run-time environment such as this is more reliable than, for example a pre-emptive multitasking system using the device's threading mechanism, or an architecture which allows for variable size buffering. Also in story messaging all content is present on the target device before the story is run.
  • a story is self contained and reliable, creation of story content can be completely automated, devices made today will be able to handle future content without upgrades.
  • This provides for intelligent content specific scaling and compression, it is easily stored and exchanged between e-mail clients as a single file, for example, that can be: embedded in a Web page, embedded in an e-mail attachment, stored in ROM, streamed from a server, run as a MIME type, run as an ActiveX component, run as a plug-in, and/or run as an ActiveX component.
  • Most story enabled devices will run or play a story in a window, or in a non-windowed operating environment such as occur on in basic or thin client devices, on a display device screen.
  • Such devices include, for example, a desktop computer, notebook computer, personal data assistant (PDAs), telephone, set-top box, movie marquee, informational kiosk, Internet e-mail appliances, billboard, microwave oven, point-of-sale displays, gasoline pump, vending machine, instructional appliance, automobile display device, global positioning system (GPS), point-of-sale display, and myriad of other device types are supported.
  • PDAs personal data assistant
  • Internet e-mail appliances billboard, microwave oven, point-of-sale displays, gasoline pump, vending machine, instructional appliance, automobile display device, global positioning system (GPS), point-of-sale display, and myriad of other device types are supported.
  • a story can even be played on a client device that is not multimedia enabled because preferred embodiments of the inventive story always have a set of text that describes, or narrates any non-textual element of the story, along with semantic information describing the role of each logical element.
  • a device may play a story entirely with voice commands and automatically articulate
  • a story maintains a focus on the intent of the message and preserves that message intent in spite of its ability to selectively communicate elements to client devices and users.
  • the primary goal has been to maintain real-time transmission of the video stream and to relax quality to the point where almost all picture quality has been lost if necessary to maintain continuous operation.
  • a high-end product such as example a diamond ring
  • inventive structure and method may be applied to on-line auctions as well and provide significant benefits here.
  • a story message provides rich product descriptions complete with
  • BID forms BID forms; bid limit exceed notifications providing a bidder a chance to upgrade a bid from a form embedded in the message without requiring the bidder to go to the action web site; and, bid accepted notification with transaction completion automation.
  • on-line auctions require composing a product description that may not scale up and down depending on the device.
  • Traditional on-line auctions typically require repeated visits the site to determine if a bid is accepted.
  • traditional on-line auctions generally require further visits to a Web site or the placement of a phone call to complete a transaction.
  • stories can be used at point of sale to provide looping demonstrations and/or advertisements of a product.
  • a story can be embedded in readonly-memory (ROM) of microwaves, stereos, set top boxes, and the like.
  • Playback of such a story can be in the store that displays the story 180 enabled product for sale.
  • the manner in which the story is played back may be modified by each viewer according to view preferences.
  • the underlying content may have English, French, Spanish, and Russian audio and text content that may be selected by the viewer.
  • Such input may be buttons on the playback device, a touch screen device, voice input, or other input devices as are known in the art.
  • story enabled devices for example, soda machines
  • media rich advertisement stories can be updated using only a phone line to upload a different story.
  • the content of such story may be communicated, for example overnight to a large variety of different device types, yet will be playable by all such device types.
  • StoryMail a story that is sent as a message from a server to a client device.
  • StoryMail System 300 is a distributed client/server system with server peering.
  • Sender/publisher 310 is connected across I/O interface 312 to user interface 314.
  • Sender/publisher 310 can be a general-purpose computer, provides at least a subset of the information and content used to generate and transmit a story to sending story server 302. In other words, parts of a story may reside on any server anywhere or computer that can be addressed, that is connected to network 306. In this case, sender/publisher 310 provides links, for example, a Uniform Reserve Locator (URL) address of the document or other resource to be included in the story.
  • URL Uniform Reserve Locator
  • Sender/publisher 310 includes a number of components which are described in greater detail below in reference to FIG. 2.
  • I/O interface 312 can be any type of I/O interface, for example, a peripheral component interconnect (PCI) bus interface, a SCSI interface, or the like.
  • Sender/publisher 310 is also connected across I/O interface 308 to network 306.
  • I/O interfaces 308 and 309 can be used if information is passed through network 306.
  • I/O interfaces 308 and 309 can be any type of I/O interface, for example, a modem connected to a public telephone network, a leased line, or a wireless radio wave or optical interface.
  • Network 306, for example, can be a local area network (LAN) or a wide area network (WAN).
  • Network 306 is connected across I/O interface 304 to sending story server 302.
  • Sending story server 302 for example.-is a general-purpose computer or device for generating and transmitting stories to client devices, such as conventional e-mail server 332, story enabled client 336, conventional e-mail client 340, and story enabled device 344.
  • client devices such as conventional e-mail server 332, story enabled client 336, conventional e-mail client 340, and story enabled device 344.
  • I/O interfaces 304, 308, 309, 324, 326, 330, 334, 338, and 342 can be any type of I/O interface, for example, a modem connected to a public telephone network, a leased line, or a wireless radio wave interface.
  • the system of the invention includes receiving story server 328, for example, is a general-purpose computer or device for transmitting stories to client devices, such as those client devices listed above.
  • receiving story server 328 is a general-purpose computer or device for transmitting stories to client devices, such as those client devices listed above.
  • One difference between receiving story server 328 and sending story server 302, for example, is that sending story server 302 is able to generate stories and distribute stories, whereas receiving story server 328 is not able to generate stories but is able to distribute already generated stories.
  • Receiving story server 328 is beneficial because it may contain functionality which can be used to eliminate the need for providing that same functionality in story enabled clients 336 and story enabled devices 344. This is advantageous because the computation and/or memory capacity of such devices is normally more limited than that of the servers 328.
  • the implementation costs are lower if the functionality is contained on the servers 328 rather than on the story enabled clients 336 and story enabled devices 344.
  • Examples of such functionality include proxy server functions, placing stories into in-boxes, and security features such as decryption, authentication and digital signature verification.
  • network 306 is connected to conventional e-mail server 332 which is a traditional e-mail server used by a number of machines connected to network 306 to distribute and collect e-mail messages. Procedures for a machine to distribute and collect e-mail messages are known in the art.
  • Conventional e-mail server 332 provides story messages to both non-story enabled devices, for example, conventional e-mail client 340, as well as story enabled clients and devices, for example, story enabled client 336 and story enabled device 344. As will be described in greater detail below, the presence of conventional e-mail server 332 is not necessary for story enabled client 336 or story enabled device 344 to receive stories.
  • a story enabled message will not include a story, but rather includes information indicating that a richer message, or story underlies the story enabled message. This embodiment is described in greater detail below in reference to FIG. 6 and FIG. 7.
  • Story enabled client 336 includes, for example, computer program applications and data for playing a story received from a story server, for example, sending story server 302 and/or receiving story server 328.
  • Story enabled client 336 is, for example, a general-purpose computer, a notebook computer, a personal digital assistant, a telephone, a set-top box, an Internet e-mail appliance, a movie marquee, an informational kiosk, a billboard, a gasoline pump, a vending machine, an instructional appliance, an automobile display device, a GPS system, a point-of-sale display, and the like.
  • Story enabled client 336 starts life as a conventional email client 340. It becomes story email client 336 when story enabling software is downloaded or installed from a network or direct connection to another device.
  • Story device 344 has the story enabling software built in by the manufacturer.
  • Conventional e-mail client 340 is a typical e-mail client, for example, a general-purpose computer that is not able to execute, or play a story.
  • conventional e-mail client 340 is able to receive e-mail messages that include information indicating that a richer content message, or story is behind the e-mail message.
  • the e-mail also includes, for example, an e-mail message that delivers the publisher's 310 message in a traditional e-mail format.
  • Such traditional e-mail formats include, for example, text, HTML and/or attachments. Such an embodiment is advantageous for a number of reasons.
  • conventional e-mail client 340 will not be able to play a story without upgrading its computer program applications, it will still receive content that corresponds to publisher's 310 message or promotion. Additionally, the message can be forwarded to another e-mail client device, for example, story enabled client 336, wherein the richer message will be available to the other client device.
  • conventional e-mail client 340 upgrades its capabilities to enable it to play a story. In a situation where conventional e-mail client 340 upgrades its computer program applications to enable it to play a story, conventional e-mail client 340 would become a story enabled client 336.
  • conventional e-mail client 340 can perform such upgrades, for example, by downloading a story player from a web site or an FTP site, or by loading a story player from a CD-ROM or diskette.
  • conventional email client 340 upgrades by responding to a link provided in the email message, wherein the link points to a download image or site.
  • Story enabled device 344 is manufactured with story functionality built in. Such devices include networked household appliances, cell phones, smart cards, and pagers.
  • Each client device 336, 340, and 344 includes, for example, an e-mail program (not shown) that respectively receives and/or delivers e-mail respectively from/to one machine connected to network 306 from/to another machine connected to network 306.
  • an email program utilizes Internet email protocols, for example, known POP3 or IMAP protocols.
  • such an e-mail program is a conventional e-mail program, such as Microsoft Outlook Express®.
  • the e-mail program is a special e-mail program designed specifically to receive and/or transmit stories to another client or device across network 306.
  • Sender/publisher 310 includes processor 142 connected across local bus 144 to memory 146.
  • Processor 142 is used to execute computer program applications 148 and fetch data 150 from memory 146.
  • Local bus 144 can be any type of bus, for example a peripheral component interconnect (PCI) bus, as long as local bus 144 has a set of signal lines that can be used by processor 142 to transfer information respectively to and from memory 146.
  • PCI peripheral component interconnect
  • Data 150 includes, for example, database 152 representing any combinations of textual information, motion video, audio, forms, automation scripts, a story recipient list and any other message content, communication, or the like, that may be sent in an electronic format.
  • a form can be any type of form or document, for example, a purchase order form, a registration or an application form. Typically a form provides an inquiry and provides some instructions for answering of responding to the inquiry.
  • Database 152 is a standard database that can be created and managed using any of a number of conventional database tools.
  • database 152 includes, for example, textual descriptions in more than one language of a number of products, digital or binary images of the products, motion videos to advertise and illustrate the products, product identification numbers, audio clips to advertise and describe the products, and/or recipient information, such as a list of e-mail addresses to which to send a story.
  • a textual description of that item of data is available. For example, if database 152 includes a color photo of a particular toy, there will be a corresponding text description of that toy.
  • a digital or binary image can have a set of scaled and color depth versions of the binary image.
  • database 152 includes a 300 dots per inch (dpi) 24-bit color binary image of the cover of a book
  • database 152 will also include a 1 -bit black and white representation of the image, an 8-bit and 16-bit gray scale representation of the image, and various resolutions of each of the resolutions, such as 100 bit and 200 bit resolutions.
  • scaling of logical story elements can occur at three different times: (1) when generating the message; (2) when executing the procedural elements of the message; and, (3) while the message elements are being rendered by the hardware specific functions (e.g., the HAL functions) that connect a portable story playback engine to actual device specific hardware.
  • sending story server (see FIG. 1) scales the story content when generating the message to conform to the story enabled clients' 336 hardware capabilities, network connection characteristics, and specified user preferences at the time that such information are determined (see FIG. 7, step 228).
  • story player 194 (see FIG. 5) scales the content of the story when the procedural elements of the story are executed, or played.
  • a digital image may be scaled from 300 dpi to 200 dpi while the digital image is being displayed.
  • .story playerls 1.94. HAL ma -scale the story to fit into a particular display screen size and/or add scroll bars to the display so that an entire story can be viewed.
  • Document 154 is author once information created by using a number of structured document languages, for example, extensible markup language (XML), and Excel spreadsheet format, database records extracted with SQL, and the like.
  • Document 154 is an XML document.
  • Document 154 can be created in a number of different ways. For example, Document 154 can be created using any of a number of known XML Editors, Word processors, device drivers, and the like.
  • FIG. 3 there is a block diagram that illustrates aspects of an exemplary Document 154 used by sending story server 302 (see FIG. 1) to generate a message/promotional story 180, according to one embodiment of the invention.
  • FIG. 3 uses a structured document syntax pseudocode that does not conform to any one particular structured document syntax, but is rather used only for purposes of illustrating the invention.
  • XML document 154 includes a tag that identifies a particular storyteller 172 (see FIG. 4) and a unique identifying attribute of the particular storyteller 172.
  • the property can be either an absolute description string, an embedded document, or a string that includes a URL and a document name. If a descriptive property is a URL and document name, the URL will be accessed and the identified document downloaded when document 154 is parsed by story server 302 (see FIG. 4) during one time processing of document 154, as described in greater detail below in reference to FIG. 4.
  • Line 400 includes a tag that identifies a "STORYTELLER ID” element, which is followed by an attribute ofthe element, "ecoupon 5".
  • "Ecoupon 5" identifies a unique storyteller 172 (see FIG. 4) in story server 302 (see FIG. 1).
  • ecoupon 5 storyteller 172 will be used to generate a form and a user interface to be used by a sender/publisher 310 (see FIG. 1) to generate and distribute one or more ecoupon stories 180 (see FIG. 4) to distribute to one or more customers as dictated by sender/publisher 310 (see FIG. 1).
  • Storytellers 172 are described in greater detail below in reference to FIG. 4.
  • Line 402 includes a tag that identifies a "PRODUCT VIDEO" element, which is followed by an attribute of the element that identifies a particular MPEG motion video,
  • the motion video is identified by a URL link to the author's database 152 (see FIG. 4).
  • Lines 404 and 406 include tags that identify respective product picture elements, wherein each respective tag identifies a specific binary image (or other digital image or graphic) that has a respective different pixel resolution.
  • line 404 includes a tag that identifies a "PRODUCT PICTURE 100DPI" element, which is followed by an attribute of the element that identifies a 100 dpi binary image, such as the JPEG image "BOOKRETAILER.COM ⁇ PROMO24 ⁇ ISBNL2980 100DPI.JPG".
  • line 404 includes a tag that identifies a "PRODUCT PICTURE 100DPI" element, which is followed by an attribute of the element that identifies a 100 dpi binary image, such as the JPEG image "BOOKRETAILER.COM ⁇ PROMO24 ⁇ ISBNL2980 100DPI.JPG".
  • Lines 408 and 410 include tags that identify respective audio file elements, wherein each respective tag identifies a specific audio file .that.is implemented in.a different language.
  • line 408 includes a tag that identifies a "PRODUCT AUDIO ENGLISH” element, which is followed by an attribute of the element that identifies an audio file that is implemented in English (“BOOKRETAILER.COM ⁇ PROMO24 ⁇ ISBNL2980 ENG.WAV").
  • line 410 includes a tag that identifies a "PRODUCT AUDIO SPANISH” element, which is followed by an attribute of the element that identifies an audio file that is implemented in Spanish (“BOOKRETAILER.COM ⁇ PROMO24 ⁇ ISBNL2980 SPAN.WAV"). Both audio files are identified by respective URL links to the author's database 152 (see FIG. 2) and a corresponding WAV document.
  • Lines 412 through 418 include tags that identify respective text file elements, wherein each respective tag identifies a specific text file with analogous intent written in a different language.
  • line 412 includes a tag that identifies a "PRODUCT TEXT ENGLISH" element, which is followed by an attribute of the element that identifies an ASCII text file that is implemented in English ("BOOKRETAILER.COM ⁇ PROMO24 ⁇ ISBNL2980 ENG.TXT").
  • line 414 includes a tag that identifies a "PRODUCT TEXT MANDARIN” element, which is followed by an attribute of the element that identifies a Unicode text file that is written in Mandarin ("BOOKRETAILER.COM ⁇ PROMO24 ⁇ ISBNL2980 MANDARIN.UNI") and the like. Each text file of these examples is identified by respective URL links to the authors database 152 and a corresponding text or Unicode document.
  • Line 420 includes a tag that identifies a respective "PRODUCT SKU” (stocking unit) number element, which is followed by an attribute of the element, in particular an absolute value that identifies the promotion's targeted product's SKU.
  • Line 422 includes a tag that identifies a respective "FULFILLMENT SERVER URL" element, which is followed by an attribute of the element, in particular a URL for the promotion's fulfillment server.
  • a procedure for using such a fulfillment server is described in greater detail below in reference to FIG. 7.
  • Lines 424 - 428 includes tags that identify story 180 (see FIG. 4) recipient or customer information.
  • Line 424 includes a tag that identifies a "FIRST NAME” element, which is followed by an attribute of the element, in particular, the name "DAVE”.
  • Line 426 includes a tag that identifies an "EMAIL ADDRESS” element, which is followed by an attribute of the element, in particular an e-mail address, such as for example to "someone @ somewhere . com” that identifies the recipient's e-mail address, and the like.
  • Line 430 includes a tag that identifies a respective "MASTERDATABASE ID" that is used by sending story server 302 (see FIG. 1) to identify those portions of a master parts database to use for a particular message/promotion.
  • sending story server 302 returns the message/promotion ID 430 to sender/publisher 310 (see FIG. 1), such that the message/promotion ID 430 is unique to any other message/promotion IDs in a master parts database.
  • Such a message/promotion ID can be used by publisher 310 to modify and/or delete the information that corresponds to a message/promotion in a corresponding master parts database.
  • Such a master parts database is described in greater detail below in reference to FIG. 4.
  • such a message/promotion ID is used by publisher 310 to send a corresponding message/promotion to recipients in batches, each batch job referencing the message/promotion ID.
  • document 154 can include any number of user defined elements and respective attributes of such defined elements.
  • recipient information for example, that information illustrated in lines 424-428, .can be supplied to sending story server 302 (see FIG. 1 and FIG.4) at any time through a number of different mechanisms.
  • a textual description of that non-textual data is identified in Document 154.
  • there is a corresponding text description identified in more than one language for example, English and Spanish text descriptions.
  • Document 154 identifies an audio file in a particular language
  • Document 154 also identifies other audio files that have analogous content to the audio file in different languages. It may also provide a textual transcription and/or a summary of the audio files for presentation when the receiving device does not provide audio playback or the recipient chooses not to receive the content in an audio format.
  • document 154 if document 154 includes a binary image (either embedded or via a URL) having a particular resolution, document 154 also includes other resolutions of the binary image. Including such multiple resolutions of a binary image is beneficial for the reasons discussed in greater detail above. Furthermore, not only may the binary or digital images be different resolution, they may be different types of files, such as for example, a bit-mapped image (*.bmp), a TIFF format image (*.tif), a JPEG compressed image (*.jpg), or the like.
  • Applications 148 includes, for example, one or more of the following computer program applications: (a) a Web browser (not shown) such as Netscape Navigator® or Microsoft Internet Explorer®, for accessing a Web page served from sending story server 302; (b) any of a number of commercially available XML Editors for creating document 154.
  • Other applications may also be stored or provided, for example, multimedia authoring systems, story mail applications, templates for other applications such as spreadsheets, multimedia and/or XML database managers.
  • Sender/publisher 310 also includes, for example, a database stored or referenced which includes at least a subset of the content necessary to represent the information and data in a story.
  • Server 302 includes processor 162 connected across local bus 164 to memory 166.
  • Processor 162 is used to execute computer program applications 168 and fetch information from data 170.
  • Local bus 164 can be any type of bus, for example, a peripheral component interconnect (PCI) bus, as long as local bus 164 has a set of signal lines that can be used by processor 162 to transfer information respectfully to and from memory 166.
  • PCI peripheral component interconnect
  • each server 302 and 328 will respectively communicate directly with another respective server 302 and 328, or with one or more conventional e-mail servers 332 (see FIG. 1) using one or more communication protocols, for example, SMTP/ESMTP/MIME/HTTP communication protocols.
  • SMTP/ESMTP/MIME/HTTP communication protocols for example, SMTP/ESMTP/MIME/HTTP communication protocols.
  • Sending story server 302 using information that is provided both by sender 302 and story enabled client 336, generates and distributes stories 180 as e-mail, or StoryMail.
  • Such information can be provided to sending story server 302 through a number of different mechanisms. For example, the information may be provided if sender/publisher 310 (see FIG. 1) sends document 154 across I/O interface 308 to server 302. (The contents of document 154 are described in greater detail above).
  • sending story server 302 also serves one or more documents on the World Wide Web (WWW) identified by a unique Uniform Resource Locator (URL) that allows a user of sender 302 to input information through network 306 into server 302 that will be translated into document
  • WWW World Wide Web
  • URL Uniform Resource Locator
  • Applications 168 includes, for example, composition engine 170, storyteller 172, e-mail engine
  • composition engine 170 provides, for example, a framework of data structures, a run-time model, a compiler, an application programming interface (API), and conventions for building an almost endless variety of different stories 180 that conform to a story run-time model.
  • the story run-time model is designed such that a story playback engine on a story client can be simple in complexity and fast.
  • the run time model provides a lightweight cooperative multitasking multimedia and central application framework. (Such a run-time model described in greater detail below).
  • Composition engine 170 passes information provided by sender/publisher 310 (see FIG. 1), such that the information is represented in a procedural data format that is not a flat data format.
  • the technologies are designed for the procedural content to be fully computer-generated, that is, without manual user intervention. (Manual building is possible but it is not preferred or even desirable.)
  • industry standard XML interfaces are used to completely automate one time processing of such provided information, such that existing authoring tools and content formats, for example, JPEG, AVI, MPEG, MP3, and the like, are supported through a simple yet powerful transcoding mechanism of the invention.
  • composition engine 170 performs one-time processing of the provided information such that the resulting procedural format of the information for example, is a sequenced set of data, for example, computer program instructions or operation codes (op codes), control information, parameters and media parts.
  • sequenced set means that the data is organized into a time line that dictates the rendering and navigational characteristics of a story 180. This time line may include procedural tests, branches, jumps, conditional statements, and the like so that the rendering may not ultimately be perfectly linear or sequential.
  • such a sequenced set of data may include a first set of computer program instructions to display a graphic.
  • the first set of computer program instructions is followed, for example, data used by a story player to display navigational buttons on the story receiving devices display.
  • each media part is assigned an absolute priority that controls when and if a particular media part will be rendered.
  • the computer program instructions specify operations to render graphical user interface (GUI) components, media parts, and provide procedural control to user interaction with the GUI components.
  • GUI graphical user interface
  • the control information for example, provides offsets into the sequenced set of data that indicate where particular media parts are located.
  • control information also provides a set of semantics and flags for each logical element of a story to maintain the intent of the message on all receiving devices.
  • control information includes an array of hot spots, one hot spot for every logical element.
  • logical elements include, for example, button controls, text input controls, bitmaps, areas wherein motion video will be displayed, text boxes, decorative elements, and the like.
  • Each hot spot is associated with a rectangular region of the receiving devices' screen display .(if one is available).
  • the .rectangular region facilitates event identification.
  • event identification is associated with user instantiated events. For example, if a user selects, for example, with a mouse device, a region identified by the rectangle associated with a particular hotspot, the operating system will generate a button click event which, as will be described in greater detail below is processed by a story player in the context of the logical element selected.
  • Each hot spot is further identified as being either active or inactive.
  • An active hotspot is a hotspot that generates an event when a user selects a region within the rectangular area associated with the hotspot.
  • an inactive hotspot does not generate an event when a user selects a region within the rectangular area.
  • each hotspot area is implemented as a bitmap.
  • the hotspot array may also contain semantic and alternative rendering element identifiers (ids) for logical elements other than areas.
  • ids semantic and alternative rendering element identifiers
  • a hotspot's semantic flags may indicate that there is overview test available that describes the overall purpose of a screen of information, and the hotspot may also contain the id of the overview text element of the story.
  • control and control information include memory buffer creation, memory buffer loading, branching, condition or searching, layout, subroutines, linkage between different sequences of instructions, decompression and compression and file packaging, e-mail access for sending messages, requests for subfiles.
  • each opcode, parameter and offset is a 32-bit word. This is beneficial for a number of reasons. For example, portability and adaptability are supported by the use of fixed size 32- bit words.
  • a 32-bit fixed size word is advantageously used for representing a large dynamic range of value and is highly compressible because both instructions and parameters are designed to have mostly small integer values.
  • the fixed size makes things very scalable and processor words are always aligned along the word boundary.
  • the playback code, or the story 180 is also small and reusable.
  • Parameters and opcodes can be processed by the same code and operation, for example, addition operations can be performed without the need for size conversion of the code.
  • An additional advantage is that the opcodes and data are aligned in memory for fast access. Aspects of an exemplary procedure to use such a procedural data layout to play story 180 are described in greater detail below in reference to FIG. 5 and FIG. 6.
  • Such one-time processed information is stored by composition engine 170 as a set of master parts data into master parts database 178.
  • each set of master parts data is identified by a unique identifier that can later be used by sender/publisher 310 to access, modify, and delete the contents of a particular set of master parts data, in master parts database 178.
  • the set of master parts data can be used by sender/publisher 310 (see FIG. 1 and FIG. 2) to generate and distribute any number of stories 180 to targeted e-mail enabled clients.
  • composition engine 170 is eminently portable, meaning that it may also be embedded in other devices besides sending story server 302.
  • composition engine 170 may be embedded, for example, into a digital camera.
  • a single global data structure allows the implementation of composition engine 170 code as a set of C++ objects, composition engine 1 0 code is reusable and can be instantiated more than one time.
  • An additional advantage of this is that applications including composition engine 170 will be easy to build.
  • sizes of all program variables are explicitly defined and there is built-in support for little-endian and big-endian systems.
  • a thin hardware extraction layer (HAL) and the ability for all text to be represented in ASCII or Unicode also supports portability. In combination, all of these aspects make a story quickly and easily portable to a broad range of devices, able to handle nearly all the computer programming instruction sets or languages.
  • Story teller 172 includes, for example, a set of programmed logic that will select at least a subset of a particular set of master parts data in master parts database 178 to build story 180. Because composition engine 170 represents the provided information in a procedural format, a story 180 is just one big procedural language/data/environment. In a preferred embodiment, a story 180 is part of the same procedural language including the content, decompression, rendering, layout, hotspot responses and navigation. In some aspects, a story 180 may be viewed as a self-contained ultra-low overhead multi-threaded run-time system. For example, a story 180 generates video frames by executing sequences of instructions. This allows for mixing of different video decompression/reconstruction algorithms within a single frame. For example, a motion compensation vector equivalent for a whole frame can be applied using a single instruction which moves rectangular parts of one picture into another.
  • storyteller 172 builds a story 180 from the master parts database 178 in response to a message from StoryMail enabled client 336 (see FIGS. 1 and 4).
  • a message is described in greater detail below in reference to FIGS. 5 and 6).
  • the message will include a unique identifier, such as the unique identifier discussed above, to determine which set of master parts data to use to build a story.
  • the particular master parts that a storyteller 172 will select to piece together story 180 together depends on the purpose of storyteller 172 and the particular hardware capabilities, network connection characteristics, and user preferences associated with a targeted story enabled client 336 (see FIG. 1 and FIG. 4).
  • Aspects of an exemplary procedure to send server 302 such capabilities, characteristics, and preferences are described in greater detail below in reference to FIG. 5 and FIG. 6.
  • storyteller 172 can include any one of the exemplary applications of a story 180 that were discussed in greater detail above or other purposes.
  • sending story server
  • a first storyteller 172-1 may be used to build an e-coupon story 180
  • a second storyteller 172-2 may be used to build a parts catalog story 180, and the like.
  • sending story server 302 will serve a Web page interface (not shown) whereby publisher/sender 310 creates and modifies storytellers 172.
  • a Web interface provides a set of button controls that when selected by a user allows the user to: (1) add logical story elements, for example, an MPEG file, to master parts database 178; (2) select portions of such logical story elements, for example, a user selects a particular picture and a particular video to include in a story 180; (3) specify the dimensions of portions of the story, for example, a user may specify that the dimensions of a particular sequence of logical story elements are to be of a particular width and height; (4) order the logical story elements on a time line, and take into consideration any user navigation; and, (5) define a set of templates, wherein a particular template specifies, for example, the particular operating parameters and rules used to scale the logical story elements to optimally play on a particular story enabled client 336 (see FIG.
  • E-mail engine 173 is used to both send and receive e-mail respectively to/from sender/publisher 31.0, tory .enabled .client.336. and conventional .e-mail client-340.
  • Conventional e-mail engines are known in the art of internet e-mail messaging. Aspects of such e-mail messages are discussed in greater detail below in reference to FIG. 5 and FIG. 6.
  • FIG. 5 there is a block diagram that illustrates aspects of an exemplary story enabled client 336 (client 336), according to one embodiment of the present invention.
  • Client 336 receives and plays stories 180.
  • Client 336 can also forward story 180 to other e-mail enabled clients, for example, another story enabled client 336 and/or conventional e-mail client 340 (see FIG. 1).
  • client 336 includes processor 184 connected across local bus 186 to memory 188.
  • Processor 184 is used to execute computer program applications 190 and fetch data 198 from memory 188.
  • Local bus 186 can be any type of bus, for example, a peripheral component interconnect
  • PCI peripheral component interconnect
  • Data 198 includes, for example, e-mail message 200, which is sent to story enabled client 336 by sending story server 302 (see FIG. 1). Aspects of an exemplary procedure for sending story enabled client 336 e-mail message 200 are described in greater detail below in reference to FIG. 5 and FIG. 6.
  • e-mail message 200 includes, for example, novel story e-mail, which indicates to story enabled client 336 that a richer content story 180 is behind e-mail message 200.
  • Story enabled client 336 receives a mail message 200 before it receives story 180.
  • story 180 is only received by story enabled client 336 after story enabled client 336 collects its e-mail from an e-mail server, for example, conventional e-mail server 332 (see FIG. 1).
  • story header 201 includes, for example, story teller ID 202, data set ID
  • Story teller ID 202 identifies a particular story teller 172 (see FIG. 4) used by sending story server 302 (see FIG. 1) to build story 180. Aspects of exemplary procedure for sending story server 302 to build story 180 are described in greater detail above in reference to FIG. 2, FIG. 5 and
  • Data set ID 204 is used to identify a data set that corresponds to at least a subset of the information in master parts database 178 (see FIG. 4) that will be used by sending story server 302 to generate story 180.
  • URL 206 identifies the URL of the particular sending story server 302 that sent client 336 e-mail message 200. Although a conventional mandatory return path e-mail header (not shown) may also identify the particular story server 302, the URL information is beneficial because story messages may come from different servers belonging to different service providers or sender/publishers 310 (see FIG. 1).
  • story enabled client 336 may be forwarded by story enabled client 336 to another device
  • story enabled client 336 does not forward story 180 to another device, but rather e-mail message 200 is forwarded to another device.
  • Such other devices include, for example, another story enabled client 336, a conventional e-mail client 340, and/or a story enabled device 344.
  • a targeted device receives the forwarded e-mail message 200
  • any corresponding collection request by the targeted device associated. with e-mail message 200 is redirected to sending story server 302, such that sending story server 302 determines whether the target device is story enabled or not.
  • sending story server 302 determines, for example, the particular hardware characteristics, network connection characteristics, and any user preferences associated with the targeted device before sending .story .1.80 to .the ..targeted device. Aspects of an exemplary procedure to make such a determination are described in greater detail below in reference to FIG. 5 and FIG. 6. This level of indirection ensures that an optimized story 180 will be forwarded to story enabled clients 336 and story enabled devices 344. This level of indirection also ensures that if the targeted device is not story enabled, that the targeted device, although not receiving story 180, receives conventional content associated with the mail message 200 along with the novel story header 201 information.
  • E-mail message 203 includes, for example, story 180.
  • e-mail message 203 is received by story enabled client 336 after sending story server 302 has determined story enabled client's 336 particular hardware characteristics and any user preferences.
  • story 180 is scaled to story enabled client's 336 particular hardware characteristics, network connection characteristics, and user preferences.
  • Applications 190 includes, for example, information provider 192, story player 194, and other applications 196.
  • Information provider 192 sends story enabled client's 336 hardware capabilities, network connection characteristics and any user preferences to sending story server 302 (see FIG. 4). Such capabilities and characteristics (discussed in greater detail above) are typically obtained by querying operating system software (not shown) that controls the execution of computer programs and provides such services as hardware management, computer resource allocation, input/output control, and file management in story enabled client 336.
  • Information provider 192 determines any user preferences in a number of ways.
  • information provider 192 displays a GUI onto a display device (not shown) connected to story enabled client 336.
  • the GUI will have one or more user interface controls, for example, a dialog box, an edit control, and/or a combination box, to the end-user for end-user selection and input with respect to a predefined number of preference categories.
  • categories include, for example, a preferred language, message size limits, message download time limits, message filters (for example, no e-coupons), data encryption requirements, and security requirements. (Either limits may be greater or less than a default set of time limits). In one embodiment, if there are a number of preferences, certain preferences will be given a higher priority than other preferences.
  • such preferences are stored in data 198 as a text file (not shown) in a structured file format, for example, XML, that can be edited by a user with using a text editor.
  • Story player 194 executes, or plays story 180.
  • story 180 includes one or more of op codes, parameters, offsets and media parts.
  • player 194 sequentially parses story 180 to extract these op codes, control information (parameters and offsets), and media parts. As each op code is extracted, player 194 will match the op code to a particular computer program instruction, or procedure, which is a logical set of computer program instructions.
  • Story player 194 will jump to a procedure that corresponds to the opcode and begin a set of corresponding computer program instructions.
  • such computer program instructions are C instructions. If the computer program .instruction requires .corresponding parameters, the required parameters are extracted on an as needed basis from story 180. In one embodiment, parameters can signal the parsing of other parameters from the stack. There are a number of well known ways that a specific number and specific type of parameter can be mapped to a computer program instruction. For example, the number and types of parameters can be hard wired in the implementation of a computer program instruction. If a parameter is an offset to a media part of story 180, the offset is used when playing story 180 to extract the data for the particular media part when necessary.
  • Story player 194 advantageously implements cooperative multithreading and synchronization through resource constrained retry at the instruction level. To provide such advantages, each procedure in story 180 returns one of a number of possible status codes, for example, success, retry, and yield status codes. In one embodiment, story player 194 executes sequences of instructions for a thread as long as the instruction functions return a status code of "success". Upon receiving a status code of success, a next thread is executed by story player 194 under similar constraints.
  • Any instruction that takes a predetermined amount of time to complete will return a "yield” status code, indicating to story player 194 that other threads should be executed.
  • story player 194 stops executing the thread and places it onto a queue for later execution.
  • Such yield status codes are inserted at appropriate places in story 180 by story teller 172 when story teller 172 creates story 180.
  • Certain story 180 instructions are executed on a time line as described in greater detail above in reference to FIG. 4. Such instructions are so tagged with a "wait until time” instruction by storyteller 172 (see FIG. 4) before being placed into a master parts database 178. Story player 194 will wait until the indicated time to execute such instructions.
  • story player 194 If story player 194 encounters such an instruction and it is not time to execute the instruction, story player 194 will retry the instruction at another time. Any instruction encountered by story player 194 that requires a memory buffer, wherein the memory buffer is not available, is placed on a queue such that story player 194 will retry the instruction at a later time wherein such memory resources may be available. In one embodiment, story player 194 identifies "wait for event" flags to synchronize story 180 instructions.
  • story player 194 presents a purchase button to a user that is used to provide a response to the story 180.
  • the HAL identifies a user selection in the rectangular area defined by a particular hotspot associated with the button. (Hot spots are described in greater detail above in reference to FIG. 4).
  • story player 194 executes a story procedure or story thread associated with the selection.
  • Other applications 196 include, for example, an optional e-mail client application, for example,
  • Microsoft Outlook Express® that provides e-mail receipt and delivery capabilities to story enabled client
  • Internet e-mail protocols include, for example, POP3 and IMAP protocols.
  • e-mail receipt and delivery capabilities are provided by story player 194.
  • FIG. 6 there is a block diagram that illustrates aspects of an exemplary procedure
  • StoryMail enabled client 336 see FIGS. 1 and FIG. 5
  • conventional e-mail client 340 see FIG. 4
  • FIG. 1 To better describe procedure 210, the following description references structure that are respectively illustrated in FIG. 1, FIG. 2, FIG. 3, and FIG. 4.
  • Step 212 provides, for example, multimedia content and/or message parameters to story server 302 (see FIG. 4).
  • message parameters correspond to the multimedia content.
  • a message parameter is a discount rate.
  • multimedia content includes, for example, product descriptions, promotional information, customer specific information and/or pictures to the story server 302 (see FIG.
  • sender/publisher 310 sends such content in Document 154 (see FIG. 2).
  • sender/publisher 310 accesses a URL that corresponds to a Web page (not shown) served by sending story server 302, whereby a user could input such content to sending story server 302.
  • Such content is described in greater detail above in referent to FIG. 2.
  • such content also includes, for example, the identity of a specific storyteller 172 to be used to generate a story 180 (see FIGS. 3 and 4).
  • sender/publisher 310 is an Internet book, music and video retailer that offers music CDs, video, DVD, computer games and other products
  • the specific storyteller 172 may be used to build a parts catalog story 180 to be distributed to retailers, or the specific storyteller 172 may be selected to generate a holiday card story 180 to be distributed to customers.
  • Step 218 performs one time processing of the content as described in greater detail above in reference to composition engine 170 as illustrated in FIG. 4.
  • Step 220 returns a unique master parts identification to sender/publisher 310.
  • an identification is used to identify the particular set of master parts data that corresponds to the one time processed content. This identification can be used by sender/publisher 310 to access, modify and delete the one time processed information from sending story server 302, as well as to send new messages using the same master information as default content.
  • Step 220 sends e-mail message 200 (see FIG. 5) to each recipient that is identified in the provided content (step 212).
  • e-mail message 200 is an e-mail message that includes story header 201.
  • a recipient can ' be either a story enabled client 336 (see FIG. 1), a conventional e-mail client 340, or a story enabled device 344.
  • Step 222 intercepts an e-mail collection request from the e-mail message 200 receiver. Step
  • step 226 evaluates whether the e.-mail message 200 receiver is story enabled, for example, a story enabled client 336. If not, step 226 sends the contents of e-mail message 200 to the non-story enabled device, for example, conventional e-mail client 340 (see FIG. 1). Otherwise, procedure 210 continues as illustrated in FIG. 7.
  • Step 228 gets story enabled client 336 information.
  • such information includes corresponding hardware capabilities, network connection characteristics, and any user preferences.
  • capabilities, characteristics and preferences are represented by story enabled client 336 in a structured file format, for example, as an XML document.
  • quick communication protocols are used between story servers 302 and 328 and story enabled client 336 respectively for intra-server and server client communications, for example,
  • story enabled client 336 could represent its particular capabilities characteristics and preferences in a structured file format as follows.
  • CPUSpeed 300 indicates that in the client 336 CPU speed is equal to 300 MHz.
  • CPU or processor speed criteria may be used to influence the generation of an optimized story in that the CPU may not be fast enough to process large video clips in real time.
  • a video clip with small dimensions (width and height) might be used instead.
  • a signal picture may repress the video content instead of a video stream.
  • Sound yes” indicates that the client 336 includes a sound card, chip, or other sound or audio regeneration or playback means and that the data element that includes audio can be used to create a story 180.
  • such capabilities, characteristics and preferences are sent to the URL of sending story server 302, which was included in the story header 201
  • Step 230 generates the story 180 (see FIG. 4 and FIG. 5) using a particular storyteller 172 identified by story teller ID 202 (see FIG. 5) in e-mail message 200.
  • the specific storyteller 172 selects, or strings together only those portions of the set of master parts (identified by the date set ID 204, see step 219) in the master parts database 178 (see FIG. 4) that are compatible with each of the following: the capabilities, characteristics and preferences identified in step 228; and, the content which is compatible with the purpose of the specific storyteller. While stringing together such information, the specific storyteller 172 may create several original logical files, compress them, and compress each of the compressed logical files into a final single file.
  • the logical order of the data in the each respective original single file is maintained in the headers of a sequence of sub-files that are automatically generated from each respective original logical file.
  • Such a logical order is advantageously used by sending story server 302 (see FIG. 1) when transferring a story 180 to a story enabled client 336 (see also, step 232).
  • the opcodes representing computer program instructions and parameters may be placed in a first logical file, text and parameters in a second logical file, all motion video may be placed in a third logical file, all audio data may be placed in a fourth logical file, and the like.
  • the computer program, control information, audio data, motion video, and the like may be interspersed.
  • the elements which are best compressed using the same compression algorithms are combined together so as to achieve a more optimal compression level.
  • system 300 cooperates in collecting all relevant information and data first, such as for example, the capabilities, characteristics, and preferences described above, before generating a story 180 (step 230). This makes system 300, and in particular story 180 generation advantageously automated and dynamically adaptive. Having obtained all this information, system 300 then generates the optimum story 180 after a connection has been made with recipient. This is because only at the time of connection will story server 302 know for certain the particular characteristics of the recipient's client device, communication channel, and user preferences. In some conventional systems, a user may register with a server characteristics of a registered device as well as registered user preferences. However, these conventional systems do not generally test or otherwise take into account the hardware capabilities of the device or network connection characteristics used by the device to communicate with the server at that moment of time.
  • the StoryMail system 300 (see FIG. 1) and procedure 210, on the other hand, take all such factors into account after connecting to a recipient's device to generate the optimal story 180 from a standpoint of story size, language, use or not use of audio or visual content, and the like.
  • the StoryMail procedure 210 is contrary to other prevailing trends which attempts to pre-form content so that is available as early as possible in that StoryMail 300 actually delays composition of an e-mail message until these capabilities, characteristics and preferences are known. In this manner, a story 180 sent to any device will be experienced in a manner that is optimal for that device and user.
  • Step 232 communicates a second StoryMail message 200 to story enabled client 336.
  • the second e-mail message 203 includes that generated story (step 230) and the corresponding story header 201 (see FIG. 5).
  • storyteller 172 encrypts generated story 180 (step 230) so that it cannot be read by any intervening process after it is sent to story enabled client 336 and before it reaches its destination.
  • public key encryption there is no need to have a central repository of public keys because the public keys of the center and receiver client can be exchanged after connection time when the story 180 is being generated (step 230).
  • each logical sub-file of story 180 includes, for example, a startup sequence of instructions that can be used to start the transfer of the following sub-files in the sequence.
  • Such segmentation of the files is beneficial for a number of reasons. For example, while transferring a story 180 to a story enabled client 336 (see FIG. 1), if the bandwidth is too small, a sub-file will not arrive in time. In one embodiment, story player 194 (see FIG. 5) pauses until each respective sub-file transfer is complete. In this manner, quality of story 180 presentation will be constant, even if receipt of story 180 content is intermittent. In yet another embodiment of the invention, real-time transmission of story 180 is not required so that the recipient may never be aware that transmission was delayed, suspended, or intermittent for a particular portion of story 180.
  • Step 234 executes, or plays the story. Aspects of an exemplary procedure to play a story 180 are described in greater detail above in reference to FIG. 4.
  • a custom story 180 is generated for each receiving device, such that a story 180 can be generated to play on all types of story enabled devices and compatibility is maintained for all stories 180 even as story enabled devices may change or evolve.
  • Even the rich media stories 180 will play on non-rich media enabled devices because, in preferred embodiments of the invention, there is always some text or other simplified content behind more complex elements such as sound or video clips to fall back on. This is because the master parts database 178 (see FIG. 4) includes information to create new stories that will play on all story players because there will always be the old instruction alternative to fall back on.
  • even rich media stories are able to playback on conventional e-mail clients 340 having rudimentary e-mail applications because of the fall back text provided in the master parts database 178.
  • each logical element of a story 180 includes, for example, associated semantic information that respectively indicates a set of logical elements of story 180 that are to be displayed, or played on the recipients device.
  • such semantic information also indicates when story player 194 should substitute an alternative logical element for another particular logical element.
  • Step 236 determines whether 1here is a response to the played story 180. Such a response can be provided, for example, by a user selecting a button control that the story 180 causes to be displayed. If there is such a response, step 238 generates a response to the story 180. For example, if the story is an e-coupon that promotes the purchase of a particular book, story player 194 (see FIG. 5) will create a structured format purchase order form, for example, an XML purchase order form. Such a form includes, for example, the customer ID, the product SKU (stocking number) that was included in story 180 (parsed from document 154 (see FIG. 2, FIG. 3, and FIG. 4), and any preferences. Such preferences include, for example, an indication of whether the book is to be received in electronic format instead of a physical format, the language that the book is to be written in, payment information, and the like.
  • Step 240 communicates the response (step 238) to the fulfillment server that was identified in the story 180 (parsed from document 154 (see FIGs. 2, 3, and 4).
  • Such communication can be implemented by using a number of different protocols, for example, the HTTP protocols or SMTP protocols.
  • the invention offers a number of strengths as compared to the closest competing technologies.
  • a story 180 plays off line as well as online and is lightweight (thin) enough to run on inexpensive information appliances or other devices.
  • a story includes, for example, user navigational aids, user forms, and can automate a transaction fulfillment process.
  • a story is instantly interactive, self-contained and reliable. Creation of a story's 180 content can be completely automated, such that devices made today will be able to handle future content without upgrades.
  • the invention facilitates publishing messages that are meaningful to individuals with physical disabilities and provides for intelligent content specific scaling and compression.
  • a story 180 is easily stored and exchanged as a single file, and the same content runs in Web pages in its own window and on low-power device screens.
  • a StoryMail Message Tag (MT) is assigned by the Story Server and sent to the Client (either conventional e-mail client or story enabled client or device) in the e-mail header.
  • This tag is used in the subsequent interactions between the Client and the Story Server and optionally with the Response Automation system and optionally with the StoryMail Certificate Authority (SMCA).
  • SMCA StoryMail Certificate Authority
  • MTs Message Tags
  • Valid MTs are chose sparsely from a large space, so the chance of guessing a valid Message Tag is very small. For the design given below, this chance is one in 2* * 48 (2 48 ). 4. MTs include a bit field that can be chosen by the server software in any way that it likes. For example, this field could be a simple counter that starts at zero for all servers. This field is 48-bits in the design given below.
  • the MTs are specific to a given recipient E-Mail address.
  • the server is very likely to detect an attempt to fetch a story using an MT that was sent to a different user.
  • the client software cannot distinguish valid from invalid MTs. There may be some benefit to adding a simple checksum character to the encoded MT, but this does not influence the basic algorithm.
  • the algorithm can be scaled to produce different size MTs.
  • a Message ID is the unscrambled form of a Message Tag (MT).
  • An MID contains a
  • Redundancy Field which could be 48-bits wide as shown below
  • Message Number which could be 48-bits wide as shown below.
  • the exact layout of the MID does not matter, though the diagram shows the Redundancy Field appearing to the left of the Message Number.
  • the bits of these fields can be interspersed in any fixed way known to the StoryMail Server.
  • the Redundancy Field allows the server to detect bogus MTs or MTs that were intended for a different user or server.
  • RF Left_48_Bits (SHA1 (ServerName
  • the ServerName is the domain name of the StoryMail server, or the name of the primary server when there is a collection of servers. It could be any unique character string, and it does not have to be kept secret.
  • the RecipientEmailAddress is the ASCII representation of the recipient's email address.
  • " means concatenation.
  • the function SHA1 means a FIPS-180-1 SHA1 digest.
  • the RF could also be a function of a secret known only to the StoryMail Server, or an indication of the date range when the MT was created, or other information from the Client's digital certificate, or other information sent by the Client before sending the Message Tag.
  • the SHA1 digest function shown above can be replaced with any cryptographically secure compression or hash or digest function including but not limited to MD2, MD4, MD5, RIPE160, SHA-256, SHA-384, SHA-512, DES-CBC-MAC, 3DES-CBC-MAC, IDEA-CBC-MAC, AES-CBC-MAC, DES-MDC, and DES-MDC2.
  • This algorithm performs three block encryption algorithms using a secret key, called Kmt, chosen by the server during installation. If this key is compromised, then the attacker can create and decode Message Tags. This is not considered to be a big security risk.
  • Kmt secret key
  • the current cryptographic architecture calls for using a 64-bit block cipher called XTEA, which has a 128-bit key.
  • the server needs to change the Kmt secret key, it will not be able to recognize MTs created by the old key. However, if the server wants to have a policy of changing the key periodically, they could keep a history of keys, and simply try each one to see if the MT unscrambles into a valid MID. If the server is willing to try three different keys, then chances of a random MT appearing valid will be three out of 2* * 48 (2 48 ).
  • the steps for creating the MT from the MID are listed below. During installation the Kmt key is chosen. The following steps can be conveniently performs using a single 12-byte buffer that is used as the input and output of the encryption function.
  • the buffer starts with the 12-byte MID and ends up with the 12-byte MT.
  • the algorithm operates on different eight-byte windows of the 12-byte buffer with xor operations used to link the windows.
  • FIG. 10 provides a diagrammatic illustration illustrating steps for creating an embodiment of a message tag from a message ID.
  • the algorithm to create the message tag can be viewed as a modified Cipher Block Chaining (CBC) mode that first processes the data from left to right and then again from right to left.
  • CBC Cipher Block Chaining
  • This two-pass approach guarantees that each output bit is dependent on each input bit.
  • the plaintext blocks contain both overlap data and data xor'ed in from the previous blocks. If some of the bits of the MID were hard to predict, then it would be possible to get by with just two encryption operations, but given the small performance benefit, this strong three step algorithm is used because it is easy to argue that it is secure.
  • the server checks the message tag when the client software attempts to fetch a story.
  • the client connected to the server via the lightweight SSL protocol, they will have sent their digital certificate, which includes their email address, and will have proven that they have current access to the private key that went with that certificate.
  • the email address in the certificate becomes the
  • RecipientEmailAddress that is used to compute the Redundancy Field in the MID. The steps are:
  • Secure communications and message is established between the various components of the StoryMail system with the aid of digital certificates.
  • the Story Server and Story Enabled Client both have digital certificates that are used to establish a secure session between them to communicate Story Messages.
  • the Story Servers each have a unique certificate, and the Clients can have either unique or shared certificates. If there client has a unique certificate, then strong security properties, such as client authentication based on access to a unique private key, are possible.
  • the StoryMail system includes an innovation that makes the certificates smaller and carry both the encryption and authentication keys, so the architecture is simpler and fewer round trip messages are required to establish strong security properties.
  • the certificates have the following format:
  • MSB first RSA Public Key Modulus.
  • the exponent is 3 when the Version field is zero.
  • Subject-Enveloping-Key - 128 bytes, MSB first RSA Public Key Modulus.
  • the exponent is 3 when the Version field is zero.
  • Tag - 4 bytes Device number for certificate. Zero first device enrolled. MSB first.
  • MSB first length of following characters in bytes (i.e., Unicode characters count as 2 bytes if they are ever adding to this design).
  • Subject-Name - zero or more bytes, leftmost character first. • Issuer-Name-Length - 2 bytes, MSB first length of following characters in bytes.
  • Issuer-Name zero or more bytes, leftmost character first.
  • Issuer-Signature - 128 bytes signature from StoryMail CA on this certificate.
  • the signature covers all the fields above this one, including the Type, Version and Content- Length. Notice that all the fixed length fields appear first, which improves the performance of certificate processing software. Also, notice that the certificate includes both the signing key for authentication and the enveloping key for encryption.
  • the format can be extended to include more than two public keys for the subject.
  • Type and Version fields encode all the information that is carried in several different fields of a traditional X.509 certificate. It encodes, the selection of cryptographic algorithms for
  • the StoryMail protocols for secure sessions, secure one-way messaging, secure downloading, secure upgrading, secure enrollment and secure auditing, are all based on a small common set of cryptographic methods (also called primitives in this description) and common data formats used for sending information between and within StoryMail components (Server, Client, Response Automation, Certificate Authority, and the like).
  • the following encryption primitive provides privacy and tamper detection and is used for example in the LW SSL Data and Finish packets.
  • This primitive can be expressed functionally as shown below. When used with the LW SSL protocol this primitive covers the entire record including the 4-byte header. That is, after the handshake all the data in the TCP stream is protected by encryption and cryptographic checksums.
  • the encryption can be viewed as existing in the layer between the TCP socket and the parsing of data records.
  • SealEncryptedData (Key, CBC-Chain, Data-To-Protect, Protected-Data, Output- CBC-Chain) performs the following steps:
  • Ciphertext CBC-Pad-Encrypt (Key, CBC-Chain, Plaintext).
  • Ciphertext Protected-Data
  • the CBC-Pad algorithms can be based on any block cipher, and is illustrated above for block ciphers that have 8-byte block sizes. Other block sizes, such as 16-bytes are implemented in a similar manner.
  • the specific cipher used in the preferred embodiment is the XTEA 64-bit block cipher with a
  • cipher 128-bit key running in CBC mode with PKCS #5 padding (i.e., one to eight pad bytes where each byte has the same value which is equals the number of padding bytes).
  • PKCS #5 padding i.e., one to eight pad bytes where each byte has the same value which is equals the number of padding bytes.
  • the XTEA cipher has the advantage of requiring a very small size of software code to implement.
  • Other ciphers such as triple-DES, DES,
  • the primitive can be expressed as a function as show immediately below.
  • the Data-Encryption-Key is the first 128-bits of the 160-bit OAEP-Seed.
  • SealSignedlnsideEnveloped (Recipient-Public-Key, Sender-Private-Key.Sender-Certificate, Data- Encryption-Key, OAEP-Seed, Data-To-Seal, Protected-Data)
  • This function performs the following steps.
  • Envelope-Block RSA-Public-Encrypt-OAEP (Recipient-Public-Key, Data-Encryption-Key, OAEP-Seed) 2.
  • Envelope-Recipient SHA1 (Recipient-Public-Key)
  • the Recipient-Public-Key is passed to SHA1 with the MSB first.
  • the exponent is assumed to be 3 and it not passed to SHA1.
  • Sender-Cert-Chain be an array of bytes where the first byte is the number of certificates in the chain, and the remaining bytes are the concatenation of the certificates. Recall that certificates include length information, so the start of each certificate can be identified.
  • the Data-Encryption-Key and the OAEP-Seed can be proper or improper subsets of each other.
  • the Data-Encryption-Key could be the first 128 bits of the OAEP-Seed, or the OAEP- Seed could be generated from the Data-Encryption-Key by adding a fixed padding or by adding bits that are a simple function (such as bit-selection or rolling-exclusive-or) of the Key.
  • the LW SSL protocol runs on top of a reliable bi-directional byte stream such as TCP.
  • the byte stream is assumed to be insecure in the sense that bytes can be modified, recorded, replayed, inserted or deleted.
  • the protocol turns this byte stream into a record stream by sending blocks of information preceded by a header that identifies the type of the record and its length. Implementations of this protocol will want to organize the transmission of records to fall within a single IP packet that makes up the TCP byte stream.
  • the protocol assumes that the byte stream will deliver any bytes that are sent so there is no need to handle retransmissions or acknowledgements at the LW SSL layer (these are done at the TCP layer).
  • the protocol does however detect deleted data. If an application needs an acknowledgement that some piece of data is received, it will do that at a higher layer (e.g., the StoryMail reader expects to fetch a story and will keep trying until it gets the whole story).
  • the protocol begins with a handshake phases that sends two records in each direction.
  • the two records sent by the server can be combined into a single TCP/IP packet, so the total overhead is three packets.
  • These records can be used to setup a new master key (MK) for parties that have not communicated with each other recently, or reuse an existing MK that is cached to improve performance (reducing computation overhead and communication bandwidth).
  • MK master key
  • the parties will be mutually authenticate to each other.
  • Different keys are used by the client and server for sending data. This avoids possible replay attacks such as sending the client a message that it had originally sent to the server in order to trick the client into thinking that the message came from the server.
  • the SSL protocol has this mechanism also.
  • the client and server maintain the following information.
  • the KID for the MK is the hash of the MK itself, so there is no need to store it separately.
  • the KID for the MK is the hash of the MK itself, but it is the index to this table, so it must be kept as a column. Rows can be deleted when they have not been used for some time or when space is needed. o Cache table of hash values for client certificates that have been validated.
  • This table reduces the effort required to validate a client certificate.
  • MSB first number of bytes in remaining content not including the four header bytes. If more than 65536 bytes are to be sent, then up to 4 bits of the version byte can be used to represent lengths up to 1 Mbyte. The preferred way to send a large data item is to place it in several smaller records.
  • the Type byte of a record can have the following meanings. For the first release the version byte will be zero.
  • SM-Certificate a certificate.
  • SM-Hello-New-MK a new master key request.
  • the protocol for setting up a new master key assumes that the client has the digital certificate for the server. It would get this through the email header information or request it via an unsecured request protocol (e.g., HTTP get and response exchange). At a minimum it needs to know the server's public key, and during the setup it will be given the server's certificate, which is then verified to ensure that the server is a valid member ofthe StoryMail system.
  • HTTP get and response exchange e.g., HTTP get and response exchange
  • the exchange is based on a digital enveloping mechanism that is shared with the lightweight S/MIME protocol. The steps are listed below. Notice that the client certificate is encrypted inside a digital envelop that can only be opened by the server. This helps improve the privacy of communication since the sender's identity is not exposed at this layer, though of course some IP source address information will be exposed by the lower layers, but that IP address might belong to a firewall/proxy rather than to the sender.
  • SealSignedlnsideEnveloped (Client-Public-Key, Server-Private-Key, Server- Certificate, Client-Message-Key, Client-Message-Key, Server-Nonce)
  • the server can respond with a different certificate than the client used to in step 1 , but the server name in the certificate must match the expected value.
  • MK HMAC (Server-Nonce
  • C -> S Client-Finish Same format as Data message, with the contents being the 160-bit value SHA1 (Client None
  • New-MK record does not include any value generated by the Client, so the Server can precomputed this value and avoid the performance penalty of performing an RSA private key operation to start each new
  • the Server can reuse the same signed value with multiple Clients with little worry about weakening the resulting session keys.
  • Client-Message-Key is used as both the message key and the OAEP-Seed value in the embodiment shown above.
  • Other embodiments could use a different value for the Client- Message-Key and the OAEP-Seed.
  • the protocol for reusing the master key is tried whenever possible to avoid the computational overhead of RSA.
  • the server will send a reject message if the MK is no longer cached or if it has been used for too long.
  • the client responds to a reject by initiating the New MK protocol.
  • SHA1 cryptographic digest show in the embodiment above can be replaced with any other cryptographically strong digest function such as MD5, RIPEMD-160, SHA-256, and the like.
  • This Hello-Reuse-MK Record record has a standard header followed by two fixed length fields. All the Reuse-MK records have a very similar formats. This reduce the amount of code needed to implementation them.
  • MSB first number of bytes in remaining content.
  • This Accept-Reuse-MK Record record has a standard header followed by three fixed length fields.
  • the Client-Nonce is included to make replay attacks that use TCP stream insertion techniques harder to perform.
  • MSB first number of bytes in remaining content.
  • Server-Nonce - 20 bytes Output of pseudo random number generator, or hardware random number generator.
  • This Reject-Reuse-MK Record record has a standard header followed by two fixed length fields.
  • the Client-Nonce is included to make denial of service attacks that use TCP stream insertion techniques harder to perform.
  • the client should respond to this record by attempting a Hello-New-MK handshake.
  • the Hello-New-MK record has the standard header followed by a nonce that is wrapped up for the Server. It includes the client's certificate, so the server does not need a database of client certificates. The server checks the signature on the client certificate, or checks that the hash of the certificate is in its database of previously validated certificates. See the section on cryptographic primitives for the data produced by SignedlnsideEnveloped. • Type - 1 byte.
  • MSB first number of bytes in remaining content.
  • the Accept-New-MK record has the standard header followed by a nonce that is wrapped up for the Client. It includes the server's certificate since the client may only have the server's public key. The client verifies the certificate to ensure that it is speaking to an authorized server. See the section on cryptographic primitives for the data produced by SignedlnsideEnveloped.
  • MSB first number of bytes in remaining content.
  • the Server-Nonce and Message-Key come from the server's pseudo random number generator, the Client-Public-Key comes from the Client-Certificate received in the Hello-New-MK message.
  • the Server-Nonce and Message-Key come from the server's pseudo random number generator, the Client-Public-Key comes from the Client-Certificate received in the Hello-New-MK message.
  • Private-Key and Client-Certificate comes from the server's protected storage.
  • the Client-Nonce is not included in this record to allow the server to reduce the number of private key operations that it must perform.
  • the server can send the same signed Server-Nonce to multiple clients as long as they all have different Client-Nonce values, thus it does not need to do a private key operation to create each Accept-New-MK message, just a public key operation to sent it to the client. However, the server does need to perform a private key operation to Unseal the Hello-New- MK message. Since the Client-Nonce in not included in the Accept-New-MK record, an attacker could replay an old message and the client will not immediately detect the replay. The client will discover the replay when it validates the Server-Finish record. Only a current Accept-New-MK record will produce the correct validation for the Server-Finish, since it requires knowledge of the new Client-Nonce as well as the possibly replayed Server-Nonce. An old Server-Finish record will not validate.
  • This record appears inside the EncryptedData primitive.
  • the first block of encryption must be stripped off to find the 4-byte record header in order to find the length of the record contents. See the section on cryptographic.pr.imitiv.esJor.details. For. the, Finish records. the CBC-Chain is zero.
  • This Server-Finish Record record is similar to Client-Finish.
  • This record appears inside the EncryptedData primitive.
  • the first block of encryption must be stripped off to find the 4-byte record header in order to find the length of the record contents. See the section on cryptographic primitives for details.
  • the CBC-Chain value comes from the last ciphertext block of the encrypted Finish record.
  • Subsequent CBC-Chain values come from the last ciphertext block of the previous Data record.
  • the enrollment can take place automatically without any user interaction. 2. For baseline security it is not necessary to issue individual certificates to the clients.
  • the SSSL protocol will ensure privacy, integrity, and server-side authentication even if all clients share the same private keys that are built into the Reader program.
  • the enrolling device receives a digital certificate that is specific to the user's email address. 4.
  • the certificate is issued by a global StoryMail Certificate Authority (SMCA). There may be half a dozen of these in the world and they maintain a loosely synchronized database.
  • SMCA StoryMail Certificate Authority
  • the digital certificate is in a proprietary format (not X.509) and it includes both a public key from signing and a public key for enveloping (encrypting) data.
  • the key-pairs are generated by the SMCA using a strong random number generator and the private keys are forgotten.
  • This documents includes notes on a future feature that would allow client devices to generate their own private keys.
  • the LW SSL protocol ensures privacy, integrity, and server-side authentication even if an attacker knows the private key of the client. The attacker must know the private key for both the client and the server to be able to compute the session key. In this case, the server's private key is not known.
  • the Reader programs can all share the same private keys and use self-signed certificates that include each client's email address.
  • Every StoryMail SMTP message includes an invitation to download a StoryMail reader so the user can see the Story content as its author intended. If the device already has a reader, then information in the header-of the SMTP message will be processed by the reader and the SMTP message will be replaced with the Story that is fetched from a StoryMail server via the SSSL protocol. Thus, only users who do not have the Reader see the body of the SMTP message. Somewhere in that message body will be a URL that the user can click on to download the reader and play the Story. When the user clicks on the download URL, their browser will launch and eventually the desired Story will play. This document describes the security relevant actions that take place between clicking the URL and the playing the first Story.
  • the download proceeds in two phases.
  • the first phase uses the browser's own security mechanisms to fetch a Loader program, and during the .second phase the Loader uses StoryMail protocols to securely fetch the StoryMail Reader and perform the enrollment protocol to get a digital
  • SMCA StoryMail Certificate Authority
  • this design assumes that data transferred has good enough integrity and authenticity for the user, but that an attacker will be able to record all of this data for later analysis or replay.
  • the browser may be able to perform strong authentication of the source of information using SSL, but the SSL encryption used by the browser may be weak enough for the attacker to easily break (e.g., 40-bit keys). It might even happen that no SSL capability is present, but the user trusts the address resolution process of the Internet to navigate to the correct host when data is downloaded. In this case, the data is not encrypted. Basically, the user assumes that the attacker is not able to actively intercept and modify downloaded data.
  • the result of the first phase is that a small Loader program begins to run on the client device.
  • the server Based on information sent to the server during the HTTPS or HTTP GET request generated by clicking the download URL, the server will send an Internet Explorer (IE) ActiveX control or a Netscape plug-in.
  • IE Internet Explorer
  • the Loader comes from the StoryMail server that sent the SMTP message to the user, and it will include information that came from the download URL. That URL includes: 1. The name of the StoryMail server.
  • the StoryMail server can verify that the message tag and client email address match using an algorithm described in [Mtag] that is based on a server specific secret key. This means that the attackers cannot forge new download URLs, they can only replay ones that have been recorded from the SMTP messages or Loader requests.
  • the StoryMail server modifies the Loader program for each download request by including a the client's email address, which will be used when requesting a digital certificate, or for baseline security (before the SMCA exists) this address will be placed in a self-signed certificate.
  • the Loader also includes the URL for the regional SMCA.
  • this design assumes that the Loader program will be able to create a private, encrypted, tamperproof and server-authenticated data pipe between the client device and the SMCA.
  • the Loader uses the SSSL protocol to achieve this security.
  • the Loader is configured to use fixed private keys, which the attacker can know without compromising the security properties of this protocol.
  • the certificate in the Loader which goes with these keys indicates that they are Loader keys, and thus they do not uniquely identify an email address, and the matching private keys may be known to the attacker.
  • the Loader connects to the SMCA using a compiled in URL and the SSSL protocol with the compiled in certificate and private keys.
  • the SSSL implementation will generate a random pre-master key value that is sent to the SMCA encrypted with the SMCA's public key (which is also compiled into the Loader). Notice that an attacker would need to know the SMCA's private key to recover this value.
  • the SMCA sends back a different random pre-master key value encrypted with the Loader's public key and signed by the server's private key. An attacker will be able to recover this value, since the Loader's private key is known, but the attacker cannot create these values, only replay them.
  • the session master key is a cryptographic function of both random pre-master key values, so the attacker will not be able to compute it, and therefore will not be able to read the subsequent traffic.
  • the Loader then requests the correct Reader program for the client platform, and if the SMCA is issuing client specific certificates, the Loader .(or Reader) requests a certificate for the .client.
  • the request includes the client's email address which is put in the certificate.
  • the SMCA generates the key- pairs for singing and encrypting data.
  • the public keys go into the certificate, and the private keys are passed to the Loader along with the certificate.
  • the SMCA deletes the private keys after they has been sent to the Loader.
  • SMCA sites which could be server farms
  • the entries in this database are updated between the SMCA sites using some protocol that is beyond the scope of this document.
  • the security of this system does not rely on tight coupling between the databases on different SMCA sites. This design assumes that the sites are synchronized at least once per day.
  • the following data is maintained by the SMCA sites.
  • the certificate request is separate from the Reader download request. This protocol could be executed by the Loader, or later by the- Reader. However, it does require that the requester know the client's email address.
  • This protocol uses a record structure (like the one used by the SSSL protocol) to send the request and the response, though these records are transported as ordinary Data records of the SSSL protocol.
  • the request includes the email address of the client.
  • the first part of the response will be the private keys.
  • the second part of the response will be a certificate chain that starts with the user certificate and chains up to and including the StoryMail root certificate.
  • Other versions of this protocol have the client generating the key-pairs, so the request will include the public keys and the response will not include the private keys.
  • the format of the Certificate Request is shown below. In the first release, the public key lengths and exponents are zero since the SMCA is generating the key-pairs.
  • MSB first number of bytes in remaining content
  • Email-Address-Length - 2 bytes, MSB first length of following characters in bytes.
  • Email-Address - Zero or more bytes Client Email Address.
  • Signing-Public-Key-Exponent- 2 bytes, MSB first. • Signing-Public-Key-Length - 2 bytes, MSB first length of following field in bytes.
  • Enveloping-Public-Key- n bytes, MSB first Modulus.
  • the format of the Certificate Response is shown below.
  • the private key length and exponent fields will be zero if the client chooses the key-pairs itself and simply sends the public keys in the request message.
  • Type - 1 byte SM-Certificate-Response
  • MSB first all the parts of the private key in an order to be determined (e.g., P, Q, and CRT parameters).
  • MSB first all the parts of the private key in an order to be determined (e.g., P, Q, and CRT parameters).
  • Cert-Chain - n bytes an array of bytes where the first byte is the number of certificates in the chain, and the remaining bytes are the concatenation of the certificates. Recall that certificates include length information, so the start of each certificate can be identified.
  • the client's certificate will be the first one in the chain.
  • the Loader will put the received key-pairs and certificates in a place that can be located by the Reader program.
  • the Reader program When the Reader program is first launched, it should validate that the public keys in the certificate match the private keys.
  • the client could download a special program that generates key-pairs and performs the certificate request process. If the certificate request requires a message tag, then requesting a certificate would have to be integrated with the mail filter software that sees the message tags. If only the Email Address is required, this can run separately, though there would need to be some mechanism that proves that the requester has current access to an Address.
  • the key generation program could be downloaded separately from the SMCA site by clicking on URLs that are part of documentation or online help pages.
  • the key generation software will need to be audited by an independent cryptography consultant to convince security conscious users that it is secure.
  • PKCS #12 file that has been exported by browsers from Netscape or Microsoft, or other PKI software.
  • An other class or security conscious users will want the StoryMail Reader to access private keys stored on a physical or virtual smart card. This type of security feature may also be provided.
  • the Story Enabled Client can establish a secure Response Session between the client machine and a Response Server machine using the Secure Response Protocol.
  • the an advertisement message could include a button that the user presses to connect to the a merchant server that is acting as the Response Server or to a server that is shared among two or more merchants called the Response Automation Server to send and receive further information.
  • the case of sending a unidirectional response message is described below. This section is describing the establishment of a secure bi-directional link.
  • a valuable feature of the Secure Response Session protocol is that it is nearly identical to the LW SSL protocol.
  • the difference is that the URL of the Response Server and the public key for the Response Server are both embedded in the Story message, instead of, for example, appearing in the regular e-mail header as it does with LW SSL.
  • the Secure Response Session is set up by the following-steps: Extract the URL of the Response Server and public key of the Response Server from the currently playing Story message. a. These two values can appear separately in the Story message. b. One or both of these two values can appear inside a Compact Certificate that appears in the Story. In this case, the digital signature on the certificate is verified to confirm that this is an authorized certificate. c. Additional security checks may optionally be performed on these two values, such as checking that the URL of the Response Server matches part of a URL that appears elsewhere in the story such as the identity of the author of this story. 2. Check for a cached Master-Key related to the Response Server's URL. a.
  • the Response Server can authenticate the Client using unique information, which could be the Message Tag, that was placed in the Story sent to the Client.
  • Message to a Response Server This might be initiated by the Client in response to the user clicking on some active area of the Story display or other user interface action.
  • an advertisement message could include a "buy-it" button that the user will click on to initiate a purchase transaction with the Response Server operating on behalf of the merchant offering the advertised good or service.
  • This protocol can also be used to send secure unidirectional messages between any two Story
  • the Sender of the message receives the Compact Certificate for the Recipient of the message.
  • a Story message played by a Story Enabled Client might include the Compact Certificate for the Recipient as part of the data associated with an active region of the display or other user interface component.
  • the Sender gathers together the data it wants to send and then creates a record using the common SealSignedlnsideEnveloped cryptographic primitive.
  • the Type field identifies the purpose of this record and the format field identifies its structure.
  • the Recipient can use the common UnsealSignedlnsideEnveloped cryptographic primitive to extract the data and verify the authenticity of its source.
  • the authenticity of the Sender can be attested to by the presence of a data value that was uniquely sent to the Sender, such as a Message Tag or other token or cookie that was created with the story or exists on the Sender's machine (e.g., Microsoft Global Unique ID, Product ID, CPU ID, or Story Reader Registration ID).
  • a data value that was uniquely sent to the Sender, such as a Message Tag or other token or cookie that was created with the story or exists on the Sender's machine (e.g., Microsoft Global Unique ID, Product ID, CPU ID, or Story Reader Registration ID).
  • the steps in sending a Secure Unidirectional Message are: 1. Extract the URL of the Response Server and public key of the Response Server from the currently playing Story message, or from a repository of values like an address book. a. These two values can appear separately in the message or repository. b. One or both of these two values can appear inside a Compact Certificate that appears in the Story. In this case, the digital signature on the certificate is verified to confirm that this is an authorized certificate. c. Additional security checks may optionally be performed on these two values, such as checking that the URL of the Response Server matches part of a URL that appears elsewhere in the message such as the identity of the author of this story.
  • the step in receiving a Secure Unidirectional Message are:
  • the invention provides a hardware architecture neutral and operating system neutral and network transport neutral method for secure messaging and communications.
  • this method includes the following procedures and steps with options or variations.
  • An authorization procedure is provided for authorizing any particular user the right to access a specific resource.
  • a digital certificate procedure is provided that enables at least encryption and digital signatures having lower storage and bandwidth requirements than conventional digital certificates.
  • a security protocol implementation procedure for implementing two or more security protocols using a common set of data formats, algorithms, subroutines, and procedures.
  • a secure session interaction procedure having reduced software/firmware computer code/instructions and reduced network bandwidth than conventional secure session interaction procedures.
  • a unidirectional messaging procedure using less software/firmware code and reduced network bandwidth than conventional unidirectional messaging procedures.
  • a secure certificate issuing procedure using less software/firmware code and reduced network bandwidth than conventional secure certificate issuing procedures.
  • a secure response procedure using less software/firmware code and reduced network bandwidth than conventional secure response procedures.
  • a secure unidirectional response messaging procedure using less software/firmware code and reduced network bandwidth than conventional secure unidirectional messaging procedures.
  • the invention provides a hardware architecture neutral and operating system neutral and network transport neutral method for communicating or messaging. Embodiments are conveniently referenced and listed using a number surrounded by parenthesis for convenient reference.
  • a hardware architecture, operating system, and network transport neutral method secure communications comprising: an authorization procedure for authorizing any particular user the right to access a specific resource; a digital certificate procedure that enables at least encryption and digital signatures having lower storage and bandwidth requirements than conventional digital certificates; a security protocol implementation procedure for implementing two or more security protocols using a common set of data formats, algorithms, subroutines, and procedures; a secure session interaction procedure having reduced software/firmware computer code/instructions and reduced network bandwidth than conventional secure session interaction procedures; a secure unidirectional messaging procedure using less software/firmware code and reduced network bandwidth than conventional unidirectional messaging procedures; a secure certificate issuing procedure using less software/firmware code and reduced network bandwidth than conventional secure certificate issuing procedures; a secure response session procedure using less software/firmware code and reduced network bandwidth than conventional secure response procedures; and a secure unidirectional response messaging procedure using less software/firmware code and reduced network bandwidth than conventional secure unidirectional messaging procedures.
  • a system for secure communications comprising: an authorization module for authorizing any particular user the right to access a specific resource; a digital certificate encryption module that enables at least encryption and digital signatures having lower storage and bandwidth requirements than conventional digital certificates; a security protocol module for implementing two or more security protocols using a common set of data formats, algorithms, subroutines, and procedures; a secure session interaction module having reduced software/firmware computer code/instructions and reduced network bandwidth than conventional secure session interaction procedures; a secure unidirectional messaging module using less software/firmware code and reduced network bandwidth than conventional unidirectional messaging procedures; a secure certificate issuing module using less software/firmware code and reduced network bandwidth than conventional secure certificate issuing procedures; a secure response session module using less software/firmware code and reduced network bandwidth than conventional secure response procedures; and a secure unidirectional response messaging module using less software/firmware code and reduced network bandwidth than conventional secure unidirectional messaging procedures.
  • a computer program product for use in conjunction with a computer system having a server and a client, the computer program product comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism, comprising: a program module that directs the computer system and/or components thereof including at least one or the client or server, to function in a specified manner to provide message communications, the message communications occurring in a computer system hardware architecture neutral and operating system neutral and network transport protocol neutral manner for secure communications, the program module including instructions for: an authorization procedure for authorizing any particular user the right to access a specific resource; a digital certificate .procedure .that enables.
  • a security protocol implementation procedure for implementing two or more security protocols using a common set of data formats, algorithms, subroutines, and procedures; a secure session interaction procedure having reduced software/firmware computer code/instructions and reduced network bandwidth than conventional secure session interaction procedures; a secure unidirectional messaging procedure using less software/firmware code and reduced network bandwidth than conventional unidirectional messaging procedures; a secure certificate issuing procedure using less software/firmware code and reduced network bandwidth than conventional secure certificate issuing procedures; a secure response session procedure using less software/firmware code and reduced network bandwidth than conventional secure response procedures; and a secure unidirectional response messaging procedure using less software/firmware code and reduced network bandwidth than conventional secure unidirectional messaging procedures.
  • a hardware architecture, operating system, and network transport neutral method secure communications comprising: an authorization procedure for authorizing any particular user the right to access a resource; a digital certification procedure for encryption and digital signing; a security protocol procedure for implementing a plurality of security protocols using a single common set of policies and parameters; a secure session interaction procedure; a secure unidirectional messaging procedure; a secure certificate issuing procedure; a secure response session procedure; and a secure unidirectional response messaging procedure; the procedures using less software/firmware/computer code and reduced network bandwidth than conventional procedures to accomplish analogous functionality.
  • the invention provides a hardware architecture neutral and operating system neutral and network transport neutral method for authorizing a specific user the right to access a specific resource such as an e-mail message or a promotional coupon.
  • this method includes the following steps and options or variations.
  • a Resource Owner sends to the Specified User a Resource Tag (e.g., Message Tag or Coupon Tag), where the Resource Tag is the result of a reversible cryptographic transformation of a Redundancy Field and Resource Identifier Field (e.g., Message Number) and optionally other information.
  • a Resource Tag e.g., Message Tag or Coupon Tag
  • the Resource Tag is the result of a reversible cryptographic transformation of a Redundancy Field and Resource Identifier Field (e.g., Message Number) and optionally other information.
  • the cryptographic transformation of the fields of a Resource Tag can be based on one or more secret keys known to the Resource Owner using series of block encryption steps on portions of the fields in a manner that allows the transformation to be reverse by an entity that knows the one or more secret keys.
  • the cryptographic transformation can be performed by three or more applications of 8-byte block encryption using a cipher such as triple-DES or XTEA or RC5, where a portion of the output bits from each block encryption are xor'ed with a portion of the input bits to the next block encryption.
  • a cipher such as triple-DES or XTEA or RC5
  • the cryptographic transformation can be performed by a block cipher operating in Cipher-Block-Chaining mode with an initialization vector of zero or some fixed value that is applied in two passes, first from left to right across the bytes of the fields and then from right to left across those resulting bytes, with the end result being that each Resource Tag bit depends strongly on each bit of the input fields, and only an entity who knows the one or more keys can reverse this transformation.
  • the Redundancy Field can be a cryptographic hash (e.g. SHA1) of 1) some or all of the User Credential and 2) one or more parts of the Server's Credential, and 3) optionally of the other input fields of the Resource Tag.
  • the User's Credential could include that user's e-mail address.
  • Credential could include that server's domain name, or the domain name associated with the Resource
  • the optional fields from the Resource Tag could include the Resource Identifier.
  • the Specified User presents the Resource Tag and User Credential Information to the Resource Owner in a manner that allows the Resource Owner to verify the User's Credential
  • the verification of the User's Credential can be based on a challenge-response authentication protocol that proves that the User (client) communicating with the Resource Owner
  • server has current access to a private key (e.g., RSA or Elliptic Curve or NTRU private key) associated with a public key that appears as one field of the User Credential Information which is digitally signed along with other credential information by an entity that is trusted by the Resource Owner.
  • a private key e.g., RSA or Elliptic Curve or NTRU private key
  • the verification of the User's Credential can be based on a challenge response authentication protocol that proves that the User (client) communicating with the Resource Owner (server) has current access to a secret key (e.g., triple-DES or XTEA or RC5 or AES key) associated with a key identifier that appears as one field of the User Credential Information where the key identifier allows the server to lookup the same secret key known to the client, and other fields in the User Credential Information are verified using a cryptographic checksum based on that same secret key.
  • a secret key e.g., triple-DES or XTEA or RC5 or AES key
  • the Resource Owner determines whether to grant access to the Resource (e.g., e-mail message) by comparing a first cryptographic transformation of the Resource Tag to a second cryptographic transformation of some or all of the User Credential Information and one or more parts of the Server's (Resource Owner's) Credential Information, and optionally, one or more of the input fields to the Resource Tag, and then granting access if they are equal, otherwise denying access.
  • the first cryptographic transformation is the reverse of the one applied to create the tag from its input fields followed by an operation that extracts the Redundancy Field.
  • the second cryptographic transformation follows the same steps used to create the Redundancy Field based on verified User Credential Information, the Server Credential Information, and optionally one or more of the input fields to the
  • a computer program product for use in conjunction with a computer system having a server and a client, the computer program product comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism, comprising: a program module that directs the computer system a ⁇ u/u ⁇ components thereof including at least one or the client or server, to function in a specified manner to provide message communications, the message communications occurring in a computer system hardware architecture neutral and operating system neutral and network transport protocol neutral manner for a resource owner authorizing a specific user the right to access a particular resource, the program module including instructions for: A. sending a resource tag to a specified user; B. receiving, back from the specified user, the resource tag sent earlier and a user credential information; C.
  • a hardware architecture neutral and operating system neutral and network transport neutral method for a resource owner authorizing a specific user the right to access a particular resource comprising: A. sending a first information item to a specified user; B. receiving, back from the specified user, the resource tag sent earlier and a user second information item; C. verifying the user second information item; and D. comparing a first cryptographic transformation of the first information item to a second cryptographic transformation of the second information item; and E. granting access to the particular resource only if the first cryptographic transformation of the first information item has a predetermined relationship with the second cryptographic transformation of the second information items, and otherwise denying access to the particular resource.
  • the method in embodiment (6), wherein the particular resource comprises an e-mail message.
  • the method in embodiment (6), wherein the particular resource comprises a promotional coupon.
  • the method in embodiment (6), wherein the particular resource comprises an information item in electronic form.
  • the method in embodiment (6), wherein the particular resource comprises a storymail story.
  • the method in embodiment (6), wherein the resource tag comprises a message tag or a coupon tag.
  • the resource tag is generated as the result of a reversible cryptographic transformation.
  • the first information item comprises a redundancy field and the second information item comprises a resource identifier field and the transformation comprises a transformation of one or more of the Redundancy
  • the transformation comprises a transformation of a Redundancy Field, a Resource Identifier Field, and other information.
  • the resource tag comprises a message tag or a coupon tag and is generated as the result of a reversible cryptographic transformation, the transformation comprising a transformation of at least a Redundancy Field and a Resource Identifier Field, at least one of the redundancy field and resource identifier field including a message number.
  • the Cipher-Block-Chaining mode operates with an initialization vector, and said initialization vector has a fixed value.
  • the initialization vector has a fixed value.
  • the initialization vector is applied in two passes, a first pass in a first direction (from left to right) across the bytes of the fields and then a second pass in the opposite direction to the first pass (from right to left) across those resulting bytes, with the end result being that of generating resource tag bits which together form the resource tag, and wherein each resource tag bit depends strongly on bits of the input fields, so that only an entity who knows the one or more keys can reverse this cryptographic transformation.
  • the Redundancy Field comprises a cryptographic hash.
  • the redundancy field cryptographic hash comprises SHA1 of (i) some or all of a User Credential, and (ii) one or more parts of a Server Credentials.
  • the redundancy field cryptographic hash further comprises SHA1 of (iii) one or more other of the optional other input fields of the Resource Tag.
  • the optional fields from the Resource Tag include the Resource Identifier.
  • the User's Credential includes that user's e-mail address.
  • Credential includes either one or both of the server's internet domain name or the domain name associated with the Resource Owner.
  • verification of the User's Credential is based on a challenge-response authentication protocol.
  • the challenge-response authentication protocol is a protocol that proves that the User (client) communicating with the Resource Owner (server) has current access to a private key associated with a public key.
  • the private key comprises a RSA private key, an Elliptic Curve private key, or a NTRU private key.
  • the method in embodiment (41), wnerein the key identifier allows the server to look up the same secret key known to the client.
  • the first information comprises the Resource Tag
  • the second information item comprises some portion or all of the User Credential Information and one or more portions of the Server's or Resource Owner's Credential Information.
  • the method in embodiment (6), wherein the comparison comprises a logical operation.
  • the method in embodiment (48), wherein the comparison comprises a logical operation performed on a bit, byte, multi-bit, or multi-byte basis.
  • the comparison comprises an algorithm based comparison operation.
  • the method in embodiment (6), wherein the comparison comprises a mathematical operation.
  • the method in embodiment (6), wherein the first information comprises the Resource Tag, and the second information item comprises some portion or all of the User Credential Information and one or more portions of the
  • the comparison comprises at least one of a logical operation and a mathematical operation.
  • the predetermined relationship is equality.
  • the comparison comprises at least one of a logical operation and a mathematical operation and the predetermined relationship is equality.
  • the first information item comprises a redundancy field and the second information item comprises a resource identifier field; and the first cryptographic transformation comprises a process that is the reverse of the process applied to create the resource tag from its input fields followed by an operation that extracts the Redundancy Field.
  • the second cryptographic transformation includes substantially the same steps used to create the Redundancy Field based on at least one of the verified
  • a method for authorizing a user access a resource comprising: sending a resource tag to the user; receiving the resource tag and a user credential information from the user; verifying the user credential information; comparing a first cryptographic transformation of the resource tag to a second cryptographic transformation of some portion or all of the User Credential Information and one or more selected portions of the Server's or Resource Owner's Credential Information; and granting access to the resource only if the first cryptographic transformation of the resource tag matches with the second cryptographic transformation of the selected portion or all of the User Credential Information and one or more portions of the Server's or Resource Owner's Credential Information, and otherwise denying access to the resource.
  • the invention provides a ⁇ ar ⁇ ware architecture neutral and operating system neutral and network transport neutral method for representing a digital certificate that enables at least encryption and digital signatures using substantially less storage and bandwidth than conventional digital certificates.
  • this method includes the following steps and options or variations.
  • a common data object header is used that includes fields called Type, Version, and Content-
  • Length in all communicated data including certificates.
  • the type field may be used to identify that this object is a Certificate.
  • the Version number may be used to represent four of more of the following attributes: Algorithm used by Certificate Issuer to sign the certificate, Algorithm to be used with the
  • Subject's first public key Algorithm to be used the Subject's second or subsequent public key, Length of each public key, Length of Certificate Issuer's signature, Parameters for each of the algorithms such as the exponent to use with RSA public key, Subject Name and/or Character Set of Subject Name, and Issuer Name and/or Character Set of Issuer Name.
  • Two or more (a plurality of) public keys are contained in a single certificate, each with its own purpose such as encrypting message or session keys, or signing messages, or signing and encrypting data.
  • a Tag Field is included that functions as a discriminator of different Certificates issued to the same Subject.
  • the Tag Field may be treated as an unsigned integer (e.g., a four byte value) that is incremented with each Certificate issued to the Subject, so given two Certificates with the same Subject Name, it is easy to tell which on is more recent. This replaces the validity dates found with X.509 Certificates.
  • the Tag Field may for example, be treated as four ASCII characters to represent the expiration date of the Certificate as a two digit month number and a two digit year number (e.g., MMDD or DDMM, etc.).
  • the Subject Name and Certificate Issuer Name are represented in one fixed character set determined by the Version Field. For example, represent the Subject Name and Certificate Issuer Name as two-byte Unicode characters.
  • the Version Field is used to indicate any additional fields that are present in the certificate. Some particular embodiments relating to these aspects are highlighted below.
  • a computer program product for use in conjunction with a computer system having a server and a client, the computer program product comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism, comprising: a program module that directs the computer system and/or components thereof including at least one or the client or server, to function in a specified manner to provide message communications, the message communications occurring in a computer system hardware architecture neutral and operating system neutral and network transport protocol neutral manner for representing a digital certificate, the program module including instructions for: A. using a common data object header in substantially all communicated data including communicated certificates; B.
  • each the byte has a length selected from the set of byte lengths consisting of 8 bits, 10 bits, 12 bits, 16 bits, 24 bits, 32 bits, 64 bits, 96 bits, and 128 bits.
  • the version number is used to represent at least one of the following attributes: (i) Algorithm used by Certificate Issuer to sign the certificate, (ii) Algorithm to be used with the Subject's first public key, (iii) Algorithm to be used the Subject's second or subsequent public key, (iv) Length of each public key, (v) Length of Certificate Issuer's signature, (vi) parameters for the algorithm, (vii) an exponent to use with RSA public key (viii) Character Set of Subject Name, and (ix) Character Set of Issuer Name.
  • the version number is used to represent a plurality of attributes selected from the set of attributes consisting of: (i) Algorithm used by Certificate Issuer to sign the certificate, (ii) Algorithm to be used with the Subject's first public key, (iii) Algorithm to be used the Subject's second or subsequent public key, (iv) Length of each public key, (v) Length of Certificate Issuer's signature, (vi) parameter(s) for an algorithm, (vii) an exponent to use with RSA public key, (viii) Character Set of Subject Name, and (ix) Character Set of Issuer Name.
  • Version number is used to represent at least four attributes selected from the set of attributes consisting of: (i) Algorithm used by Certificate Issuer to sign the certificate, (ii) Algorithm to be used with the Subject's first public key, (iii) Algorithm to be used the
  • Subject's second or subsequent public key (iv) Length of each public key, (v) Length of Certificate Issuer's signature, (vi) parameter(s) for an algorithm, (vii) an exponent to use with RSA public key, (viii) Character Set of Subject Name, and (ix) Character Set of Issuer Name.
  • the plurality of public keys include at least two public keys that have the same size (same length) and system parameters.
  • the system parameters include an RSA Exponent or Diffie-Helman Generator.
  • the Tag Field is treated as an unsigned integer that is incremented with each Certificate issued to the Subject.
  • Tag Field is treated as four ASCII characters to represent the expiration date of the Certificate as a two digit month number and a two digit year number.
  • a hardware architecture neutral and operating system neutral and network transport neutral method for representing a digital certificate that enables at least encryption and digital signatures using substantially less storage and bandwidth than conventional digital certificates comprising the steps of: using a common data object header in substantially all communicated data including communicated certificates; providing a plurality of public keys including a first public key and a second public key in a single certificate, each of the at least first and second public keys being associated with its own purpose; providing a Tag Field that functions as a discriminator of different Certificates issued to the same Subject; and representing a Subject Name and a Certificate Issuer Name in one fixed character set determined by the Version Field; the common data object header includes a plurality of fields including a Type field, a Version field, and a Content-Length field; the purpose is selected from the group of purposes consisting of encrypting messages, encrypting session keys, signing messages, signing and encrypting data, and combinations thereof; at most two bytes are used to represent a type and a version for the Type Field the Version Field; and
  • a method for representing a digital certificate comprising: using a common data object header in all communicated data including communicated certificates; providing a plurality of public keys including a first public key and a second public key in a single certificate; providing a first field that functions as a discriminator of different certificates issued to the same subject; and representing a subject name and a certificate issuer name in one fixed character set determined by a second field.
  • the invention provides a hardware architecture neutral and operating system neutral and network transport neutral method for implementing two or more security protocols such as 1) secure interactive sessions, 2) secure unidirectional messaging, 3) secure software downloading, 4) secure software upgrading, and 5) secure issuing of digital certificates, using a common set of data formats, algorithms, subroutines, and procedures.
  • security protocols such as 1) secure interactive sessions, 2) secure unidirectional messaging, 3) secure software downloading, 4) secure software upgrading, and 5) secure issuing of digital certificates, using a common set of data formats, algorithms, subroutines, and procedures.
  • the method includes the following steps and options or variations.
  • Encrypted-Data which provides privacy and data integrity based on a secret key and cipher algorithm (e.g., triple-DES, XTEA, RC4, AES, etc.), and for 2) Signed-lnside-Enveloped-Data, which provides transport of a secret key
  • Encrypted-Data which provides privacy and data integrity based on a secret key and cipher algorithm (e.g., triple-DES, XTEA, RC4, AES, etc.)
  • Signed-lnside-Enveloped-Data which provides transport of a secret key
  • the primitive For block ciphers (e.g., triple-DES and XTEA) the primitive includes an Initialization Vector for Cipher-Block-Chaining mode that is an input to the primitive and appears in the data format of the output, and the primitive returns a new Initialization Vector to be used with the next block of Encrypted Data.
  • an Initialization Vector for Cipher-Block-Chaining mode that is an input to the primitive and appears in the data format of the output, and the primitive returns a new Initialization Vector to be used with the next block of Encrypted Data.
  • the secret key to the cipher is one input to this primitive.
  • stream ciphers e.g., RC4
  • the secret key to the cipher is one input to this primitive.
  • the integrity of the data that is, tamper detection, is provided by a cryptographic message authentication code that is based on a secret key, which could be equal to or derived from the key used to encrypt the data, where the authentication code is computed by well known algorithms such as CBC-MAC or HMAC.
  • the primitive can take as an optional input some data, such as Type, Version and Content-Length fields, that is protected by the cryptographic message authentication code, but not part of the output data; for example, the Type field may be transmitted first before the Encrypted-Data and not be part ofthe Encrypted-Data.
  • the method provides in one embodiment that only these two primitives are used to construct two or more protocols.
  • a protocol application does not have or does not need public keys and/or certificates for both the Sender and the Recipient, use fixed public keys and/or certificates.
  • a protocol application such as downloading signed software does not require that the data be encrypted, so such protocols often invent a third cryptographic primitive for signed-only data, in contrast this method calls for using Signed-lnside-Enveloped-Data to provide the software signing and encryption using a fixed Recipient public key to which all receiving software knows the private key.
  • the certificates used with this protocol include at least signing and encryption public keys, so it is possible for the Receiver to send an encrypted message back to the Sender of a message, since the Senders Certificate in the received message includes the Senders encryption public key.
  • the Signed-lnside-Enveloped-Data primitive provides all the security functions required for secure unidirectional messaging such as e-mail or a response to a promotional offer.
  • the Signed-lnside-Enveloped-Data primitive provides the critical piece for setting up a session key with a new entity for which the Sender knows the Recipient's public key, which could happened via a plaintext request of the certificate of the Recipient, by sending the Recipient a master secret from which the session keys will be derived, or by the Sender having received the Recipient's certificate in a previous communication.
  • the keys for the Encrypted-Data primitive can oe derived from information exchanged either in the clear (i.e., insecure plaintext) and/or in the Signed-lnside-Enveloped-Data primitive. This provides a form of dual key determination and challenge-response authentication.
  • New secret session keys can be derived from old secret keys that where previously agreed to by the Sender and Recipient, and thus the overhead of public and private key operations can be avoided by just using the Encrypted-Data primitive with appropriate keys.
  • Authentication for a session key can be provided by using the Encrypted-Data primitive with values that are produced by the cryptographic hash of some or all of the data transmitted before sending the authentication message. Including all of the prior data helps thwart various attacks on cryptographic protocols. To avoid various protocol attacks, separate keys can be used by the Sender and Recipient by
  • Certificate Issuing can be authenticated by sending a Resource Tag (e.g., Message Tag) to the Resource Tag (e.g., Message Tag) to the Resource Tag (e.g., Message Tag) to the Resource Tag (e.g., Message Tag)
  • Issuer after the session keys have been established using fixed public and private keys for a client device that wants to get a Certificate from the Issuer.
  • the fixed keys are replaced with the newly generated keys (generated either on the client or by the Issuer) once the client has received the Certificate, and optionally the generated keys.
  • a Secure Response Session protocol can be implemented using the Signed-lnside-Enveloped- Data primitive with a public key of the Recipient that is included inside the promotional message to which this is a response session, perhaps inside a Certificate that is verified by the Sender of the Response, and the information contained in the Signed-lnside-Enveloped-Data, including possibly a portion of the information encrypted with the Recipient's public key, being used to derive privacy and integrity keys for a bi-directional session.
  • a Secure Response Message protocol can be implemented using the Encrypted-Data primitive with a secret key know to the Recipient that is included inside the promotional message that was received securely, and the Encrypted-Data primitive containing the Response Message.
  • a Secure Response Message protocol can be implemented using the Signed-lnside-Enveloped-Data primitive with a public key of the Recipient that is included inside the promotional message to which this is a response, for example, it may be included inside a Certificate that is verified by the Sender of the Response Message, and the primitive containing the Response Message.
  • a computer program product for use in conjunction with a computer system having a server and a client comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism, comprising: a program module that directs the computer system and/or components thereof including at least one or the client or server, to function in a specified manner to provide message communications, the message communications occurring in a computer system hardware architecture neutral and operating system neutral and network transport protocol neutral manner for implementing a plurality of separate security protocols using a common set of criteria, the program module including instructions for: A. defining two cryptographic primitives; and B. using only the two cryptographic primitives to construct the plurality of separate security protocols.
  • a hardware architecture neutral and operating system neutral and network transport neutral method for implementing a plurality of separate security protocols using a common set of criteria comprising the steps of: A. defining two cryptographic primitives; and B. using only the two cryptographic primitives to construct the plurality of separate security protocols.
  • the method in embodiment (85), wherein the two cryptographic primitives are sued to construct a greater plurality of security protocols.
  • the cryptographic primitives consist of only formats and algorithms.
  • Encrypted-Data providing privacy and data integrity based on a secret key and a cipher algorithm.
  • the cipher comprise a block cipher; the primitive includes an Initialization Vector for Cipher-Block-Chaining mode that is an input to the primitive and appears in the data format of the output; and, the primitive returns a new Initialization Vector to be used with the next block of Encrypted Data.
  • the secret key to the cipher is one input to this primitive.
  • the block cipher is a cipher selected from the set consisting of a triple-DES based cipher, and a XTEA based cipher.
  • the authentication code is computed by a CBC-MAC based algorithm and/or a HMAC based algorithm.
  • the primitive takes as an optional input some other data that is protected by the cryptographic message authentication code, but not part of the output data.
  • the method in embodiment (107), wherein such other data is selected from the set of data identified as data in a Type Field, Version Field, Content- Length field, and combinations thereof.
  • the invention provides a hardware architecture neutral and operating system neutral and network transport neutral method for secure interactive sessions using less software code and network bandwidth than conventional systems.
  • the method includes the following steps and options or variations.
  • the Client sends to the Server a first message and the Server sends to the Client a second message, where the first message and second message have substantially the same content, format and cryptographic processing, and the first message includes a Client-Nonce, and the second message contains a copy of the Client-Nonce extracted from the first message, and the second message has a value, sometimes called the Server-Nonce, that was chosen by the Server that is not predictable by the
  • the first and second message may or may not have any cryptographic processing, and in particular may have no cryptographic processing when the protocol is attempting to reuse cryptographic master keys that were established in a previous session, and these messages will have substantially the same format, and the Server verifies the existence of the Key-ID from the first message in its cache of pairs of Key-ID and Master Key values.
  • the first and second message have a common header that includes fields for Type, Version, and Content-Length, and the first message contents containing a Key-ID and a Client-Nonce, and the second message contents containing the same Key-ID, same Client-Nonce, and a new Server-Nonce.
  • the Key-ID may be a cryptographic hash (e.g., MD5, SHA-1 , SHA-256) of a previously set up
  • the Client-Nonce and Server-Nonce have the same length, which may for example be 16, 20, 32 bytes, or other length long.
  • the first and second messages can be cryptographically processed using public key operations such as RSA, and these messages will have substantially the same format and cryptographic processing, and the Client and Server verify the certificate chain in the received second and first message respectively.
  • the first and second messages are created using the Signed- Inside-Enveloped-Data cryptographic primitive defined earlier, and the Client-Nonce (respectively Server-
  • Nonce is sent to the Server (Client) encrypted by the Server's (Client's) public key in the field of the public key encryption block that is normally associated with a data encryption key or with an OAEP padding seed, and this nonce is used as the encryption key for the Encrypted-Data primitive, and each one contains copy of the message Sender's certificate chain.
  • the benefit of transmitting a nonce in the field normally used for a data encryption key or an OAEP padding seed is that a single cryptographic primitive (e.g., Signed-lnside-Enveloped-Data) can be used for secure session setup and for secure unidirectional messaging and for other secure protocol applications.
  • the Data carried in the first message is a Client-Nonce and the data carried in the second message is the Server-Nonce.
  • An important benefit of this design is that the digitally signed portion of the second message can be pre- computed or even reused with different sessions, and thus the Server does not need to perform a computationally expense private key operation to initiate a secure session.
  • the Client sends to the server a third message and the Server sends to the Client a fourth message, where these two messages can be sent in either order, and they have substantially the same format, contents, and cryptographic processing as each other and as with subsequent data transfer messages, and the Data contents of the third and fourth message include a cryptographic transformation of at least the Client-Nonce and Server-Nonce, where the transformation is slightly different in the third and fourth messages.
  • the cryptographic transformation in the third and fourth messages can be different by exchanging the roles of the Client-Nonce and the Server-Nonce.
  • the cryptographic transformation can be a hash (e.g., MD5, SHA-1 , SHA-256) of the concatenation of the two nonce values.
  • the cryptographic transformation can be an encryption (e.g., triple-DES, XTEA, RC5, AES) of one nonce value using the other nonce value as the key.
  • the third and fourth messages may be created using the Encrypted-Data cryptographic primitive described earlier, where the Encrypted-Data key for the third message is different than the one for the fourth message, and both keys are derived from a Master Key that is computed with the aid of one or more applications of a cryptographic hash function applied to the Client-Nonce and the Server-Nonce and some or all of the information in the previously send or received messages.
  • MK Master Key
  • HMAC Server- Nonce
  • HMAC is a well known cryptographic primitive based on the hash functions, such as the MD5 and/or SHA1 hash functions.
  • the Encrypted-Data key for the third message equals HMAC (MK, Client-Subject- Name), where Client-Subject-Name is one or more fields extracted from the Client's certificate.
  • the Encrypted-Data key for the fourth message equals HMAC (MK, Server-Subject-Name), where Server-Subject-Name is one or more fields extracted from the Server's certificate.
  • the Client and Server then verify the received fourth and third messages respectively to confirm that they have the expected contents and thus were created by an entity that knew both the Client-Nonce and the Server-Nonce.
  • the Client and Server send subsequent data messages that have substantially the same format and cryptographic processing as the third and fourth messages.
  • the Client and Server data messages may be created using the Encrypted-Data cryptographic primitive defined earlier.
  • the protocol does not have (or require) a separate session termination message because it uses the signals termination by closing the underlying network connection (e.g., closes the TCP socket).
  • Some particular embodiments relating to these aspects are highlighted below.
  • a computer program product for use in conjunction with a computer system having a server and a client the computer program product comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism, comprising: a program module that directs the computer system and/or components thereof including at least one or the client or server, to function in a specified manner to provide message communications, the message communications occurring in a computer system hardware architecture neutral and operating system neutral and network transport protocol neutral manner for secure interactive communication sessions, the program module including instructions for: A.
  • the Server-Nonce that was chosen by the Server that is not predictable by the Client and is unlikely to have been previously chosen by the Server; the first message and second message having substantially the same content, format and cryptographic processing; D. exchanging third and fourth messages between the client and the server (client to server message) and the server and the client (server to client message) respectively, where the order that the third and fourth messages are sent and received is not material; the third and fourth messages including a content portion that is substantially the same though not necessarily identical and having substantially the same format and cryptographic processing as each other and as with subsequent data transfer messages; the data contents portions of the third and fourth message include a cryptographic transformation of at least the Client-Nonce and Server-Nonce, where the cryptographic transformation is slightly different in the third and fourth messages; and E. each of the server and client examining the respective received third and fourth messages to confirm that they have the expected contents and thus were created by an entity that knew both the Client-Nonce and the Server-Nonce.
  • a hardware,architecture neutral and operating system neutral and network transport neutral method for secure interactive communication sessions using less software code and network bandwidth than conventional systems comprising: A. sending to a server, by a client, a first message containing a Client-Nonce; B. receiving the first message including the Client-Nonce by the server; C. sending to the client, by the server in response to the received first message and Client- Nonce, a second message containing a copy ofthe Client-Nonce extracted from the first message, and a value in the form of a Server-Nonce that was chosen by the Server that is not predictable by the Client and is unlikely to have been previously chosen by the Server; the first message and second message having substantially the same content, format and cryptographic processing; D.
  • third and fourth messages exchanging third and fourth messages between the client and the server (client to server message) and the server and the client (server to client message) respectively, where the order that the third and fourth messages are sent and received is not material;
  • the third and fourth messages including a content portion that is substantially the same though not necessarily identical and having substantially the same format and cryptographic processing as each other and as with subsequent data transfer messages;
  • the data contents portions of the third and fourth message include a cryptographic transformation of at least the
  • Client-Nonce and Server-Nonce where the cryptographic transformation is slightly different in the third and fourth messages; and E. each of the server and client examining the respective received third and fourth messages to confirm that they have the expected contents and thus were created by an entity that knew both the Client-Nonce and the Server-Nonce.
  • the cryptographic hash is a MD5 based hash, a SHA-1 based hash, or a SHA-256 based hash.
  • the method in embodiment (142), wherein the Client-Nonce and the Server-Nonce have a length of 8 bytes, 10 bytes, 16 bytes, 20 bytes, 24 bytes, 32 bytes, 64 bytes, 96 bytes, or 128 bytes.
  • the first and second messages are created using a Signed- lnside-Enveloped-Data cryptographic primitive;
  • the Client-Nonce is sent to the Server encrypted by the Server's public key in the field of the public key encryption block that is normally associated with a data encryption key or with an OAEP padding seed, and this Client-nonce is used as the encryption key for the Encrypted-Data primitive, and each one contains copy of the message Sender's certificate chain;
  • the Server-Nonce is sent to the Client encrypted by the Client's public key in the field of the public key encryption block that is normally associated with a data encryption key or with an OAEP padding seed, and this Server-nonce is used as the encryption key for the Encrypted-Data primitive, and each one contains copy of the message Sender's certificate chain; and transmission of the Sever-Nonce and
  • Client-Nonce in the field normally used for a data encryption key or an OAEP padding seed enabling a single cryptographic primitive to be used for secure session setup and for secure unidirectional messaging and for other secure protocol applications.
  • MK HMAC (Server-Nonce
  • MK HMAC (Server-Nonce
  • MK HMAC (Server-Nonce
  • MK HMAC (Server-Nonce
  • MK HMAC (Server-Nonce
  • MK HMAC (Server-Nonce
  • MK HMAC (Server-
  • the Encrypted-Data key for the third message equals HMAC (MK, Client-Subject-Name), where a Client-Subject-Name is generated from one or more fields extracted from the Client's certificate; and the Encrypted-Data key for the fourth message equals HMAC (MK, Server-Subject-Name), where Server-Subject-Name is one or more fields extracted from the Server's certificate.
  • a method for conducting secure interactive communication sessions between a server and a client comprising: sending a first message containing a first token chosen by the client; receiving the first message including the first .token .by .the .server; .sending a .second message containing a copy of the first token extracted from the first message, and a second token that was chosen by the server, by the server; exchanging third and fourth messages between the client and the server, the third and fourth messages including a content portion having substantially the same format and cryptographic processing as each other, the contents portions of the third and fourth messages including a cryptographic transformation of at least the first token and second token; and each of the server and client examining the respective received third and fourth messages to confirm that they were created by an entity that knew both the first token and the second token.
  • a computer program product for use in conjunction with a computer system having a server and a client comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism, comprising: a program module that directs the computer system and/or components thereof including at least one of the client or server, to function in a specified manner to conduct secure interactive communication sessions between a server and a client, the communications occurring in a computer system hardware architecture neutral and operating system neutral and network transport protocol neutral manner for secure interactive communication sessions, the program module including instructions for: sending a first message containing a first token chosen by the client; receiving the first message including the first token by the server; sending a second message containing a copy of the first token extracted from the first message, and a second token that was chosen by the server, by the server; exchanging third and fourth messages between the client and the server, the third and fourth messages including a content portion having substantially the same format and cryptographic processing as each other, the contents portions of the third and fourth messages including a cryptographic transformation of at least the
  • the invention provides a hardware architecture neutral and operating system neutral and network transport neutral method for secure unidirectional messaging using less software code and network bandwidth than conventional systems, ln one embodiment, the method includes the following steps and options or variations.
  • the Sender extracts the appropriate public key (e.g. RSA public key) and matching destination address (e.g., e-mail address or URL) of the Recipient from a storage means that is trusted and has been verified previously using a digital signature (e.g., verified with a trusted public key) or cryptographic checksum (e.g., verified with a trusted key derived from a Master Key or Session Key or Message Key).
  • a digital signature e.g., verified with a trusted public key
  • cryptographic checksum e.g., verified with a trusted key derived from a Master Key or Session Key or Message Key
  • the storage means in this or other aspects and embodiments may for example, be a Compact Certificate as explained earlier, or chain of Compact Certificates leading to a trusted root public key.
  • the storage means may also or alternatively be, for example, a previously received story enabled message that was securely received and verified by mechanisms that are trusted for that kind of message.
  • the storage-means- can be a normal e-mail message or web page, which the ' Sender trusts that has been copied into the Sender's computer memory via mechanisms that the Sender trusts.
  • the Sender extracts their own private signing key and certificate chain from a trusted storage means, and then passes that extracted information, and the data of the message along with the Recipient's public enveloping key, and a fresh random data encryption key and fresh random OAEP padding seed to the Signed-lnside-Enveloped-Data cryptographic primitive to construct a secure unidirectional message.
  • the OAEP padding seed and the data encryption key can be the same value to avoid the overhead of generating multiple random values, or may be different values.
  • the Sender's private key and certificate chain may be fixed values shared among many Senders or may differ and be unfixed. These values can be either widely known, or the Sender's software may employ mechanisms to make it difficult to discover these values through a process of reverse engineering.
  • the Recipient receives the message and extracts its own private key from a secure storage means to decrypt the public key encryption, extract the data encryption key, decrypts the data which is digitally signed, and verifies the signature of the data and the certificate chain of the Sender, and all of this is done using the same cryptographic primitive that is used with at least a secure session protocol.
  • a computer program product for use in conjunction with a computer system having a server and a client comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism, comprising: a program module that directs the computer system and/or components thereof including at least one or the client or server, to function in a specified manner to provide message communications, the message communications occurring in a computer system hardware architecture neutral and operating system neutral and network transport protocol neutral manner for secure unidirectional messaging, the program module including instructions for: A. extracting, by the sender, an appropriate public key and matching destination address of a Recipient from a storage means that is trusted and has been verified; B.
  • the method in embodiment (190), wherein the messaging platform is a messaging platform selected from the set consisting of: a computer, a server, a PDA, a telephone, an appliance, an information appliance, a pager, or any other device supporting such messaging.
  • the method in embodiment (182), wherein the OAEP padding seed and the data encryption key are different values.
  • the method in embodiment (182), wherein the OAEP padding seed and the data encryption key are the same value to avoid the overhead of generating multiple random values.
  • the method in embodiment (182), wherein the Sender's private key and certificate chain comprise fixed values shared among a plurality of Senders.
  • the method in embodiment (182), wherein the Sender's private key and certificate chain fixed values are widely known.
  • the method in embodiment (182), wherein the Sender's private key and certificate chain fixed values are not widely known and the Sender's software employs mechanisms to make it difficult to discover these values through a process of reverse engineering.
  • a method for secure unidirectional messaging from a sender to a recipient comprising: obtaining, by the sender, a public key and destination address of a message recipient and the sender's own private signing key and certificate chain from one or more trusted source; passing, by the sender, the extracted public key and matching destination address and private signing key and certificate chain information, and the data of an intended message along with the recipient's public enveloping key and a random data encryption key and random padding seed to a cryptographic primitive; and constructing, by the sender, a secure unidirectional message there from.
  • the method of embodiment (197) further comprising: sending, by the sender, the constructed
  • the method of embodiment (198) further comprising: receiving the secure unidirectional message by the recipient; extracting, by the Recipient, the recipient's own private key from a secure source and decrypting the public key encryption, and the data encryption key and decrypting the data which is digitally signed; and verifying the signature of the data and the certificate chain of the sender.
  • the message is an e-mail message.
  • the trusted source or storage means comprises a Compact Certificate as explained earlier, or chain of Compact Certificates leading to a trusted root public key.
  • the invention provides a hardware architecture neutral and operating system neutral and network transport neutral method for secure certificate issuing using less software code and network bandwidth than conventional systems.
  • this method includes the following steps with options and variations.
  • the Client (or other entity), which is requesting a certificate, extracts a network address (e.g., URL) for the Issuer from a trusted storage means.
  • the trusted storage means can be data compiled into the Client software, or the trusted storage means can be data received from communicating with a Server via a secure session.
  • the Client extracts a Resource Tag (e.g., message tag) related to its own Subject Name (e.g., e-mail address) from a message that was received from a Server.
  • a Resource Tag e.g., message tag
  • Subject Name e.g., e-mail address
  • the Client then extracts a fixed public and private key and certificate chain from a trusted storage means and uses that information along with the previously extract network address to create a secure session with the Issuer.
  • the secure session authenticates the issuer using the same protocol as described elsewhere in this specification.
  • the public and private key operations may for example, be performed by any asymmetric cryptosystems such as RSA, Elliptic Curve, or NTRU.
  • the Client sends, as its first Data message (after the session setup messages, if any) structure that has a common header with fields for Type, Version and Content-Length, and the contents include the Resource Tag, the Client's Subject Name, and optionally one or more public keys that the Client has generated.
  • the Issuer verifies that a valid Server issued the Resource Tag and that the tag is valid for the given received Subject Name.
  • the Issuer creates a Compact Certificate with one or more public keys and with the Client's Subject Name and digitally signs the certificate with the Issuer's private key, where the public key(s) could be generated by the Issuer or sent to the Issuer by the Client who generated them.
  • the Issuer sends a message back to the Client over the secure channel where the message includes the Compact Certificate and if the Issuer generated the public key(s), the message includes the matching private key(s).
  • the Client places the Compact Certificate and keys into a trusted storage means for later use.
  • a computer program product for use in conjunction with a computer system having a server and a client comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism, comprising: a program module that directs the computer system and/or components thereof including at least one or the client or server, to function in a specified manner to provide message communications, the message communications occurring in a computer system hardware architecture neutral and operating system neutral and network transport protocol neutral manner for secure certificate issuing by an Issuer to a Client requesting the certificate, the program module including instructions for: A. extracting, by a certificate requesting client, a network address for the Issuer from a trusted source or storage means; B.
  • a hardware architecture neutral and operating system neutral and network transport neutral method for secure certificate issuing by an Issuer to a Client requesting the certificate using less software code and network bandwidth than conventional systems, the method comprising the steps of: A. extracting, by a certificate requesting client, a network address for the Issuer from a trusted source or storage means; B.
  • a method for secure certificate issuing by an issuer to an entity requesting the certificate, the method comprising: extracting, by the entity, a network address for the certificate issuer from a trusted source; extracting, by the entity, information including a resource tag related to its own subject name from a message that was received from a server, and a public key and a private key and certificate chain from a trusted source; using, by the entity, the extracted information to create a secure session with
  • the invention provides a hardware architecture neutral and operating system neutral and network transport neutral method for secure response session using less software code and network bandwidth than conventional systems.
  • this method includes the following steps with options and variations.
  • the Client who is establishing a secure response session to the Merchant in order to respond to a message from the Merchant, extracts the Merchant's public key (e.g. RSA public key) and matching destination address (e.g., URL) of the Merchant from a trusted storage means that has been verified previously using a digital signature (verified with a trusted public key) or cryptographic checksum (verified with a trusted key derived from a Master Key or Session Key or Message Key).
  • a digital signature verified with a trusted public key
  • cryptographic checksum verified with a trusted key derived from a Master Key or Session Key or Message Key
  • the trusted storage means can, for example, be data from a normal e-mail message or a non- secured web page, or a secured web page (e.g., secured by SSL, PCT, or TLS). Also or alternatively, the trusted storage means can be data received from communicating with a Server via a secure session. Next, the Client extracts its public and private key and certificate chain from a trusted storage means and uses that information along with the previously extract destination address to create a secure session with the Merchant using the previously explained secure session protocol, and the Client's first Data message, which is sent after the session setup messages, contains a Resource Tag that was included in the message received from the Merchant to which this session is a response.
  • the Client's keys and certificate chain may be fixed values shared by more than one Client system, in which case, the Merchant will authenticate the Client based on this Resource Tag.
  • the Client's keys and certificate chain can be unique to this Client, and the Merchant can authenticate tfie Client using this unique certificate and/or using a Resource Tag was included in the message received from the Merchant to which this session is a response.
  • After the Merchant has performed the session setup portion of the secure session protocol it verifies the Client's certificate chain and verifies the Resource Tag that is received in the first Data message from the Client.
  • the Client and Merchant optionally exchange additional data related to the application that is using this secure response protocol.
  • either the Client or the Merchant can terminate the session by closing the underlying network connection (e.g., TCP socket) so that a separate session termination is not required.
  • a computer program product for use in conjunction with a computer system having a server and a client comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism, comprising: a program module that directs the computer system and/or components thereof including at least one or the client or server, to function in a specified manner to provide message communications, the message communications occurring in a computer system hardware architecture neutral and operating system neutral and network transport protocol neutral manner for conducting a secure response session, the program module including instructions for: A. extracting, by a Client who is establishing a secure response session to a Entity in order to respond to a message from the Entity, the Entity's public key and matching destination address of the Entity from a trusted source or storage means; B.
  • a hardware architecture neutral and operating system neutral and network transport neutral method for secure response session using less software code and network bandwidth than conventional systems comprising the steps of: A. extracting, by a Client who is establishing a secure response session to a Entity in order to respond to a message from the .Entity, the Entity's public key and matching destination address ofthe Entity from a trusted source or storage means; B. extracting, by the Client, the Client's public and private key and certificate chain from a trusted source or storage means; C. using the extracted client public and private key and certificate chain information along with the previously extracted Entity destination address to create a secure session with the Entity using a secure session protocol; D.
  • the matching destination address comprises a URL or URL based address.
  • the trusted source or storage means comprises data selected from the set consisting of a normal conventional e-mail message, a non-secured web page, a secured web page, and combinations thereof.
  • the method in embodiment (230), wherein the trusted storage means comprises data received from communicating with a Server via a secure session.
  • a method for conducting a secure les ⁇ uuse session from a Client that is establishing a secure response session to an Entity in order to respond to a message from the Entity comprising the steps of: extracting, by the Client, information including the Entity's public key and destination address and Client's public and private key and certificate chain from one or more trusted source; using, by the Client, the extracted information to create a secure session with the Entity using a secure session protocol; and sending, by the Client, a first data message that contains a resource tag that was included in the message received from the Entity to which this Client initiated session is a response.
  • a computer program product for use in conjunction with a computer system comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism, comprising: a program module that directs the computer system and/or components thereof, to function in a specified manner to conduct a secure response session from a Client that is establishing a secure response session to an Entity in order to respond to a message from the Entity and occurring in a computer system hardware architecture neutral and operating system neutral and network transport protocol neutral manner for conducting a secure response session, the program module including instructions for: extracting, by the Client, information including the Entity's public key and destination address and Client's public and private key and certificate chain from one or more trusted source; using, by the Client, the extracted information to create a secure session with the Entity using a secure session protocol; and sending, by the Client, a first data message that contains a resource tag that was included in the message received from the Entity to which this Client initiated session is a response.
  • the invention provides a hardware architecture neutral and operating system neutral and network- transport neutral method for secure unidirectional response message using less software code and network bandwidth than conventional systems.
  • this method includes the following steps with options and variations.
  • the Client who is sending a secure response message to the Merchant (or other entity) in order to respond to a message ⁇ from the Merchant, such as a promotional offer, extracts the Merchant's public key (e.g. RSA public key) and matching destination address (e.g., e-mail address) of the Merchant from a trusted storage means that has been verified previously using a digital signature (verified with a trusted public key) or cryptographic checksum (verified with a trusted key derived from a Master Key or
  • a digital signature verified with a trusted public key
  • cryptographic checksum verified with a trusted key derived from a Master Key
  • the trusted storage means can be data from a normal e-mail message or a non- secured web page, or a secured web page (e.g., secured by SSL, PCT, or TLS). Also, or alternatively, the trusted storage means can be data received from communicating with a Server via a secure session.
  • the Client then extracts its public and private key and certificate chain from a trusted storage means and uses that information along with the previously extracted destination address to create a secure unidirectional message to the Merchant using the previously explained secure unidirectional message protocol (e.g., using the Signed-lnside-Enveloped-Data cryptographic primitive), and the Data portion ofthe Client's message contains a Resource Tag that was included in the message received from the Merchant to which this message is a response.
  • the Client's keys and certificate chain can be fixed values shared by more than one Client system, in- which -case, the Merchant will authenticate the Client based on this Resource Tag.
  • the Client's keys and certificate chain can be unique to this client, and the Merchant can authenticate the Client using this unique certificate and/or using a Resource Tag was included in the message received from the Merchant to which this session is a response.
  • the Merchant verifies the Client's certificate chain and verifies the Resource Tag that is included in the Data portion of the received message. Finally, the Merchant performs an appropriate application-level action for the received response message.
  • a computer program product for use in conjunction with a computer system having a server and a client comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism, comprising: a program module that directs the computer system and/or components thereof including at least one or the client or server, to function in a specified manner to provide message communications, the message communications occurring in a computer system hardware architecture neutral and operating system neutral and network transport protocol neutral manner for secure unidirectional response message, the program module including instructions for: A.
  • Extracting by a Client who is sending a secure response message to the Entity in order to respond to a message from the Entity, the Entity's public key and matching destination address of the Entity from a trusted storage means; B. extracting, by the Client, the Client's public and private key and certificate chain from a trusted source or storage means; C. using, the extracted Client's public and private key and certificate chain information along with the previously extracted Entity's destination address to create a secure unidirectional message to the Entity using the a secure unidirectional message protocol, a data portion of the Client's message containing a Resource Tag that was included in the message received from the Entity to which this message is a response; and D. verifying, by the Entity, the Client's certificate chain.
  • a hardware architecture neutral and operating system neutral and network transport neutral method for secure unidirectional response message using less software code and network bandwidth than conventional systems comprising the steps of: A. extracting, by a Client who is sending a secure response message to the Entity in order to respond to a message from the Entity, the Entity's public key and matching destination address of the Entity from a trusted storage means; B. extracting, by the Client, the Client's public and private key and certificate chain from a trusted source or storage means; C.
  • the matching destination address comprises an e-mail address.
  • the method in embodiment (252), wherein the public key and matching destination address have been verified previously using a digital signature (verified with a trusted public key) or cryptographic checksum (verified with a trusted key derived from a Master Key or Session Key or Message Key).
  • the method in embodiment (252), wherein the trusted source or storage means comprises data from a normal e-mail message, a non-secured web age, or.a secured web page, or combination thereof.
  • the web page is secured by one of the set consisting or SSL, PCT, or TLS.
  • the trusted source or storage means comprises data received from communicating with a Server via a secure session.
  • the Client's keys and certificate chain are fixed values shared by more than one Client system, and the Entity authenticates the Client based on this Resource Tag.
  • a method for communicating a secure unidirectional response message from a Client that is sending a secure response message to the Entity in order to respond to a message from the Entity comprising the steps of: extracting, by the Client, information including the Entity's public key and matching destination address and the Client's public and private key and certificate chain from one or more trusted source; and using, by the Client, the extracted information to create a secure unidirectional message to the Entity using the a secure unidirectional message protocol, a data portion of the secure unidirectional message containing a resource tag that was included in the message received from the Entity to which the secure unidirectional message is a response.
  • the method in embodiment (266) further comprising sending the secure unidirectional message to the entity.
  • a story as the term is used in this description generally refers to a single, author once, play everywhere file or data/command structure that is interactive either on-line or off-line and that can be used to distribute rich multimedia messages or other rich-media content to all e-mail enabled clients.
  • “stories” are described elsewhere in the detailed description.
  • e-mail is used here because it represents a form of electronic communication that is known in the art, but it will be appreciated that the inventive system, method, software, business and operating model pertain to much more than what is normally envisioned for conventional e-mail systems and methodologies.
  • inventive e-mail enhancement, extension, or replacement contemplates some generalized electronic content that is directed to one, a plurality, or a multitude of recipients.
  • a story is a single, author once, play everywhere file or data/command structure that is interactive either on-line or off-line that can be used to distribute rich multimedia messages or other rich-media content to all e-mail enabled clients.
  • stories can be used to distribute and coordinate e-commerce transactions, order fulfillment, meeting scheduling, advertisements, catalog item descriptions, customized catalogs and brochures, holiday greeting cards, electronic storybooks, driving directions, vacation slide and picture shows, surveys, real-estate walk throughs, medical care pamphlets, pharmaceutical information pamphlets, recipes, business presentations, party invitations, instructional manuals, entertainment, and numerous other applications, particularly where the message consists of more than merely a text or symbolic message.
  • exemplary applications include, for example, surveys, forms, contracts.
  • Story content creation is advantageously automated and dynamically adaptive, because a story is optimized over a plurality of variables to selectively communicate elements of an e-mail message to e- mail client devices and users.
  • variables include, for example, client device hardware capabilities, network connection characteristics and user preferences. This is accomplished from a standpoint, for example, of CPU speed, display type, screen size, the existence of and or attributes of audio and/or video capabilities, data scalability, language, use of or not use of audio or visual content, nominal speed or bandwidth of all of the communication links and protocols, and the like.
  • a nnal story is not generated until substantially all such relevant e-mail client information is determined during the time of connection of the client device.
  • the system and procedure of the present invention is contrary to other prevailing trends (which attempt to pre-form content so that is available as early as possible) in that StoryMail actually delays composition ofthe final message until it is ready to be received. For example, if it is determined that an e-mail client cannot view motion video but can display text and play audio, the story will be generated such that it does not include motion video, but rather textual and/or audio elements that communicate the intent of the e-mail publisher within the capabilities of the e-mail client.
  • a client device may be capable of receiving and rendering a very rich message
  • the then prevailing communication channel is only supporting low-speed or low- bandwidth communication
  • a story is generated such that the richness .of .the. message .is reduced so that the message is optimized for the attributes of the client device and the user preferences at that moment in time.
  • the message may be optimized or nearly optimized to be received within any time constraints that may be imposed; however, unlike systems and methods that must satisfy real-time or near real time constraints, the story need not provide real-time delivery, as it is intended to be a messaging and communication system, method, and operating model, rather than a real-time rich-media broadcast or streaming system.
  • a story is a fully aware e-mail message that is optimized to substantially deliver the intent of an e-mail publisher across the broad range of all e-mail client architectures.
  • a story may further be optimized to comply with a predefined set of user defined preferences, making each story beneficially configurable for physically challenged individuals. This is because for every logical element (either text, sound, images, video, or the like logical elements) there is an underlying textual description of that logical element.
  • logical element either text, sound, images, video, or the like logical elements
  • contextual logical elements included as may be needed to insure that the intent of the message may be easily understood in text or audio only representations.
  • An example of such contextual logical element would be a text element that provides an overview of what is on the screen to be rendered as text or audio in cases where some or all of the screen's visual elements can not be seen by the recipient on the receiving device.
  • all logical elements have corresponding semantic information so that it can be known or determined which elements to use under varying circumstances.
  • the aforementioned contextual logical text element would have associated semantic flags packaged with it inside a story indicating that the element contains text providing an overview of the elements displayed on a screen for use when it is known that the recipient cannot view the screen.
  • an audio representation either recorded or generated by a text to speech engine may provide audio information backup - contextual information, or semantic information rather than text.
  • the inventive system, method, and operating model are designed to interface with a peripheral device that generates a Braille or other tactilely sensible indica corresponding to the story.
  • This peripheral device may either be linked to a conventional client device, such as a computer, or integrated within the device. Using semantics, there is always an alternative sensory presentation mode.
  • stories are self contained and lightweight, meaning that stories have relatively small memory and processor requirements and can be played on client devices the types and sophistication of which are virtually unlimited.
  • a story is self contained because in at least one embodiment, a story is actually a single file that is made up of a number of component logical files.
  • Each component file encapsulates, for example, one or more of computer program instructions, control information, user input forms, validation procedures, and/or multimedia content.
  • Each component logical file is respectively compressed and all of the component logical files are combined, packaged, compressed again to generate the single story file.
  • a story - is lightweight not-only because when it is executed, or played, a story's contents are selectively and sequentially decompressed. But also because a story only includes those elements that are optimized and compatible with the e-mail client's hardware capabilities and network connection characteristics, making stories lightweight (thin) enough to run on inexpensive information appliances or other devices.
  • one of the great advantages of the StoryMail system is its ability to support the hardware capabilities and network connection characteristics of virtually any client device.
  • a story can even be played on a client device that is not multimedia enabled because a story always has a set of text that describes, or narrates any non-textual element of the story.
  • the story also contains semantic flags indicating the circumstances under which to render all text or non-textual elements.
  • a story according to embodiments of the invention is reliable because it is played in a novel run-time environment, wherein, unlike an HTML Web page where there may be links to other servers to provide further information, a story is a self-contained unit.
  • the novel run-time environment is largely deterministic because of the self contained cooperative multitasking system employed in the playback engine and the explicit input buffer coding instructions with fixed size memory buffers. So if it runs correctly one time on one device it will almost certainly run correctly most of the time on all devices.
  • a run-time environment such as this is more reliable than, for example a pre-emptive multitasking system using the device's threading mechanism, or an architecture which allows for variable size buffering. Also in story messaging all content is present on the target device before the story is run.
  • Most story enabled devices will run or play a story in a window, or in a non-windowed operating environment such as occur on in basic or thin client devices, on a display device screen.
  • Such devices include, for example, a desktop computer, notebook computer, personal data assistant (PDAs), telephone, set-top box, movie marquee, informational kiosk, Internet e-mail appliances, billboard, microwave oven, point-of-sale displays, gasoline pump, vending machine, instructional appliance, automobile display device, global positioning system (GPS), point-of-sale display, and myriad of other device types are supported.
  • a story can even be played on a client device that is not multimedia enabled because preferred embodiments of the inventive story always have a set of text that describes, or narrates any non-textual element of the story, along with semantic information describing the role of each logical element.
  • a device may play a story entirely with voice commands and automatically articulated responses. It is noted that although applicant describes embodiments of the inventive structure, method, computer program, operating model, and structure and organization of content used in or in conjunction with other aspects of the invention, the underlying inventive concept and indeed many embodiments of the invention do not require all features described here. Many such structures and procedures though advantageous and desirable are optional. Including text behind each logical element of the story is a preferred embodiment. Therefore, with respect to the structure and content of a story described here, it should be understood for example, that not all stories must contain underlying text .behind each logical element of the story.
  • a story maintains a focus on the intent of the message and preserves that message intent in spite of its ability to selectively communicate elements to client devices and users.
  • the primary goal has been to maintain real-time transmission of the video stream and to relax quality to the point where almost all picture quality has been lost if necessary to maintain continuous operation.
  • a high-end product such as example a diamond ring
  • a story message provides rich product descriptions complete with BID forms; bid limit exceed notifications providing a bidder a chance to upgrade a bid from a form embedded in the message without requiring the bidder to go to the action web site; and, bid accepted notification with transaction completion automation.
  • on-line auctions require composing a product description that may not scale up and down depending on the device.
  • Traditional on-line auctions typically require repeated visits the site to determine if a bid is accepted.
  • traditional on-line auctions generally require further visits to a
  • stories can be used at point of sale to provide looping demonstrations and/or advertisements of a product.
  • a story can be embedded in read-only-memory (ROM) of microwaves, stereos, set top boxes, and the like.
  • Playback of such a story can be in the store that displays the story 180 enabled product for sale.
  • the manner in which the story is played back may be modified by each viewer according to view preferences.
  • the underlying content may have English, French, Spanish, and Russian audio and text content that may be selected by the viewer.
  • Such input may be buttons on the playback device, a touch screen device, voice input, or other input devices as are known in the art.
  • story enabled devices for example, soda machines
  • story enabled devices can be implemented to play media rich advertisement stories that can be updated using only a phone line to upload a different story.
  • the content of such story may be communicated, for example overnight to a large variety of different device types, yet will be playable by all such device types.
  • stories can also be used for meeting scheduling, advertising, catalog item descriptions, holiday greeting cards, electronic storybooks, driving directions, vacation slide and picture shows, surveys, real-estate walk throughs, medical care pamphlets, pharmaceutical information pamphlets, cooking or production recipes, business presentations, instructional manuals, entertainment, and numerous other applications where the message consists of more than merely the text message.
  • StoryMail System 300 (also referred to simply as system 300) is a distributed client/server system with server peering.
  • Sender/publisher 310 is connected across I/O interface 312 to user interface 314.
  • Sender/publisher 310 can be a general-purpose computer, provides at least a subset of the information and content used to generate and transmit a story to sending story server 302. In other words, parts of a story may reside on any server anywhere or computer that can be addressed, that is connected to network 306.
  • sender/publisher 310 provides links, for example, a Uniform
  • Sender/publisher 310 includes a number of components which are described in greater detail below in reference to FIG. 2.
  • I/O interface 312 can be any type of I/O interface, for example, a peripheral component interconnect (PCI) bus interface, a SCSI interface, or the like.
  • Sender/publisher 310 is also connected across I/O interface 308 to network 306.
  • I/O interfaces 308 and 309 can be used if information is passed through network 306.
  • I/O interfaces 308 and 309 can be any type of I/O interface, for example, a modem connected to a public telephone network, a leased line, or a wireless radio wave or optical interface.
  • Network 306, for example, can be a local area network (LAN) or a wide area network (WAN).
  • Network 306 is connected across I/O interface 304 to sending story server 302.
  • Sending story server 302 for example, is a general-purpose computer or device for generating and transmitting stories to client devices, such as conventional e-mail server 332, story enabled client 336, conventional e-mail client 340, and story enabled device 344.
  • client devices such as conventional e-mail server 332, story enabled client 336, conventional e-mail client 340, and story enabled device 344.
  • I/O interfaces 304, 308, 309, 324, 326, 330, 334, 338, and 342 can be any type of I/O interface, for example, a modem connected to a public telephone network, a leased line, or a wireless radio wave interface.
  • the system of the invention includes receiving story server 328, for example, is a general-purpose computer or device for transmitting stories to client devices, such as those client devices listed above.
  • receiving story server 328 is a general-purpose computer or device for transmitting stories to client devices, such as those client devices listed above.
  • sending story server 302 is able to generate stories and distribute stories
  • receiving story server 328 is not able to generate stories but is able to distribute already generated stories.
  • Receiving story server 328 is beneficial because it may contain functionality which can be used to eliminate the need for providing that same functionality in story enabled clients 336 and story enabled devices 344. This is advantageous because the computation and/or memory capacity of such devices is normally more limited than that of the servers 328.
  • the implementation costs are lower if the functionality is contained on the servers 328 rather than on the story enabled clients 336 and story enabled devices 344. Examples of such functionality include proxy server functions, placing stories into in-boxes, and security features such as decryption, authentication and digital signature verification.
  • network 306 is connected to conventional e-mail server 332 which is a traditional e-mail server used by a number of machines connected to network 306 to distribute and collect e-mail messages. Procedures for a machine to distribute and collect e-mail messages are known in the art.
  • Conventional e-mail server 332 provides story messages to both .non-story enabled devices, for example, conventional e-mail client 340, as well as story enabled clients and devices, for example, story enabled client 336 and story enabled device 344. As will be described in greater detail below, the presence of conventional e-mail server 332 is not necessary for story enabled client 336 or story enabled device 344 to receive stories.
  • Story enabled client 336 includes, for example, computer program applications and data for playing a story received from a story server, for example, sending story server 302 and/or receiving story server 328.
  • Story enabled client 336 is, for example, a general-purpose computer, a notebook computer, a personal digital assistant, a telephone, a set-top box, an Internet e-mail appliance, a movie marquee, an informational kiosk, a billboard, a gasoline pump, a vending machine, an instructional appliance, an automobile display device, a GPS system, a point-of-sale display, and the like.
  • Story enabled client 336 starts life as a conventional email client 340. It becomes story email client 336 when story enabling software is downloaded or installed from a network or direct connection to another device.
  • Story device 344 has the story enabling software built in by the manufacturer.
  • Conventional e-mail client 340 is a typical e-mail client, for example, a general-purpose computer that is not able to execute, or play a story.
  • conventional e-mail client 340 is able to receive e-mail messages that include information indicating that a richer content message, or story is behind the e-mail message.
  • the e-mail also includes, for example, an e-mail message that delivers the publisher's 310 message in a traditional e-mail format.
  • Such traditional e-mail formats include, for example, text, HTML and/or attachments. Such an embodiment is advantageous for a number of reasons.
  • conventional e-mail client 340 will not be able to play a story without upgrading its computer program applications, it will still receive content that corresponds to publisher's 310 message or promotion. Additionally, the message can be forwarded to another e-mail client device, for example, story enabled client 336, wherein the richer message will be available to the other client device.
  • conventional e-mail client 340 upgrades its capabilities to enable it to play a story. In a situation where conventional e-mail client 340 upgrades its computer program applications to enable it to play a story, conventional e-mail client 340 would become a story enabled client 336.
  • conventional e-mail client 340 can perform such upgrades, for example, by 85 downloading a story player from a web site or an FTP site, or by loading a story player from a CD-ROM or diskette.
  • conventional email client 340 upgrades by responding to a link provided in the email message, wherein the link points to a download image or site.
  • Story enabled device 344 is manufactured with story functionality built in. Such devices include networked household appliances, cell phones, smart cards and pagers.
  • Each client device 336, 340, and 344 includes, for example, an e-mail program (not shown) that respectively receives and/or delivers e-mail respectively from/to one machine connected to network 306 from/to another machine connected to network 306.
  • an email program utilizes Internet email protocols, for example, known POP3 or IMAP protocols.
  • such an e-mail program is a conventional e-mail program, such as Microsoft Outlook Express®.
  • the e-mail program is a special e-mail program designed specifically to receive and/or transmit stories to another client or device across network 306.
  • Sender/publisher 310 includes processor 142 connected across local bus 144 to memory 146.
  • Processor 142 is used to execute computer program applications 148 and fetch data 150 from memory 146.
  • Local bus 144 can be any type of bus, for example a peripheral component interconnect (PCI) bus, as long as local bus 144 has a set of signal lines that can be used by processor 142 to transfer information respectively to and from memory 146.
  • PCI peripheral component interconnect
  • Data 150 includes, for example, database 152 representing any combinations of textual information, motion video, audio, forms, automation scripts, a story recipient list and any other message content, communication, or the like, that may be sent in an electronic format.
  • a form can be any type of form or document, for example, a purchase order form, a registration or an application form. Typically' a form provides an inquiry and provides some instructions for answering or responding to the inquiry.
  • Database 152 is a standard database that can be created and managed using any of a number of conventional database tools.
  • database 152 includes, for example, textual descriptions in more than one language of a number of products, digital or binary images of the products, motion videos to advertise and illustrate the products, product identification numbers, audio clips to advertise and describe the products, and/or recipient information, such as a list of e-mail addresses to which to send a story.
  • a textual description of that item of data is available. For example, if database 152 includes a color photo of a particular toy, there will be a corresponding text description of that toy.
  • a digital or binary image can have a set of scaled and color depth versions of the binary image.
  • database 152 includes a 300 dots per inch (dpi) 24-bit color binary image of the cover of a book
  • database 152 will also include a 1 -bit black and white representation of the image, an 8-bit and 16-bit gray scale representation of the image, and various resolutions of each of the resolutions, such as 100 bit and 200 bit resolutions.
  • scaling of logical story elements can occur at three different times: (1) when generating the message; (2) when executing the procedural elements of the message; and, (3) while the message elements are being rendered by the hardware specific functions (e.g., the HAL functions) that connect a portable story playback engine to actual device specific hardware.
  • sending story server (see FIG. 1) scales the story content when generating the message to conform to the story enabled clients' 336 hardware capabilities, network connection characteristics, and specified user preferences at the time that such information are determined (see FIG. 7, step 228).
  • story player 194 (see FIG. 5) scales the content of the story when the procedural elements of the story are executed, or played.
  • a digital image may be scaled from 300 dpi to 200 dpi while the digital image is being displayed.
  • story player's 194 HAL may scale the story to fit into a particular display screen size and/or add scroll bars to the display so that an entire story can be viewed.
  • Document 154 is author once information created by using a number of structured document languages, for example, extensible markup language (XML), and Excel spreadsheet format, database records extracted with SQL, and alike.
  • XML extensible markup language
  • Excel spreadsheet format database records extracted with SQL, and alike.
  • .Document .154 is an XML document.
  • Document 154 can be created in a number of different ways.
  • Document 154 can be created using any of a number of known XML Editors, Word processors, device drivers, and the like.
  • FIG. 3 there is a block diagram that illustrates aspects of an exemplary Document 154 used by sending story server 302 (see FIG. 1) to generate a message/promotional story 180, according to one embodiment of the invention.
  • FIG. 3 uses a structured document syntax pseudocode that does not conform to any one particular structured document syntax, but is rather used only for purposes of illustrating the invention.
  • XML document 154 includes a tag that identifies a particular storyteller 172 (see FIG. 4) and a unique identifying attribute of the particular storyteller 172.
  • the property can be either an absolute description string, an embedded document, or a string that includes a URL and a document name. If a descriptive property is a URL and document name, the URL will be accessed and the identified document downloaded when document 154 is parsed by story server 302 (see FIG. 4) during one time processing of document 154, as described in greater detail below in reference to FIG. 4.
  • Line 400 includes a tag that identifies a "STORYTELLER ID” element, which is followed by an attribute ofthe element, "ecoupon 5".
  • "Ecoupon 5" identifies a unique storyteller 172 (see FIG. 4) in story server 302 (see FIG. 1).
  • ecoupon 5 storyteller 172 will be used to generate a form and a user interface to be used by a sender/publisher 310 (see FIG. 1) to generate and distribute one or more ecoupon stories 180 (see FIG. 4) to distribute to one or more customers as dictated by sender/publisher 310 (see FIG. 1).
  • Storytellers 172 are described in greater detail below in reference to FIG. 4.
  • Line 402 includes a tag that identifies a "PRODUCT VIDEO" element, which is followed by an attribute of the element that identifies a particular MPEG motion video,
  • the motion video is identified by a URL link to the author's database 152 (see FIG. 4).
  • Lines 404 and 406 include tags that identify respective product picture elements, wherein each respective tag identifies a specific binary image (or other digital image or graphic) that has a respective different pixel resolution.
  • line 404 includes a tag that identifies a "PRODUCT PICTURE
  • 100DPI element, which is followed by an attribute of the element that identifies a 100 dpi binary image
  • line 406 includes a tag that identifies a "PRODUCT PICTURE 200DPI” element, which is followed by an attribute of the element that identifies a 200 dpi binary image, "BOOKRETAILER.COM ⁇ PROMO24 ⁇ ISBNL2980 200DPI.JPG".
  • Both binary image files are identified by respective URL links to the author's database 152 (see FIG. 2) and a corresponding JPEG document.
  • Lines 408 and 410 include tags that identify respective audio file elements, wherein each respective tag identifies a specific audio file that is implemented in a different language.
  • line 408 includes a tag that identifies a "PRODUCT AUDIO ENGLISH” element, which is followed by an attribute of the element that identifies an audio file that is implemented in English (“BOOKRETAILER.COM ⁇ PROMO24 ⁇ ISBNL2980 ENG.WAV").
  • line 410 includes a tag that identifies a "PRODUCT AUDIO SPANISH” element, which is followed by an attribute of the element that identifies an audio file that is implemented in Spanish (“BOOKRETAIJ.ER.COJVl ⁇ PRO.MO24MSBNL2980 SPAN.WAV"). Both audio files are identified by respective URL links to the author's database 152 (see FIG. 2) and a corresponding WAV document.
  • Lines 412 through 418 include tags that identify respective text file elements, wherein each respective tag identifies a specific text file with analogous intent written in a different language.
  • line 412 includes a tag that identifies a "PRODUCT TEXT ENGLISH" element, which is followed by an attribute of the element that identifies an ASCII text file that is implemented in English ("BOOKRETAILER.COM ⁇ PROMO24 ⁇ ISBNL2980 ENG.TXT").
  • line 414 includes a tag that identifies a "PRODUCT TEXT MANDARIN” element, which is followed by an attribute of the element that identifies a Unicode text file that is written in Mandarin ("BOOKRETAILER.COM ⁇ PROMO24 ⁇ ISBNL2980 MANDARIN. UNI") and the like.
  • Each text file of these examples is identified by respective URL links to the authors database 152 and a corresponding text or Unicode document.
  • Line 420 includes a tag that identifies a respective "PRODUCT SKU” (stocking unit) number element, which is followed by an attribute of the element, in particular an absolute value that identifies the promotion's targeted product's SKU.
  • Line 422 includes a tag that identifies a respective "FULFILLMENT SERVER URL” element, which is followed by an attribute of the element, in particular a URL for the promotion's fulfillment server. A procedure for using such a fulfillment server is described in greater detail below in reference to FIG. 7.
  • Lines 424 - 428 includes tags that identify story 180 (see FIG. 4) recipient or customer information.
  • Line 424 includes a tag that identifies a "FIRST NAME” element, which is followed by an attribute of the element, in particular, the name "DAVE”.
  • Line 426 includes a tag that identifies an "EMAIL. ADDRESS” element, which is followed by an attribute of the element, in particular an e-mail address, such as for example to "someone @ somewhere . com” that identifies the recipient's e-mail address, and the like.
  • Line 430 includes a tag that identifies a respective "MASTERDATABASE ID" that is used by sending story server 302 (see F'G. 1) to identify those portions of a master parts database to use for a particular message/promotion.
  • sending story server 302 returns the message/promotion ID 430 to sender/publisher 310 (see FIG. 1), such that the message/promotion ID 430 is unique to any other message/promotion IDs in a master parts database.
  • Such a message/promotion ID can be used by publisher 310 to modify and/or delete the information that corresponds to a message/promotion in a corresponding master parts database.
  • Such a master parts database is described in greater detail below in reference to FIG. 4.
  • such a message/promotion ID is used by publisher 310 to send a corresponding message/promotion to recipients in batches, each batch job referencing the message/promotion ID.
  • document 154 can include any number of user defined elements and respective attributes of such defined elements.
  • recipient information for example, that information illustrated in lines 424-428, can be supplied to sending story server 302 (see FIG. 1 and FIG.4) at any time through a number of different mechanisms.
  • a textual description of that non-textual data is identified in Document 154.
  • Document 154 identifies an audio file in a -particular language
  • Document 154 also identifies other audio files that have analogous content to the audio file in different languages. It may also provide a textual transcription and/or a summary of the audio files for presentation when the receiving device does not provide audio playback or the recipient chooses not to receive the content in an audio format.
  • document 154 if document 154 includes a binary image (either embedded or via a URL) having a particular resolution, document 154 also includes other resolutions of the binary image. Including such multiple resolutions of a binary image is beneficial for the reasons discussed in greater detail above. Furthermore, not only may the binary or digital images be different resolution, they may be different types of files, such as for example, a bit-mapped image ( * .bmp), a TIFF format image (*.tif), a JPEG compressed image (*.jpg), or the like.
  • Applications 148 includes, for example, one or more of the following computer program applications: (a) a Web browser (not shown) such as Netscape Navigator® or Microsoft Internet Explorer®, for accessing a Web page served from sending story server 302; (b) any of a number of commercially available XML Editors for creating document 154.
  • Other applications may also be stored or provided, for example, multimedia authoring systems, story mail applications, templates for other applications such as spreadsheets, multimedia and/or XML database managers.
  • Sender/publisher 310 also includes, for example, a database stored or referenced which includes at least a subset ofthe content necessary to represent the information and data in a story.
  • Server 302 includes processor 162 connected across local bus 164 to memory 166.
  • Processor 162 is used to execute computer program applications 168 and fetch information from data 170.
  • Local bus 164 can be any type of bus, for example, a peripheral component interconnect (PCI) bus, as long as local bus 164 has a set of signal lines that can be used by processor 162 to transfer information respectfully to and from memory 166.
  • PCI peripheral component interconnect
  • each server 302 and 328 will respectively communicate directly with another respective server 302 and 328, or with one or more conventional e-mail servers 332 (see FIG. 1) using one or more communication protocols, for example, SMTP/ESMTP/MIME/HTTP communication protocols. (For purposes of this description, wherever SMTP is used, ESMTP is also applicable).
  • sender/publisher 310 (see FIG. 1) sen ⁇ s document 154 across I/O interface 308 to server 302. (The contents of document 154 are described in greater detail above).
  • sending story server 302 also serves one or more documents on the World Wide Web (WWW) identified by a unique Uniform Resource Locator (URL) that allows a user of sender 302 to input information through network 306 into server 302 that will be translated into document
  • WWW World Wide Web
  • URL Uniform Resource Locator
  • Applications 168 includes, for example, composition engine 170, storyteller 172, e-mail engine
  • composition engine 170 provides, for example, a framework of data structures, a run-time model, a compiler, an application programming interface (API), and conventions for building an almost endless variety of different stories 180 that conform to a story run-time model.
  • the story run-time model is designed such that a story playback engine on a story client can be simple in complexity and fast.
  • the run time model provides a lightweight cooperative multitasking multimedia and central application framework. (Such a run-time model described in greater detail below).
  • Composition engine 170 passes information provided by sender/publisher 310 (see FIG. 1), such that the information is represented in a procedural data format that is not a flat data format.
  • the technologies are designed for the procedural content to be fully computer-generated, that is, without manual user intervention. (Manual building is possible but it is not preferred or even desirable.)
  • industry standard XML interfaces are used to completely automate one time processing of such provided information, such that existing authoring tools and content formats, for example, JPEG, AVI, MPEG, MP3, and the like, are supported through a simple yet powerful transcoding mechanism of the invention.
  • composition engine 170 performs one-time processing of the provided information such that the resulting procedural format of the information for example, is a sequenced set of data, for example, computer program instructions or operation codes (op codes), control information, parameters and media parts.
  • sequenced set means that the data is organized into a time line that dictates the rendering and navigational characteristics of a story 180. This time line may include procedural tests, branches, jumps, conditional statements, and the like so that the rendering may not ultimately be perfectly linear or sequential.
  • such a sequenced set of data may include a first set of computer program instructions to display a graphic.
  • the first set of computer program instructions is followed, for example, data used by a story player to display navigational buttons on the story receiving devices display.
  • each media part is assigned an absolute priority that controls when and if a particular media part will be rendered.
  • the computer program instructions specify operations to render graphical user interface (GUI) components, media parts, and provide procedural control to user interaction with the GUI components.
  • GUI graphical user interface
  • control information for example, provides offsets into the sequenced set of data that indicate where particular media parts are located.
  • control information also provides a set of semantics and flags for each logical element of a story to maintain the intent of the message on all receiving devices.
  • control information includes an array of hot spots, one hot spot for every logical element.
  • logical elements include, for example, button controls, text input controls, bitmaps, areas wherein motion video will be displayed, text boxes, decorative elements, and the like.
  • Each hot spot is associated with a rectangular region of the receiving devices' screen display (if one is available). The rectangular region facilitates event identification.
  • event identification is associated with user instantiated events. For example, if a user selects, for example, with a mouse device, a region identified by the rectangle associated with a particular hotspot, the operating system will generate a button click event which, as will be described in greater detail below is processed by a story player in the context of the logical element selected.
  • Each hot spot is further identified as being either active or inactive.
  • An active hotspot is a hotspot that generates an event when a user selects a region within the rectangular area associated with the hotspot.
  • an inactive hotspot does not generate an event when a user selects a region within the rectangular area.
  • each hotspot area is implemented as a bitmap. Aspects of an exemplary procedure for a story player to use an array of hot spots to play a story is described in greater detail below in reference to FIG. 6.
  • the hotspot array may also contain semantic and alternative rendering element identifiers (ids) for logical elements other than areas.
  • ids semantic and alternative rendering element identifiers
  • a hotspot's semantic flags may indicate that there is overview test available that describes the overall purpose of a screen of information, and the hotspot may also contain the id of the overview text element of the story.
  • control and control information include memory buffer creation, memory buffer loading, branching, condition or searching, layout, subroutines, linkage between different sequences of instructions, decompression and compression and file packaging, e-mail access for sending messages, requests for subfiles.
  • each opcode, parameter and offset is a 32-bit word. This is beneficial for a number of reasons. For example, portability and adaptability are supported by the use of fixed size 32- bit words.
  • a 32-bit fixed size word is advantageously used for representing a large dynamic range of value and is highly compressible because both instructions and parameters are designed to have mostly small integer values.
  • the fixed size makes things very scalable and processor words are always aligned along the word boundary.
  • the playback code, or the story 180 is also small and reusable.
  • Parameters and opcodes can be processed by the same code and operation, for example, addition operations can be performed without the need for size conversion of the code.
  • An additional advantage is that the opcodes and data are aligned in memory for fast access. Aspects of an exemplary procedure to use such a procedural data layout to play story 180 are described in greater detail below in reference to FIG. 5 and FIG. 6.
  • composition engine 170 is stored by composition engine 170 as a set of master parts data into master parts database 178.
  • each set of master parts data is identified by a unique identifier that can later be used by sender/publisher 310 to access, modify, and delete the contents of a particular set of master parts data, in master parts database 178.
  • the set of master parts data can be used by sender/publisher 310 (see FIG. 1 and FIG. 2) to generate and distribute any number of stories 180 to targeted e-mail enabled clients.
  • composition engine 170 is eminently portable, meaning that it may also be embedded in other devices besides sending story server 302.
  • composition engine 170 may be embedded, for example, into a digital camera.
  • a single global data structure allows the implementation of composition engine 170 code as a set of C++ objects, composition engine 170 code is reusable and can be instantiated more than one time.
  • An additional advantage of this is that applications including composition engine 170 will be easy to build.
  • sizes of all program variables are explicitly defined and there is built-in support for little-endian and big-endian systems.
  • a thin hardware extraction layer (HAL) and the ability for all text to be represented in ASCII or Unicode also supports portability. In combination, all of these aspects make a story quickly and easily portableto a broad range of devices, able to handle nearly all the computer programming instruction sets or languages.
  • Story teller 172 includes, for example, a set of programmed logic that will select at least a subset of a particular set of master parts data in master parts database 178 to build story 180. Because composition engine 170 represents the provided information in a procedural format, a story 180 is just one big procedural language/data/environment. In a preferred embodiment, a story 180 is part of the same procedural language including the content, decompression, rendering, layout, hotspot responses and navigation. In some aspects, a story 180 may be viewed as a self-contained ultra-low overhead multi-threaded run-time system. For example, a story 180 generates video frames by executing sequences of instructions. This allows for mixing of different video decompression/reconstr ⁇ ction algorithms within a single frame. For example, a motion compensation vector equivalent for a whole frame can be applied using a single instruction which moves rectangular parts of one picture into another.
  • storyteller 172 builds a story 180 from the master parts database 178 in response to -a message from StoryMail enabled client 336 (see FIGS. 1 and 4). (Such a message is described in greater detail below in reference to FIGS. 5 and 6).
  • the message will include a unique identifier, such as the unique identifier discussed above, to determine which set of master parts data to use to build a story.
  • the particular master parts that a storyteller 172 will select to piece together story 180 together depends on the purpose of storyteller 172 and the particular hardware capabilities, network connection characteristics, and user preferences associated with a targeted story enabled client 336 (see FIG. 1 and FIG. 4). Aspects of an exemplary procedure to send server 302 such capabilities, characteristics, and preferences are described in greater detail below in reference to FIG. 5 and FIG. 6.
  • storyteller 172 can include any one of the exemplary applications of a story 180 that were discussed in greater detail above or other purposes.
  • sending story server 302 includes any number of pre-configured storytellers 172, wherein each storyteller 172 will have a unique such purpose.
  • a first storyteller 172-1 may be used to build an e-coupon story 180
  • a second storyteller 172-2 may be used to build a parts catalog story 180, and the like.
  • sending story server 302 will serve a Web page interface (not shown) whereby publisher/sender 310 creates and modifies storytellers 172.
  • a Web interface provides a set of button controls that when selected by a user allows the user to: (1) add logical story elements, for example, an MPEG file, to master parts database 178; (2) select portions of such logical story elements, for example, a user selects a particular picture and a particular video to include in a story 180; (3) specify the dimensions of portions of the story, for example, a user may specify that tne dimensions of a particular sequence of logical story elements are to be of a particular width and height; (4) order the logical story elements on a time line, and take into consideration any user navigation; and, (5) define a set of templates, wherein a particular template specifies, for example, the particular operating parameters and rules used to scale the logical story elements to optimally play on a particular story enabled client 336 (see FIG.
  • E-mail engine 173 is used to both send and receive e-mail respectively to/from sender/publisher 310, story enabled client 336 and conventional e-mail client 340.
  • Conventional e-mail engines are known in the art of internet e-mail messaging. Aspects of such e-mail messages are discussed in greater detail below in reference to FIG. 5 and FIG. 6.
  • FIG. 5 there is a block diagram that illustrates aspects of an exemplary story enabled client 336 (client 336), according to one embodiment of the present invention.
  • Client 336 receives and plays stories 180.
  • Client 336 can also forward story 180 to other e-mail enabled clients, for example, another story enabled client 336 and/or conventional e-mail client 340 (see FIG. 1).
  • client 336 includes processor 184 connected across local bus 186 to memory 188.
  • Processor 184 is used to execute computer program applications 190 and fetch data 198 from memory 188.
  • Local bus 186 can be any type of bus, for example, a peripheral component interconnect (PCI) bus, as long as local bus 186 has a set of signal lines that can be used by processor 184 to transfer information respectfully to and from memory 188.
  • PCI peripheral component interconnect
  • Data 198 includes, for example, e-mail message 200, which is sent to story enabled client 336 by sending story server 302 (see FIG. 1). Aspects of an exemplary procedure for sending story enabled client 336 e-mail message 200 are described in greater detail below in reference to FIG. 5 and FIG. 6.
  • e-mail message 200 includes, for example, novel story e-mail, which indicates to story enabled client 336 that a richer content story 180 is behind e-mail message 200.
  • Story enabled client 336 receives a mail message 200 before it receives story 180.
  • story 180 is only received by story enabled client 336 after story enabled client 336 collects its e-mail from an e-mail server, for example, conventional e-mail server 332 (see FIG. 1).
  • story header 201 includes, for example, story teller ID 202, data set ID
  • Story teller ID 202 identifies a particular story teller 172 (see FIG.4) used by sending story server 302 (see FIG. 1) to build story 180. Aspects of exemplary procedure for sending story server 302 to build story 180 are described in greater detail above in reference to FIG. 2, FIG. 5 and
  • Data set ID 204 is used to identify a data set that corresponds to at least a subset of the information in master parts database 178 (see FIG. 4) that will be used by sending story server 302 to generate story 180.
  • URL 206 identifies the URL of the particular sending story server 302 that sent client
  • story enabled client 336 may be forwarded by story enabled client 336 to another device, in a preferred embodiment, story enabled client 336 does not forward story 180 to another device, but rather e-mail message 200 is forwarded to another device.
  • Such other devices include, for example, another story enabled client 336, a conventional e-mail client 340, and/or a story enabled device 344.
  • any corresponding collection request by the targeted device associated with e-mail message 200 is redirected to sending story server 302, such that sending story server 302 determines whether the target device is story enabled or not. If the targeted device is story enabled, sending story server 302 determines, for example, the particular hardware characteristics, network connection characteristics, and any user preferences associated with the targeted device before sending story 180 to the targeted device. Aspects of an exemplary procedure to make such a determination are described in greater detail below in reference to FIG. 5 and FIG. 6. This level of indirection ensures that an optimized story 180 will be forwarded to story enabled clients 336 and story enabled devices 344. This level of indirection also ensures that if the targeted device is not story enabled.
  • the targeted device although not receiving story 180, receives conventional content associated with the mail message 200 along with the novel story header 201 information.
  • conventional content is determined by sender/publisher 310 (see FIG. 1) and storyteller 172 (see FIG. 2) upon creation of a message or promotion that corresponds to story 180.
  • E-mail message 203 includes, for example, story 180.
  • e-mail message 203 is received by story enabled client 336 after sending story server 302 has determined story enabled client's 336 particular hardware characteristics and any user preferences.
  • story 180 is scaled to story enabled client's 336 particular hardware characteristics, network connection characteristics, and user preferences.
  • Applications 190 includes, for example, information provider 192, story player 194, and other applications 196.
  • Information provider 192 for example, sends story enabled client's 336 hardware capabilities, network connection characteristics and any user preferences to sending story server 302 (see FIG. 4). Such capabilities and characteristics (discussed in greater detail above) are typically obtained by querying operating system software (not shown) that controls the execution of computer programs and provides such services as hardware management, computer resource allocation, input/output control, and file management in story enabled client 336.
  • Information provider 192 determines any user preferences in a number of ways.
  • information provider 192 displays a GUI onto a display device (not shown) connected to story enabled client 336.
  • the GUI will have one or more user interface controls, for example, a dialog box, an edit control, and/or a combination box, to the end-user for end-user selection and input with respect to a predefined number of preference categories.
  • categories include, for example, a preferred language, ⁇ message size limits, message download time limits, message filters (for example, no e-coupons), data encryption requirements, and security requirements. (Either limits may be greater or less than a default set of time limits).
  • if there are a number of preferences certain preferences will be given a higher priority than other preferences.
  • such preferences are stored in data 198 as a text file (not shown) in a structured file format, for example, XML, that can be edited by a user with using a text editor.
  • Story player 194 executes, or plays story 180.
  • story 180 includes one or more of op codes, parameters, offsets and media parts.
  • player 194 sequentially parses story 180 to extract these op codes, control information (parameters and offsets), and media parts.
  • control information parameters and offsets
  • media parts As each op code is extracted, player 194 will match the op code to a particular computer program instruction, or procedure, which is a logical set of computer program instructions.
  • Story player 194 will jump to a procedure that corresponds to the opcode and begin a set of corresponding computer program instructions.
  • such computer program instructions are C instructions. If the computer program instruction requires corresponding parameters, the required parameters are extracted on an as needed basis from story 180.
  • parameters can signal the parsing of other parameters from the stack.
  • a specific number and specific type of parameter can be mapped to a computer program instruction. For example, the number and types of parameters can be hard wired in the implementation of a computer program instruction. .If.a.parameter.is an offset to. a .media part of story 180, the offset is used when playing story 180 to extract the data for the particular media part when necessary.
  • Story player 194 advantageously implements cooperative multithreading and synchronization through resource constrained retry at the instruction level. To provide such advantages, each procedure in story 180 returns one of a number of possible status codes, for example, success, retry, and yield status codes. In one embodiment, story player 194 executes sequences of instructions for a thread as long as the instruction functions return a status code of "success". Upon receiving a status code of success, a next thread is executed by story player 194 under similar constraints.
  • Any instruction that takes a predetermined amount of time to complete will return a "yield” status code, indicating to story player 194 that other threads should be executed.
  • story player 194 stops executing the thread and places it onto a queue for later execution.
  • Such yield status codes are inserted at appropriate places in story 180 by story teller 172 when story teller 172 creates story 180.
  • Certain story 180 instructions are executed on a time line as described in greater detail above in reference to FIG. 4. Such instructions are so tagged with a "wait until time” instruction by storyteller 172 (see FIG. 4) before being placed into a master parts database 178. Story player 194 will wait until the indicated time to execute such instructions.
  • story player 194 If story player 194 encounters such an instruction and it is not time to execute the instruction, story player 194 will retry the instruction at another time. Any instruction encountered by story player 194 that requires a memory buffer, wherein the memory buffer is not available, is placed on a queue such that story player 194 will retry the instruction at a later time wherein such memory resources may be available. In one embodiment, story player 194 identifies "wait for event" flags to synchronize story 180 instructions.
  • story player 194 presents a purchase button to a user that is used to provide a response to the story 180.
  • the HAL identifies a user selection in the rectangular area defined by a particular hotspot associated with the button. (Hot spots are described in greater detail above in reference to FIG. 4).
  • story player 194 executes a story procedure or story thread associated with the selection.
  • Other applications 196 include, for example, an optional e-mail client application, for example, Microsoft Outlook Express®, that provides e-mail receipt and delivery capabilities to story enabled client
  • Internet e-mail protocols include, for example, POP3 and IMAP protocols.
  • e-mail receipt and delivery capabilities are provided by story player 194. Referring to FIG. 6, there is a block diagram that illustrates aspects of an exemplary procedure
  • StoryMail enabled client 336 see FIGS. 1 and FIG. 5
  • conventional e-mail client 340 see FIG. 4
  • FIG. 1 To better describe procedure 210, the following description references structure that are respectively illustrated in FIG. 1 , FIG. 2, FIG. 3, and FIG. 4.
  • Step 212 provides, for example, multimedia content and/or message parameters to story server 302 (see FIG.4).
  • message parameters correspond to the multimedia content.
  • a message parameter is a discount rate.
  • multimedia content includes, for example, product descriptions, promotional information, customer specific information and/or pictures to the story server 302 (see FIG.
  • sender/publisher 310 sends such content in Document 154 (see FIG. 2).
  • sender/publisher 310 accesses a URL that corresponds to a Web page (not shown) served by sending story server 302, whereby a user could input such content to sending story server 302.
  • Such content is described in greater detail above in referent to FIG. 2.
  • such content also includes, for example, the identity of a specific storyteller 172 to be used to generate a story 180 (see FIGS. 3 and 4).
  • sender/publisher 310 is an Internet book, music and video retailer that offers music CDs, video, DVD, computer games and other products
  • the specific storyteller 172 may be used to build a parts catalog story 180 to be distributed to retailers, or the specific storyteller 172 may be selected to generate a holiday card story 180 to be distributed to customers.
  • Step 218 performs one time processing of the content as described in greater detail above in reference to composition engine 170 as illustrated in FIG. 4.
  • Step 220 returns a unique master parts identification to sender/publisher 310.
  • an identification is used to identify the particular set of master parts data that corresponds to the one time processed content. This identification can be used by sender/publisher 310 to access, modify and delete the one time processed information from sending story server 302, as well as to send new messages using the same master information as default content.
  • Step 220 sends e-mail message 200 (see FIG. 5) to each recipient that is identified in the provided content (step 212).
  • e-mail message 200 is an e-mail message that includes story header 201.
  • a recipient can be either a story enabled client 336 (see FIG. 1), a conventional e-mail client 340, or a story enabled device 344.
  • Step 222 intercepts an e-mail collection request from the e-mail message 200 receiver. Step
  • Step 226 evaluates whether the e-mail message 200 receiver is story enabled, for example, a story enabled client 336. If not, step 226 sends the contents of e-mail message 200 to the non-story enabled device, for example, conventional e-mail client 340 (see FIG. 1). Otherwise, procedure 210 continues as illustrated in FIG. 7.
  • Step 228 gets story enabled client 336 information. As described above, such information includes corresponding hardware capabilities, network connection characteristics, and any user preferences. In a preferred embodiment, such capabilities, characteristics and preferences are represented by story enabled client 336 in a structured file format, for example, as an XML document.
  • quick communication protocols are used between story servers 302 and 328 and story enabled client 336 respectively for intra-server and server client communications, for example, HTTP communication protocols.
  • story enabled client 336 could represent its particular capabilities characteristics and preferences in a structured file format as follows.
  • CPUSpeed 300 indicates that in the client 336 CPU speed is equal to 300 MHz.
  • CPU or processor speed criteria may be used to influence the .generation of an optimized. story .in that the CPU may not be fast enough to process large video clips in real time.
  • a video clip with small dimensions (width and height) might be used instead.
  • a signal picture may repress the video content instead of a video stream.
  • Step 230 generates the story 180 (see FIG. 4 and FIG. 5) using a particular storyteller 172 identified by story teller ID 202 (see FIG. 5) in e-mail message 200.
  • the specific storyteller 172 selects, or strings together only those portions of the set of master parts (identified by the date set ID 204, see step 219) in the master parts database 178 (see FIG. 4) that are compatible with each of the following: the capabilities, characteristics and preferences identified in step 228; and, the content which is compatible with the purpose of the specific storyteller. While stringing together such information, the specific storyteller 172 may create several original logical files, compress them, and compress each of the compressed logical files into a final single file.
  • the logical order of the data in the each respective original single file is maintained in the headers, of a sequence of sub-files that are automatically generated from each respective original logical file.
  • a logical order is advantageously used by sending story server 302 (see FIG. 1) when transferring a story 180 to a story enabled client 336 (see also, step 232).
  • the opcodes representing computer program instructions and parameters may be placed in a first logical file, text and parameters in a second logical file, all motion video may be placed in a third logical file, all audio data may be placed in a fourth logical file, and the like.
  • the computer program, control information, audio data, motion video, and the like may be interspersed.
  • the elements which are best compressed using the same compression algorithms are combined together so as to achieve a more optimal compression level.
  • system 300 cooperates in collecting all relevant information and data first, such as for example, the capabilities, characteristics, and preferences described above, before generating a story 180 (step 230). This makes system 300, and in particular story 180 generation advantageously automated and dynamically adaptive. Having obtained all this information, system 300 then generates the optimum story 180 after a connection has been made with recipient. This is because only at the time of connection will story server 302 know for certain the particular characteristics of the recipient's client device, communication channel, and user preferences. In some conventional systems, a user may register with a server characteristics of a registered device as well as registered user preferences. However, these conventional systems do not generally test or otherwise take into account the hardware capabilities of the device or network connection characteristics used by the device to communicate with the server at that moment of time.
  • the StoryMail system 300 (see FIG. 1) and procedure 210, on the other hand, take all such factors into account after connecting to a recipient's device to generate the optimal story 180 from a standpoint ofstory size, language, use or not use of audio or -visual content, and the like.
  • the StoryMail procedure 210 is contrary to other prevailing trends which attempts to pre-form content so that is available as early as possible in that StoryMail 300 actually delays composition of an e-mail message until these capabilities, characteristics and preferences are known. In this manner, a story 180 sent to any device will be experienced in a manner that is optimal for that device and user.
  • Step 232 communicates a second StoryMail message 200 to story enabled client 336.
  • the second e-mail message 203 includes that generated story (step 230) and the corresponding story header 201 (see FIG. 5).
  • storyteller 172 encrypts generated story 180 (step 230) so that it cannot be read by any intervening process after it is sent to story enabled client 336 and before it reaches its destination.
  • public key encryption there is no need to have a central repository of public keys because the public keys of the center and receiver client can be exchanged after connection time when the story 180 is being generated (step 230).
  • each logical sub-file of story 180 includes, for example, a startup sequence of instructions that can be used to start the transfer of the following sub-files in the sequence.
  • Such segmentation of the files is beneficial for a number of reasons. For example, while transferring a story 180 to a story enabled client 336 (see FIG. 1), if the bandwidth is too small, a sub-file will not arrive in time. In one embodiment, story player 194 (see FIG. 5) pauses until each respective sub-file transfer is complete. In this manner, quality of story 180 presentation will be constant, even if receipt of story 180 content is intermittent. In yet another embodiment of the invention, real-time transmission of story 180 is not required so that the recipient may never be aware that transmission was delayed, suspended, or intermittent for a particular portion of story 180.
  • Step 234 executes, or plays the story. Aspects of an exemplary procedure to play a story 180 are described in greater detail above in reference to FIG. 4.
  • a custom story 180 is generated for each receiving device, such that a story 180 can be generated to play on all types of story enabled devices and compatibility is maintained for all stories 180 even as story enabled devices may change or evolve.
  • Even the rich media stories 180 will play on non- rich media enabled devices because, in preferred embodiments of the invention, there is always some text or other simplified content behind more complex elements such as sound or video clips to fall back on. This is because the master parts database 178 (see FIG. 4) includes information to create new stories that will play on all story players because there will always be the old instruction alternative to fall back on.
  • each logical element of a story 180 includes, for example, associated semantic information that respectively indicates a set of logical elements of story 180 that are to be displayed, or played on the recipients device. In one embodiment, such semantic information also indicates when story player 194 should substitute an alternative logical element for another particular logical element.
  • Step 236 determines whether there is a response to the played story 180. Such a response can be provided, for example, by a user selecting a button control that the story 180 causes to be displayed. If there is such a response, step 238 generates a response to the story 180. For example, if the story is an e-coupon that promotes the purchase of a particular book, story player 194 (see FIG. 5) will create a structured format purchase order form, for example, an XML purchase order form. Such a form includes, for example, the customer .ID, .the product .SKU .(stocking number) that was included -in story 180 (parsed from document 154 (see FIG. 2, FIG. 3, and FIG. 4), and any preferences. Such preferences include, for example, an indication of whether the book is to be received in electronic format instead of a physical format, the language that the book is to be written in, payment information, and the like.
  • Step 240 communicates the response (step 238) to the fulfillment server that was identified in the story 180 (parsed from document 154 (see FIGs. 2, 3, and 4).
  • Such communication can be implemented by using a number of different protocols, for example, the HTTP protocols or SMTP protocols.
  • the invention offers a number of strengths as compared to the closest competing technologies.
  • a story 180 plays off line as well as online and is lightweight (thin) enough to run on inexpensive information appliances or other devices.
  • a story includes, for example, user navigational aids, user forms, and can automate a transaction fulfillment process.
  • a story is instantly interactive, self-contained and reliable. Creation of a story's 180 content can be completely automated, such that devices made today will be able to handle future content without upgrades.
  • the invention facilitates publishing messages that are meaningful to individuals with physical disabilities and provides for intelligent content specific scaling and compression.
  • a story 180 is easily stored and exchanged as a single file, and the same content runs in Web pages in its own window and on low-power device screens.
  • the inventive system and method provide a single file format (referred to as the story file format) and file execution procedure that permits communication of text, pictures, motion video, and other rich media content
  • story files and the story file format can encapsulate the rich-media content itself, user navigation, e-commerce, intelligent forms, automation, as well as other data and executables in a procedural form.
  • embodiments of the story files are e-commerce and email aware, fully functional on-line or off-line, compressed to reduce storage and transmission overhead, efficient, and lightweight. All story files are desirably constructed to run in a large variety of operating environments and on a large variety of devices.
  • the system allows for efficient automated generation and efficient automated customization through the use of logical files and indirection.
  • the inventive story file may be embedded in and run from an Internet web page, streamed from a server, run or executed from an email attachment, executed from ROM or RAM in any one of a variety of devices or device types, executed as an independent program (stand-alone program or as an application program within an operating system environment), as a Multipurpose Internet Mail Extensions (MIME) Type, as an ActiveX component, as a plug-in to another application program, executed within an email or other client, or in numerous other ways.
  • the story file can be generated automatically by computer programs, for example a program running on an Internet connected server.
  • Pieces of story procedural content can be very efficiently selected, concatenated into logical files, then packaged into a single story file customized according to the input, without the need for complex decision or linking operations.
  • Such input may include limits on final story file size, content types, preferred language, and the like.
  • SPPL Story Procedural Programming Language
  • SPPL is designed for procedural content to be fully computer or otherwise autonomously generated without human involvement, though SPPL may be generated manually though less efficiently, and in one embodiment, provides a self-contained ultra-low overhead multi-threaded run-time system.
  • SPPL provides a procedural and methodological framework that may advantageously be optimized for multimedia and e-commerce applications.
  • Semantic elements include flags and/or other indicators or indicia that identify the particular content element with which the semantic element is associated. For example, a semantic element may identify that the associated content element is for an overview of an element that would not be used as a direct substitute or replacement for an alternative (e.g. richer) content element. In this example, a story player would use the overview text and a text to speech algorithm to communicate what the screen shows for a user who cannot see the display screen at all. In this case this overview element does not directly replace or back-up another element.
  • semantic elements support explanation and navigation. Semantic elements need not be in a one-to-one relationship with other elements. Semantic elements further permit a type of filtering or extraction of story components. For example, it would be possible to search for all elements of any particular type (e.g. pictures, text, audio, motion video, overviews for content that would be rendered directly on suitable devices, and the like.
  • SPPL formatted stories execute or play on all story enabled devices for all time.
  • all rich media stories will play on poor-media devices because there is always a text or symbolic (poor-media) element behind each rich-media logical story element to fall back on in the event the rich-media element cannot be played.
  • Semantic information and procedures included within the story ensure that the proper elements can be automatically selected at run time so as to preserve the intent of the story message regardless of the limitations of the story playback device.
  • new SPPL stories which contain new instructions will play on old story players (or on earlier versions of story player software) because in preferred embodiments there will be an older or compatible SPPL instruction set alternative to fall back on that will play either the -richest-media alternative or a poor-media alternative using only the instructions supported by the old story player.
  • the decision of whether to fall back is made using only instructions known to exist in all story players. In this manner new instructions are never executed on old players which do not support the new instructions, yet there is always a method for communicating the intent of the message, albeit in a less media rich manner.
  • the story capabilities are supported by several enabling technologies. These enabling technologies include the provision and use of a set of proprietary compression algorithms and techniques adapted for voice, video, music, images, and text or other symbolic data. Self-contained threaded procedural data technology is also used that is very processor and memory efficient, and highly functional, flexible and portable to a wide array of devices.
  • the story technologies are embodied in two portable code engines: a composition engine and a playback engine.
  • the story composition engine may be used for human and computerized or autonomous authoring systems as well as for automatically generating custom stories using parameters from customer or other databases.
  • the story playback engine may be used for story playback in for example, playback in Internet web browsers, playback in various devices, and playback in custom applications.
  • Embodiments of the inventive story file format and SPPL provide a run-time system with cooperative multi-threading at the instruction level, and thread and media playback synchronization based on resource constraints and instruction retry methods.
  • the code-based story standard is advantageous for several reasons. It is reliable because a single set of source code is used for all encoders and decoders thereby eliminating incompatibilities that might arise because of untested combinations of encoders and decoders developed by different third parties. Also, there can be no misunderstandings on how-to implement certain features such as may arise from ambiguities or misreading of text based specifications. It also provides for quick porting to Microsoft Windows OS,
  • the story file format is also interoperable across a wide range of networks and devices.
  • SFF Story File Format
  • SPPL Story Procedural Programming Language
  • a story file will include control information, text or other symbolic information, audio information, pictorial information, motion picture information, video information, and semantic information designed to allow players to preserve the intent of a story message when play back of elements of the story are not possible.
  • the composition engine (described elsewhere in this specification) is responsible for putting together or packaging these information items into the single story file so that it may be utilized by the story player.
  • the characteristics of the composer, communication channel, and story player influence how this packaging (and later unpackaging) is most beneficially performed. It is advantageous from the standpoint of the story player and the device on which the story player is installed or implemented that the received file is as small as possible, consistent with maintaining the message and its intent.
  • the story player will be a thin device with small or modest memory.
  • the thin story client is capable of receiving and storing the compressed story file, there remains a need to decompress the file for playback or rendering.
  • the desirability of providing autonomously computer generated story files suggests using predetermined procedures for processing logical elements ofthe story file during its creation.
  • the inventive story file is therefore produced according to a story file assembly procedure that satisfies each of these and other needs and/or preferences.
  • the story composition engine operates according to predetermined rules so that each story file is assembled into a standard framework that is understood by every story player. Assembly within the composition engine includes packaging and one or more levels of compression of a plurality of story file constituent logical elements into logical files. These logical files can also be compressed/decompressed using a top-level of compression during the packaging and unpackaging or unpacking process. Disassembly within the story player playback engine includes intelligent selective unpackaging and decompression of these constituent logical elements from logical files.
  • the composition engine is responsible for choosing the constituent logical elements required in each story file. These constituent elements will generally include commands, parameters for the commands, and data. Data may take the form of text or other similar symbolic or character data, audio data for generating or reproducing sound information, and video data for reproducing still or motion graphics, pictures, images, or other two dimensional (or three dimensional) information. As described elsewhere herein, preferred embodiments of the invention provide for multiple levels of media richness so that rich-media content may be utilized when possible but media having lower richness is available as a backup when necessary or preferred. Recall for example, that text is a backup for audio or video, that monochrome video is a backup of color video, that still imagery is a backup for motion video, and so forth.
  • each logical element is matched to a set of semantic flags which indicate the circumstances and manner in which the logical elements might be used. For example a flag may be set for a text element that indicates that it is a first level overview of the message intent. A different flag for another element could indicate that element is selectable and has text available to describe the action taken when the element is selected.
  • a typical rich-media story will include multiple text, audio, and video logical elements, as well as control elements and semantic flags describing the role of elements for story playback and user interface and/or navigation.
  • these logical elements are advantageously packaged and compressed differently.
  • Control elements, text elements, audio elements, and video elements represent different types of logical elements arising at least in part from their associated data characteristics, available and/or preferred data compression schemes appropriate to each logical element type, the size of decompressed data in the story player, the relative or absolute time at which the particular type of logical element is needed during .story .playback .in the story .client (or intervening receiving entity), and other factors.
  • Even audio logical element types may be further characterized into subtypes, that for example, treat speech differently from music.
  • video type logical elements may be broken into additional subtypes, that for example, treat computer generated graphics having limited colors or tones and well defined color or tonal boundaries differently from continuous tone photographs. These subtle differences, may frequently permit the use of a more efficient compression/decompression scheme for each logical element. (The separate compression of different logical elements into like logical files as described hereinafter.)
  • the composition engine builds each logical element separately or a group of logical elements having the same logical element type.
  • a group may include only some logical elements of a particular type or all elements of that type. It then optionally but preferably compresses the logical element or group of logical elements using an appropriate compression scheme.
  • Compression schemes for audio may, for example, include ADPCM, physco-acoustical models, Transforms, .MP3, as well as other schemes.
  • Compression schemes for video may, for example, include DCT, LZSS, Motion Vectors,
  • Control type logical elements and text type logical elements may be compressed using, for example, be a LZSS, Run-Length, Table look up, or other suitable compression scheme, but may frequently not be compressed at this initial pre-packaging stage of composition. (But, see description of compression of packaged story file.)
  • logical elements or groups of logical elements are then combined into a single file.
  • the combination may be accomplished by concatenating the logical files (logical elements or group of logical elements) sequentially or in any other way.
  • logical files are parts of a single story file.
  • Subfiles described further later in this document, relate to a streaming mechanism for such applications such as starting to play a story before the entire story has been received by the player, and which are in a sense complete stories in themselves that are chained together.
  • the combined file is then optionally but preferably further compressed in a final compression stage.
  • a generic compression scheme such as Lempel Ziv Welch (LZW) compression may, for example, be utilized as well as other schemes. Compression of the combined file is particularly advantageous when the control and text logical elements or groups of logical elements have not been separately compressed.
  • Using multi-stage (compress logical elements and then compress combined file) and element differentiated compression may permit reducing memory and bandwidth requirements by a factor of from about 1 to about 1000, dependent upon data characteristics and the algorithms applied.
  • the compressed file is then communicated to the client, where it may be received in its entirety prior to the initiation of playback or where portions of the compressed file may be received after playback has begun.
  • the logical files, command portions, and the text portions, of the file are unpackaged and decompressed using the decompression to undo the final stage compression described above.
  • the decompression occurs as the story is being played back so that only the portions of the commands (and optionally the text) that are actually needed are decompressed.
  • all of the commands (and/or text portions) are decompressed either when received or at the start -of a story playback phase.
  • the larger logical elements are not decompressed until their data is needed for playback.
  • the audio logical elements and the video logical elements are advantageously decompressed on the fly during playback so as not to unnecessarily consume client device memory.
  • the decompressed audio and video logical elements are not saved, so that it is necessary to redo the decompression if the story is replayed. (Other embodiments save the decompressed elements but this is not preferred as client resources, particularly client device memory, are inefficiently utilized.
  • decompression of the logical elements does not necessarily directly reveal a data structure having an array of picture elements (pixels). Instead, a procedure with commands and data are revealed that is easily implemented or executed by the story player to render the image.
  • This approach places a greater burden on the compiler in the composition engine but greatly simplifies the work in the story player. It also permits a thinner and more processor and power efficient story player.
  • Other embodiments may directly decompress the larger logical elements, such as audio and video, and place them into a data structure for subsequent playback or rendering, but this approach is not preferred as it tends to increase memory requirements and playback engine or process sophistication.
  • Embodiments of the story procedures may conveniently be implemented in general purpose computer programming languages to take advantage of a large base of skilled programmers. For example, languages such as "C”, “C++”, JAVA, or the like may be utilized to author or generate programs into SPPL or SPF. However, when such conventional languages are used it will be understood that the functions and subroutines may be novel and specifically directed to story applications. For example, novel function and subroutine libraries are provided by the invention.
  • One, such a library subroutine is a procedural function made up of a series of story instructions that decompresses, synchronizes and drops frames as necessary during playback of video streams.
  • the SPE State Playback Engine
  • the SPE code should run in all devices and environments with a minimum of platform specific effort. The goal is to be able to enable a new device for Story playback with less than two work weeks of effort by a programmer familiar with the target device, but not necessarily familiar with the SPE code. It is expected that third party device and application programmers will be able to do ports based on the Story code-base and documentation, with only minimal support from StoryMail.
  • C has proven to be efficient in code size and execution speed while remaining highly portable.
  • C++ was not selected because it is not supported by tools for many DSPs and is not as efficient as C; however, we do want to take advantage of the modern optimizers built into existing C++ compilers and preserve some of the advantages of C++ such as the ability to easy create multiple instances. For this reason the C language subset we have chosen is compatible with C++ compilers and can easily be encapsulated in a C++ wrapper in a manner that allows for multiple instance creation.
  • C++ as well as other current and to be developed languages may however be used to implement the invention.
  • the first two functions perform the functions of implementing a round-robin, multi-threaded operating system.
  • the second two functions illustrate functions that implement actual Story op-code execution.
  • StoryPlaybackCycle should be called continually in a loop on a single host operating system thread.
  • This functions executes all the threads once in order, until each thread gives up control, then returns.
  • This function fetches an opcode from the input buffer and calls the function that implements the opcode. It also handles instruction retry by:
  • the instruction pointer is reset to point back to the opcode by restoring the saved value.
  • the return code, YIELD_TO_NEXT_THREAD_RETURN_CODE has a different value than a SUCCESS_RETURN_CODE .
  • ⁇ p.c. s32_ProcessInstructionReturnCode YIELD_TO_NEXT_THREAD_RETURN_CODE; return;
  • End ops are used to end subroutines and disable threads.
  • p.c. s32_ProcessInstructionReturnCode YIELD_TO_NEXT_THREAD_RETURN_CODE;
  • Versions optionally but desirably are placed into Story Playback Applications using two values #defined in stConfig.h.
  • the first value identifies the platform and the second identifies the platform independent revision number. Both values are 31 bits and are accessible during run-time as an indirect parameter to any Story instruction op-code.
  • HAL Hardware Abstraction Layer API
  • API Application Program Interface
  • the API is embodied in a set of C functions and associated informational memory structures and data structures for the media to be rendered.
  • the portable code of the SPE handles as much as possible to make the Hardware Abstraction Layer (HAL) as simple as possible and to limit the need to use any more of the device operating system as possible. For example, pictures and audio are decompressed and rendered into simple raw output sample values in a very limited number of possible formats.
  • all synchronization of media and cooperative multitasking is done within the Portable Playback Engine code on a single device native operating system thread. Even this one thread returns to the device OS within 1/30 of a second so that the device can perform other functions even if it does not contain a multithreaded OS.
  • HAL Hardware Abstraction Layer
  • the Story Playback Engine (SPE) core will provide media and other data to the HAL in a limited number of formats, as discussed in this section. Though it is intent of the SPE core to provide the most useful and common formats, the large code size that would be entailed by directly supporting all data formats used across all platforms is to be avoided to the extent possible. Thus, it may be necessary for the HAL to perform data conversion if it uses a data format not supported by the SPE core. In some, such conversion code can be adapted from an existing HAL.
  • Audio Formats Picture/Video Frame Formats, and Other Media formats.
  • Media formats are advantageously limited to selected formats so that when exposed to the player device Hardware Abstraction Layer a lot of complexity (and code size) is not required. This preference yields simplicity and light weight and facilitates portability of the player on multiple platforms as the number of options are small. It should be appreciated, however, that this does not represent a compromise in system performance or in the features that the player (or composer) can offer. Rather than permitting numerous formats in the player, flexibility to handle multiple possibly diverse picture, video, audio, text, and/or other media is done by transcoding so as to be compatible with all current and future formats without requiring player changes or updates. The author of a message can use any format he or she wants, and transcoding or conversion from the author's format to one of the player supported formats is readily performed. This approach keeps the story player simple, lightweight, and portable. The intelligence and flexibility are provided in the transcoder.
  • the frame formats used by the player are BW, RGB, and YCbCr (analogous to YUV in analog formats).
  • Audio sample and playback rate and channel formats supported by the player in this embodiment are 8000HZ 1 channel, 11025HZ 2channel, 22050HZ 2channel. and 44100HZ 2channel.
  • ASCII or Unicode formats may be supported, and where one is supported, conversion to the other is accomplished using known techniques.
  • HalGetTimeO should support. One is based on actual time, and the other is related, but based on the actual physical audio sample's output rate. Having the two modes is necessary to ensure that there is no drift in the synchronization of audio and video. If a device does not support audio output then in both modes HalGetTimeO should just return the time based on milliseconds from any fixed starting point. There is no time of day or calendar date available; however they may optionally be provided.
  • HAL Hardware Abstraction Layer
  • C Bit Fields are preferably not used.
  • the size and order of bits within integers will cause portability problems between little and big-endian machines.
  • Pointers can have a size different from that of integers on some processors. So, it is important never to assume anything about the size of pointers. Also for security, robustness and portability reasons, no pointers should be stored on a Story Thread input buffer, thread stack, or in the main allocated memory block.
  • Compression algorithms were selected to make for small de-compressors with low CPU requirements. Having a procedural representation allows for a small number of functions to be coordinated by procedural control to do a wide range of things, keeping the playback code small. All data is kept aligned on a four-byte boundary and accessed as 32 bit unsigned words. This eliminates the need to have code to convert and compare values of different sizes and allows us to use the same functions to operate on different types. All this results in smaller playback engine code size.
  • the operations carried out by the story playback engine are designed to be simple at the expense of complexity to the programmer or compiler that generates Stories. For example, there is no memory allocation related garbage collection because that would require a good deal of code to implement and present real-time execution uncertainties. Instead, the programmer, compiler or generator should explicitly specify with an INIT_OP operation (See description of INIT_OP operation elsewhere in this description) exactly how much memory will be required for execution until the next INIT_OP operation will be executed. At least one INIT_OP operation should be present in each Story, and executed near the beginning of the Story playback.
  • INIT_OP operation See description of INIT_OP operation elsewhere in this description
  • the SPE creates its own cooperative multi-threading runtime system.
  • the interface to the playback engine consists of two functions.
  • the function void_lnitStoryPlayback(void) is called once, then SINT StoryPlaybackCyclefvoid) is called repeatedly in a loop so long as the return value is positive.
  • An example loop used for a single threaded Windows 32 bit implementation follows:
  • the Story compiler tools or Story author should ensure that no set of active threads can take more than 1/30 second before returning to the main cycle loop when running on a 300mhz Pentium (or equivalent) processor. This is to ensure that smooth video playback is possible on high end devices, and that non-Story features of a device controlled by the CPU will still be able to have a responsive user interface.
  • Story Files encapsulate all multimedia content using just three fixed compressions schemes; however, support for all video and audio formats can be supported by transcoding files from these formats to a procedural Story representation at the time that Stories are created.
  • LZSS compression is typically used for Text, Native Executable code, Story Format Code, and some Discrete tone pictures.
  • ADPCM is used for two-channel Music and one-channel voice.
  • DCT Discrete Cosine Transforms
  • Graphics operations are advantageously handled procedurally.
  • compression of video streams can be encoded as a sequence of compressed isolated frames, but taking advantage of the redundancy between adjacent frames normally improves the compression effectiveness by a factor of about three.
  • Story instructions can be used to move any rectangular area of any existing uncompressed picture to anyplace in a picture buffer into which a new picture is being decompressed. This rectangular area can serve as the starting point for corrections applied using Inverse Discrete Cosine Transform (IDCT) results.
  • IDCT Inverse Discrete Cosine Transform
  • To perform these operations there are instructions to move rectangles, average source rectangles with the target pixels, and add IDCT results to target 8x8 pixel areas in the target picture buffer.
  • a picture operation (PICTURE_OP) instruction with flags is provided to indicate to move a rectangle from a source picture buffer to a target picture while applying unary, binary, filtering, scaling, rotating, and/or fading operations to the source and target pixels.
  • PICTURE_OP instruction will be able to perform compositing, rotations, fades and scaling similar to Macromedia Flash technology, but using pixel graphics operation in addition to the mainly vector graphics operations of Flash. Translation can be performed as part of the DESCRIPTOR_OP and LAYOUT_OP instructions.
  • the Portable Playback Engine will become part of many applications across many platforms. Conveniently, steps are taken to document and maintain version release control for the story playback engine. Embodiments of the inventive system used a two-fold approach. First, as many aspects of building a release will be automated as much as possible. This ensures that there is a way to determine exactly what files and actions are used to build each release. Also, it reduces the likelihood of making simple human mistakes. Second, each build will be dependent on making one #defined release-specific symbol have the value one and all other #defined release symbols have the value 0. All other build level and type related #defines will be automated based on the release symbols. See the stConfig.h file to see how this is presently done.
  • the SPE code contains exactly one Global Variable. That variable, "p” is of type STORY_PLAYBACK_TYPE. (The STORY_PLAYBACK_TYPE is defined in stTypes.h.) It is a multilevel structure containing all the individual variables used throughout the SPE code. One may note that many functions, in particular the op-code specific functions, do not take any parameters or return any values. Instead everything is passed in the global, "p". This eliminates the code and execution time that it takes to pass and return parameters. When it is desired to make a C++ Story Playback object out of the SPE Code it is only necessary to- make "p" a member variable ofthe Story Playback object class, and make the Core engine functions member functions.
  • a side benefit of having one global variable is that it makes looking at variables in a visual debugger very easy since you only need to have one variable in a watch window and all the terminal variables are organized logically by structure.
  • the portable files should preferably not use any C or C++ variable types directly. Instead it is preferred to always use one of the Story Types as typedef ed below in a code fragment that is compiled in when USE_32BIT_VISUAL_C_PLUS_PLUS_TYPES is not zero.
  • the invention provides a system, device, method, computer program, and computer program product for cooperative application-level multi-thread execution including instruction retry feature upon identifying constrained ystem .resource. This aspect. is now described in greater detail.
  • the one global variable "p" is initialized to all zeroes when void lnitStoryPlayback(void) is called before the first play cycle. Also, the one memory block allocated by the HalAllocateMainMemoryBlock() call in the InitOpO function is zeroed just after it is allocated. Knowing that all variables and main memory start with a zero value eliminates the need to have code to initialize individual values, and makes the code more robust because it always starts in a known state. Many variable values, such as thread states are defined so that a zero value represents the initial state desired. Likewise the pointer table to buffers, and all buffer memory can be assumed to initially have zero values. Note that the CreateBufferOpO function does not zero the buffer memory.
  • the header and data of the buffer will still contain its old values until these are explicitly specified.
  • Another exception to the zeroing rule is the stack and input buffer for thread 0. One should not assume anything about the starting state ofthe stack and input buffer memory contents for thread 0. This is done on purpose so that thread 0 can run the first INIT_OP instruction that does the allocation of the one main memory block.
  • the stack and input buffer of thread zero can be used to retain state- when the main memory block is reinitialized over and over again by multiple INIT_OP instructions.
  • Logical Story File Packing and Unpacking Logical Story files contain a part of a final packaged Story File.
  • Logical files are accessed by the portable code, not by name, but rather by a number pair, the content ID (contentld) and the current file number (currentFileNumber).
  • Story Content is encoded as sequences of 32-bit unsigned values. Each value represents either an op-code or an op-code parameter. The next value to be accessed is pointed to by an instruction pointer (IP).
  • IP Instruction Pointer
  • content or story playback begins with the Instruction Pointer (IP) pointing to a value that represents an op-code. Playback then proceeds according to steps (a)-(f), as follows:
  • the IP is moved to point just past the op-code.
  • the value of the op-code is used as an index into an array of function pointers to call a C function that implements the op-code function.
  • the function then fetches the op-code specific parameters which follow the op-code.
  • the IP pointer is advanced as each parameter is fetched.
  • the number and type of parameters is specific to the op-code.
  • Each Story Playback Engine (SPE) thread executes one sequence of instructions/parameter values.
  • Each thread has a context, which includes its own IP, a stack mostly used for calling Story subroutines, and an input buffer to hold the sequence of values as it is executing.
  • the input buffer can be tied to a specific file that holds the thread's sequences of instructions that are not resident in memory.
  • YIELD_TO_NEXT_THREAD_RETURN_CODE will be returned when it is time for the thread to give up control of the CPU and move on to the next thread.
  • RETRY_INSTRUCTION _RETURN_ CODE will be returned when an instruction cannot perform the operation called for by the op-code and its parameters because it encounters a resource constraint.
  • resource constraint situation is when a
  • TIME_OP op-code that is set to wait for a particular time to occur, but it is not that time yet.
  • the op-code returns the RETRY_INSTRUCTION_RETURN_CODE.
  • the outer instruction dispatch loop sees that an instruction returned such a code, it resets the IP for the thread to point back to the op-code it just tried to execute. Then it starts up the next thread. After all other threads have had an opportunity to run, the TIME_OP thread will run again and try to execute that same instruction again. In this manner the thread will effectively wait for a resource, the time at which to continue the sequence, to occur without blocking the other threads.
  • a thread can wait to decode a picture into a particular buffer until another thread empties the buffer and releases it for use by other threads.
  • Thread context states */
  • Memory Allocation Memory allocation is done as part of the functionality of an INIT_OP instruction. Except for the
  • Input and Stack buffers of thread 0 all memory that is to be used until another INIT_OP instruction reallocates (and thereby destroys all past memory allocations) is desirably allocated as one big main memory block allocation performed during the execution of the INIT DP. From within this main memory block, buffers are created to hold pictures, audio samples, subroutines, text and even the stack and input information for all but the very first thread. Allocating memory in this manner allows for security checks to be performed with a small amount of code, and avoids the need for any complex and lengthy garbage collection algorithms.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Resources & Organizations (AREA)
  • Software Systems (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • Storage Device Security (AREA)

Abstract

Système, procédé, signal, modèle opératoire et programme d'ordinateur pour messagerie électronique. Systèmes et procédé permettant de sécuriser la communication de données de messages électroniques, sessions interactives, téléchargements de logiciels, mises à jour de logiciels et autres contenus d'une source à un appareil récepteur ; signaux utilisés pour ce type de communication (304, 309, 308, 324, 342, 338, 334, 330, 326). Systèmes, procédés, signaux, architectures d'appareils, formats de données et structures de programmes d'ordinateur assurant l'authentification, l'intégrité, la confidentialité, la non-répudiation, la protection contre la réinsertion ainsi que d'autres propriétés de sécurité tout en réduisant la bande passante du réseau (306), ressources informatiques et interactions manuelles de l'utilisateur (314) requises pour l'installation, l'activation, le déploiement et l'utilisation de ces propriétés de sécurité. Système, appareil, procédé, programme d'ordinateur et produit programme d'ordinateur permettant de rechercher et de sélectionner des éléments de donnée et de commande dans des procédures relatives aux messages et des ensembles de données pour obtenir une représentation automatique et complète du message et préserver l'intention du message.
PCT/US2001/023713 2000-07-28 2001-07-27 Systeme, procede et produit programme d'ordinateur pour appareil, systeme d'exploitation et messagerie multimedia interactive reseau, neutre et securisee Ceased WO2002010962A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU8467401A AU8467401A (en) 2000-07-28 2001-07-26 System, method and computer program product for device, operating system, and network transport neutral secure interactive multi-media messaging

Applications Claiming Priority (54)

Application Number Priority Date Filing Date Title
US62735800A 2000-07-28 2000-07-28
US62820500A 2000-07-28 2000-07-28
US62764500A 2000-07-28 2000-07-28
US62735700A 2000-07-28 2000-07-28
US09/628,205 2000-07-28
US09/627,357 2000-07-28
US09/627,645 2000-07-28
US09/627,358 2000-07-28
US70661200A 2000-11-04 2000-11-04
US70661700A 2000-11-04 2000-11-04
US70666100A 2000-11-04 2000-11-04
US70661500A 2000-11-04 2000-11-04
US70666400A 2000-11-04 2000-11-04
US70661400A 2000-11-04 2000-11-04
US70662100A 2000-11-04 2000-11-04
US70661300A 2000-11-04 2000-11-04
US70661000A 2000-11-04 2000-11-04
US70660600A 2000-11-04 2000-11-04
US70661100A 2000-11-04 2000-11-04
US70660900A 2000-11-04 2000-11-04
US70661600A 2000-11-04 2000-11-04
US09/706,613 2000-11-04
US09/706,615 2000-11-04
US09/706,612 2000-11-04
US09/706,661 2000-11-04
US09/706,621 2000-11-04
US09/706,609 2000-11-04
US09/706,664 2000-11-04
US09/706,616 2000-11-04
US09/706,614 2000-11-04
US09/706,610 2000-11-04
US09/706,606 2000-11-04
US09/706,611 2000-11-04
US09/706,617 2000-11-04
US27145501P 2001-02-25 2001-02-25
US60/271,455 2001-02-25
US09/912,773 2001-07-25
US09/912,936 US20020194483A1 (en) 2001-02-25 2001-07-25 System and method for authorization of access to a resource
US09/912,773 US20020196935A1 (en) 2001-02-25 2001-07-25 Common security protocol structure and mechanism and system and method for using
US09/912,901 US20020199001A1 (en) 2001-02-25 2001-07-25 System and method for conducting a secure response communication session
US09/912,901 2001-07-25
US09/912,715 2001-07-25
US09/912,905 2001-07-25
US09/912,941 US20020165912A1 (en) 2001-02-25 2001-07-25 Secure certificate and system and method for issuing and using same
US09/912,715 US20030009694A1 (en) 2001-02-25 2001-07-25 Hardware architecture, operating system and network transport neutral system, method and computer program product for secure communications and messaging
US09/912,772 US20020178360A1 (en) 2001-02-25 2001-07-25 System and method for communicating a secure unidirectional response message
US09/912,860 2001-07-25
US09/912,860 US20020199096A1 (en) 2001-02-25 2001-07-25 System and method for secure unidirectional messaging
US09/912,905 US20030041110A1 (en) 2000-07-28 2001-07-25 System, Method and Structure for generating and using a compressed digital certificate
US09/912,885 US20030023960A1 (en) 2001-07-25 2001-07-25 Microprocessor instruction format using combination opcodes and destination prefixes
US09/912,772 2001-07-25
US09/912,885 2001-07-25
US09/912,941 2001-07-25
US09/912,936 2001-07-25

Publications (1)

Publication Number Publication Date
WO2002010962A1 true WO2002010962A1 (fr) 2002-02-07

Family

ID=27586820

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/023713 Ceased WO2002010962A1 (fr) 2000-07-28 2001-07-27 Systeme, procede et produit programme d'ordinateur pour appareil, systeme d'exploitation et messagerie multimedia interactive reseau, neutre et securisee

Country Status (2)

Country Link
AU (1) AU8467401A (fr)
WO (1) WO2002010962A1 (fr)

Cited By (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004049205A3 (fr) * 2002-11-26 2004-10-28 Ibm Procede et dispositif pour permettre l'acces a un fichier multimedia via une page web
US6920611B1 (en) 2002-11-25 2005-07-19 Visa U.S.A., Inc. Method and system for implementing a loyalty merchant component
US6964695B2 (en) 2001-03-13 2005-11-15 Carbon Technologies Nv Method and equipment for removing volatile compounds from air
US7051923B2 (en) 2003-09-12 2006-05-30 Visa U.S.A., Inc. Method and system for providing interactive cardholder rewards image replacement
US7104446B2 (en) 2003-09-03 2006-09-12 Visa U.S.A., Inc. Method, system and portable consumer device using wildcard values
US7121456B2 (en) 2002-09-13 2006-10-17 Visa U.S.A. Inc. Method and system for managing token image replacement
WO2009015470A1 (fr) * 2007-08-01 2009-02-05 Echoworx Corporation Procédé et système pour délivrer des messages sécurisés sur le bureau d'un ordinateur
US7653602B2 (en) 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
US7725369B2 (en) 2003-05-02 2010-05-25 Visa U.S.A. Inc. Method and server for management of electronic receipts
US8005763B2 (en) 2003-09-30 2011-08-23 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US8010405B1 (en) 2002-07-26 2011-08-30 Visa Usa Inc. Multi-application smart card device software solution for smart cardholder reward selection and redemption
US8015060B2 (en) 2002-09-13 2011-09-06 Visa Usa, Inc. Method and system for managing limited use coupon and coupon prioritization
US8407083B2 (en) 2003-09-30 2013-03-26 Visa U.S.A., Inc. Method and system for managing reward reversal after posting
US8429048B2 (en) 2009-12-28 2013-04-23 Visa International Service Association System and method for processing payment transaction receipts
US8554610B1 (en) 2003-08-29 2013-10-08 Visa U.S.A. Inc. Method and system for providing reward status
US8626577B2 (en) 2002-09-13 2014-01-07 Visa U.S.A Network centric loyalty system
US8924395B2 (en) 2010-10-06 2014-12-30 Planet Data Solutions System and method for indexing electronic discovery data
WO2016003285A1 (fr) * 2014-07-03 2016-01-07 Storymail B.V. Système permettant de générer une vidéo
RU172100U1 (ru) * 2016-03-02 2017-06-28 Александр Дмитриевич Фролов Устройство повышения оперативности и достоверности обработки криптограмм
KR101805458B1 (ko) 2017-07-07 2017-12-07 주식회사 티맥스소프트 웹 소켓 지원 방법, 그리고 이를 사용한 웹 서버 및 웹 애플리케이션 서버
US9852437B2 (en) 2002-09-13 2017-12-26 Visa U.S.A. Inc. Opt-in/opt-out in loyalty system
WO2018213239A1 (fr) * 2017-05-15 2018-11-22 Polyport, Inc. Chiffrement empilé
CN110209533A (zh) * 2019-06-06 2019-09-06 于德媛 信息备份方法、装置及终端
CN110316203A (zh) * 2018-03-30 2019-10-11 丰田自动车株式会社 控制装置、控制方法以及存储了程序的非暂时性存储介质
CN110706147A (zh) * 2019-09-29 2020-01-17 百度在线网络技术（北京）有限公司 图像处理的环境确定方法、装置、电子设备和存储介质
CN111081237A (zh) * 2018-10-22 2020-04-28 深圳市冠旭电子股份有限公司 音箱的播放控制方法、系统及智能设备
CN111476592A (zh) * 2019-01-23 2020-07-31 丰田自动车株式会社 信息处理装置、车辆管理系统及信息处理方法
US10756898B2 (en) 2017-06-12 2020-08-25 Rebel AI LLC Content delivery verification
KR102196478B1 (ko) * 2019-10-04 2020-12-30 주식회사 레인보우브레인 블록체인 기반 인공 지능 로봇 자동화 소프트웨어 실행 결과물의 신뢰성 검증 서비스 제공 방법 및 시스템
CN112488130A (zh) * 2020-12-17 2021-03-12 苏州聚悦信息科技有限公司 一种ai的微小孔壁检测算法
CN112866613A (zh) * 2019-11-12 2021-05-28 三星电子株式会社 电子装置及其控制方法
US11132691B2 (en) 2009-12-16 2021-09-28 Visa International Service Association Merchant alerts incorporating receipt data
US11213773B2 (en) 2017-03-06 2022-01-04 Cummins Filtration Ip, Inc. Genuine filter recognition with filter monitoring system
US11263296B2 (en) 2018-02-28 2022-03-01 Wippit Ltd. Secure 3D printing
CN114201207A (zh) * 2021-11-22 2022-03-18 北京达佳互联信息技术有限公司 一种资源同步方法、装置、电子设备及存储介质
CN114338241A (zh) * 2022-03-10 2022-04-12 成都网讯优速信息技术有限公司 数据加解密方法和装置及采用该装置的网络路由器
US11516270B1 (en) 2021-08-20 2022-11-29 T-Mobile Usa, Inc. Network protocol for enabling enhanced features for media content
US11570186B2 (en) * 2019-12-12 2023-01-31 Intel Corporation Security reporting via message tagging
CN109937405B (zh) * 2016-11-08 2023-03-24 微软技术许可有限责任公司 用于发送大数据集的高级重试机制
CN115955309A (zh) * 2023-03-13 2023-04-11 浙江华创视讯科技有限公司 一种加密推理方法及其系统、设备、存储介质
TWI804301B (zh) 2022-05-05 2023-06-01 仁寶電腦工業股份有限公司 基本輸入輸出系統的驗證系統及其驗證方法
CN116701381A (zh) * 2023-08-03 2023-09-05 南京莫愁智慧信息科技有限公司 一种分布式数据采集入库用的多级校验系统及校验方法
US11811681B1 (en) 2022-07-12 2023-11-07 T-Mobile Usa, Inc. Generating and deploying software architectures using telecommunication resources
CN117131485A (zh) * 2023-09-22 2023-11-28 杭州融御科技有限公司 一种软件服务的授权方法
US20240169330A1 (en) * 2021-05-27 2024-05-23 The Toronto-Dominion Bank Systems and methods for configuring resource transfers
US12164887B2 (en) 2022-07-12 2024-12-10 T-Mobile Usa, Inc. Identifying standards-related requirements for software architectures using telecommunication resources
US12356207B2 (en) 2022-07-12 2025-07-08 T-Mobile Usa, Inc. Telecommunication resource deployment using machine learning systems and methods

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6018724A (en) * 1997-06-30 2000-01-25 Sun Micorsystems, Inc. Method and apparatus for authenticating on-line transaction data
US6044362A (en) * 1997-09-08 2000-03-28 Neely; R. Alan Electronic invoicing and payment system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6018724A (en) * 1997-06-30 2000-01-25 Sun Micorsystems, Inc. Method and apparatus for authenticating on-line transaction data
US6044362A (en) * 1997-09-08 2000-03-28 Neely; R. Alan Electronic invoicing and payment system

Cited By (79)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6964695B2 (en) 2001-03-13 2005-11-15 Carbon Technologies Nv Method and equipment for removing volatile compounds from air
US8010405B1 (en) 2002-07-26 2011-08-30 Visa Usa Inc. Multi-application smart card device software solution for smart cardholder reward selection and redemption
US8626577B2 (en) 2002-09-13 2014-01-07 Visa U.S.A Network centric loyalty system
US10460338B2 (en) 2002-09-13 2019-10-29 Visa U.S.A. Inc. Network centric loyalty system
US7121456B2 (en) 2002-09-13 2006-10-17 Visa U.S.A. Inc. Method and system for managing token image replacement
US8239261B2 (en) 2002-09-13 2012-08-07 Liane Redford Method and system for managing limited use coupon and coupon prioritization
US7374078B2 (en) 2002-09-13 2008-05-20 Visa U.S.A. Inc. Method and system for managing token image replacement
US8015060B2 (en) 2002-09-13 2011-09-06 Visa Usa, Inc. Method and system for managing limited use coupon and coupon prioritization
US7591412B2 (en) 2002-09-13 2009-09-22 Visa U.S.A. Inc. Method and system for managing token image replacement
US9852437B2 (en) 2002-09-13 2017-12-26 Visa U.S.A. Inc. Opt-in/opt-out in loyalty system
US7624917B2 (en) 2002-09-13 2009-12-01 Visa U.S.A. Inc. Method and system for managing token image replacement
US6920611B1 (en) 2002-11-25 2005-07-19 Visa U.S.A., Inc. Method and system for implementing a loyalty merchant component
WO2004049205A3 (fr) * 2002-11-26 2004-10-28 Ibm Procede et dispositif pour permettre l'acces a un fichier multimedia via une page web
US7711843B2 (en) 2002-11-26 2010-05-04 International Business Machines Corporation Method and a device for making a media file accessible via a web page
US7987120B2 (en) 2003-05-02 2011-07-26 Visa U.S.A. Inc. Method and portable device for management of electronic receipts
US9087426B2 (en) 2003-05-02 2015-07-21 Visa U.S.A. Inc. Method and administration system for management of electronic receipts
US7725369B2 (en) 2003-05-02 2010-05-25 Visa U.S.A. Inc. Method and server for management of electronic receipts
US7827077B2 (en) 2003-05-02 2010-11-02 Visa U.S.A. Inc. Method and apparatus for management of electronic receipts on portable devices
US8386343B2 (en) 2003-05-02 2013-02-26 Visa U.S.A. Inc. Method and user device for management of electronic receipts
US8554610B1 (en) 2003-08-29 2013-10-08 Visa U.S.A. Inc. Method and system for providing reward status
US8793156B2 (en) 2003-08-29 2014-07-29 Visa U.S.A. Inc. Method and system for providing reward status
US7350702B2 (en) 2003-09-03 2008-04-01 Visa U.S.A. Inc. Method, system and portable consumer device using wildcard values
US7611054B2 (en) 2003-09-03 2009-11-03 Visa U.S.A. Inc. Mobile phone including wildcard data string
US7104446B2 (en) 2003-09-03 2006-09-12 Visa U.S.A., Inc. Method, system and portable consumer device using wildcard values
US7367501B2 (en) 2003-09-03 2008-05-06 Visa U.S.A. Inc. Method, system and portable consumer device using wildcard values
US7857215B2 (en) 2003-09-12 2010-12-28 Visa U.S.A. Inc. Method and system including phone with rewards image
US7464870B2 (en) 2003-09-12 2008-12-16 Visa U.S.A. Inc. Method and system for providing interactive cardholder rewards image replacement
US7051923B2 (en) 2003-09-12 2006-05-30 Visa U.S.A., Inc. Method and system for providing interactive cardholder rewards image replacement
US7857216B2 (en) 2003-09-12 2010-12-28 Visa U.S.A. Inc. Method and system for providing interactive cardholder rewards image replacement
US8407083B2 (en) 2003-09-30 2013-03-26 Visa U.S.A., Inc. Method and system for managing reward reversal after posting
US8244648B2 (en) 2003-09-30 2012-08-14 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US9141967B2 (en) 2003-09-30 2015-09-22 Visa U.S.A. Inc. Method and system for managing reward reversal after posting
US8005763B2 (en) 2003-09-30 2011-08-23 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US7653602B2 (en) 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
US9710811B2 (en) 2003-11-06 2017-07-18 Visa U.S.A. Inc. Centralized electronic commerce card transactions
WO2009015470A1 (fr) * 2007-08-01 2009-02-05 Echoworx Corporation Procédé et système pour délivrer des messages sécurisés sur le bureau d'un ordinateur
US11132691B2 (en) 2009-12-16 2021-09-28 Visa International Service Association Merchant alerts incorporating receipt data
US8429048B2 (en) 2009-12-28 2013-04-23 Visa International Service Association System and method for processing payment transaction receipts
US8650124B2 (en) 2009-12-28 2014-02-11 Visa International Service Association System and method for processing payment transaction receipts
US8924395B2 (en) 2010-10-06 2014-12-30 Planet Data Solutions System and method for indexing electronic discovery data
NL2013117B1 (nl) * 2014-07-03 2016-07-14 Storymail B V I O Systeem voor het genereren van een videofilm.
WO2016003285A1 (fr) * 2014-07-03 2016-01-07 Storymail B.V. Système permettant de générer une vidéo
RU172100U1 (ru) * 2016-03-02 2017-06-28 Александр Дмитриевич Фролов Устройство повышения оперативности и достоверности обработки криптограмм
CN109937405B (zh) * 2016-11-08 2023-03-24 微软技术许可有限责任公司 用于发送大数据集的高级重试机制
US11213773B2 (en) 2017-03-06 2022-01-04 Cummins Filtration Ip, Inc. Genuine filter recognition with filter monitoring system
WO2018213239A1 (fr) * 2017-05-15 2018-11-22 Polyport, Inc. Chiffrement empilé
US10713388B2 (en) 2017-05-15 2020-07-14 Polyport, Inc. Stacked encryption
US10756898B2 (en) 2017-06-12 2020-08-25 Rebel AI LLC Content delivery verification
KR101805458B1 (ko) 2017-07-07 2017-12-07 주식회사 티맥스소프트 웹 소켓 지원 방법, 그리고 이를 사용한 웹 서버 및 웹 애플리케이션 서버
US11263296B2 (en) 2018-02-28 2022-03-01 Wippit Ltd. Secure 3D printing
CN110316203A (zh) * 2018-03-30 2019-10-11 丰田自动车株式会社 控制装置、控制方法以及存储了程序的非暂时性存储介质
CN111081237B (zh) * 2018-10-22 2022-06-10 深圳市冠旭电子股份有限公司 音箱的播放控制方法、系统及智能设备
CN111081237A (zh) * 2018-10-22 2020-04-28 深圳市冠旭电子股份有限公司 音箱的播放控制方法、系统及智能设备
CN111476592A (zh) * 2019-01-23 2020-07-31 丰田自动车株式会社 信息处理装置、车辆管理系统及信息处理方法
CN111476592B (zh) * 2019-01-23 2023-11-24 丰田自动车株式会社 信息处理装置、车辆管理系统及信息处理方法
CN110209533A (zh) * 2019-06-06 2019-09-06 于德媛 信息备份方法、装置及终端
CN110706147B (zh) * 2019-09-29 2023-08-11 阿波罗智联(北京)科技有限公司 图像处理的环境确定方法、装置、电子设备和存储介质
CN110706147A (zh) * 2019-09-29 2020-01-17 百度在线网络技术（北京）有限公司 图像处理的环境确定方法、装置、电子设备和存储介质
KR102196478B1 (ko) * 2019-10-04 2020-12-30 주식회사 레인보우브레인 블록체인 기반 인공 지능 로봇 자동화 소프트웨어 실행 결과물의 신뢰성 검증 서비스 제공 방법 및 시스템
CN112866613A (zh) * 2019-11-12 2021-05-28 三星电子株式会社 电子装置及其控制方法
US11570186B2 (en) * 2019-12-12 2023-01-31 Intel Corporation Security reporting via message tagging
CN112488130A (zh) * 2020-12-17 2021-03-12 苏州聚悦信息科技有限公司 一种ai的微小孔壁检测算法
CN112488130B (zh) * 2020-12-17 2023-08-15 苏州聚悦信息科技有限公司 一种ai的微小孔壁检测方法
US12131302B2 (en) * 2021-05-27 2024-10-29 The Toronto-Dominion Bank Systems and methods for configuring resource transfers
US20240169330A1 (en) * 2021-05-27 2024-05-23 The Toronto-Dominion Bank Systems and methods for configuring resource transfers
US11516270B1 (en) 2021-08-20 2022-11-29 T-Mobile Usa, Inc. Network protocol for enabling enhanced features for media content
US11924261B2 (en) 2021-08-20 2024-03-05 T-Mobile Usa, Inc. Network protocol for enabling enhanced features for media content
CN114201207A (zh) * 2021-11-22 2022-03-18 北京达佳互联信息技术有限公司 一种资源同步方法、装置、电子设备及存储介质
CN114338241A (zh) * 2022-03-10 2022-04-12 成都网讯优速信息技术有限公司 数据加解密方法和装置及采用该装置的网络路由器
TWI804301B (zh) 2022-05-05 2023-06-01 仁寶電腦工業股份有限公司 基本輸入輸出系統的驗證系統及其驗證方法
US11811681B1 (en) 2022-07-12 2023-11-07 T-Mobile Usa, Inc. Generating and deploying software architectures using telecommunication resources
US12164887B2 (en) 2022-07-12 2024-12-10 T-Mobile Usa, Inc. Identifying standards-related requirements for software architectures using telecommunication resources
US12356207B2 (en) 2022-07-12 2025-07-08 T-Mobile Usa, Inc. Telecommunication resource deployment using machine learning systems and methods
CN115955309B (zh) * 2023-03-13 2023-06-02 浙江华创视讯科技有限公司 一种加密推理方法及其系统、设备、存储介质
CN115955309A (zh) * 2023-03-13 2023-04-11 浙江华创视讯科技有限公司 一种加密推理方法及其系统、设备、存储介质
CN116701381B (zh) * 2023-08-03 2023-11-03 南京莫愁智慧信息科技有限公司 一种分布式数据采集入库用的多级校验系统及校验方法
CN116701381A (zh) * 2023-08-03 2023-09-05 南京莫愁智慧信息科技有限公司 一种分布式数据采集入库用的多级校验系统及校验方法
CN117131485A (zh) * 2023-09-22 2023-11-28 杭州融御科技有限公司 一种软件服务的授权方法
CN117131485B (zh) * 2023-09-22 2024-02-20 杭州融御科技有限公司 一种软件服务的授权方法

Also Published As

Publication number Publication date
AU8467401A (en) 2002-02-13

Similar Documents

Publication Publication Date Title
US20020194483A1 (en) System and method for authorization of access to a resource
US20020199001A1 (en) System and method for conducting a secure response communication session
US20020178360A1 (en) System and method for communicating a secure unidirectional response message
US20020165912A1 (en) Secure certificate and system and method for issuing and using same
US20030009694A1 (en) Hardware architecture, operating system and network transport neutral system, method and computer program product for secure communications and messaging
US20030041110A1 (en) System, Method and Structure for generating and using a compressed digital certificate
US20020199096A1 (en) System and method for secure unidirectional messaging
US20020194501A1 (en) System and method for conducting a secure interactive communication session
US20020196935A1 (en) Common security protocol structure and mechanism and system and method for using
WO2002010962A1 (fr) Systeme, procede et produit programme d'ordinateur pour appareil, systeme d'exploitation et messagerie multimedia interactive reseau, neutre et securisee
US8661557B2 (en) Method and system for granting access to system and content
US20200186384A1 (en) Enhanced title processing arrangement
US9355389B2 (en) Purchase transaction system with encrypted payment card data
EP0938792B1 (fr) Signatures numeriques basees sur des objets
US9525747B2 (en) Method and system for processing published content on the internet
JP4512153B2 (ja) コンテンツを確実に頒布するためのシステム
US20020082997A1 (en) Controlling and managing digital assets
US20050273705A1 (en) Method and system for automatically creating network software applications
US20030037261A1 (en) Secured content delivery system and method
EP1303803A2 (fr) Systeme et procede de distribution de contenu securise
US9727753B2 (en) Watermark access/control system and method
JP2002520953A (ja) トランスコーダを介してセンダからレシーバへ情報データを送信する方法、情報データをトランスコードする方法、トランスコードされた情報データを受信する方法、センダ、トランスコーダおよびレシーバ
CN1941691B (zh) 生成用于检测在处理期间加密数据的虚假改造的数据的设备及方法
US20030081788A1 (en) Secure printing to a web-based imaging print service
US20210084160A1 (en) Methods and systems for providing rich interactive communication services on an electronic device

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION UNDER RULE 69(1) (EPO FORM 1205A) OF 26.05.2003

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP