Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
  • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
  • H04N21/4627—Rights management associated to the content

Definitions

• the present invention generally relates to the field of processing statements and expressions, including rights expressions, and more particularly to a method, system, and device for determining authorization of rights expressions with respect to a trust root.
• IPRM Intellectual Property Rights Management
• DPRM Digital Property Rights Management
• IPM Intelligent Property Management
• RM Remote Method Management
• ECM Electronic Copyright Management
• DRM Digital Rights Management
• U.S. patents 5,530,235, 5,634,012, 5,715,403, 5,638,443, and 5,629,980 the disclosures of which are incorporated herein by reference, address such issues.
• Certificate languages such as X.509 and SPKI, allow only relatively simple conditions, primarily validity time intervals, in each certificate. Accordingly, the most common certificate chain verification algorithms for these languages (e.g., Internet Engineering Task Force (IETF) RFC 2459, and RFC 2693, respectively) are relatively straight-forward to execute.
• IETF Internet Engineering Task Force
• scope e.g., limit
• each agent's certification to issue rights expressions to apply only to the assets it owns or controls. Determining the correct scope for each certificate takes some work, but is doable.
• the expression of such scoping can be accomplished using, for example, techniques described in U.S. Patent Application Serial No. 10/162,701 to Xin, et al, entitled “METHOD AND APPARATUS MANAGING THE TRANSFER OF RIGHTS" and U.S. Patent Application Serial No.
• a scoped certificate might say that agent Publisher 1 may issue rights expressions pertaining to paperback Book 1.
• Publisher -1 might actually issue a rights expression to agent Consumer 1, allowing Consumer 1 to view any paperback book.
• Consumer 1 only will be able to view paperback Book 1.
• another scoped certificate is later added that says that Publisher 1 may also issue rights expressions pertaining to paperback Book 2
• Consumer 1 will be able to view both paperback Book 1 and paperback Book 2 (since Publisher 1 said Consumer 1 could view any paperback book and since Publisher l's issuing ability is scoped to paperback Book 1 and paperback Book 2).
• One of the potential difficulties in verifying a certificate chain, including creative conditions, is the information needed to execute the verification typically is not available. For example, consider a scenario including three agents, an author, a reader, and a friend. There is one rights expression that allows the author to issue rights expressions pertaining to his book. There is another rights expression from the author to the reader, allowing the reader to read the book, and issue up to two rights expressions, one each to two of his friends. There is a third rights expression from the reader to his friend, allowing his friend to view the book. When the friend wants to view the book, he will verify the certificate chain, including the rights expressions, and at some point will have to determine if the reader has satisfied the condition of issuing only up to two rights expressions.
• W618 5 73.1 author and the reader This means that the author and reader cannot upgrade the conditions they use, unless the friend also updates the conditions it can understand.
• One solution to this, is to store the information about satisfaction of conditions in a way that the friend can process that information, without having detailed knowledge of the condition (e.g., by comparing the names of satisfied conditions with the names of conditions that need to be satisfied).
• the friend has access to the information about and names of the conditions under which the reader can issue rights expressions, because in some situations it is not desirable to share the information, such as where the information is considered confidential. For example, if there is a fee associated with the reader giving his friend a rights expression as a gift, the reader may not wish his friend to know the price of the gift.
• the condition information might be encrypted so that the friend cannot discern it, but the friend's software or hardware can process it. This extra encryption, however, also complicates the system design to some degree. In situations where knowledge of the details of the conditions is more sensitive than the actual assets themselves, the cost of the encryption needed on the conditions could be disproportionate to the asset's value.
• a method, system, and device for verifying authorized issuance of a statement or expression including determining if a statement or expression is associated with a
• W618 5 73.1 statement of trusted issuance determining if the statement of trusted issuance applies; determining if issuance of the statement of trusted issuance is authorized; and verifying that the issuance of the statement or expression was authorized, if the statement of trusted issuance applies, and the issuance of the statement of trusted issuance is authorized.
• Figure 1 shows a rights derivation scenario with a trust root, six derived rights expressions, and two statements of trusted issuance;
• Figure 2 shows a rights derivation scenario with a trust root, two derived rights expressions, a derived statement or expression, and a statement of trusted issuance;
• Figure 3 shows a procedure using statements of trusted issuance for verifying the authorized issuance of a rights expression
• Figure 4 shows an alternative configuration of rights expressions and statements of trusted issuance from that shown in Figure 1 ;
• Figure 5 shows alternative contents of a statement of trusted issuance from that shown in Figure 1 ;
• Figure 6 shows an exemplary issuance chain verification signal
• Figure 7 shows an exemplary system for verifying authorized issuance of a rights expression.
• the exemplary embodiments include a statement of trusted issuance, which is a statement including a claim that an issuance was authorized according to some trust root or rights expression.
• a statement of trusted issuance can be issued by an agent who is able to verify a statement or expression, including rights expression, and including a statement or expression chain (or a part of a chain) and can be relied on by other agents who might be unable or less able to perform such verification.
• Figure 1 shows a trust root 101, and six rights expressions, 103, 105,
• the rights expression 103 is derived from the trust root 101, and is issued by agent A to agent B. No statement of trusted issuance is included in the rights expression 103.
• the rights expression 105 is derived from the rights expression 103, and is issued by agent B to agent C. No statement of trusted issuance is included in the rights expression 105.
• the rights expression 107 is derived from the rights expression 105, and is issued by agent C to agent D.
• the rights expression 107 includes a statement of trusted issuance 115 rooted with agent A.
• the statement of trusted issuance 115 can be used in conjunction with rights expression 117 to verify that rights expression 107 was issued correctly with respect to the trust root 101, without tracing through rights expressions 105 and 103, if agent Z is considered to be trusted.
• the exemplary embodiment of Figure 1, as well as the other exemplary embodiments, also applies to statements or expressions, other than rights expressions.
• Agent A in statement of trusted issuance 115, is
• W618 5 73.1 represented in the exemplary XML representation using RSA public key information.
• the issuer field in statement of trusted issuance 115 is omitted from the exemplary XML representation, because it is to be inherited from the rights expression, which includes the statement of trusted issuance.
• the exemplary embodiments include subsequent derivative statements or expressions, including rights expressions.
• the rights expression 109 is derived from the rights expression 107, and is issued by agent D to agent E. Because rights expression 109 has no statement of trusted issuance, when using rights expression 109, the conditions of the derivation of rights expression 109 from rights expression 107 must be re- verified to establish the authorized issuance of rights expression 109. Further verification of the conditions of the derivation of rights expression 107 from rights expression 105 is not needed, because rights expression 107 includes statement of trusted issuance 115 that can be utilized, as previously described, when agent Z is considered to be trusted by agent E.
• agent E can include, for example, the statement of trusted issuance 119 rooted with agent A inside rights expression 111.
• agent F uses rights expression 111 to, for example, play a media file or derive another rights expression 113
• the statement of trusted issuance 119 can be used in conjunction with rights expression 121 to verify that rights expression 111 was issued correctly with respect to the trust root 101, without tracing through rights expressions 109, 107, 105, and 103.
• Figure 2 shows a rights derivation scenario similar to the one shown in
• statement or expression 207 could be any statement or expression.
• statement or expression 207 could express that Agent C claims that pigs flew yesterday, that pigs will fly tomorrow, that contractual obligations were fulfilled, that an entity is certified for certain
• W618573.1 qualification such as retailer for branded goods or Microsoft certified engineer, or that a purchase was made.
• Statement of trusted issuance 215, and second rights expression 217 can be used to determine that the issuance by Agent C of statement or expression 207 was authorized, based on trust root 201, in the same way that statement of trusted issuance 115 and second rights expression 117 were used to determine that the issuance by Agent C of rights expression 107 was authorized, based on trust root 101.
• FIG. 3 An exemplary procedure for verifying the authorized issuance of a statement or expression, such as a rights expression, is shown in Figure 3.
• the process starts at step 301, and at step 303 an attempt is made to find a statement or expression, including some desired claims, for example, when attempting to find a rights expression, such as usage rights to a media file. If no suitable statement or expression can be found (e.g., no rights are granted for that file or some conditions for the rights that have been granted are not met, such as time expired, fee not paid, too early to view) the process terminates in failure at step 305. If, however, a suitable statement or expression is found, it is examined at step 307.
• step 309 if the statement or expression does not include a statement of trusted issuance, the process continues at step 311, follows a sub-process to be described in more detail, and terminates in either success at step 313 or failure at step 305 or processing returns to step 307. Specifically, if the issuer of the statement or expression matches the trust root at step 311 , the process terminates in success at step 313. Otherwise, if the rights expression from which the examined statement or expression was derived (and for which all conditions were satisfied at the time of derivation) can be found (possibly with the help of additional entities) in step 315, the process returns to step 307 using that new rights expression. Otherwise, the process terminates in failure at step 305.
• step 309 finds that the statement or expression includes a statement of trusted issuance
• step 319 determines if the statement of trusted issuance matches the trust root. If so, step 321 determines if the statement of trusted issuance is authorized. This determination can be made by a variety of means, for
• step 321 determines the statement of trusted issuance is authorized, the process terminates in success at step 313, advantageously, in many cases, either faster than it would have terminated in success at step 313 resulting from step 311 or more desirable than it would have terminated in failure at step 305. If either of the determinations in steps 319 or 321 is negative, the process continues at step 311.
• Figure 4 shows items 407, 415, and 417 representing an alternate configuration of items 107, 115, and 117 of Figure 1, respectively.
• statement of trusted issuance 415 applying to rights expression 407, does not appear inside rights expression 407. Instead, some other means is used to link the two.
• the issuers of rights expression 107 and statement of trusted issuance 115 are the same, the issuer of rights expression 407 is different from the issuer of statement of trusted issuance 415.
• rights expression 117 authorizing the issuance of statement of trusted issuance 115, is issued by a third party
• rights expression 417 authorizing the issuance of statement of trusted issuance 415, is issued by the same agent through which the statement of trusted issuance claims issuance should be trusted.
• the exemplary embodiments include other forms of configurations and variations, wherein the exemplary process shown in Figure 3 still applies thereto.
• statement of trusted issuance 515 includes an indication that authorized issuance has been verified through rights expression 503.
• agent D can use rights expression 507 and included statement of trusted issuance 515, and second rights expression 517 to determine that the authorization to issue rights expression 507 traces back to rights expression 503. Agent D then can continue the chain verification process independently to determine whether the issuance of rights expression 503 was authorized, based on trust root 501.
• W618 5 73.1 11 By employing the exemplary embodiments, it is possible to implement many of the desired features in Digital Rights Management (DRM), while lowering costs.
• DRM Digital Rights Management
• the publisher A might issue a rights expression 103 to distributor B to distribute all of the publisher's paperback books in the United States and Canada.
• Distributor B then may issue a rights expression 105 to retailer C to retail paperbacks from that publisher in the United States and Canada for a publisher price of $2 each.
• retailer C After consumer D pays retailer C $5, retailer C then may issue a rights expression 107 to consumer D to read a paperback Book 1.
• retailer C When retailer C issues rights expression 107, retailer C checks the rights expression chain to verify that all conditions on all parties have been fulfilled, including that distributor B distributed paperbacks, that distributor B distributed them within the United States and Canada, and that $2 of the $5 the consumer paid went to publisher A. Because retailer C has verified the authorized issuance of rights expression 107, based on publisher A as the trust root, retailer C inserts statement of trusted issuance 115 into rights expression 107 on issuance.
• Consumer D now is able to determine if he is permitted to play paperback Book 1, by looking at just a few rights expressions, including one that says that publisher A is the trust root for Book 1, rights expression 107 that says that retailer C says consumer D may play paperback Book 1 and includes a statement of trusted issuance rooted with publisher A, and rights expression 117 that says that retailer C can issue statements of trusted issuance rooted with publisher A.
• consumer D may know that the distribution occurred in the United States in paperback form, consumer D is not required to have access to any information about where the distribution occurred, in what form, how much of his money was paid to the publisher or the like. Moreover, consumer D does not have to know what the actual possibilities and conditions of distribution were (e.g., that the book could also have been distributed in Canada, but that hardback books could not have been distributed and that $2 must have been paid to the publisher).
• consumer D does not have to know such details, it is also possible for publisher A, distributor B, and retailer C to change their software or hardware to support additional creative conditions without impacting or having to worry about the impact on consumer D. Since consumer D does not have to have access to rights expression 103 or 105, it is also not necessary to incur the expense of encrypting or otherwise protecting these rights expressions or making sure that consumer D has secure software or hardware to decrypt and access the rights expressions.
• the task of verifying the authorized issuance of a rights expression with respect to a trust root becomes much more straightforward for consumer D.
• the trust root may restrict the right to issue a statement of trusted issuance to certain agents or agents meeting certain criteria, including, for example, criteria of trustworthiness.
• an agent may decline to rely on a statement of trusted issuance issued by another. The decision whether to rely on a statement may be based on some criteria or the agent may decide not to rely on such statements generally.
• agents may be prohibited from relying on a statement of trusted issuance issued by certain other agents.
• agents would have the option of relying on a statement of trusted issuance or could "bypass" the statement, and verify all or part of a rights
• agents may be required to rely on a statement of trusted issuance, wherein an agent would not be allowed to verify all or part of a rights expression chain or otherwise access or inspect the rights expression chain.
• the exemplary embodiments also can be used for the authorization determination of other statements or expressions.
• a proof of purchase certificate must be presented in order to service goods manufactured by A.
• D can issue a proof of purchase.
• its authorization needs to be traced back from C to B to A.
• the proof of purchase certificate issued by D includes a statement of trusted issuance rooted with manufacturer A, as described with respect to the exemplary embodiments, the verification of the authorization for this proof of purchase certificate can be simplified and expedited.
• the exemplary embodiments can include a language for statements of trusted issuance (also called an issuance chain verification signal language), which could be compatible with the ISO MPEG REL.
• a language for statements of trusted issuance also called an issuance chain verification signal language
• terminology can be as used in the ISO MPEG REL.
• Clause 3 (Terms, definitions, symbols, and abbreviated terms) and Clause 4 (Namespaces and Conventions) from the ISO MPEG REL are incorporated by reference herein.
• the URI urn standards-organization : 2004 : icvs (for use with sx :property ⁇ ri) defines a property for certifying that a Principal's issuance chain verification signals are to be trusted.
• Ur otherlnf o/sx : issuanceChainVerif icationThrough z.
• the Principal identified by p shall verify, for each k from 1 to the number of z/sx : h children of i, for each 7 from 1 to the number of //sx : h/r : trustRoot children of the £* z/sx : h child of z, that there is an authorization proof for the authorization request (p, r : issue, h, v, S, L, R) where h is the A* Ur : grant or Ur : grantGroup ha. I, R is they* i/sx : h/r : trustRoot child of the A" 1 i/sx : h child of z, and v, S, and Z, are chosen accurately.
• a conventional rights interpreter attempting to verify if some Principal identified by an ⁇ Principal p was permitted to include some r : Grant or r : GrantGroup h in a License he issued could potentially encounter some difficulties: the Licenses permitting that inclusion (for instance, those including an ⁇ issue element) or the historical circumstances of that inclusion (for instance, any fees that were paid or counts that were consumed) might not be available to the rights interpreter.
• Figure 7 shows an exemplary system 700 for verifying authorized issuance of a rights expression in accordance with the exemplary embodiments of Figures 1-6.
• the exemplary system 700 can include one or more devices 702-708, a content server 710, and content database 712, coupled together via a communications network 714.
• the above-described devices and subsystems of the exemplary embodiments of Figures 1-7 can include, for example, any suitable servers, workstations, PCs, laptop computers, PDAs, Internet appliances, handheld devices, cellular telephones, wireless devices, other devices, and the like, capable of performing the processes of the exemplary embodiments of Figures 1-7.
• the devices and subsystems of the exemplary embodiments of Figures 1-7 can communicate with each other using any suitable protocol and can be implemented using one or more programmed computer systems or devices.
• One or more interface mechanisms can be used with the exemplary embodiments of Figures 1-7, including, for example, Internet access, telecommunications in any suitable form (e.g., voice, modem, and the like), wireless communications media, and the like.
• the communications network 714 can include one or more wireless communications networks, cellular communications networks, G3 communications networks, Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, a combination thereof, and the like.
• PSTNs Public Switched Telephone Network
• PDNs Packet Data Networks
• the Internet intranets, a combination thereof, and the like.
• a single computer system can be programmed to perform the special purpose functions of one or more of the devices and subsystems of the exemplary embodiments of Figures 1-7.
• two or more programmed computer systems or devices can be substituted for any one of the devices and subsystems of the exemplary embodiments of Figures 1-7.
• principles and advantages of distributed processing such as redundancy, replication, and the like, also can be implemented, as desired, to increase the robustness and performance of the devices and subsystems of the exemplary embodiments of Figures 1-7.
• FIG. 1-7 can store information relating to various processes described herein. This information can be stored in one or more memories, such as a hard disk, optical disk, magneto-optical disk, RAM, and the like, of the devices and subsystems of the exemplary embodiments of Figures 1-7.
• One or more databases of the devices and subsystems of the exemplary embodiments of Figures 1-7 can store the information used to implement the exemplary embodiments of the present invention.
• the databases can be organized using data structures (e.g., records, tables, arrays, fields, graphs, trees, lists, and the like) included in one or more memories or storage devices listed herein.
• the processes described with respect to the exemplary embodiments of Figures 1-7 can include appropriate data structures for storing data collected and/or generated by the processes of the devices and subsystems of the exemplary embodiments of Figures 1-7 in one or more databases thereof.
• All or a portion of the devices and subsystems of the exemplary embodiments of Figures 1-7 can be conveniently implemented using one or more general purpose computer systems, microprocessors, digital signal processors, micro ⁇ controllers, and the like, programmed according to the teachings of the exemplary embodiments of the present invention, as will be appreciated by those skilled in the computer and software arts. Appropriate software can be readily prepared by programmers of ordinary skill based on the teachings of the exemplary embodiments, as will be appreciated by those skilled in the software art. Further, the devices and subsystems of the exemplary embodiments of Figures 1-7 can be implemented on the World Wide Web.
• the devices and subsystems of the exemplary embodiments of Figures 1-7 can be implemented by the preparation of application- specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be appreciated by those skilled in the electrical art(s).
• the exemplary embodiments are not limited to any specific combination of hardware circuitry and/or software.
• the exemplary embodiments of the present invention can include software for controlling the devices and subsystems of the exemplary embodiments of Figures 1-7, for driving the devices and subsystems of the exemplary embodiments of Figures 1-7, for enabling the devices and subsystems of the exemplary embodiments of Figures 1- 7 to interact with a human user, and the like.
• Such software can include, but is not limited to, device drivers, firmware, operating systems, development tools, applications software, and the like.
• Such computer readable media further can include the computer program product of an embodiment of the present invention for performing all or a portion (if processing is distributed) of the processing performed in implementing the invention.
• Computer code devices of the exemplary embodiments of the present invention can include any suitable interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), Java classes and applets, complete
• W618573.1 19 executable programs, Common Object Request Broker Architecture (CORBA) objects, and the like. Moreover, parts of the processing of the exemplary embodiments of the present invention can be distributed for better performance, reliability, cost, and the like.
• CORBA Common Object Request Broker Architecture
• the devices and subsystems of the exemplary embodiments of Figures 1-7 can include computer readable medium or memories for holding instructions programmed according to the teachings of the present invention and for holding data structures, tables, records, and/or other data described herein.
• Computer readable medium can include any suitable medium that participates in providing instructions to a processor for execution. Such a medium can take many forms, including but not limited to, non-volatile media, volatile media, transmission media, and the like.
• Non- volatile media can include, for example, optical or magnetic disks, magneto-optical disks, and the like.
• Volatile media can include dynamic memories, and the like.
• Transmission media can include coaxial cables, copper wire, fiber optics, and the like.
• Transmission media also can take the form of acoustic, optical, electromagnetic waves, and the like, such as those generated during radio frequency (RF) communications, infrared (IR) data communications, and the like.
• RF radio frequency
• IR infrared
• Common forms of computer-readable media can include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other suitable magnetic medium, a CD- ROM, CDRW, DVD, any other suitable optical medium, punch cards, paper tape, optical mark sheets, any other suitable physical medium with patterns of holes or other optically recognizable indicia, a RAM, a PROM, an EPROM, a FLASH- EPROM, any other suitable memory chip or cartridge, a carrier wave, or any other suitable medium from which a computer can read.
• an AGENT can include an entity that can act, possibly on behalf of another entity and/or according to a set of rules (examples of agents are hardware devices, integrated circuits, firmware modules, software modules, software systems, humans, organizations, services, smart cards, and seeing-eye dogs).
• An ASSET can include an entity, quality, event, state,
• W018S73.1 20 concept, substance, or anything else referred to by a noun and possibly of some value examples of assets are books, e-books, videos, services, web services, companies, security levels, domain names, e-mail addresses, football games, messages, and rights.
• a CERTIFICATE can include a "rights expression”.
• a CONDITION can include a limitation on some claim made in an expression or statement (examples are times of validity, territories of applicability, numbers of times the claim can be relied on, and situations in which the claim holds).
• To ISSUE can include an act of making the claims in an expression or statement and standing behind those claims.
• METARIGHTS can include rights with respect to other rights.
• RIGHTS can include actions or attributes an agent is permitted to take possibly with respect to an asset or to other rights (examples of actions are walk and shutdown; examples of actions with respect to assets are consumption actions such as play and print, modification actions such as edit and append, distribution actions, such as copy and move, and service actions such as requests ervice and sendMessage; examples of actions with respect to other rights are issue and revoke; examples of attributes are name, address, color, securityLevel, employee, relative, friend, domain, graduate, and certifiedRepairFacility; examples of attributes with respect to assets are author and distributor; examples of attributes with respect to other rights are issuanceChainVerifier, certificate Authority, and trustedlssuer).
• DERIVATION can include issuing a statement or expression such as a rights expression whose issuance was permitted within another rights expression or a trust root (the issued statement or rights expression is called the derived statement or derived rights expression and it is said to be derived from the rights expression or trust root that permitted its issuance).
• a RIGHTS EXPRESSION can include an expression including a claim that rights are granted (examples of rights expression languages include the ISO MPEG REL, the extensible rights Markup Language, the Contract Expression Language from the Content Reference Forum (see http://www.crforum.org/), the Open Digital Rights Language from IPRSystems, OMA DRM 2.0 Specification Rights Expression Language, the Security Assertion Markup Language from the Organization for the Advancement of Structured Information
• W618 5 73.1 21 Standards OASIS
• OASIS extensible Access Control Markup Language
• X.509 the extensible Access Control Markup Language from OASIS
• SPKI the Rights Management and Protection Information from the TV Anytime Forum
• Copy Control Information bits can include creating something that gives confidence that an expression or statement that a party issues actually is issued by said party.
• a STATEMENT OF TRUSTED ISSUANCE can include a statement including a claim that an issuance was authorized according to some trust root or rights expression.
• a TRUST ROOT can include an encapsulation of rights that are assumed to be authorized.
• the exemplary embodiments are described in terms of use of a rights expression, and distribution and use of digital works, the exemplary embodiments are not restricted to rights expressions, and digital works. Accordingly, the benefits associated with not having to process all the data in a chain of data and the other advantages of the exemplary embodiments can apply to other kinds of computing applications.
• the exemplary embodiments can be used in connection with other statements or expressions, which can benefit from an efficient method to determine authorization, such as proof of transaction, proof of purchase, proof of certification, proof of identity, proof of approval, statement of fact, business intent, business contract, rules, policies, and the like.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Multimedia (AREA)
• Technology Law (AREA)
• Computer Hardware Design (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Databases & Information Systems (AREA)
• Signal Processing (AREA)
• Storage Device Security (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=36407422

Family Applications (1)

Country Status (5)

Families Citing this family (1)

Family Cites Families (7)

• 2004
  • 2004-11-12 EP EP04810791A patent/EP1817727A1/de not_active Withdrawn
  • 2004-11-12 KR KR1020127003578A patent/KR101197665B1/ko not_active IP Right Cessation
  • 2004-11-12 WO PCT/US2004/037734 patent/WO2006054963A1/en active Application Filing
  • 2004-11-12 CN CNA2004800446426A patent/CN101084503A/zh active Pending
  • 2004-11-12 JP JP2007541152A patent/JP4951518B2/ja not_active Expired - Fee Related

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events