text:
|Publication number
|Publication type
|Application number
|Publication date
|3 Nov 2005
|Filing date
|29 Mar 2005
|Priority date
|30 Aug 2002
|Publication number
|Stefan Roever, Kevin Collins, Alex Clark, James Bruce, Shannon Thrasher, Ron Martinez
|Original Assignee
|Navio Systems, Inc.
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (78), Referenced by (206), Classifications (7), Legal Events (1)
|External Links: USPTO, USPTO Assignment, Espacenet
The present application claims priority under 35 U.S.C. 120 and is a continuation-in-part of each of U.S. patent application Ser. No. 10/439,629 (Attorney Docket No. NAV1P004X4) filed on May 15, 2003, U.S. patent application Ser. No. 10/440,286 (Attorney Docket No. NAV1P004X3) filed on May 15, 2003, U.S. patent application Ser. No. 10/414,830 (Attorney Docket No. NAV1P004X2) filed on Apr. 15, 2003, U.S. patent application Ser. No. 10/414,817 (Attorney Docket No. NAV1P004X1) filed on Apr. 15, 2003, and U.S. patent application Ser. No. 10/232,861 (Attorney Docket No. NAV1P004) filed on Aug. 30, 2002, the entire disclosure of each of which is incorporated herein by reference for all purposes.
The present invention relates to the facilitation of transactions relating to digital assets. More specifically, the apparatus and techniques described herein enable a wide variety of transactions for digital goods and services in network environments.
The Internet has become an efficient mechanism for globally distributing digital content, such as documents, pictures, music, and other types of digital content. Information can now be transmitted directly and instantly across the Internet from the content owner to the content buyer, without having to first convert it into physical form, such as paper documents, compact disks, photographs, etc.
However, the advantage of easy digital communication has also allowed digital content to be easily pirated by just about anyone with a computer and Internet access. The combination of high-speed broadband Internet access, digital content compression software (which reduces the size of digital content files), peer-to-peer file trading networks (which allows users to post content files), and lack of a viable digital rights standard, has caused the content owners to lose control of their content. Consequently, content owners are experiencing a loss of potential revenue.
In addition, the lack of standardized and transparent techniques for digital rights management is preventing a commercially viable solution from emerging. In order for such a system to be commercially viable, the system should be secure both from the user's and the content owner's standpoint, universal so that electronic device manufactures are encouraged to engineer it into their products, and transparent so that users are not required to change their behavior.
Existing systems that attempt to provide confidence between buyers include escrow agreements, third party confirmations, third party appraisals and other similar techniques. These systems are slow and complex, and they do not provide the content user with sufficient confidence that the buyers and sellers are not illegally replicating the content or otherwise attempting to sell pirated copies of works.
In addition to the pirating aspects associated with sharing digital content, users are burdened with less than ideal methods for legally sharing digital content. These cumbersome methods include transferring entire files to other users via electronic mail, instant messenger, peer-to-peer and other applications, or sharing hyperlinks via electronic mail, instant messenger, and other applications. These methods can be viewed as counter productive, anti-social and even bothersome to the users that receive or attempt to share the content. Sharing of digital content via electronic mail is a drain on resources and inefficient to the electronic mail servers, the network, and the receiving users. Sharing of hyperlinks can lead to broken links, complex URL (Universal Resource Locator) strings, and restrictions on the type of content that can be shared (i.e. linked to). Compatibility problems are widespread and create frustration when sharing digital content of a specific media type.
What is needed are advanced techniques for controlling the trading of digital rights so that the buyers are assured of an authentic copy, "fair use" is preserved for the copy, and content owners are fairly compensated.
The present invention provides a variety of methods and apparatus for enabling transactions relating to digital assets in electronic networks.
According to one set of embodiments, methods and apparatus are provided for providing access to services via a network. Access to a service title object is provided via a service interface on a first device on the network. The service title object includes service title data identifying a corresponding service and access rights to the corresponding service. In response to selection of the service title object via the service interface, the corresponding service is delivered via the network in accordance with the access rights.
According to another set of embodiments, methods and apparatus are provided for enabling transactions relating to digital assets in a network. An interface is provided on a first device in the network in which the digital assets may be managed. A first title object is automatically generated for a first one of the digital assets in response to selection of the first digital asset via the interface. The first title object includes first title data identifying the first digital asset and access rights relating to the first digital asset. The first title object is operable to facilitate transactions in the network relating to the first digital asset.
According to another set of embodiments, methods and apparatus are provided for enabling transactions relating to digital assets in a network. A first title object is generated for a first one of the digital assets. The first title object includes first title data identifying the first digital asset and access rights relating to the first digital asset. The first title object is operable to facilitate transactions in the network relating to the first digital asset. A first transaction relating to the first digital asset is facilitated by making the first title object available on the network.
According to another set of embodiments, methods and apparatus are provided for facilitating transactions in a network relating to a plurality of digital assets. A content store device is provided on the network in which the plurality of digital assets are stored. Interface code is provided to a second device on the network which is operated independently from the first device. The interface code is operable to present an interface on user devices in communication with the second device and to provide access by the user devices via the interface to title objects which are operable to facilitate transactions relating to the digital assets on the content store device. Each title object corresponds to at least one of the digital assets and includes title data identifying the at least one corresponding digital asset and access rights relating to the at least one corresponding digital asset.
According to another set of embodiments, methods and apparatus are provided for facilitating transactions in a network relating to a plurality of digital assets. A content store is provided in a first device on the network in which the plurality of digital assets are stored. An interface is presented on a user device in communication with the first device. Access by the user device is provided via the interface to title objects which are operable to facilitate transactions relating to the digital assets in the content store. Each title object corresponds to at least one of the digital assets and includes title data identifying the corresponding digital asset and access rights relating to the corresponding digital asset.
According to another set of embodiments, methods and apparatus are provided for facilitating transactions via a network. A first promissory title object is provided with which a first party may compensate a second party via the network. The first promissory title object including data identifying a transaction and a payment amount for which the first promissory title object may be redeemed. Payment to the second party is effected via the network from funds in an account corresponding to the first party in response to presentation of the first promissory title object by the second party.
According to another set of embodiments, methods and apparatus are provided for enabling transactions relating to a plurality of digital assets in a network. A plurality of asset title objects are generated. Each asset title object corresponds to at least one of the plurality of digital assets and includes asset title data identifying the corresponding digital asset and access rights relating to the corresponding digital asset. The asset title objects are operable to facilitate transactions in the network relating to the digital assets. Computer code is generated with reference to the asset title data. The computer code is operable to generate interfaces for facilitating the transactions. The transactions are facilitated by making the asset title objects available on the network.
According to another set of embodiments, methods and apparatus are provided for enabling transactions relating to a plurality of digital assets in a network. At least one key word employed in a first search initiated within a browser on the computer is identified. The first search includes a first plurality of devices on the network. A second search using the at least one key word is initiated. The second search includes at least one device on the network which is not included in the first plurality of devices. The at least one device has the plurality of digital assets stored therein. Each of the digital assets has a title object associated therewith. Each title object includes title data identifying the associated digital asset and access rights relating to the associated digital asset. The title objects are operable to facilitate the transactions. An interface is generated in conjunction with the browser for presentation on the computer. The interface includes first search results corresponding to the first search and second search results corresponding to the second search. The second search results are operable to provide access to selected ones of the title objects. A first transaction is facilitated using at least one of the selected title objects.
According to another set of embodiments, methods and apparatus are provided for enabling transactions in a network using a wireless handset. A client application is transmitted to the handset. The client application is operable to identify any digital assets stored on the handset, and to transmit first information regarding the digital assets to a digital commerce engine. In response to transmission of the first information, a first title object is generated for each of the digital assets. Each first title object includes title data identifying a corresponding one of the digital assets and access rights relating to the corresponding digital asset. The transactions relating to the digital assets are facilitated using the first title objects in conjunction with the client application.
According to another set of embodiments, methods and apparatus are provided for creating a customer account. First instructions are provided which may be used by a user of a wireless handset to transmit a first message from the wireless handset to obtain access to a first digital asset. The first message is received and a first identifier associated with the wireless handset is identified. An access code is generated and associated with the first identifier. An account corresponding to the user is created with reference to the first identifier and the access code. A second message is transmitted to the wireless handset. The second message provides second instructions for accessing the first digital asset using the access code.
A further understanding of the nature and advantages of the present invention may be realized by reference to the remaining portions of the specification and the drawings
The invention is described with reference to the figures, in which:
FIGS. 8A-E depict exemplary title management displays according to an embodiment of the invention;
FIGS. 9A-B depict exemplary title creation displays according to an embodiment of the invention;
FIGS. 10A-B depict exemplary administrative user control displays according to an embodiment of the invention;
FIGS. 13A-E depict exemplary title data according to an embodiment of the invention;
FIGS. 24A-D depicts exemplary title data according to an embodiment of the invention;
FIGS. 34A-B depict a redeem component, according to an embodiment of the invention;
Reference will now be made in detail to specific embodiments of the invention including the best modes contemplated by the inventors for carrying out the invention. Examples of these specific embodiments are illustrated in the accompanying drawings. While the invention is described in conjunction with these specific embodiments, it will be understood that it is not intended to limit the invention to the described embodiments. On the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims. In the following description, specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be practiced without some or all of these specific details. In addition, well known features may not have been described in detail to avoid unnecessarily obscuring the invention.
Various embodiments of the invention are directed to the enablements of transactions for digital goods or services through the use of titles. According to various ones of such embodiments, a title is an object that may have a number of elements and attributes including embedded digital content, ownership attributes, copy permissions, and others as described herein. A title can represent the rights to a single piece of digital content or a single resource, or it can represent the rights to a multitude of digital content and resources and in a variety of formats. The digital content rights, such as the ability to exchange or copy, are determined by the content publisher. Furthermore, a title can also represent the rights to another title or multitude of titles, which in turn express rights to digital content or resources.
Users can initiate a variety of exchanges with each other depending on the type of title and the rules associated with that title. These exchanges can take the form of trades or transfers. In the case of trades, offers can be reviewed, and then subsequently accepted, canceled, or a counter-offer can be presented. The counter-offer process can continue until satisfaction, or until trade is canceled.
According to various embodiments, in order to help protect the integrity of the trade, a chained hash cryptographic technique is used to guarantee that only a single instance of the title is in circulation at any one point in time. The title management and publisher structure may perform verification on the chained hash to ensure its integrity. The chained hash technique may be implemented in such a way as to provide benefits typically associated with one-time password and digital cash systems. However this implementation may be modified to provide a high degree of integrity around the use of titles within the ecosystem.
The chained hash technique can be combined with additional controls that work in conjunction with the security classification element to provide varying degrees of security for the title and the digital content referred to by the title. These additional controls may include cryptographic key-splitting techniques as well as multi-user and multi-factor authentication. Security class is an element that resides in the title to convey the level of security appropriate for this title. Security class is set by the publisher based on the publisher's requirements and rules. Security class can be used within the ecosystem to determine appropriate handling of the title. For example, a title with a high-security rating of 5 can force strong authentication of the user as well as strong encryption of the digital content associated with the title. As an example, a multi-user authentication requirement can be used for parental controls, whereby a guardian must also provide authentication (and acceptance) on the purchase and use of a title where a minor is involved.
The content rating system can be used by publishers to determine appropriate ratings for their content, and these ratings can be enforced by title management and resolver apparatus to ensure guardian approval. Content rating is an element within the content element to convey a rating regarding the suitability of the content. The rating system is dependent on the type of content and the regulatory factors involved (e.g. music, video, movie, etc.).
The exchange structure, specification, and rules provide the ability for the title publisher and/or the title owner to determine the exchange capabilities of subsequent owners of the title. For example, a title publisher could limit a title owner to only one trade, or even to deny trades but allow transfers. A title owner may transfer the title to another person for a limited period of time and deny that person any ability to trade or transfer. This ability to set limitations may operate in conjunction with the rules structure.
A trust structure is also implemented to provide users with a simple ability to validate the digital content they receive. The trust structure may convey that the digital content was (if applicable) rightfully issued by the content publisher. Content publishers are not bound to use the trust structure for the titles they issue but in doing so can provide assurances to the buyer.
The invention is described with reference to specific apparatus and embodiments. Those skilled in the art may recognize that the description is for illustration and to provide the best mode of practicing the invention. For example, references are made to computer servers and clients, but in a peer-to-peer network, any computer is capable of acting in either role. Likewise, reference is made to Internet protocol while any substantially comparable data transmission protocol can be used.
The users log on to title management apparatus 102 over the network and are authorized to perform certain functions and access certain data based on their ownerships and permissions, in order to manage, resell, market, barter or auction their respective titles. A digital content file stored within a content publishing structure 110 is redeemed through a pointer stored within is respective title. This pointer indicates the location of the digital content file. However, since this location could have changed since the title was created, a resolver structure 109 substitutes the updated digital content file address, if needed.
Redemption can occur in various ways. For example, the digital content file could be downloaded in its entirety, or it could be streamed to one of the client computers 112-116 and then viewed or listened locally. If the digital content file is already stored locally, redemption could allow access or playability. In the case of an online game or chat application, redemption of the digital content file could authorize participation.
In another embodiment,
In another embodiment,
The title transaction system may provide the ability for users to manage their profile information and to generate titles for accessing profile information. For example, this functionality can be used by someone to easily create a business card title and distribute that title to their associates. The title in this case would be a tag that refers (that is, points) to their "business card" profile elements containing (as an example) their name, title, business address, and business contact information. In an other example, some else could create an emergency profile card and distribute it to specific people so that in an emergency they would have access to certain personal information such as name, medical insurance number, allergies, health risks, and emergency contacts. In this particular case, the title could be a ticket. The title transaction system provides for close integration of profile information to provide significant value add for the user as they participate in a community where communication, purchasing, trading, auctioning, and bartering are common place.
As depicted in
The title object may have more than one stub object associated with it in order to convey additional information, controls, content, or other value-add not explicitly given in the original title. The stub object provides extensibility to the title without requiring a complete replacement to the title object. As an example, a value-add reseller such as a retail merchant may attach additional content or value to the original title in order to promote their product or even to make the original title more attractive for sale or trade. In another example, an additional control stub maybe attached to the original title in order to ensure appropriate handling of the title for use by minors, such as ensuring that only an edited version of the content is viewed. The use of the stub object is flexible to ensure extensibility of the title object.
As depicted in
The system employs a set of specification and rules for structuring, creating, managing, handling and using titles. The specification and rules, as well as the format of the title, are extensible to support the needs of both the user and content publisher, as well as the needs of intermediary systems within the ecosystem that handle (or interact) with titles.
In the exemplary embodiment, a tag is a title object that can be copied among users, a token is a title object that cannot be copied like a tag, but can be transferred or exchanged between users, and a ticket is a title object that is issued to a specific user, and hence cannot be copied or transferred among users.
Logical Structure and Operation
A channel support structure 612 is responsible for communicating with users and is associated with the communication procedures 622. The channel support 612 communicates over the network using a number of possible protocols including HTTP (hyper-text transfer protocol), SMTP (simple mail transfer protocol), SMS (short messaging service) and others.
The title protocol may define a standard set of protocol bindings to describe how title transactions are communicated across those protocols. However the title protocol specification may define extensions so that the title protocol can be bound to other underlying protocols as required within the ecosystem. When an inbound message is received by the channel support 612, the message is passed along to a number of other structures that decode, transform and interact with the message. For example a transform structure 614 performs a transform on the inbound data request to conform it to a normalized application interface for a core title transaction application. The use of the transform layer at this point provides standardized parsing of the transaction as it proceeds through the pipeline to the core title transaction application. A tracker 616 acts as a transaction filter to maintain a log of all the inbound messages and requests. A rule structure 618 then applies a number of possible rules to the message. The rule structure obtains its rule sets from several sources including the title itself (as defined in the title format), data storage through the data abstraction portion, and extensions that can support the retrieval of rules through other sources such as via the network. The rules include characteristics for each title, for example, whether it can be refunded, exchanged, played viewed, etc. Often, the functions that can be performed on a given title are related to the title type. For example, in the exemplary embodiment, titles of type tag can be freely distributed to all users, titles of type ticket are tied to a specific user and cannot be exchanged, and titles of type token can be exchanged with other users. When a title of type token is exchanged with another user, the user can no longer redeem that title, and the system may disable any offline content associated with the title.
For instance, the content element within a title can contain an encrypted password that is not known to the user. A program for viewing or playing the offline content, such as Windows Media Player, would read the title through an application program interface, check the rule sets, and then execute content, such as an MP3 file, using the encrypted password. Once a user exchanges the title with another user, the rule sets would be modified to reflect that the user no longer has rights to the content, and the content itself could not be played or viewed.
The rules associated to the title are developed and applied by the content publisher and by the user (or someone acting on behalf of the user). The title management and title publisher modules may provide an application and interface to easily develop and apply rules to the titles. For example, a content publisher may apply usage rules applicable to the title and the digital content and/or resource it provides evidence of rights to. In turn, a user may apply default rules within the title management module to assist in controlling and protecting their actions related to certain titles (for example, to prevent from accidentally trading a valuable title). In another example, a parent may establish restrictions on the type of content their child may access and use in their title management module.
Specialized rules, called triggers, may also be used. Triggers are rules that invoke actions that are external to the title management apparatus. For instance, a parent can be notified by email that a child wishes to redeem a digital content file for which there is some age restriction.
Specialized rules, called timers, may also be used. Timers are rules that invoke actions based on a specific time or based on a spent amount of time. For example a title may only be good for twenty four hours, or an exchange may only be valid for one week. Timers maybe combined with triggers in rule processing.
The core title transaction application 620 (core TTS) is the application that verifies the ownership of the titles by the users and that authenticates the titles and selectively permits the titles to be transferred if such rights are allowed. Among the modules that may be contained within the core TTS application are the following:
(a) A title manager module performs management functions on titles such as organizing, deleting, adding, transferring, trading, copying, backing up, viewing, and redeeming. In addition to basic title functionality, the title manager module can provide sophisticated and value-add features to allow the user a better online experience such as chat where real-time redemption and trading are available during the chat session. Furthermore, features such as sorting categorizing, searching and notify can be made available to the user. As an example, a sophisticated search capability can be implemented whereby the user can search the network for other users, titles available for bid, transaction makers, or even a secure and trusted third party lockbox with which to conduct a trade. This sophisticated discovery process may be an integral part of the TTS ecosystem. The title manager module is the primary application component that the user may interact with on a regular basis. The title manager module maybe designed to be a single-user or multi-user application depending on the specific use of the module. A single-user version can be used in a peer-to-peer network, whereas a multi-user version can be deployed with consumer aggregators. The title manager implements a lockbox feature that is responsible for securely executing trades between two parties. The lockbox provides storage for titles being traded and provides a secure environment where users can verify trades, view samples, and accept a trade. Upon acceptance of the trade by all parties involved, the lockbox may execute the trade and provide each party with an updated title and stub object-pair that evidences their new rights. The lockbox feature of the title manager can be implemented as a standalone service so that a trusted third party can provide secure execution of trades.
(b) A transaction tracker module performs the basic task of tracking all inbound and outbound transactions whether successful or not. The tracker module is configurable by the user to determine the level of tracking to be performed based on the user's requirements. The tracker may be used to provide a record of all transactions performed by the user such as trades and transfers. The tracker may be used by all core TTS components for creating a record of all transactions (for example, those performed by the resolver and content publisher). The tracker may record transactions in a data repository using the data abstraction portion.
(c) A rules builder module performs the task of building rules to be associated with the titles and processing of the titles. The rules builder module may provide an easy to use interface for the user to create and build rules that can be embedded within a title or used during the processing of a title. Rules that are not embedded within a title may be stored in a data repository using the data abstraction portion. The rules builder may provide an extension capability to apply rules developed external to the rules builder ensuring the adaptability of title processing.
(d) A title resolver module that the important task of resolving all titles presented. This process involves all applicable tasks to the title presented including verifying integrity of the title, validating the title, ensuring ownership of the title, decoding and decrypting the necessary title elements and retrieving the content or resource requested. The title resolver may be responsible for executing and acting upon rules and triggers that are applicable to the title presented. An additional function of the resolver would be to refresh old titles. For example, if information contained within a title became outdated, this information could be automatically refreshed either by replacing the title completely or by adding a new stub object that updates the information. In addition, the title resolver may invoke additional processes as required such as the CODEC module.
(e) A state server module that maintains and verifies state associated with the use of titles throughout the ecosystem. The state server may work in conjunction with the title resolver in order to verify the validity of the title and generate new stub objects associated with the title on every redemption and exchange. The state server may be a high-capacity, high-availability, and high-performance system that can be widely distributed and chained in order to perform fast validation for titles in use. The state server may perform functions and algorithms associated with the chained hash, one-time password, and key-splitting techniques.
(f) A title publisher module performs the tasks associated with publishing (that is, creating new titles). The title publisher provides an easy to use interface for a user to identify, organize, and group new content (or resources), and then generate a new title or title template that points to that digital content or those resources. Titles can be generated on the fly and immediately by the title publisher which would then invoke the title manager to store the newly generated titles. Alternatively, the title publisher can generate new title templates that would describe the contents of the title but would not immediately generate a title. Title templates could be used in a variety of ways by the content publisher, for example by the content publisher's online shopping site to automatically generate titles when a buyer purchases new content. The content publisher stores work in progress (such as grouped publishing efforts) in a data repository using the data abstraction portion. Title publishers may provide sophisticated functionality to enhance the online experience for content publishers such as organizing content and title publishing into projects, sharing projects, and allowing community projects. Workgroup and workflow capabilities can be built into the title publisher as well as creating single-user and multi-user versions. As an example, a multi-user version can be implemented by a consumer aggregator or service provider in order to perform title publishing activities on behalf of a user community. Enhanced features may provide additional value to people using the title publisher such as verifying pointers to content files and resources, automatically obtaining icons, and even pushing titles and content out to servers.
(g) A rating system module performs rating tasks on transaction records to support billing requirements. The rating system may be flexible to support the variety of billing options required within the ecosystem. The rating system may act on transaction data but may maintain separation between the data sets to ensure integrity of the transaction log.
(h) A CODEC module performs coding and decoding functions on the content retrieved by the title resolver. The primary purpose of this module is to encapsulate content in a secure package as determined by the security required of the title and established by the rules. For example, this module can perform digital watermarking of music and image content, and it can also be used to encrypt the content in a traditional digital rights management package. Additionally, the CODEC can be used by the resolver to decode contents within the title before processing by the resolver. The CODEC may provide mechanisms to support these functions as required within the ecosystem.
(i) A billing interface module provides an interface to the billing system operated by the user or entity running any of the core TTS components or modules.
(j) A transaction viewer module provides an interface for the user to view transactions recorded by the transaction tracker.
(k) A content interface module performs the tasks associated with retrieving the content. This module may generally be invoked by the resolver. The content interface module may be extensible to support a variety of content and resource systems in use by content publishers.
(l) A synch & replication module performs synchronization and replication across components and modules within the TTS system. This is required for a number of functions including (but not limited to) synchronization and replication of transaction log entries, synchronization of titles across title management modules in a highly distributed environment, and replication of title databases to support redundancy and high-availability.
(m) A crypto interface module performs symmetric and asymmetric cryptographic functions as required within the TTS ecosystem.
(n) An authentication and authorization module performs the type authentication and authorization required by (and specified by) the title or other ecosystem configurations. Authentication may not be required in certain instances, or can be as simple as providing an identifier for "free" use. Strong authentication may be required for other instances and may be enforced by the ecosystem components. Strong authentication can take the form of two-factor such as Smartcard and PIN, or via mobile phone using a SIM card and a PIN, or via any other supported method such as a SecurID token card. In basic form, authentication may be a username and password. Authorization may provide fine-grained access control to core TTS applications as well as to use titles within the ecosystem. Authorization may be based on rules established within titles and configured as part of the implementation of core TTS applications.
(o) A payment interface module provides an interface to a payment system operated by a user or entity of the core TTS components and modules. This permits real-time and batch processing of payment requests as configured by the user or entity.
(p) A cache management module performs basic caching functions of the content or resources retrieved by the title system. This function may provide performance benefits using cached content versus retrieving new content on every request for the same content.
(q) A user registration module performs registration of new users into the core TTS components and modules. This may be used to establish new users in a single user environment such as peer-to-peer, as well as establish new users in a multi-user environment such as that hosted by a consumer aggregator. A consumer aggregator is an entity that provides services to a consumer base (i.e., ISP, mobile operator, etc.).
(r) A transaction maker module performs transaction maker functions such as operating an exchange for the sale of titles, perform licensing of content represented by the titles, maintaining a book of trades, closing and clearing trade transactions, and performing additional value add as determined by the market.
(s) An intelligent data retrieval and query module integrated with the data abstraction portion in order to perform intelligent searches and queries on a variety of data in a variety of disparate locations. The IDRQ module can combine, map, and match data before presenting it to requesting applications through the data abstraction portion. Persistence and caching can be developed into the IDRQ module to enhance performance on multiple and frequent queries/searches.
(t) A web crawler module performs searches on the web to catalog content and provide a mechanism to automatically generate titles that represent the content that has been discovered. The web crawler module can be used statically or dynamically executed based on configuration of the implementation and/or on inbound requests. The web crawler module could interface with the intelligent data retrieval and query system attached to the data abstraction layer for intelligent searches and retrieval of web content.
(u) A discovery mechanism that can be used by all appropriate modules for discovering TTS resources that may be available on the network. The discovery mechanism may allow TTS modules to participate in a peer-to-peer environment as well as collaborate on activities. The discovery process can ensure that trust third parties are available for conducting secure transactions and well as simplifying the user and content publisher experience for clearing titles through the ecosystem.
In the outbound stream from the core TTS, the rules structure 618 then performs certain functions on the outbound information according to rules stored in the data 650 and/or embedded in the title. The tracker 616 checks to ensure that the outbound information matches the inbound requests so that no inbound messages are dropped or ignored and that outbound message are responding to legitimate inbound messages. The tracker may log transactions in accordance with the configuration. The transform 614 converts the outbound information from a normalized format into a format that conforms to a user profile or preference, as well as based on incoming requests for particular transforms. For example, the data can be transformed into WML for display on a WAP enabled phone, or into HTML for display on a web browser. Certain transforms can be executed based on rules established within the system. The profile or preference data as well as the transform templates are retrieved from the data portion 650 in order to perform the transform. Finally, the channel support 612 communicates with the user of the network in a native protocol format.
In another embodiment,
The title manager 712, content publisher 714, transaction maker 718, content creator 716, and hosting provider 720 are coupled to each other using a network protocol 724 such as TCPIP over the Internet. The client device 704 can be coupled to title manager 712, content publisher 714 and transaction maker 718 using any one of a number of network protocols. Among these are HTTP 706, E-Mail (SMTP) 708, and SMS 710.
Initially, the content creator 716 creates a digital content file, such as an MP3 song, as well as a title associated with the digital content file. The creating user interacts with a display as shown in
Users desiring the digital content file may access the transaction maker 718 using the client device 704. Transaction maker 718 functions as a marketplace where digital content buyers and sellers can transact with each other in a secure environment. When a user agrees to buy the digital content file from a seller, in this case the content publisher 714, the transaction maker 718 communicates this to the title manager 712, which in turn, modifies the title of the digital content file with the new rights just purchased by the user. The user can now redeem the digital content file from the content publisher 714 and download it to the client device 704.
If the user desires to transfer the title to a new user, and the title's security indicia allows it, the user can become a digital content seller and post an offer to transfer the title on transaction maker 718. As before, when a new user agrees to buy the digital content file from the user, the transaction maker 718 communicates this to the title manager 712, which in turn, modifies the title of the digital content file with the new rights just purchased by the new user. The buyer can now redeem the digital content file from the content publisher 714 and download it to the client device 704. The seller can no longer access the digital content file on the content publisher 714.
In this example, the user selected mySongArtist#3 814 in the title folder pane 806, and is displayed the owned titles to mySongArtist#3 songs 812. From this display, the user has the option to play 813 the song on the user's client computer, trade 814 the title to the song to another user, or delete 815 the title altogether.
If the user selects one of mySongArtist#3 songs 812, a more detailed title content pane 842 appears, as shown in
For example, if the user chooses to trade 814 mySong#3, a trade Preparation pane 862 appears, as shown in
The user must select whether to trade or transfer 864 the title of mySong#3 with another user. Additionally, the user may be asked if they would like to list it on a barter site ("list on barter site") or post it to a transaction maker site ("post to transaction maker"). The user can enter description of the mySong#3 in the description field 866, as well as a note in the Personal Note field 870 to the user with whom the trade is being transacted. In the trade with whom field 868, the user enters the e-mail or mobile phone number of the user with whom they wish to trade. Once this information is substantially complete, the user selects the user selectable button trade title 872 to proceed, or the user selectable button cancel 874 to cancel the transaction.
The e-mail and mobile phone numbers are used to provide examples of identifying trading parties. The title transaction system has been designed with a flexible and extensible title format to accept and support a variety of naming schemes, including but not limited to domain name, phone numbers, X.500 naming, and LDAP.
The display is divided into two sections, a new project pane 902, and a project list pane 908. A project is a set of digital content files that share the same title object. If the user opens myprojectName#3, 910 for example, a project detail display 920 appears, as in
Digital content files can be quickly added to a project by entering the name of the directory in which they are located into user input field 952, and selecting the add files user selectable button 954. Furthermore, information contained in the title is shown and can be modified through fields the project detail pane 921 such as: name field 922, creator field 924, type field 928, category field 930, description field 932, location field 934, quantity field 936, value field 938, mime type field 940, rating field 942, sample at field 944, and icon field 946. When the users wish to save the information in the title, the user selectable button update 948 is selected.
The business tab 1032, as shown
Methods of Facilitating Merchant Transactions
Current online payment systems commonly require bank cards, such as Visa or Master Card. In order to complete a purchase, customers must enter the bank card account information, along with personal contact information, into an online form at the merchant Internet site. Often, the information is stored by the merchant to simplify future customer purchases. For instance, instead of having to re-enter the information, the customer can just authenticate with a login and password, and complete the purchase.
Customer fears about data security and confidentiality, however, have inhibited ecommerce growth. And although security systems have greatly improved, criminal sophistication has also increased. Customers are not only inconvenienced with having to enter and re-enter account information at every merchants site, they are also concerned with propagation of their account information, protection of their privacy at each of the merchants site, and tracking of their habits and activities online.
Because of the distributed and anonymous nature of the Internet, online merchants are prone to both fraudulent bank card transactions and malicious hacking attacks. These same merchants, however, cannot remain in business if their attempts to increase security result in unintended customer frustration. Modern payment systems must both enhance the customer buying experience and be secure. A modern payment system must also support anonymous payment methods similar to the physical cash schemes that are currently in use throughout the world.
Consumer's device 1202 presents the user interface of the online title manager and wallet through which titles and digital content files are managed, transacted, and delivered. The device can be almost any type of computing device that can communicate with the DCE, including desktop computers, laptops, PDA's, and mobile phones. The title manager 1208 located in the DCE provides title management services to the consumer such as adding, viewing, and trading titles. Additionally, the title manager 1208 provides wallet functionality for viewing accounts, currencies, and receipts as well as handling payment processing on behalf of the consumer. Optionally, the functionality offered by both the consumer's device and the DCE can be packaged in a number of ways including a completely integrated application to be run on a consumer's device such as a desktop computer.
The merchant site 1210 is an online merchant system that provides both web-based and e-commerce functionality such as catalog, product information, product configurators, shopping pages, shopping cart, and payment services. While only one merchant site is shown in the diagram, the invention can support any number of merchant sites. The merchant site 1210 is further comprised of title-enabled components as shown in
The third party digital lockbox 1212 in
The title enabled payment provider 1214 is an online payment provider service that is title enabled, in that they can support title based transactions. While only one title enabled payment provider is shown, the invention can support any number of title enabled payment providers. In addition to supporting titles, a title enabled payment provider 1214 would provide services typical of a payment provider such as payment processing, gateways to payment networks, and merchant accounts. As shown in
Each of the system elements shown in
As previously described, a title is an object that may have a number of elements and attributes including embedded digital content, ownership attributes, and copy permissions. In this example, a consumer wishes to buy a product or service from a merchant using a title transaction. A purchasing transaction generally comprises two or more separate titles: a product title or titles being offered by the merchant; and a payment slip title or payment titles being offered by the consumer. The product title or titles give the title owner specific rights to the product, for instance, the ability to play a song. The payment slip title is a financial instrument that authorizes a payment provider to pay the merchant for any product titles purchased. Once the transaction is complete, the consumer would be in possession of the product title or titles and the merchant would be in possession of the payment slip title or payment titles.
For instance, a customer would use a web browser on customer's device 1202 to access a merchant site 1210 through online title manager 1204. When the merchant site determines that the transaction is title-enabled, it presents the product title choices and displays the consumer's title payment options. Once items are selected for purchase, the merchant site places the product titles in a digital lockbox 1212, generates a pre-filled sales order title comprising transaction details including a transaction number, product title information, purchase detail, and information on the digital lockbox 1212. The sales order title functions as an electronic invoice or promise of payment for the merchant 1210.
The sales order is transmitted back to title manager 1204 and stored for the consumer to view, select payment type, and approve using the consumer device 1202. Once approved by the consumer, the title publisher 1206 may generate a payment slip title using the sales order title as a guide. The payment slip title is transmitted to the digital lockbox 1212 and the merchant 1210 is notified. The merchant 1210 verifies the payment slip title in the digital lockbox 1212 and completes the transaction by releasing the product titles to the customer. A receipt title can also be generated and included in the transaction if requested or required. The merchant 1212 then captures payment from the customer by forwarding the completed payment slip title to the title payment provider 1214 for payment. Alternatively, the merchant 1210 can use a standard collection process such as that used for credit card processing, and deal directly with a traditional payment provider 1216.
As described previously, a sales order title is created by the title publisher 1210 b operated by the merchant site 1210 as shown in
The title content pane 1406 presents summarized information 1408 for account, currency, or receipt titles. Title content pane 1406 also allows the consumer to modify authorized entries within the titles. For example, the user has selected the dollars currency title 1412. This displays a summary of the currency amounts contained with the title, as well as allows the user to top up the account 1410 with additional currency.
Methods of Facilitating Contact Management
The exchange of paper business cards has been a familiar part of business for many years. The advent of the Internet enabled business cards to be digitized, and the exchange to be electronic. And while this was certainly easier and faster, digital business cards still suffered from the static content inherited from paper business cards. Previously, there had been no optimal way to update transmitted digital business cards short of permanently maintaining distribution lists and re-transmitting the updated digital business cards themselves.
The hosted digital commerce engine 2303 (DCE) is intended to depict an example implementation of the invention whereby the DCE hosts the title enabled systems on behalf of consumers that use devices 2302 to access the DCE. The title enabled systems include the profile manager 2304 that stores and manages the consumers profile information including their contact information, the title manager 2305 that stores and manages the consumer's titles, and the title publisher 2306 that generates titles for the DCE. In other embodiments of the invention, these title enabled systems may reside independently of each other, or even be integrated into a desktop application.
The electronic mail system 2307, short message service system 2308, and instant messenger system 2309 depict external systems that can be used to transmit and deliver titles to other consumers that may or may not use an online title enabled solution. Each of these systems would transmit Titles using their own network protocols and network systems. For example, an electronic mail system 2307 can deliver a title as an attachment to an electronic message using the SMTP protocol. The recipient can retrieve the message using the POP3 protocol, and open the attachment in a title enabled application.
An additional hosted digital commerce engine 2310 is shown in
As previously described, a title is an object that may have a number of elements and attributes including embedded digital content, ownership attributes, and copy permissions. In this example, a contact title can redeem a single contact record, such as an electronic business card, or a contact list composed of multiple contact records, as in business directory. The contact record contains information that would be commonly found in a business card, such as full name, company name, address, phone number, email, etc. The contact title comprises as a pointer to the location of the contact record or contact list. That is, it directs the title management system to the specific online profile manager 2304 upon which the contact record or contact list resides.
For instance, a contact owner creates a single contact record and stores it on a specific profile manager 2304. The owner then requests a contact title, which would then be generated by the title publisher 2306 and stored in the title manager 2305 for distribution by the contact owner to users. Users could then use the contact title to redeem the latest contact record whenever needed.
The profile manager 2304 can store any type and quantity of information on behalf of the user including business, personal, financial, preference, and emergency information. Furthermore, any variation of contact titles can also be generated by the title publisher 2306 on behalf of the user. The titles can be any number of tags, tickets, or tokens as deemed necessary by the user. For instance, a tag can be published that points to business contact information as described previously. This tag can then be freely copied and distributed to other business recipients. By redeeming the tag, the recipient will only be able to dynamically read the business contact information from the profile. Alternatively, a ticket can be published that points a trusted business associate to financial information. This ticket can be redeemed by the business associate to dynamically read certain financial records within the profile to support the users business needs. Another example would be to give a ticket to a spouse in order to read and update certain profile records.
Contact titles can refer to individual contacts or a list of contacts, or set of lists of contacts, or even to other contact titles. This allows groups to be established and easily shared among members, with each member gaining controlled and granular access to dynamic and up to date information on other members. These types of titles would be similar in structure to the titles shown in
Alternatively, the user can use an application such as a Microsoft Windows application (e.g. Microsoft Outlook) or a Macromedia Flash application to access the title manager and request title listings. In this case, these applications can have the added benefit of caching contact information, to enhance performance, reduce network traffic, and work offline. In this case, the application can retrieve contact information as the user requests and cache it for further reference, or can automatically retrieve contact information in the background and update it on a frequent and scheduled basis. This type of support allows the user to remove their device 2302 from the network and still view contact information. Another alternative is to have the title management functionality incorporated directly into the application along with the title data table.
Title Structure & Management
In another embodiment, a title structure is employed to optimize the description, creation, management and use of titles. Although, the structure of title objects as described herein maybe representative of certain technologies and formats such as XML, this is only as an example and to demonstrate one embodiment. A title object can be represented in a number of formats including XML, ASN.1, or other proprietary formats including textual and binary structures.
Although certain examples of the title structure are presented, the structure is intended to represent any number of digital and physical assets such as digital content, including music, images, video, and text, as well as physical goods such as computers, cameras, vehicles, and appliances. Furthermore, a title can be used to represent virtual assets such as an online experience created through a series of activities and events, and can also represent currencies such as cash. In one embodiment, a title structure can be used to represent both a digital and physical asset such as the identity of a person, whereby the person has physical assets associated with their identity and also digital assets associated with their identity. Titles may also represent digital services delivered over a network.
Referring now to
In one aspect of the invention, a set of stub elements can be coupled to a specific title, to further optimize a title's content, attributes, and security indicia. In another aspect of the invention, a stub element can be created and coupled to the title, after the title is created. In yet another aspect of the invention, a stub element can be coupled to a set or group of titles as specified in the stubs binding information. This permits efficient coupling of stubs to titles.
Title element 2902 comprises a structure used to describe the title and the content (or asset), and express the rights associated with title object 2901. Title object 2901 can be issued for a specified period of time or can be left infinite. The integrity of title object 2901 can be further protected by the use of cryptographic algorithms. In one embodiment, a digital signature is used. In another embodiment a chained hash is used. Information within title element 2902 can be overridden by information contained within stub element 2902, as long as stub element 2902 was issued by the same entity as title object 2901, and further specifies what information is being overridden. In another embodiment of the invention, the issuer of a title object can delegate authority, thereby permitting other authorities to issue stubs on its behalf.
In one embodiment, title element 2902 is the only substantial piece of a title object 2901 that can be stored in a lockbox and inspected by participating parties in a trading transaction. This embodiment provides for separation between the descriptive information provided within a title element (2902) and security indicia, and/or content, and/or additional value-add information that maybe contained in stub elements (2903) that are coupled to the title. As an example, an effective separation permits trading parties to inspect the title that is being traded without comprising the security of the security indicia.
Stub element 2903 is a flexible extension mechanism to the title object 2901, and can be used to convey any related and appropriate information such as value-add content or additional rule processing. Each stub element 2903 can be issued and signed by different entities and can have different lifetimes. In one embodiment, stub element 2903 is optional for a tag. In another embodiment, an authenticator stub must be included for all valid tickets and tokens. The authenticator stub contains the security indicia that are used to authenticate a valid instance of a ticket or token.
Owner component 3005 comprises any valid type of identity indicia in context to the applications that create, manage, and use titles. The identity indicia maybe formal or informal depending on the requirements for the applications. For example, the identity indicia for the owner can be a name, email, phone number, X.500 Distinguished Name, user ID, tag pointer, etc. The identity indicia can include technical detail used to authenticate the owner. For example, the identity indicia may provide technical detail sufficient for an application to prove identity through the use of X.509 digital certificates or through the use of a biometric device. Similarly, the invention can utilize the identity indicia to instruct an application relying on the title to properly authenticate an owner through trusted sources such as a remote access server, or through a domain controller and rely on that trusted sources to properly authenticate the owner using standard means such as username and password. In one embodiment, owner component 3005 is optional for a tag and a token, but is required for a ticket.
Content component 3006 can comprise applicable information pertaining to an asset such as a digital content file associated with title object 2901. In one embodiment, content component 3006 comprises a pointer defining the location of the digital content file. In another embodiment, content component 3006 comprises a query that can be used to obtain the digital content file. Content component 3006 can further comprise additional information such as ID, name, creator, rating, etc. A single title object 2901, as shown in
Rules component 3007 comprises statements specifying the specific rules that are applied to the use of the title, as well as procedures for monitoring events associated with title object 2901, as shown in
Custom component 3008 comprises custom information desired by title object 2901 publisher. In one embodiment, custom 3008 can contain any text and/or valid XML, which in turn can be referenced throughout title element 2901 or stub element 2902. The custom component may also contain pointers, references, or links to additional information or resources that are applicable to the title object.
In one embodiment, manifest component 3009 comprises reference information that must be included as part of title object 2901. For example, if a stub element must be included along with title object 2901, then it could be referenced here. In another embodiment, external data that must be included as part of title object 2901, can also be referenced within the manifest component. Applications that process the title can also process the content or referenced content within the manifest, and in another embodiment use this manifest as part of an integrity check of the title object.
Signature component 3010 comprises cryptographic information used to verify the integrity of title element 2902. In an embodiment of the title object, the signature component can be an XML Digital Signature block in compliance with the W3C. In another embodiment, the signature component may contain proprietary cryptographic information used to verify the integrity of the title, as well as provide functionality generally associated with digital signatures.
FIGS. 31A-B depict simplified diagrams according to one embodiment of the invention, in which components of stub element 2902, as shown in of
Referring now to
In one embodiment of authenticator component 3106, a chained hash technique can be employed to authenticate the title. Authenticator component 3106 would contain the encrypted seed for the hash, a copy of the current valid hash in the hash chain, and an algorithm identifier, all of which would be used by a state server to authenticate the title in conjunction with an index that the state server maintains. In another embodiment, a hash tree can be implemented within the authenticator stub to support divisible titles. The hash tree technique can be employed by titles that represent cash or some form of currency that can be divided.
In another embodiment, stub content 3104 comprises embeddedcontent 3107, which can further include a digital content file. Embeddedcontent 3107 can be also be used by issuers who wish to provide an option to their customers for embedding content directly into title object 2901. Advantages includes additional functionality in processing title object 2901 (for example, while executing a trade only title objects are included in the lockbox, therefore eliminating any potential security exposure by having embedded content directly inside the title object 2901). In another embodiment, the embeddedcontent can contain textual information or even XML structured information.
In another embodiment, stub content 3104 comprises rules component 3108. In another embodiment, a rules component 3108 procedure can override rules component 3007 procedure, as shown in
Other component 3109 comprises other functionality that may be included in stub content 3104 and defined by the publisher of the title and understood, interpreted, and processed by applications involved in the title transaction ecosystem.
Referring now to
Titleid component 3201 comprises the unique identifier associated with the title. In one embodiment the titleid is a GUID (globally unique identifier). In another embodiment, the titleid is a unique identifier within all titles created by a single issuer. The identifier used in title id can be formal or informal, registered or not registered. Titletype component 3202 comprises the type of the title object 2901 such as tag, ticket, or token and states the type in this component. The type can be specified as a textual string element such as "Tag", "Ticket", or "Token", or in another embodiment can be specified through formal or informal identifiers such as a registered OID (object identifier). In another embodiment, titletype can provide a formal structural hierarchy to the title such that title can be associated with a family of titles, and can be used to describe how the title was formed based on a type of inheritance. The titletype would contain specific title-typing indicia such that the processing applications can retrieve, understand, interpret, and process properties associated with ancestor titles. In another embodiment, the titletype can be used to reference the template that was used to create the title.
Titlename component 3203 is a short text string used to name the title object 2901, and is similar to a file name. Titledescription 3204 comprises a longer text string, and can be used to contain primary descriptive information regarding title object 2901, including ID, type, name, description, and technical elements used for processing. Typeofcontent 3205 comprises the type of content referred to by title object 2901. In one embodiment, Typeofcontent 3205 can include terms such as "mixed", "music" or other descriptive term. In another embodiment, typeofcontent can contain more formal definitions such as MIME type classifications or industry standard codes such as that used in Rosettanet and EDI systems. Additionally, typeofcontent can be used to specify a title content such that other titles may be embedded within or specified by this title. In this example, a title can refer to other titles and convey additional rules or taxonomy regarding the referred to or contained titles.
Securityclass component 3206 comprises security classification identifiers that can be used by processing applications. In one embodiment, the classification can be as simple as a numerically ordered scheme that identifies the security processing level required of this title from an range of low to high. In another embodiment, the classification scheme can be a registered scheme or even a more technically descriptive classification such as that used in ASN.1 encoding schemes for X.509 certificates. Priorityflag component 3207 comprises a priority indicator to be used by processing applications to apply appropriate levels of processing such is the case for service level agreements, or quality of service guarantees. For example, a high priority setting can indicate to processing applications that this titles requires priority processing (that is, preferred status) and can be placed at the front of the queue. In an embodiment, the priorityflag can be textual, numerical, or structured information to be used by processing applications. In another embodiment, the priorityflag can provide or reference technically descriptive service level agreement detail that can be directly processed by applications, such as that used in Policy Based Networks or Directory. Enabled Networks.
Trackit component 3208 comprises indicators for the level tracking information that should be maintained by processing applications, such as if title object 2901 must be tracked on every event. In another example, the trackit component can specify that both the transaction request and response information be tracked in the log. In another embodiment, the trackit component can specify that every action must be tracked in a stub element 2903 of the title object 2901. By tracking transactions and events in the stub, the title can maintain a journal of activities and provide a self contained log. The logging activity within a single stub or multiple stubs can be used as a record of the activities that comprise the titles experience. This can be used as an effective tool for analysis and reporting, and is also an essential aspect for titles creating and representing an experience, whereby the title maintains its own state. For example, a title can be used to create a digital treasure hunt, where the owner of the title redeems it for each step in the treasure hunt. Completing each step requires that the title maintain its state and also record the activities completed by the owner. When the treasure hunt is complete, the owner is entitled to receive a prize. The trackit component 3208, along with the recording ability of stubs, permits the title to create this experience. The title also becomes a record that can prove a sequence of steps. The tracking ability enabled by the trackit component 3208 and stubs can be used by rules components for fine-grained control over a title and for event processing. For example, based on a specific step within an experience, the title can initiate certain actions. This would require understanding of the current state and the sequence of steps that led up to the event.
The membership component 3210 comprises title membership information such as the group or family that a title may belong. In one embodiment this could be implemented as a group identifier and in another embodiment this could be implemented through references.
Referring now to
ContentID component 3302 comprises an identifier for the content. In one embodiment, contentID component 3302 can be used to convey any type of content ID used by content publishers such as DOI, OID, or a proprietary scheme. In another embodiment, the identifier could be a serial number. Contentcreator component 3303 comprises a text string identifying the creator of the content such as a digital content file or asset. The contentcreator component can be a textual string, an identifier, or even structured identity indicia on the creator as described in other identity related components such as the owner component 3005. Contentdescription component 3304 comprises a longer text string, and can be used to contain primary descriptive information. Contentcategory component 3305 comprises the categories or taxonomy of content referred to by title object 2901. In one embodiment the contentcategory can be a simple text label, while in another embodiment the contentcategory can be a structured component with detailed taxonomy on the content referred to by the title object.
Quantity component 3306 comprises the instances of a single digital content file associated with title object 2901. Value component 3307 comprises the economic price associated with title object 2901. Icon component 3308 comprises the computer icon to be displayed in the title management system or by processing applications. Shortform/shortformpointer component 3309 comprises a pointer to a sample of the content or asset such as an image, thumbnail image, short sample audio, or low quality audio. In another embodiment, the shortform component can contain the actual sample such as textual information. For example, the shortform can contain a name and email address for a contact record. In this case, the shortform provides quick and immediate access to information, whereas the title provides access to the entire contact information. Shortform and shortformpointer and useful components when titles are traded and shared.
Redeem 3310 component comprises methods for the redemption of the title object. Redemption of the title object can be obtaining the digital content that the title refers to, or can also be the trading of the title or the sharing of the title. The redeem component is a structured component that has one to many methods describing in detail how the title may be redeemed. This structure is flexible to accommodate a variety of redemption processes and procedures that are required by publishers and consumers of title objects..
Rating component 3311 comprises a content rating for the digital content file, such as the MPAA rating of "G", "PG", etc. The detail within the rating component is context specific according to the content or asset referred to by the title object. Contentintegrity 3312 comprises a cryptographic message digest which is used for verification of digital content integrity. The contentintegrity component provides attributes to identify the method employed for integrity checking such as the SHA-1 algorithm. Keywords component 3313 comprises a list of keywords associated with the content or asset. This can be used during queries, searches, and categorizations.
Referring now to FIGS. 34A-B, redeem component of
In another embodiment, a query component 3404 comprises searching procedures for the digital content file. This component has attributes to identify the query mechanism being described. In one embodiment, the query component can contain SQL queries in order to obtain dynamic information from a database. In another embodiment, the query component can contain an XQuery statement to obtain data from an XML data set or document collection. In another embodiment, the query component can contain computer executable statements to process some query business logic in order to calculate or process the results. The rules component 3405 comprises statements specifying the specific rules that are applied before, during, and after redemption. The structure and statements contained within the rules component is similar to that described for the rules component 3007 in the title object, in that it can contain and describe any type of rules statement such as XSLT, XrML, BRML; and can also contain pointers or references to external rules. However, this rules component is specifically associated with a redemption method.
The pointer component 3406 specifies a pointer to the content or asset being referenced by the title object. The pointer structure is specified in the component and in one embodiment can be a simple URL. In another embodiment this may be a URI, XPointer, XLink, coordinates or other pointer description to the content or asset.
Other component 3407 comprises additional functionality that may be added to the set of methods 3402. The other component accommodates proprietary or custom information to be used during redemption and should be understood, interpreted, and processed by applications.
Referring now to
Referring now to
Referring now to
The next step in the lifecycle and management is the production or creation stage, as shown in create title 3604. The create title 3604 stage involves a "factory" or similar process to produce titles. Production can be on-demand, in bulk, or as scheduled depending on the requirements of publishers. Implementations of the create title 3604 process can consider request, complexity, reporting, control, and performance factors to ensure that production demands are satisfied. Additional functionality supported by the create title 3604 process can include warehousing and distribution of titles that are created. Warehousing and distribution functions can be used to service requests by several parties involved in the title object lifecycle such as in syndication and content distribution networks. The creation process is described further in
The next stage in lifecycle and management is the storage of titles as depicted in 3606. This stage would include typical title object storage and management functions including securing title objects as they are stored, properly authenticating owner's access to title objects, and viewing title objects that maybe stored. Storage functions can be implemented as server applications or incorporated directly into client applications that run directly on consumer computing devices such as desktop computers and mobile devices. Server applications can be implemented to support a community of users. Storage of title objects can be a critical stage in the lifecycle as a title object may tend to spend a majority of its life in storage. Therefore, it will be essential for applications involved in this stage to provide proper handling such as ensuring that security requirements are satisfied.
The next stage in the lifecycle and management is the consuming of titles as depicted in 3608. Consuming of titles primarily involves the use of titles in order to experience the content. This is accomplished by redeeming the title using the variety of redemption methods defined within a title object. Applications that are involved in this stage can be complex as they must effectively process the title object, including rule processing, business logic processing, interpretation of descriptive information, resolution of references and pointers, and most importantly the authentication of titles and owners. In an embodiment of the lifecycle there would also be the communication, interpretation and processing of fine-grained trust between all parties involved in the lifecycle. In one embodiment, the title manager, resolver, state server, content proxy, and content server would all be involved in the consumption of a title object.
Consume title 3608 component can tie back to the design title 3602 and create title 3604 components to complete the lifecycle. In one embodiment, the detail obtained through the consumption and use of title objects will be essential information used in the design of subsequent and additional titles. In another more direct embodiment, the consumption of title can be effectively tracked and directly used by one title object to create a new or enhanced title object template. In this instance, as a title is consumed it will progressively track and update various properties within its stub element structure. These properties will combine to represent the experience of the title object, and on a particular redemption method will generate either a new title object template or an enhanced title object template. The new or enhanced template can then be used to create additional title objects. In this embodiment, a title can be an effective tool and mechanism for use in expert systems or artificial intelligence engines. In another embodiment, a title can be used as a data source into the create title 3604 process to create new titles, and this can be triggered by one of the redemption methods in the original title. This embodiment can be an effective technique in using title objects for syndication or delegation. It can also be an effective technique for transforming a title object, enhancing a title object, evolving a title object, or morphing a title object.
Title trading is supported by the title technology and the applications that process titles. Trading between parties can be accomplished in many different ways and involve any number of technologies and techniques. Referring now to
In another embodiment, digital lockbox component 3710 supports a transfer in which party A intends to give party B the title objects with nothing expected in return. For example, party B could sample the content and review it before accepting the transfer. The claim process for the title objects would remain the same and digital lockbox component 3710 can provide a record of the transaction. In yet another embodiment, digital lockbox component 3710 can support: multi-party, dependent trades, nested-trades. In yet another embodiment, digital lockbox component 3710 may support complex trades involving service level agreements, insurance, legal recourse, guarantees, and content introspection. For example, a highly confidential trade can be implemented with special content inspection rights provided through digital lockbox component 3710. This would provide both parties with the ability to view the confidential content for the duration of the trade negotiations under special circumstances, such as viewing directly using a controlled application similar to that provided by digital rights management software.
In another embodiment, a simplified trade can be executed directly between two parties by having title manager components 3718 and 3720 simply transfer title objects 3716 and 3715, and subsequently have the receiving title manager 3718 and 3720 claim ownership over the respective title objects 3716 and 3715. In yet another embodiment, a trade can be executed directly by title manager components 3718 and 3720 acting as secure agents. An established protocol can be used by title managers 3718 and 3720 to securely trade the title objects. For example, a Boolean circuit can be utilized by the title managers. In another embodiment, security ownership indicia associated with each title object can be updated according to specific title authentication techniques employed by each respective title objects 3716 and 3715.
In another embodiment, title objects and management components are directly embedded into hardware. For example, a title object can be stored on a smartcard device along with a secure management component that is responsible for processing and updating the title object's security indicia. A user would subsequently insert the smartcard into a terminal in order, among other things, to guarantee transaction validity. The title object's security indicia would be securely updated directly on the smartcard, as a security precaution. In another example, management components are implemented as firmware in hardware computing appliances (i.e., firewalls, consumer set-top boxes, etc.), or in portable hardware tokens that can be attached to computing devices through direct interfaces, cables or wireless connections.
Title Protocol and Authentication
In another embodiment, a title protocol is employed for communication between systems participating in a title based transaction. Referring now to
The components depicted in
Protocol 3801 can be used in other circumstances and not just for communication between devices over an external network such as the Internet. In another embodiment, the protocol can be implemented within a device for communication between components. For example, in an embedded implementation such as an electronically controlled machine in a manufacturing application, the protocol 3801 can be implemented for communication between discretely operating components. This can include retrieving control sequences and operating independent machine apparatus. The protocol can accommodate both synchronous and asynchronous messaging processes such that sequences of events can be triggered as required as well as on-demand, or as available.
In one embodiment, consumer device 3802 is used to communicate the redemption request to title manager 3804. Title manager 3804 performs title processing and returns a title command to the consumer device redirecting the consumer to the content. Consumer device 3802 communicates the title directly to content proxy 3806, which subsequently makes a request to a trusted resolver 3808 in order to validate and authenticate the title. In this embodiment, resolver 3808 is a separate component. In another embodiment, the resolver functionality may be incorporated directly into the content proxy.
Resolver 3808 both validates the title (by ensuring that rules are properly executed) and also to authenticate the title. In one embodiment, in order to properly authenticate the title, resolver 3808 communicates the title object to the state server 3810. State server 3810 subsequently authenticates the title object using an authentication technique specified by the title and supported by state server 3810. The authentication process may further involve security indicia included with the title object. The endorsement process is responsible for placing the security indicia in the title object. In one embodiment, state server 3810 returns the authentication response to resolver 3808 along with updated security indicia for the title. If the title is authentic and valid, resolver 3808 communicates the updated security indicia to title manager 3804 and responds to the original request by content proxy 3806.
Upon successful authentication, content proxy 3806 permits the request through to content 3812 which is then returned to consumer device 3802. If the transaction should substantially fail, and consumer device 3802 cannot communicate with content 3812, an error message may be returned. In one embodiment, the error message is substantially communicated to all participating parties to insure an orderly rollback of the transaction, if needed.
In another embodiment, multiple titles may be involved in a transaction. For example, a consumer may want to redeem multiple content objects, each comprising a separate title object, or redeem only one title object requiring the presentation of another title object for identity and authorization. In yet another embodiment, the intermediary parties and systems involved in a transaction may also be required to present titles to other systems with which they communicate with during the transaction flow. These titles can be used to authenticate the intermediaries and systems involved. For example, resolver 3808 in
Header component 3904 may be used to contain transaction and system specific information that will be processed by some or all of the parties involved in the transaction flow. The header information can be items such as action identifiers, transaction type specifications, routing information, remote commands, and security classifications. Body component 3906 may be used to contain the transaction detail such as titles involved in the transaction.
Descriptor component 4002 may be used to describe system related properties associated with the transaction. Transactionid component 4004 may provide an identifier for the transaction that can be used for tracking purposes, and can also be used to maintain state of the transaction. The identifier can be a GUID or some other form of identifier supported by the applications in the ecosystem. Actiontype component 4005 may identify the action that the protocol is initiating and can be a textual label specifying an action such as 'redeem', 'delete', or can be a formal identifier used within the title transaction ecosystem such as an object identifier or URI. Actiontype component 4005 identifies the type of action being performed by the requesting application and may also be used as an identifier in order to initiate particular actions in applications such as triggering tracking and routing. Transactiontype component 4006 may specify the type of transaction that is being conducted, such as identifying this transaction as an ACID transaction. By indicating an ACID transaction all participating applications in the transaction flow must maintain a record of the transaction and also provide the ability to rollback the transaction if required. Transactiontype can comprise a simple indicator of the nature of the transaction and it can also include granular control instructions over the transaction. For example, the transactiontype component can reference transaction processes that must complete before the transaction is successful and if any process fails to complete, the entire transaction is rolled back. In another example, certain processes can be required to complete where other processes can be optional. In this example, a transaction process such as an asynchronous notification message need not complete for the transaction to complete successfully.
Sequenceid component 4007 may provide an identifier for a transaction sequence that this particular transaction object is a member of in set or chain of transactions. In one embodiment, sequenceid component 4007 specifies a numerical order for the processing of this transaction, or provides a more sophisticated identifier such as a hierarchical technique. Securityclass component 4008 may identify the security classification associated with the transaction. The classification may be understood, interpreted, and acted upon by all applications that process the transaction. In one embodiment, the classification is a numerical ordering specifying a security setting from low to high. In another embodiment the securityclass component 4008 specifies a set of parameters or instructions for processing such as indicating the security classification of devices permitted to receive and/or process the protocol message. For example, specifying a government security classification. Priority component 4009 may indicate a priority or class of service that should be applied to the processing of this transaction. In yet another embodiment, priority component 4009 is a textual label to indicate a priority level. This component can maintain service level agreements or providing quality of service guarantees. For example, a transaction object with a high priority level can be placed at the head of the queue for faster response or priority transmission.
Lifespan component 4010 may specify how long a transaction should live. This comprises controls on the processing of the transaction, such that it must be completed within a specified time period, or must be completed within a specified number of steps. Lifespan component 4010 can specify a time such as a UTC time, and/or can specify a numerical number, or some other lifespan indicia that would be understood by applications in the title ecosystem. For example, the minimum and maximum number of devices that a protocol message must traverse in an automated fulfillment application. In this example, the fulfillment process can be automated by a title object traversing a network of fulfillment devices using the protocol 3801 for communication. The title object traverses the network to each device in search of fulfillment offers. The depth of the traversal is controlled by lifespan component 4010 before the title object discontinues its search. Titleaware component 4011 may identify if the source device or application is title aware (such that they understand and process titles directly), allowing the initiation of certain processing. For instance, an application that is not title aware may require assistance from proxies in handling title based transactions.
Session component 4012 may specify a session identifier to be associated with the transaction. The session identifier can be any type of identifier used by the processing applications to uniquely identify the session. For example, in web server applications a session identifier is created when a user logs into the web server. Session component 4012 may permit a set of transactions to be related and tracked to a particular session.
Recipients component 4014 may identify the parties that should receive and process the transaction. It further comprises identifiers for the recipients in compliance with the network protocols that are handling the transaction. In one embodiment, the recipients are identified through domain names. In another embodiment the recipients are identified through URLs. In another embodiment, the recipients are identified by using titles. The structure of recipients component 4014 may be such that one or many recipients can be identified. Furthermore, a group of recipients can be identified such as in broadcast or multicast situations.
Responsemethod component 4016 may specify the technique and address of where to direct the response to this transaction. This component allows the support of asynchronous message responses such that the response to a transaction can be directed through different channels. In one embodiment, the original transaction is received through a SOAP message over HTTP. Once the transaction is completed, the initiator of the transaction may require that the response be sent through another channel such as over SMTP. In another embodiment, the initiator may also indicate that the response be sent back through the original channel (such as HTTP) as well as through another channel (such as SMTP). Multiple response methods can be indicated in the responsemethod component 4016. In another embodiment, the responsemethod can specify that no response is required and can be used to control one-way and two-way communication. In another example, the responsemethod 4016 can specify a timed response, such that a response will not be initiated until required by the requesting device or application. Routing component 4018 comprises instructions on how the transaction is to be routed through intermediary or participating parties. The routing instructions should be understood, interpreted, and processed by all devices and applications that receive the transaction.
Commands component 4020 may specify commands to the receiving application or applications of the transaction object. These commands will be formatted in a manner consistent with the command language understood by the receiving application, or applications, or devices. For example, scripts may be included such as XSLT, Javascript, or other scripts and command languages. This component allows additional instructions to accompany the transaction. In another embodiment, the commands component 4020 can be used to implement callbacks. In one embodiment, the commands component 4020 can be combined with the routing component 4018 for flexible and powerful network control. Referring again to
In another embodiment, protocol 3801 can be combined with title objects to create efficient and effective robots or remote control objects to automate tasks and implement intelligent networks. Routing and command structures along with protocol 3801 can be combined with title object rules and redemption methods for smart network traversal, instruction relays, dynamic communications, information gathering and logic processing. For example, title objects are provided with a mechanism and language for communication and collaboration with other title objects on the network. In another embodiment, title objects and protocol 3801 can also utilize dictionaries and dictionary components as containers and servers for logic that the title objects and protocol messages require. This permits the title object and protocol message to remain small while providing the ability for the object and/or message to retrieve logic as required and in the format necessary for the processing environment. For example, a protocol message 3801 contains command references to a remote dictionary component 4032 as depicted in
Transactionintegrity component 4022, as shown in
Referring now to
At each step in the network traversal the protocol message can be processed by devices, including the title objects that may be contained in the message. In another embodiment, the processing can be intelligent in that protocol messages and title objects may execute a learning process. That is, they gather information and properties from each device in order to make smart decisions on the routing method and path. The protocol messages as they are executed on processing devices can contain routing instructions that are triggered on events. For example, as the protocol message arrived at device B 4026, its processing can include information gathering, such as identifying additional devices in the proximity that meet the order fulfillment requirements and service level agreements. Based on the information gathered and the routing instructions, a decision can be made to route to device D 4030.
Referring now to
In another embodiment, transactiontitles component 4104 may only contain stubs that reference titles. This method is supported by the title object in that the stub can reference the title to which it is bound/attached and that may be stored remotely on another device. This technique can be effective in reducing the size and verbosity of the protocol 3801. As an example, an owner may have many titles that represent the same currency and denomination in their wallet. The only differentiating factor between the titles is the authenticator stub. For communication purposes it could be inefficient to transport all titles over a network such as a wireless RF network. In this instance, the stubs could be sent rather than the entire title. The stub elements reference a title using their binding components. In another instance, a single copy of the title can be sent along with all the stubs necessary for the transaction.
Transactionparameters component 4106 may specify all the arbitrary parameters or properties associated with the transaction. For example, parameters can specify a particular transform that should be applied to the result of a query transaction to title manager 3804, as shown in
Communication channels and discovery are essential elements for support of the protocol 3801. As mentioned previously, the protocol 3801 can be implemented on top of existing protocols and existing communication channels such as TCP/IP, RF networks, and the Internet. Discovery is the process whereby devices, applications, and title objects can find and locate each other using various identity, naming, and locator schemes. The discovery mechanism can be implemented using a variety of techniques depending on the environment where the protocol 3801 is operating. For example, the discovery technique can differ significantly between the Internet, embedded devices, and locator systems such as GPS.
Referring now to
Referring now to
Referring now to
The transaction flow and protocol may rely on authentication of titles to properly identify parties involved in a transaction, as well as evaluate the trust that should be placed on a transaction. As illustrated in
Referring now to
In another embodiment, when a title is used (for example, during a redeem action), the title is presented to state server 4502 for authentication by resolver 4508. State server 4502 performs the authentication process and verifies the security indicia contained within the title to that of the current state maintained in the state collection 4504. The security indicium for a title is contained in the titles authenticator stub.
State server 4502 may also perform endorsement and authentication as supported by the title transaction ecosystem. A variety of techniques and algorithms can be supported by the title technology, and the technique and algorithm employed on a particular title can be subsequently conveyed to state server 4502 for authentication. In one embodiment, a chained hash mechanism, similar to PayWord, is used for title authentication. In another embodiment, the chained hash may be generated by repeatedly hashing an initial value v which may include title information combined with a random number or other appropriate data using a cryptographically strong hash function H such as MD5 or SHA-1. The first iteration of the chained hash algorithm gives h0=H(v). The second iteration gives h1=H(h0). The nth iteration gives hn=H(hn-1) where n represents the desired length of the hash chain. This hash chain of length n may represent any value within the system from the maximum number of redemptions allowed by a title to the maximum number of users connected to a system, or any other value required by the system. In another embodiment, v may be composed of a random value and a hash of the title to later be used for title integrity verification.
In another embodiment, the state server component may generate hn and securely store n and the value v that was used as the initial hash value for h0. The value hn may then be set in the authenticator stub for the title along with the name of the hash algorithm used to create hn. In one instance, the client may then later present the title upon redemption where the state server may extract the value hn from the authenticator stub along with the hash algorithm name specified by that stub. The state server may then look up its stored values v and n and compute hi=Hi(hi-1) where h0=H0(v) and i={1, 2, 3, . . . , n}. The value hn would be checked for equality with hi and if equal, the title would be authenticated. The server may then store n-1 in place of n, generate a new authenticator stub containing hn-1 and the name of the algorithm used, and return that stub back to the client where the title may be authenticated again using the above process as long as n>0.
In yet another embodiment, state server 4502 generates the hash as defined above and set the values hn, and ve along with the name of the hash algorithm used in the authenticator stub, where ve is the encrypted value v. The state server would only need to store n in this embodiment. Upon redemption, the client would present the title with the authenticator stub containing ve, hn, and the name of the hash algorithm to use. The state server component may then decrypt ve to get vd and compute hi=Hi(hi-1) where h0=H0(vd) and i={1, 2, 3, . . . , n}. The state server component would then verify hi=hn and if true, the title would be authenticated. The server may then store n-1 in place of n, generate a new authenticator stub containing hn-1, ve, and the name of the hash algorithm used, and return that stub back to the client where the title may be authenticated again using the above process as long as n>0.
In yet another embodiment, the client is responsible for generating the hash chain. In one instance, the client generates the value v using the techniques described above or another appropriate method. The client then computes the hash chain hi=Hi(hi-1) where h0=H0(v) and i={1, 2, 3, . . . , n}. The resulting hash chain={h0, h1, h2, . . . , hn}. The client sends its credentials, h0, and the name of the hash algorithm used, to the state server component. The state server component verifies the client's credentials and stores h0 in its secure data store. Upon title redemption, the client sends the title with h1 and the name of the hash algorithm embedded in the authenticator stub to the state server component for verification. The state server component retrieves h0 from its secure data store and hashes h0 using the algorithm indicated to produce h1*. The title is authenticated if and only if h1=h1*. The state server component then replaces h0 with h1 in its secure data store. The client can no longer use h1. Note that in this embodiment the client will always supply hi and the state server component will always store hi-1. The ith redemption consists of the value hi supplied by the client which the state server component can verify using hi-1. Each such redemption requires no calculations from the client and only a single hash operation by the state server component.
In another embodiment, when a chain of hashes expires, such as n=0, the state server 4502 can automatically perform a re-endorsement of the title and create a new chain. The re-endorsement can occur selectively and as permitted on the particular title.
In another embodiment, a random value technique is applied to authenticate a title. A random value is generated by the state server 4502 and placed in the authenticator stub. The state server 4502 also maintains a record of the random value in its state collection 4504. The random value would be changed by the state server every time the title is authenticated and only the title object with the correct random value would be valid.
Referring now to FIGS. 46A-B, a simplified diagram of a hash authentication scheme for divisible cash is shown, according to one embodiment of the invention. In one embodiment, a title's value is represented by a tree where each node represents a denomination of the title and the root node is the sum of all its child nodes equal to the total value of the title. For example, in
Referring now to
In another embodiment of the authentication technique and process, the authenticating security indicia can be separated across multiple title objects. In this instance, two or more title objects would need to be presented in order to authenticate any one, some or all of the title objects. For example, a split-key technique can be applied such that the security indicia is securely broken into multiple parts and correctly applied to a set of title objects in the endorsement process. The title objects can be distributed normally to various parties. In this embodiment all of the parties would need to present their title objects in order to redeem content or gain access to an asset. In one variation of this method, the security indicia can be securely split among various title objects such that only some of those title objects need to be presented and not all. For example, the security indicia can be split across three title objects, but only two title objects need to be presented for authentication. In another variation, the technique applied for authenticating a title can be dependent upon another title or set of titles. For example, the security indicium that authenticates a title can be generated based upon direct references to another title or set of titles. The state server 4502 in this case would reference the other titles and perform a serialized authentication process. These methods can be effective for implementing secondary authentication policies such that two parties must be present before access is granted.
In another embodiment of the authentication technique and process, several layers of security indicia can be applied to a title object. In this instance, a title object can be authenticated at various levels using different security indicia, and can in turn implement different authenticating techniques for each level. For example, in a three stage authentication process, a title object can be endorsed three separate times using different techniques with each technique applying more strict guidelines and stronger security. In this example, the third stage endorsement can be utilized for insecure network traversal; the second stage for more secure network traversal and for limited redemption of the title; the first stage for confidential processing and full access to title redemption methods. This multi-stage endorsement and authentication process can be effective in mixed environments where the title object can be routed and authenticated in an insecure public environment without comprising the security indicia that is used for authentication and verification in secure environments.
In another embodiment, a title object can be endorsed by multiple and independent state servers. This permits a single title object to be endorsed (i.e. certified) by separate parties, domains, entities, etc. thereby permitting use of the title object in a particular environment. In one example, the multiple endorsements can relay a particular trust about the title object. For instance, an ecosystem of computing devices that implement title enabled applications may be configured such that they trust only state servers that are identified and reside in the ecosystem; as well as trusting only titles endorsed by these state servers. In order for these applications to trust a title that originated outside the ecosystem it can be re-endorsed by the state servers inside the ecosystem. In this example, the title object would have two endorsements and two authenticator stubs: one from the originating state server; and the other from the state server operating in the ecosystem. For authentication, applications in the current ecosystem would rely on their state server for authentication. In another variation, the state server inside the ecosystem can authenticate the title object itself, and also request authentication from the originating state server outside the ecosystem.
In yet another embodiment, state server 4502 supports a revocation and suspension process, whereby titles in circulation can be revoked for various reasons. For example, if a title has been reported stolen it can be revoked. Or, if a consumer has not met the requirements for the continued use of a title it can be suspended until the requirements are met. In this example, a revocation or suspension protocol message is sent to state server 4502 from a valid and trusted source. State server 4502 will then revoke or suspend the title in question and maintain this in the state collection 4504. In one example, revocation can be requested by the owner of the title and in this case the title can be presented for revocation. The state server 4502 will authenticate the title before revoking.
The establishment of trust within the title transaction ecosystem can occur in several ways. In one embodiment, the participants in a title transaction establish trust implicitly by trusting the authentication of titles used in a transaction that have been endorsed and authenticated by known and configured state servers. For example, as applications and devices communicate using the title protocol, the titles conveyed within the protocol will be authenticated by known and trusted state servers. In another embodiment, trust is established by using trust titles configured on title enabled applications and devices. The trust titles provide fine-grained descriptions and instructions on what title objects are to be trusted and under what circumstances. Trust titles can be created and endorsed by administrative applications and configured on title-enabled applications. The title-enabled applications can then refer to trust titles to execute instructions and filters on transactions that they process to ensure that the titles can be trusted. Trust within a title transaction ecosystem can be established on an implicit or explicit basis, in a peer-to-peer matrix relationship, in a formal hierarchical manner, or in a hybrid fashion depending on the requirements of applications involved in title transactions. In another embodiment, trust can be established through the title object authentication process as described previously. In another embodiment, trust can be established by utilizing a public key infrastructure or similar method such as X.509 and PGP digital certificates. This can operate in conjunction with digitally signed title objects and digitally signed stubs. In another embodiment, trust can be explicitly specified by a user on a title by title basis, or by configuring a set of parameters within their profile.
File Sharing and Distribution
In another embodiment of the title system, titles can be used to manage the access to, sharing and distribution of digital asset. A digital asset comprises anything that may be stored in digital format (i.e., documents, pictures, audio, and web-based assets). Previous approaches to file access control are normally based upon the concept of the name and password which can easily be propagated among multiple users. In this embodiment the title is used to easily refer to and control access to that digital asset.
Referring now to
Referring now to
The user's title manager will then present the title to the appropriate title resolver 4802. The title resolver will reject the title if the authentication stub is invalid 4804. The system can have an optional rejection mechanism which can offer a range of responses and possible actions depending upon the requirements and needs of the asset owner or provider.
If the authentication stub is valid, then the authentication stub is updated 4806 and the title object is re-issued to the user 4807. This update and re-issue process ensures that any copies of the title that were made by the user will now be invalid. This means that it is not possible to copy and distribute a title object among a group of people as the first person to redeem the title object will make the other copies of the title object invalid and thus the other members of the group will have no access to the asset.
In another embodiment this ability of the title to manage and control access to the asset can be further enhanced through other mechanisms of the title object which for example limit the access of the title to the asset based upon number of uses, time period, time of days and other appropriate mechanisms that support the business model of the asset owner.
In yet another embodiment the mechanism within a title that supports different redeem methods enables users who use multiple devices to access asset, to have the asset presented to them in the most appropriate format for the device that the user is using at that particular point in time. For example if the user is accessing the asset from a mobile phone then the asset could be text based, while if the access device is a computer then the asset could be multimedia based.
Referring now to
In this embodiment of the search process the user selects the title search option 4901. The user is then prompted for the type of asset that the user wishes to search for 4902. Based upon the asset type a dedicated search form will be displayed 4903, which the user enters the criteria in 4904. The title search engine will then search for titles that meet those criteria 4905 across a single domain or multiple domains. There is an option to check the digital signature 4906 within the titles to ensure that they have been published by a valid entity. The title search engine will then return a list of valid titles 4907, and the user has the option of refining the search further 4908, or selecting and previewing the titles of interest 4909.
The multiple redemption methods that titles supports means that the preview methods used in 4909 can be extremely flexible ranging from a simple description to the ability to access the actual asset with a set of constraints such as view once or only valid for a number of days. Once the consumer has found the asset of interest then a title transaction can occur 4910 between the user and the owner of the title object. Once a user posses a title, which gives them a certain set of rights to the digital asset, depending upon those rights the user can carry out a number of transactions with those titles that they own. These transactions being to share the title, to give the title, or to trade the title.
Referring now to
The mechanism for sharing between user1 and user2 is very simple, user 1 an asset that they wish to share 5001, user 1 selects the title, and selects the share option 5002. Users 1 title manager creates a shadow title 5003 if the original title object allows the sharing mode, which user 1 sends to user 2 using an appropriate mechanism 5004 such as email, instant messaging or another digital transport mechanism. The shadow title is a modified version of the original title object in that a mechanism such as removing the authentication stub is used to indicate that this shadow title has no rights. In other embodiments the user interaction could be different, and the functionality to create the shadow title may exist within other elements of the system for example the client device or the title publishing system.
Once user2 receives the shadow title, it is stored in title manager 5005, and it can now be redeemed by presenting it to the title resolver system 5006. When the title resolver detects that the title object is a shadow 5007, then using the business rules indicated within the title itself, or through the asset system a preview version 5008 of the asset will be presented to user2 5009. This preview version of the asset can take many forms including a simple description, a lower quality version, an online version rather than a downloaded version, or a limited use version based upon time, number of uses or other appropriate mechanisms. It should be noted that in this embodiment it was a one to one transaction, but in fact could be a one to many transaction were multiple shadow titles are generated. In another embodiment, the shadow title can be stored in title manager 5003 on behalf of the recipient user2 who may not have a title manager or title-enabled application. In this instance, the recipient would have no method or apparatus for redeeming the title. Instead, the title manager 5003 in this example maintains the shadow copy and presents an encoded URL, to user1 that refers to the shadow copy. User1 then sends the encoded URL to user2 using a standard communication mechanism such as electronic mail or instant messaging. Upon receiving the encoded URL, user 2 clicks on it thereby initiating a redemption with title manager 5003.
This approach to sharing of asset meets the needs of asset owners and providers to have their legal rights to that asset to be fully respected, while providing an easy to use mechanism for the users of asset to make other users aware of this asset and for them to use this asset in some restricted form. If the recipients feel that the asset is of value to them then they can purchase the asset.
Referring now to
In this embodiment of the gift scenario user1 purchases a title object to give as gift 5101. Once user1 has received the title object into the title manager, user1 selects the title 5102 and selects the gift option 5103, user1 selects the recipient and has the option to create a gift message. User1's title manager presents the title object to the resolver in gift mode 5104. The resolver will validate that this title can be given as a gift and that optional criteria have been met 5104. These optional criteria can include such features as the asset must have never been accessed by user1. If the title object cannot be given as gift the title is rejected and an optional rejection mechanism can occur.
The title resolver will update the authentication stub to invalidate any copies of the title object that user1 may have 5106, and the updated title object is sent to the user1's title manger which will automatically send the title object and the associated message to user2's title manger 5108. On receipt of the title user2's title manager can optionally refresh the authentication stub of the title object for added security. It should be noted that other embodiments of the gift mechanism could be implemented, for example using a lockbox for extra security, or getting the title publishing system to send the title direct to user 2. An enhanced version of the gift mechanism would be to allow user1 to build an album or collection of digital asset that could be given as a gift, in this case the systems would handle the multiple titles. A further embodiment would be the ability to give the title objects to multiple people where the payment for the multiple copies would be handled automatically as part of the gift process.
Referring now to
Once a trade has been agreed upon, a mechanism must be provided for the trade to occur. In this embodiment, a digital lock box is used but there a wide range of options for providing the actual trading mechanism. User1 places title1 into the digital lockbox 5207 and user2 places title2 into the digital lockbox 5208. A mechanism then verifies and authenticates the titles to be traded. Examples include using digital signatures, presenting the titles to the issuing site, or giving the users the ability to view the titles.
Once the titles are verified, they are presented to their respected title resolvers for their authentication stubs to be updated at 5211 & 5212. This ensures that any copy of the titles kept by users is now invalid for redemption. The titles are now traded 5213 & 5214 and delivered to the title managers 5215 & 5216.
In another embodiment, the trading mechanism comprises digital trading cards. In general, the collection and trading of physical trading cards is very popular. However, implementing a corresponding digital trading card system has generally been impractical. One reason may have been concerns of piracy. That is, a complex centralized digital rights system would be required to log all ownership and securely manage trades. Through the use of the present invention, however, a secure scalable digital trading card system can be implemented.
Referring now to
The mechanisms for generating titles that refer to digital assets can be divided into two classes, automated systems and user driven systems. Automated systems that interact with established web based systems such content management systems would use dedicated interfaces and such embodiments of this approach to title generation have been covered by other descriptions. There are a wide range of embodiments for user driven systems that deliver a functionality that systems deployed to day cannot deliver. In one embodiment, a file sharing system allows users to distribute content easily among their contacts.
Referring now to
Referring now to
Referring now to
Further Exemplary Embodiments
At this point, it should be clear that the title objects of the present invention may be flexibly configured to enable a vast array of interactions and transactions relating to digital assets. As described above, title objects may be used to refer to and control access to such digital assets.
It should also be noted that although many of the examples discussed above refer to transactions involving digital goods such as digital content files, the flexible nature of the title object also makes it suitable for enabling transactions relating to the delivery of other types of digital assets, e.g., services, over networks. Such services may relate, for example, to enabling communication between and among devices, but they also may relate to other types of services, e.g., professional services, which may be delivered via such communication channels. Some examples will be instructive.
According to various embodiments of the invention, a Web-based application is provided which employs title objects as a basis for delivering communication services. According to more specific embodiments, a variety of sophisticated title-enabled functionalities may also be provided with such communication services to provide the capabilities of a so-called 4G (Fourth Generation) device on a personal computer. Such capabilities may include, for example, the download of applications and media, and the sharing of the same with other users and devices. Integrated payment capabilities and access rights management capabilities may also be provided. Such additional capabilities may be enabled through the use of suitably configured title objects as discussed herein. In addition, the mode of communication enabled by various embodiments may be at least partly facilitated in the primary interface through which the communication services are accessed. For example, the interface could include a streaming video window which shows one of the participants in the communication.
A specific embodiment of the invention by which communication services are provided will now be described with reference to the flowchart of
To initiate a communication session, the user selects a particular service in the interface (5704) which results in a communication title object being presented to a communication service provider (5706). As will be understood with reference to the various title structures described herein, the structure of such a communication title object may vary considerably and may represent a wide variety of communication services. For example, the service provided could be an open-ended voice communication session with another computer or phone for which the user might be billed. Alternatively, the service could be prepaid for a communication session of a specific duration. As will be understood, payment for communication services could be effected using title objects as described elsewhere herein. As yet another alternative, the communication session might be the joining of an ongoing conference or Internet chat. Such a service could be free, but access might be limited only to holders of the proper title objects.
In response to presentation of the communication title object, the user might be prompted for the necessary information for connecting with the person to be called, e.g., phone number, URL, e-mail address, instant or text messaging address, etc. (5708). Again, it should be understood that the capabilities of the title-enabled contact management system described herein may be leveraged to facilitate this part of the process. The communication session is then established (5710).
According to some embodiments, title-enabled transactions relating to various types of digital assets (goods and services) may be facilitated during a communication session (5712). That is, the participants in a call may share or sell such digital assets using title objects as described herein. For example, to support such transactions, identity management, rights management, and payment options can all be facilitated using appropriately configured title objects.
The communication session is terminated when the participants request termination or when a predetermined session period has expired (5714).
Whether or not title-enabled transactions are facilitated in the context of a title-enabled communication session, it will be understood that the title objects and title management systems of the present invention may be employed to facilitate the delivery of a wide range of services. For example, various embodiments of the invention "productize" communications sessions by expressing access to such sessions with expert professionals (e.g., lawyers, physicians, tutors) through the use of titles. Such title object might, for example, specify the nature of the services to be provided, the length of a session, and the cost of a session. Identity and rights management, and a variety of payment options may be facilitated through the use of titles as well. Such payment options might include alternative payment models such as, for example, flat fee per session, time-based (metered) payments, etc. According to the invention, a vast array of professional services could be made accessible through a single interface. Such services might include, for example, legal consultation, language instruction, tutoring, expert advice, etc.
According to an embodiment illustrated by the flowchart of
A communication session between the user and the professional is then initiated (5808). According to some embodiments, a title-enabled communication session such as described with reference to
If the professional services being delivered for remuneration, payment for the services may be facilitated (5810). As discussed above, different payment models may be employed. And according to some embodiments, payment may be facilitated using any of the title-enabled payment options discussed herein. The session is terminated when one of the participants requests termination or when a predetermined session period has expired (5812).
As discussed above, the techniques described herein are well suited for supporting transactions involving the exchange of a wide variety of digital content. Further techniques for facilitating such transactions will now be described with reference to
According to one such technique, title objects for digital assets are automatically created with reference to the characteristics of the digital assets themselves. According to one approach, available metadata are used in an ad hoc way to make the digital assets readily available for sharing. The title objects created according to such techniques are generally described above with reference to
Referring to
Metadata associated with the selected digital asset are then obtained (5904), and these data are then used to construct and populate a corresponding title object (5906). For example, if the digital asset is a JPEG photo, the size, bit depth and other information are obtained from the JPEG header. In addition, the filename and the physical location URL are noted so that the asset may be made available for delivery to others who come to possess title to the JPEG. A thumbnail may also be generated from the JPEG data itself for preview. If the asset has richer metadata available, e.g., MP3 tags or an MPEG-21 digital item with detailed metadata, this information may be incorporated into the title object. Specific embodiments allow "glosses" on available metadata such as, for example, descriptions or human-friendly naming.
According to some embodiments, the user may be prompted for additional parameters required to set up the title (5908). For example, the user might be asked whether they want to charge others for or restrict access to the asset. As discussed above, the answers to such questions would result in a different types of title objects than if the user intended to make the asset freely available.
Once the title object has been created for the digital asset, transactions relating to the digital asset, e.g., sharing, trading, or selling of the digital asset, may be facilitated (5910).
According to some embodiments of the invention, title objects facilitate device independent delivery of digital assets according to recipient capabilities and preferences, and media type. According to specific ones of these embodiments, such title objects may be generated according to the technique described above with reference to
In any case, once the recipient receives title to the asset, he or she may select from a number of delivery methods enabled by the title object (6008). For example, if the asset is a JPEG, the recipient might be given the options of downloading the JPEG to his computer, having it delivered to his mobile phone, or having it printed by a third party, e.g., Ofoto.com, and sent to his home via regular mail. The downloading may be accomplished via a third-party server, or in a peer-to-peer (P2P) fashion, i.e., directly from the owner's hard drive to the recipient's hard drive. Alternatively, for a mobile or picture phone delivery option, the recipient would provide his phone number, thereby causing a session to be initiated during which the JPEG is transmitted to the phone. In this way, the flexibility of the title object of the present invention (particularly with regard to delivery method) is leveraged to allow interactions among widely heterogeneous user populations and media types.
As mentioned above and according to a specific embodiment of the method described with reference to
P2P sharing enables users to share files and other digital objects from devices under their control. However, when users go offline, their files become unavailable to others on the network. This issue is particularly problematic when the objects being shared are large, e.g., several megabytes, and have correspondingly long download times. In such cases, it is much more likely than with a small object that the source of a large object (i.e., a binary large object or blob) will go offline while the object is being downloaded. Therefore, according to a specific embodiment of the invention, a hosted service is provided which guarantees availability of digital assets placed with the service.
According to one such embodiment illustrated in
This guaranteed availability service cannot necessarily guarantee delivery of the title-ized items, i.e., that the intended recipient will redeem the title during the specified period. Therefore, according to another embodiment, guaranteed delivery of digital assets is enabled by incorporating a more persistent network store to which the intended recipient has access. The digital asset to be delivered may then be pushed to the persistent store by the service provider (6114) upon receipt of the asset from (and perhaps payment by) the sender. This "drop box" may be located in a variety of places such as, for example, within the service provider's network, in the recipient's network, or at some trusted third party site, e.g., an ISP, to which the recipient has reliable access. According to a specific embodiment, recipients of such deliveries register with the service provider in advance, during which registration one or more "drop zones" are established.
As discussed herein, the nature of the transactions enabled by the title objects and title management capabilities of the present invention can vary widely. According to one set of embodiments, title objects are employed to enable a distribution mechanism by which intended recipients do not receive rights to the digital asset, but an offer to purchase or obtain rights to the digital asset. According to some embodiments, such an offer may be precipitated by the actions of a user which are incompatible with the rights defined by a title object currently held by the user. An example of such an embodiment is illustrated in
A user might have a title corresponding to the delivery of a particular object which indicates that the title is not shareable, but that the user may offer the title to other users for purchase. When the user attempts to share the title with another user (6202), the system recognizes this (6204) and, instead of making a title available to the intended recipient which provides access to the digital object (6205), an offer title object is generated (6206), and an offer to purchase the object is communicated to the intended recipient (6208), the offer being enabled by the offer title which provides "preview" rights and "buy it" rights (as opposed to "delivery" rights). According to a specific embodiment, the offer title is a transformation of the title held by the offering user.
According to another embodiment of the invention illustrated in
According to another set of title-enabled techniques, all of the functionality required to facilitate a title-enabled transaction is transmitted as a lightweight flier over an electronic network to a user's device. These techniques takes the individualized digital asset(s) (as represented by the title), and wraps it/them in a digital flyer which includes full presentation capabilities (e.g., Web/Flash, etc.), product pricing and other information, and a built-in account setup, checkout, and delivery initiation function. These digital flyers can be transmitted via a wide variety of channels including, but not limited to, email, the Web, mobile communication devices, etc.
According to some of these embodiments (an example of which is illustrated in
As mentioned above, the lightweight flier may be returned in response to a search of a P2P network to find, display, and/or use digital assets. According to one such embodiment, title management capabilities as described herein are explicitly supported in the interface and search mechanisms with which each user accesses the P2P network. According to such an embodiment, the transmitted flier need not include all of the necessary functionalities and might only include, for example, the title objects necessary to complete a given transaction. Also, in such an embodiment, an affiliate payout program may be implemented in which revenue is shared between the P2P network and the provider of the title-enabled technologies. Priority sort (like paid search placement) may also be included.
There are products and services offered online which have a high risk of transaction repudiation. The rules by which credit card issuers typically handle repudiations in "card not present" transactions such as these often result in the provider of such products and services being blacklisted by the credit card issuers. That is, the merchant is penalized for the behavior of its customers. Therefore, according to various specific embodiments, titles are employed to enable online payment techniques which are alternatives to credit cards. According to one such embodiment, a digital promissory note (represented by a title object) may be provided to a merchant in lieu of cash settlement. This allows the merchant to take on the risk of repudiation directly. According to a specific embodiment illustrated in
At this point, the myriad ways in which the techniques of the present invention enable commerce and sharing of digital goods and services should be apparent. According to one set of embodiments illustrated in
According to some embodiments, code is dynamically delivered in an HTML page which launches a Flash application which provides access to title objects and the title management capabilities described herein. According to others embodiments, these capabilities are delivered via a browser plug-in, e.g., an ActiveX control, which functions as a proxy in writing a page. The plug-in might be offered, for example, as an opportunity to extend the capabilities of typical Internet search engines by initiating searches of sources not ordinarily searched by such search engines, e.g., paid database searches. The content in such alternate sources is title-enabled as discussed herein. Referring now to
According to a particular class of embodiments, a client application may be downloaded to a wireless handset to enable collection, sharing, and viral distribution of digital content using titles. It should be noted that the client application may be implemented to operate with a wide variety of handset types including, but not limited to, J2ME (Java 2 Platform, Micro Edition) clients, BREW (Binary Runtime Environment for Wireless) clients, etc., and any other handset type. The invention should therefore not be limited to any particular handset type. According to some embodiments, the client application is operable to "retrofit" existing content found on the handset when it is downloaded. That is, previously downloaded content in the handset user's collection is automatically "title-ized" when the client app is downloaded.
According to a specific embodiment illustrated in
According to a specific embodiment, the digital commerce engine compares the digital content identified in the handset to a catalog of digital content (6810) to identify additional information relating to the identified digital content (6812). Such additional information might include, for example, meta data corresponding to the digital content or links, e.g., URLs, which would facilitate purchases of the identified, additional, or related content. The catalog might identify, for example, content which has been sold into such handsets over some time period, e.g., the last 3 years.
According to a specific embodiment, the additional information identified from the catalog may be employed by the digital commerce engine in the creation of the titles for the identified content. Such information might, for example, indicate what rights should be made available for the content by the creation of the title. For example, whether or not a title should be designated as shareable or restricted in some way might be indicated.
In addition, or alternatively, the title created by the client application may provide a mechanism, for example, by which a holder of the title might be able to purchase the corresponding digital asset. The title created might also facilitate a preview of the digital asset. In such cases, the meta data from the catalog may be used to generate human readable information which is displayed with or as part of the title on the handset to identify the digital asset (e.g., this is a ring tone from Usher featuring Ludacris) and, possibly, instructions for previewing and/or acquiring it.
The titles created by the digital commerce engine are then made available by the digital commerce engine for management by the client application (6814). That is, the client application can then interact with the digital commerce engine to gain access to and engage in transactions (e.g., sharing) with the created titles as described elsewhere herein. Such titles may be acquired via the handset or via any other title-enabled device, e.g., a personal computer on the Web.
According to a specific embodiment, the client application can have any or all of the title management capabilities described in this specification, allowing it to manage and engage in transactions with any kind of titles including, for example, a title representing content which is much to large to store in such a handset, e.g., a multi-gigabyte movie, or titles acquired via other title-enable platforms. Similarly, a user could manage the title acquired via the handset on the other title-enabled platforms such as those described elsewhere herein. In addition, transactions can be conducted with any other title-enabled platform including, for example, another handset with the same or similar capabilities, a PC, a cable device, or a gaming console. Thus, these embodiments of the invention enable transactions using wireless handsets (including handset-to-handset transactions) involving any digital asset which can be represented by a title, whether or not the digital asset can be directly experienced via the handset.
Embodiments of the present invention are contemplated in which the client application described may also enable title-based transaction with devices not previously title-enabled. That is, when a device which is title-enabled attempts to share a title with another device which is not title-enabled, the user of the second device is notified (e.g., via SMS or email) of the pending transaction. The user is then given the option (e.g., using a hypertext link) to initiate download of the client application described above and receive the capability to engage in title-based transactions.
It should also be understood that while embodiments in the immediately preceding paragraphs have been described with reference to handsets, it should be understood that the techniques described are not limited to that environment. For example, the automatic titleing of a previously downloaded collection of digital assets upon the downloading of an application, applet, or plug-in could be achieved in any kind of network environment and on any platform or device in which title-based transactions may be conducted.
According to another class of embodiments, consumer relationships may be readily captured and maintained, such relationships then providing marketing opportunities as well as opportunities for facilitating title-based and other types of transactions. Embodiments will be described below with reference to SMS interfaces and wireless handsets. These references are merely for exemplary purposes. It will be understood that the basic techniques described may employ a wide variety of interface and device types and in a wide variety of environments without departing from the scope of the invention.
According to a specific embodiment illustrated in
As will be understood, the instructions for sending the message may be communicated by virtually any medium in any context. In some cases, the instructions may be used by anyone receiving them. In others, the instructions may require that the user include specific information in the message which effectively limits access to the premium to an exclusive set of users. For example, the instructions might request that a unique code on a concert ticket (which may only be used once) be identified in the message for access to ring tones for the artist performing at the concert, i.e., one access per customer. As will be understood, such unique identifiers may be delivered and processed in any of a wide variety of ways.
Regardless of how the instructions are delivered to the user, once the user sends the requested message to the identified number or address (6904), the message is received by, for example, a server (6906), and the handset's phone number is captured (6908). According to some embodiments, where available, information about the handset carrier is also captured. The message generated by the user could be, for example, an empty SMS message, or could include additional information such as, for example, information responsive to the particular promotion, e.g., votes, quiz answers, etc.
A temporary password is created (6910) and pushed (e.g., using an HTTP post or an XML/SOAP call), along with the captured phone number, to a process, e.g., a digital commerce engine (DCE) such as any described herein (6912), which uses the information to creates an account (6914). According to a specific embodiment, the phone number is employed as a log in ID for the account and the temporary password, obviously, as the password.
A message is then generated (6916) and sent back to the handset (6918) which instructs the user how to obtain the premium. For example, the message might include a URL and instruct the user to use the log in ID and the password to gain access to digital content at the URL. The message might also outline or link to conditions to which the user must agree before proceeding, e.g., conditions agreeing to receive SMS marketing messages. According to a specific embodiment, the user can subsequently go to the URL or a related URL to "turn off" such marketing messages.
The user then accesses the URL, inputs the required information, and gains access to the premium (6920). According to various embodiments, additional information, e.g., personal info, email address, etc., may be captured for a variety of purposes.
According to a specific embodiment, when the user accesses the URL, the transaction involving the premium, e.g., the downloading of digital content, may be facilitated using the title-enable technologies described herein. That is, any digital assets involved in the transaction may be represented by title objects which are exchanged and managed as described above. According to an even more specific embodiment, creation of the user account also includes the downloading of a client application to the user's wireless handset (e.g., as described above with reference to
While the invention has been particularly shown and described with reference to specific embodiments thereof, it will be understood by those skilled in the art that changes in the form and details of the disclosed embodiments may be made without departing from the spirit or scope of the invention. In addition, although various advantages, aspects, and objects of the present invention have been discussed herein with reference to various embodiments, it will be understood that the scope of the invention should not be limited by reference to such advantages, aspects, and objects. Rather, the scope of the invention should be determined with reference to the appended claims.
|Cited Patent
|Filing date
|Publication date
|27 Jan 1995
|3 Oct 1995
|Citibank, N.A.
|Electronic-monetary system
|19 Sep 1994
|25 Feb 1997
|Electronic document verification system and method
|23 Nov 1994
|13 May 1997
|Xerox Corporation
|System for controlling the distribution and use of digital works
|23 Jan 1997
|12 May 1998
|Fuji Xerox Co., Ltd.
|Structured document retrieval system
|7 Nov 1995
|7 Jul 1998
|At&T Corp.
|Usage management system
|3 Dec 1996
|11 Aug 1998
|Newleaf Entertainment Corporation
|Apparatus and method for an on demand data delivery system for the preview, selection, retrieval and reproduction at a remote location of previously recorded or programmed materials
|30 Aug 1996
|6 Apr 1999
|Intertrust Technologies Corp.
|Systems and methods for secure transaction management and electronic rights protection
|19 Jul 1996
|11 May 1999
|Biffar; Peter C.
|Self-contained payment system with circulating digital vouchers
|27 Sep 1996
|21 Sep 1999
|Apple Computer, Inc.
|Object-oriented editor for creating world wide web documents
|24 Nov 1997
|1 Aug 2000
|International Business Machines Corporation
|System and method for controlling access rights to and security of digital content in a distributed information system, e.g., Internet
|11 Apr 1997
|12 Sep 2000
|The Brodia Group
|Virtual property system
|28 May 1998
|28 Nov 2000
|Nuvomedia, Inc.
|Display orientation features for hand-held content display device
|24 Sep 1998
|9 Jan 2001
|Payformance Corporation
|Self-authenticating negotiable documents
|24 Mar 1997
|13 Feb 2001
|Preview Systems, Inc.
|Digital Certificate
|21 Aug 1998
|20 Mar 2001
|Citibank, N.A.
|Trusted agents for open electronic commerce where the transfer of electronic merchandise or electronic money is provisional until the transaction is finalized
|6 Jan 1999
|3 Apr 2001
|Unisys Corporation
|Self-authentication of value documents using encoded indices
|5 Mar 1999
|11 Dec 2001
|Walker Digital, Llc
|System and process for issuing and managing forced redemption vouchers having alias account numbers
|10 Dec 1999
|22 Jan 2002
|The Brodia Group
|Smart electronic receipt system
|16 Jan 2001
|16 Apr 2002
|Intel Corporation
|Method and apparatus for sharing music content between devices
|9 Dec 1999
|23 Apr 2002
|The Brodia Group
|Trusted agent for electronic commerce
|15 May 1998
|14 May 2002
|First Union National Bank
|Regulating access to digital content
|14 Sep 1998
|3 Jun 2003
|International Business Machines Corporation
|Secure electronic content management system
|28 Jan 2000
|8 Jul 2003
|Commerce One Operations, Inc.
|Method of retrieving schemas for interpreting documents in an electronic commerce system
|16 Oct 1997
|29 Jul 2003
|Unisys Corporation
|Apparatus and method for enhancing check security
|22 Dec 1999
|30 Sep 2003
|Accenture Llp
|Account settlement and financing in an e-commerce environment
|30 May 2002
|9 Dec 2003
|America Online, Incorporated
|Client-side form filler that populates form fields based on analyzing visible field labels and visible display format hints without previous examination or mapping of the form
|12 Aug 1999
|6 Jan 2004
|Zix Corporation
|Transaction authorization system
|24 Nov 1998
|15 Jun 2004
|Drm Technologies, L.L.C.
|Tracking electronic component
|14 Dec 1999
|3 Aug 2004
|International Business Machines Corporation
|Method and system for presentation and manipulation of PKCS signed-data objects
|9 Jul 1999
|15 Mar 2005
|Fujitsu Limited
|System and method for electronic shopping using an interactive shopping agent
|27 Oct 1999
|22 Mar 2005
|Yodlee, Inc.
|System and method for distributed storage and retrieval of personal information
|17 Dec 2001
|17 May 2005
|Contentguard Holdings, Inc.
|Usage rights grammar and digital works having usage rights created with the grammar
|19 Dec 2002
|24 May 2005
|Contentguard Holdings, Inc.
|Method and apparatus for executing code in accordance with usage rights
|9 Nov 1999
|21 Jun 2005
|Clarita Corporation
|Method and apparatus for automatic form filling
|28 Jan 1999
|5 Jul 2005
|Citicorp Development Center, Inc.
|Method and system of tracking and providing an audit trail of smart card transactions
|18 Oct 2002
|30 Aug 2005
|Intertrust Technologies Corporation
|Methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information
|12 Apr 2000
|13 Sep 2005
|Microsoft Corporation
|System and method for data rights management
|15 May 2000
|20 Sep 2005
|Digimarc Corporation
|Cell phones with optical capabilities, and related applications
|17 Jul 2000
|28 Mar 2006
|Citibank, N.A.
|Inside money
|3 Jun 2002
|11 Apr 2006
|Contentguardiholdings, Inc.
|Method and apparatus for distributing enforceable property rights
|22 Dec 1999
|27 Jun 2006
|Accenture Llp
|Initiating an agreement in an e-commerce environment
|29 Jun 2001
|31 Oct 2006
|International Business Machines Corporation
|Digital rights management
|7 Feb 2001
|19 Jul 2001
|Stefik Mark J.
|System for controlling the distribution and use of rendered digital works through watermarking
|25 Jan 2001
|4 Oct 2001
|Satoshi Watanabe
|Apparatus and method for managing contents in a computer
|1 Dec 2000
|18 Oct 2001
|Davor Runje
|System and method for secure electronic digital rights management, secure transaction management and content distribution
|28 Aug 2001
|28 Feb 2002
|Chica Sebastian De La
|System and methods for the flexible usage of electronic content in heterogeneous distributed environments
|23 Feb 2001
|7 Mar 2002
|Vlahoplus John C.
|Electronic ownership control system and method
|7 Sep 2001
|14 Mar 2002
|Francis Sweeney
|System and method of automated brokerage for risk management services and products
|17 Aug 2001
|23 May 2002
|Iannacci Gregory Fx
|System and method for an automated benefit recognition, acquisition, value exchange, and transaction settlement system using multivariable linear and nonlinear modeling
|11 Jan 2001
|11 Jul 2002
|Ryuichi Okamoto
|Digital data distribution system
|27 Dec 2001
|8 Aug 2002
|Ta-Kuang Yang
|Multiple registration system and method of using the same account for registering different device to a DRC server
|20 Feb 2001
|22 Aug 2002
|Koninklijke Philips Electronics N.V.
|Broadcast and processing of meta-information associated with content material
|5 Apr 2002
|17 Oct 2002
|Rudd James M.
|System and methods for managing the distribution of electronic content
|26 Mar 2001
|5 Dec 2002
|Eric Hughes
|Combined digital signature
|24 Jun 2002
|30 Jan 2003
|Stefik Mark J.
|System for controlling the distribution and use of digital works
|6 Jun 2002
|30 Jan 2003
|Contentguard Holdings, Inc.
|Digital rights management of content when content is a future live event
|21 Dec 2001
|3 Jul 2003
|Falso Edward D.
|Method and system for managing contractual risk
|12 Dec 2001
|24 Jul 2003
|Probst Bruce E.
|Digital asset data type definitions
|27 May 1999
|21 Aug 2003
|Michael A. Epstein
|Method and apparatus for use of a watermark and a receiver dependent reference for the purpose of copy pretection
|19 Nov 2002
|25 Sep 2003
|Contentguard Holdings, Inc.
|Systems and methods for creating, manipulating and processing rights and contract expressions using tokenized templates
|30 Aug 2002
|20 Nov 2003
|Stefan Roever
|Methods and apparatus for a title transaction network
|29 Nov 2000
|4 Mar 2004
|Russell David C.
|Methods, systems and apparatuses for secure transactions
|13 Sep 2002
|18 Mar 2004
|Sun Microsystems, Inc., A Delaware Corporation
|Repositing for digital content access control
|31 Dec 2002
|1 Jul 2004
|International Business Machines Corporation
|Method and system for attribute exchange in a heterogeneous federated environment
|15 Oct 2003
|15 Jul 2004
|Sun Microsystems, Inc., A Delaware Corporation
|Accessing in a rights locker system for digital content access control
|5 Mar 2002
|2 Dec 2004
|Hansen Thomas J.
|Wireless point of sale transaction
|27 Jun 2003
|3 Feb 2005
|Jason Cahill
|Organization-based content rights management and systems, structures, and methods therefor
|21 Jun 2004
|17 Feb 2005
|Navio Systems, Inc.
|Methods and apparatus for enabling transactions in networks
|21 Jun 2004
|17 Feb 2005
|Navio Systems, Inc.
|Methods and apparatus for enabling transaction relating to digital assets
|30 Mar 2005
|20 Oct 2005
|Navio Systems, Inc.
|User agent for facilitating transactions in networks
|15 Apr 2003
|10 Nov 2005
|Stefan Roever
|Methods of facilitating merchant transactions using a computerized system including a set of titles
|16 Jun 2005
|8 Dec 2005
|Navio Systems, Inc.
|Methods and apparatus for a title transaction network
|15 Apr 2003
|16 Feb 2006
|Stefan Roever
|Methods of facilitating contact management using a computerized system including a set of titles
|15 May 2003
|16 Feb 2006
|Stefan Roever
|Methods and apparatus for title protocol, authentication, and sharing
|24 Mar 2006
|27 Jul 2006
|Microsoft Corporation
|Digital license and method for obtaining/providing a digital license
|3 Jun 2005
|3 Aug 2006
|Navio Systems Inc.
|Methods and apparatus for optimizing digital asset distribution
|29 Apr 2005
|3 Aug 2006
|Navio Systems, Inc.
|Methods and apparatus for optimizing identity management
|30 Apr 2007
|13 Dec 2007
|Navio Systems, Inc.
|Title-enabled networking
|Citing Patent
|Filing date
|Publication date
|20 Jun 2005
|3 Apr 2007
|Microsoft Corporation
|Secure online transactions using a captcha image as a watermark
|3 Mar 2005
|17 Apr 2007
|Nec Corporation
|Call device, call control system, call management system, and call control method
|16 Sep 2004
|31 Mar 2009
|Target Brands, Inc.
|Financial transaction approval system and method
|27 Sep 2006
|21 Jul 2009
|Nec Corporation
|Call device, call control system, call management system, and call control method
|22 Aug 2006
|21 Jul 2009
|Microsoft Corporation
|Secure online transactions using a captcha image as a watermark
|30 Aug 2005
|4 Aug 2009
|Damaka, Inc.
|System and method for traversing a NAT device for peer-to-peer hybrid communications
|15 May 2006
|24 Nov 2009
|Damaka, Inc.
|System and method for conferencing in a peer-to-peer hybrid communications network
|29 Dec 2006
|24 Nov 2009
|Damaka, Inc.
|System and method for deterministic routing in a peer-to-peer hybrid communications network
|7 Sep 2006
|8 Dec 2009
|Microsoft Corporation
|Order system payment routing
|15 Apr 2003
|27 Apr 2010
|Navio Systems, Inc.
|Methods of facilitating merchant transactions using a computerized system including a set of titles
|15 May 2003
|27 Apr 2010
|Navio Systems, Inc.
|Methods and apparatus for title structure and management
|6 Dec 2005
|18 May 2010
|Shabbir Khan
|System and/or method for bidding
|2 Nov 2007
|18 May 2010
|Metropolitan Life Ins. Co.
|System and method for remote deposit capture
|31 Oct 2005
|8 Jun 2010
|Sap Ag
|Integration of digital asset management with intellectual property management
|19 May 2006
|6 Jul 2010
|Cisco Technology, Inc.
|Method and apparatus for simply configuring a subscriber appliance for performing a service controlled by a separate service provider
|29 Dec 2006
|17 Aug 2010
|Damaka, Inc.
|System and method for dynamic stability in a peer-to-peer hybrid communications network
|30 Mar 2009
|21 Sep 2010
|Target Brands, Inc.
|Financial transaction approval system and method
|15 May 2003
|12 Oct 2010
|Navio Systems, Inc.
|Methods and apparatus for title protocol, authentication, and sharing
|31 Oct 2005
|23 Nov 2010
|Sap Ag
|Integration of a digital asset management system with a network sales system
|9 Apr 2004
|7 Dec 2010
|At&T Mobility Ii Llc
|Sharing content on mobile devices
|9 Apr 2010
|1 Feb 2011
|Metropolitan Life Insurance Company
|System and method for remote deposit capture
|6 Dec 2005
|22 Feb 2011
|Lippershy Celestial Llc
|Digital object routing
|17 Oct 2005
|26 Apr 2011
|Damaka, Inc.
|System and method for routing and communicating in a heterogeneous network environment
|13 Mar 2007
|3 May 2011
|Scott Albers
|Method for developing a personalized musical ring-tone for a mobile telephone based upon characters and length of a full name of a user
|10 Aug 2009
|16 Aug 2011
|Damaka, Inc.
|System and method for peer-to-peer hybrid communications
|4 Jan 2010
|16 Aug 2011
|Adobe Systems Incorporated
|Interrupting and resuming a media player
|27 Jan 2006
|30 Aug 2011
|Damaka, Inc.
|System and method for data transfer in a peer-to peer hybrid communication network
|6 Dec 2005
|6 Sep 2011
|Lippershy Celestial Llc
|Bidding network
|21 May 2010
|13 Sep 2011
|Cisco Technology, Inc.
|Method and apparatus for simply configuring a subscriber appliance for performing a service controlled by a separate service provider
|28 Feb 2007
|25 Oct 2011
|Sybase 365, Inc.
|System and method for subscription management
|15 May 2006
|1 Nov 2011
|Damaka, Inc.
|System and method for concurrent sessions in a peer-to-peer hybrid communications network
|6 Dec 2005
|8 Nov 2011
|Lippershy Celestial Llc
|Digital object title and transmission information
|23 Jun 2006
|17 Jan 2012
|Microsoft Corporation
|Extended data collection for multi-merchant purchasing environment for downloadable products
|11 Jan 2008
|31 Jan 2012
|Seven Networks, Inc.
|Mobile virtual network operator
|30 Nov 2005
|14 Feb 2012
|Seven Networks, Inc.
|Provisioning of e-mail settings for a mobile terminal
|27 Jun 2008
|28 Feb 2012
|Microsoft Corporation
|Guided content metadata tagging for an online content repository
|30 Jun 2009
|20 Mar 2012
|Damaka, Inc.
|System and method for traversing a NAT device for peer-to-peer hybrid communications
|7 Oct 2004
|20 Mar 2012
|International Business Machines Corporation
|Role-based views access to a workflow weblog
|15 Dec 2005
|27 Mar 2012
|Microsoft Corporation
|Client-side CAPTCHA ceremony for user verification
|17 Oct 2007
|29 May 2012
|Industrial Color, Inc.
|Digital file management system with unstructured job upload
|6 Dec 2005
|5 Jun 2012
|Lippershy Celestial Llc
|System and/or method for downstream bidding
|26 Jun 2012
|At&T Mobility Ii, Llc.
|Spam control for sharing content on mobile devices
|25 Aug 2011
|10 Jul 2012
|Damaka, Inc.
|System and method for data transfer in a peer-to-peer hybrid communication network
|10 Jul 2012
|Quickplay Media Inc.
|Seamlessly switching among unicast, multicast, and broadcast mobile media content
|9 Oct 2009
|21 Aug 2012
|Adobe Systems Incorporated
|Using local codecs
|16 Sep 2010
|4 Sep 2012
|Target Brands, Inc.
|Financial transaction approval system and method
|15 Aug 2011
|27 Nov 2012
|Adobe Systems Incorporated
|Interrupting and resuming a media player
|18 Nov 2009
|11 Dec 2012
|American Express Travel Related Services Company, Inc.
|File listener system and method
|2 May 2005
|11 Dec 2012
|American Airlines, Inc.
|System and method for managing multiple message format communication
|29 Apr 2010
|8 Jan 2013
|Damaka, Inc.
|System and method for peer-to-peer media routing using a third party instant messaging system for signaling
|26 Nov 2008
|19 Feb 2013
|Damaka, Inc.
|System and method for endpoint handoff in a hybrid peer-to-peer networking environment
|26 Mar 2013
|Damaka, Inc.
|System and method for traversing a NAT device for peer-to-peer hybrid communications
|4 Apr 2011
|26 Mar 2013
|Damaka, Inc.
|System and method for sharing unsupported document types between communication devices
|28 Apr 2005
|9 Apr 2013
|International Business Machines Corporation
|Visualization of attributes of workflow weblogs
|12 Dec 2003
|16 Apr 2013
|International Business Machines Corporation
|Method for tracking the status of a workflow using weblogs
|15 Sep 2011
|30 Apr 2013
|Damaka, Inc.
|System and method for concurrent sessions in a peer-to-peer hybrid communications network
|7 May 2013
|Damaka, Inc.
|Device and method for maintaining a communication session during a network transition
|11 Jun 2010
|14 May 2013
|Adobe Systems Incorporated
|Rendering text in a brew device
|18 Jun 2010
|21 May 2013
|Damaka, Inc.
|System and method for transferring a call between endpoints in a hybrid peer-to-peer network
|18 Jun 2013
|Damaka, Inc.
|System and method for peer-to-peer hybrid communications
|18 Jun 2013
|Damaka, Inc.
|System and method for language translation in a hybrid peer-to-peer environment
|15 Jul 2011
|2 Jul 2013
|Damaka, Inc.
|System and method for reliable virtual bi-directional data stream communications with single socket point-to-multipoint capability
|28 Nov 2006
|9 Jul 2013
|Cisco Technology, Inc.
|Messaging security device
|2 Oct 2007
|1 Oct 2013
|Callwave Communications, Llc
|Methods and systems for blocking unwanted telecommunications
|24 Oct 2011
|15 Oct 2013
|Sybase 365, Inc.
|System and method for subscription management
|14 Sep 2012
|22 Oct 2013
|Adobe Systems Incorporated
|Interrupting and resuming a media player
|3 Mar 2010
|29 Oct 2013
|Oncircle, Inc.
|Methods and apparatus for title structure and management
|30 Jun 2011
|5 Nov 2013
|Amazon Technologies, Inc.
|Remote browsing session between client browser and network based browser
|19 Jan 2011
|12 Nov 2013
|Metropolitan Life Insurance, Co
|System and method for remote deposit capture
|27 Sep 2011
|19 Nov 2013
|Amazon Technologies, Inc.
|Historical browsing session management
|19 Dec 2007
|19 Nov 2013
|Adobe Systems Incorporated
|Event-sensitive content for mobile devices
|23 Jun 2010
|17 Dec 2013
|Damaka, Inc.
|System and method for secure messaging in a hybrid peer-to-peer network
|29 Sep 2011
|24 Dec 2013
|Amazon Technologies, Inc.
|Network content message placement management
|26 Jan 2012
|7 Jan 2014
|Amazon Technologies, Inc.
|Remote browsing and searching
|8 Aug 2011
|21 Jan 2014
|Cisco Technology, Inc.
|Method and apparatus for simply configuring a subscriber appliance for performing a service controlled by a separate service provider
|13 Dec 2007
|11 Mar 2014
|Quickplay Media Inc.
|Consumption profile for mobile media
|19 Mar 2010
|1 Apr 2014
|Damaka, Inc.
|System and method for providing a virtual peer-to-peer environment
|17 May 2011
|8 Apr 2014
|Damaka, Inc.
|System and method for transferring a call bridge between communication devices
|30 Jun 2011
|22 Apr 2014
|Amazon Technologies, Inc.
|Remote browsing session management
|15 Feb 2010
|13 May 2014
|Damaka, Inc.
|NAT traversal by concurrently probing multiple candidates
|2 Mar 2010
|27 May 2014
|Oncircle, Inc.
|Methods of facilitating merchant transactions using a computerized system including a set of titles
|11 Oct 2010
|3 Jun 2014
|Damaka, Inc.
|System and method for a reverse invitation in a hybrid peer-to-peer environment
|11 Dec 2013
|8 Jul 2014
|Callwave Communications, Llc
|Methods and systems for blocking unwanted communications
|31 Aug 2012
|15 Jul 2014
|Target Brands, Inc.
|Financial transaction approval system and method
|7 Mar 2012
|15 Jul 2014
|Microsoft Corporation
|Client-side CAPTCHA ceremony for user verification
|13 Dec 2007
|29 Jul 2014
|Seven Networks, Inc.
|Content delivery to a mobile device from a content service
|30 Jun 2011
|5 Aug 2014
|Amazon Technologies, Inc.
|Remote browsing session management
|24 Apr 2012
|12 Aug 2014
|Quickplay Media Inc.
|Seamlessly switching among unicast, multicast, and broadcast mobile media content
|5 Sep 2008
|12 Aug 2014
|Seven Networks, Inc.
|Maintaining mobile terminal information for secure communications
|28 Apr 2011
|9 Sep 2014
|Seven Networks, Inc
|System and method for tracking billing events in a mobile wireless network for a network operator
|28 Jan 2009
|16 Sep 2014
|Seven Networks, Inc.
|Web-based access to data objects
|26 Jan 2012
|16 Sep 2014
|Amazon Technologies, Inc.
|Remote browsing and searching
|27 Sep 2011
|30 Sep 2014
|Amazon Technologies, Inc.
|Historical browsing session management
|7 Aug 2012
|7 Oct 2014
|Quickplay Media Inc.
|Method for remotely controlling a streaming media server with a pause and resume functionality
|29 Sep 2008
|14 Oct 2014
|Damaka, Inc.
|System and method for transitioning a communication session between networks that are not commonly controlled
|1 Apr 2013
|21 Oct 2014
|Damaka, Inc.
|System and method for concurrent sessions in a peer-to-peer hybrid communications network
|20 Nov 2013
|21 Oct 2014
|Ikonopedia, Inc.
|Secure medical data transmission
|17 Aug 2010
|28 Oct 2014
|Damaka, Inc.
|System and method for signaling and data tunneling in a peer-to-peer environment
|25 Aug 2010
|18 Nov 2014
|Damaka, Inc.
|System and method for shared session appearance in a hybrid peer-to-peer environment
|4 Apr 2009
|18 Nov 2014
|Quickplay Media Inc.
|Progressive download playback
|27 Sep 2011
|16 Dec 2014
|Amazon Technologies, Inc.
|Managing network based content
|16 Aug 2012
|27 Jan 2015
|Amazon Technologies, Inc.
|Automated content update notification
|1 Apr 2013
|3 Feb 2015
|Damaka, Inc.
|Device and method for maintaining a communication session during a network transition
|3 Jul 2014
|17 Feb 2015
|Callwave Communications, Llc
|Methods and systems for blocking unwanted communications
|1 Dec 2011
|3 Mar 2015
|Amazon Technologies, Inc.
|Offline browsing session management
|7 Sep 2006
|24 Mar 2015
|Seven Networks, Inc.
|Connection architecture for a mobile network
|13 Dec 2007
|31 Mar 2015
|Quickplay Media Inc.
|Mobile media pause and resume
|9 Dec 2011
|14 Apr 2015
|Amazon Technologies, Inc.
|Remote browsing session management
|8 Jan 2013
|21 Apr 2015
|Damaka, Inc.
|System and method for peer-to-peer media routing using a third party instant messaging system for signaling
|27 Feb 2012
|28 Apr 2015
|Redigi, Inc.
|Methods and apparatus for sharing, transferring and removing previously owned digital media
|11 Sep 2013
|5 May 2015
|Damaka, Inc.
|System and method for providing additional functionality to existing software in an integrated manner
|2 Jun 2014
|12 May 2015
|Damaka, Inc.
|System and method for a reverse invitation in a hybrid peer-to-peer environment
|16 Aug 2011
|19 May 2015
|Amazon Technologies, Inc.
|Managing information associated with network resources
|10 Feb 2012
|19 May 2015
|Amazon Technologies, Inc.
|Zooming interaction tracking and popularity determination
|29 Mar 2010
|26 May 2015
|Damaka, Inc.
|System and method for session sweeping between devices
|28 Dec 2007
|2 Jun 2015
|Nokia Corporation
|Content management for packet-communicating devices
|24 May 2011
|9 Jun 2015
|Amazon Technologies, Inc.
|Service for managing digital content licenses
|13 Dec 2007
|23 Jun 2015
|Quickplay Media Inc.
|Encoding and transcoding for mobile media
|29 May 2014
|23 Jun 2015
|Quickplay Media Inc.
|Seamlessly switching among unicast, multicast, and broadcast mobile media content
|24 May 2011
|23 Jun 2015
|Amazon Technologies, Inc.
|Service for managing digital content resales
|17 Aug 2007
|7 Jul 2015
|Nebraska Book Company, Inc.
|Digital delivery system and method
|23 May 2012
|7 Jul 2015
|At&T Mobility Ii Llc
|Spam control for sharing content on mobile devices
|3 Jul 2013
|7 Jul 2015
|Cisco Technology, Inc.
|Messaging security device
|26 Jan 2012
|21 Jul 2015
|Amazon Technologies, Inc.
|Narration of network content
|26 Jan 2012
|28 Jul 2015
|Amazon Technologies, Inc.
|Remote browsing and searching
|3 Jul 2012
|11 Aug 2015
|Damaka, Inc.
|System and method for data transfer in a peer-to-peer hybrid communication network
|9 Dec 2011
|25 Aug 2015
|Amazon Technologies, Inc.
|Remote browsing session management
|12 Oct 2010
|1 Sep 2015
|Quickplay Media Inc.
|Digital rights management in a mobile environment
|16 May 2013
|8 Sep 2015
|Damaka, Inc.
|System and method for language translation in a hybrid peer-to-peer environment
|21 Feb 2012
|15 Sep 2015
|Amazon Technologies, Inc.
|Remote browsing session management
|16 Dec 2013
|22 Sep 2015
|Damaka, Inc.
|System and method for secure messaging in a hybrid peer-to-peer network
|21 Jun 2004
|17 Feb 2005
|Navio Systems, Inc.
|Methods and apparatus for enabling transaction relating to digital assets
|12 Dec 2003
|16 Jun 2005
|International Business Machines Corporation
|Method for tracking the status of a workflow using weblogs
|7 Oct 2004
|16 Jun 2005
|International Business Machines Corporation
|Role-based views access to a workflow weblog
|28 Apr 2005
|8 Sep 2005
|International Business Machines Corporation
|Visualization of attributes of workflow weblogs
|3 Mar 2005
|15 Sep 2005
|Yuri Kuroda
|Call device, call control system, call management system, and call control method
|30 Mar 2005
|20 Oct 2005
|Navio Systems, Inc.
|User agent for facilitating transactions in networks
|9 Apr 2004
|1 Dec 2005
|Anuraag Agrawal
|Sharing content on mobile devices
|15 Apr 2003
|16 Feb 2006
|Stefan Roever
|Methods of facilitating contact management using a computerized system including a set of titles
|15 May 2003
|16 Feb 2006
|Stefan Roever
|Methods and apparatus for title protocol, authentication, and sharing
|17 Oct 2005
|23 Feb 2006
|Damaka, Inc.
|System and method for routing and communicating in a heterogeneous network environment
|17 Aug 2004
|23 Feb 2006
|Theda Benja-Athon
|Method of improving physicians' productivity
|30 Aug 2005
|9 Mar 2006
|Damaka, Inc.
|System and method for traversing a NAT device for peer-to peer hybrid communications
|16 Sep 2004
|16 Mar 2006
|Target Brands, Inc.
|Financial transaction approval system and method
|2 Nov 2005
|4 May 2006
|Kvarts, Llc
|System and method for authenticating users for secure mobile electronic gaming
|2 Nov 2005
|4 May 2006
|Global Direct Management Corp.
|System and method for authenticating users for secure mobile electronic transactions
|14 Dec 2005
|4 May 2006
|Damaka, Inc.
|System and method for conducting an auction in a peer-to peer network
|27 Jan 2006
|8 Jun 2006
|Damaka, Inc.
|System and method for data transfer in a peer-to peer hybrid communication network
|24 Jan 2005
|27 Jul 2006
|Microsoft Corporation
|Multi-merchant purchasing environment for downloadable products
|24 Jan 2005
|27 Jul 2006
|Microsoft Corporation
|Product locker for multi-merchant purchasing environment for downloadable products
|3 Jun 2005
|3 Aug 2006
|Navio Systems Inc.
|Methods and apparatus for optimizing digital asset distribution
|29 Apr 2005
|3 Aug 2006
|Navio Systems, Inc.
|Methods and apparatus for optimizing identity management
|31 Oct 2005
|10 Aug 2006
|Oliver Stanke
|Method and system for digital asset management
|31 Oct 2005
|10 Aug 2006
|Jutta Weber
|Integration of a digital asset management system with a network sales system
|31 Oct 2005
|10 Aug 2006
|Jutta Weber
|Integration of a digital asset management system with a project management system
|25 Feb 2005
|31 Aug 2006
|Leapfrog Technologies, Inc.
|Wireless electronic coupon delivery system for use by mobile communication devices
|15 May 2006
|14 Sep 2006
|Damaka, Inc.
|System and method for conferencing in a peer-to-peer hybrid communications network
|15 May 2006
|14 Sep 2006
|Damaka, Inc.
|System and method for natural language processing in a peer-to-peer hybrid communications network
|31 Oct 2005
|28 Sep 2006
|Jutta Weber
|Integration of digital asset management with intellectual property management
|15 May 2006
|28 Sep 2006
|Damaka, Inc.
|System and method for concurrent sessions in a peer-to-peer hybrid communications network
|16 May 2006
|16 Nov 2006
|Knowlton Kier L
|Building digital assets for use with software applications
|20 Jun 2005
|21 Dec 2006
|Microsoft Corporation
|Secure online transactions using a captcha image as a watermark
|22 Aug 2006
|4 Jan 2007
|Microsoft Corporation
|Secure online transactions using a captcha image as a watermark
|8 Jul 2005
|11 Jan 2007
|Microsoft Corporation
|Secure online transactions using a trusted digital identity
|23 Jun 2006
|1 Feb 2007
|Microsoft Corporation
|Add License Anonymously To Product Locker For Multi-Merchant Purchasing Environment
|13 Nov 2006
|5 Apr 2007
|Damaka, Inc.
|System and method for advertising in a peer-to-peer hybrid communications network
|7 Nov 2006
|19 Apr 2007
|Leapfrog Technologies, Inc.
|Wireless electronic coupon delivery system for use by mobile communication devices
|31 May 2006
|20 Dec 2007
|Big Fish Games, Inc
|Operation of a Network Service Recruitment Architecture
|17 Oct 2007
|25 Sep 2008
|Aaron Henry Holm
|Digital File Management System With Unstructured Job Upload
|31 Mar 2011
|Partnet, Inc.
|Systems and methods for providing an asset title corresponding to an asset
|4 Aug 2011
|Brightcove, Inc.
|Distribution of content
|15 Sep 2011
|Wright Michael W
|Web-Hosted Self-Managed Virtual Systems With Complex Rule-Based Content Access
|29 Sep 2011
|Robin Daniel Chamberlain
|System and/or method for linking network content
|9 Apr 2009
|20 Oct 2011
|Bahman Mobasser
|Method of broadcasting digital content, network and terminal for implementing that method
|19 Jan 2012
|Enyama, Inc.
|Techniques For Provisioning Content
|24 Feb 2011
|20 Dec 2012
|Rakuten, Inc.
|Storage device, server device, storage system, database device, provision method of data, and program
|27 Feb 2012
|31 Jan 2013
|Redigi, Inc.
|Methods and Apparatus for Sharing, Transferring and Removing Previously Owned Digital Media
|22 Aug 2012
|28 Feb 2013
|Hung-Yu Chen
|E-commerce transaction system and method for intangible merchandises
|28 Feb 2013
|Steven Michael Rourke
|System and method for content syndication service
|20 Oct 2011
|25 Apr 2013
|Ebay Inc.
|Sending and receiving digital goods through a service provider
|23 Jan 2013
|16 Jan 2014
|Owl Computing Technologies, Inc.
|File manifest filter for unidirectional transfer of files
|4 Dec 2013
|27 Mar 2014
|C-Sam, Inc.
|Aggregating multiple transaction protocols for transacting between a plurality of distinct payment acquiring devices and a transaction acquirer
|5 Oct 2012
|10 Apr 2014
|Microsoft Corporation
|Dynamic captions from social streams
|7 Dec 2012
|12 Jun 2014
|Whp Workflow Solutions, Llc
|Multi-media file upload workflow and transactions
|28 Feb 2013
|28 Aug 2014
|Apple Inc.
|Network-based distribution system supporting transfer of application products
|24 May 2013
|27 Nov 2014
|Bank Of America Corporation
|Multiple Payee Endorsement
|21 Jun 2013
|25 Dec 2014
|Here Global B.V.
|Methods, apparatuses, and computer program products for facilitating a data interchange protocol
|30 Sep 2014
|15 Jan 2015
|Quickplay Media Inc.
|Automated content tag processing for mobile media
|25 Oct 2010
|16 May 2012
|Method and system for realizing color ring back tone service
|23 May 2012
|9 Apr 2014
|Amazon Technologies, Inc.
|Service for managing digital content resales
|22 Dec 2006
|12 Jul 2007
|Navio Systems Inc
|Software, systems, and methods for processing digital bearer instruments
|16 Jan 2007
|26 Jul 2007
|Patrick Questembert
|Systems, methods and computer readable code for visualizing and managing digital cash
|2 Mar 2007
|13 Sep 2007
|Sybase 365 Inc
|System and method for subscription management
|26 Mar 2007
|4 Oct 2007
|Chen Benjamin
|Facilitating online content syndication
|30 Apr 2007
|15 Nov 2007
|Kevin Collins
|Enhanced title processing arrangement
|2 Nov 2007
|15 May 2008
|Metropolitan Life Insurance Co
|System and method for remote deposit capture
|1 Nov 2007
|15 May 2008
|Adams Thom
|System and method for managing information using entity-centric objects
|15 Nov 2007
|22 May 2008
|Tracfone Wireless Inc
|Prepaid wireless service and billing system, apparatus and method
|27 Nov 2007
|23 Oct 2008
|Cisco Tech Inc
|Messaging security device
|30 Sep 2010
|7 Apr 2011
|Partnet, Inc.
|Systems and methods for providing an asset title corresponding to an asset
|10 Nov 2010
|26 May 2011
|American Express Travel Related Services Company, Inc.
|File listener system and method
|23 May 2012
|29 Nov 2012
|Amazon Technologies, Inc.
|Service for managing digital content resales
|18 Jan 2013
|25 Jul 2013
|Myspace, Llc
|Media exchange platform
|11 Jan 2013
|3 Oct 2013
|Shankar Narayanan
|Digital emulation of cash-based transactions
|18 Oct 2013
|5 Jun 2014
|Apple Inc.
|Assigning electronically purchased items of content to users
|24 Dec 2013
|4 Sep 2014
|Apple Inc.
|Network-based distribution system supporting transfer of application products
|U.S. Classification
|705/35, 705/902
|International Classification
|Cooperative Classification
|European Classification
|23 Jun 2005
Owner name: NAVIO SYSTEMS, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ROEVER, STEFAN;COLLINS, KEVIN;CLARK, ALEX F.;AND OTHERS;REEL/FRAME:016717/0578;SIGNING DATES FROM 20050504 TO 20050526