US20100070774A1 - Interoperable systems and methods for peer-to-peer service orchestration - Google Patents
Interoperable systems and methods for peer-to-peer service orchestration Download PDFInfo
- Publication number
- US20100070774A1 US20100070774A1 US12/620,452 US62045209A US2010070774A1 US 20100070774 A1 US20100070774 A1 US 20100070774A1 US 62045209 A US62045209 A US 62045209A US 2010070774 A1 US2010070774 A1 US 2010070774A1
- Authority
- US
- United States
- Prior art keywords
- service
- node
- services
- content
- nemo
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 title abstract description 71
- 238000009739 binding Methods 0.000 claims abstract description 92
- 230000027455 binding Effects 0.000 claims abstract description 91
- 230000009471 action Effects 0.000 claims description 22
- 230000015572 biosynthetic process Effects 0.000 abstract description 3
- 229920002239 polyacrylonitrile Polymers 0.000 abstract 1
- 201000006292 polyarteritis nodosa Diseases 0.000 abstract 1
- 239000000344 soap Substances 0.000 abstract 1
- 230000004044 response Effects 0.000 description 99
- 230000003993 interaction Effects 0.000 description 53
- 238000013475 authorization Methods 0.000 description 51
- 238000012545 processing Methods 0.000 description 50
- 230000008569 process Effects 0.000 description 49
- 238000007726 management method Methods 0.000 description 43
- 238000004891 communication Methods 0.000 description 39
- 230000007246 mechanism Effects 0.000 description 26
- 230000006870 function Effects 0.000 description 25
- 239000008186 active pharmaceutical agent Substances 0.000 description 22
- 238000004806 packaging method and process Methods 0.000 description 20
- 230000006978 adaptation Effects 0.000 description 17
- 238000009795 derivation Methods 0.000 description 15
- 239000003795 chemical substances by application Substances 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 9
- 230000008901 benefit Effects 0.000 description 8
- 230000008859 change Effects 0.000 description 8
- 230000010354 integration Effects 0.000 description 8
- 238000009877 rendering Methods 0.000 description 8
- 238000013459 approach Methods 0.000 description 7
- 238000004422 calculation algorithm Methods 0.000 description 7
- 239000002131 composite material Substances 0.000 description 7
- 238000013507 mapping Methods 0.000 description 7
- 101000873111 Homo sapiens Vesicle transport protein SEC20 Proteins 0.000 description 6
- 102100035030 Vesicle transport protein SEC20 Human genes 0.000 description 6
- 230000001360 synchronised effect Effects 0.000 description 6
- 238000012795 verification Methods 0.000 description 6
- 230000002776 aggregation Effects 0.000 description 5
- 238000004220 aggregation Methods 0.000 description 5
- 230000000694 effects Effects 0.000 description 5
- 229920001690 polydopamine Polymers 0.000 description 5
- 230000014509 gene expression Effects 0.000 description 4
- 238000000926 separation method Methods 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 230000008838 symmetric binding Effects 0.000 description 4
- 241001125671 Eretmochelys imbricata Species 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 3
- 238000005314 correlation function Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 239000000203 mixture Substances 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 230000001012 protector Effects 0.000 description 3
- 230000001052 transient effect Effects 0.000 description 3
- 230000007723 transport mechanism Effects 0.000 description 3
- 101150003901 PRKD1 gene Proteins 0.000 description 2
- 230000009118 appropriate response Effects 0.000 description 2
- 230000004888 barrier function Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 230000008878 coupling Effects 0.000 description 2
- 238000010168 coupling process Methods 0.000 description 2
- 238000005859 coupling reaction Methods 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 230000007613 environmental effect Effects 0.000 description 2
- 230000008676 import Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000009870 specific binding Effects 0.000 description 2
- 230000008685 targeting Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- LMDZBCPBFSXMTL-UHFFFAOYSA-N 1-ethyl-3-(3-dimethylaminopropyl)carbodiimide Chemical compound CCN=C=NCCCN(C)C LMDZBCPBFSXMTL-UHFFFAOYSA-N 0.000 description 1
- 240000007643 Phytolacca americana Species 0.000 description 1
- 239000004696 Poly ether ether ketone Substances 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- JUPQTSLXMOCDHR-UHFFFAOYSA-N benzene-1,4-diol;bis(4-fluorophenyl)methanone Chemical compound OC1=CC=C(O)C=C1.C1=CC(F)=CC=C1C(=O)C1=CC=C(F)C=C1 JUPQTSLXMOCDHR-UHFFFAOYSA-N 0.000 description 1
- 238000003339 best practice Methods 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000008275 binding mechanism Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000001427 coherent effect Effects 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 238000013506 data mapping Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000034184 interaction with host Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000007935 neutral effect Effects 0.000 description 1
- 238000012858 packaging process Methods 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 229920002530 polyetherether ketone Polymers 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 229910052710 silicon Inorganic materials 0.000 description 1
- 239000010703 silicon Substances 0.000 description 1
- 239000004557 technical material Substances 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
- G06Q20/123—Shopping for digital content
- G06Q20/1235—Shopping for digital content with control of digital rights management [DRM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/951—Indexing; Web crawling techniques
-
- 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]
- G06F21/107—License processing; Key processing
- G06F21/1073—Conversion
-
- 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]
- G06F21/108—Transfer of content, software, digital rights or licenses
- G06F21/1084—Transfer of content, software, digital rights or licenses via third party
-
- 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]
- G06F21/108—Transfer of content, software, digital rights or licenses
- G06F21/1085—Content sharing, e.g. peer-to-peer [P2P]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0281—Proxies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q2220/00—Business processing using cryptography
- G06Q2220/10—Usage protection of distributed data files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q2220/00—Business processing using cryptography
- G06Q2220/10—Usage protection of distributed data files
- G06Q2220/18—Licensing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
- H04L2209/603—Digital right managament [DRM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/101—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
Definitions
- Networks such as the Internet have become the predominant medium for the delivery of digital content and media related services.
- a services framework is provided that enables multiple types of stakeholders in the consumer or enterprise media space (e.g., consumers, content providers, device manufacturers, service providers) to find each other, establish a trusted relationship, and exchange value in rich and dynamic ways through exposed service interfaces.
- Embodiments of this framework which will be referred to generally as the Network Environment for Media Orchestration (NEMO)—can provide a platform for enabling interoperable, secure, media-related e-commerce in a world of heterogeneous consumer devices, media formats, communication protocols, and security mechanisms.
- Distributed policy management of the service interfaces can be used to help provide trust and security, thereby facilitating commercial exchange of value.
- NEMO While emerging web service standards are beginning to address interoperability issues for Internet-facing services, embodiments of NEMO can be used to address interoperability across multiple network tiers spanning personal and local area networks; home, enterprise, and department gateways; and wide area networks. For example, NEMO can provide interoperability in one interconnected system using cell phones, game platforms, PDAs, PCs, web-based content services, discovery services, notification services, and update services. Embodiments of NEMO can further be used to provide dynamic, peer-to-peer orchestration of both simple and complex services using a variety of local and remote interface bindings (e.g. WS-I[1], Java RMI, DOOM, C, .Net, etc.), thereby enabling the integration of legacy applications.
- local and remote interface bindings e.g. WS-I[1], Java RMI, DOOM, C, .Net, etc.
- diverse service discovery protocols and registries such as Bluetooth, UPnP, Rendezvous, JINI, UDDI, and LDAP (among others) can coexist within the same service, enabling each node to use the discovery service(s) most appropriate for the device that hosts that node.
- Another service might support IP-based as well as wireless SMS notification, or various media formats (MP4, WMF, etc.).
- Embodiments of NEMO satisfy these goals using peer-to-peer (P2P) service orchestration. While the advantages of P2P frameworks have been seen for such things as music and video distribution, P2P technology can be used much more extensively.
- P2P peer-to-peer
- NEMO is also capable of handling situations in which a person carries parts of their personal area network (PAN), moves into the proximity of a LAN or another PAN, and wants to reconfigure service access immediately, as well as connect to many additional services on a peer basis.
- PAN personal area network
- embodiments of NEMO can be used to provide a service-oriented architecture designed to address the deficiencies and limitations of closed, homogeneous DRM systems.
- Preferred embodiments can be used to provide interoperable, secure, media-related commerce and operations for disparate consumer devices, media formats, and security mechanisms.
- preferred embodiments of the present invention enable client-side DRM engines to be relatively simple, enforcing the governance policies set by richer policy management systems operating at the service level.
- Preferred embodiments of the present invention can also provide increased flexibility in the choice of media formats and cryptographic protocols, and can facilitate interoperability between DRM systems.
- a simple, open, and flexible client-side DRM engine can be used to build powerful DRM-enabled applications.
- the DRM engine is designed to integrate easily into a web services environment, and into virtually any host environment or software architecture.
- Service orchestration is used to overcome interoperability barriers. For example, when there is a query for content, the various services (e.g., discovery, search, matching, update, rights exchange, and notification) can be coordinated in order to fulfill the request.
- Preferred embodiments of the orchestration capability allow a user to view all home and Internet-based content caches from any device at any point in a dynamic, multi-tiered network. This capability can be extended to promote sharing of streams and playlists, making impromptu broadcasts and narrowcasts easy to discover and connect to, using many different devices, while ensuring that rights are respected.
- Preferred embodiments of NEMO provide an end-to-end interoperable media distribution system that does not rely on a single set of standards for media format, rights management, and fulfillment protocols.
- Preferred embodiments of NEMO fulfill this goal by providing means for multiple service providers to innovate and introduce new services that benefit both consumers and service providers without having to wait for or depend on a monolithic set of end-to-end standards. Policy management can limit the extent to which pirates can leverage those legitimate services. NEMO allows the network effect to encourage the evolution of a very rich set of legitimate services providing better value than pirates can provide.
- a novel DRM engine and architecture is also presented that can be used with the NEMO framework. This DRM system can be used to achieve some or all of the following goals:
- a DRM engine uses a minimalist stack-based Virtual Machine (VM) to execute control programs (e.g., programs that enforce governance policies).
- VM Virtual Machine
- control programs e.g., programs that enforce governance policies.
- the VM might consist of only a few pages of code.
- the DRM engine is designed to function as a single module integrated into a larger DRM-enabled application.
- Many of the functions that were once performed by monolithic DRM kernels can be requested from the host environment, which may provide these services to other code modules. This allows designers to incorporate standard or proprietary technologies with relative ease.
- DRM engine Flexibility. Because of its modular design, preferred embodiments of the DRM engine can be used in a wide variety of software environments, from embedded devices to general-purpose PCs.
- Embodiments of the DRM engine are suitable for use as reference software, so that code modules and APIs can be implemented by users in virtually any programming language and in systems that they control completely.
- the system does not force users to adopt particular content formats or restrict content encoding.
- the DRM engine is based on a simple graph-based model that turns authorization requests into queries about the structure of the graph.
- the vertices in the graph represent entities in the system, and directed edges represent relationships between these entities.
- the DRM engine does not need to be aware of what these vertices and edges represent in any particular application.
- the DRM client engine can use web services in several ways. For example, vertices and edges in the graph can be dynamically discovered through services. Content and content licenses may also be discovered and delivered to the DRM engine through sophisticated web services. Although one embodiment of the DRM engine can be configured to leverage web services in many places, its architecture is independent of web services, and can be used as a stand-alone client-side DRM kernel.
- the graph topology can be reused to simplify the derivation of content protection keys without requiring cryptographic retargeting.
- the key derivation method is an optional but powerful feature of the DRM engine—the system can also, or alternatively, be capable of integrating with other key management systems.
- the controls that govern content are logically distinct from the cryptographic information used to enforce the governance.
- the controls and cryptographic information are logically distinct from content and content formats. Each of these elements can be delivered separately or in a unified package, thus allowing a high degree of flexibility in designing a content delivery system.
- FIG. 1 illustrates a sample embodiment of the system framework.
- FIG. 2 a illustrates a conceptual network of system nodes.
- FIG. 2 b illustrates system nodes in a P2P network.
- FIG. 2 c illustrates system nodes operating across the Internet.
- FIG. 2 d illustrates a system gateway node.
- FIG. 2 e illustrates a system proxy node
- FIG. 2 f illustrates a system device adapter node.
- FIG. 3 illustrates a conceptual network of DRM devices.
- FIG. 4 illustrates a conceptual DRM node authorization graph.
- FIG. 5 a illustrates a conceptual view of the architecture of a system node.
- FIG. 5 b illustrates multiple service interface bindings supported by the service adaptation layer of a system node.
- FIG. 6 a illustrates basic interaction between a service-providing system node and a service-consuming system node.
- FIG. 6 b is another example of an interaction between a service-providing system node and a service-consuming system node.
- FIG. 7 a illustrates a service access point involved in a client-side WSDL interaction.
- FIG. 7 b illustrates a service access point involved in a client-side native interaction.
- FIG. 7 c illustrates a service access point involved in a service-side point-to-point interaction pattern.
- FIG. 7 d illustrates a service access point involved in a service-side point-to-multiple point interaction pattern.
- FIG. 7 e illustrates a service access point involved in a service-side point-to-intermediary interaction pattern.
- FIG. 8 illustrates an embodiment of the architecture of the service adaptation layer.
- FIG. 9 a illustrates an interaction pattern of a workflow collator relying upon external service providers.
- FIG. 9 b illustrates an interaction pattern of a workflow collator involved in direct multi-phase communications with a client node.
- FIG. 9 c illustrates a basic intra-node interaction pattern of a workflow collator.
- FIG. 9 d illustrates a relatively complex interaction pattern of a workflow collator.
- FIG. 10 illustrates the system integration of a DRM engine.
- FIG. 11 illustrates an embodiment of the architecture of a DRM engine.
- FIG. 12 a illustrates a DRM engine and related elements within a client-side system node.
- FIG. 12 b illustrates a DRM engine and related elements within a service-side system node.
- FIG. 13 illustrates an embodiment of content protection and governance DRM objects.
- FIG. 14 illustrates an embodiment of node and link DRM objects.
- FIG. 15 illustrates an embodiment of DRM cryptographic key elements.
- FIG. 16 illustrates a basic interaction pattern between client and service-providing system nodes.
- FIG. 17 a illustrates a set of notification processing nodes discovering a node that supports a notification handler service.
- FIG. 17 b illustrates the process of notification delivery.
- FIG. 18 a illustrates a client-driven service discovery scenario in which a requesting node makes a service discovery request to a targeted service providing node.
- FIG. 18 b illustrates a peer registration service discovery scenario in which a requesting node seeks to register its description with a service providing node.
- FIG. 18 c illustrates an event-based service discovery scenario in which an interested node receives a notification of a change in service availability (e.g., the existence of a service within a service-providing node).
- a change in service availability e.g., the existence of a service within a service-providing node.
- FIG. 19 a illustrates the process of establishing trust using a service binding with an implicitly trusted channel.
- FIG. 19 b illustrates the process of establishing trust based on a request/response model.
- FIG. 19 c illustrates the process of establishing trust based on an explicit exchange of security credentials.
- FIG. 20 illustrates policy-managed access to a service.
- FIG. 21 illustrates a sample DRM node graph with membership and key access links.
- FIG. 22 illustrates an embodiment of the format of a DRM VM code module.
- FIG. 23 illustrates a system function profile hierarchy
- FIG. 24 illustrates DRM music player application scenarios.
- inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents.
- inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents.
- inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents.
- inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents.
- inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents.
- inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents.
- inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents.
- inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents.
- inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents.
- the Web Services Architecture is a specific instance of a Service Oriented Architecture (SOA).
- SOA Service Oriented Architecture
- An SOA is itself a type of distributed system consisting of loosely coupled, cooperating software agents.
- the agents in an SOA may provide a service, request (consume) a service, or do both.
- a service can be seen as a well-defined, self-contained set of operations managed by an agent acting in a service provider role. The operations are invoked over the network at some network-addressable location, called an endpoint, using standard protocols and data formats.
- self-contained it is meant that the service does not depend directly on the state or context of another service or encompassing application.
- WSA is attractive because it is not tied to a specific platform, programming language, application protocol stack, or data format convention. WSA uses standard formats based on XML for describing services and exchanging messages which promotes loose coupling and interoperability between providers and consumers, and supports multiple standard Internet protocols (notably HTTP), which facilitates deployment and participation in a potentially globally distributed system.
- the service bus approach provides for orchestration of services by leveraging description, messaging, and transport standards.
- the infrastructure may also incorporate standards for discovery, transformation, security, and perhaps others as well.
- the fundamental unit of work (the service) is called a web service.
- a particular web service can be described as an abstract interface for a logically coherent set of operations that provides a basis for a (possibly transient) relationship between a service provider and a service requester.
- provider concrete implementation
- service as distinguished from web service
- the software that actually implements the functionality for the service provider is the provider agent and for the service requester, the requester agent.
- the person or organization that owns the agent is referred to as the provider entity or requester entity, as appropriate.
- requester or provider may refer to either the respective entity or agent depending on context.
- a web service exists to fulfill a purpose, and how this is achieved is specified by the mechanics and semantics of the particular web service message exchange.
- the mechanics refers to the precise machine-processable technical specifications that allow the message exchange to occur over a network. While the mechanics are precisely defined, the semantics might not be.
- the semantics refers to the explicit or implicit “contract,” in whatever form it exists, governing the understanding and overall expectations between the requester and provider entities for the web service.
- Web services are often modeled in terms of the interactions of three roles: (i) Service Provider; (ii) Service Requester; and (iii) Service Registry.
- a service provider “publishes” the information describing its web service to a service registry.
- a service requester “finds” this information via some discovery mechanism, and then uses this information to “bind” to the service provider to utilize the service. Binding simply means that the requester will invoke the operations made available by the provider using the message formatting, data mapping, and transport protocol conventions specified by the provider in the published service description.
- the XML-based language used to describe this information is called Web Services Description Language (WSDL).
- a service provider offers access to some set of operations for a particular purpose described by a WSDL service description; this service description is published to a registry by any of a number of means so that the service may be discovered.
- a registry may be public or private within a specific domain.
- a service registry is software that responds to service search requests by returning a previously published service description.
- a service requester is software that invokes various operations offered by a provider according to the binding information specified in the WSDL obtained from a registry.
- the service registry may exist only conceptually or may in fact exist as real software providing a database of service descriptions used to query, locate, and bind to a particular service. But whether a requester actually conducts an active search for a service or whether a service description is statically or dynamically provided, the registry is a logically distinct aspect of the web services model. It is interesting to note that in a real world implementation, a service registry may be a part of the service requester platform, the service provider platform, or may reside at another location entirely identified by some well-known address or an address supplied by some other means.
- the WSDL service description supports loose coupling, often a central theme behind an SOA. While ultimately a service requester will understand the semantics of the interface of the service it is consuming for the purpose of achieving some desired result, the service description isolates a service interface from specific service binding information and supports a highly dynamic web services model.
- a service-oriented architecture can be built on top of many possible technology layers.
- web services typically incorporate or involve aspects of the following technologies:
- HTTP a standard application protocol for most web services communications. Although web services can be deployed over various network protocols (e.g., SMTP, FTP, etc), HTTP is the most ubiquitous, firewall-friendly transport in use. For certain applications, especially within an intranet, other network protocols may make sense depending on requirements; nevertheless, HTTP is a part of almost any web services platform built today.
- XML a standard for formatting and accessing the content (and information about the content) of structured information.
- XML is a text-based standard for communicating information between web services agents. Note that the use of XML does not mean that message payloads for web services may not contain any binary data; but it does mean that this data will be formatted according to XML conventions. Most web services architectures do not necessarily dictate that messages and data be serialized to a character stream—they may just as likely be serialized to a binary stream where that makes sense—but if XML is being used, these streams will represent XML documents. That is, above the level of the transport mechanism, web service messaging will often be conducted using XML documents.
- XML-Namespaces are used to resolve naming conflicts and assert specific meanings to elements contained with XML documents.
- XML-Schema are used to define and constrain various information items contained within an XML document. Although it is possible (and optional) to accomplish these objectives by other means, the use of XML is probably the most common technique used today.
- the XML document format descriptions for web service documents themselves are defined using XML-Schema, and most real world web services operations and messages themselves will be further defined incorporating XML-Schema.
- SOAP an XML-based standard for encapsulating instructions and information into a specially formatted package for transmission to and handling by other receivers.
- SOAP Simple Object Access Protocol
- SOAP Simple Object Access Protocol
- SOAP defines a relatively lightweight convention for structuring messages and providing information about content.
- Each SOAP document contains an envelope that is divided into a header and a body.
- the header is generally used for meta-information or instructions for receivers related to the handling of the content contained in the body.
- a Message Exchange Pattern is a feature that defines a pattern for how messages are exchanged between nodes.
- a common MEP is request-response, which establishes a single, complete message transaction between a requesting and a responding node (see http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapsupmep.).
- WSDL an XML-based standard for describing how to use a web service.
- a service is related to a set of messages exchanged between service requesters and providers. Messages are described in an abstract manner that can be mapped to specific protocols. The exchange of messages that invokes some functionality is called an operation.
- a specific set of operations defines an interface.
- An interface is tied to a concrete message format and protocol by a named binding. The binding (the mapping of an interface to a concrete protocol) is associated with a URI appropriate to the protocol, resulting in an endpoint.
- a collection of one or more related endpoints (mapping an interface to concrete protocols at specific URIs) comprises a service.
- Types container element for type definitions Message an abstract definition of the type of data being sent Operation an abstract description of an action based on a combination of input, output, and fault messages
- portType an abstract set of operations - an interface binding specification of a concrete protocol and data format for an interface (portType) port the combination of a binding and an actual network address - an endpoint service a collection of related ports (endpoints)
- WSDL defines a common binding mechanism and then defines specific binding extensions for SOAP, HTTP GET/POST, and MIME.
- binding does not necessarily mean binding to a transport protocol directly, but to a specific wire format.
- the most common binding for web services is SOAP, although actual SOAP message exchanges generally occur over HTTP on port 80 (via an http://URI).
- an interface can be directly bound to HTTP; alternatively, for example, a binding for SOAP can use SMTP (via a mailto://URI).
- An implementation can even define its own wire format and use a custom binding extension.
- WSDL encourages maintainability and reusability by providing support for an ⁇ import> element.
- a WSDL document can be divided into separate pieces in ways that make sense to an organization.
- the following separation into three documents is reasonable:
- a service interface description containing what is considered the reusable portion ⁇ message> ⁇ portType> ⁇ binding> A service implementation definition containing the specific service end point ⁇ service>
- WSDL interfaces are not exactly like Java (or IDL, or some other programming language) interfaces.
- a Java interface declaration specifies a set of methods that must match at least a subset of the methods of a class claiming to implement that interface. More than one class can implement an interface, and each implementation can be different; but the method signatures (method name and any input or output types) generally must be identical. This is mandated by the language and enforced at compile time, runtime, or both.
- a WSDL interface is different, and more like an actual abstract class that alone is not fully useful.
- Various WSDL interfaces, or portTypes, of a single web service are logically related in the sense that the set of operation names should be identical as if the portType did, in fact, implement a specific contract defined somewhere else but no such element actually exists and there is no mechanism for enforcing portType symmetry.
- Each portType is generally named to identify the type of binding it supports even though a portType alone does not create a binding.
- the portType operations for related portTypes are named the same, but the input, output, and fault messages (if present) are mapped to specific messages that contain named parts also necessary for supporting a specific binding. This raises the point that messages themselves are not completely abstract.
- a web service may and often does need to define similar but distinct messages for the various bindings required.
- a system architecture can be developed that facilitates the creation of networked interoperable media-related services that utilize a variety of different protocols and interfaces across a wide range of hardware and software platforms and operating environments.
- Preferred embodiments of the present invention seek to enable, promote, and/or actively support a peer-to-peer environment in which peers can spontaneously offer a variety of functionality by exposing services.
- One embodiment of the framework discourages viewing peers as having a fixed set of capabilities; and instead encourages a model where a peer at any point in time is a participant in one or more roles.
- a role can be defined by a set of services that a given peer exposes in combination with a specific behavior pattern.
- a NEMO-enabled node may act in multiple roles based on a variety of factors: its actual implementation footprint providing the functionality for supporting a given set of services, administrative configuration, information declaring the service(s) the peer is capable of exposing, and load and runtime policy on service interfaces.
- An explicit set of roles could be defined based on various different types of services. Over time, as common patterns of participation are determined and as new services are introduced, a more formal role categorization scheme could be defined.
- a preliminary set of roles that may be formalized over time could include the following:
- Client a relatively simple role in which no services are exposed, and the peer simply uses services of other peers.
- Authorizer this role denotes a peer acting as a Policy Decision Point (PDP), determining if a requesting principal has access to a specified resource with a given set of pre-conditions and post-conditions.
- Gateway in certain situations a peer may not be able to directly discover or interact with other service providers, for reasons including: transport protocol incompatibility, inability to negotiate a trusted context, or lack of the processing capability to create and process the necessary messages associated with a given service.
- a gateway is a peer acting as a bridge to another peer in order to allow the peer to interact with a service provider.
- the requesting peer may actually delegate to the gateway peer its identity and allow that peer to negotiate and make decisions on its behalf.
- the gateway peer may act as a simple relay point, forwarding or routing requests and responses.
- Orchestrator in situations where interaction with a set of service providers involves nontrivial coordination of services (possibly including transactions, distributed state management, etc.), it may be beyond a peer's capability to participate.
- An orchestrator is a specialization of the gateway role.
- a peer may request an orchestrator to act on its behalf, intervening to provide one or more services.
- the orchestrating peer may use certain additional NEMO components, such as an appropriately configured Workflow Collator in order to satisfy the orchestration requirements.
- this model there are four tiers of service components: 1) Content Authoring, Assembly, and Packaging services, 2) Web-based Content Aggregation and Distribution services, 3) Home Gateway services, and 4) Consumer Electronics devices.
- Each of these four tiers typically has different requirements for security, rights management, service discovery, service orchestration, user interface complexity, and other service attributes.
- the first two tiers fit very roughly into the models that we see for “traditional” web services, while the last two tiers fit more into what we might call a personal logical network model, with certain services of the home gateway being at the nexus between the two types of models.
- services for CE devices could occasionally appear in any of the tiers.
- rights management and content governance for the home gateway and CE device tiers may entail a different trust model that emphasizes fair use rights that are relatively straightforward from the consumer's point of view.
- Peer devices in a personal logical network may want to interact using the relatively simple trust model of that network, and with the ability to interact with peers across a wide area network using a global trust model, perhaps through proxy gateway services.
- an effective approach to rights management while enabling end-to-end distribution, might also be heterogeneous, supporting a variety of rights management services, including services that interpret expressions of distribution rights and translate them, in context, to individual consumer use rights in a transaction that is orchestrated with a sales transaction, or perhaps another event where a subscription right is exercised.
- the system framework consists of a logically connected set of nodes that interact in a peer-to-peer (P2P) fashion.
- Peer-to-peer computing is often defined as the sharing of resources (such as hard drives and processing cycles) among computers and other intelligent devices. See http://www.intel.com/cure/peer.htm.
- P2P may be viewed as a communication model allowing network nodes to symmetrically consume and provide services of all sorts.
- P2P messaging and workflow collation allow rich services to be dynamically created from a heterogeneous set of more primitive services. This enables examination of the possibilities of P2P computing when the shared resources are services of many different types, even using different service bindings.
- Different embodiments can provide a media services framework enabling stakeholders (e.g., consumers, content providers, device manufacturers, and service providers) to find one another, to interact, exchange value, and to cooperate in rich and dynamic ways.
- stakeholders e.g., consumers, content providers, device manufacturers, and service providers
- These different types of services range from the basic (discovery, notification, search, and file sharing) to more complex higher level services (such as lockers, licensing, matching, authorization, payment transaction, and update), and combinations of any or all of these.
- Services can be distributed across peer-to-peer communicating nodes, each providing message routing and orchestration using a message pump and workflow collator (described in greater detail below) designed for this framework.
- Nodes interact by making service invocation requests and receiving responses.
- the format and payload of the request and response messages are preferably defined in a standard XML schema-based web service description language (e.g., WSDL) that embodies an extensible set of data types enabling the description and composition of services and their associated interface bindings.
- WSDL standard XML schema-based web service description language
- Many of the object types in WSDL are polymorphic and can be extended to support new functionality.
- the system framework supports the construction of diverse communication patterns, ranging from direct interaction with a single service provider to a complex aggregation of a choreographed set of services from multiple service providers.
- the framework supports the basic mechanisms for using existing service choreography standards (WSCI, BPEL, etc.), and also allows service providers to use their own conventions.
- the syntax of messages associated with service invocation are preferably described in a relatively flexible and portable manner, as are the core data types used within the system framework. In one embodiment, this is accomplished using WSDL to provide relatively simple ways for referencing semantic descriptions associated with described services.
- a service interface may have one or more service bindings.
- a node may invoke the interface of another node as long as that node's interface binding can be expressed in, e.g., WSDL, and as long as the requesting node can support the conventions and protocols associated with the binding. For example, if a node supports a web service interface, a requesting node may be required to support SOAP, HTTP, WS-Security, etc.
- Any service interface may be controlled (e.g., rights managed) in a standardized fashion directly providing aspects of rights management. Interactions between nodes can be viewed as governed operations.
- NEMO-enabled device typically includes some or all of the following logical modules (discussed in greater detail below):
- Native Services API the set of one or more services that the device implements. There is no requirement that a NEMO node expose any service directly or indirectly in the NEMO framework.
- Native Service Implementation the corresponding set of implementations for the native services API.
- Service Adaptation Layer the logical layer through which an exposed subset of an entity's native services is accessed using one or more discoverable bindings described in, e.g., WSDL.
- Framework Support Library components that provide support functionality for working with the NEMO Framework including support for invoking service interfaces, message processing, service orchestration, etc.
- a basic WSDL profile defines a minimum “core” set of data types and messages for supporting interaction patterns and infrastructural functionality. Users may either directly, in an ad-hoc manner, or through some form of standardization process, define other profiles built on top of this core, adding new data and service types and extending existing ones.
- this core profile includes definitions for some or all of the following major basic data types:
- Node a representation of a participant in the system framework.
- a node may act in multiple roles including that of a service consumer and/or a service provider.
- Nodes may be implemented in a variety of forms including consumer electronic devices, software agents such as media players, or virtual service providers such as content search engines, DRM license providers, or content lockers.
- Device encapsulates the representation of a virtual or physical device.
- User encapsulates the representation of a client user.
- Request encapsulates a request for a service to a set of targeted Nodes.
- Request Input encapsulates the input for a Request.
- Response encapsulates a Response associated with a Request.
- Request Result encapsulates the Results within a Response associated with some Request.
- Service Encapsulates the representation of a set of well-defined functionality exposed or offered by a provider Node. This could be, for example, low-level functionality offered within a device such as a cell phone (e.g. a voice recognition service), or multi-faceted functionality offered over the world-wide web (e.g. a shopping service). Services could cover a wide variety of applications, including DRM-related services such as client personalization and license acquisition.
- Service Provider an entity (e.g., a Node or Device) that exposes some set of Services. Potential Service Providers include consumer electronics devices, such as cell phones, PDAs, portable media players and home gateways, as well as network operators (such as cable head-ends), cellular network providers, web-based retailers and content license providers.
- Service Interface a well-defined way of interacting with one or more Services.
- Service Binding encapsulates a specific way to communicate with a Service, including the conventions and protocols used to invoke a Service Interface. These may be represented in a variety of well-defined ways, such as the WS-I standard XML protocol, RPC based on the WSDL definition, or a function invocation from a DLL.
- Service Access Point SAP—encapsulates the functionality necessary for allowing a Node to make a Service Invocation Request to a targeted set of Service Providing Nodes, and receive a set of Responses.
- WFC Workflow Collator
- DRM digital rights management
- a typical profile might include various DRM-related services (described below) for the following set of content protection and governance objects, which represent entities in the system, protect content, associate usage rules with the content, and determine if access can be granted when requested:
- Content Reference encapsulates the representation of a reference or pointer to a content item. Such a reference will typically leverage other standardized ways of describing content format, location, etc.
- DRM Reference encapsulates the representation of a reference or pointer to a description of a digital rights management format.
- Link links between entities (e.g., Nodes).
- Content represents media or other content.
- Content Key represents encryption keys used to encrypt Content.
- Control represents usage or other rules that govern interaction with Content.
- Controller represents associations between Control and ContentKey objects Projector—represent associations between Content and ContentKey objects
- a core profile includes definitions for some or all of the following basic Services:
- Authorization a request or response to authorize some participant to access a Service.
- governance The process of exercising authoritative or dominating influence over some item (e.g., a music file, a document, or a Service operation), such as the ability to download and install a software upgrade.
- governance typically interacts with Services providing functionality such as trust management, policy management, and content protection.
- Message Routing a Request or Response to provide message routing functionality, including the ability to have the Service Providing Node forward the message or collect and assemble messages.
- Node Registration a Request or Response to perform registration operations for a Node, thereby allowing the Node to be discovered through an Intermediate Node.
- Notification a Request or Response to send or deliver targeted Notification messages to a given set of Nodes.
- Security Credential Exchange a Request or Response related to allowing Nodes to exchange security related information, such as key pairs, certificates, or the like.
- Service Discovery (Query) a Request or Response related to the discovery of Services provided by some set of one or more Nodes.
- Service Orchestration The assembly and coordination of Services into manageable, coarser-grained Services, reusable components, or full applications that adhere to rules specified by a service provider. Examples include rules based on provider identity, type of Service, method by which Services are accessed, order in which Services are composed, etc.
- Trust Management provides a common set of conventions and protocols for creating authorized and trusted contexts for interactions between Nodes.
- NEMO Trust Management may leverage and/or extend existing security specifications and mechanisms, including WS-Security and WS-Policy in the web services domain.
- Upgrade represents a Request or Response related to receiving a functionality upgrade. In one embodiment, this service is purely abstract, with other profiles providing concrete representations.
- the basic logical interaction between two system nodes, a service requester and a service provider typically includes the following sequence of events. From the perspective of the service requesting node:
- the service requesting node makes a service discovery request to locate any NEMO-enabled nodes that can provide the necessary service using the specified service bindings.
- a node may choose to cache information about discovered services.
- the interface/mechanism for service discovery between nodes can be just another service that a NEMO node chooses to implement.
- the requesting node may choose to dispatch a request to one or more of the service providing nodes based on a specific service binding.
- two nodes that wish to communicate securely with each other will establish a trusted relationship for the purpose of exchanging WSDL messages. For example, they may negotiate a set of compatible trust credentials (e.g., X.500 certificates, device keys, etc.) that may be used in determining identity, verifying authorization, establishing a secure channel, etc.
- the negotiation of these credentials may be an implicit property of the service interface binding (e.g., WS-Security if WS-I XML Protocol is used, or an SSL request between two well-known nodes).
- the negotiation of trust credentials may be an explicitly separate step. In one embodiment, it is up to a given node to determine which credentials are sufficient for interacting with another node, and to make the decision that it can trust a given node.
- the requesting node creates the appropriate WSDL request message(s) that correspond to the requested service.
- the communication style of the request may, for example, be synchronous or asynchronous RPC style, or message-oriented based on the service binding. Dispatching of service requests and receiving of responses may be done directly by the device or through the NEMO Service Proxy.
- the service proxy (described below) provides an abstraction and interface for sending messages to other participants, and may hide certain service binding issues, such as compatible message formats, transport mechanisms, message routing issues, etc.
- the requesting node After dispatching a request, the requesting node will typically receive one or more responses. Depending on the specifics of the service interface binding and the requesting node's preferences, the response(s) may be returned in a variety of ways, including, for example, an RPC-style response or a notification message.
- the response, en-route to the targeted node(s), may pass through other intermediate nodes that may provide a number of relevant services, including, e.g., routing, trust negotiation, collation and correlation functions, etc.
- the requesting node validates the response(s) to ensure it adheres to the negotiated trust semantics between it and the service providing node.
- sequence of events typically would include the following:
- the NEMO framework does not mandate the style or granularity of how a service interface maps as an entry point to a service.
- a service interface may map unambiguously to a given service and the act of binding to and invoking it may constitute support for the service.
- a single service interface may handle multiple types of requests; and a given service type may contain additional attributes that need to be examined before a determination can be made that the node supports the specifically desired functionality.
- the service provider may be necessary for the service provider to determine if it trusts the requesting node and to negotiate a set of compatible trust credentials. In one embodiment, regardless of whether the service provider determines trust, any policy associated with the service interface will still apply.
- the service provider determines and dispatches authorization request(s) to those node(s) responsible for authorizing access to the interface in order to determine if the requesting node has access.
- the authorizing node and the service providing node will be the same entity, and the dispatching and processing of the authorization request will be local operations invoked through a lightweight service interface binding such as a C function entry point.
- the service provider Upon receiving the authorization response, if the requesting node is authorized, the service provider will fulfill the request. If not, an appropriate response message might be generated.
- the response message is returned based on the service interface binding and requesting node's preferences.
- the message may pass through other intermediate nodes that may provide necessary or “value added” services.
- an intermediate node might provide routing, trust negotiation, or delivery to a notification processing node that can deliver the message in a way acceptable' to the requesting node.
- An example of a “value added” service is a coupon service that appends coupons to the message if it knows of the requesting node's interests.
- NEMO nodes may interact by making service invocation requests and receiving responses.
- the NEMO framework supports the construction of diverse and rich communication patterns ranging from a simple point to point interaction with a single service provider to a complex aggregation of a choreographed set of services from multiple service providers.
- the NEMO nodes interact with one another to provide a variety of services that, in the aggregate, implement a music licensing system.
- Music stored in Consumer Music Locker 110 can be extracted by Web Music Retailer 120 and provided to end users at their homes via their Entertainment Home Gateway 130 .
- Music from Consumer Music Locker 110 may include rules that govern the conditions under which such music may be provided to Web Music Retailer 120 , and subsequently to others for further use and distribution.
- Entertainment Home Gateway 130 is the vehicle by which such music (as well as video and other content) can be played, for example, on a user's home PC (e.g., via PC Software Video Player 140 ) or on a user's portable playback device (e.g., Portable Music Player 150 ).
- a user might travel, for example, with Portable Music Player 150 and obtain, via a wireless Internet connection (e.g., to Digital Rights License Service 160 ), a license to purchase additional songs or replay existing songs additional times, or even add new features to Portable Music Player 150 via Software Upgrade Service 170 .
- a wireless Internet connection e.g., to Digital Rights License Service 160
- a license to purchase additional songs or replay existing songs additional times or even add new features to Portable Music Player 150 via Software Upgrade Service 170 .
- NEMO nodes can interact with one another, and with other devices, in a variety of different ways.
- a NEMO host as illustrated in FIG. 2 a , is some type of machine or device hosting at least one NEMO node.
- a host may reside within a personal area network 210 or at a remote location 220 accessible via the Internet.
- a host could, for example, be a server 230 , a desktop PC 240 , a laptop 250 , or a personal digital assistant 260 .
- a NEMO node is a software agent that can provide services to other nodes (such as host 235 providing a 3 rd party web service) as well as invoke other nodes' services within the NEMO-managed framework.
- Some nodes 270 are tethered to another host via a dedicated communication channel, such as Bluetooth.
- These hosts 240 and 250 are equipped with network connectivity and sufficient processing power to present a virtual node to other participating NEMO nodes.
- a NEMO node can be a full peer within the local or personal area network 210 .
- Nodes share the symmetric capability of exposing and invoking services; however, each node generally does not offer identical sets of services.
- Nodes may advertise and/or be specifically queried about the services they perform.
- local NEMO nodes e.g., within personal area network 210
- remote nodes 220 can also access the services of remote nodes 220 .
- local and remote nodes e.g., Internet-capable NEMO hosts 280
- not all NEMO nodes may be on hosts capable of communicating with other hosts, whether local or remote.
- a NEMO host 280 can provide a gateway service through which one node can invoke the services of another, such as tethered node 285 or nodes in personal area network 210 .
- a node 295 on a tethered device may access the services of other nodes via a gateway, as discussed above. It may also be accessed by other nodes via a proxy service on another host 290 .
- the proxy service creates a virtual node running on the NEMO host. These proxy nodes can be full NEMO peers.
- a NEMO host may provide dedicated support for tethered devices via NEMO node adapters.
- a private communication channel 296 is used between host/NEMO device adapter 297 and tethered node 298 using any suitable protocol. Tethered node 298 does not see, nor is it visible to, other NEMO peer nodes.
- DRM digital rights management
- NEMO services and the exemplary DRM engine described herein can be used in combination to achieve interoperability that allows devices based on the NEMO framework to provide consumers with the perception of a seamless rendering and usage experience, even in the face of a heterogeneous DRM and media format infrastructure.
- a network of NEMO-enabled DRM devices may include content provider/server 310 , which packages content for other DRM devices, as well as consumer PC player 330 and consumer PC packager/player 320 , which can not only play protected content, but can also package content for delivery to portable device 340 .
- the DRM engine performs specific DRM functions (e.g., enforcing license terms, delivering keys to the host application, etc.), and relies on the host application for those services which can be most effectively provided by the host, such as encryption, decryption, and file management.
- specific DRM functions e.g., enforcing license terms, delivering keys to the host application, etc.
- the DRM engine includes a virtual machine (VM) designed to determine whether certain actions on protected content are permissible.
- VM virtual machine
- This Control VM can be implemented as a simple stack-based machine with a minimal set of instructions. In one embodiment, it is capable of performing logical and arithmetic calculations, as well as querying state information from the host environment to check parameters such as system time, counter state, and so forth.
- the DRM engine utilizes a graph-based algorithm to verify relationships between entities in a DRM value chain.
- FIG. 4 illustrates a conceptual embodiment of such a graph.
- the graph comprises a collection of nodes or vertices, connected by links.
- Each entity in the system can be represented by a vertex object. Only entities that need to be referenced by link objects, or be the recipient of cryptographically targeted information, need to have corresponding vertex objects.
- a vertex typically represents a user, a device, or a group. Vertex objects also have associated attributes that represent certain properties of the entity associated with the vertex.
- FIG. 4 shows two users (Xan and Knox), two devices (the Mac and a portable device), and several entities representing groups (members of the Carey family, members of the public library, subscribers to a particular music service, RIAA-approved devices, and devices manufactured by a specific company). Each of these has a vertex object associated with it.
- the semantics of the links may vary in an application-specific manner.
- the directed edge from the Mac vertex to the Knox vertex may mean that Knox is the owner of the Mac.
- the edge from Knox to Public Library may indicate that Knox is a member of the Public Library.
- the DRM engine does not impose or interpret these semantics—it simply ascertains the existence or non-existence of paths within the graph.
- This graph of vertices can be considered an “authorization” graph in that the existence of a path or relationship (direct or indirect) between two vertices may be interpreted as an authorization for one vertex to access another vertex.
- the Music Service vertex is considered reachable from another vertex when there is a path from that vertex to the Music Service. This allows a control to be written that allows permission to access protected content based on the condition that the Music Service be reachable from the portable device in which the application that requests access (e.g., a DRM client host application) is executing.
- the application that requests access e.g., a DRM client host application
- a content owner may create a control program to be interpreted by the Control VM that allows a particular piece of music to be played if the consuming device is owned by a member of the Public Library and is RIAA-approved.
- the Control VM running on the device evaluates this control program, the DRM engine determines whether links exist between Portable Device and Public Library, and between Portable Device and RIAA Approved.
- the edges and vertices of the graph may be static and built into devices, or may be dynamic and discovered through services communicating with the host application.
- the DRM engine can enable great flexibility.
- the system can be adapted to many usage models, from traditional delegation-based policy systems to authorized domains and personal area networks.
- the DRM client can also reuse the authorization graph for content protection key derivation.
- System designers may chose to allow the existence of a link to also indicate the sharing of certain cryptographic information.
- the authorization graph can be used to derive content keys without explicit cryptographic retargeting to consuming devices.
- NEMO-enabled device any type of device (physical or virtual), including consumer electronics equipment, networked services, or software clients, can potentially be NEMO-enabled, which means that the device's functionality may be extended in such a way as to enable participation in the NEMO system.
- a NEMO-enabled device is conceptually comprised of certain standard modules, as illustrated in FIG. 5 a.
- Native Services API 510 represents the logical set of one or more services that the device implements. There is no requirement that a NEMO node expose any service directly or indirectly.
- Native Service Implementation 520 represents the corresponding set of implementations for the native services API.
- Service Access Point 530 provides support for invoking exposed service interfaces. It encapsulates the functionality necessary for allowing a NEMO node to make a service invocation request to a targeted set of service-providing NEMO nodes and to receive a set of responses. NEMO-enabled nodes may use diverse discovery, name resolution, and transport protocols, necessitating the creation of a flexible and extensible communication API.
- the Service Access Point can be realized in a variety of ways tailored to a particular execution environment and application framework style. One common generic model for its interface will be an interface capable of receiving XML messages in some form and returning XML messages. Other models with more native interfaces can also be supported.
- NEMO Service Adaptation Layer 540 represents an optional layer through which an exposed subset of an entity's native services are accessed using one or more discoverable bindings. It provides a level of abstraction above the native services API, enabling a service provider to more easily support multiple types of service interface bindings. In situations where a service adaptation layer is not present, it may still be possible to interact with the service directly through the Service Access Point 530 if it supports the necessary communication protocols.
- the Service Adaptation Layer 540 provides a common way for service providers to expose services, process requests and responses, and orchestrate services in the NEMO framework. It is the logical point at which services are published, and provides a foundation on which to implement other specific service interface bindings.
- Service Adaptation Layer 540 In addition to providing a common way of exposing a service provider's native services to other NEMO-enabled nodes, Service Adaptation Layer 540 also provides a natural place on which to layer components for supporting additional service interface bindings 560 , as illustrated in FIG. 5 b . By supporting additional service interface bindings, a service provider increases the likelihood that a compatible binding will be able to be negotiated and used either by a Service Access Point or through some other native API.
- Workflow Collator 550 provides supporting management of service messages and service orchestration. It provides a common interface allowing a node to manage and process collections of request and response messages. This interface in turn provides the basic building blocks to orchestrate services through management of the messages associated with those services. This interface typically is implemented by a node that supports message routing functionality as well as the intermediate queuing and collating of messages.
- the NEMO framework includes a collection of optional support services that facilitate an entity's participation in the network.
- Such services can be classified according to various types of functionality, as well as the types of entities requiring such services (e.g., services supporting client applications, as opposed to those needed by service providers).
- Typical supporting services include the following:
- WSDL Formatting and Manipulation Routines provide functionality for the creation and manipulation of WSDL-based service messages.
- Service Cache provides a common interface allowing a node to manage a collection of mappings between discovered nodes and the services they support.
- Notification Processor Interface provides a common service provider interface for extending a NEMO node that supports notification processing to some well-defined notification processing engine.
- Miscellaneous Support Functionality including routines for generating message IDs, timestamps, etc.
- Asynchronous RPC Delivery Style this model is particularly appropriate if there is an expectation that fulfilling the request will take an extended period of time and the client does not want to wait.
- the client submits a request with the expectation that it will be processed in an asynchronous manner by any service-providing nodes.
- the service-providing endpoint may respond indicating that it does not support this model, or, if the service-providing node does support this model, it will return a response that will carry a ticket that can be submitted to the given service-providing node in subsequent requests to determine if it has a response to the client's request.
- any service-providing endpoint that does support this model is obligated to cache responses to pending client requests based on an internal policy. If a client attempts to redeem a ticket associated with such a request and no response is available, or the response has been thrown away by the service-providing node, then an appropriate error response is returned. In this embodiment, it is up to the client to determine when it will make such follow-on requests in attempting to redeem the ticket for responses.
- Synchronous RPC Delivery Style the client submits a request and then waits for one or more responses to be returned.
- a service-providing NEMO-enabled endpoint may respond indicating that it does not support this model.
- the client submits a request indicating that it wants to receive any responses via a message notification associated with one or more of its notification handling service interfaces.
- a service-providing NEMO-enabled endpoint may respond indicating that it does not support this model.
- a Service Access Point can be used as a common, reusable API for service invocation. It can encapsulate the negotiation and use of a transport channel. For example, some transport channels may require SSL session setup over TCP/IP, while some channels may only support relatively unreliable communication over UDP/IP, and still others may not be IP-based at all.
- a SAP can encapsulate the discovery of an initial set of NEMO nodes for message routing.
- a cable set-top box may have a dedicated connection to the network and mandate that all messages flow through a specific route and intermediary.
- a portable media player in a home network may use UPnP discovery to find multiple nodes that are directly accessible. Clients may not be able, or may choose not, to converse directly with other NEMO nodes by exchanging XML messages.
- a version of the SAP may be used that exposes and uses whatever native interface is supported.
- the SAP pattern supports the following two common communication models (although combinations of the two, as well as others, may be supported): (i) Message Based (as discussed above)—where the SAP forms XML request messages and directly exchanges NEMO messages with the service provider via some interface binding; or (ii) Native—where the SAP may interact with the service provider through some native communication protocol.
- the SAP may internally translate to/from XML messages defined elsewhere within the framework.
- FIG. 6 a A sample interaction between two NEMO peer nodes is illustrated in FIG. 6 a .
- Client node 610 interacts with service-providing node 660 using NEMO service access point (SAP) 620 .
- SAP NEMO service access point
- Service-providing node 660 uses its web services layer 670 (using, e.g., WSDL and SOAP-based messaging) to expose its services to clients such as node 610 .
- Web services layer 630 of client node 610 creates and interprets SOAP messages, with help from mapping layer 640 (which maps SOAP messages to and from SAP interface 620 ) and trust management processing layer 650 (which could, for example, leverage WS-Security using credentials conveyed within SOAP headers).
- FIG. 6 b Another example interaction between NEMO nodes is illustrated in FIG. 6 b .
- Service-providing node 682 interacts with client node 684 using SAP 686 .
- service-providing node 682 includes a different but interoperable trust management layer than client 684 .
- service-providing node 682 includes both a trust engine 688 and an authorization engine 690 .
- trust engine 688 might be generally responsible for performing encryption and decryption of SOAP messages, for verifying digital certificates, and for performing other basic cryptographic operations
- authorization engine 690 might be responsible for making higher-level policy decisions.
- client node 684 includes a trust engine 692 , but not an authorization engine.
- client node 684 might be capable of performing basic cryptographic operations and enforcing relatively simple policies (e.g., policies related to the level of message authenticity, confidentiality, or the like), but might rely on service providing node 682 to evaluate and enforce higher order policies governing the client's use of, and interaction with, the services and/or content provided by service providing node 682 .
- FIG. 6 b is provided for purposes of illustration and not limitation, and that in other embodiments client node 684 might also include an authorization engine, as might be the case if the client needed to adhere to a set of obligations related to a specified policy.
- different NEMO peers can contain different parts of the trust management framework depending on their requirements.
- 6 b also illustrates that the communication link between nodes can be transport agnostic. Even in the context of a SOAP processing model, any suitable encoding of data and/or processing rules can be used. For example, the XML security model could be replaced with another security model that supported a different encoding scheme.
- a Service Access Point may be implemented in a variety of forms, such as within the boundaries of a client (in the form of a shared library) or outside the boundaries of the client (in the form of an agent running in a different process).
- the exact form of the Service Access Point implementation can be tailored to the needs of a specific type of platform or client. From a client's perspective, use of the Service Access Point may be optional, although in general it provides significant utility, as illustrated below.
- the Service Access Point may be implemented as a static component supporting only a fixed set of service protocol bindings, or it may be able to support new bindings dynamically.
- Interactions involving the Service Access Point can be characterized from at least two perspectives—a client-side which the requesting participant uses, and a service-side which interacts with other NEMO-enabled endpoints (nodes).
- Service Access Point 710 directly exchanges XML messages with client 720 .
- Client 720 forms request messages 740 directly and submits them to Service Access Point 710 , which generates and sends one or more response messages 750 to client 720 , where they are collected, parsed and processed.
- Client 720 may also submit (when making requests) explicit set(s) of service bindings 730 to use in targeting the delivery of the request.
- service bindings may have been obtained in a variety of ways. For example, client 720 can perform service-discovery operations and then select which service bindings are applicable, or it can use information obtained from previous responses.
- Service Access Point 760 directly supports a native protocol 770 of client 780 .
- Service Access Point 760 will translate messages internally between XML and that native protocol 770 , thereby enabling client 780 to participate within the NEMO system.
- native protocol 770 (or a combination of native protocol 770 and the execution environment) must provide any needed information in some form to Service Access Point 760 , which generates an appropriate request and, if necessary, determines a suitable target service binding.
- the interaction patterns can be tailored and may vary based on a variety of criteria, including the nature of the request, the underlying communication network, and the nature of the application and/or transport protocols associated with any targeted service bindings.
- FIG. 7 c A relatively simple type of service-side interaction pattern is illustrated in FIG. 7 c , in which Service Access Point 711 communicates directly with the desired service-providing node 712 in a point-to-point manner.
- Service Access Point 721 may initiate communication directly with (and may receive responses directly from) multiple potential service providers 725 .
- This type of interaction pattern may be implemented by relaying multiple service bindings from the client for use by Service Access Point 721 ; or a broadcast or multicast network could be utilized by Service Access Point 721 to relay messages. Based on preferences specified in the request, Service Access Point 721 may choose to collect and collate responses, or simply return the first acceptable response.
- Service Access Point 731 doesn't directly communicate with any targeted service-providing endpoints 735 . Instead, requests are routed through an intermediate node 733 which relays the request, receives any responses, and relays them back to Service Access Point 731 .
- Service Access Point 731 may want to take advantage of intermediate node 733 because it supports more robust collection and collating functionality, which in turn permits more flexible communication patterns between Service Access Point 731 and service providers such as endpoint nodes 735 .
- Service Access Point In addition to the above basic service-side interaction patterns, combinations of such patterns or new patterns can be implemented within the Service Access Point. Although the Service Access Point is intended to provide a common interface, its implementation will typically be strongly tied to the characteristics of the communication models and associated protocols employed by given NEMO-enabled endpoints.
- the Service Access Point can be used to encapsulate the logic for handling the marshalling and un-marshaling of I/O related data, such as serializing objects to appropriate representations, such as an XML representation (with a format expressed in WSDL), or one that envelopes XML-encoded objects in the proper format.
- appropriate representations such as an XML representation (with a format expressed in WSDL), or one that envelopes XML-encoded objects in the proper format.
- the SAP also encapsulates logic for communication via one or more supported application, session, and/or transport protocols, such as service invocation over HTTP using SOAP enveloping.
- the SAP may encapsulate logic for providing message integrity and confidentiality, such as support for establishing SSL/TLS sessions and/or signing/verifying data via standards such as XML-Signature and XML-Encryption.
- the SAP may encapsulate the logic for establishing an initial connection to a default/initial set of NEMO nodes where services can be discovered or resolved.
- the SAP can be initialized based on an optional set of environmental parameters.
- the API also accept a Boolean flag indicating whether or not the client should wait for a response. Normally, the flag will be true, except in the case of messages with no associated response, or messages to which responses will be delivered back asynchronously via another channel (such as via notification).
- the resulting message may also convey some resulting error condition.
- This API allows the client to set up any necessary hooks between itself and the SAP to allow the SAP to obtain keys associated with a particular type of trust management operation.
- the interface is based on callbacks supporting integrity protection through digital signing and verification, and confidentiality through encryption and decryption.
- each of the callbacks is of the form:
- KeyDesc is an optional object describing the key(s) required and a list of appropriate keys is returned. Signatures are validated as part of receiving response services messages when using the InvokeService( . . . ) API. If a message element fails verification, an XML message can be returned from InvokeService( . . . ) indicating this state and the elements that failed verification.
- the Service Adaptation Layer provides a common way for service providers to expose their services, process requests and generate responses for services, and orchestrate services in the NEMO framework. It also provides a foundation on which other specific service interface bindings can be implemented.
- WSDL is used to describe a service's interface within the system.
- Such a service description might, in addition to defining how to bind to a service on a particular interface, also include a list of one or more authorization service providers that will be responsible for authorizing access to the service, a pointer to a semantic description of the purpose and usage of the service, and a description of the necessary orchestration for composite services resulting from the choreographed execution of one or more other services.
- the Service Adaptation Layer also preferably encapsulates the concrete representations of the NEMO data types and objects specified in NEMO service profiles for platforms that are supported by a given participant. It also contains a mechanism for mapping service-related messages to the appropriate native service implementation.
- the NEMO framework does not mandate how the Service Adaptation Layer for a given platform or participant is realized.
- a service-providing node does not require translation of its native service protocols i.e., exposing its services only to client nodes that can communicate via that native protocol then that service-providing node need not contain a Service Adaptation Layer.
- Service Adaptation Layer will typically contain the following elements, as illustrated in FIG. 8 :
- Message Processing Logic a layer 820 that corresponds to the logic for message processing, typically containing a message pump 825 that drives the processing of messages, some type of XML data binding support 826 , and low level XML parser and data representation support 827 .
- Native Services a layer representing the native services available (onto which the corresponding service messages are mapped), including a native services API 830 and corresponding implementation 840.
- a Workflow Collator helps fulfill most nontrivial NEMO service requests by coordinating the flow of events of a request, managing any associated data including transient and intermediate results, and enforcing the rules associated with fulfillment. Examples of this type of functionality can be seen in the form of transaction coordinators ranging from simple transaction monitors in relational databases to more generalized monitors as seen in Microsoft MTS/COM+.
- the Workflow Collator is a programmable mechanism through which NEMO nodes orchestrate the processing and fulfillment of service invocations.
- the WFC can be tailored toward a specific NEMO node's characteristics and requirements, and can be designed to support a variety of functionality ranging from traditional message queues to more sophisticated distributed transaction coordinators.
- a relatively simple WFC might provide an interface for storage and retrieval of arbitrary service-related messages.
- a basic service interaction pattern begins with a service request arriving at some NEMO node via the node's Service Adaptation Layer.
- the message is handed off to the WSDL Message Pump that initially will drive and in turn be driven by the WFC to fulfill the request and return a response.
- the fulfillment of a service request might require multiple messages and responses and the participation of multiple nodes in a coordinated fashion.
- the rules for processing requests may be expressed in the system's service description language or using other service orchestration description standards such as BPEL.
- the WFC determines the correct rules for processing this request.
- the service description logic may be represented in the form of a fixed state machine for a set of services that the node exposes or it may be represented in ways that support the processing of a more free form expression of the service processing logic.
- the WFC architecture is modular and extensible, supporting plug-ins.
- the WFC may need to determine whether to use NEMO messages in the context of initiating a service fulfillment processing lifecycle, or as input in the chain of an ongoing transaction.
- NEMO messages include IDs and metadata that are used to make these types of determinations.
- NEMO messages also can be extended to include additional information that may be service transaction specific, facilitating the processing of messages.
- notification services are directly supported by various embodiments of the NEMO system.
- a notification represents a message targeted at interested NEMO-enabled nodes received on a designated service interface for processing.
- Notifications may carry a diverse set of payload types for conveying information and the criteria used to determine if a node is interested in a notification is extensible, including identity-based as well as event-based criteria.
- a service-providing NEMO node 910 provides a service that requires an orchestration process by its Workflow Collator 914 (e.g., the collection and processing of results from two other service providers) to fulfill a request for that service from client node 940 .
- Workflow Collator 914 e.g., the collection and processing of results from two other service providers
- Workflow Collator 914 When NEMO-enabled application 942 on client node 940 initiates a request to invoke the service provided by service provider 910 , Workflow Collator 914 in turn generates messages to initiate its own requests (on behalf of application 942 ), respectively, to Service Provider “Y” 922 on node 920 and Service Provider “Z” 932 on node 930 . Workflow Collator 914 then collates and processes the results from these two other service-providing nodes in order to fulfill the original request from client node 940 .
- a requested service might not require the services of multiple service-providing nodes; but might instead require multiple rounds or phases of communication between the service-providing node and the requesting client node.
- Workflow Collator 914 engages in multiple phases of communication 950 with client node 940 in order to fulfill the original request.
- Workflow Collator 914 may generate and send messages to client node 940 (via Access Point 944 ), receive and process the responses, and then generate additional messages (and receive additional responses) during subsequent phases of communication, ultimately fulfilling the original request from client node 940 .
- Workflow Collator 914 is used by service provider 910 to keep track (perhaps based on a service-specific session ID or transaction ID as part of the service request) of which phase of the operation it is in with the client for correct processing.
- a state machine or similar mechanism or technique could be employed to process these multiple phases of communication 950 .
- FIG. 9 c illustrates one embodiment of a relatively basic interaction, within service-providing node 960 , between Workflow Collator 914 and Message Pump 965 (within the node's Service Adaptation Layer, not shown).
- Workflow Collator 914 processes one or more service requests 962 and generates responses 964 , employing a storage and retrieval mechanism 966 to maintain the state of this orchestration process.
- Workflow Collator 914 is able to process multiple service requests and responses, which could be implemented with a fairly simple state machine.
- FIG. 9 d illustrates a node architecture that can both drive or be driven in performing service orchestration.
- Such functionality includes the collection of multiple service requests, aggregation of responses into a composite response, and either manual or automated orchestration of multiple service requests and responses in order to create a composite service.
- a variety of scenarios can be supported by the architecture surrounding Workflow Collator 914 in FIG. 9 d .
- an external coordinator 970 that understands the semantics of process orchestration (such as a Business Process Language engine driven by a high level description of the business processes associated with services) or resource usage semantics (such as a Resource Description Framework engine which can be driven by the semantic meaning of resources in relationship to each other), it is possible to create more powerful services on top of simpler ones.
- Custom External BPL 972 and/or RDF 973 processors may leverage external message pump 975 to execute process descriptions via a manual orchestration process 966 , i.e., one involving human intervention.
- the WFC can be initialized based on an optional set of environmental parameters.
- a more ad hoc XML-based orchestration description e.g., for a more dynamic application, such as a distributed search.
- FIG. 10 illustrates the integration of a modular embodiment of a DRM Engine 1000 into a NEMO content consumption device, thereby facilitating its integration into many different devices and software environments.
- Host application 1002 typically receives a request to access a particular piece of content through its user interface 1004 . Host application 1002 then sends the request, along with relevant DRM engine objects (preferably opaque to the host application), to DRM engine 1000 .
- DRM engine 1000 may make requests for additional information and cryptographic services to host services module 1008 through well-defined interfaces. For example, DRM engine 1000 may ask host services 1008 whether a particular link is trusted, or may ask that certain objects be decrypted. Some of the requisite information may be remote, in which case host services 1008 can request the information from networked services through a service access point 1014 .
- DRM engine 1000 Once DRM engine 1000 has determined that a particular operation is permitted, it indicates this and returns any required cryptographic keys to host services 1008 which, under the direction of host application 1002 , relies on content services 1016 to obtain the desired content and manage its use. Host services 1008 might then initiate the process of media rendering 1010 (e.g., playing the content through speakers, displaying the content on a screen, etc.), coordinated with cryptography services 1012 as needed.
- media rendering 1010 e.g., playing the content through speakers, displaying the content on a screen, etc.
- the system architecture illustrated in FIG. 10 is a relatively simple example of how the DRM engine can be used in applications, but it is only one of many possibilities.
- the DRM engine can be integrated into packaging applications under the governance of relatively sophisticated policy management systems.
- client (content consumption) and server (content packaging) applications of the DRM engine including descriptions of the different types of DRM-related objects relied upon by such applications, will be discussed below, following a description of one embodiment of the internal architecture of the DRM engine itself.
- DRM Engine 1100 relies on a virtual machine, control VM 1110 , for internal DRM processing (e.g., executing control programs that govern access to content) within a broad range of host platforms, utilizing host environment 1120 (described above, and in greater detail below) to interact with the node's host application 1130 and, ultimately, other nodes within, e.g., the NEMO or other system.
- control VM 1110 for internal DRM processing (e.g., executing control programs that govern access to content) within a broad range of host platforms, utilizing host environment 1120 (described above, and in greater detail below) to interact with the node's host application 1130 and, ultimately, other nodes within, e.g., the NEMO or other system.
- host environment 1120 described above, and in greater detail below
- control VM 1110 is a virtual machine used by an embodiment of DRM Engine 1100 to execute control programs that govern access to content. Following is a description of the integration of control VM 1110 into the architecture of DRM engine 1100 , as well as some of the basic elements of the control VM, including details about its instruction set, memory model, code modules, and interaction with host environment 1120 via system calls 1106 .
- control VM 1110 is a relatively small-footprint virtual machine that is designed to be easy to implement using various programming languages. It is based on a stack-oriented instruction set that is designed to be minimalist in nature, without much concern for execution speed or code density. However, it will be appreciated that, if execution speed and/or code density were issues in a given application, conventional techniques (e.g., data compression) could be used to improve performance.
- Control VM 1100 is suitable as a target for low or high level programming languages, and supports languages such as assembler, C, and FORTH. Compilers for other languages, such as Java or custom languages, could also be implemented with relative ease.
- Control VM 1110 is designed to be hosted within DRM Engine 1100 , including host environment 1120 , as opposed to being run directly on a processor or in silicon. Control VM 1110 runs programs by executing instructions stored in Code Modules 1102 . Some of these instructions can make calls to functions implemented outside of the program itself by making one or more System Calls 1106 , which are either implemented by Control VM 1110 itself, or delegated to Host Environment 1120 .
- Control VM 1110 executes instructions stored in code modules 1102 as a stream of byte code loaded in memory 1104 .
- Control VM 1110 maintains a virtual register called the program counter (PC) that is incremented as instructions are executed.
- PC program counter
- the VM executes each instruction, in sequence, until the OP_STOP instruction is encountered, an OP_RET instruction is encountered with an empty call stack, or an exception occurs.
- Jumps are specified either as a relative jump (specified as a byte offset from the current value of PC), or as an absolute address.
- control VM 1110 has a relatively simple memory model.
- VM memory 1104 is separated into a data segment (DS) and a code segment (CS).
- the data segment is a single, flat, contiguous memory space, starting at address 0.
- the data segment is typically an array of bytes allocated within the heap memory of host application 1130 or host environment 1120 .
- the size of the memory space is preferably fixed to a maximum; and attempts to access memory outside of that space will cause faults and terminate program execution.
- the data segment is potentially shared between several code modules 1102 concurrently loaded by the VM.
- the memory in the data segment can be accessed by memory-access instructions, which can be either 32-bit or 8-bit accesses. 32-bit memory accesses are accomplished using the big-endian byte order. No assumptions are made with regard to alignment between the VM-visible memory and the host-managed memory (host CPU virtual or physical memory).
- the code segment is a flat, contiguous memory space, starting at address 0.
- the code segment is typically an array of bytes allocated within the heap memory of host application 1130 or host environment 1120 .
- Control VM 1110 may load several code modules, and all of the code modules may share the same data segment (each module's data is preferably loaded at a different address), but each has its own code segment (e.g., it is preferably not possible for a jump instruction from one code module 1102 to cause a jump directly to code in another code module 1102 ).
- the VM has a notion of a data stack, which represents 32-bit data cells stored in the data segment.
- the VM maintains a virtual register called the stack pointer (SP). After reset, SP points to the end of the data segment, and the stack grows downward (when data is pushed onto the data stack, the SP registers are decremented).
- SP stack pointer
- the 32-bit values on the stack are interpreted either as 32-bit addressed, or 32-bit signed, integers, depending on the instruction referencing the stack data.
- control VM 1110 manages a call stack for making nested subroutine calls.
- the values pushed onto this stack cannot be read or written directly by the memory-access instructions, but are used indirectly by the VM when executing OP_JSR and OP_RET instructions.
- the size of this return address stack is preferably fixed to a maximum, which will allow a certain number of nested calls that cannot be exceeded.
- control VM 1110 uses a relatively simple instruction set. Even with a limited number of instructions; however, it is still possible to express simple programs.
- the instruction set is stack-based: except for the OP_PUSH instruction, none of the instructions have direct operands. Operands are read from the data stack, and results are pushed onto the data stack.
- the VM is a 32-bit VM: all the instructions in this illustrative embodiment operate on 32-bit stack operands, representing either memory addresses or signed integers. Signed integers are represented using a 2s complement binary encoding.
- code modules 1102 are stored in an atom-based format that is essentially equivalent to the atom structure used in the MPEG-4 file format.
- An atom consists of 32 bits, stored as 4-octets in big-endian byte order, followed by a 4-octet type (usually octets that correspond to ASCII values of letters of the alphabet), followed by the payload of the atom (size-8 octets).
- DRM client-side consuming applications consume DRM content (e.g., play a song, display a movie, etc.).
- DRM service-side packaging applications typically residing on a server) package content (e.g., associate with the content relevant usage and distribution rights, cryptographic keys, etc.) targeted to DRM clients.
- FIG. 12 a illustrates one embodiment of the main architectural elements of a DRM client.
- Host application 1200 interfaces with a device user (e.g., the owner of a music player) through user interface 1210 .
- the user might, for example, request access to protected content and receive metadata along with the content (e.g., text displaying the name of the artist and song title, along with the audio for the song itself).
- Host application 1200 in addition to interacting with user interface 1210 , also performs various functions necessary to implement the user's request, which may include managing interaction with the other DRM client modules to which it delegates certain functionality. For example, host application 1200 may manage interaction with the file system to extract the requested content. Host application also preferably recognizes the protected content object format and issues a request to the DRM engine 1220 to evaluate the DRM objects that make up the license (e.g., by running the relevant control program) to determine whether permission to access the protected content should be granted.
- Host Application 1200 might also need to verify required signatures and delegate to crypto services 1230 any other general purpose cryptographic functions required by DRM engine 1220 .
- DRM Engine 1220 is responsible for evaluating the DRM objects, confirming or denying permission, and providing the keys to host application 1200 to decrypt the content.
- Host services 1240 provides DRM Engine 1220 with access to data managed by (as well as certain library functions implemented by) host application 1200 .
- Host application 1200 interacts with content services 1250 to access the protected content, passing to DRM engine 1220 only that portion of the content requiring processing.
- Content services 1250 acquires the content from external media servers and stores and manages the content, relying on the client's persistent storage mechanisms.
- host application 1200 interacts with media rendering engine 1260 (e.g., by delivering keys) to decrypt and render the content via the client's AV output facilities.
- media rendering engine 1260 e.g., by delivering keys
- Some of the information needed by DRM Engine 1220 may be available in-band with the content, and can be acquired and managed via content services 1250 , while other information may need to be obtained through external NEMO DRM services or some other source.
- crypto services 1230 which interacts indirectly with DRM engine 1220 via host services 1240 , which forwards requests.
- Crypto services 1230 can also be used by media rendering engine 1260 to perform content decryption.
- FIG. 12 b illustrates an embodiment of the main architectural elements of an exemplary DRM service-side packaging node.
- Host application 1200 interfaces with a content packager (e.g., an owner or distributor of music content) through user interface 1210 .
- the packager might, for example, provide content and licensing information to host application 1200 so that the content can be protected (e.g., encrypted and associated with limited access rights) and distributed to various end user and intermediate content providing nodes.
- Host application 1200 in addition to interacting with user interface 1210 , can also perform various functions necessary to implement the packager's request, including, for example, managing interaction with the other DRM packaging modules to which it delegates certain functionality. For example, it may manage interaction with general crypto services 1235 to encrypt the content. It may also create a content object that contains or references the content and contains or references a license (e.g., after DRM packaging engine 1225 creates the DRM objects that make up the license). Metadata can be associated with the license that explains what the license is about in a human-readable way (e.g., for potential client users to view).
- host application 1200 interacts with the user via user interface 1210 . It is responsible for getting information such as a content reference and the action(s) the packager wants to perform (e.g., who to bind the content to). It can also display information about the packaging process such as the text of the license issued and, if a failure occurs, the reason for this failure. Some information needed by host application 1200 may require the use of NEMO Services 1270 (e.g., to leverage services such as authentication or authorization as well as membership).
- host application 1200 delegates to media format services 1255 responsibility for managing all media format operations, such as transcoding and packaging.
- General crypto services 1235 is responsible for issuing and verifying signatures, as well as encrypting and decrypting certain data. The request for such operations could be issued externally or from DRM packaging engine 1225 via host services 1240 .
- content crypto services 1237 is logically separated from general crypto services 1235 because it is unaware of host application 1200 . It is driven by media format services 1255 at content packaging time with a set of keys previously issued by DRM packaging engine 1225 (all of which is coordinated by host application 1200 ).
- a content provider uses a host application that relies on a DRM packager engine to create a set of objects that protect the content and govern its use, including conveying the information necessary for obtaining the content encryption keys.
- the term, license is used to encompass this set of objects.
- the content and its license are logically separate, but are bound together by internal references using object IDs.
- the content and license are usually stored together, but could be stored separately if necessary or desirable.
- a license can apply to more than one item of content, and more than one license can apply to any single item of content.
- FIG. 13 illustrates an embodiment of such a license, including the relationships among the set of objects discussed below.
- control object 1320 and controller object 1330 are both signed objects in this embodiment, so that the DRM client engine can verify that the control information comes from a trusted source prior to providing the host application with permission to access the protected content.
- all of these objects, with the exception of content object 1300 are created by the DRM client engine.
- Content object 1300 represents the encrypted content 1304 , using a unique ID 1302 to facilitate the binding between the content and its associated key.
- Content object 1300 is an “external” object.
- the format and storage of encrypted content 1304 (e.g., MP4 movie file, MP3 music track, etc.) is determined by the host application (or delegated to a service), based in part upon the type of content.
- the format of the content also provides support for associating ID 1302 with encrypted content 1304 .
- the packager's host application encrypts the content in a format-dependent manner, and manages content object 1300 , using any available cryptosystem (e.g., using a symmetric cipher, such as AES).
- ContentKey object 1310 represents the encrypted key data 1314 (including a unique encryption key(s), optionally stored internally within the object), and also has a corresponding unique ID 1312 .
- this key data if contained within ContentKey object 1310 , is itself encrypted so that it can only be identified by those authorized to decrypt the content.
- ContentKey object 1310 also specifies which cryptosystem was used to encrypt this key data. This cryptosystem, an embodiment of which is discussed in greater detail below, is referred to as the “key distribution system.”
- Control object 1320 includes and protects the control program (e.g., control byte code 1324 ) that represents the rules that govern the use of the keys used to encrypt and decrypt the content. It also includes ID 1322 so that it can be bound to the corresponding ContentKey object. As noted above, control object 1320 is signed so that the DRM client engine can verify the validity of the binding between the ContentKey 1310 and control 1320 , as well as the binding between the ContentKey ID 1312 and the encrypted key data 1314 . The validity of control byte code 1324 can optionally be derived by verifying a secure hash (e.g., control hash 1338 , if available) contained in controller object 1330 .
- a secure hash e.g., control hash 1338 , if available
- Controller object 1330 represents the binding between the keys and the rules governing their control, using IDs 1312 and 1322 , respectively, to bind the ContentKey 1310 and control 1320 objects. Controller object 1330 governs the use of protected content by controlling application of the rules to that content—i.e., by determining which control governs the use of which ContentKey object 1310 . Controller object 1330 also contains a hash 1336 value for each of the ContentKey objects 1310 that it references, in order to prevent tampering with the binding between each ContentKey object 1310 and its corresponding encrypted key data 1314 .
- controller objects 1330 are preferably signed (e.g., by a packager application that has a certificate allowing it to sign controller objects, using public key or symmetric key signatures, as discussed below) to enable verification of the validity of the binding between the ContentKey 1310 and control 1320 objects, as well as the binding between the ContentKey ID 1312 and the encrypted key data 1314 .
- controller object 1330 also optionally contains control hash 1338 , which allows the validity of control object 1320 to be derived without having to separately verify its signature.
- a symmetric key signature is the most common type of signature for controller objects 1330 .
- this type of signature is implemented by computing a MAC (Message Authentication Code) of the controller object 1330 , keyed with the same key as the key represented by the ContentKey object 1310 .
- MAC Message Authentication Code
- this type of signature is used when the identity of the signer of the controller object 1330 needs to be asserted uniquely.
- This type of signature is implemented with a public key signature algorithm, signing with the private key of the principal who is asserting the validity of this object.
- the ContentKey binding information carried in the controller object 1330 preferably contains a hash 1336 of the key contained in the ContentKey object 1310 , concatenated with a fingerprint of the signing private key (typically a hash of the private key). This binding ensures that the signer of the object has knowledge of the key used to protect the content.
- Protector object 1340 provides protected access to content by controlling the use of keys used to encrypt and decrypt that content.
- Protector object 1340 binds content object 1300 to ContentKey object 1310 in order to associate protected content with its corresponding key(s). To accomplish this binding, it includes references 1342 and 1344 , respectively, to the IDs 1302 and 1312 of content 1300 and ContentKey 1310 .
- protector object 1340 contains information not only as to which key was used to encrypt one or more content items, but also as to which encryption algorithm was employed.
- ContentKey reference 1344 may still reference only one ContentKey object 1310 , indicating that all of those content items were encrypted using the same encryption algorithm and the same key.
- FIG. 14 illustrates the DRM objects that represent entities in the system (e.g., users, devices or groups), as well as the relationships among those entities.
- FIG. 14 illustrates two types of objects that implement an embodiment of this conceptual graph: vertex (or “node”) objects ( 1400 a and 1400 b ), which represent entities and their attributes, and link objects ( 1420 ), which represent the relationships among node objects.
- vertex (or “node”) objects 1400 a and 1400 b
- link objects 1420
- the DRM engine by executing control programs, instigates one or more usage patterns involving these objects—e.g., encrypting a song and associating it with a license that restricts its distribution to particular individuals.
- the DRM engine in this embodiment does not specify, implicitly or explicitly, the semantics attached to these objects (e.g., to which individuals the song may be distributed).
- this semantic context is defined within the attributes of the node objects themselves.
- a DRM profile may include descriptions of these entities and the various roles and identities they represent, typically expressed using node attributes ( 1401 a and 1401 b ).
- a link 1420 between two nodes 1400 a and 1400 b could represent various types of semantic relationships. For example, if one node was a “user” and the other was a “device,” then link 1420 might represent “ownership.” If the other node was a “user group” instead of a “device,” then link 1420 might represent “membership.” Link 1420 might be unidirectional in one scenario and bidirectional in another (e.g., representing two links between the same two nodes).
- Node objects 1400 a and 1400 b also typically have object confidentiality protection asymmetric key pairs (e.g., private key 1405 a and public key 1406 a of node 1400 a , and private key 1405 b and public key 1406 b of node 1400 b ) to limit confidential information to authorized portions of the node. Confidential information targeted at a node will be encrypted with that node's confidentiality protection public key.
- a content protection asymmetric key pair (e.g., private key 1403 a and public key 1403 b of node 1400 a , and private key 1403 b and public key 1403 b of node 1400 b ) can be used in conjunction with link objects when the system uses a ContentKey derivation system for ContentKey distribution, as discussed in greater detail below.
- Content items themselves may be protected with content protection symmetric keys, such as symmetric key 1402 a of node 1400 a and key 1402 b of node 1400 b.
- link objects represent relationships between nodes.
- the semantics of these relationships can be stored in node attributes (e.g., 1401 a of node 1400 a and 1401 b of node 1400 b ), referenced from within the link objects (e.g., node reference 1422 to node 1400 a and node reference 1424 to node 1400 b ).
- Link objects can also optionally contain cryptographic data (e.g., key derivation info 1426 ) that enables the link object to be used for ContentKey derivations, as discussed below.
- the link object itself is a signed object, represented by a directed edge in a graph, such as in FIG. 4 above.
- a directed edge from one node (e.g., node X) to another (e.g., node Y)
- this “path” from node X to node Y indicates that node Y is “reachable” from node X.
- the existence of a path can be used by other DRM objects, e.g., as a condition of performing a particular function.
- a control object might check to determine whether a target node is reachable before it allows a certain action to be performed on its associated content object.
- a control that governs this content object might test whether a certain node U representing a certain user is reachable from node D (e.g., whether that user is the “owner” of that device), and only allow the “play” action to be performed if that condition is satisfied.
- the DRM engine can run a control program to determine whether there exists a set of link objects that can establish a path (e.g., a direct or indirect relationship) between node D and node U.
- the DRM engine is unaware of the semantics of the relationship; it simply determines the existence of a path, enabling the host application, for example, to interpret this path as a conditional authorization, permitting access to protected content.
- the DRM engine verifies link objects before allowing them to be used to determine the existence of paths in the system node graph.
- the validity of a link object at any given time may depend upon the particular features of the certificate system (discussed below) used to sign link objects. For example, they may have limited “lifetimes” or be revoked or revalidated from time to time based on various conditions.
- policies that govern which entities can sign link objects, which link objects can be created, and the lifetime of link objects are not directly handled by the DRM engine. Instead, they may leverage the node attributes information.
- the system may provide a way to extend standard certificate formats with additional constraint checking. These extensions make it possible to express validity constraints on certificates for keys that sign links, such that constraints (e.g., the type of nodes connected by the link, as well as other attributes), can be checked before a link is considered valid.
- the link object may contain cryptographic data that provides the user with the nodes' content protection keys for key distribution. That cryptographic data may, for example, contain, in addition to metadata, the private and/or symmetric content protection keys of the “from” node, encrypted with the content protection public key and/or the content protection symmetric key of the “to” node. For example, an entity that has been granted the ability to create link objects that link device nodes and user nodes under a certain policy may check to ensure that it only creates links between node objects that have attributes indicating they are indeed representing a device, and nodes that have attributes indicating that they represent a user.
- FIG. 15 An example embodiment of a DRM key distribution system is illustrated in FIG. 15 .
- the basic principle behind the key distribution system shown in FIG. 15 is to use link objects to distribute keys in addition to their primary purpose of establishing relationships between node objects.
- a control object may contain a control program that determines whether a requested operation should be permitted. That control program may check to determine whether a specific node is reachable via a collection of link objects.
- the key distribution system shown in FIG. 15 leverages that search through a collection of link objects to facilitate the distribution of a key such that it is available to the DRM engine that is executing the control program.
- each node object that uses the key distribution system has one or more keys. These keys are used to encrypt content keys and other nodes' key distribution keys.
- Link objects created for use in the same deployment contain some cryptographic data payload that allows key information do be derived when chains of links are processed by the DRM engine.
- nodes and links carrying keys this way, given a collection of links (e.g., from a node A to a node B . . . to a node Z), any entity that has access to the private keys of node A also has access to the private keys of node Z. Having access to node Z's private keys gives the entity access to any content key encrypted with those keys.
- Node objects that participate in a key distribution system contain keys as part of their data. As illustrated in FIG. 15 , in one embodiment each node ( 1500 a , 1500 b , and 1500 c ) has three keys:
- Public Key Kpub[N] This is the public part of a pair of public/private keys for the public key cipher. In one embodiment this key ( 1505 a , 1505 b and 1505 c , respectively, in nodes 1500 a , 1500 b and 1500 c ) comes with a certificate (discussed below) so that its credentials can be verified by entities that want to bind confidential information to it cryptographically.
- Private Key Kpriv[N] This is the private part of the public/private key pair. The entity that manages the node is responsible for ensuring that this private key (keys 1515 a , 1515 b and 1515 c , respectively, in nodes 1500 a , 1500 b and 1500 c ) is kept secret.
- this private key is stored and transported separately from the rest of the node information.
- Symmetric Key Ks[N] This key is used with a symmetric cipher (discussed below). Because this private key (keys 1525 a , 1525 b and 1525 c , respectively, in nodes 1500 a , 1500 b and 1500 c ) is confidential, the entity that manages the node is responsible for keeping it secret.
- the key distribution system illustrated in FIG. 15 can be implemented using different cryptographic algorithms, though the participating entities will generally need to agree on a set of supported algorithms.
- at least one public key cipher such as RSA
- one symmetric key cipher such as AES
- Ep(kpub[N], M) means “the message M encrypted with the public key Kpub of node N, using a public key cipher”
- Dp(Kpriv[N], M) means “the message M decrypted with the private key Kpriv of node N using a public key cipher”
- Es(Ks[N], M) means “the message M encrypted with the symmetric key Ks of node N using a symmetric key cipher”
- Ds(Ks[N], M) means “the message M decrypted with the symmetric key Ks of node N using a symmetric key cipher”
- Targeting a “ContentKey” to a node means making that key available to the entities that have access to the private keys of that node.
- binding is done by encrypting the key using one or both of the following methods:
- symmetric binding is preferably used whenever possible, as it uses a less computationally intensive algorithm that is less onerous on the receiving entity.
- the entity e.g., a content packager
- Kpub[N] should be available, as it is not confidential information.
- Kpub[N] will usually be made available to entities that need to target ContentKeys, accompanied by a certificate that can be inspected by the entity to decide whether Kpub[N] is indeed the key of a node that can be trusted to handle the ContentKey in accordance with some agreed-upon policy.
- link objects contain a “payload.” That payload allows any entity that has access to the private keys of the link's “from node” to also have access to the private keys of the link's “to node.” In this manner, an entity can decrypt any ContentKey targeted to a node that is reachable from its node.
- link 1530 a which links node 1500 a to node 1500 b , contains a payload that is created by encrypting the private keys 1515 b and 1525 b of node 1500 b with either the symmetric key 1515 a of node 1500 a or, if unavailable (e.g., due to its confidentiality), with the public key 1525 a of node 1500 a .
- link 1530 b which links node 1500 b to node 1500 c , contains a payload that is created by encrypting the private keys 1515 c and 1525 c of node 1500 c with either the symmetric key 1515 b of node 1500 b or, if unavailable, with the public key 1525 b of node 1500 b.
- a DRM engine When a DRM engine processes link objects, it processes the payload of each link to update an internal chain 1550 of keys to which it has access.
- the payload of a link from node A to node B consists of either:
- Kpriv[B ⁇ is a data structure containing Ks[B] and Kpriv[B].
- the public derivation information is used to convey the private keys of node B, Ks[B] and Kpriv[B], to any entity that has access to the private key of node A, Kpriv[A].
- the symmetric derivation information is used to convey the private keys of node B, Ks[B] and Kpriv[B], to any entity that has access to the symmetric key of node A, Kpriv[A].
- an entity that has access to the private keys of node 1500 a (private key 1515 a and symmetric key 1525 a ) enables the DRM engine to utilize these private keys 1560 as a “first link” in (and starting point in generating the rest of) key chain 1550 .
- Scuba keys 1560 are used to decrypt 1555 a the ContentKey object within link 1530 a (using private key 1515 a for public derivation if public binding via public key 1505 a was used, or symmetric key 1525 a for symmetric derivation if symmetric binding via symmetric key 1525 a was used), resulting in the next link 1570 in key chain 1550 i.e., the confidential keys of node 1500 b (private key 1515 b and symmetric key 1525 b ).
- the DRM engine uses these keys 1570 in turn to decrypt 1555 b the ContentKey object within link 1530 b (using private key 1515 b for public derivation if public binding via public key 1505 b was used, or symmetric key 1525 b for symmetric derivation if symmetric binding via symmetric key 1525 b was used), resulting in the final link 1580 in key chain 1550 i.e., the confidential keys of node 1500 c (private key 1515 c and symmetric key 1525 c ).
- the DRM engine can process links in any order, it may not be able to perform a key derivation at the time a link is processed (e.g., because the keys of the “from” node of that link have not yet been derived). In that case, the link is remembered, and processed again when such information becomes available (e.g., when a link is processed in which that node is the “to” node).
- certificates are used to check the credentials associated with cryptographic keys before making decisions based on the digital signature created with those keys.
- multiple certificate technologies can be supported, leveraging existing information typically available as standard elements of certificates, such as validity periods, names, etc.
- additional constraints can be encoded to limit potential usage of a certified key.
- this is accomplished by using key-usage extensions as part of the certificate-encoding process.
- the information encoded in such extensions can be used to enable the DRM engine to determine whether the key that has signed a specific object was authorized to be used for that purpose.
- a certain key may have a certificate that allows it to sign only those link objects in which the link is from a node with a specific attribute, and/or to a node with another specific attribute.
- the base technology used to express the certificate typically is not capable of expressing such a constraint, as its semantics may be unaware of elements such as links and nodes.
- specific constraints are therefore conveyed as key usage extensions of the basic certificate, including a “usage category” and a corresponding “constraint program.”
- the usage category specifies which type of objects a key is authorized to sign.
- the constraint program can express dynamic conditions based on context. In one embodiment a verifier that is being asked to verify the validity of such a certificate is required to understand the relevant semantics, though the evaluation of the key usage extension expression is delegated to the DRM engine. The certificate is considered valid only if the execution of that program generates a successful result.
- the role of a constraint program is to return a boolean value—e.g., “true” indicating that the constraint conditions are met, and “false” indicating that they are not met.
- the control program may also have access to some context information that can be used to reach a decision.
- the available context information may depend upon the type of decision being made by the DRM engine when it requests the verification of the certificate. For example, before using the information in a link object, a DRM engine may verify that the certificate of the key that signed the object allows that key to be used for that purpose.
- the environment of the DRM engine is populated with information regarding the link's attributes, as well as the attributes of the nodes referenced by that link.
- the constraint program embedded in the key usage extension is encoded, in one embodiment, as a code module (described above).
- This code module preferably exports at least one entry point named, for example,
- NEMO nodes before NEMO nodes invoke application-specific functionality, they go through a process of initialization and authorization. Nodes initially seek to discover desired services (via requests, registration, notification, etc.), and then obtain authorization to use those services (e.g., by establishing that they are trustworthy and that they satisfy any relevant service provider policies).
- FIG. 16 This process is illustrated in FIG. 16 , which outlines a basic interaction between a Service Provider 1600 (in this embodiment, with functionality shared between a Service Providing Node 1610 and an Authorizing Node 1620 ) and a Service Requester 1630 (e.g., a client consumer of services). Note that this interaction need not be direct. Any number of Intermediary Nodes 1625 may lie in the path between the Service Requester 1630 and the Service Provider 1600 . The basic steps in this process, which will be described in greater detail below, are discussed from the perspectives of both the client Service Requester 1630 and Service Provider 1600 .
- Service Requester 1630 initiates a service discovery request to locate any NEMO-enabled nodes that provide the desired service, and obtain information regarding which service bindings are supported for accessing the relevant service interfaces. Service Requester 1630 may choose to cache information about discovered services. It should be noted that the interface/mechanism for Service Discovery between NEMO Nodes is just another service a NEMO Node chooses to implement and expose. The Service Discovery process is described in greater detail below, including other forms of communication, such as notification by Service Providers to registered Service Requesters.
- Service Binding Selection Once candidate service-providing Nodes are found, the requesting Node can choose to target (dispatch a request to) one or more of the service-providing Nodes based on a specific service binding.
- Negotiation of Acceptable Trusted Relationship with Service Provider In one embodiment, before two Nodes can communicate in a secure fashion, they must be able to establish a trusted relationship for this purpose. This may include an exchange of compatible trust credentials (e.g. X.500 certificates, tokens, etc.) in some integrity-protected envelope that may be used to determine identity; and/or it may include establishing a secure channel, such as an SSL channel, based on certificates both parties trust.
- the exchange and negotiation of these credentials may be an implicit property of the service interface binding (e.g. WS-Security if the WS-I XML Protocol is used when the interface is exposed as a web service, or an SSL request between two well-known nodes).
- the exchange and negotiation of trust credentials may be an explicitly separate step.
- NEMO provides a standard and flexible framework allowing Nodes to establish trusted channels for communication. It is up to a given Node, based on the characteristics of the Node and on the characteristics of the service involved in the interaction, to determine which credentials are sufficient for interacting with another NEMO Node, and to make the decision whether it trusts a given Node.
- the NEMO framework leverages existing and emerging standards, especially in the area of security-related data types and protocols.
- the framework will support using SAML to describe both credentials (evidence) given by service requestors to service providers when they want to invoke a service, as well as using SAML as a way of expressing authorization queries and authorization responses.
- Creation of Request Message The next step is for Requesting Node 1630 to create the appropriate request message(s) corresponding to the desired service. This operation may be hidden by the Service Access Point.
- the Service Access Point provides an abstraction and interface for interacting with service providers in the NEMO framework, and may hide certain service invocation issues, such as native interfaces to service message mappings, object serialization/de-serialization, negotiation of compatible message formats, transport mechanisms or message routing issues, etc.
- Dispatching of Request —Once the request message is created, it is dispatched to the targeted service-providing Node(s)—e.g., Node 1610 .
- the communication style of the request can be synchronous/asynchronous RPC style or message-oriented, based on the service binding and/or preferences of the requesting client. Interacting with a service can be done directly by the transmission and processing of service messages or done through more native interfaces through the NEMO Service Access Point.
- Requesting Node 1610 receives one or more responses in reply.
- the reply(s) can be returned in various ways, including an RPC-style response or notification message.
- requests and replies can be routed to their targeted Node via other intermediary Node(s) 1625 , which may themselves provide a number of services, including: routing, trust negotiation, collation and correlation functions, etc. All services in this embodiment are “standard” NEMO services described, discovered, authorized, bound to, and interacted with in the same consistent framework.
- the Service Access Point may hide message-level abstractions from the Node.
- Requesting Node 1630 validates the response message to ensure that it adheres to the negotiated trust semantics between it and the Service Providing Node 1610 . This logic typically is completely encapsulated within the Service Access Point. Processing of Message Payload—Finally, any appropriate processing is then applied based on the (application specific) message payload type and contents.
- Service Support Determination A determination is first made as to whether the requested service is supported.
- the NEMO framework doesn't mandate the style or granularity of how a service interface maps as an entry point to a service.
- a service interface maps unambiguously to a given service, and the act of binding to and invoking that interface constitutes support for the service.
- Service Provider 1600 determines whether it trusts Requesting Node 1630 , and establish a trusted communication channel. This process is explained in detail above.
- Dispatch Authorization Request to Nodes Authorizing Access to Service Interface—Service Providing Node 1610 determines whether Requesting Node 1630 is authorized or entitled to have access to the service, and, if so, under what conditions. This may be a decision based on local information, or on a natively supported authorization decision mechanism.
- Service Providing Node 1610 may dispatch an authorization request(s) to a known NEMO authorization service provider (e.g., Authorizing Node 1620 ) that governs its services, in order to determine if the Requesting Node 1610 is authorized to have access to the requested services.
- Authorizing Node 1620 and Service Providing Node 1610 will be the same entity, in which case the dispatching and processing of the authorizing request will be local operations invoked through a lightweight service interface binding such as a C function entry point.
- Authorization requests can reference identification information and/or attributes associated with the NEMO Node itself, or information associated with users and/or devices associated with the Node.
- Message Processing Upon Receipt of Authorization Response Upon receiving the authorization response, if Requesting Node 1630 is authorized, Service Provider 1600 performs the necessary processing to fulfill the request. Otherwide, if Requesting Node 1630 is not authorized, an appropriate “authorization denied” response message can be generated.
- Return Response Message The response is then returned based on the service interface binding and the preferences of Requesting Node 1630 , using one of several communication methods, including an RPC-style response or notification message.
- requests and replies can be routed to their targeted Node via other Intermediary Node(s) 1625 , which may themselves provide a number of services, including routing, trust negotiation, collation and correlation functions, etc.
- An example of a necessary service provided by an Intermediary Node 1625 might be delivery to a notification processing Node that can deliver the message in a manner known to Requesting Node 1630 .
- An example of a “value added” service might be, for example, a coupon service which associates coupons to the response if it knows of the interests of Requesting Node 1630 .
- some NEMO embodiments also support a pure messaging type of communication pattern based on the notion of notification.
- the following elements constitute data and message types supporting this concept of notification in one embodiment:
- Notification a message containing a specified type of payload targeted at interested endpoint Nodes.
- Notification Interest criteria used to determine whether a given Node will accept a given notification.
- Notification interests may include interests based on specific types of identity (e.g., Node ID, user ID, etc.), events (e.g., Node discovery, service discovery, etc.), affinity groups (e.g., new jazz club content), or general categories (e.g., advertisements).
- Notification Payload the typed contents of a notification. Payload types may range from simple text messages to more complex objects.
- Notification Handler Service Interface the type of service provider interface on which notifications may be received. The service provider also describes the notification interests associated with the interface, as well as the acceptable payload types.
- a Node supporting this interface may be the final destination for the notification or an intermediary processing endpoint.
- Notification Processor Service a service that is capable of matching notifications to interested Nodes, delivering the notifications based on some policy.
- Notification Originator a Node that sends out a notification targeted to a set of interested Nodes and/or an intermediary set of notification processing Nodes.
- the notification, notification interest, and notification payload are preferably extensible. Additionally, the notification handler service interface is preferably subject to the same authorization process as any other NEMO service interface. Thus, even though a given notification may match in terms of interest and acceptable payload, a Node may refuse to accept a notification based on some associated interface policy related to the intermediary sender or originating source of the notification.
- FIG. 17 a depicts a set of notification processing Nodes 1710 discovering 1715 a Node 1720 that supports the notification handler service. As part of its service description, node 1720 designates its notification interests, as well as which notification payload types are acceptable.
- FIG. 17 b depicts how notifications can be delivered.
- Any Node could be the originating source as well as processor of the notification, and could be responsible for delivering the notification to Node 1720 , which supports the notification handler service.
- Node 1710 a could be the originating notification processing Node; or such functionality might be split between Node 1710 c (originating source of notification) and Node 1710 b (processor of notification).
- Still another Node (not shown) might be responsible for delivery of the notification.
- Notification processors that choose to handle notifications from foreign notification-originating Nodes may integrate with a commercial notification-processing engine such as Microsoft Notification Services in order to improve efficiency.
- NEMO Nodes In order to use NEMO services, NEMO Nodes will need to first know about them.
- One embodiment of NEMO supports three dynamic discovery mechanisms, illustrated in FIGS. 18 a - c:
- a NEMO Node 1810 a (in FIG. 18 a ) explicitly sends out a request to some set of targeted Nodes (e.g., 1820 a ) that support a “Service Query” service interface 1815 a , the request asking whether the targeted Nodes support a specified set of services. If requesting Node 1810 a is authorized, Service Providing Node 1820 a will send a response indicating whether it supports the requested interfaces and the associated service interface bindings. This is one of the more common interfaces that Nodes will support if they expose any services.
- Node 18 b can register its description, including its supported services, with other Nodes, such as Service Providing Node 1820 b . If a Node supports this interface 1815 b , it is willing to accept requests from other Nodes and then cache those descriptions based on some policy. These Node descriptions are then available directly for use by the receiving Node or by other Nodes that perform service queries targeted to Nodes that have cached descriptions. As an alternative to P2P registration, a Node could also utilize a public registry, such as a UDDI (Universal Discovery, Description and Integration) standard registry for locating services. Event-Based—Nodes (such as Node 1810 c in FIG.
- UDDI Universal Discovery, Description and Integration
- the notification 1815 c can contain a full description of the node and its services, or just the ID of the node associated with the event. Interested nodes may then choose to accept and process the notification.
- a NEMO Node before a NEMO Node allows access to a requested service, it first determines whether, and under which conditions, the requesting Node is permitted access to that service. Access permission is based on a trust context for interactions between service requestor and service provider. As will be discussed below, even if a Node establishes that it can be trusted, a service providing Node may also require that it satisfy a specified policy before permitting access to a particular service or set of services.
- NEMO does not mandate the specific requirements, criteria, or decision-making logic employed by an arbitrary set of Nodes in determining whether to trust each other. Trust semantics may vary radically from Node to Node. Instead, NEMO provides a standard set of facilities that allow Nodes to negotiate a mutually acceptable trusted relationship. In the determination and establishment of trust between Nodes, NEMO supports the exchange of credentials (and/or related information) between Nodes, which can be used for establishing a trusted context. Such trust-related credentials may be exchanged using a variety of different models, including the following:
- Service-Binding Properties a model where trust credentials are exchanged implicitly as part of the service interface binding. For example, if a Node 1920 a (in FIG. 19 a ) exposes a service in the form of an HTTP Post over SSL, or as a Web Service that requires a WS-Security XML Signature, then the actual properties of this service binding may communicate all necessary trust-related credentials 1915 a with a Requesting Node 1910 a.
- Request/Response Attributes a model where trust credentials are exchanged through WSDL request and response messages (see FIG. 19 b ) between a Requesting Node 1910 b and a Service Providing Node 1920 b , optionally including the credentials as attributes of the messages 1915 b .
- Explicit Exchange a model where trust credentials are exchanged explicitly through a service-provider interface ( 1915 c in FIG. 19 c ) that allows querying of information related to the trust credentials that a given node contains. This is generally the most involved model, typically requiring a separate roundtrip session in order to exchange credentials between a Requesting Node 1910 c and a Service Providing Node 1920 c .
- the service interface binding itself provides a mutually acceptable trusted channel for explicit exchange of credentials.
- NEMO can also support combinations of these different approaches.
- the communication channel associated with a semi-trusted service binding may be used to bootstrap the exchange of other security-related credentials more directly, or exchanging security-related credentials (which may have some type of inherent integrity) directly and using them to establish a secure communication channel associated with some service interface binding.
- trust model semantics and the processes of establishing trust may vary from entity to entity. In some situations, mutual trust between nodes may not be required.
- This type of dynamic heterogeneous environment calls for a flexible model that provides a common set of facilities that allow different entities to negotiate context-sensitive trust semantics.
- a service providing Node in addition to requiring the establishment of a trusted context before it allows a requesting Node to access a resource, may also require that the requesting Node satisfy a policy associated with that resource.
- the policy decision mechanism used for this purpose may be local and/or private.
- NEMO provides a consistent, flexible mechanism for supporting this functionality.
- an authorization service providing Node implements a standard service for handling and responding to authorization query requests. Before access is allowed to a service interface, the targeted service provider dispatches an “Authorization” query request to any authorizing Nodes for its service, and access will be allowed only if one or more such Nodes (or a pre-specified combination thereof) respond indicating that access is permitted.
- a Requesting Node 2010 exchanges messages 2015 with a Service Providing Node 2020 , including an initial request for a particular service.
- Service Providing Node 2020 determines whether Requesting Node 2010 is authorized to invoke that service, and thus exchanges authorization messages 2025 with the authorizing Nodes 2025 that manage access to the requested service, including an initial authorization request to these Nodes 2030 .
- Service Providing Node 2020 Based on the responses it receives, Service Providing Node 2020 then either processes and returns the applicable service response, or returns a response indicating that access was denied.
- the Authorization service allows a NEMO Node to participate in the role of policy decision point (PDP).
- PDP policy decision point
- NEMO is policy management system neutral; it does not mandate how an authorizing Node reaches decisions about authorizations based on an authorization query.
- authorization requests and responses adhere to some standard, and be sufficiently extensible to carry a flexible payload so that they can accommodate different types of authorization query requests in the context of different policy management systems.
- support is provided for at least two authorization formats: (1) a simple format providing a very simple envelope using some least common denominator criteria, such as input, a simple requestor ID, resource ID, and/or action ID, and (2) the standard “Security Assertion Markup Language” (SAML) format to envelope an authorization query.
- SAML Security Assertion Markup Language
- an authorizing Node must recognize and support at least a predefined “simple” format and be able to map it to whatever native policy expression format exists on the authorizing Node. For other formats, the authorizing Node returns an appropriate error response if it does not handle or understand the payload of an “Authorization” query request. Extensions may include the ability for Nodes to negotiate over acceptable formats of an authorization query, and for Nodes to query to determine which formats are supported by a given authorizing service provider Node.
- FIG. 21 is a DRM Node (or Vertex) Graph that can serve to illustrate the interaction among DRM Nodes, as well as their relationships.
- portable device 2110 is a content playback device (e.g., an iPod1).
- Nip1 is the Node that represents this device.
- Kip1 is the content encryption key associated with Nip1.
- User is the owner of the portable device, and
- Ng is the Node that represents the user.
- Kg is the content encryption key associated with Ng.
- PubLib is a Public Library.
- Npl represents the members of this library, and Kpl is the content encryption key associated with Npl.
- ACME represents all the ACME-manufactured Music Players.
- Namp represents that class of devices, and Kamp is the content encryption key associated with this group.
- L1 is a link from Nip1 to Ng, which means that the portable device belongs to the user (and has access to the user's keys).
- L2 is a link from Ng to Npl, which means that the user is a member of the Public Library (and has access to its keys).
- L3 is a link from Nip1 to Namp, which means that the portable device is an ACME device (mere membership, as the company has no keys).
- L4 is a link from Npl to Napl, which is the Node representing all public libraries (and has access to the groupwide keys).
- C1 is a movie file that the Public Library makes available to its members.
- Kc1 is a key used to encrypt C1.
- GB[C1] (not shown) is the governance information for C1 (e.g., rules and associated information used for governing access to the content).
- E(a,b) means ‘b’ encrypted with key ‘a’.
- the content C1 is encrypted with Kc1.
- the portable device receives C1 and GB[C1]. For example, both might be packaged in the same file, or received separately.
- the portable device received L1 when the user first installed his device after buying it.
- the portable device received L2 when the user paid his subscription fee to the Public Library.
- the portable device received L3 when it was manufactured (e.g., L3 was built in).
- the portable device is able to check that Nip1 has a graph path to Ng (L1), Npl (L1+L2), and Namp (L3).
- the portable device wants to play C1.
- the portable device runs the rule found in GB[C1].
- the rule can check that Nip1 is indeed an ACME device (path to Namp) and belongs to a member of the public library (path to Npl). Thus, the rule returns “yes”, and the ordered list (Namp, Npl).
- the portable device uses L1 to compute Kg, and then L2 to compute Kpl from Kg.
- the portable device also uses L3 to compute Kamp.
- the portable device applies Kpl and Kamp to RK[C1], found in GB[C1], and computes Kc1. It then uses Kc1 to decrypt and play C1.
- Node keys are symmetric keys
- the content packager needs to have access to the keys of the Nodes to which it wishes to “bind” the content. This can be achieved by creating a Node that represents the packager, and a link between that Node and the Nodes to which it wishes to bind rules. This can also be achieved “out of band” through a service, for instance. But in some situations, it may not be possible, or practical to use symmetric keys. In that case, it is possible to assign a key pair to the Nodes to which a binding is needed without shared knowledge. In that case, the packager would bind a content key to a Node by encrypting the content key with the target Node's public key. To obtain the key for decryption, the client would have access to the Node's private key via a link to that Node.
- the Nodes used for the rules and the Nodes used for computing content encryption keys need not be the same. It is natural to use the same Nodes, since there is a strong relationship between a rule that governs content and the key used to encrypt it, but it is not necessary. In some systems, some Nodes may be used for content protection keys that are not used for expressing membership conditions, and vice versa, and in some situations, two different graphs of Nodes can be used, one for the rules and one for content protection.
- a rule could say that all members of group Npl can have access to content C1, but the content key Kc1 may not be protected by Kpl, but may instead by protected by the node key Kapl of node Napl, which represents all public libraries, not just Npl. Or a rule could say that you need to be a member of Namp, but the content encryption key could be bound only to Npl.
- FIG. 22 depicts an exemplary code module 2200 of a DRM engine's VM that implements the formation and enforcement of such content governance policies.
- illustrative Code Module 2200 Four main elements of illustrative Code Module 2200 , shown in FIG. 22 , include:
- pkCM Atom The pkCM Atom 2210 is the top-level Code Module Atom. It contains a sequence of sub-atoms.
- pkDS Atom The pkDS Atom 2220 contains a memory image that can be loaded into the Data Segment.
- the payload of the Atom is a raw sequence of octet values.
- pkCS Atom The pkCS Atom 2230 contains a memory image that can be loaded into the Code Segment.
- the payload of the Atom is a raw sequence of octet values.
- pkEX Atom The pkEX Atom 2240 contains a list of export entries.
- Each export entry consists of a name, encoded as an 8-bit name size, followed by the characters of the name, including a terminating 0, followed by a 32-bit integer representing the byte offset of the named entry point (this is an offset from the start of the data stored in the pkCS Atom).
- the Control VM is responsible for loading Code Modules.
- a Code Module When a Code Module is loaded, the memory image encoded in pkDS Atom 2220 is loaded at a memory address in the Data Segment. That address is chosen by the VM Loader, and is stored in the DS pseudo-register.
- the memory image encoded in the pkCS Atom 2230 is loaded at a memory address in the Code Segment. That address is chosen by the VM Loader, and is stored in the CS pseudo-register.
- Control VM Programs can call functions implemented outside of their Code Module's Code Segment. This is done through the use of the OP_CALL instruction, that takes an integer stack operand specifying the System Call Number to call.
- the implementation can be a Control VM Byte Code routine in a different Code Module (for instance, a library of utility functions), directly by the VM in the VM's native implementation format, or delegated to an external software module, such as the VM's Host Environment.
- SYS_NOP 0: This call is a no-operation call. It just returns (does nothing else). It is used primarily for testing the VM.
- SYS_DEBUG_PRINT 1: Prints a string of text to a debug output. This call expects a single stack argument, specifying the address of the memory location containing the null-terminated string to print.
- SYS_FIND_SYSCALL_BY_NAME 2: Determines whether the VM implements a named System Call. If it does, the System Call Number is returned on the stack; otherwise the value ⁇ 1 is returned. This call expects a single stack argument, specifying the address of the memory location containing the null-terminated System Call name that is being requested.
- the Control VM reserves System Call Numbers 0 to 1023 for mandatory System Calls (System Calls that have to be implemented by all profiles of the VM).
- System Call Numbers 16384 to 32767 are available for the VM to assign dynamically (for example, the System Call Numbers returned by SYS_FIND_SYSCALL_BY_NAME can be allocated dynamically by the VM, and do not have to be the same numbers on all VM implementations).
- Standard System Calls are provided to facilitate writing Control Programs.
- Such standard system calls may include a call to obtain a time stamp from the host, a call to determine if a node is Reachable, and/or the like.
- System calls preferably have dynamically determined numbers (e.g., theft System Call Number can be retrieved by calling the SYS_FIND_SYSCALL_BY_NAME System Call with their name passed as the argument).
- the context object is used by the DRM engine to make callbacks into the application.
- This function should be called by the Host Application when it encounters certain types of objects in the media files that can be identified as belonging to the DRM subsystem.
- objects include content control programs, membership tokens, etc.
- the syntax and semantics of those objects is opaque to the Host Application.
- the host application calls this function when it needs to interact with a multimedia content file.
- the DRM engine returns a Content object that can be used subsequently for retrieving DRM information about the content, and interacting with such information.
- the Host Application calls this function when it wants to interact with a Content object.
- the actionInfo parameter specifies what type of action the application needs to perform (e.g., Play), as well as any associated parameters, if necessary.
- the function returns an Action object that can then be used to perform the action and retrieve the content key.
- This virtual FileSystem will be used to store DRM state information.
- the data within this FileSystem is readable and writeable only by the DRM subsystem.
- HostContext : VerifySignature(signatureInfo)
- the signatureInfo object contains information equivalent to the information found in an XMLSig element.
- the Host Services are responsible for managing the keys and key certificates necessary to validate the signature.
- HostContext::CreateCipher(cipherType, keyInfo) ⁇ Cipher Creates a Cipher object that the DRM subsystem can use to encrypt and decrypt data.
- a minimal set of cipher types will preferably be defined, and for each a format for describing the key info required by the cipher implementation.
- Cipher Encrypt(data)
- the Cipher object referred to above used to encrypt data.
- Cipher Decrypt(data)
- the Cipher object referred to above used to decrypt data.
- the Digester object referred to above used to obtain the secure hash computed by the DRM subsystem.
- the context object is used by the DRM Packaging engine to make callbacks into the application.
- the Host Application will call this function in order to create a Content object that will be associated with license objects in subsequent steps. Having more than one content reference in the contentReferences array implies that these are bound together in a bundle (one audio and one video track for example), and that the license issued should be targeted to these as one indivisible group.
- the drmInfo parameter specifies the metadata of the license that will be issued.
- the structure will be read and will act as a guideline to compute the license into bytecode for the VM.
- Content::GetDRMObjects(format) ⁇ drmObjects This function is called when the Host Application is ready to get the drmObjects that the DRM Packaging engine created.
- the format parameter will indicate the format expected for these objects (e.g., XML or binary atoms).
- Content::GetKeys( ) ⁇ keys[ ] This function is called by the Host Application when it needs the keys in order to encrypt the content. In one embodiment there will be one key per content reference.
- This virtual FileSystem would be used to store DRM state information.
- the data within this FileSystem should only be readable and writeable by the DRM subsystem.
- HostContext GetCurrentTime( ) ⁇ Time
- HostContext GetIdentity( ) ⁇ ID
- HostContext :PerformSignature(signatureInfo, data)
- Some DRM objects created by the DRM Packaging engine will have to be trusted. This service, provided by the host, will be used to sign the specified object.
- Cipher Encrypt(data)
- the Cipher object referred to above used to encrypt data.
- Cipher Decrypt(data)
- the Cipher object referred to above used to decrypt data.
- the Digester object referred to above used to comput the secure hash.
- the Digester object referred to above used to obtain the secure hash computed by the DRM subsystem.
- a preferred embodiment of the NEMO architecture employs a flexible and portable way of describing the syntax of requests and responses associated with service invocation, data types used within the framework, message enveloping, and data values exposed by and used within the NEMO framework.
- WSDL 1.1 and above provides sufficient flexibility to describe and represent a variety of types of service interface and invocation patterns, and has sufficient abstraction to accommodate bindings to a variety of different endpoint Nodes via diverse communication protocols.
- a profile to be a set of thematically related data types and interfaces defined in WSDL.
- NEMO distinguishes a “Core” profile (which includes the foundational set of data types and service messages necessary to support fundamental NEMO Node interaction patterns and infrastructural functionality) from an application-specific profile, such as a DRM Profile (which describes the Digital Rights Management services that can be realized with NEMO), both of which are discussed below.
- the definition of service interfaces and related data types is structured as a set of mandatory and optional profiles that build on one another and may be extended.
- the difference between a profile and a profile extension is a relatively subtle one.
- profile extensions don't add new data types or service type definitions. They just extend existing abstract and concrete types.
- FIG. 23 illustrates an exemplary profile hierarchy for NEMO and DRM functionality.
- the main elements of this profile hierarchy include:
- Core Profile At the base of this profile hierarchy lies Core Profile 2300 , which preferably shares both NEMO and DRM functionality. This is the profile on which all other profiles are based. It includes a basic set of generic types (discussed below) that serve as the basis for creating more complex types in the framework. Many of the types in the Core Profile are abstract and will need to be specialized before use.
- Core Profile Extensions immediately above Core Profile 2300 are the Core Profile Extensions 2320 , which are the primary specializations of the types in Core Profile 2300 , resulting in concrete representations.
- Core Services Profile Also immediately above Core Profile 2300 , the Core Services Profile 2310 defines a set of general infrastructure services, also discussed below.
- Core Services Profile Extensions Building upon both Core Profile Extensions 2320 and Core Services Profile 2310 are the Core Services Profile Extensions 2330 , which are the primary specializations of the services defined in Core Services Profile 2310 , resulting in concrete representations.
- DRM Profile immediately above Core Profile 2300 lies DRM Profile 2340 , upon which other DRM-related profiles are based.
- DRM Profile 2340 includes a basic set of generic types (discussed below) that serve as the basis for creating more complex DRM-specific types. Many of the types in DRM Profile 2340 are abstract and will need to be specialized before use.
- DRM Profile Extensions Building upon DRM Profile 2340 are the DRM Profile Extensions 2350 , which are the primary specializations of the types in DRM Profile 2340 , resulting in concrete representations.
- DRM Services Profile Also building upon DRM Profile 2340 is DRM Services Profile 2360 , which defines a set of general DRM services (discussed below). In this profile, the service definitions are abstract and need to be specialized before use.
- Specific DRM Profile Building upon both DRM Profile Extensions 2350 and DRM Services Profile 2360 is the Specific DRM Profile 2370 , which is a further specialization of the DRM services defined in DRM Services Profile 2360 . This profile also introduces some new types and further extends certain types specified in Core Profile Extensions 2320 .
- Peer Discovery the ability to have peers in the system discover one another.
- Service Discovery the ability to discover and obtain information about services offered by different peers.
- Authorization the ability to determine if a given peer (e.g., a Node) is authorized to access a given resource (such as a service).
- Notification services related to the delivery of targeted messages, based on specified criteria, to a given set of peers (e.g., Nodes).
- Personalization services to obtain the credentials, policy, and other objects needed for a DRM-related endpoint (such as a CE device, music player, DRM license server, etc.) to establish a valid identity in the context of a specific DRM system.
- Licensing Acquisition services to obtain new DRM licenses.
- Licensing Translation services to exchange one new DRM license format for another.
- Membership services to obtain various types of objects that establish membership within some designated domain.
- the NEMO/DRM profile hierarchy can be described, in one embodiment, as a set of Generic Interface Specifications (describing an abstract set of services, communication patterns, and operations), Type Specifications (containing the data types defined in the NEMO profiles), and Concrete Specifications (mapping abstract service interfaces to concrete ones including bindings to specific protocols).
- Generic Interface Specifications describing an abstract set of services, communication patterns, and operations
- Type Specifications containing the data types defined in the NEMO profiles
- Concrete Specifications mapping abstract service interfaces to concrete ones including bindings to specific protocols.
- FIG. 24 illustrates a relatively simple example of an embodiment of NEMO in operation in the context of a consumer using a new music player to play a DRM-protected song.
- This simple example illustrates many different potential related application scenarios.
- This example demonstrates the bridging of discovery services—using universal plug and play (UPnP) based service discovery as a mechanism to find and link to a UDDI based directory service. It also details service interactions between Personal Area Network (PAN) and Wide Area Network (WAN) services, negotiation of a trusted context for service use, and provisioning of a new device and DRM service.
- UDDI universal plug and play
- a consumer having bought a new music player 2400 , desires to play a DRM-protected song.
- Player 2400 can support this DRM system, but needs to be personalized.
- Player 2400 although it includes certain elements (not shown) that render it both NEMO-enabled and DRM-capable, must first perform a personalization process to become part of this system.
- a NEMO client would include certain basic elements illustrated in FIGS. 5 a and 6 above, such as a Service Access Point to invoke other Node's services, Trust Management Processing to demonstrate that it is a trusted resource for playing certain protected content, as well as a Web Services layer to support service invocations and the creation and receipt of messages. As discussed below, however, not all of these elements are necessary to enable a Node to participate in a NEMO system.
- client nodes may also include certain basic DRM-related elements, as illustrated in FIGS. 12 a and 13 - 15 above, such as a DRM client engine and cryptographic services (and related objects and cryptographic keys) to enable processing of protected content, including decrypting protected songs, as well as a media rendering engine to play those songs.
- DRM client engine and cryptographic services (and related objects and cryptographic keys) to enable processing of protected content, including decrypting protected songs, as well as a media rendering engine to play those songs.
- cryptographic services and related objects and cryptographic keys
- Player 2400 is wireless, supports the UPnP and Bluetooth protocols, and has a set of X.509 certificates it can use to validate signatures and sign messages.
- Player 2400 is NEMO-enabled in that it can form and process a limited number of NEMO service messages, but it does not contain a NEMO Service Access Point due to resource constraints.
- Player 2400 is able to participate in a Personal Area Network (PAN) 2410 in the user's home, which includes a NEMO-enabled, Internet-connected, Home Gateway Device 2420 with Bluetooth and a NEMO SAP 2430 .
- PAN Personal Area Network
- the UPnP stacks of both Player 2400 and Gateway 2420 have been extended to support a new service profile type for a “NEMO-enabled Gateway” service, discussed below.
- Player 2400 determines that it needs to be personalized, and initiates the process. For example, Player 2400 may initiate a UPnP service request for a NEMO gateway on PAN 2410 . It locates a NEMO gateway service, and Gateway 2420 returns the necessary information to allow Player 2400 to connect to that service.
- Player 2400 then forms a NEMO Personalization request message and sends it to the gateway service.
- the request includes an X.509 certificate associated with Player 2400 's device identity.
- Gateway 2420 upon receiving the request, determines that it cannot fulfill the request locally, but has the ability to discover other potential service providers. However, Gateway 2420 has a policy that all messages it receives must be digitally signed, and thus it rejects the request and returns an authorization failure stating the policy associated with processing this type of request.
- Player 2400 upon receiving this rejection, notes the reason for the denial of service and then digitally signs (e.g., as discussed above in connection with FIG. 15 ) and re-submits the request to Gateway 2420 , which then accepts the message.
- Gateway 2420 cannot fulfill this request locally, but can perform service discovery.
- Gateway 2420 is unaware of the specific discovery protocols its SAP 2430 implementation supports, and thus composes a general attribute-based service discovery request based on the type of service desired (personalization), and dispatches the request via SAP 2430 .
- SAP 2430 configured with the necessary information to talk to UDDI registries, such as Internet-Based UDDI Registry 2440 , converts the request into a native UDDI query of the appropriate form and sends the query.
- UDDI Registry 2440 knows of a service provider that supports DRM personalization and returns the query results.
- SAP 2430 receives these results and returns an appropriate response, with the necessary service provider information, in the proper format, to Gateway 2420 .
- Gateway 2420 extracts the service provider information from the service discovery response and composes a new request for Personalization based on the initial request on behalf of Player 2400 .
- This request is submitted to SAP 2430 .
- the service provider information (in particular, the service interface description of Personalization Service 2450 ) reveals how SAP 2430 must communicate with a personalization service that exposes its service through a web service described in WSDL. SAP 2430 , adhering to these requirements, invokes Personalization Service 2450 and receives the response.
- Gateway 2420 then returns the response to Player 2400 , which can use the payload of the response to personalize its DRM engine.
- Player 2400 is provisioned, and can fully participate in a variety of local and global consumer oriented services. These can provide full visibility into and access to a variety of local and remote content services, lookup, matching and licensing services, and additional automated provisioning services, all cooperating in the service of the consumer. As explained above, various decryption keys may be necessary to access certain protected content, assuming the consumer and Player 2400 satisfy whatever policies are imposed by the content provider.
- a consumer using a personal media player at home can enjoy the simplicity of a CE device, but leverage the services provided by both gateway and peer devices.
- the device can rediscover and use most or all of the services available at home, and, through new gateway services, be logically connected to the home network, while enjoying the services available at the new venue that are permitted according to the various policies associated with those services.
- the consumer's device can provide services to peers found at the new venue.
- NEMO Nodes SAPs
- Service Adaptation Layers various standards such as XML, WSDL, SOAP, UDDI, etc.
- Player 2400 might have contained its own SAP, perhaps eliminating the need for Gateway 2420 .
- UDDI Registry 2440 might have been used for other purposes, such as locating and/or licensing music content.
- DRM applications could be constructed, e.g., involving a licensing scheme imposing complex usage and distribution policies for many different types of audio and video, for a variety of different categories of users.
- any other service-based applications could be constructed using the NEMO framework.
- Preferred embodiments of NEMO can be used to address these limitation by means of a P2P policy architecture that stresses capability discovery and format negotiation. It is possible to structure the creation of an application (e.g., a document) in richer ways, providing multiple advantages. Rich policy can be applied to the objects and to the structure of the application. For example, a policy might specify some or all of the following:
- the authoring application used by each participant can be a NEMO-enabled peer.
- a template can be used that describes the policy, including who is authorized and what can be done to each part of the document (in addition to the document's normal formatting rules).
- the policy engine used by the NEMO peer can interpret and enforce policy rules consistent with their semantics, and as long as the operations supported by the peer interfaces allowed in the creation of the document can be mapped to a given peer's environment via the Service Adaptation Layer, then any peer can participate, but may internally represent the document differently.
- a wireless PDA application is running an application written in Java, which it uses for processing and rendering the document as text.
- a different implementation running under Microsoft Windows® on a desktop workstation processes the same document using the Microsoft Word® format.
- Both the PDA and the workstation are able to communicate, for example, by connection over a local area network, thus enabling the user of the PDA and the user of the workstation to collaborate on the same document application.
- a portable wireless consumer electronics (CE) device that is a NEMO-enabled node (X), and that supports DRM format A, but wants to play content in DRM format B.
- X announces its desire to render the content as well as a description of its characteristics (e.g., what its identity is, what OS it supports, its renewability profile, payment methods it supports, and/or the like) and waits for responses back from other NEMO peers providing potential solutions.
- X receives three responses:
- X determines that option one is the best choice. It submits a request for content via offer number one.
- the request includes an assertion for a delegation that allows Peer 1 to deduct $2.00 from X's payment account via another NEMO service. Once X has been charged, then X is given back in a response from Peer 1 a token that allows it to download the MP3 file.
- option three may need to be represented as a transactional business process described using a NEMO Orchestration Descriptor (NOD) implemented by the NEMO Workflow Collator (WFC) elements contained in the participating NEMO enabled peers.
- NOD NEMO Orchestration Descriptor
- WFC NEMO Workflow Collator
- Yet another example of a potential application of the NEMO framework is in the context of online gaming.
- Many popular multiplayer gaming environment networks are structured as centralized, closed portals that allow online garners to create and participate in gaming sessions.
- One of the limitations of these environments is that the users generally must have a tight relationship with the gaming network and must have an account (usually associated with a particular game title) in order to use the service.
- the typical gamer must usually manage several game accounts across multiple titles across multiple gaming networks and interact with game-provider-specific client applications in order to organize multiple player games and participate within the networks. This is often inconvenient, and discourages online use.
- Embodiments of the NEMO framework can be used to enhance the online gaming experience by creating an environment that supports a more federated distributed gaming experience, making transparent to the user and the service provider the details of specific online game networks. This not only provides a better user experience, thereby encouraging adoption and use of these services, but can also reduce the administrative burden on game network providers.
- gaming clients can be personalized with NEMO modules so that they can participate as NEMO peers.
- gaming networks can be personalized with NEMO modules so that they can expose their administrative interfaces in standardized ways.
- NEMO trust management can be used to ensure that only authorized peers interact in intended ways.
- X and Y both acquire a new title that works with C and want to play each other.
- X's gaming peer can automatically discover online gaming provider C.
- X's account information can be transmitted to C from A, after A confirms that C is a legitimate gaming network.
- X is now registered with C, and can be provisioned with correct tokens to interact with C.
- User Y goes through the same process to gain access to C using its credentials from B. Once both X and Y are registered they can now discover each other and create an online gaming session.
- This simple registration example can be further expanded to deal with other services that online gaming environments might provide, including, e.g., game token storage (e.g., in lockers), account payment, and shared state information such as historical score boards.
- game token storage e.g., in lockers
- account payment e.g., debit card
- shared state information such as historical score boards.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computing Systems (AREA)
- Databases & Information Systems (AREA)
- Business, Economics & Management (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Accounting & Taxation (AREA)
- Data Mining & Analysis (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Finance (AREA)
- Computer And Data Communications (AREA)
- Storage Device Security (AREA)
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Systems and methods are described for performing policy-managed, peer-to-peer service orchestration in a manner that supports the formation of self-organizing service networks that enable rich media experiences. In one embodiment, services are distributed across peer-to-peer communicating nodes, and each node provides message routing and orchestration using a message pump and workflow collator. Distributed policy management of service interfaces helps to provide trust and security, supporting commercial exchange of value. Peer-to-peer messaging and workflow collation allow services to be dynamically created from a heterogeneous set of primitive services. The shared resources are services of many different types, using different service interface bindings beyond those typically supported in a web service deployments built on UDDI, SOAP, and WSDL. In a preferred embodiment, a media services framework is provided that enables nodes to find one another, interact, exchange value, and cooperate across tiers of networks from WANs to PANs.
Description
- This application is a division of U.S. application Ser. No. 11/894,624, filed Aug. 20, 2007, which is a continuation of U.S. application Ser. No. 10/863,551, filed Jun. 7, 2004, which claims the benefit of U.S. Provisional Applications Nos. 60/476,357, filed Jun. 5, 2003, entitled Systems and Methods for Peer-To-Peer Service Orchestration, attached hereto as Appendix 1(A), and 60/504,524, filed Sep. 15, 2003, entitled Digital Rights Management Engine Systems and Methods, attached hereto as Appendix 1(B), all of which are incorporated herein by reference.
- A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
- Networks such as the Internet have become the predominant medium for the delivery of digital content and media related services. The emergence of standard web services protocols promises to accelerate this trend, enabling companies to provide services that can interoperate across multiple software platforms and support cooperation between business services and consumers via standardized mechanisms.
- Yet, significant barriers exist to the goal of an interoperable and secure world of media-related services. For example, multiple, overlapping de facto and formal standards can actually inhibit straightforward interoperability by forcing different implementations to choose between marginally standard, but otherwise incompatible, alternative technical approaches to addressing the same basic interoperability or interconnection problems. In some cases these incompatibilities are due to problems that arise from trying to integrate different generations of technologies, while in other cases the problems are due to market choices made by different parties operating at the same time but in different locales and with different requirements. Thus, despite standardization, it is often difficult to locate, connect to, and interact with devices that provide needed services. And there are frequently incompatibility issues between different trust and protection models.
- While emerging web service standards such as WSDL (Web Services Description Language) are beginning to address some of these issues for Internet-facing systems, such approaches are incomplete. They fail to address these issues across multiple network tiers spanning personal and local area networks; home, enterprise, and department gateways; and wide area networks. Nor do they adequately address the need for interoperability based on dynamic orchestration of both simple and complex services using a variety of service interface bindings (e.g., CORBA, WS-I, Java RMI, DCOM, C function invocation, .Net, etc.), thus limiting the ability to integrate many legacy applications. The advent of widely deployed and adopted peer-to-peer (P2P) applications and networks further compounds the challenges of creating interoperable media-related services, due in part to the fact that there is no unified notion of how to represent and enforce usage rights on digital content.
- Embodiments of the systems and methods described herein can be used to address some or all of the foregoing problems. In one embodiment, a services framework is provided that enables multiple types of stakeholders in the consumer or enterprise media space (e.g., consumers, content providers, device manufacturers, service providers) to find each other, establish a trusted relationship, and exchange value in rich and dynamic ways through exposed service interfaces. Embodiments of this framework—which will be referred to generally as the Network Environment for Media Orchestration (NEMO)—can provide a platform for enabling interoperable, secure, media-related e-commerce in a world of heterogeneous consumer devices, media formats, communication protocols, and security mechanisms. Distributed policy management of the service interfaces can be used to help provide trust and security, thereby facilitating commercial exchange of value.
- While emerging web service standards are beginning to address interoperability issues for Internet-facing services, embodiments of NEMO can be used to address interoperability across multiple network tiers spanning personal and local area networks; home, enterprise, and department gateways; and wide area networks. For example, NEMO can provide interoperability in one interconnected system using cell phones, game platforms, PDAs, PCs, web-based content services, discovery services, notification services, and update services. Embodiments of NEMO can further be used to provide dynamic, peer-to-peer orchestration of both simple and complex services using a variety of local and remote interface bindings (e.g. WS-I[1], Java RMI, DOOM, C, .Net, etc.), thereby enabling the integration of legacy applications.
- In the media world, the systems and interfaces required or favored by the major sets of stakeholders (e.g., content publishers, distributors, retail services, consumer device providers, and consumers) often differ widely. Thus, it is desirable to unite the capabilities provided by these entities into integrated services that can rapidly evolve into optimal configurations meeting the needs of the participating entities.
- For example, diverse service discovery protocols and registries, such as Bluetooth, UPnP, Rendezvous, JINI, UDDI, and LDAP (among others) can coexist within the same service, enabling each node to use the discovery service(s) most appropriate for the device that hosts that node. Another service might support IP-based as well as wireless SMS notification, or various media formats (MP4, WMF, etc.).
- Embodiments of NEMO satisfy these goals using peer-to-peer (P2P) service orchestration. While the advantages of P2P frameworks have been seen for such things as music and video distribution, P2P technology can be used much more extensively.
- Most activity in web services has focused on machine-to-machine interaction with relatively static network configuration and client service interactions. NEMO is also capable of handling situations in which a person carries parts of their personal area network (PAN), moves into the proximity of a LAN or another PAN, and wants to reconfigure service access immediately, as well as connect to many additional services on a peer basis.
- Opportunities also exist in media and various other enterprise services, and especially in the interactions between two or more enterprises. While enterprises are most often organized hierarchically, and their information systems often reflect that organization, people from different enterprises will often interact more effectively through peer interfaces. For example, a receiving person/service in company A can solve problems or get useful information more directly by talking to the shipping person in company B. Traversing hierarchies or unnecessary interfaces generally is not useful. Shipping companies (such as FedEx and UPS) realize this and allow direct visibility into their processes, allowing events to be directly monitored by customers. Companies and municipalities are organizing their services through enterprise portals, allowing crude forms of self-service.
- However, existing peer-to-peer frameworks do not allow one enterprise to expose its various service interfaces to its customers and suppliers in such a way as to allow those entities to interact at natural peering levels, enabling those entities to orchestrate the enterprise's services in ways that best suit them. This would entail, for example, some form of trust management of those peer interfaces. Preferred embodiments of the present invention can be used to not only permit, but facilitate, this P2P exposure of service interfaces.
- In the context of particular applications such as DRM (Digital Rights Management), embodiments of NEMO can be used to provide a service-oriented architecture designed to address the deficiencies and limitations of closed, homogeneous DRM systems. Preferred embodiments can be used to provide interoperable, secure, media-related commerce and operations for disparate consumer devices, media formats, and security mechanisms.
- In contrast to many conventional DRM systems, which require relatively sophisticated and heavyweight client-side engines to handle protected content, preferred embodiments of the present invention enable client-side DRM engines to be relatively simple, enforcing the governance policies set by richer policy management systems operating at the service level. Preferred embodiments of the present invention can also provide increased flexibility in the choice of media formats and cryptographic protocols, and can facilitate interoperability between DRM systems.
- A simple, open, and flexible client-side DRM engine can be used to build powerful DRM-enabled applications. In one embodiment, the DRM engine is designed to integrate easily into a web services environment, and into virtually any host environment or software architecture.
- Service orchestration is used to overcome interoperability barriers. For example, when there is a query for content, the various services (e.g., discovery, search, matching, update, rights exchange, and notification) can be coordinated in order to fulfill the request. Preferred embodiments of the orchestration capability allow a user to view all home and Internet-based content caches from any device at any point in a dynamic, multi-tiered network. This capability can be extended to promote sharing of streams and playlists, making impromptu broadcasts and narrowcasts easy to discover and connect to, using many different devices, while ensuring that rights are respected. Preferred embodiments of NEMO provide an end-to-end interoperable media distribution system that does not rely on a single set of standards for media format, rights management, and fulfillment protocols.
- In the value chain that includes content originators, distributors, retailers, service providers, device manufacturers, and consumers, there are often a number of localized needs in each segment. This is especially true in the case of rights management, where content originators may express rights of use that apply differently in various contexts to different downstream value chain elements. A consumer gateway typically has a much more narrow set of concerns, and an end user device may have a yet simpler set of concerns, namely just playing the content. With a sufficiently automated system of dynamically self-configuring distribution services, content originators can produce and package content, express rights, and confidently rely on value added by other service providers to rapidly provide the content to interested consumers, regardless of where they are or what kind of device they are using.
- Preferred embodiments of NEMO fulfill this goal by providing means for multiple service providers to innovate and introduce new services that benefit both consumers and service providers without having to wait for or depend on a monolithic set of end-to-end standards. Policy management can limit the extent to which pirates can leverage those legitimate services. NEMO allows the network effect to encourage the evolution of a very rich set of legitimate services providing better value than pirates can provide.
- Some “best practice” techniques common to many of the NEMO embodiments discussed below include the following:
-
- Separation of complex device-oriented and service-oriented policies
- Composition of sophisticated services from simpler services
- Dynamic configuration and advertisement of services
- Dynamic discovery and invocation of various services in a heterogeneous environment
- Utilization of gateway services from simple devices
- A novel DRM engine and architecture is also presented that can be used with the NEMO framework. This DRM system can be used to achieve some or all of the following goals:
- Simplicity. In one embodiment, a DRM engine is provided that uses a minimalist stack-based Virtual Machine (VM) to execute control programs (e.g., programs that enforce governance policies). For example, the VM might consist of only a few pages of code.
- Modularity. In one embodiment, the DRM engine is designed to function as a single module integrated into a larger DRM-enabled application. Many of the functions that were once performed by monolithic DRM kernels (such as cryptography services) can be requested from the host environment, which may provide these services to other code modules. This allows designers to incorporate standard or proprietary technologies with relative ease.
- Flexibility. Because of its modular design, preferred embodiments of the DRM engine can be used in a wide variety of software environments, from embedded devices to general-purpose PCs.
- Open. Embodiments of the DRM engine are suitable for use as reference software, so that code modules and APIs can be implemented by users in virtually any programming language and in systems that they control completely. In one embodiment, the system does not force users to adopt particular content formats or restrict content encoding.
- Semantically Agnostic. In one embodiment, the DRM engine is based on a simple graph-based model that turns authorization requests into queries about the structure of the graph. The vertices in the graph represent entities in the system, and directed edges represent relationships between these entities. However, the DRM engine does not need to be aware of what these vertices and edges represent in any particular application.
- Seamless Integration with Web Services. The DRM client engine can use web services in several ways. For example, vertices and edges in the graph can be dynamically discovered through services. Content and content licenses may also be discovered and delivered to the DRM engine through sophisticated web services. Although one embodiment of the DRM engine can be configured to leverage web services in many places, its architecture is independent of web services, and can be used as a stand-alone client-side DRM kernel.
- Simplified Key Management. In one embodiment, the graph topology can be reused to simplify the derivation of content protection keys without requiring cryptographic retargeting. The key derivation method is an optional but powerful feature of the DRM engine—the system can also, or alternatively, be capable of integrating with other key management systems.
- Separation of Governance, Encryption, and Content. In one embodiment, the controls that govern content are logically distinct from the cryptographic information used to enforce the governance. Similarly, the controls and cryptographic information are logically distinct from content and content formats. Each of these elements can be delivered separately or in a unified package, thus allowing a high degree of flexibility in designing a content delivery system.
- Embodiments of the NEMO framework, its applications, and its component parts are described herein. It should be understood that the framework itself is novel, as are many of its components and applications. It should also be appreciated that the present inventions can be implemented in numerous ways, including as processes, apparatuses, systems, devices, methods, computer readable media, or a combination thereof. These and other features and advantages will be presented in more detail in the following detailed description and the accompanying drawings which illustrate by way of example the principles of the inventive body of work.
- Embodiments of the inventive body of work will be readily understood by referring to the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:
-
FIG. 1 illustrates a sample embodiment of the system framework. -
FIG. 2 a illustrates a conceptual network of system nodes. -
FIG. 2 b illustrates system nodes in a P2P network. -
FIG. 2 c illustrates system nodes operating across the Internet. -
FIG. 2 d illustrates a system gateway node. -
FIG. 2 e illustrates a system proxy node. -
FIG. 2 f illustrates a system device adapter node. -
FIG. 3 illustrates a conceptual network of DRM devices. -
FIG. 4 illustrates a conceptual DRM node authorization graph. -
FIG. 5 a illustrates a conceptual view of the architecture of a system node. -
FIG. 5 b illustrates multiple service interface bindings supported by the service adaptation layer of a system node. -
FIG. 6 a illustrates basic interaction between a service-providing system node and a service-consuming system node. -
FIG. 6 b is another example of an interaction between a service-providing system node and a service-consuming system node. -
FIG. 7 a illustrates a service access point involved in a client-side WSDL interaction. -
FIG. 7 b illustrates a service access point involved in a client-side native interaction. -
FIG. 7 c illustrates a service access point involved in a service-side point-to-point interaction pattern. -
FIG. 7 d illustrates a service access point involved in a service-side point-to-multiple point interaction pattern. -
FIG. 7 e illustrates a service access point involved in a service-side point-to-intermediary interaction pattern. -
FIG. 8 illustrates an embodiment of the architecture of the service adaptation layer. -
FIG. 9 a illustrates an interaction pattern of a workflow collator relying upon external service providers. -
FIG. 9 b illustrates an interaction pattern of a workflow collator involved in direct multi-phase communications with a client node. -
FIG. 9 c illustrates a basic intra-node interaction pattern of a workflow collator. -
FIG. 9 d illustrates a relatively complex interaction pattern of a workflow collator. -
FIG. 10 illustrates the system integration of a DRM engine. -
FIG. 11 illustrates an embodiment of the architecture of a DRM engine. -
FIG. 12 a illustrates a DRM engine and related elements within a client-side system node. -
FIG. 12 b illustrates a DRM engine and related elements within a service-side system node. -
FIG. 13 illustrates an embodiment of content protection and governance DRM objects. -
FIG. 14 illustrates an embodiment of node and link DRM objects. -
FIG. 15 illustrates an embodiment of DRM cryptographic key elements. -
FIG. 16 illustrates a basic interaction pattern between client and service-providing system nodes. -
FIG. 17 a illustrates a set of notification processing nodes discovering a node that supports a notification handler service. -
FIG. 17 b illustrates the process of notification delivery. -
FIG. 18 a illustrates a client-driven service discovery scenario in which a requesting node makes a service discovery request to a targeted service providing node. -
FIG. 18 b illustrates a peer registration service discovery scenario in which a requesting node seeks to register its description with a service providing node. -
FIG. 18 c illustrates an event-based service discovery scenario in which an interested node receives a notification of a change in service availability (e.g., the existence of a service within a service-providing node). -
FIG. 19 a illustrates the process of establishing trust using a service binding with an implicitly trusted channel. -
FIG. 19 b illustrates the process of establishing trust based on a request/response model. -
FIG. 19 c illustrates the process of establishing trust based on an explicit exchange of security credentials. -
FIG. 20 illustrates policy-managed access to a service. -
FIG. 21 illustrates a sample DRM node graph with membership and key access links. -
FIG. 22 illustrates an embodiment of the format of a DRM VM code module. -
FIG. 23 illustrates a system function profile hierarchy. -
FIG. 24 illustrates DRM music player application scenarios. - A detailed description of the inventive body of work is provided below. While this description is provided in conjunction with several embodiments, it should be understood that the inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents. For example, while some embodiments are described in the context of consumer-oriented content and applications, those skilled in the art will recognize that the disclosed systems and methods are readily adaptable for broader application. For example, without limitation, these embodiments could be readily adapted and applied to the context of enterprise content and applications. In addition, while numerous specific details are set forth in the following description in order to provide a thorough understanding of the inventive body of work, some embodiments may be practiced without some or all of these details. Moreover, for the purpose of clarity, certain technical material that is known in the art has not been described in detail in order to avoid unnecessarily obscuring the inventive body of work.
- 1.1. Web Services
- The Web Services Architecture (WSA) is a specific instance of a Service Oriented Architecture (SOA). An SOA is itself a type of distributed system consisting of loosely coupled, cooperating software agents. The agents in an SOA may provide a service, request (consume) a service, or do both. A service can be seen as a well-defined, self-contained set of operations managed by an agent acting in a service provider role. The operations are invoked over the network at some network-addressable location, called an endpoint, using standard protocols and data formats. By self-contained, it is meant that the service does not depend directly on the state or context of another service or encompassing application.
- Examples of established technologies that support the concepts of an SOA include CORSA, DCOM, and J2EE. WSA is attractive because it is not tied to a specific platform, programming language, application protocol stack, or data format convention. WSA uses standard formats based on XML for describing services and exchanging messages which promotes loose coupling and interoperability between providers and consumers, and supports multiple standard Internet protocols (notably HTTP), which facilitates deployment and participation in a potentially globally distributed system.
- An emerging trend is to view an SOA in the context of a “plug-and-play” service bus. The service bus approach provides for orchestration of services by leveraging description, messaging, and transport standards. The infrastructure may also incorporate standards for discovery, transformation, security, and perhaps others as well. Through the intrinsic qualities of the ubiquitous standards incorporated into the WSA, it is flexible, extensible, and scalable, and therefore provides the appropriate foundation for constructing an orchestrated service bus model. In this model, the fundamental unit of work (the service) is called a web service.
- There are a wide number of definitions for a web service. The following definition comes from the World Wide Web Consortium (W3C) Web Services Architecture working draft (Aug. 8, 2003—see www.w3.org/TR/ws-arch):
-
- A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
While the W3C definition provides a useful starting point, it should be understood that the term “web services” is used herein in a broader sense, without limitation, for example, to the use of specific standards, formats, and protocols (e.g., WSDL, SOAP, XML, HTTP, etc.).
- A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
- A particular web service can be described as an abstract interface for a logically coherent set of operations that provides a basis for a (possibly transient) relationship between a service provider and a service requester.
- Of course, actual web services have concrete implementations. The provider's concrete implementation is sometimes referred to as the service (as distinguished from web service). The software that actually implements the functionality for the service provider is the provider agent and for the service requester, the requester agent. The person or organization that owns the agent is referred to as the provider entity or requester entity, as appropriate. When used by itself, requester or provider may refer to either the respective entity or agent depending on context.
- A web service exists to fulfill a purpose, and how this is achieved is specified by the mechanics and semantics of the particular web service message exchange. The mechanics refers to the precise machine-processable technical specifications that allow the message exchange to occur over a network. While the mechanics are precisely defined, the semantics might not be. The semantics refers to the explicit or implicit “contract,” in whatever form it exists, governing the understanding and overall expectations between the requester and provider entities for the web service.
- Web services are often modeled in terms of the interactions of three roles: (i) Service Provider; (ii) Service Requester; and (iii) Service Registry. In this model, a service provider “publishes” the information describing its web service to a service registry. A service requester “finds” this information via some discovery mechanism, and then uses this information to “bind” to the service provider to utilize the service. Binding simply means that the requester will invoke the operations made available by the provider using the message formatting, data mapping, and transport protocol conventions specified by the provider in the published service description. The XML-based language used to describe this information is called Web Services Description Language (WSDL).
- A service provider offers access to some set of operations for a particular purpose described by a WSDL service description; this service description is published to a registry by any of a number of means so that the service may be discovered. A registry may be public or private within a specific domain.
- A service registry is software that responds to service search requests by returning a previously published service description. A service requester is software that invokes various operations offered by a provider according to the binding information specified in the WSDL obtained from a registry.
- The service registry may exist only conceptually or may in fact exist as real software providing a database of service descriptions used to query, locate, and bind to a particular service. But whether a requester actually conducts an active search for a service or whether a service description is statically or dynamically provided, the registry is a logically distinct aspect of the web services model. It is interesting to note that in a real world implementation, a service registry may be a part of the service requester platform, the service provider platform, or may reside at another location entirely identified by some well-known address or an address supplied by some other means.
- The WSDL service description supports loose coupling, often a central theme behind an SOA. While ultimately a service requester will understand the semantics of the interface of the service it is consuming for the purpose of achieving some desired result, the service description isolates a service interface from specific service binding information and supports a highly dynamic web services model.
- A service-oriented architecture can be built on top of many possible technology layers. As currently practiced, web services typically incorporate or involve aspects of the following technologies:
- HTTP—a standard application protocol for most web services communications. Although web services can be deployed over various network protocols (e.g., SMTP, FTP, etc), HTTP is the most ubiquitous, firewall-friendly transport in use. For certain applications, especially within an intranet, other network protocols may make sense depending on requirements; nevertheless, HTTP is a part of almost any web services platform built today.
- XML—a standard for formatting and accessing the content (and information about the content) of structured information. XML is a text-based standard for communicating information between web services agents. Note that the use of XML does not mean that message payloads for web services may not contain any binary data; but it does mean that this data will be formatted according to XML conventions. Most web services architectures do not necessarily dictate that messages and data be serialized to a character stream—they may just as likely be serialized to a binary stream where that makes sense—but if XML is being used, these streams will represent XML documents. That is, above the level of the transport mechanism, web service messaging will often be conducted using XML documents.
- Two XML subset technologies that are particularly important to many web services are XML Namespaces and XML Schema. XML-Namespaces are used to resolve naming conflicts and assert specific meanings to elements contained with XML documents. XML-Schema are used to define and constrain various information items contained within an XML document. Although it is possible (and optional) to accomplish these objectives by other means, the use of XML is probably the most common technique used today. The XML document format descriptions for web service documents themselves are defined using XML-Schema, and most real world web services operations and messages themselves will be further defined incorporating XML-Schema.
- SOAP—an XML-based standard for encapsulating instructions and information into a specially formatted package for transmission to and handling by other receivers. SOAP (Simple Object Access Protocol) is a standard mechanism for packaging web services messages for transmission between agents. Somewhat of a misnomer, its legacy is as a means of invoking distributed objects and in that respect it is indeed “simpler” than other alternatives; but the recent trend is to consider SOAP as an XML-based wire protocol for purposes that have transcended the original meaning of the acronym.
- SOAP defines a relatively lightweight convention for structuring messages and providing information about content. Each SOAP document contains an envelope that is divided into a header and a body. Although structurally similar, the header is generally used for meta-information or instructions for receivers related to the handling of the content contained in the body.
- SOAP also specifies a means of identifying features and the processing needed to fulfill the features' obligations. A Message Exchange Pattern (MEP) is a feature that defines a pattern for how messages are exchanged between nodes. A common MEP is request-response, which establishes a single, complete message transaction between a requesting and a responding node (see http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapsupmep.).
- WSDL—an XML-based standard for describing how to use a web service. From a WSDL perspective, a service is related to a set of messages exchanged between service requesters and providers. Messages are described in an abstract manner that can be mapped to specific protocols. The exchange of messages that invokes some functionality is called an operation. A specific set of operations defines an interface. An interface is tied to a concrete message format and protocol by a named binding. The binding (the mapping of an interface to a concrete protocol) is associated with a URI appropriate to the protocol, resulting in an endpoint. A collection of one or more related endpoints (mapping an interface to concrete protocols at specific URIs) comprises a service.
- These definitions map to specific WSDL elements:
-
Types container element for type definitions Message an abstract definition of the type of data being sent Operation an abstract description of an action based on a combination of input, output, and fault messages portType an abstract set of operations - an interface binding specification of a concrete protocol and data format for an interface (portType) port the combination of a binding and an actual network address - an endpoint service a collection of related ports (endpoints) - WSDL defines a common binding mechanism and then defines specific binding extensions for SOAP, HTTP GET/POST, and MIME. Thus, binding does not necessarily mean binding to a transport protocol directly, but to a specific wire format. The most common binding for web services is SOAP, although actual SOAP message exchanges generally occur over HTTP on port 80 (via an http://URI). However, an interface can be directly bound to HTTP; alternatively, for example, a binding for SOAP can use SMTP (via a mailto://URI). An implementation can even define its own wire format and use a custom binding extension.
- WSDL encourages maintainability and reusability by providing support for an <import> element. Using import, a WSDL document can be divided into separate pieces in ways that make sense to an organization. For a cohesive web services environment desiring some degree of separation between an interface definition and an implementation definition, the following separation into three documents is reasonable:
-
A schema (.xsd) document - the root node is <schema> and the namespace is “http://www.w3.org/2001/XMLSchema.” A service interface description containing what is considered the reusable portion <message> <portType> <binding> A service implementation definition containing the specific service end point <service> - WSDL interfaces are not exactly like Java (or IDL, or some other programming language) interfaces. For example, a Java interface declaration specifies a set of methods that must match at least a subset of the methods of a class claiming to implement that interface. More than one class can implement an interface, and each implementation can be different; but the method signatures (method name and any input or output types) generally must be identical. This is mandated by the language and enforced at compile time, runtime, or both.
- A WSDL interface is different, and more like an actual abstract class that alone is not fully useful. Various WSDL interfaces, or portTypes, of a single web service are logically related in the sense that the set of operation names should be identical as if the portType did, in fact, implement a specific contract defined somewhere else but no such element actually exists and there is no mechanism for enforcing portType symmetry. Each portType is generally named to identify the type of binding it supports even though a portType alone does not create a binding. The portType operations for related portTypes are named the same, but the input, output, and fault messages (if present) are mapped to specific messages that contain named parts also necessary for supporting a specific binding. This raises the point that messages themselves are not completely abstract. A web service may and often does need to define similar but distinct messages for the various bindings required.
- As will be illustrated below, by leveraging emerging web service and related standards, a system architecture can be developed that facilitates the creation of networked interoperable media-related services that utilize a variety of different protocols and interfaces across a wide range of hardware and software platforms and operating environments.
- 1.2. Roles
- Preferred embodiments of the present invention seek to enable, promote, and/or actively support a peer-to-peer environment in which peers can spontaneously offer a variety of functionality by exposing services. One embodiment of the framework discourages viewing peers as having a fixed set of capabilities; and instead encourages a model where a peer at any point in time is a participant in one or more roles.
- A role can be defined by a set of services that a given peer exposes in combination with a specific behavior pattern. At any given moment a NEMO-enabled node may act in multiple roles based on a variety of factors: its actual implementation footprint providing the functionality for supporting a given set of services, administrative configuration, information declaring the service(s) the peer is capable of exposing, and load and runtime policy on service interfaces.
- An explicit set of roles could be defined based on various different types of services. Over time, as common patterns of participation are determined and as new services are introduced, a more formal role categorization scheme could be defined. A preliminary set of roles that may be formalized over time could include the following:
- Client—a relatively simple role in which no services are exposed, and the peer simply uses services of other peers.
Authorizer—this role denotes a peer acting as a Policy Decision Point (PDP), determining if a requesting principal has access to a specified resource with a given set of pre-conditions and post-conditions.
Gateway—in certain situations a peer may not be able to directly discover or interact with other service providers, for reasons including: transport protocol incompatibility, inability to negotiate a trusted context, or lack of the processing capability to create and process the necessary messages associated with a given service. A gateway is a peer acting as a bridge to another peer in order to allow the peer to interact with a service provider. From the perspective of identity and establishing an authorized and trusted context for operation, the requesting peer may actually delegate to the gateway peer its identity and allow that peer to negotiate and make decisions on its behalf. Alternatively, the gateway peer may act as a simple relay point, forwarding or routing requests and responses.
Orchestrator—in situations where interaction with a set of service providers involves nontrivial coordination of services (possibly including transactions, distributed state management, etc.), it may be beyond a peer's capability to participate. An orchestrator is a specialization of the gateway role. A peer may request an orchestrator to act on its behalf, intervening to provide one or more services. The orchestrating peer may use certain additional NEMO components, such as an appropriately configured Workflow Collator in order to satisfy the orchestration requirements. - Given the goal of “providing instant gratification by satisfying a request for any media, in any format, from any source, at any place, at any time, on any device complying with any agreeable set of usage rules,” the following informal model illustrates how this goal can be achieved using embodiments of the NEMO framework. It will become apparent from the highest level of the model (without enumerating every aspect of how NEMO enables all of the media services that one can imagine) how NEMO enables lower-level services from different tiers in the model to be assembled into richer end-to-end media services.
- In one embodiment of this model there are four tiers of service components: 1) Content Authoring, Assembly, and Packaging services, 2) Web-based Content Aggregation and Distribution services, 3) Home Gateway services, and 4) Consumer Electronics devices.
- Each of these four tiers typically has different requirements for security, rights management, service discovery, service orchestration, user interface complexity, and other service attributes. The first two tiers fit very roughly into the models that we see for “traditional” web services, while the last two tiers fit more into what we might call a personal logical network model, with certain services of the home gateway being at the nexus between the two types of models. However, services for CE devices could occasionally appear in any of the tiers.
- One dilemma lies in the desire to specialize parts of the framework for efficiency of implementation, while being general enough to encompass an end-to-end solution. For example, a UDDI directory and discovery approach may work well for relatively static and centralized web services, but for a more dynamic transient merging of personal networks, discovery models such as those found in UPnP and Rendezvous may be more appropriate. Thus, in some embodiments multiple discovery standards are accommodated within the framework
- Similarly, when rights management is applied to media distribution through wholesale, aggregator, and retail distribution sub-tiers, there can be many different types of complex rights and obligations that need to be expressed and tracked, suggesting the need for a highly expressive and complex rights language, sophisticated content governance and clearing services, and a global trust model. However, rights management and content governance for the home gateway and CE device tiers may entail a different trust model that emphasizes fair use rights that are relatively straightforward from the consumer's point of view. Peer devices in a personal logical network may want to interact using the relatively simple trust model of that network, and with the ability to interact with peers across a wide area network using a global trust model, perhaps through proxy gateway services. At the consumer end, complexity arises from automated management of content availability across devices, some of which are mobile and intermittently intersect multiple networks. Thus, an effective approach to rights management, while enabling end-to-end distribution, might also be heterogeneous, supporting a variety of rights management services, including services that interpret expressions of distribution rights and translate them, in context, to individual consumer use rights in a transaction that is orchestrated with a sales transaction, or perhaps another event where a subscription right is exercised.
- 1.3. Logical Model
- In one embodiment, the system framework consists of a logically connected set of nodes that interact in a peer-to-peer (P2P) fashion. Peer-to-peer computing is often defined as the sharing of resources (such as hard drives and processing cycles) among computers and other intelligent devices. See http://www.intel.com/cure/peer.htm. Here, P2P may be viewed as a communication model allowing network nodes to symmetrically consume and provide services of all sorts. P2P messaging and workflow collation allow rich services to be dynamically created from a heterogeneous set of more primitive services. This enables examination of the possibilities of P2P computing when the shared resources are services of many different types, even using different service bindings.
- Different embodiments can provide a media services framework enabling stakeholders (e.g., consumers, content providers, device manufacturers, and service providers) to find one another, to interact, exchange value, and to cooperate in rich and dynamic ways. These different types of services range from the basic (discovery, notification, search, and file sharing) to more complex higher level services (such as lockers, licensing, matching, authorization, payment transaction, and update), and combinations of any or all of these.
- Services can be distributed across peer-to-peer communicating nodes, each providing message routing and orchestration using a message pump and workflow collator (described in greater detail below) designed for this framework.
- Nodes interact by making service invocation requests and receiving responses. The format and payload of the request and response messages are preferably defined in a standard XML schema-based web service description language (e.g., WSDL) that embodies an extensible set of data types enabling the description and composition of services and their associated interface bindings. Many of the object types in WSDL are polymorphic and can be extended to support new functionality. The system framework supports the construction of diverse communication patterns, ranging from direct interaction with a single service provider to a complex aggregation of a choreographed set of services from multiple service providers. In one embodiment, the framework supports the basic mechanisms for using existing service choreography standards (WSCI, BPEL, etc.), and also allows service providers to use their own conventions.
- The syntax of messages associated with service invocation are preferably described in a relatively flexible and portable manner, as are the core data types used within the system framework. In one embodiment, this is accomplished using WSDL to provide relatively simple ways for referencing semantic descriptions associated with described services.
- A service interface may have one or more service bindings. In such an embodiment, a node may invoke the interface of another node as long as that node's interface binding can be expressed in, e.g., WSDL, and as long as the requesting node can support the conventions and protocols associated with the binding. For example, if a node supports a web service interface, a requesting node may be required to support SOAP, HTTP, WS-Security, etc.
- Any service interface may be controlled (e.g., rights managed) in a standardized fashion directly providing aspects of rights management. Interactions between nodes can be viewed as governed operations.
- Virtually any type of device (physical or virtual) can be viewed as potentially NEMO-enabled, and able to implement key aspects of the NEMO framework. Device types include, for example, consumer electronics equipment, networked services, and software clients. In a preferred embodiment, a NEMO-enabled device (node) typically includes some or all of the following logical modules (discussed in greater detail below):
- Native Services API—the set of one or more services that the device implements. There is no requirement that a NEMO node expose any service directly or indirectly in the NEMO framework.
Native Service Implementation—the corresponding set of implementations for the native services API.
Service Adaptation Layer—the logical layer through which an exposed subset of an entity's native services is accessed using one or more discoverable bindings described in, e.g., WSDL.
Framework Support Library—components that provide support functionality for working with the NEMO Framework including support for invoking service interfaces, message processing, service orchestration, etc. - 1.4. Terminology
- In one embodiment, a basic WSDL profile defines a minimum “core” set of data types and messages for supporting interaction patterns and infrastructural functionality. Users may either directly, in an ad-hoc manner, or through some form of standardization process, define other profiles built on top of this core, adding new data and service types and extending existing ones. In one embodiment, this core profile includes definitions for some or all of the following major basic data types:
- Node—a representation of a participant in the system framework. A node may act in multiple roles including that of a service consumer and/or a service provider. Nodes may be implemented in a variety of forms including consumer electronic devices, software agents such as media players, or virtual service providers such as content search engines, DRM license providers, or content lockers.
Device—encapsulates the representation of a virtual or physical device.
User—encapsulates the representation of a client user.
Request—encapsulates a request for a service to a set of targeted Nodes.
Request Input—encapsulates the input for a Request.
Response—encapsulates a Response associated with a Request.
Request Result—encapsulates the Results within a Response associated with some Request.
Service—encapsulates the representation of a set of well-defined functionality exposed or offered by a provider Node. This could be, for example, low-level functionality offered within a device such as a cell phone (e.g. a voice recognition service), or multi-faceted functionality offered over the world-wide web (e.g. a shopping service). Services could cover a wide variety of applications, including DRM-related services such as client personalization and license acquisition.
Service Provider—an entity (e.g., a Node or Device) that exposes some set of Services. Potential Service Providers include consumer electronics devices, such as cell phones, PDAs, portable media players and home gateways, as well as network operators (such as cable head-ends), cellular network providers, web-based retailers and content license providers.
Service Interface—a well-defined way of interacting with one or more Services.
Service Binding—encapsulates a specific way to communicate with a Service, including the conventions and protocols used to invoke a Service Interface. These may be represented in a variety of well-defined ways, such as the WS-I standard XML protocol, RPC based on the WSDL definition, or a function invocation from a DLL.
Service Access Point (SAP)—encapsulates the functionality necessary for allowing a Node to make a Service Invocation Request to a targeted set of Service Providing Nodes, and receive a set of Responses.
Workflow Collator (WFC)—a Service Orchestration mechanism that provides a common interface allowing a Node to manage and process collections of Requests and Responses related to Service invocations. This interface provides the basic building blocks to orchestrate Services through management of the Messages associated with the Services. - In the context of a particular application, such as digital rights management (DRM), a typical profile might include various DRM-related services (described below) for the following set of content protection and governance objects, which represent entities in the system, protect content, associate usage rules with the content, and determine if access can be granted when requested:
- Content Reference—encapsulates the representation of a reference or pointer to a content item. Such a reference will typically leverage other standardized ways of describing content format, location, etc.
DRM Reference—encapsulates the representation of a reference or pointer to a description of a digital rights management format.
Link—links between entities (e.g., Nodes).
Content—represents media or other content.
Content Key—represents encryption keys used to encrypt Content.
Control—represents usage or other rules that govern interaction with Content.
Controller—represent associations between Control and ContentKey objects
Projector—represent associations between Content and ContentKey objects - In one embodiment, a core profile includes definitions for some or all of the following basic Services:
- Authorization—a request or response to authorize some participant to access a Service.
Governance—The process of exercising authoritative or dominating influence over some item (e.g., a music file, a document, or a Service operation), such as the ability to download and install a software upgrade. Governance typically interacts with Services providing functionality such as trust management, policy management, and content protection.
Message Routing—a Request or Response to provide message routing functionality, including the ability to have the Service Providing Node forward the message or collect and assemble messages.
Node Registration—a Request or Response to perform registration operations for a Node, thereby allowing the Node to be discovered through an Intermediate Node.
Node Discovery (Query)—a Request or Response related to the discovery of Nodes.
Notification—a Request or Response to send or deliver targeted Notification messages to a given set of Nodes.
Security Credential Exchange—a Request or Response related to allowing Nodes to exchange security related information, such as key pairs, certificates, or the like.
Service Discovery (Query)—a Request or Response related to the discovery of Services provided by some set of one or more Nodes.
Service Orchestration—The assembly and coordination of Services into manageable, coarser-grained Services, reusable components, or full applications that adhere to rules specified by a service provider. Examples include rules based on provider identity, type of Service, method by which Services are accessed, order in which Services are composed, etc.
Trust Management—provides a common set of conventions and protocols for creating authorized and trusted contexts for interactions between Nodes. In some embodiments, NEMO Trust Management may leverage and/or extend existing security specifications and mechanisms, including WS-Security and WS-Policy in the web services domain.
Upgrade—represents a Request or Response related to receiving a functionality upgrade.
In one embodiment, this service is purely abstract, with other profiles providing concrete representations. - 1.5. Illustrative Interaction Between Nodes
- As will be discussed in greater detail below, the basic logical interaction between two system nodes, a service requester and a service provider, typically includes the following sequence of events. From the perspective of the service requesting node:
- The service requesting node makes a service discovery request to locate any NEMO-enabled nodes that can provide the necessary service using the specified service bindings. A node may choose to cache information about discovered services. The interface/mechanism for service discovery between nodes can be just another service that a NEMO node chooses to implement.
- Once candidate service providing nodes are found, the requesting node may choose to dispatch a request to one or more of the service providing nodes based on a specific service binding.
- In one embodiment, two nodes that wish to communicate securely with each other will establish a trusted relationship for the purpose of exchanging WSDL messages. For example, they may negotiate a set of compatible trust credentials (e.g., X.500 certificates, device keys, etc.) that may be used in determining identity, verifying authorization, establishing a secure channel, etc. In some cases, the negotiation of these credentials may be an implicit property of the service interface binding (e.g., WS-Security if WS-I XML Protocol is used, or an SSL request between two well-known nodes). In other cases, the negotiation of trust credentials may be an explicitly separate step. In one embodiment, it is up to a given node to determine which credentials are sufficient for interacting with another node, and to make the decision that it can trust a given node.
- The requesting node creates the appropriate WSDL request message(s) that correspond to the requested service.
- Once the messages are created, they are dispatched to the targeted service providing node(s). The communication style of the request may, for example, be synchronous or asynchronous RPC style, or message-oriented based on the service binding. Dispatching of service requests and receiving of responses may be done directly by the device or through the NEMO Service Proxy. The service proxy (described below) provides an abstraction and interface for sending messages to other participants, and may hide certain service binding issues, such as compatible message formats, transport mechanisms, message routing issues, etc.
- After dispatching a request, the requesting node will typically receive one or more responses. Depending on the specifics of the service interface binding and the requesting node's preferences, the response(s) may be returned in a variety of ways, including, for example, an RPC-style response or a notification message. The response, en-route to the targeted node(s), may pass through other intermediate nodes that may provide a number of relevant services, including, e.g., routing, trust negotiation, collation and correlation functions, etc.
- The requesting node validates the response(s) to ensure it adheres to the negotiated trust semantics between it and the service providing node.
- Appropriate processing is then applied based on the message payload type and contents.
- From the perspective of the service providing node, the sequence of events typically would include the following:
- Determine if the requested service is supported. In one embodiment, the NEMO framework does not mandate the style or granularity of how a service interface maps as an entry point to a service. In the simplest case, a service interface may map unambiguously to a given service and the act of binding to and invoking it may constitute support for the service. However, in some embodiments a single service interface may handle multiple types of requests; and a given service type may contain additional attributes that need to be examined before a determination can be made that the node supports the specifically desired functionality.
- In some cases it may be necessary for the service provider to determine if it trusts the requesting node and to negotiate a set of compatible trust credentials. In one embodiment, regardless of whether the service provider determines trust, any policy associated with the service interface will still apply.
- The service provider determines and dispatches authorization request(s) to those node(s) responsible for authorizing access to the interface in order to determine if the requesting node has access. In many situations, the authorizing node and the service providing node will be the same entity, and the dispatching and processing of the authorization request will be local operations invoked through a lightweight service interface binding such as a C function entry point.
- Upon receiving the authorization response, if the requesting node is authorized, the service provider will fulfill the request. If not, an appropriate response message might be generated.
- The response message is returned based on the service interface binding and requesting node's preferences. En route to the requesting node, the message may pass through other intermediate nodes that may provide necessary or “value added” services. For example an intermediate node might provide routing, trust negotiation, or delivery to a notification processing node that can deliver the message in a way acceptable' to the requesting node. An example of a “value added” service is a coupon service that appends coupons to the message if it knows of the requesting node's interests.
- Consider a sample embodiment of the NEMO system framework, as illustrated in
FIG. 1 , implementing a DRM application. - As noted above, NEMO nodes may interact by making service invocation requests and receiving responses. The NEMO framework supports the construction of diverse and rich communication patterns ranging from a simple point to point interaction with a single service provider to a complex aggregation of a choreographed set of services from multiple service providers.
- In the context of
FIG. 1 , the NEMO nodes interact with one another to provide a variety of services that, in the aggregate, implement a music licensing system. Music stored in Consumer Music Locker 110 can be extracted byWeb Music Retailer 120 and provided to end users at their homes via theirEntertainment Home Gateway 130. Music from Consumer Music Locker 110 may include rules that govern the conditions under which such music may be provided toWeb Music Retailer 120, and subsequently to others for further use and distribution.Entertainment Home Gateway 130 is the vehicle by which such music (as well as video and other content) can be played, for example, on a user's home PC (e.g., via PC Software Video Player 140) or on a user's portable playback device (e.g., Portable Music Player 150). A user might travel, for example, withPortable Music Player 150 and obtain, via a wireless Internet connection (e.g., to Digital Rights License Service 160), a license to purchase additional songs or replay existing songs additional times, or even add new features toPortable Music Player 150 viaSoftware Upgrade Service 170. - NEMO nodes can interact with one another, and with other devices, in a variety of different ways. A NEMO host, as illustrated in
FIG. 2 a, is some type of machine or device hosting at least one NEMO node. A host may reside within apersonal area network 210 or at aremote location 220 accessible via the Internet. A host could, for example, be aserver 230, adesktop PC 240, alaptop 250, or a personaldigital assistant 260. - A NEMO node is a software agent that can provide services to other nodes (such as
host 235 providing a 3rd party web service) as well as invoke other nodes' services within the NEMO-managed framework. Somenodes 270 are tethered to another host via a dedicated communication channel, such as Bluetooth. Thesehosts - As illustrated in
FIG. 2 b, a NEMO node can be a full peer within the local orpersonal area network 210. Nodes share the symmetric capability of exposing and invoking services; however, each node generally does not offer identical sets of services. Nodes may advertise and/or be specifically queried about the services they perform. - If an Internet connection is present, as shown in
FIG. 2 c, then local NEMO nodes (e.g., within personal area network 210) can also access the services ofremote nodes 220. Depending on local network configuration and policy, it is also possible for local and remote nodes (e.g., Internet-capable NEMO hosts 280) to interoperate as NEMO peers. - As illustrated in
FIG. 2 d, not all NEMO nodes may be on hosts capable of communicating with other hosts, whether local or remote. ANEMO host 280 can provide a gateway service through which one node can invoke the services of another, such astethered node 285 or nodes inpersonal area network 210. - As illustrated in
FIG. 2 e, anode 295 on a tethered device may access the services of other nodes via a gateway, as discussed above. It may also be accessed by other nodes via a proxy service on anotherhost 290. The proxy service creates a virtual node running on the NEMO host. These proxy nodes can be full NEMO peers. - As illustrated in
FIG. 2 f, a NEMO host may provide dedicated support for tethered devices via NEMO node adapters. Aprivate communication channel 296 is used between host/NEMO device adapter 297 andtethered node 298 using any suitable protocol.Tethered node 298 does not see, nor is it visible to, other NEMO peer nodes. - We next consider exemplary digital rights management (DRM) functionality that can be provided by NEMO-enabled devices in certain embodiments, or that can be used outside the NEMO context. As previously described, one of the primary goals of a preferred embodiment of the NEMO system framework is to support the development of secure, interoperable interconnections between media-related services spanning both commercial and consumer-oriented network tiers. In addition to service connectivity, interoperability between media-related services will often require coordinated management of usage rights as applied to the content available through those services. NEMO services and the exemplary DRM engine described herein can be used in combination to achieve interoperability that allows devices based on the NEMO framework to provide consumers with the perception of a seamless rendering and usage experience, even in the face of a heterogeneous DRM and media format infrastructure.
- In the context of a DRM application, as illustrated in
FIG. 3 , a network of NEMO-enabled DRM devices may include content provider/server 310, which packages content for other DRM devices, as well asconsumer PC player 330 and consumer PC packager/player 320, which can not only play protected content, but can also package content for delivery toportable device 340. - Within each DRM device, the DRM engine performs specific DRM functions (e.g., enforcing license terms, delivering keys to the host application, etc.), and relies on the host application for those services which can be most effectively provided by the host, such as encryption, decryption, and file management.
- As will be discussed in greater detail below, in one embodiment the DRM engine includes a virtual machine (VM) designed to determine whether certain actions on protected content are permissible. This Control VM can be implemented as a simple stack-based machine with a minimal set of instructions. In one embodiment, it is capable of performing logical and arithmetic calculations, as well as querying state information from the host environment to check parameters such as system time, counter state, and so forth.
- In one embodiment, the DRM engine utilizes a graph-based algorithm to verify relationships between entities in a DRM value chain.
FIG. 4 illustrates a conceptual embodiment of such a graph. The graph comprises a collection of nodes or vertices, connected by links. Each entity in the system can be represented by a vertex object. Only entities that need to be referenced by link objects, or be the recipient of cryptographically targeted information, need to have corresponding vertex objects. In one embodiment, a vertex typically represents a user, a device, or a group. Vertex objects also have associated attributes that represent certain properties of the entity associated with the vertex. - For example,
FIG. 4 shows two users (Xan and Knox), two devices (the Mac and a portable device), and several entities representing groups (members of the Carey family, members of the public library, subscribers to a particular music service, RIAA-approved devices, and devices manufactured by a specific company). Each of these has a vertex object associated with it. - The semantics of the links may vary in an application-specific manner. For example, the directed edge from the Mac vertex to the Knox vertex may mean that Knox is the owner of the Mac. The edge from Knox to Public Library may indicate that Knox is a member of the Public Library. In one embodiment the DRM engine does not impose or interpret these semantics—it simply ascertains the existence or non-existence of paths within the graph. This graph of vertices can be considered an “authorization” graph in that the existence of a path or relationship (direct or indirect) between two vertices may be interpreted as an authorization for one vertex to access another vertex.
- For example, because Knox is linked to the Carey family and the Carey family is linked to the Music Service, there is a path between Knox and the Music Service. The Music Service vertex is considered reachable from another vertex when there is a path from that vertex to the Music Service. This allows a control to be written that allows permission to access protected content based on the condition that the Music Service be reachable from the portable device in which the application that requests access (e.g., a DRM client host application) is executing.
- For example, a content owner may create a control program to be interpreted by the Control VM that allows a particular piece of music to be played if the consuming device is owned by a member of the Public Library and is RIAA-approved. When the Control VM running on the device evaluates this control program, the DRM engine determines whether links exist between Portable Device and Public Library, and between Portable Device and RIAA Approved. The edges and vertices of the graph may be static and built into devices, or may be dynamic and discovered through services communicating with the host application.
- By not imposing semantics on the vertices and links, the DRM engine can enable great flexibility. The system can be adapted to many usage models, from traditional delegation-based policy systems to authorized domains and personal area networks.
- In one embodiment, the DRM client can also reuse the authorization graph for content protection key derivation. System designers may chose to allow the existence of a link to also indicate the sharing of certain cryptographic information. In such cases, the authorization graph can be used to derive content keys without explicit cryptographic retargeting to consuming devices.
- 3.1. Overview
- Any type of device (physical or virtual), including consumer electronics equipment, networked services, or software clients, can potentially be NEMO-enabled, which means that the device's functionality may be extended in such a way as to enable participation in the NEMO system. In one embodiment, a NEMO-enabled device (node) is conceptually comprised of certain standard modules, as illustrated in
FIG. 5 a. -
Native Services API 510 represents the logical set of one or more services that the device implements. There is no requirement that a NEMO node expose any service directly or indirectly. Native Service Implementation 520 represents the corresponding set of implementations for the native services API. -
Service Access Point 530 provides support for invoking exposed service interfaces. It encapsulates the functionality necessary for allowing a NEMO node to make a service invocation request to a targeted set of service-providing NEMO nodes and to receive a set of responses. NEMO-enabled nodes may use diverse discovery, name resolution, and transport protocols, necessitating the creation of a flexible and extensible communication API. The Service Access Point can be realized in a variety of ways tailored to a particular execution environment and application framework style. One common generic model for its interface will be an interface capable of receiving XML messages in some form and returning XML messages. Other models with more native interfaces can also be supported. - NEMO
Service Adaptation Layer 540 represents an optional layer through which an exposed subset of an entity's native services are accessed using one or more discoverable bindings. It provides a level of abstraction above the native services API, enabling a service provider to more easily support multiple types of service interface bindings. In situations where a service adaptation layer is not present, it may still be possible to interact with the service directly through theService Access Point 530 if it supports the necessary communication protocols. - The
Service Adaptation Layer 540 provides a common way for service providers to expose services, process requests and responses, and orchestrate services in the NEMO framework. It is the logical point at which services are published, and provides a foundation on which to implement other specific service interface bindings. - In addition to providing a common way of exposing a service provider's native services to other NEMO-enabled nodes,
Service Adaptation Layer 540 also provides a natural place on which to layer components for supporting additionalservice interface bindings 560, as illustrated inFIG. 5 b. By supporting additional service interface bindings, a service provider increases the likelihood that a compatible binding will be able to be negotiated and used either by a Service Access Point or through some other native API. - Referring back to
FIG. 5 a,Workflow Collator 550 provides supporting management of service messages and service orchestration. It provides a common interface allowing a node to manage and process collections of request and response messages. This interface in turn provides the basic building blocks to orchestrate services through management of the messages associated with those services. This interface typically is implemented by a node that supports message routing functionality as well as the intermediate queuing and collating of messages. - In some embodiments, the NEMO framework includes a collection of optional support services that facilitate an entity's participation in the network. Such services can be classified according to various types of functionality, as well as the types of entities requiring such services (e.g., services supporting client applications, as opposed to those needed by service providers). Typical supporting services include the following:
- WSDL Formatting and Manipulation Routines—provide functionality for the creation and manipulation of WSDL-based service messages.
Service Cache—provides a common interface allowing a node to manage a collection of mappings between discovered nodes and the services they support.
Notification Processor Interface—provides a common service provider interface for extending a NEMO node that supports notification processing to some well-defined notification processing engine.
Miscellaneous Support Functionality—including routines for generating message IDs, timestamps, etc. - 3.2. Basic Node Interaction
- Before examining the individual architectural elements of NEMO nodes in greater detail, it is helpful to understand the manner by which such nodes interact and communicate with one another. Diverse communication styles are supported, ranging from synchronous and asynchronous RPC-style communication, to one-way interface invocations and client callbacks.
- Asynchronous RPC Delivery Style—this model is particularly appropriate if there is an expectation that fulfilling the request will take an extended period of time and the client does not want to wait. The client submits a request with the expectation that it will be processed in an asynchronous manner by any service-providing nodes. In this case, the service-providing endpoint may respond indicating that it does not support this model, or, if the service-providing node does support this model, it will return a response that will carry a ticket that can be submitted to the given service-providing node in subsequent requests to determine if it has a response to the client's request.
- In one embodiment, any service-providing endpoint that does support this model is obligated to cache responses to pending client requests based on an internal policy. If a client attempts to redeem a ticket associated with such a request and no response is available, or the response has been thrown away by the service-providing node, then an appropriate error response is returned. In this embodiment, it is up to the client to determine when it will make such follow-on requests in attempting to redeem the ticket for responses.
- Synchronous RPC Delivery Style—the client submits a request and then waits for one or more responses to be returned. A service-providing NEMO-enabled endpoint may respond indicating that it does not support this model.
- Message-Based Delivery Style—the client submits a request indicating that it wants to receive any responses via a message notification associated with one or more of its notification handling service interfaces. A service-providing NEMO-enabled endpoint may respond indicating that it does not support this model.
- From the client application's perspective, none of the interaction patterns above necessitates an architecture that must block and wait for responses, or must explicitly poll. It is possible to use threading or other platform-specific mechanisms to model both blocking and non-blocking semantics with the above delivery style mechanisms. Also, none of the above styles is intended to directly address issues associated with the latency of a given communication channel—only potential latency associated with the actual fulfillment of a request. Mechanisms to deal with the issues associated with communication channel latency should be addressed in the specific implementation of a component such as the Service Access Point, or within the client's implementation directly.
- 3.3. Service Access Point
- As noted above, a Service Access Point (SAP) can be used as a common, reusable API for service invocation. It can encapsulate the negotiation and use of a transport channel. For example, some transport channels may require SSL session setup over TCP/IP, while some channels may only support relatively unreliable communication over UDP/IP, and still others may not be IP-based at all.
- A SAP can encapsulate the discovery of an initial set of NEMO nodes for message routing. For example, a cable set-top box may have a dedicated connection to the network and mandate that all messages flow through a specific route and intermediary. A portable media player in a home network may use UPnP discovery to find multiple nodes that are directly accessible. Clients may not be able, or may choose not, to converse directly with other NEMO nodes by exchanging XML messages. In this case, a version of the SAP may be used that exposes and uses whatever native interface is supported.
- In a preferred embodiment, the SAP pattern supports the following two common communication models (although combinations of the two, as well as others, may be supported): (i) Message Based (as discussed above)—where the SAP forms XML request messages and directly exchanges NEMO messages with the service provider via some interface binding; or (ii) Native—where the SAP may interact with the service provider through some native communication protocol. The SAP may internally translate to/from XML messages defined elsewhere within the framework.
- A sample interaction between two NEMO peer nodes is illustrated in
FIG. 6 a. Client node 610 interacts with service-providing node 660 using NEMO service access point (SAP) 620. In this example, web service protocols and standards are used both for exposing services and for transport. Service-providing node 660 uses its web services layer 670 (using, e.g., WSDL and SOAP-based messaging) to expose its services to clients such as node 610. Web services layer 630 of client node 610 creates and interprets SOAP messages, with help from mapping layer 640 (which maps SOAP messages to and from SAP interface 620) and trust management processing layer 650 (which could, for example, leverage WS-Security using credentials conveyed within SOAP headers). - Another example interaction between NEMO nodes is illustrated in
FIG. 6 b. Service-providingnode 682 interacts withclient node 684 usingSAP 686. In this example, service-providingnode 682 includes a different but interoperable trust management layer thanclient 684. In particular, service-providingnode 682 includes both a trust engine 688 and anauthorization engine 690. In this example, trust engine 688 might be generally responsible for performing encryption and decryption of SOAP messages, for verifying digital certificates, and for performing other basic cryptographic operations, whileauthorization engine 690 might be responsible for making higher-level policy decisions. In the example shown inFIG. 6 b,client node 684 includes atrust engine 692, but not an authorization engine. Thus, in this example,client node 684 might be capable of performing basic cryptographic operations and enforcing relatively simple policies (e.g., policies related to the level of message authenticity, confidentiality, or the like), but might rely onservice providing node 682 to evaluate and enforce higher order policies governing the client's use of, and interaction with, the services and/or content provided byservice providing node 682. It should be appreciated thatFIG. 6 b is provided for purposes of illustration and not limitation, and that in otherembodiments client node 684 might also include an authorization engine, as might be the case if the client needed to adhere to a set of obligations related to a specified policy. Thus, it can be seen that different NEMO peers can contain different parts of the trust management framework depending on their requirements.FIG. 6 b also illustrates that the communication link between nodes can be transport agnostic. Even in the context of a SOAP processing model, any suitable encoding of data and/or processing rules can be used. For example, the XML security model could be replaced with another security model that supported a different encoding scheme. - A Service Access Point may be implemented in a variety of forms, such as within the boundaries of a client (in the form of a shared library) or outside the boundaries of the client (in the form of an agent running in a different process). The exact form of the Service Access Point implementation can be tailored to the needs of a specific type of platform or client. From a client's perspective, use of the Service Access Point may be optional, although in general it provides significant utility, as illustrated below.
- The Service Access Point may be implemented as a static component supporting only a fixed set of service protocol bindings, or it may be able to support new bindings dynamically.
- Interactions involving the Service Access Point can be characterized from at least two perspectives—a client-side which the requesting participant uses, and a service-side which interacts with other NEMO-enabled endpoints (nodes).
- In one client-side embodiment, illustrated in
FIG. 7 a,Service Access Point 710 directly exchanges XML messages withclient 720.Client 720 forms requestmessages 740 directly and submits them toService Access Point 710, which generates and sends one ormore response messages 750 toclient 720, where they are collected, parsed and processed.Client 720 may also submit (when making requests) explicit set(s) ofservice bindings 730 to use in targeting the delivery of the request. These service bindings may have been obtained in a variety of ways. For example,client 720 can perform service-discovery operations and then select which service bindings are applicable, or it can use information obtained from previous responses. - In another client-side embodiment, illustrated in
FIG. 7 b,Service Access Point 760 directly supports anative protocol 770 ofclient 780.Service Access Point 760 will translate messages internally between XML and thatnative protocol 770, thereby enablingclient 780 to participate within the NEMO system. To effect such support, native protocol 770 (or a combination ofnative protocol 770 and the execution environment) must provide any needed information in some form toService Access Point 760, which generates an appropriate request and, if necessary, determines a suitable target service binding. - On the service-side, multiple patterns of interaction between a client's Service Access Point and service-providing NEMO-enabled endpoints can be supported. As with the client-side, the interaction patterns can be tailored and may vary based on a variety of criteria, including the nature of the request, the underlying communication network, and the nature of the application and/or transport protocols associated with any targeted service bindings.
- A relatively simple type of service-side interaction pattern is illustrated in
FIG. 7 c, in whichService Access Point 711 communicates directly with the desired service-providingnode 712 in a point-to-point manner. - Turning to
FIG. 7 d,Service Access Point 721 may initiate communication directly with (and may receive responses directly from) multiplepotential service providers 725. This type of interaction pattern may be implemented by relaying multiple service bindings from the client for use byService Access Point 721; or a broadcast or multicast network could be utilized byService Access Point 721 to relay messages. Based on preferences specified in the request,Service Access Point 721 may choose to collect and collate responses, or simply return the first acceptable response. - In
FIG. 7 e,Service Access Point 731 doesn't directly communicate with any targeted service-providingendpoints 735. Instead, requests are routed through anintermediate node 733 which relays the request, receives any responses, and relays them back toService Access Point 731. - Such a pattern of interaction may be desirable if
Service Access Point 731 is unable or unwilling to support directly any of the service bindings associated with service-providingendpoints 735, but can establish a relationship withintermediate node 733, which is willing to act as a gateway. Alternatively, the client may not be able to discover or otherwise determine the service bindings for any suitable service-providing nodes, but may be willing to allowintermediate node 733 to attempt to discover any suitable service providers. Finally,Service Access Point 731 may want to take advantage ofintermediate node 733 because it supports more robust collection and collating functionality, which in turn permits more flexible communication patterns betweenService Access Point 731 and service providers such asendpoint nodes 735. - In addition to the above basic service-side interaction patterns, combinations of such patterns or new patterns can be implemented within the Service Access Point. Although the Service Access Point is intended to provide a common interface, its implementation will typically be strongly tied to the characteristics of the communication models and associated protocols employed by given NEMO-enabled endpoints.
- In practice, the Service Access Point can be used to encapsulate the logic for handling the marshalling and un-marshaling of I/O related data, such as serializing objects to appropriate representations, such as an XML representation (with a format expressed in WSDL), or one that envelopes XML-encoded objects in the proper format.
- In a preferred embodiment, the SAP also encapsulates logic for communication via one or more supported application, session, and/or transport protocols, such as service invocation over HTTP using SOAP enveloping.
- Finally, in some embodiments, the SAP may encapsulate logic for providing message integrity and confidentiality, such as support for establishing SSL/TLS sessions and/or signing/verifying data via standards such as XML-Signature and XML-Encryption. When the specific address of a service interface is unknown or unspecified (for example, when invoking a service across multiple nodes based on some search criteria), the SAP may encapsulate the logic for establishing an initial connection to a default/initial set of NEMO nodes where services can be discovered or resolved.
- The following is an example, non-limiting embodiment of a high-level API description exported by one SAP embodiment:
- ServiceAccessPoint::Create(Environment[ ])→ServiceAccessPoint—this is a singleton interface that returns an initialized instance of a SAP. The SAP can be initialized based on an optional set of environmental parameters.
ServiceAccessPoint::InvokeService(Service Request Message, Boolean)→Service Response Message—a synchronous service invocation API is supported where the client (using WSDL) forms an XML service request message, and receives an XML message in response. The API also accept a Boolean flag indicating whether or not the client should wait for a response. Normally, the flag will be true, except in the case of messages with no associated response, or messages to which responses will be delivered back asynchronously via another channel (such as via notification). The resulting message may also convey some resulting error condition.
ServiceAccessPoint::ApplyIntegrityProtection(Boolean, Desc[ ])→Boolean—This API allows the caller to specify whether integrity protection should be applied, and to which elements in a message it should be applied.
ServiceAccessPoint::ApplyConfidentiality(Boolean, Descp [ ])→Boolean—This API allows the caller to specify whether confidentiality should be applied and to which objects in a message it should be applied. -
ServiceAccessPoint::SetKeyCallbacks( SigningKeyCallback, SignatureVerificationKeyCallback, EncryptionKeyCallback, DecryptionKeyCallback) → Boolean
As indicated in the previous APIs, when a message is sent or received it may contain objects which require integrity protection or confidentiality. This API allows the client to set up any necessary hooks between itself and the SAP to allow the SAP to obtain keys associated with a particular type of trust management operation. In one embodiment, the interface is based on callbacks supporting integrity protection through digital signing and verification, and confidentiality through encryption and decryption. In one embodiment, each of the callbacks is of the form: - KeyCallback(KeyDesc)→Key[ ]
- where KeyDesc is an optional object describing the key(s) required and a list of appropriate keys is returned. Signatures are validated as part of receiving response services messages when using the InvokeService( . . . ) API. If a message element fails verification, an XML message can be returned from InvokeService( . . . ) indicating this state and the elements that failed verification.
- 3.4. Service Adaptation Layer
- As noted above, the Service Adaptation Layer provides a common way for service providers to expose their services, process requests and generate responses for services, and orchestrate services in the NEMO framework. It also provides a foundation on which other specific service interface bindings can be implemented. In one embodiment, WSDL is used to describe a service's interface within the system.
- Such a service description might, in addition to defining how to bind to a service on a particular interface, also include a list of one or more authorization service providers that will be responsible for authorizing access to the service, a pointer to a semantic description of the purpose and usage of the service, and a description of the necessary orchestration for composite services resulting from the choreographed execution of one or more other services.
- In addition to serving as the logical point at which services are exposed, the Service Adaptation Layer also preferably encapsulates the concrete representations of the NEMO data types and objects specified in NEMO service profiles for platforms that are supported by a given participant. It also contains a mechanism for mapping service-related messages to the appropriate native service implementation.
- In one embodiment, the NEMO framework does not mandate how the Service Adaptation Layer for a given platform or participant is realized. In situations where a service-providing node does not require translation of its native service protocols i.e., exposing its services only to client nodes that can communicate via that native protocol then that service-providing node need not contain a Service Adaptation Layer.
- Otherwise, its Service Adaptation Layer will typically contain the following elements, as illustrated in
FIG. 8 : - Entry Points—a layer encapsulating the service interface entry points 810 and associated WSDL bindings. Through these access points, other nodes invoke services, pass parameter data, and collect results.
Message Processing Logic—a layer 820 that corresponds to the logic for message processing, typically containing a message pump 825 that drives the processing of messages, some type of XML data binding support 826, and low level XML parser and data representation support 827.
Native Services—a layer representing the native services available (onto which the corresponding service messages are mapped), including a native services API 830 and corresponding implementation 840. - 3.5. Workflow Collator
- In a preferred embodiment, a Workflow Collator (WFC) helps fulfill most nontrivial NEMO service requests by coordinating the flow of events of a request, managing any associated data including transient and intermediate results, and enforcing the rules associated with fulfillment. Examples of this type of functionality can be seen in the form of transaction coordinators ranging from simple transaction monitors in relational databases to more generalized monitors as seen in Microsoft MTS/COM+.
- In one embodiment, the Workflow Collator is a programmable mechanism through which NEMO nodes orchestrate the processing and fulfillment of service invocations. The WFC can be tailored toward a specific NEMO node's characteristics and requirements, and can be designed to support a variety of functionality ranging from traditional message queues to more sophisticated distributed transaction coordinators. A relatively simple WFC might provide an interface for storage and retrieval of arbitrary service-related messages. By building on this, it is possible to support a wide variety of functionality including (i) collection of service requests for more effective processing; (ii) simple aggregation of service responses into a composite response; (iii) manual orchestration of multiple service requests and service responses in order to create a composite service; and (iv) automated orchestration of multiple service requests and service responses in order to create a composite service.
- A basic service interaction pattern begins with a service request arriving at some NEMO node via the node's Service Adaptation Layer. The message is handed off to the WSDL Message Pump that initially will drive and in turn be driven by the WFC to fulfill the request and return a response. In even more complex scenarios, the fulfillment of a service request might require multiple messages and responses and the participation of multiple nodes in a coordinated fashion. The rules for processing requests may be expressed in the system's service description language or using other service orchestration description standards such as BPEL.
- When a message is given to the WFC, the WFC determines the correct rules for processing this request. Depending upon the implementation of the WFC, the service description logic may be represented in the form of a fixed state machine for a set of services that the node exposes or it may be represented in ways that support the processing of a more free form expression of the service processing logic.
- In a preferred embodiment the WFC architecture is modular and extensible, supporting plug-ins. In addition to interpreting service composition and processing rules, the WFC may need to determine whether to use NEMO messages in the context of initiating a service fulfillment processing lifecycle, or as input in the chain of an ongoing transaction. In one embodiment, NEMO messages include IDs and metadata that are used to make these types of determinations. NEMO messages also can be extended to include additional information that may be service transaction specific, facilitating the processing of messages.
- As discussed in greater detail below, notification services are directly supported by various embodiments of the NEMO system. A notification represents a message targeted at interested NEMO-enabled nodes received on a designated service interface for processing. Notifications may carry a diverse set of payload types for conveying information and the criteria used to determine if a node is interested in a notification is extensible, including identity-based as well as event-based criteria.
- In one embodiment, illustrated in
FIG. 9 a, a service-providingNEMO node 910 provides a service that requires an orchestration process by its Workflow Collator 914 (e.g., the collection and processing of results from two other service providers) to fulfill a request for that service fromclient node 940. - When NEMO-enabled
application 942 onclient node 940 initiates a request to invoke the service provided byservice provider 910,Workflow Collator 914 in turn generates messages to initiate its own requests (on behalf of application 942), respectively, to Service Provider “Y” 922 onnode 920 and Service Provider “Z” 932 onnode 930.Workflow Collator 914 then collates and processes the results from these two other service-providing nodes in order to fulfill the original request fromclient node 940. - Alternatively, a requested service might not require the services of multiple service-providing nodes; but might instead require multiple rounds or phases of communication between the service-providing node and the requesting client node. As illustrated in
FIG. 9 b, when NEMO-enabledapplication 942 onclient node 940 initiates a request to invoke the service provided byservice provider 910,Workflow Collator 914 in turn engages in multiple phases ofcommunication 950 withclient node 940 in order to fulfill the original request. For example,Workflow Collator 914 may generate and send messages to client node 940 (via Access Point 944), receive and process the responses, and then generate additional messages (and receive additional responses) during subsequent phases of communication, ultimately fulfilling the original request fromclient node 940. - In this scenario,
Workflow Collator 914 is used byservice provider 910 to keep track (perhaps based on a service-specific session ID or transaction ID as part of the service request) of which phase of the operation it is in with the client for correct processing. As noted above, a state machine or similar mechanism or technique could be employed to process these multiple phases ofcommunication 950. -
FIG. 9 c illustrates one embodiment of a relatively basic interaction, within service-providingnode 960, betweenWorkflow Collator 914 and Message Pump 965 (within the node's Service Adaptation Layer, not shown). As noted above,Workflow Collator 914 processes one ormore service requests 962 and generatesresponses 964, employing a storage andretrieval mechanism 966 to maintain the state of this orchestration process. In this simple example,Workflow Collator 914 is able to process multiple service requests and responses, which could be implemented with a fairly simple state machine. - For more complex processing, however,
FIG. 9 d illustrates a node architecture that can both drive or be driven in performing service orchestration. Such functionality includes the collection of multiple service requests, aggregation of responses into a composite response, and either manual or automated orchestration of multiple service requests and responses in order to create a composite service. - A variety of scenarios can be supported by the architecture surrounding
Workflow Collator 914 inFIG. 9 d. For example, by having a NEMO node combine its functionality with that of anexternal coordinator 970 that understands the semantics of process orchestration (such as a Business Process Language engine driven by a high level description of the business processes associated with services) or resource usage semantics (such as a Resource Description Framework engine which can be driven by the semantic meaning of resources in relationship to each other), it is possible to create more powerful services on top of simpler ones.Custom External BPL 972 and/orRDF 973 processors may leverage external message pump 975 to execute process descriptions via amanual orchestration process 966, i.e., one involving human intervention. - In addition to relying on a manually driven process that relies on an external coordinator working in conjunction with a NEMO node's message pump, it is also possible to create an architecture where modules may be integrated directly with
Workflow Collator 914 to support an automated form of service coordination andorchestration 968. For example, for regular types of service orchestration patterns, such as those represented in BPEL and EBXML and communicated in the web service bindings associated with a service interface,Workflow Collator 914 can be driven directly by a description and collection of request andresponse messages 967 that arrive over time. In this scenario, a composite response message is pushed toMessage Pump 965 only when the state machine associated with the given orchestration processor plug-in (e.g.,BPEL 982 or EBXML 983) has determined that it is appropriate. - Following is an embodiment of a relatively high-level API description exported by an embodiment of a NEMO Workflow Collator:
- WorkflowCollator:Create(Environment[ ])→WorkflowCollator—this is a singleton interface that returns an initialized instance of a WFC. The WFC can be initialized based on an optional set of environmental parameters.
WorkflowCollator:Store(Key[ ], XML Message)→Boolean—this API allows the caller to store a service message within the WFC via a set of specified keys.
WorkflowCollator:RetrieveByKey(Key[ ], XML Message)→XML Message[ ]—this API allows the caller to retrieve a set of messages via a set of specified keys. The returned messages are no longer contained within the WFC.
WorkflowCollatoc:PeekByKey(Key[ ], XML Message)→XML Message[ ]—this API allows the caller to retrieve a set of messages via a set of specified keys. The returned messages are still contained within the WFC.
WorkflowCollator::Clear( )→Boolean—this API allows the caller to clear any messages stored within the WFC. - As an alternative to the relatively rigid BPEL orchestration standard, another embodiment could permit a more ad hoc XML-based orchestration description e.g., for a more dynamic application, such as a distributed search. Consider the following description that could be interpreted by a NEMO Workflow Collator (and could possibly even replace an entire service given a sufficiently rich language):
-
<WSDL> <NEMO Orchestration Descriptor> <Control Flow> e.g., EXECUTE Service A; If result = Yes then Service B; Else Service C <Shared State/Context> e.g., Device State <Transactions> e.g., State, Rollback, etc <Trust/Authorization> Note that Trust not necessarily transitive - 3.6. Exemplary DRM Engine Architecture
- In the context of the various embodiments of the NEMO node architecture described above,
FIG. 10 illustrates the integration of a modular embodiment of aDRM Engine 1000 into a NEMO content consumption device, thereby facilitating its integration into many different devices and software environments. -
Host application 1002 typically receives a request to access a particular piece of content through itsuser interface 1004.Host application 1002 then sends the request, along with relevant DRM engine objects (preferably opaque to the host application), toDRM engine 1000.DRM engine 1000 may make requests for additional information and cryptographic services tohost services module 1008 through well-defined interfaces. For example,DRM engine 1000 may askhost services 1008 whether a particular link is trusted, or may ask that certain objects be decrypted. Some of the requisite information may be remote, in whichcase host services 1008 can request the information from networked services through aservice access point 1014. - Once
DRM engine 1000 has determined that a particular operation is permitted, it indicates this and returns any required cryptographic keys tohost services 1008 which, under the direction ofhost application 1002, relies oncontent services 1016 to obtain the desired content and manage its use.Host services 1008 might then initiate the process of media rendering 1010 (e.g., playing the content through speakers, displaying the content on a screen, etc.), coordinated withcryptography services 1012 as needed. - The system architecture illustrated in
FIG. 10 is a relatively simple example of how the DRM engine can be used in applications, but it is only one of many possibilities. For example, in other embodiments, the DRM engine can be integrated into packaging applications under the governance of relatively sophisticated policy management systems. Both client (content consumption) and server (content packaging) applications of the DRM engine, including descriptions of the different types of DRM-related objects relied upon by such applications, will be discussed below, following a description of one embodiment of the internal architecture of the DRM engine itself. -
DRM Engine 1100, illustrated inFIG. 11 , relies on a virtual machine,control VM 1110, for internal DRM processing (e.g., executing control programs that govern access to content) within a broad range of host platforms, utilizing host environment 1120 (described above, and in greater detail below) to interact with the node'shost application 1130 and, ultimately, other nodes within, e.g., the NEMO or other system. - In one embodiment,
control VM 1110 is a virtual machine used by an embodiment ofDRM Engine 1100 to execute control programs that govern access to content. Following is a description of the integration ofcontrol VM 1110 into the architecture ofDRM engine 1100, as well as some of the basic elements of the control VM, including details about its instruction set, memory model, code modules, and interaction withhost environment 1120 via system calls 1106. - In one embodiment,
control VM 1110 is a relatively small-footprint virtual machine that is designed to be easy to implement using various programming languages. It is based on a stack-oriented instruction set that is designed to be minimalist in nature, without much concern for execution speed or code density. However, it will be appreciated that, if execution speed and/or code density were issues in a given application, conventional techniques (e.g., data compression) could be used to improve performance. -
Control VM 1100 is suitable as a target for low or high level programming languages, and supports languages such as assembler, C, and FORTH. Compilers for other languages, such as Java or custom languages, could also be implemented with relative ease. -
Control VM 1110 is designed to be hosted withinDRM Engine 1100, includinghost environment 1120, as opposed to being run directly on a processor or in silicon.Control VM 1110 runs programs by executing instructions stored inCode Modules 1102. Some of these instructions can make calls to functions implemented outside of the program itself by making one ormore System Calls 1106, which are either implemented byControl VM 1110 itself, or delegated to HostEnvironment 1120. - Execution Model
-
Control VM 1110 executes instructions stored incode modules 1102 as a stream of byte code loaded inmemory 1104.Control VM 1110 maintains a virtual register called the program counter (PC) that is incremented as instructions are executed. The VM executes each instruction, in sequence, until the OP_STOP instruction is encountered, an OP_RET instruction is encountered with an empty call stack, or an exception occurs. Jumps are specified either as a relative jump (specified as a byte offset from the current value of PC), or as an absolute address. - Memory Model
- In one embodiment,
control VM 1110 has a relatively simple memory model.VM memory 1104 is separated into a data segment (DS) and a code segment (CS). The data segment is a single, flat, contiguous memory space, starting at address 0. The data segment is typically an array of bytes allocated within the heap memory ofhost application 1130 orhost environment 1120. For a given VM implementation, the size of the memory space is preferably fixed to a maximum; and attempts to access memory outside of that space will cause faults and terminate program execution. The data segment is potentially shared betweenseveral code modules 1102 concurrently loaded by the VM. The memory in the data segment can be accessed by memory-access instructions, which can be either 32-bit or 8-bit accesses. 32-bit memory accesses are accomplished using the big-endian byte order. No assumptions are made with regard to alignment between the VM-visible memory and the host-managed memory (host CPU virtual or physical memory). - In one embodiment, the code segment is a flat, contiguous memory space, starting at address 0. The code segment is typically an array of bytes allocated within the heap memory of
host application 1130 orhost environment 1120. -
Control VM 1110 may load several code modules, and all of the code modules may share the same data segment (each module's data is preferably loaded at a different address), but each has its own code segment (e.g., it is preferably not possible for a jump instruction from onecode module 1102 to cause a jump directly to code in another code module 1102). - Data Stack
- In a preferred embodiment, the VM has a notion of a data stack, which represents 32-bit data cells stored in the data segment. The VM maintains a virtual register called the stack pointer (SP). After reset, SP points to the end of the data segment, and the stack grows downward (when data is pushed onto the data stack, the SP registers are decremented). The 32-bit values on the stack are interpreted either as 32-bit addressed, or 32-bit signed, integers, depending on the instruction referencing the stack data.
- Call Stack
- In one embodiment,
control VM 1110 manages a call stack for making nested subroutine calls. The values pushed onto this stack cannot be read or written directly by the memory-access instructions, but are used indirectly by the VM when executing OP_JSR and OP_RET instructions. For a given VM profile, the size of this return address stack is preferably fixed to a maximum, which will allow a certain number of nested calls that cannot be exceeded. - Instruction Set
- In one embodiment,
control VM 1110 uses a relatively simple instruction set. Even with a limited number of instructions; however, it is still possible to express simple programs. The instruction set is stack-based: except for the OP_PUSH instruction, none of the instructions have direct operands. Operands are read from the data stack, and results are pushed onto the data stack. The VM is a 32-bit VM: all the instructions in this illustrative embodiment operate on 32-bit stack operands, representing either memory addresses or signed integers. Signed integers are represented using a 2s complement binary encoding. - An illustrative instruction set used in one embodiment is shown below:
-
OP CODE Name Operands Description OP_PUSH Push N (direct) Push a constant on the stack Constant OP_DROP Drop Remove top of stack OP_DUP Duplicate Duplicate top of stack OP_SWAP Swap Swap top two stack elements OP_ADD Add A, B Push the sum of A and B (A + B) OP_MUL Multiply A, B Push the product of A and B (A * B) OP_SUB Subtract A, B Push the difference between A and B (A − B) OP_DIV Divide A, B Push the division of A by B (A/B) OP_MOD Modulo A, B Push A modulo B (A % B) OP_NEG Negate A Push the 2s complement negation of A (−A) OP_CMP Compare A Push −1 if A negative, 0 if A is 0, and 1 is a positive OP_AND And A, B Push bit-wise AND of A and B (A & B) OP_OR Or A, B Push the bit-wise OR of A and B (A| B) OP_XOR Exclusive Or A, B Push the bit-wise eXclusive OR of A and B (A {circumflex over ( )} B) OP_NOT Logical A Push the logical negation of A (1 if Negate A is 0, and 0 if A is not 0) OP_SHL Shift Left A, B Push A logically shifted left by B bits (A << B) OP_SHR Shift Right A, B Push A logically shifted right by B bits (A >> B) OP_JSR Jump to A Jump to subroutine at absolute Subroutine address A OP_JSRR Jump to A Jump to subroutine at PC + A Subroutine (Relative) OP_RET Return from Return from subroutine Subroutine OP_BRA Branch A Jump to PC + A Always OP_BRP Branch if A, B Jump to PC + A if B > 0 Positive OP_BRN Branch if A, B Jump to PC + A if B > 0 Negative OP_BRZ Branch if A, B Jump to PC + A if B is 0 Zero OP_JMP Jump A Jump to A OP_PEEK Peek A Push the 32-bit value at address A OP_POKE Poke A, B Store the 32-bit value B at address A OP_PEEKB Peek Byte A Push the 8-bit value at address A OP_POKEB Poke Byte A, B Store the least significant bits of B at address A OP_PUSHSP Push Stack Push the value of SP Pointer OP_POPSP Pop Stack A Set the value of SP to A Pointer OP_CALL System Call A Perform System Call with index A OP_STOP Stop Terminate Execution - Module Format
- In one embodiment,
code modules 1102 are stored in an atom-based format that is essentially equivalent to the atom structure used in the MPEG-4 file format. An atom consists of 32 bits, stored as 4-octets in big-endian byte order, followed by a 4-octet type (usually octets that correspond to ASCII values of letters of the alphabet), followed by the payload of the atom (size-8 octets). - 3.7. DRM Client-Server Architecture: Content Consumption and Packaging
- As noted above, DRM client-side consuming applications (e.g., media players) consume DRM content (e.g., play a song, display a movie, etc.). DRM service-side packaging applications (typically residing on a server) package content (e.g., associate with the content relevant usage and distribution rights, cryptographic keys, etc.) targeted to DRM clients.
-
FIG. 12 a illustrates one embodiment of the main architectural elements of a DRM client.Host application 1200 interfaces with a device user (e.g., the owner of a music player) throughuser interface 1210. The user might, for example, request access to protected content and receive metadata along with the content (e.g., text displaying the name of the artist and song title, along with the audio for the song itself). -
Host application 1200, in addition to interacting withuser interface 1210, also performs various functions necessary to implement the user's request, which may include managing interaction with the other DRM client modules to which it delegates certain functionality. For example,host application 1200 may manage interaction with the file system to extract the requested content. Host application also preferably recognizes the protected content object format and issues a request to theDRM engine 1220 to evaluate the DRM objects that make up the license (e.g., by running the relevant control program) to determine whether permission to access the protected content should be granted. - If permission is granted,
Host Application 1200 might also need to verify required signatures and delegate tocrypto services 1230 any other general purpose cryptographic functions required byDRM engine 1220.DRM Engine 1220 is responsible for evaluating the DRM objects, confirming or denying permission, and providing the keys to hostapplication 1200 to decrypt the content. -
Host services 1240 providesDRM Engine 1220 with access to data managed by (as well as certain library functions implemented by)host application 1200.Host application 1200 interacts withcontent services 1250 to access the protected content, passing toDRM engine 1220 only that portion of the content requiring processing.Content services 1250 acquires the content from external media servers and stores and manages the content, relying on the client's persistent storage mechanisms. - Once the content is cleared for access,
host application 1200 interacts with media rendering engine 1260 (e.g., by delivering keys) to decrypt and render the content via the client's AV output facilities. Some of the information needed byDRM Engine 1220 may be available in-band with the content, and can be acquired and managed viacontent services 1250, while other information may need to be obtained through external NEMO DRM services or some other source. - In a preferred embodiment, all of the cryptographic operations (encryption, signature verification, etc.) are handled by
crypto services 1230, which interacts indirectly withDRM engine 1220 viahost services 1240, which forwards requests.Crypto services 1230 can also be used bymedia rendering engine 1260 to perform content decryption. - Turning to the service side,
FIG. 12 b illustrates an embodiment of the main architectural elements of an exemplary DRM service-side packaging node.Host application 1200 interfaces with a content packager (e.g., an owner or distributor of music content) throughuser interface 1210. The packager might, for example, provide content and licensing information tohost application 1200 so that the content can be protected (e.g., encrypted and associated with limited access rights) and distributed to various end user and intermediate content providing nodes. -
Host application 1200, in addition to interacting withuser interface 1210, can also perform various functions necessary to implement the packager's request, including, for example, managing interaction with the other DRM packaging modules to which it delegates certain functionality. For example, it may manage interaction withgeneral crypto services 1235 to encrypt the content. It may also create a content object that contains or references the content and contains or references a license (e.g., afterDRM packaging engine 1225 creates the DRM objects that make up the license). Metadata can be associated with the license that explains what the license is about in a human-readable way (e.g., for potential client users to view). - As noted above,
host application 1200 interacts with the user viauser interface 1210. It is responsible for getting information such as a content reference and the action(s) the packager wants to perform (e.g., who to bind the content to). It can also display information about the packaging process such as the text of the license issued and, if a failure occurs, the reason for this failure. Some information needed byhost application 1200 may require the use of NEMO Services 1270 (e.g., to leverage services such as authentication or authorization as well as membership). - In one embodiment,
host application 1200 delegates tomedia format services 1255 responsibility for managing all media format operations, such as transcoding and packaging. Generalcrypto services 1235 is responsible for issuing and verifying signatures, as well as encrypting and decrypting certain data. The request for such operations could be issued externally or fromDRM packaging engine 1225 viahost services 1240. - In one embodiment,
content crypto services 1237 is logically separated fromgeneral crypto services 1235 because it is unaware ofhost application 1200. It is driven bymedia format services 1255 at content packaging time with a set of keys previously issued by DRM packaging engine 1225 (all of which is coordinated by host application 1200). - 3.8. DRM Content Protection and Governance Objects
- In an illustrative scenario, a content provider uses a host application that relies on a DRM packager engine to create a set of objects that protect the content and govern its use, including conveying the information necessary for obtaining the content encryption keys. The term, license, is used to encompass this set of objects.
- In a preferred embodiment, the content and its license are logically separate, but are bound together by internal references using object IDs. The content and license are usually stored together, but could be stored separately if necessary or desirable. A license can apply to more than one item of content, and more than one license can apply to any single item of content.
-
FIG. 13 illustrates an embodiment of such a license, including the relationships among the set of objects discussed below. Note thatcontrol object 1320 andcontroller object 1330 are both signed objects in this embodiment, so that the DRM client engine can verify that the control information comes from a trusted source prior to providing the host application with permission to access the protected content. In this embodiment, all of these objects, with the exception ofcontent object 1300, are created by the DRM client engine. - Content object—
Content object 1300 represents theencrypted content 1304, using aunique ID 1302 to facilitate the binding between the content and its associated key.Content object 1300 is an “external” object. The format and storage of encrypted content 1304 (e.g., MP4 movie file, MP3 music track, etc.) is determined by the host application (or delegated to a service), based in part upon the type of content. The format of the content also provides support for associatingID 1302 withencrypted content 1304. The packager's host application encrypts the content in a format-dependent manner, and managescontent object 1300, using any available cryptosystem (e.g., using a symmetric cipher, such as AES). - ContentKey object—
ContentKey object 1310 represents the encrypted key data 1314 (including a unique encryption key(s), optionally stored internally within the object), and also has a correspondingunique ID 1312. Preferably, this key data, if contained withinContentKey object 1310, is itself encrypted so that it can only be identified by those authorized to decrypt the content.ContentKey object 1310 also specifies which cryptosystem was used to encrypt this key data. This cryptosystem, an embodiment of which is discussed in greater detail below, is referred to as the “key distribution system.” - Control object—
Control object 1320 includes and protects the control program (e.g., control byte code 1324) that represents the rules that govern the use of the keys used to encrypt and decrypt the content. It also includes ID 1322 so that it can be bound to the corresponding ContentKey object. As noted above,control object 1320 is signed so that the DRM client engine can verify the validity of the binding between theContentKey 1310 andcontrol 1320, as well as the binding between theContentKey ID 1312 and the encryptedkey data 1314. The validity of control byte code 1324 can optionally be derived by verifying a secure hash (e.g.,control hash 1338, if available) contained incontroller object 1330. - Controller object—
Controller object 1330 represents the binding between the keys and the rules governing their control, usingIDs 1312 and 1322, respectively, to bind theContentKey 1310 andcontrol 1320 objects.Controller object 1330 governs the use of protected content by controlling application of the rules to that content—i.e., by determining which control governs the use of whichContentKey object 1310.Controller object 1330 also contains ahash 1336 value for each of the ContentKey objects 1310 that it references, in order to prevent tampering with the binding between eachContentKey object 1310 and its corresponding encryptedkey data 1314. As noted above,controller objects 1330 are preferably signed (e.g., by a packager application that has a certificate allowing it to sign controller objects, using public key or symmetric key signatures, as discussed below) to enable verification of the validity of the binding between theContentKey 1310 andcontrol 1320 objects, as well as the binding between theContentKey ID 1312 and the encryptedkey data 1314. As also noted above,controller object 1330 also optionally containscontrol hash 1338, which allows the validity ofcontrol object 1320 to be derived without having to separately verify its signature. - Symmetric Key Signature—In a preferred embodiment, a symmetric key signature is the most common type of signature for controller objects 1330. In one embodiment, this type of signature is implemented by computing a MAC (Message Authentication Code) of the
controller object 1330, keyed with the same key as the key represented by theContentKey object 1310. - Public Key Signature—In a preferred embodiment, this type of signature is used when the identity of the signer of the
controller object 1330 needs to be asserted uniquely. This type of signature is implemented with a public key signature algorithm, signing with the private key of the principal who is asserting the validity of this object. When using this type of signature, the ContentKey binding information carried in thecontroller object 1330 preferably contains ahash 1336 of the key contained in theContentKey object 1310, concatenated with a fingerprint of the signing private key (typically a hash of the private key). This binding ensures that the signer of the object has knowledge of the key used to protect the content. - Protector object—
Protector object 1340 provides protected access to content by controlling the use of keys used to encrypt and decrypt that content.Protector object 1340 bindscontent object 1300 toContentKey object 1310 in order to associate protected content with its corresponding key(s). To accomplish this binding, it includesreferences IDs content 1300 andContentKey 1310. In one embodiment,protector object 1340 contains information not only as to which key was used to encrypt one or more content items, but also as to which encryption algorithm was employed. In one embodiment, ifcontent reference 1342 references more than onecontent object 1300,ContentKey reference 1344 may still reference only oneContentKey object 1310, indicating that all of those content items were encrypted using the same encryption algorithm and the same key. - 3.9. DRM Node and Link Objects
- While
FIG. 13 illustrates the content protection and governance objects created by DRM engines to control access to protected content,FIG. 14 illustrates the DRM objects that represent entities in the system (e.g., users, devices or groups), as well as the relationships among those entities. - While
FIG. 4 , discussed above, illustrates a conceptual embodiment of a node or authorization graph depicting these entities and their relationships,FIG. 14 illustrates two types of objects that implement an embodiment of this conceptual graph: vertex (or “node”) objects (1400 a and 1400 b), which represent entities and their attributes, and link objects (1420), which represent the relationships among node objects. In one embodiment, the DRM engine, by executing control programs, instigates one or more usage patterns involving these objects—e.g., encrypting a song and associating it with a license that restricts its distribution to particular individuals. Yet, the DRM engine in this embodiment does not specify, implicitly or explicitly, the semantics attached to these objects (e.g., to which individuals the song may be distributed). - In one embodiment this semantic context, referred to as a DRM profile, is defined within the attributes of the node objects themselves. A DRM profile may include descriptions of these entities and the various roles and identities they represent, typically expressed using node attributes (1401 a and 1401 b). As discussed above, a
link 1420 between two nodes 1400 a and 1400 b could represent various types of semantic relationships. For example, if one node was a “user” and the other was a “device,” then link 1420 might represent “ownership.” If the other node was a “user group” instead of a “device,” then link 1420 might represent “membership.”Link 1420 might be unidirectional in one scenario and bidirectional in another (e.g., representing two links between the same two nodes). - Node objects 1400 a and 1400 b also typically have object confidentiality protection asymmetric key pairs (e.g., private key 1405 a and public key 1406 a of node 1400 a, and private key 1405 b and public key 1406 b of node 1400 b) to limit confidential information to authorized portions of the node. Confidential information targeted at a node will be encrypted with that node's confidentiality protection public key. Optionally, a content protection asymmetric key pair (e.g., private key 1403 a and public key 1403 b of node 1400 a, and private key 1403 b and public key 1403 b of node 1400 b) can be used in conjunction with link objects when the system uses a ContentKey derivation system for ContentKey distribution, as discussed in greater detail below. Content items themselves may be protected with content protection symmetric keys, such as symmetric key 1402 a of node 1400 a and key 1402 b of node 1400 b.
- As noted above, in one embodiment link objects (e.g., link 1420) represent relationships between nodes. The semantics of these relationships can be stored in node attributes (e.g., 1401 a of node 1400 a and 1401 b of node 1400 b), referenced from within the link objects (e.g.,
node reference 1422 to node 1400 a andnode reference 1424 to node 1400 b). Link objects can also optionally contain cryptographic data (e.g., key derivation info 1426) that enables the link object to be used for ContentKey derivations, as discussed below. - In one embodiment the link object itself is a signed object, represented by a directed edge in a graph, such as in
FIG. 4 above. When there exists such a directed edge from one node (e.g., node X) to another (e.g., node Y), this “path” from node X to node Y indicates that node Y is “reachable” from node X. The existence of a path can be used by other DRM objects, e.g., as a condition of performing a particular function. A control object might check to determine whether a target node is reachable before it allows a certain action to be performed on its associated content object. - For example, if node D represents a device that wants to perform the “play” action on a content object, a control that governs this content object might test whether a certain node U representing a certain user is reachable from node D (e.g., whether that user is the “owner” of that device), and only allow the “play” action to be performed if that condition is satisfied. To determine if node U is reachable, the DRM engine can run a control program to determine whether there exists a set of link objects that can establish a path (e.g., a direct or indirect relationship) between node D and node U. As noted above, in one embodiment the DRM engine is unaware of the semantics of the relationship; it simply determines the existence of a path, enabling the host application, for example, to interpret this path as a conditional authorization, permitting access to protected content.
- In one embodiment the DRM engine verifies link objects before allowing them to be used to determine the existence of paths in the system node graph. The validity of a link object at any given time may depend upon the particular features of the certificate system (discussed below) used to sign link objects. For example, they may have limited “lifetimes” or be revoked or revalidated from time to time based on various conditions.
- Also, in one embodiment the policies that govern which entities can sign link objects, which link objects can be created, and the lifetime of link objects are not directly handled by the DRM engine. Instead, they may leverage the node attributes information. To facilitate the task of enforcing certain policies, the system may provide a way to extend standard certificate formats with additional constraint checking. These extensions make it possible to express validity constraints on certificates for keys that sign links, such that constraints (e.g., the type of nodes connected by the link, as well as other attributes), can be checked before a link is considered valid.
- Finally, in one embodiment the link object may contain cryptographic data that provides the user with the nodes' content protection keys for key distribution. That cryptographic data may, for example, contain, in addition to metadata, the private and/or symmetric content protection keys of the “from” node, encrypted with the content protection public key and/or the content protection symmetric key of the “to” node. For example, an entity that has been granted the ability to create link objects that link device nodes and user nodes under a certain policy may check to ensure that it only creates links between node objects that have attributes indicating they are indeed representing a device, and nodes that have attributes indicating that they represent a user.
- 3.10. DRM Cryptographic Keys
- An example embodiment of a DRM key distribution system is illustrated in
FIG. 15 . The basic principle behind the key distribution system shown inFIG. 15 is to use link objects to distribute keys in addition to their primary purpose of establishing relationships between node objects. - As noted above, a control object may contain a control program that determines whether a requested operation should be permitted. That control program may check to determine whether a specific node is reachable via a collection of link objects. The key distribution system shown in
FIG. 15 leverages that search through a collection of link objects to facilitate the distribution of a key such that it is available to the DRM engine that is executing the control program. - In one embodiment, each node object that uses the key distribution system has one or more keys. These keys are used to encrypt content keys and other nodes' key distribution keys. Link objects created for use in the same deployment contain some cryptographic data payload that allows key information do be derived when chains of links are processed by the DRM engine.
- With nodes and links carrying keys this way, given a collection of links (e.g., from a node A to a node B . . . to a node Z), any entity that has access to the private keys of node A also has access to the private keys of node Z. Having access to node Z's private keys gives the entity access to any content key encrypted with those keys.
- Node objects that participate in a key distribution system contain keys as part of their data. As illustrated in
FIG. 15 , in one embodiment each node (1500 a, 1500 b, and 1500 c) has three keys: - Public Key Kpub[N]—This is the public part of a pair of public/private keys for the public key cipher. In one embodiment this key (1505 a, 1505 b and 1505 c, respectively, in nodes 1500 a, 1500 b and 1500 c) comes with a certificate (discussed below) so that its credentials can be verified by entities that want to bind confidential information to it cryptographically.
Private Key Kpriv[N]—This is the private part of the public/private key pair. The entity that manages the node is responsible for ensuring that this private key (keys 1515 a, 1515 b and 1515 c, respectively, in nodes 1500 a, 1500 b and 1500 c) is kept secret. For that reason, in one embodiment this private key is stored and transported separately from the rest of the node information.
Symmetric Key Ks[N]—This key is used with a symmetric cipher (discussed below). Because this private key (keys 1525 a, 1525 b and 1525 c, respectively, in nodes 1500 a, 1500 b and 1500 c) is confidential, the entity that manages the node is responsible for keeping it secret. - The key distribution system illustrated in
FIG. 15 can be implemented using different cryptographic algorithms, though the participating entities will generally need to agree on a set of supported algorithms. In one embodiment, at least one public key cipher (such as RSA) and one symmetric key cipher (such as AES) are supported. - The following notation refers to cryptographic functions:
- Ep(kpub[N], M) means “the message M encrypted with the public key Kpub of node N, using a public key cipher”
Dp(Kpriv[N], M) means “the message M decrypted with the private key Kpriv of node N using a public key cipher”
Es(Ks[N], M) means “the message M encrypted with the symmetric key Ks of node N using a symmetric key cipher”
Ds(Ks[N], M) means “the message M decrypted with the symmetric key Ks of node N using a symmetric key cipher” - Targeting a “ContentKey” to a node means making that key available to the entities that have access to the private keys of that node. In one embodiment binding is done by encrypting the key using one or both of the following methods:
- Public Binding Create a ContentKey object that contains Ep(Kpub[N], CK)
Symmetric Binding Create a ContentKey object that contains Es(Ks[N], CK) - In this embodiment, symmetric binding is preferably used whenever possible, as it uses a less computationally intensive algorithm that is less onerous on the receiving entity. However, the entity (e.g., a content packager) that creates the ContentKey object may not always have access to Ks[N]. In that case, public binding can be used, as Kpub[N] should be available, as it is not confidential information. Kpub[N] will usually be made available to entities that need to target ContentKeys, accompanied by a certificate that can be inspected by the entity to decide whether Kpub[N] is indeed the key of a node that can be trusted to handle the ContentKey in accordance with some agreed-upon policy.
- To allow entities to have access to the distribution keys of all reachable nodes, in one embodiment link objects contain a “payload.” That payload allows any entity that has access to the private keys of the link's “from node” to also have access to the private keys of the link's “to node.” In this manner, an entity can decrypt any ContentKey targeted to a node that is reachable from its node.
- Thus, returning to
FIG. 15 , link 1530 a, which links node 1500 a to node 1500 b, contains a payload that is created by encrypting the private keys 1515 b and 1525 b of node 1500 b with either the symmetric key 1515 a of node 1500 a or, if unavailable (e.g., due to its confidentiality), with the public key 1525 a of node 1500 a. Similarly, link 1530 b, which links node 1500 b to node 1500 c, contains a payload that is created by encrypting the private keys 1515 c and 1525 c of node 1500 c with either the symmetric key 1515 b of node 1500 b or, if unavailable, with the public key 1525 b of node 1500 b. - When a DRM engine processes link objects, it processes the payload of each link to update an
internal chain 1550 of keys to which it has access. In one embodiment the payload of a link from node A to node B consists of either: - or
- Where {Ks[B], Kpriv[B} is a data structure containing Ks[B] and Kpriv[B].
- The public derivation information is used to convey the private keys of node B, Ks[B] and Kpriv[B], to any entity that has access to the private key of node A, Kpriv[A]. The symmetric derivation information is used to convey the private keys of node B, Ks[B] and Kpriv[B], to any entity that has access to the symmetric key of node A, Kpriv[A].
- Thus, with reference to
key chain 1550, an entity that has access to the private keys of node 1500 a (private key 1515 a and symmetric key 1525 a) enables the DRM engine to utilize theseprivate keys 1560 as a “first link” in (and starting point in generating the rest of)key chain 1550.Scuba keys 1560 are used to decrypt 1555 a the ContentKey object within link 1530 a (using private key 1515 a for public derivation if public binding via public key 1505 a was used, or symmetric key 1525 a for symmetric derivation if symmetric binding via symmetric key 1525 a was used), resulting in thenext link 1570 inkey chain 1550 i.e., the confidential keys of node 1500 b (private key 1515 b and symmetric key 1525 b). The DRM engine uses thesekeys 1570 in turn to decrypt 1555 b the ContentKey object within link 1530 b (using private key 1515 b for public derivation if public binding via public key 1505 b was used, or symmetric key 1525 b for symmetric derivation if symmetric binding via symmetric key 1525 b was used), resulting in thefinal link 1580 inkey chain 1550 i.e., the confidential keys of node 1500 c (private key 1515 c and symmetric key 1525 c). - Since, in one embodiment, the DRM engine can process links in any order, it may not be able to perform a key derivation at the time a link is processed (e.g., because the keys of the “from” node of that link have not yet been derived). In that case, the link is remembered, and processed again when such information becomes available (e.g., when a link is processed in which that node is the “to” node).
- 3.11. DRM Certificates
- As noted above, in one embodiment certificates are used to check the credentials associated with cryptographic keys before making decisions based on the digital signature created with those keys. In one embodiment, multiple certificate technologies can be supported, leveraging existing information typically available as standard elements of certificates, such as validity periods, names, etc. In addition to these standard elements, additional constraints can be encoded to limit potential usage of a certified key.
- In one embodiment this is accomplished by using key-usage extensions as part of the certificate-encoding process. The information encoded in such extensions can be used to enable the DRM engine to determine whether the key that has signed a specific object was authorized to be used for that purpose. For example, a certain key may have a certificate that allows it to sign only those link objects in which the link is from a node with a specific attribute, and/or to a node with another specific attribute.
- The base technology used to express the certificate typically is not capable of expressing such a constraint, as its semantics may be unaware of elements such as links and nodes. In one embodiment such specific constraints are therefore conveyed as key usage extensions of the basic certificate, including a “usage category” and a corresponding “constraint program.”
- The usage category specifies which type of objects a key is authorized to sign. The constraint program can express dynamic conditions based on context. In one embodiment a verifier that is being asked to verify the validity of such a certificate is required to understand the relevant semantics, though the evaluation of the key usage extension expression is delegated to the DRM engine. The certificate is considered valid only if the execution of that program generates a successful result.
- In one embodiment, the role of a constraint program is to return a boolean value—e.g., “true” indicating that the constraint conditions are met, and “false” indicating that they are not met. The control program may also have access to some context information that can be used to reach a decision. The available context information may depend upon the type of decision being made by the DRM engine when it requests the verification of the certificate. For example, before using the information in a link object, a DRM engine may verify that the certificate of the key that signed the object allows that key to be used for that purpose. When executing the constraint program, the environment of the DRM engine is populated with information regarding the link's attributes, as well as the attributes of the nodes referenced by that link.
- The constraint program embedded in the key usage extension is encoded, in one embodiment, as a code module (described above). This code module preferably exports at least one entry point named, for example,
- “EngineName.Certificate.<Category>.Check”, where Category is a name indicating which category of certificates need to be checked. Parameters to the verification program will be pushed onto the stack before calling the entry point. The number and types of parameters passed onto the stack depends on the category of certificate extension being evaluated.
- 4.1. Basic Node Interaction
- Having examined various embodiments of the principal architectural elements of the NEMO system, including embodiments in the context of DRM applications, we now turn to the NEMO system in operation—i.e., the sequence of events within and among NEMO nodes that establish the foundation upon which application-specific functionality can be layered.
- In one embodiment, before NEMO nodes invoke application-specific functionality, they go through a process of initialization and authorization. Nodes initially seek to discover desired services (via requests, registration, notification, etc.), and then obtain authorization to use those services (e.g., by establishing that they are trustworthy and that they satisfy any relevant service provider policies).
- This process is illustrated in
FIG. 16 , which outlines a basic interaction between a Service Provider 1600 (in this embodiment, with functionality shared between aService Providing Node 1610 and an Authorizing Node 1620) and a Service Requester 1630 (e.g., a client consumer of services). Note that this interaction need not be direct. Any number ofIntermediary Nodes 1625 may lie in the path between theService Requester 1630 and theService Provider 1600. The basic steps in this process, which will be described in greater detail below, are discussed from the perspectives of both theclient Service Requester 1630 andService Provider 1600. - From the perspective of the
Service Requester 1630, the logical flow of events shown inFIG. 16 is as follows: - Service Discovery—In one embodiment,
Service Requester 1630 initiates a service discovery request to locate any NEMO-enabled nodes that provide the desired service, and obtain information regarding which service bindings are supported for accessing the relevant service interfaces.Service Requester 1630 may choose to cache information about discovered services. It should be noted that the interface/mechanism for Service Discovery between NEMO Nodes is just another service a NEMO Node chooses to implement and expose. The Service Discovery process is described in greater detail below, including other forms of communication, such as notification by Service Providers to registered Service Requesters.
Service Binding Selection—Once candidate service-providing Nodes are found, the requesting Node can choose to target (dispatch a request to) one or more of the service-providing Nodes based on a specific service binding.
Negotiation of Acceptable Trusted Relationship with Service Provider—In one embodiment, before two Nodes can communicate in a secure fashion, they must be able to establish a trusted relationship for this purpose. This may include an exchange of compatible trust credentials (e.g. X.500 certificates, tokens, etc.) in some integrity-protected envelope that may be used to determine identity; and/or it may include establishing a secure channel, such as an SSL channel, based on certificates both parties trust. In some cases, the exchange and negotiation of these credentials may be an implicit property of the service interface binding (e.g. WS-Security if the WS-I XML Protocol is used when the interface is exposed as a web service, or an SSL request between two well-known nodes). In other cases, the exchange and negotiation of trust credentials may be an explicitly separate step. NEMO provides a standard and flexible framework allowing Nodes to establish trusted channels for communication. It is up to a given Node, based on the characteristics of the Node and on the characteristics of the service involved in the interaction, to determine which credentials are sufficient for interacting with another NEMO Node, and to make the decision whether it trusts a given Node. In one embodiment the NEMO framework leverages existing and emerging standards, especially in the area of security-related data types and protocols. For example, in one embodiment the framework will support using SAML to describe both credentials (evidence) given by service requestors to service providers when they want to invoke a service, as well as using SAML as a way of expressing authorization queries and authorization responses.
Creation of Request Message—The next step is for RequestingNode 1630 to create the appropriate request message(s) corresponding to the desired service. This operation may be hidden by the Service Access Point. As noted above, the Service Access Point provides an abstraction and interface for interacting with service providers in the NEMO framework, and may hide certain service invocation issues, such as native interfaces to service message mappings, object serialization/de-serialization, negotiation of compatible message formats, transport mechanisms or message routing issues, etc.
Dispatching of Request—Once the request message is created, it is dispatched to the targeted service-providing Node(s)—e.g.,Node 1610. The communication style of the request can be synchronous/asynchronous RPC style or message-oriented, based on the service binding and/or preferences of the requesting client. Interacting with a service can be done directly by the transmission and processing of service messages or done through more native interfaces through the NEMO Service Access Point.
Receiving Response Message(s)—After dispatching the request, RequestingNode 1610 receives one or more responses in reply. Depending on the specifics of the service interface binding and the preferences of RequestingNode 1610, the reply(s) can be returned in various ways, including an RPC-style response or notification message. As noted above, requests and replies can be routed to their targeted Node via other intermediary Node(s) 1625, which may themselves provide a number of services, including: routing, trust negotiation, collation and correlation functions, etc. All services in this embodiment are “standard” NEMO services described, discovered, authorized, bound to, and interacted with in the same consistent framework. The Service Access Point may hide message-level abstractions from the Node. For example from the Node's perspective, invocation of a service may seem like a standard function invocation with a set of simple fixed parameters.
Validation of Response re Negotiated Trust Semantics—In one embodiment, RequestingNode 1630 validates the response message to ensure that it adheres to the negotiated trust semantics between it and theService Providing Node 1610. This logic typically is completely encapsulated within the Service Access Point.
Processing of Message Payload—Finally, any appropriate processing is then applied based on the (application specific) message payload type and contents. - Following are the (somewhat similar) logical flow of events from the perspective of the Service Provider 1600:
- Service Support Determination—A determination is first made as to whether the requested service is supported. In one embodiment, the NEMO framework doesn't mandate the style or granularity of how a service interface maps as an entry point to a service. In the simplest case, a service interface maps unambiguously to a given service, and the act of binding to and invoking that interface constitutes support for the service. However, it may be the case that a single service interface handles multiple types of requests, or that a given service type contains additional attributes which need to be sampled before a determination can be made as to whether the Node really supports the specifically desired functionality.
Negotiation of Acceptable Trusted Relationship with Service Requester—In some cases, it may be necessary forService Provider 1600 to determine whether it trusts RequestingNode 1630, and establish a trusted communication channel. This process is explained in detail above.
Dispatch Authorization Request to Nodes Authorizing Access to Service Interface—Service Providing Node 1610 then determines whether RequestingNode 1630 is authorized or entitled to have access to the service, and, if so, under what conditions. This may be a decision based on local information, or on a natively supported authorization decision mechanism. If not supported locally,Service Providing Node 1610 may dispatch an authorization request(s) to a known NEMO authorization service provider (e.g., Authorizing Node 1620) that governs its services, in order to determine if the RequestingNode 1610 is authorized to have access to the requested services. In many situations, AuthorizingNode 1620 andService Providing Node 1610 will be the same entity, in which case the dispatching and processing of the authorizing request will be local operations invoked through a lightweight service interface binding such as a C function entry point. Once again, however, since this mechanism is itself just a NEMO service, it is possible to have a fully distributed implementation. Authorization requests can reference identification information and/or attributes associated with the NEMO Node itself, or information associated with users and/or devices associated with the Node.
Message Processing Upon Receipt of Authorization Response—Upon receiving the authorization response, if RequestingNode 1630 is authorized,Service Provider 1600 performs the necessary processing to fulfill the request. Otherwide, if RequestingNode 1630 is not authorized, an appropriate “authorization denied” response message can be generated.
Return Response Message—The response is then returned based on the service interface binding and the preferences of RequestingNode 1630, using one of several communication methods, including an RPC-style response or notification message. Once again, as noted above, requests and replies can be routed to their targeted Node via other Intermediary Node(s) 1625, which may themselves provide a number of services, including routing, trust negotiation, collation and correlation functions, etc. An example of a necessary service provided by anIntermediary Node 1625 might be delivery to a notification processing Node that can deliver the message in a manner known to RequestingNode 1630. An example of a “value added” service might be, for example, a coupon service which associates coupons to the response if it knows of the interests of RequestingNode 1630. - 4.2. Notification
- As noted above, in addition to both asynchronous and synchronous RPC-like communication patterns, where the client specifically initiates a request and then either waits for responses or periodically checks for responses through redemption of a ticket, some NEMO embodiments also support a pure messaging type of communication pattern based on the notion of notification. The following elements constitute data and message types supporting this concept of notification in one embodiment:
- Notification—a message containing a specified type of payload targeted at interested endpoint Nodes.
Notification Interest—criteria used to determine whether a given Node will accept a given notification. Notification interests may include interests based on specific types of identity (e.g., Node ID, user ID, etc.), events (e.g., Node discovery, service discovery, etc.), affinity groups (e.g., new jazz club content), or general categories (e.g., advertisements).
Notification Payload—the typed contents of a notification. Payload types may range from simple text messages to more complex objects.
Notification Handler Service Interface—the type of service provider interface on which notifications may be received. The service provider also describes the notification interests associated with the interface, as well as the acceptable payload types. A Node supporting this interface may be the final destination for the notification or an intermediary processing endpoint.
Notification Processor Service—a service that is capable of matching notifications to interested Nodes, delivering the notifications based on some policy.
Notification Originator—a Node that sends out a notification targeted to a set of interested Nodes and/or an intermediary set of notification processing Nodes. - The notification, notification interest, and notification payload are preferably extensible. Additionally, the notification handler service interface is preferably subject to the same authorization process as any other NEMO service interface. Thus, even though a given notification may match in terms of interest and acceptable payload, a Node may refuse to accept a notification based on some associated interface policy related to the intermediary sender or originating source of the notification.
-
FIG. 17 a depicts a set ofnotification processing Nodes 1710 discovering 1715 aNode 1720 that supports the notification handler service. As part of its service description,node 1720 designates its notification interests, as well as which notification payload types are acceptable. -
FIG. 17 b depicts how notifications can be delivered. Any Node could be the originating source as well as processor of the notification, and could be responsible for delivering the notification toNode 1720, which supports the notification handler service. Thus, Node 1710 a could be the originating notification processing Node; or such functionality might be split between Node 1710 c (originating source of notification) and Node 1710 b (processor of notification). Still another Node (not shown) might be responsible for delivery of the notification. Notification processors that choose to handle notifications from foreign notification-originating Nodes may integrate with a commercial notification-processing engine such as Microsoft Notification Services in order to improve efficiency. - 4.3. Service Discovery
- In order to use NEMO services, NEMO Nodes will need to first know about them. One embodiment of NEMO supports three dynamic discovery mechanisms, illustrated in
FIGS. 18 a-c: - Client Driven—a NEMO Node 1810 a (in
FIG. 18 a) explicitly sends out a request to some set of targeted Nodes (e.g., 1820 a) that support a “Service Query” service interface 1815 a, the request asking whether the targeted Nodes support a specified set of services. If requesting Node 1810 a is authorized, Service Providing Node 1820 a will send a response indicating whether it supports the requested interfaces and the associated service interface bindings. This is one of the more common interfaces that Nodes will support if they expose any services.
Node Registration—a NEMO Node 1810 b (inFIG. 18 b) can register its description, including its supported services, with other Nodes, such as Service Providing Node 1820 b. If a Node supports this interface 1815 b, it is willing to accept requests from other Nodes and then cache those descriptions based on some policy. These Node descriptions are then available directly for use by the receiving Node or by other Nodes that perform service queries targeted to Nodes that have cached descriptions. As an alternative to P2P registration, a Node could also utilize a public registry, such as a UDDI (Universal Discovery, Description and Integration) standard registry for locating services.
Event-Based—Nodes (such as Node 1810 c inFIG. 18 c) send out notifications 1815 c to Interested Nodes 1820 c (that are “notification aware” and previously indicated their interest), indicating a change in state (e.g., Node active/available), or a Node advertises that it supports some specific service. The notification 1815 c can contain a full description of the node and its services, or just the ID of the node associated with the event. Interested nodes may then choose to accept and process the notification. - 4.4. Service Authorization and the Establishment of Trust
- As noted above, in one embodiment, before a NEMO Node allows access to a requested service, it first determines whether, and under which conditions, the requesting Node is permitted access to that service. Access permission is based on a trust context for interactions between service requestor and service provider. As will be discussed below, even if a Node establishes that it can be trusted, a service providing Node may also require that it satisfy a specified policy before permitting access to a particular service or set of services.
- In one embodiment NEMO does not mandate the specific requirements, criteria, or decision-making logic employed by an arbitrary set of Nodes in determining whether to trust each other. Trust semantics may vary radically from Node to Node. Instead, NEMO provides a standard set of facilities that allow Nodes to negotiate a mutually acceptable trusted relationship. In the determination and establishment of trust between Nodes, NEMO supports the exchange of credentials (and/or related information) between Nodes, which can be used for establishing a trusted context. Such trust-related credentials may be exchanged using a variety of different models, including the following:
- Service-Binding Properties—a model where trust credentials are exchanged implicitly as part of the service interface binding. For example, if a Node 1920 a (in
FIG. 19 a) exposes a service in the form of an HTTP Post over SSL, or as a Web Service that requires a WS-Security XML Signature, then the actual properties of this service binding may communicate all necessary trust-related credentials 1915 a with a Requesting Node 1910 a.
Request/Response Attributes—a model where trust credentials are exchanged through WSDL request and response messages (seeFIG. 19 b) between a Requesting Node 1910 b and a Service Providing Node 1920 b, optionally including the credentials as attributes of the messages 1915 b. For example, digital certificates could be attached to, and flow along with, request and response messages, and could be used for forming a trusted relationship.
Explicit Exchange—a model where trust credentials are exchanged explicitly through a service-provider interface (1915 c inFIG. 19 c) that allows querying of information related to the trust credentials that a given node contains. This is generally the most involved model, typically requiring a separate roundtrip session in order to exchange credentials between a Requesting Node 1910 c and a Service Providing Node 1920 c. The service interface binding itself provides a mutually acceptable trusted channel for explicit exchange of credentials. - In addition to these basic models, NEMO can also support combinations of these different approaches. For example, the communication channel associated with a semi-trusted service binding may be used to bootstrap the exchange of other security-related credentials more directly, or exchanging security-related credentials (which may have some type of inherent integrity) directly and using them to establish a secure communication channel associated with some service interface binding.
- As noted above, trust model semantics and the processes of establishing trust may vary from entity to entity. In some situations, mutual trust between nodes may not be required. This type of dynamic heterogeneous environment calls for a flexible model that provides a common set of facilities that allow different entities to negotiate context-sensitive trust semantics.
- 4.5. Policy-Managed Access
- In one embodiment (as noted above), a service providing Node, in addition to requiring the establishment of a trusted context before it allows a requesting Node to access a resource, may also require that the requesting Node satisfy a policy associated with that resource. The policy decision mechanism used for this purpose may be local and/or private. In one embodiment, NEMO provides a consistent, flexible mechanism for supporting this functionality.
- As part of the service description, one can designate specific NEMO Nodes as “authorization” service providers. In one embodiment an authorization service providing Node implements a standard service for handling and responding to authorization query requests. Before access is allowed to a service interface, the targeted service provider dispatches an “Authorization” query request to any authorizing Nodes for its service, and access will be allowed only if one or more such Nodes (or a pre-specified combination thereof) respond indicating that access is permitted.
- As illustrated in
FIG. 20 , a RequestingNode 2010exchanges messages 2015 with aService Providing Node 2020, including an initial request for a particular service.Service Providing Node 2020 then determines whether RequestingNode 2010 is authorized to invoke that service, and thus exchangesauthorization messages 2025 with the authorizingNodes 2025 that manage access to the requested service, including an initial authorization request to theseNodes 2030. Based on the responses it receives,Service Providing Node 2020 then either processes and returns the applicable service response, or returns a response indicating that access was denied. - Thus, the Authorization service allows a NEMO Node to participate in the role of policy decision point (PDP). In a preferred embodiment, NEMO is policy management system neutral; it does not mandate how an authorizing Node reaches decisions about authorizations based on an authorization query. Yet, for interoperability, it is preferable that authorization requests and responses adhere to some standard, and be sufficiently extensible to carry a flexible payload so that they can accommodate different types of authorization query requests in the context of different policy management systems. In one embodiment, support is provided for at least two authorization formats: (1) a simple format providing a very simple envelope using some least common denominator criteria, such as input, a simple requestor ID, resource ID, and/or action ID, and (2) the standard “Security Assertion Markup Language” (SAML) format to envelope an authorization query.
- In one embodiment, an authorizing Node must recognize and support at least a predefined “simple” format and be able to map it to whatever native policy expression format exists on the authorizing Node. For other formats, the authorizing Node returns an appropriate error response if it does not handle or understand the payload of an “Authorization” query request. Extensions may include the ability for Nodes to negotiate over acceptable formats of an authorization query, and for Nodes to query to determine which formats are supported by a given authorizing service provider Node.
- 4.6. Basic DRM Node Interaction
- Returning to the specific NEMO instance of a DRM application,
FIG. 21 is a DRM Node (or Vertex) Graph that can serve to illustrate the interaction among DRM Nodes, as well as their relationships. Consider the following scenario in whichportable device 2110 is a content playback device (e.g., an iPod1). Nip1 is the Node that represents this device. Kip1 is the content encryption key associated with Nip1. “User” is the owner of the portable device, and Ng is the Node that represents the user. Kg is the content encryption key associated with Ng. - PubLib is a Public Library. Npl represents the members of this library, and Kpl is the content encryption key associated with Npl. ACME represents all the ACME-manufactured Music Players. Namp represents that class of devices, and Kamp is the content encryption key associated with this group.
- L1 is a link from Nip1 to Ng, which means that the portable device belongs to the user (and has access to the user's keys). L2 is a link from Ng to Npl, which means that the user is a member of the Public Library (and has access to its keys). L3 is a link from Nip1 to Namp, which means that the portable device is an ACME device (mere membership, as the company has no keys). L4 is a link from Npl to Napl, which is the Node representing all public libraries (and has access to the groupwide keys).
- C1 is a movie file that the Public Library makes available to its members. Kc1 is a key used to encrypt C1. GB[C1] (not shown) is the governance information for C1 (e.g., rules and associated information used for governing access to the content). E(a,b) means ‘b’ encrypted with key ‘a’.
- For purposes of illustration, assume that it is desired to set a rule that a device can play the content C1 as long as (a) the device belongs to someone who is a member of the library and (b) the device is manufactured by ACME.
- The content C1 is encrypted with Kc1. The rules program is created, as well as the encrypted content key RK[C1]=E(Kamp, E(Kpl, Kc1)). Both the rules program and RK[C1] can be included in the governance block for the content, GB[C1].
- The portable device receives C1 and GB[C1]. For example, both might be packaged in the same file, or received separately. The portable device received L1 when the user first installed his device after buying it. The portable device received L2 when the user paid his subscription fee to the Public Library. The portable device received L3 when it was manufactured (e.g., L3 was built in).
- From L1, L2 and L3, the portable device is able to check that Nip1 has a graph path to Ng (L1), Npl (L1+L2), and Namp (L3). The portable device wants to play C1. The portable device runs the rule found in GB[C1]. The rule can check that Nip1 is indeed an ACME device (path to Namp) and belongs to a member of the public library (path to Npl). Thus, the rule returns “yes”, and the ordered list (Namp, Npl).
- The portable device uses L1 to compute Kg, and then L2 to compute Kpl from Kg. The portable device also uses L3 to compute Kamp. The portable device applies Kpl and Kamp to RK[C1], found in GB[C1], and computes Kc1. It then uses Kc1 to decrypt and play C1.
- When Node keys are symmetric keys, as in the previous examples, the content packager needs to have access to the keys of the Nodes to which it wishes to “bind” the content. This can be achieved by creating a Node that represents the packager, and a link between that Node and the Nodes to which it wishes to bind rules. This can also be achieved “out of band” through a service, for instance. But in some situations, it may not be possible, or practical to use symmetric keys. In that case, it is possible to assign a key pair to the Nodes to which a binding is needed without shared knowledge. In that case, the packager would bind a content key to a Node by encrypting the content key with the target Node's public key. To obtain the key for decryption, the client would have access to the Node's private key via a link to that Node.
- In the most general case, the Nodes used for the rules and the Nodes used for computing content encryption keys need not be the same. It is natural to use the same Nodes, since there is a strong relationship between a rule that governs content and the key used to encrypt it, but it is not necessary. In some systems, some Nodes may be used for content protection keys that are not used for expressing membership conditions, and vice versa, and in some situations, two different graphs of Nodes can be used, one for the rules and one for content protection. For example, a rule could say that all members of group Npl can have access to content C1, but the content key Kc1 may not be protected by Kpl, but may instead by protected by the node key Kapl of node Napl, which represents all public libraries, not just Npl. Or a rule could say that you need to be a member of Namp, but the content encryption key could be bound only to Npl.
- 4.7. Operation of DRM Virtual Machine (VM)
- The discussion with respect to
FIG. 21 above described the operation of a DRM system at a high (Node and Link) level, including the formation and enforcement of content governance policies.FIG. 22 depicts anexemplary code module 2200 of a DRM engine's VM that implements the formation and enforcement of such content governance policies. - Four main elements of
illustrative Code Module 2200, shown inFIG. 22 , include: - pkCM Atom: The
pkCM Atom 2210 is the top-level Code Module Atom. It contains a sequence of sub-atoms.
pkDS Atom: ThepkDS Atom 2220 contains a memory image that can be loaded into the Data Segment. The payload of the Atom is a raw sequence of octet values.
pkCS Atom: ThepkCS Atom 2230 contains a memory image that can be loaded into the Code Segment. The payload of the Atom is a raw sequence of octet values.
pkEX Atom: ThepkEX Atom 2240 contains a list of export entries. Each export entry consists of a name, encoded as an 8-bit name size, followed by the characters of the name, including a terminating 0, followed by a 32-bit integer representing the byte offset of the named entry point (this is an offset from the start of the data stored in the pkCS Atom). - 4.7.1. Module Loader
- In one embodiment, the Control VM is responsible for loading Code Modules. When a Code Module is loaded, the memory image encoded in
pkDS Atom 2220 is loaded at a memory address in the Data Segment. That address is chosen by the VM Loader, and is stored in the DS pseudo-register. The memory image encoded in thepkCS Atom 2230 is loaded at a memory address in the Code Segment. That address is chosen by the VM Loader, and is stored in the CS pseudo-register. - 4.7.2. System Calls
- In one embodiment, Control VM Programs can call functions implemented outside of their Code Module's Code Segment. This is done through the use of the OP_CALL instruction, that takes an integer stack operand specifying the System Call Number to call. Depending on the System Call, the implementation can be a Control VM Byte Code routine in a different Code Module (for instance, a library of utility functions), directly by the VM in the VM's native implementation format, or delegated to an external software module, such as the VM's Host Environment.
- In one embodiment, several System Call Numbers are specified: SYS_NOP=0: This call is a no-operation call. It just returns (does nothing else). It is used primarily for testing the VM.
- SYS_DEBUG_PRINT=1: Prints a string of text to a debug output. This call expects a single stack argument, specifying the address of the memory location containing the null-terminated string to print.
SYS_FIND_SYSCALL_BY_NAME=2: Determines whether the VM implements a named System Call. If it does, the System Call Number is returned on the stack; otherwise the value −1 is returned. This call expects a single stack argument, specifying the address of the memory location containing the null-terminated System Call name that is being requested. - 4.7.3. System Call Numbers Allocation
- In one embodiment, the Control VM reserves System Call Numbers 0 to 1023 for mandatory System Calls (System Calls that have to be implemented by all profiles of the VM).
- System Call Numbers 16384 to 32767 are available for the VM to assign dynamically (for example, the System Call Numbers returned by SYS_FIND_SYSCALL_BY_NAME can be allocated dynamically by the VM, and do not have to be the same numbers on all VM implementations).
- 4.7.4. Standard System Calls
- In one embodiment, several standard System Calls are provided to facilitate writing Control Programs. Such standard system calls may include a call to obtain a time stamp from the host, a call to determine if a node is Reachable, and/or the like. System calls preferably have dynamically determined numbers (e.g., theft System Call Number can be retrieved by calling the SYS_FIND_SYSCALL_BY_NAME System Call with their name passed as the argument).
- 4.8. Interfaces Between DRM Engine Interface and Host Application
- Following are some exemplary high level descriptions of the types of interfaces provided by an illustrative DRM (client consumption) engine to a Host Application:
- Creates a session given a Host Application Context. The context object is used by the DRM engine to make callbacks into the application.
- This function should be called by the Host Application when it encounters certain types of objects in the media files that can be identified as belonging to the DRM subsystem. Such objects include content control programs, membership tokens, etc. The syntax and semantics of those objects is opaque to the Host Application.
- The host application calls this function when it needs to interact with a multimedia content file. The DRM engine returns a Content object that can be used subsequently for retrieving DRM information about the content, and interacting with such information.
- Returns DRM metadata about the content that is otherwise not available in the regular metadata for the file.
- The Host Application calls this function when it wants to interact with a Content object. The actionInfo parameter specifies what type of action the application needs to perform (e.g., Play), as well as any associated parameters, if necessary. The function returns an Action object that can then be used to perform the action and retrieve the content key.
- Returns information that is necessary for the decryption subsystem to decrypt the content.
- Checks whether the DRM subsystem will authorize the performance of this action (i.e., whether Action::Perform( ) would succeed).
- Performs the action, and carries out any consequences (with their side effects) as specified by the rule(s) that governs this action.
- Following are some exemplary high level descriptions of the type of interface provided by an illustrative Host Application to a DRM (client consumption) engine:
- Returns a virtual FileSystem object to which the DRM subsystem has exclusive access.
This virtual FileSystem will be used to store DRM state information. The data within this FileSystem is readable and writeable only by the DRM subsystem. - Returns the current date/time as maintained by the host system.
- Returns the unique ID of this host.
- Gives back to the host services a data object that may have been embedded inside a DRM object, but that the DRM subsystem has identified as being managed by the host (e.g., certificates).
- Checks the validity of a digital signature to a data object. Preferably, the signatureInfo object contains information equivalent to the information found in an XMLSig element. The Host Services are responsible for managing the keys and key certificates necessary to validate the signature.
HostContext::CreateCipher(cipherType, keyInfo)→Cipher
Creates a Cipher object that the DRM subsystem can use to encrypt and decrypt data. A minimal set of cipher types will preferably be defined, and for each a format for describing the key info required by the cipher implementation. - The Cipher object referred to above, used to encrypt data.
- The Cipher object referred to above, used to decrypt data.
- Creates a Digester object that the DRM subsystem can use to compute a secure hash over some data. A minimal set of digest types will be defined.
- The Digester object referred to above, used to compute the secure hash.
- The Digester object referred to above, used to obtain the secure hash computed by the DRM subsystem.
- Following are some exemplary high level descriptions of the type of interface provided by an illustrative DRM (service-side packaging) engine to a Host Application:
- Creates a session given a Host Application Context. The context object is used by the DRM Packaging engine to make callbacks into the application.
- The Host Application will call this function in order to create a Content object that will be associated with license objects in subsequent steps. Having more than one content reference in the contentReferences array implies that these are bound together in a bundle (one audio and one video track for example), and that the license issued should be targeted to these as one indivisible group.
- The drmInfo parameter specifies the metadata of the license that will be issued. The structure will be read and will act as a guideline to compute the license into bytecode for the VM.
Content::GetDRMObjects(format)→drmObjects
This function is called when the Host Application is ready to get the drmObjects that the DRM Packaging engine created. The format parameter will indicate the format expected for these objects (e.g., XML or binary atoms).
Content::GetKeys( )→keys[ ]
This function is called by the Host Application when it needs the keys in order to encrypt the content. In one embodiment there will be one key per content reference. - Following are some exemplary high level descriptions of the type of interface provided by an illustrative Host Application to a DRM (service-side packaging) engine:
- Returns a virtual FileSystem object to which the DRM subsystem has exclusive access. This virtual FileSystem would be used to store DRM state information. The data within this FileSystem should only be readable and writeable by the DRM subsystem.
- Returns the current date/time as maintained by the host system.
- Returns the unique ID of this host.
HostContext::PerformSignature(signatureInfo, data)
Some DRM objects created by the DRM Packaging engine will have to be trusted. This service, provided by the host, will be used to sign the specified object.
HostContext::CreateCipher(cipherType, keyInfo)→Cipher
Creates a Cipher object that the DRM Packaging engine can use to encrypt and decrypt data. This is used to encrypt the content key data in the ContentKey object. - The Cipher object referred to above, used to encrypt data.
- The Cipher object referred to above, used to decrypt data.
- Creates a Digester object that the DRM Packaging engine can use to compute a secure hash over some data.
- The Digester object referred to above, used to comput the secure hash.
- The Digester object referred to above, used to obtain the secure hash computed by the DRM subsystem.
- Generates a random number that can be used for generating a key.
- 5.1. Overview
- Having described the NEMO/DRM system from both an architectural and operational perspective, we now turn our attention to an illustrative collection of services, data types, and related objects (“profiles”) that can be used to implement the functionality of the system.
- As noted above, a preferred embodiment of the NEMO architecture employs a flexible and portable way of describing the syntax of requests and responses associated with service invocation, data types used within the framework, message enveloping, and data values exposed by and used within the NEMO framework. WSDL 1.1 and above provides sufficient flexibility to describe and represent a variety of types of service interface and invocation patterns, and has sufficient abstraction to accommodate bindings to a variety of different endpoint Nodes via diverse communication protocols.
- In one embodiment, we define a profile to be a set of thematically related data types and interfaces defined in WSDL. NEMO distinguishes a “Core” profile (which includes the foundational set of data types and service messages necessary to support fundamental NEMO Node interaction patterns and infrastructural functionality) from an application-specific profile, such as a DRM Profile (which describes the Digital Rights Management services that can be realized with NEMO), both of which are discussed below.
- It will be appreciated that many of the data types and services defined in these profiles are abstract, and should be specialized before they are used. Other profiles are built on top of the Core profile.
- 5.2. NEMO Profile Hierarchy
- In one embodiment, the definition of service interfaces and related data types is structured as a set of mandatory and optional profiles that build on one another and may be extended. The difference between a profile and a profile extension is a relatively subtle one. In general, profile extensions don't add new data types or service type definitions. They just extend existing abstract and concrete types.
-
FIG. 23 illustrates an exemplary profile hierarchy for NEMO and DRM functionality. The main elements of this profile hierarchy include: - Core Profile—At the base of this profile hierarchy lies
Core Profile 2300, which preferably shares both NEMO and DRM functionality. This is the profile on which all other profiles are based. It includes a basic set of generic types (discussed below) that serve as the basis for creating more complex types in the framework. Many of the types in the Core Profile are abstract and will need to be specialized before use.
Core Profile Extensions—Immediately aboveCore Profile 2300 are theCore Profile Extensions 2320, which are the primary specializations of the types inCore Profile 2300, resulting in concrete representations.
Core Services Profile—Also immediately aboveCore Profile 2300, theCore Services Profile 2310 defines a set of general infrastructure services, also discussed below. In this profile, the service definitions are abstract and will need to be specialized before use.
Core Services Profile Extensions—Building upon bothCore Profile Extensions 2320 andCore Services Profile 2310 are the CoreServices Profile Extensions 2330, which are the primary specializations of the services defined inCore Services Profile 2310, resulting in concrete representations.
DRM Profile—Immediately aboveCore Profile 2300 liesDRM Profile 2340, upon which other DRM-related profiles are based.DRM Profile 2340 includes a basic set of generic types (discussed below) that serve as the basis for creating more complex DRM-specific types. Many of the types inDRM Profile 2340 are abstract and will need to be specialized before use.
DRM Profile Extensions—Building uponDRM Profile 2340 are theDRM Profile Extensions 2350, which are the primary specializations of the types inDRM Profile 2340, resulting in concrete representations.
DRM Services Profile—Also building uponDRM Profile 2340 isDRM Services Profile 2360, which defines a set of general DRM services (discussed below). In this profile, the service definitions are abstract and need to be specialized before use.
Specific DRM Profile—Building upon bothDRM Profile Extensions 2350 andDRM Services Profile 2360 is theSpecific DRM Profile 2370, which is a further specialization of the DRM services defined inDRM Services Profile 2360. This profile also introduces some new types and further extends certain types specified inCore Profile Extensions 2320. - 5.3. NEMO Services and Service Specifications
- Within this profile hierarchy lies, in one embodiment, the following main service constructs (as described in more detail above):
- Peer Discovery—the ability to have peers in the system discover one another.
Service Discovery—the ability to discover and obtain information about services offered by different peers.
Authorization—the ability to determine if a given peer (e.g., a Node) is authorized to access a given resource (such as a service).
Notification—services related to the delivery of targeted messages, based on specified criteria, to a given set of peers (e.g., Nodes).
Following are definitions (also discussed above) of some of the main DRM constructs within this example profile hierarchy:
Personalization—services to obtain the credentials, policy, and other objects needed for a DRM-related endpoint (such as a CE device, music player, DRM license server, etc.) to establish a valid identity in the context of a specific DRM system.
Licensing Acquisition—services to obtain new DRM licenses.
Licensing Translation—services to exchange one new DRM license format for another.
Membership—services to obtain various types of objects that establish membership within some designated domain. - The NEMO/DRM profile hierarchy can be described, in one embodiment, as a set of Generic Interface Specifications (describing an abstract set of services, communication patterns, and operations), Type Specifications (containing the data types defined in the NEMO profiles), and Concrete Specifications (mapping abstract service interfaces to concrete ones including bindings to specific protocols). One embodiment of these specifications, in the form of Service Definitions and Profile Schemes, is set forth in Appendix 1 (C) hereto.
-
FIG. 24 illustrates a relatively simple example of an embodiment of NEMO in operation in the context of a consumer using a new music player to play a DRM-protected song. As shown below, however, even this simple example illustrates many different potential related application scenarios. This example demonstrates the bridging of discovery services—using universal plug and play (UPnP) based service discovery as a mechanism to find and link to a UDDI based directory service. It also details service interactions between Personal Area Network (PAN) and Wide Area Network (WAN) services, negotiation of a trusted context for service use, and provisioning of a new device and DRM service. - Referring to
FIG. 24 , a consumer, having bought anew music player 2400, desires to play a DRM-protected song.Player 2400 can support this DRM system, but needs to be personalized. In other words,Player 2400, although it includes certain elements (not shown) that render it both NEMO-enabled and DRM-capable, must first perform a personalization process to become part of this system. - Typically, a NEMO client would include certain basic elements illustrated in
FIGS. 5 a and 6 above, such as a Service Access Point to invoke other Node's services, Trust Management Processing to demonstrate that it is a trusted resource for playing certain protected content, as well as a Web Services layer to support service invocations and the creation and receipt of messages. As discussed below, however, not all of these elements are necessary to enable a Node to participate in a NEMO system. - In some embodiments, client nodes may also include certain basic DRM-related elements, as illustrated in
FIGS. 12 a and 13-15 above, such as a DRM client engine and cryptographic services (and related objects and cryptographic keys) to enable processing of protected content, including decrypting protected songs, as well as a media rendering engine to play those songs. Here, too, some such elements need not be present. For example, hadPlayer 2400 been a music player that was only capable of playing unprotected content, it might not require the core cryptographic elements present in other music players. - More specifically, in the example shown in
FIG. 24 ,Player 2400 is wireless, supports the UPnP and Bluetooth protocols, and has a set of X.509 certificates it can use to validate signatures and sign messages.Player 2400 is NEMO-enabled in that it can form and process a limited number of NEMO service messages, but it does not contain a NEMO Service Access Point due to resource constraints. -
Player 2400, however, is able to participate in a Personal Area Network (PAN) 2410 in the user's home, which includes a NEMO-enabled, Internet-connected,Home Gateway Device 2420 with Bluetooth and aNEMO SAP 2430. The UPnP stacks of bothPlayer 2400 andGateway 2420 have been extended to support a new service profile type for a “NEMO-enabled Gateway” service, discussed below. - When the user downloads a song and tries to play it,
Player 2400 determines that it needs to be personalized, and initiates the process. For example,Player 2400 may initiate a UPnP service request for a NEMO gateway onPAN 2410. It locates a NEMO gateway service, andGateway 2420 returns the necessary information to allowPlayer 2400 to connect to that service. -
Player 2400 then forms a NEMO Personalization request message and sends it to the gateway service. The request includes an X.509 certificate associated withPlayer 2400's device identity.Gateway 2420, upon receiving the request, determines that it cannot fulfill the request locally, but has the ability to discover other potential service providers. However,Gateway 2420 has a policy that all messages it receives must be digitally signed, and thus it rejects the request and returns an authorization failure stating the policy associated with processing this type of request. -
Player 2400, upon receiving this rejection, notes the reason for the denial of service and then digitally signs (e.g., as discussed above in connection withFIG. 15 ) and re-submits the request toGateway 2420, which then accepts the message. As previously mentioned,Gateway 2420 cannot fulfill this request locally, but can perform service discovery.Gateway 2420 is unaware of the specific discovery protocols itsSAP 2430 implementation supports, and thus composes a general attribute-based service discovery request based on the type of service desired (personalization), and dispatches the request viaSAP 2430. -
SAP 2430, configured with the necessary information to talk to UDDI registries, such as Internet-Based UDDI Registry 2440, converts the request into a native UDDI query of the appropriate form and sends the query.UDDI Registry 2440 knows of a service provider that supports DRM personalization and returns the query results.SAP 2430 receives these results and returns an appropriate response, with the necessary service provider information, in the proper format, toGateway 2420. -
Gateway 2420 extracts the service provider information from the service discovery response and composes a new request for Personalization based on the initial request on behalf ofPlayer 2400. This request is submitted toSAP 2430. The service provider information (in particular, the service interface description of Personalization Service 2450) reveals howSAP 2430 must communicate with a personalization service that exposes its service through a web service described in WSDL.SAP 2430, adhering to these requirements, invokesPersonalization Service 2450 and receives the response. -
Gateway 2420 then returns the response toPlayer 2400, which can use the payload of the response to personalize its DRM engine. At this point,Player 2400 is provisioned, and can fully participate in a variety of local and global consumer oriented services. These can provide full visibility into and access to a variety of local and remote content services, lookup, matching and licensing services, and additional automated provisioning services, all cooperating in the service of the consumer. As explained above, various decryption keys may be necessary to access certain protected content, assuming the consumer andPlayer 2400 satisfy whatever policies are imposed by the content provider. - Thus, a consumer using a personal media player at home can enjoy the simplicity of a CE device, but leverage the services provided by both gateway and peer devices. When the consumer travels to another venue, the device can rediscover and use most or all of the services available at home, and, through new gateway services, be logically connected to the home network, while enjoying the services available at the new venue that are permitted according to the various policies associated with those services. Conversely, the consumer's device can provide services to peers found at the new venue.
- Clearly, utilizing some or all of these same constructs (NEMO Nodes, SAPs, Service Adaptation Layers, various standards such as XML, WSDL, SOAP, UDDI, etc.), many other scenarios are possible, even within the realm of this DRM music player example. For example,
Player 2400 might have contained its own SAP, perhaps eliminating the need forGateway 2420.UDDI Registry 2440 might have been used for other purposes, such as locating and/or licensing music content. Moreover, many other DRM applications could be constructed, e.g., involving a licensing scheme imposing complex usage and distribution policies for many different types of audio and video, for a variety of different categories of users. Also, outside of the DRM context, virtually any other service-based applications could be constructed using the NEMO framework. - As another example, consider the application of NEMO in a business peer-to-peer environment. Techniques for business application development and integration are quickly evolving beyond the limits of traditional tools and software development lifecycles as practiced in most IT departments. This includes the development of word processing documents, graphic presentations, and spreadsheets. While some would debate whether these documents in their simplest form represent true applications, consider that many forms of these documents have well defined and complex object models that are formally described. Such documents or other objects might include, for example, state information that can be inspected and updated during the lifecycle of the object, the ability for multiple users to work on the objects concurrently, and/or additional arbitrary functionality. In more complicated scenarios, document-based information objects can be programmatically assembled to behave like full-fledged applications.
- Just as with traditional software development, these types of objects can also benefit from source control and accountability. There are many systems today that support document management, and many applications directly support some form of document control. However most of these systems in the context of distributed processing environments exhibit limitations, including a centralized approach to version management with explicit check-in and checkout models, and inflexible (very weak or very rigid) coherence policies that are tied to client rendering applications or formats particularly within the context of a particular application (e.g., a document).
- Preferred embodiments of NEMO can be used to address these limitation by means of a P2P policy architecture that stresses capability discovery and format negotiation. It is possible to structure the creation of an application (e.g., a document) in richer ways, providing multiple advantages. Rich policy can be applied to the objects and to the structure of the application. For example, a policy might specify some or all of the following:
-
- Only certain modules can be modified.
- Only object interfaces can be extended or implementations changed.
- Deletions only allowed but not extensions.
- How updates are to be applied, including functionality such as automatic merging of non-conflicting updates, and application of updates before a given peer can send any of its updates to other peers.
- Policy-based notification such that all peers can be notified of updates if they choose, in order to participate in direct synchronization via the most appropriate mechanisms.
- Support updates from different types of clients based on their capabilities.
- In order to achieve this functionality, the authoring application used by each participant can be a NEMO-enabled peer. For the document that is created, a template can be used that describes the policy, including who is authorized and what can be done to each part of the document (in addition to the document's normal formatting rules). As long as the policy engine used by the NEMO peer can interpret and enforce policy rules consistent with their semantics, and as long as the operations supported by the peer interfaces allowed in the creation of the document can be mapped to a given peer's environment via the Service Adaptation Layer, then any peer can participate, but may internally represent the document differently.
- Consider the case of a system consisting of different NEMO peers using services built on the NEMO framework for collaboration involving a presentation document. In this example, a wireless PDA application is running an application written in Java, which it uses for processing and rendering the document as text. A different implementation running under Microsoft Windows® on a desktop workstation processes the same document using the Microsoft Word® format. Both the PDA and the workstation are able to communicate, for example, by connection over a local area network, thus enabling the user of the PDA and the user of the workstation to collaborate on the same document application. In this example:
-
- NEMO peers involved in the collaboration can discover each other, their current status, and their capabilities.
- Each NEMO peer submits for each committable change, its identity, the change, and the operation (e.g., deletion, extension, etc.).
- All changes are propagated to each NEMO peer. This is possible because each NEMO peer can discover the profile and capabilities of another peer if advertised. At this point the notifying peer can have the content change encoding in a form acceptable by the notified peer if it is incapable of doing so. Alternatively the accepting peer may represent the change in any format it sees fit upon receipt at its interface.
- Before accepting a change the peer verifies that it is from an authorized NEMO participant.
- The change is applied based on the document policy.
- As another example, consider the case of a portable wireless consumer electronics (CE) device that is a NEMO-enabled node (X), and that supports DRM format A, but wants to play content in DRM format B. X announces its desire to render the content as well as a description of its characteristics (e.g., what its identity is, what OS it supports, its renewability profile, payment methods it supports, and/or the like) and waits for responses back from other NEMO peers providing potential solutions. In response to its query, X receives three responses:
-
- (1)
Peer 1 can provide a low quality downloadable version of content in clear MP3 form for a fee of $2.00. - (2)
Peer 2 can provide high quality pay-per-play streams of content over a secure channel for $0.50 per play. - (3)
Peer 3 can provide a software update to X that will permit rendering of content in DRM format B for a fee of $10.00.
- (1)
- After reviewing the offers, X determines that option one is the best choice. It submits a request for content via offer number one. The request includes an assertion for a delegation that allows
Peer 1 to deduct $2.00 from X's payment account via another NEMO service. Once X has been charged, then X is given back in a response from Peer 1 a token that allows it to download the MP3 file. - If instead, X were to decide that option three was the best solution, a somewhat more complicated business transaction might ensue. For example, option three may need to be represented as a transactional business process described using a NEMO Orchestration Descriptor (NOD) implemented by the NEMO Workflow Collator (WFC) elements contained in the participating NEMO enabled peers. In order to accomplish the necessary software update to X, the following actions could be executed using the NEMO framework:
-
- X obtains permission from its wireless service provider (B) that it is allowed to receive the update.
- Wireless service provider B directly validates peer three's credentials in order to establish its identity.
- X downloads from B a mandatory update that allows it to install 3rd party updates, their is no policy restriction on this, but this scenario is the first triggering event to cause this action.
- X is charged for the update that peer three provides.
- X downloads the update from peer three.
- In this business process some actions may be able to be carried out concurrently by the WFC elements, while other activities may need to authorized and executed in a specific sequence.
- Yet another example of a potential application of the NEMO framework is in the context of online gaming. Many popular multiplayer gaming environment networks are structured as centralized, closed portals that allow online garners to create and participate in gaming sessions.
- One of the limitations of these environments is that the users generally must have a tight relationship with the gaming network and must have an account (usually associated with a particular game title) in order to use the service. The typical gamer must usually manage several game accounts across multiple titles across multiple gaming networks and interact with game-provider-specific client applications in order to organize multiple player games and participate within the networks. This is often inconvenient, and discourages online use.
- Embodiments of the NEMO framework can be used to enhance the online gaming experience by creating an environment that supports a more federated distributed gaming experience, making transparent to the user and the service provider the details of specific online game networks. This not only provides a better user experience, thereby encouraging adoption and use of these services, but can also reduce the administrative burden on game network providers.
- In order to achieve these benefits, gaming clients can be personalized with NEMO modules so that they can participate as NEMO peers. Moreover, gaming networks can be personalized with NEMO modules so that they can expose their administrative interfaces in standardized ways. Finally, NEMO trust management can be used to ensure that only authorized peers interact in intended ways.
- For example, assume there are three gaming network providers A, B, and C, and two users X and Y. User X has an account with A, and User Y has an account with B. X and Y both acquire a new title that works with C and want to play each other. Using the NEMO framework, X's gaming peer can automatically discover online gaming provider C. X's account information can be transmitted to C from A, after A confirms that C is a legitimate gaming network. X is now registered with C, and can be provisioned with correct tokens to interact with C. User Y goes through the same process to gain access to C using its credentials from B. Once both X and Y are registered they can now discover each other and create an online gaming session.
- This simple registration example can be further expanded to deal with other services that online gaming environments might provide, including, e.g., game token storage (e.g., in lockers), account payment, and shared state information such as historical score boards.
- While several examples were presented in the context of enterprise document management, online gaming, and media content consumption, it will be appreciated that the NEMO framework and the DRM system described herein can be used in any suitable context, and are not limited to these specific examples.
-
- Although the foregoing has been described in some detail for purposes of clarity, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. It should be noted that there are many alternative ways of implementing both the processes and apparatuses of the present inventions. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the inventive body of work is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.
Claims (4)
1. A system comprising:
means for encrypting a piece of electronic content;
means for associating a license with the piece of electronic content, the license comprising a control program, the control program requiring, as a condition of authorizing decryption of the piece of electronic content, possession of a set of one or more link objects logically connecting a first node object with a second node object, the license further comprising an encrypted version of a first key for use in decrypting the piece of electronic content;
means for sending the piece of electronic content to a remote computer system;
means for determining that the remote computer system has possession of a set of one or more link objects logically connecting the first node object with the second node object, wherein at least one of the one or more link objects comprises an encrypted version of a second key for use in decrypting the first key;
means for decrypting the second key using a key associated with the remote computer system;
means for decrypting the first key using the second key; and
means for decrypting the piece of electronic content using the first key.
2. The system of claim 1 , in which the license further comprises a controller object securely binding the control program with the first key.
3. The system of claim 2 , in which the controller object include a hash of a content key object and a control object, wherein the content key object comprises an encrypted version of the first key, and the control object comprises the control program.
4. A computer-readable medium comprising program code, the program code being operable, when executed by a computer system, to cause the computer system to perform actions comprising:
encrypting a piece of electronic content;
associating a license with the piece of electronic content, the license comprising a control program, the control program requiring, as a condition of authorizing decryption of the piece of electronic content, possession of a set of one or more link objects logically connecting a first node object with a second node object, the license further comprising an encrypted version of a first key for use in decrypting the piece of electronic content;
sending the piece of electronic content to a remote computer system;
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/620,452 US20100070774A1 (en) | 2003-06-05 | 2009-11-17 | Interoperable systems and methods for peer-to-peer service orchestration |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US47635703P | 2003-06-05 | 2003-06-05 | |
US50452403P | 2003-09-15 | 2003-09-15 | |
US10/863,551 US8234387B2 (en) | 2003-06-05 | 2004-06-07 | Interoperable systems and methods for peer-to-peer service orchestration |
US11/894,624 US20090094453A1 (en) | 2003-06-05 | 2007-08-20 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/620,452 US20100070774A1 (en) | 2003-06-05 | 2009-11-17 | Interoperable systems and methods for peer-to-peer service orchestration |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/894,624 Division US20090094453A1 (en) | 2003-06-05 | 2007-08-20 | Interoperable systems and methods for peer-to-peer service orchestration |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100070774A1 true US20100070774A1 (en) | 2010-03-18 |
Family
ID=34197784
Family Applications (22)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/863,551 Expired - Fee Related US8234387B2 (en) | 2003-06-05 | 2004-06-07 | Interoperable systems and methods for peer-to-peer service orchestration |
US11/804,667 Abandoned US20070283423A1 (en) | 2003-06-05 | 2007-05-17 | Interoperable systems and methods for peer-to-peer service orchestration |
US11/829,805 Abandoned US20080301430A1 (en) | 2003-06-05 | 2007-07-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US11/829,774 Abandoned US20080285757A1 (en) | 2003-06-05 | 2007-07-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US11/829,751 Abandoned US20080056500A1 (en) | 2003-06-05 | 2007-07-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US11/829,837 Expired - Fee Related US9466054B1 (en) | 2003-06-05 | 2007-07-27 | Interoperable systems and methods for peer-to-peer service orchestration |
US11/829,809 Abandoned US20080298591A1 (en) | 2003-06-05 | 2007-07-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US11/894,372 Abandoned US20080140835A1 (en) | 2003-06-05 | 2007-08-20 | Interoperable systems and methods for peer-to-peer service orchestration |
US11/894,624 Abandoned US20090094453A1 (en) | 2003-06-05 | 2007-08-20 | Interoperable systems and methods for peer-to-peer service orchestration |
US11/929,937 Abandoned US20080133731A1 (en) | 2003-06-05 | 2007-10-30 | Interoperable Systems and Methods for Peer-To-Peer Service Orchestration |
US12/459,490 Abandoned US20100005513A1 (en) | 2003-06-05 | 2009-06-30 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/459,491 Abandoned US20100017606A1 (en) | 2003-06-05 | 2009-06-30 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/617,164 Expired - Fee Related US9235833B2 (en) | 2003-06-05 | 2009-11-12 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/620,445 Abandoned US20100067699A1 (en) | 2003-06-05 | 2009-11-17 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/620,452 Abandoned US20100070774A1 (en) | 2003-06-05 | 2009-11-17 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/789,004 Expired - Fee Related US9424564B2 (en) | 2003-06-05 | 2010-05-27 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/792,965 Abandoned US20100250927A1 (en) | 2003-06-05 | 2010-06-03 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/792,952 Expired - Fee Related US9235834B2 (en) | 2003-06-05 | 2010-06-03 | Interoperable systems and methods for peer-to-peer service orchestration |
US13/283,126 Expired - Fee Related US9317843B2 (en) | 2003-06-05 | 2011-10-27 | Interoperable systems and methods for peer-to-peer service orchestration |
US13/283,313 Abandoned US20120159643A1 (en) | 2003-06-05 | 2011-10-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US13/283,245 Abandoned US20120042389A1 (en) | 2003-06-05 | 2011-10-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US15/266,928 Abandoned US20170163645A1 (en) | 2003-06-05 | 2016-09-15 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
Family Applications Before (14)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/863,551 Expired - Fee Related US8234387B2 (en) | 2003-06-05 | 2004-06-07 | Interoperable systems and methods for peer-to-peer service orchestration |
US11/804,667 Abandoned US20070283423A1 (en) | 2003-06-05 | 2007-05-17 | Interoperable systems and methods for peer-to-peer service orchestration |
US11/829,805 Abandoned US20080301430A1 (en) | 2003-06-05 | 2007-07-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US11/829,774 Abandoned US20080285757A1 (en) | 2003-06-05 | 2007-07-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US11/829,751 Abandoned US20080056500A1 (en) | 2003-06-05 | 2007-07-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US11/829,837 Expired - Fee Related US9466054B1 (en) | 2003-06-05 | 2007-07-27 | Interoperable systems and methods for peer-to-peer service orchestration |
US11/829,809 Abandoned US20080298591A1 (en) | 2003-06-05 | 2007-07-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US11/894,372 Abandoned US20080140835A1 (en) | 2003-06-05 | 2007-08-20 | Interoperable systems and methods for peer-to-peer service orchestration |
US11/894,624 Abandoned US20090094453A1 (en) | 2003-06-05 | 2007-08-20 | Interoperable systems and methods for peer-to-peer service orchestration |
US11/929,937 Abandoned US20080133731A1 (en) | 2003-06-05 | 2007-10-30 | Interoperable Systems and Methods for Peer-To-Peer Service Orchestration |
US12/459,490 Abandoned US20100005513A1 (en) | 2003-06-05 | 2009-06-30 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/459,491 Abandoned US20100017606A1 (en) | 2003-06-05 | 2009-06-30 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/617,164 Expired - Fee Related US9235833B2 (en) | 2003-06-05 | 2009-11-12 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/620,445 Abandoned US20100067699A1 (en) | 2003-06-05 | 2009-11-17 | Interoperable systems and methods for peer-to-peer service orchestration |
Family Applications After (7)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/789,004 Expired - Fee Related US9424564B2 (en) | 2003-06-05 | 2010-05-27 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/792,965 Abandoned US20100250927A1 (en) | 2003-06-05 | 2010-06-03 | Interoperable systems and methods for peer-to-peer service orchestration |
US12/792,952 Expired - Fee Related US9235834B2 (en) | 2003-06-05 | 2010-06-03 | Interoperable systems and methods for peer-to-peer service orchestration |
US13/283,126 Expired - Fee Related US9317843B2 (en) | 2003-06-05 | 2011-10-27 | Interoperable systems and methods for peer-to-peer service orchestration |
US13/283,313 Abandoned US20120159643A1 (en) | 2003-06-05 | 2011-10-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US13/283,245 Abandoned US20120042389A1 (en) | 2003-06-05 | 2011-10-27 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US15/266,928 Abandoned US20170163645A1 (en) | 2003-06-05 | 2016-09-15 | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
Country Status (13)
Country | Link |
---|---|
US (22) | US8234387B2 (en) |
EP (3) | EP2280524A3 (en) |
JP (4) | JP5242915B2 (en) |
KR (4) | KR101030203B1 (en) |
CN (2) | CN103001923B (en) |
AP (1) | AP2005003476A0 (en) |
AU (2) | AU2004264582B2 (en) |
BR (1) | BRPI0410999A (en) |
CA (2) | CA2776354A1 (en) |
EA (2) | EA015549B1 (en) |
IL (2) | IL172366A (en) |
SG (1) | SG155065A1 (en) |
WO (1) | WO2005017654A2 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050027871A1 (en) * | 2003-06-05 | 2005-02-03 | William Bradley | Interoperable systems and methods for peer-to-peer service orchestration |
US20070100701A1 (en) * | 2005-10-18 | 2007-05-03 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US20070185814A1 (en) * | 2005-10-18 | 2007-08-09 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US20070204078A1 (en) * | 2006-02-09 | 2007-08-30 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US9589110B2 (en) | 2011-04-11 | 2017-03-07 | Intertrust Technologies Corporation | Information security systems and methods |
Families Citing this family (742)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6658568B1 (en) * | 1995-02-13 | 2003-12-02 | Intertrust Technologies Corporation | Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management |
US5892900A (en) * | 1996-08-30 | 1999-04-06 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US7133846B1 (en) * | 1995-02-13 | 2006-11-07 | Intertrust Technologies Corp. | Digital certificate support system, methods and techniques for secure electronic commerce transaction and rights management |
US7143290B1 (en) * | 1995-02-13 | 2006-11-28 | Intertrust Technologies Corporation | Trusted and secure techniques, systems and methods for item delivery and execution |
US6948070B1 (en) | 1995-02-13 | 2005-09-20 | Intertrust Technologies Corporation | Systems and methods for secure transaction management and electronic rights protection |
US7133845B1 (en) * | 1995-02-13 | 2006-11-07 | Intertrust Technologies Corp. | System and methods for secure transaction management and electronic rights protection |
US20060206397A1 (en) * | 1995-02-13 | 2006-09-14 | Intertrust Technologies Corp. | Cryptographic methods, apparatus and systems for storage media electronic right management in closed and connected appliances |
US6157721A (en) * | 1996-08-12 | 2000-12-05 | Intertrust Technologies Corp. | Systems and methods using cryptography to protect secure computing environments |
US7165174B1 (en) * | 1995-02-13 | 2007-01-16 | Intertrust Technologies Corp. | Trusted infrastructure support systems, methods and techniques for secure electronic commerce transaction and rights management |
US7095854B1 (en) * | 1995-02-13 | 2006-08-22 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US7124302B2 (en) * | 1995-02-13 | 2006-10-17 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
CN100452072C (en) * | 1995-02-13 | 2009-01-14 | 英特特拉斯特技术公司 | Systems and methods for secure transaction management and electronic rights protection |
US5943422A (en) | 1996-08-12 | 1999-08-24 | Intertrust Technologies Corp. | Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels |
US7809138B2 (en) * | 1999-03-16 | 2010-10-05 | Intertrust Technologies Corporation | Methods and apparatus for persistent control and protection of content |
US6959384B1 (en) | 1999-12-14 | 2005-10-25 | Intertrust Technologies Corporation | Systems and methods for authenticating and protecting the integrity of data streams and other data |
US7430670B1 (en) * | 1999-07-29 | 2008-09-30 | Intertrust Technologies Corp. | Software self-defense systems and methods |
US8145776B1 (en) * | 1999-10-15 | 2012-03-27 | Sony Corporation | Service providing apparatus and method, and information processing apparatus and method as well as program storage medium |
US6832316B1 (en) * | 1999-12-22 | 2004-12-14 | Intertrust Technologies, Corp. | Systems and methods for protecting data secrecy and integrity |
US7266681B1 (en) | 2000-04-07 | 2007-09-04 | Intertrust Technologies Corp. | Network communications security agent |
US7085839B1 (en) | 2000-04-07 | 2006-08-01 | Intertrust Technologies Corporation | Network content management |
US7313692B2 (en) * | 2000-05-19 | 2007-12-25 | Intertrust Technologies Corp. | Trust management systems and methods |
US7107448B1 (en) | 2000-06-04 | 2006-09-12 | Intertrust Technologies Corporation | Systems and methods for governing content rendering, protection, and management applications |
US7213266B1 (en) * | 2000-06-09 | 2007-05-01 | Intertrust Technologies Corp. | Systems and methods for managing and protecting electronic content and applications |
US7050586B1 (en) | 2000-06-19 | 2006-05-23 | Intertrust Technologies Corporation | Systems and methods for retrofitting electronic appliances to accept different content formats |
US8868448B2 (en) | 2000-10-26 | 2014-10-21 | Liveperson, Inc. | Systems and methods to facilitate selling of products and services |
US9819561B2 (en) | 2000-10-26 | 2017-11-14 | Liveperson, Inc. | System and methods for facilitating object assignments |
US20060015390A1 (en) * | 2000-10-26 | 2006-01-19 | Vikas Rijsinghani | System and method for identifying and approaching browsers most likely to transact business based upon real-time data mining |
WO2002054391A1 (en) * | 2000-12-28 | 2002-07-11 | Hitachi Maxell, Ltd. | Magnetic tape, its cleaning method, and optical servotrack forming/cleaning apparatus |
US20050220286A1 (en) * | 2001-02-27 | 2005-10-06 | John Valdez | Method and apparatus for facilitating integrated access to communications services in a communication device |
US7580988B2 (en) * | 2001-04-05 | 2009-08-25 | Intertrust Technologies Corporation | System and methods for managing the distribution of electronic content |
US7136840B2 (en) | 2001-04-20 | 2006-11-14 | Intertrust Technologies Corp. | Systems and methods for conducting transactions and communications using a trusted third party |
US7581103B2 (en) | 2001-06-13 | 2009-08-25 | Intertrust Technologies Corporation | Software self-checking systems and methods |
US7149899B2 (en) * | 2002-04-25 | 2006-12-12 | Intertrust Technologies Corp. | Establishing a secure channel with a human user |
US7383570B2 (en) | 2002-04-25 | 2008-06-03 | Intertrust Technologies, Corp. | Secure authentication systems and methods |
JP3973986B2 (en) * | 2002-07-12 | 2007-09-12 | 株式会社エヌ・ティ・ティ・ドコモ | Node search method, node, communication system, and node search program |
US8799883B2 (en) * | 2003-01-31 | 2014-08-05 | Hewlett-Packard Development Company, L. P. | System and method of measuring application resource usage |
AU2004200734B2 (en) * | 2003-02-26 | 2010-07-15 | Wms Gaming Inc. | Gaming management service in the service-oriented gaming network environment |
US20060142086A1 (en) * | 2003-02-26 | 2006-06-29 | Blackburn Christopher W | Progressive service in a service-oriented gaming network environment |
US20040235563A1 (en) * | 2003-02-26 | 2004-11-25 | Blackburn Christopher W. | Game update service in a service-oriented gaming network environment |
JP2004255187A (en) * | 2003-02-26 | 2004-09-16 | Wms Gaming Inc | Network surroundings for service pointed game |
US8308567B2 (en) * | 2003-03-05 | 2012-11-13 | Wms Gaming Inc. | Discovery service in a service-oriented gaming network environment |
US20040243849A1 (en) * | 2003-03-06 | 2004-12-02 | Blackburn Christopher W. | Authorization service in a service-oriented gaming network environment |
US20040243848A1 (en) * | 2003-03-06 | 2004-12-02 | Blackburn Christopher W. | Authentication service in a service-oriented gaming network environment |
US7927210B2 (en) * | 2003-03-17 | 2011-04-19 | Wms Gaming Inc. | Accounting service in a service-oriented gaming network environment |
US20040242331A1 (en) * | 2003-03-17 | 2004-12-02 | Blackburn Christopher W. | Time service in a service-oriented gaming network environment |
US20040266532A1 (en) * | 2003-03-27 | 2004-12-30 | Blackburn Christopher W. | Event management service in a service-oriented gaming network environment |
US8261062B2 (en) * | 2003-03-27 | 2012-09-04 | Microsoft Corporation | Non-cryptographic addressing |
CA2464797A1 (en) * | 2003-04-16 | 2004-10-16 | Wms Gaming Inc. | Remote authentication of gaming software in a gaming system environment |
US20040266523A1 (en) * | 2003-04-16 | 2004-12-30 | Gentles Thomas A | Secured networks in a gaming system environment |
US20040266533A1 (en) * | 2003-04-16 | 2004-12-30 | Gentles Thomas A | Gaming software distribution network in a gaming system environment |
US20050227768A1 (en) * | 2003-05-27 | 2005-10-13 | Blackburn Christopher W | Gaming network environment having a language translation service |
US8095500B2 (en) | 2003-06-13 | 2012-01-10 | Brilliant Digital Entertainment, Inc. | Methods and systems for searching content in distributed computing networks |
US7729992B2 (en) * | 2003-06-13 | 2010-06-01 | Brilliant Digital Entertainment, Inc. | Monitoring of computer-related resources and associated methods and systems for disbursing compensation |
US7526541B2 (en) * | 2003-07-29 | 2009-04-28 | Enterasys Networks, Inc. | System and method for dynamic network policy management |
US8200775B2 (en) * | 2005-02-01 | 2012-06-12 | Newsilike Media Group, Inc | Enhanced syndication |
US20050038708A1 (en) * | 2003-08-10 | 2005-02-17 | Gmorpher Incorporated | Consuming Web Services on Demand |
JP4265326B2 (en) * | 2003-08-12 | 2009-05-20 | 株式会社日立製作所 | Service processing method and system, and processing program therefor |
US8307109B2 (en) * | 2003-08-27 | 2012-11-06 | International Business Machines Corporation | Methods and systems for real time integration services |
US8041760B2 (en) | 2003-08-27 | 2011-10-18 | International Business Machines Corporation | Service oriented architecture for a loading function in a data integration platform |
US7814470B2 (en) * | 2003-08-27 | 2010-10-12 | International Business Machines Corporation | Multiple service bindings for a real time data integration service |
US20050235274A1 (en) * | 2003-08-27 | 2005-10-20 | Ascential Software Corporation | Real time data integration for inventory management |
US20060010195A1 (en) * | 2003-08-27 | 2006-01-12 | Ascential Software Corporation | Service oriented architecture for a message broker in a data integration platform |
US20050228808A1 (en) * | 2003-08-27 | 2005-10-13 | Ascential Software Corporation | Real time data integration services for health care information data integration |
US8060553B2 (en) | 2003-08-27 | 2011-11-15 | International Business Machines Corporation | Service oriented architecture for a transformation function in a data integration platform |
US20050262189A1 (en) * | 2003-08-27 | 2005-11-24 | Ascential Software Corporation | Server-side application programming interface for a real time data integration service |
US20050234969A1 (en) * | 2003-08-27 | 2005-10-20 | Ascential Software Corporation | Services oriented architecture for handling metadata in a data integration platform |
US20050223109A1 (en) * | 2003-08-27 | 2005-10-06 | Ascential Software Corporation | Data integration through a services oriented architecture |
US7814142B2 (en) | 2003-08-27 | 2010-10-12 | International Business Machines Corporation | User interface service for a services oriented architecture in a data integration platform |
US20050240354A1 (en) * | 2003-08-27 | 2005-10-27 | Ascential Software Corporation | Service oriented architecture for an extract function in a data integration platform |
US7296296B2 (en) * | 2003-10-23 | 2007-11-13 | Microsoft Corporation | Protected media path and refusal response enabler |
JP2005141413A (en) * | 2003-11-05 | 2005-06-02 | Sony Corp | Information processing apparatus and its information processing method, as well as data communication system and data communication method |
US9009290B2 (en) * | 2004-01-22 | 2015-04-14 | Sony Corporation | Methods and apparatuses for discovery and notification of services |
WO2005074187A1 (en) * | 2004-01-29 | 2005-08-11 | Sony Corporation | Information processing device and method |
US20050177715A1 (en) * | 2004-02-09 | 2005-08-11 | Microsoft Corporation | Method and system for managing identities in a peer-to-peer networking environment |
US7716726B2 (en) * | 2004-02-13 | 2010-05-11 | Microsoft Corporation | System and method for protecting a computing device from computer exploits delivered over a networked environment in a secured communication |
US7814543B2 (en) * | 2004-02-13 | 2010-10-12 | Microsoft Corporation | System and method for securing a computer system connected to a network from attacks |
US7603716B2 (en) * | 2004-02-13 | 2009-10-13 | Microsoft Corporation | Distributed network security service |
US7664828B2 (en) | 2004-02-20 | 2010-02-16 | Microsoft Corporation | Invalid policy detection |
US7496649B2 (en) * | 2004-02-20 | 2009-02-24 | Microsoft Corporation | Policy application across multiple nodes |
US7243157B2 (en) * | 2004-02-20 | 2007-07-10 | Microsoft Corporation | Dynamic protocol construction |
US8862570B1 (en) | 2004-03-02 | 2014-10-14 | Rockstar Consortium Us Lp | Method and apparatus for open management of multi-media services |
US7653189B1 (en) * | 2004-03-02 | 2010-01-26 | Nortel Networks Limited | Telecommunications service negotiation |
US7738980B2 (en) * | 2004-03-04 | 2010-06-15 | Yamaha Corporation | Apparatus for editing configuration data of digital mixer |
US20050251533A1 (en) * | 2004-03-16 | 2005-11-10 | Ascential Software Corporation | Migrating data integration processes through use of externalized metadata representations |
US7761406B2 (en) * | 2004-03-16 | 2010-07-20 | International Business Machines Corporation | Regenerating data integration functions for transfer from a data integration platform |
US8239543B1 (en) * | 2004-03-22 | 2012-08-07 | Netapp, Inc. | Method and an apparatus to provide access to operational data in a storage server via multiple data management protocols |
US7565438B1 (en) * | 2004-03-30 | 2009-07-21 | Sprint Communications Company L.P. | Digital rights management integrated service solution |
US20060242406A1 (en) | 2005-04-22 | 2006-10-26 | Microsoft Corporation | Protected computing environment |
JP4192841B2 (en) * | 2004-05-17 | 2008-12-10 | ヤマハ株式会社 | Mixer engine control device and program |
US20050262075A1 (en) * | 2004-05-21 | 2005-11-24 | Bea Systems, Inc. | Systems and methods for collaboration shared state management |
US20050262007A1 (en) * | 2004-05-21 | 2005-11-24 | Bea Systems, Inc. | Systems and methods for a collaborative call center |
US20050273668A1 (en) * | 2004-05-20 | 2005-12-08 | Richard Manning | Dynamic and distributed managed edge computing (MEC) framework |
US20060031234A1 (en) * | 2004-05-21 | 2006-02-09 | Brodi Beartusk | Systems and methods for a collaborative group chat |
US20060010205A1 (en) * | 2004-05-21 | 2006-01-12 | Bea Systems, Inc. | Systems and methods for collaboration impersonation |
US20050262092A1 (en) * | 2004-05-21 | 2005-11-24 | Bea Systems, Inc. | Systems and methods for collaboration dynamic pageflows |
US20060010125A1 (en) * | 2004-05-21 | 2006-01-12 | Bea Systems, Inc. | Systems and methods for collaborative shared workspaces |
US20050289558A1 (en) * | 2004-06-08 | 2005-12-29 | Daniel Illowsky | Device interoperability runtime establishing event serialization and synchronization amongst a plurality of separate processing units and method for coordinating control data and operations |
US7788713B2 (en) * | 2004-06-23 | 2010-08-31 | Intel Corporation | Method, apparatus and system for virtualized peer-to-peer proxy services |
US7929689B2 (en) * | 2004-06-30 | 2011-04-19 | Microsoft Corporation | Call signs |
US8266429B2 (en) | 2004-07-20 | 2012-09-11 | Time Warner Cable, Inc. | Technique for securely communicating and storing programming material in a trusted domain |
US8312267B2 (en) | 2004-07-20 | 2012-11-13 | Time Warner Cable Inc. | Technique for securely communicating programming content |
US20060021018A1 (en) * | 2004-07-21 | 2006-01-26 | International Business Machines Corporation | Method and system for enabling trust infrastructure support for federated user lifecycle management |
GB2416872A (en) * | 2004-07-30 | 2006-02-08 | Canon Kk | System for managing tasks on a network by using a service discover, a task manager and a service publisher |
CA2618935C (en) * | 2004-08-13 | 2014-04-29 | Remasys Pty Ltd | Monitoring and management of distributed information systems |
US7587496B2 (en) * | 2004-09-17 | 2009-09-08 | Ricoh Company, Ltd. | Transfer device, distributed processing system, transfer device control method, program, and recording medium |
US7693994B2 (en) * | 2004-09-17 | 2010-04-06 | Ricoh Company, Ltd. | Intermediary apparatus, distributed processing system, data-transfer method, program and recording medium |
US20060064386A1 (en) * | 2004-09-20 | 2006-03-23 | Aaron Marking | Media on demand via peering |
US11734393B2 (en) | 2004-09-20 | 2023-08-22 | Warner Bros. Entertainment Inc. | Content distribution with renewable content protection |
GB2419000A (en) * | 2004-10-06 | 2006-04-12 | Hewlett Packard Development Co | Proving relationships between data |
KR100628655B1 (en) * | 2004-10-20 | 2006-09-26 | 한국전자통신연구원 | Method and system for exchanging contents between different DRM devices |
JP4357534B2 (en) * | 2004-10-28 | 2009-11-04 | 富士通株式会社 | Mobile radio communication terminal and communication control method |
US7716727B2 (en) * | 2004-10-29 | 2010-05-11 | Microsoft Corporation | Network security device and method for protecting a computing device in a networked environment |
US7810164B2 (en) * | 2004-11-11 | 2010-10-05 | Yamaha Corporation | User management method, and computer program having user authorization management function |
GB0425860D0 (en) * | 2004-11-25 | 2004-12-29 | Ibm | A method for ensuring the quality of a service in a distributed computing environment |
US8533357B2 (en) * | 2004-12-03 | 2013-09-10 | Microsoft Corporation | Mechanism for binding a structured data protocol to a protocol offering up byte streams |
EP1672891A1 (en) * | 2004-12-14 | 2006-06-21 | Alcatel | Method for transferring messages |
US7562382B2 (en) * | 2004-12-16 | 2009-07-14 | International Business Machines Corporation | Specializing support for a federation relationship |
US7533258B2 (en) * | 2005-01-07 | 2009-05-12 | Cisco Technology, Inc. | Using a network-service credential for access control |
EP1681823A1 (en) * | 2005-01-17 | 2006-07-19 | Sap Ag | A method and a system to organize and manage a semantic web service discovery |
US20080195483A1 (en) * | 2005-02-01 | 2008-08-14 | Moore James F | Widget management systems and advertising systems related thereto |
US8200700B2 (en) | 2005-02-01 | 2012-06-12 | Newsilike Media Group, Inc | Systems and methods for use of structured and unstructured distributed data |
US20080046471A1 (en) * | 2005-02-01 | 2008-02-21 | Moore James F | Calendar Synchronization using Syndicated Data |
US20080005086A1 (en) * | 2006-05-17 | 2008-01-03 | Moore James F | Certificate-based search |
US20080126178A1 (en) * | 2005-09-10 | 2008-05-29 | Moore James F | Surge-Based Online Advertising |
US20070106754A1 (en) * | 2005-09-10 | 2007-05-10 | Moore James F | Security facility for maintaining health care data pools |
US20080040151A1 (en) * | 2005-02-01 | 2008-02-14 | Moore James F | Uses of managed health care data |
US9202084B2 (en) | 2006-02-01 | 2015-12-01 | Newsilike Media Group, Inc. | Security facility for maintaining health care data pools |
US20070050446A1 (en) * | 2005-02-01 | 2007-03-01 | Moore James F | Managing network-accessible resources |
US8140482B2 (en) | 2007-09-19 | 2012-03-20 | Moore James F | Using RSS archives |
US8347088B2 (en) * | 2005-02-01 | 2013-01-01 | Newsilike Media Group, Inc | Security systems and methods for use with structured and unstructured data |
US20060265489A1 (en) * | 2005-02-01 | 2006-11-23 | Moore James F | Disaster management using an enhanced syndication platform |
US8700738B2 (en) * | 2005-02-01 | 2014-04-15 | Newsilike Media Group, Inc. | Dynamic feed generation |
EP1696633B1 (en) * | 2005-02-28 | 2008-01-09 | Alcatel Lucent | Bidirectional SOAP communication by means of a single HTTP session |
US7818350B2 (en) | 2005-02-28 | 2010-10-19 | Yahoo! Inc. | System and method for creating a collaborative playlist |
JP2006285607A (en) * | 2005-03-31 | 2006-10-19 | Sony Corp | Content information providing system, content information providing server, content reproducing unit, content information providing method, content reproducing method, and computer program |
US7890598B2 (en) * | 2005-03-31 | 2011-02-15 | Sony Corporation | Remote access management |
EP1710694A3 (en) * | 2005-04-08 | 2006-12-13 | Ricoh Company, Ltd. | Communication apparatus, program product for adding communication mechanism to communication apparatus for providing improved usability and communication efficiency, and recording medium storing program product |
US9436804B2 (en) | 2005-04-22 | 2016-09-06 | Microsoft Technology Licensing, Llc | Establishing a unique session key using a hardware functionality scan |
US9363481B2 (en) | 2005-04-22 | 2016-06-07 | Microsoft Technology Licensing, Llc | Protected media pipeline |
US7949117B2 (en) * | 2005-04-28 | 2011-05-24 | Apple Inc. | Heterogeneous video conferencing |
US7817180B2 (en) * | 2005-04-28 | 2010-10-19 | Apple Inc. | Video processing in a multi-participant video conference |
US7899170B2 (en) * | 2005-04-28 | 2011-03-01 | Apple Inc. | Multi-participant conference setup |
US7864209B2 (en) * | 2005-04-28 | 2011-01-04 | Apple Inc. | Audio processing in a multi-participant conference |
US8464317B2 (en) * | 2005-05-06 | 2013-06-11 | International Business Machines Corporation | Method and system for creating a protected object namespace from a WSDL resource description |
US20060271939A1 (en) * | 2005-05-11 | 2006-11-30 | Eric Joris | Enterprise-to-enterprise integration |
US20060271384A1 (en) * | 2005-05-31 | 2006-11-30 | Microsoft Corporation | Reference data aggregate service population |
US20060277092A1 (en) * | 2005-06-03 | 2006-12-07 | Credigy Technologies, Inc. | System and method for a peer to peer exchange of consumer information |
US7684421B2 (en) * | 2005-06-09 | 2010-03-23 | Lockheed Martin Corporation | Information routing in a distributed environment |
US20070011171A1 (en) * | 2005-07-08 | 2007-01-11 | Nurminen Jukka K | System and method for operation control functionality |
WO2007011917A2 (en) * | 2005-07-15 | 2007-01-25 | Newsilike Media Group, Inc. | Managing network-accessible services |
WO2007011167A1 (en) * | 2005-07-21 | 2007-01-25 | Kyungpook National University Industry-Academic Cooperation Foundation | Virtual storage system and method for searching file based on ad-hoc network |
US20070019641A1 (en) * | 2005-07-22 | 2007-01-25 | Rockwell Automation Technologies, Inc. | Execution of industrial automation applications on communication infrastructure devices |
WO2007052285A2 (en) * | 2005-07-22 | 2007-05-10 | Yogesh Chunilal Rathod | Universal knowledge management and desktop search system |
JP4765485B2 (en) * | 2005-08-26 | 2011-09-07 | ソニー株式会社 | Information processing apparatus, information recording medium, information processing method, and computer program |
US8046837B2 (en) | 2005-08-26 | 2011-10-25 | Sony Corporation | Information processing device, information recording medium, information processing method, and computer program |
EP1760921A3 (en) * | 2005-09-05 | 2011-12-28 | Yamaha Corporation | Digital mixer with detachable memory card |
US8738732B2 (en) * | 2005-09-14 | 2014-05-27 | Liveperson, Inc. | System and method for performing follow up based on user interactions |
US9432468B2 (en) | 2005-09-14 | 2016-08-30 | Liveperson, Inc. | System and method for design and dynamic generation of a web page |
US8825907B2 (en) * | 2005-09-15 | 2014-09-02 | Gendband US LLC | Incorporating a mobile device into a peer-to-peer network |
US20110010533A1 (en) * | 2005-09-20 | 2011-01-13 | Matsushita Electric Industrial Co., Ltd. | System and Method for Component Trust Model in Peer-to-Peer Service Composition |
US20070083476A1 (en) * | 2005-10-11 | 2007-04-12 | Interdigital Technology Corporation | Method and system for enforcing user rights and maintaining consistency of user data in a data network |
US20070088660A1 (en) * | 2005-10-13 | 2007-04-19 | Abu-Amara Hosame H | Digital security for distributing media content to a local area network |
TWI468969B (en) * | 2005-10-18 | 2015-01-11 | Intertrust Tech Corp | Method of authorizing access to electronic content and method of authorizing an action performed thereto |
CA2527447C (en) * | 2005-11-18 | 2015-05-05 | Allen Vi Cuong Chan | Message oriented construction of web services |
US20070130622A1 (en) * | 2005-11-21 | 2007-06-07 | Docomo Communications Laboratories Usa, Inc. | Method and apparatus for verifying and ensuring safe handling of notifications |
US20090036217A1 (en) * | 2005-11-22 | 2009-02-05 | Wms Gaming Inc. | Service-oriented gaming network environment |
US8270293B2 (en) * | 2005-12-02 | 2012-09-18 | Panasonic Corporation | Systems and methods for efficient electronic communication in a distributed routing environment |
US8560456B2 (en) * | 2005-12-02 | 2013-10-15 | Credigy Technologies, Inc. | System and method for an anonymous exchange of private data |
US9686183B2 (en) * | 2005-12-06 | 2017-06-20 | Zarbaña Digital Fund Llc | Digital object routing based on a service request |
US20080021918A1 (en) * | 2005-12-23 | 2008-01-24 | Rao Viswanatha H | Enterprise service management unifier system |
US20070162377A1 (en) * | 2005-12-23 | 2007-07-12 | Credigy Technologies, Inc. | System and method for an online exchange of private data |
US8176534B2 (en) | 2005-12-30 | 2012-05-08 | General Instrument Corporation | Method and apparatus for provisioning a device to access digital rights management (DRM) services in a universal plug and play (UPnP) network |
US7523121B2 (en) | 2006-01-03 | 2009-04-21 | Siperian, Inc. | Relationship data management |
US20070214179A1 (en) * | 2006-03-10 | 2007-09-13 | Khanh Hoang | Searching, filtering, creating, displaying, and managing entity relationships across multiple data hierarchies through a user interface |
US7836439B2 (en) * | 2006-02-03 | 2010-11-16 | Research In Motion Limited | System and method for extending a component-based application platform with custom services |
US20070201655A1 (en) * | 2006-02-03 | 2007-08-30 | Michael Shenfield | System and method for installing custom services on a component-based application platform |
US8371932B2 (en) * | 2006-02-07 | 2013-02-12 | Wms Gaming Inc. | Wager gaming network with wireless hotspots |
US8360887B2 (en) * | 2006-02-09 | 2013-01-29 | Wms Gaming Inc. | Wagering game server availability broadcast message system |
US8924335B1 (en) | 2006-03-30 | 2014-12-30 | Pegasystems Inc. | Rule-based user interface conformance methods |
US7987514B2 (en) * | 2006-04-04 | 2011-07-26 | Intertrust Technologies Corp. | Systems and methods for retrofitting electronic appliances to accept different content formats |
US8831011B1 (en) * | 2006-04-13 | 2014-09-09 | Xceedium, Inc. | Point to multi-point connections |
US8086842B2 (en) * | 2006-04-21 | 2011-12-27 | Microsoft Corporation | Peer-to-peer contact exchange |
CN101064660A (en) * | 2006-04-28 | 2007-10-31 | 西门子通信技术(北京)有限公司 | System and method for realizing service intercommunication |
KR101346734B1 (en) * | 2006-05-12 | 2014-01-03 | 삼성전자주식회사 | Multi certificate revocation list support method and apparatus for digital rights management |
EP2024894A4 (en) * | 2006-05-12 | 2016-09-21 | Samsung Electronics Co Ltd | Apparatus and method of managing security data |
US8224975B1 (en) * | 2006-05-24 | 2012-07-17 | Avaya Inc. | Web service initiation protocol for multimedia and voice communication over internet protocol |
US7747736B2 (en) * | 2006-06-05 | 2010-06-29 | International Business Machines Corporation | Rule and policy promotion within a policy hierarchy |
US8019845B2 (en) * | 2006-06-05 | 2011-09-13 | International Business Machines Corporation | Service delivery using profile based management |
US9338028B2 (en) * | 2006-06-19 | 2016-05-10 | Nokia Technologies Oy | Utilizing information of a local network for determining presence state |
CN101094223B (en) * | 2006-06-23 | 2010-12-08 | 国际商业机器公司 | Metod and device for distributing policy in service model facing to service system structural system |
US7881315B2 (en) * | 2006-06-27 | 2011-02-01 | Microsoft Corporation | Local peer-to-peer digital content distribution |
KR100877064B1 (en) * | 2006-07-24 | 2009-01-07 | 삼성전자주식회사 | Apparatus and method for creating unique identifier |
US7774463B2 (en) * | 2006-07-25 | 2010-08-10 | Sap Ag | Unified meta-model for a service oriented architecture |
US20080052343A1 (en) * | 2006-07-27 | 2008-02-28 | Wood Charles B | Usage-Based Prioritization |
US20080046369A1 (en) * | 2006-07-27 | 2008-02-21 | Wood Charles B | Password Management for RSS Interfaces |
US20080046437A1 (en) * | 2006-07-27 | 2008-02-21 | Wood Charles B | Manual Conflict Resolution for Background Synchronization |
US20080052162A1 (en) * | 2006-07-27 | 2008-02-28 | Wood Charles B | Calendar-Based Advertising |
WO2008021079A2 (en) | 2006-08-08 | 2008-02-21 | Wms Gaming Inc. | Configurable wagering game manager |
WO2008019158A2 (en) * | 2006-08-10 | 2008-02-14 | Intertrust Technologies Corporation | Trust management systems and methods |
US8095626B2 (en) * | 2006-08-31 | 2012-01-10 | Realnetworks, Inc. | System and method for configuring a client electronic device |
KR20090064410A (en) * | 2006-08-31 | 2009-06-18 | 리얼네트웍스 인코포레이티드 | Api-accessible media distribution system |
JP5079427B2 (en) * | 2006-08-31 | 2012-11-21 | アクセンチュア グローバル サーヴィシズ ゲゼルシャフト ミット ベシュレンクテル ハフツング | Service provisioning and activation engine for systems |
US20080066181A1 (en) * | 2006-09-07 | 2008-03-13 | Microsoft Corporation | DRM aspects of peer-to-peer digital content distribution |
US20080071897A1 (en) * | 2006-09-15 | 2008-03-20 | International Business Machines Corporation | Method, system, and computer program product for federating the state and behavior of a manageable resource |
US8042090B2 (en) * | 2006-09-29 | 2011-10-18 | Sap Ag | Integrated configuration of cross organizational business processes |
US8150798B2 (en) | 2006-10-10 | 2012-04-03 | Wells Fargo Bank, N.A. | Method and system for automated coordination and organization of electronic communications in enterprises |
US8520850B2 (en) | 2006-10-20 | 2013-08-27 | Time Warner Cable Enterprises Llc | Downloadable security and protection methods and apparatus |
US20080103977A1 (en) * | 2006-10-31 | 2008-05-01 | Microsoft Corporation | Digital rights management for distributed devices |
US20080104206A1 (en) * | 2006-10-31 | 2008-05-01 | Microsoft Corporation | Efficient knowledge representation in data synchronization systems |
US8732854B2 (en) | 2006-11-01 | 2014-05-20 | Time Warner Cable Enterprises Llc | Methods and apparatus for premises content distribution |
US20080113677A1 (en) * | 2006-11-11 | 2008-05-15 | Rajeev Kumar Madnawat | Mobile to mobile service invocation framework using text messsaging |
WO2008064356A1 (en) * | 2006-11-22 | 2008-05-29 | Metis Enterprise Technologies Llc | Real-time multicast peer-to-peer video streaming platform |
US8578350B2 (en) * | 2006-11-30 | 2013-11-05 | Ncr Corporation | System and method for interpreting a specification language file to implement a business system |
AU2011203040B2 (en) * | 2006-12-01 | 2012-07-05 | Catch Media, Inc. | Media management and tracking |
KR100733742B1 (en) * | 2006-12-14 | 2007-06-29 | 주식회사 아이오셀 | Portable information processing terminal and communication system thereof |
US8625481B2 (en) * | 2006-12-15 | 2014-01-07 | Samsung Electronics Co., Ltd. | Architecture for MANET over Bluetooth |
KR101369399B1 (en) * | 2006-12-29 | 2014-03-05 | 삼성전자주식회사 | Method and system for performing drm related rights enforcement when drm agent and rendering application are inplimented on separate devices |
US20100145859A1 (en) * | 2007-01-16 | 2010-06-10 | Shingo Murakami | Control device, reproducing device, permission server, method for controlling control device, method for controlling reproducing device, and method for controlling permission server |
US8621540B2 (en) | 2007-01-24 | 2013-12-31 | Time Warner Cable Enterprises Llc | Apparatus and methods for provisioning in a download-enabled system |
US9088518B2 (en) | 2007-01-25 | 2015-07-21 | Hewlett-Packard Development Company, L.P. | Web services and telecom network management unification |
US8117278B2 (en) * | 2007-02-05 | 2012-02-14 | Oracle International Corporation | Orchestration of components to realize a content or service delivery suite |
US7620659B2 (en) * | 2007-02-09 | 2009-11-17 | Microsoft Corporation | Efficient knowledge representation in data synchronization systems |
US7996882B2 (en) * | 2007-02-26 | 2011-08-09 | L Heureux Israel | Digital asset distribution system |
US20080222237A1 (en) * | 2007-03-06 | 2008-09-11 | Microsoft Corporation | Web services mashup component wrappers |
US20080222599A1 (en) * | 2007-03-07 | 2008-09-11 | Microsoft Corporation | Web services mashup designer |
KR101566171B1 (en) * | 2007-03-09 | 2015-11-06 | 삼성전자 주식회사 | Method and apparatus for digital rights management |
EP1970809A1 (en) * | 2007-03-14 | 2008-09-17 | Software Ag | Method and registry for policy consistency control in a Service Oriented Architecture |
EP1978468A1 (en) * | 2007-04-04 | 2008-10-08 | Sap Ag | A method and a system for secure execution of workflow tasks in a distributed workflow management system within a decentralized network system |
US8782527B2 (en) | 2007-06-27 | 2014-07-15 | Microsoft Corp. | Collaborative phone-based file exchange |
US7861008B2 (en) | 2007-06-28 | 2010-12-28 | Apple Inc. | Media management and routing within an electronic device |
US8041438B2 (en) | 2007-06-28 | 2011-10-18 | Apple Inc. | Data-driven media management within an electronic device |
US8111837B2 (en) * | 2007-06-28 | 2012-02-07 | Apple Inc. | Data-driven media management within an electronic device |
US8171177B2 (en) | 2007-06-28 | 2012-05-01 | Apple Inc. | Enhancements to data-driven media management within an electronic device |
US20090019427A1 (en) * | 2007-07-13 | 2009-01-15 | International Business Machines Corporation | Method and Apparatus for Providing Requirement Driven Static Analysis of Test Coverage for Web-Based, Distributed Processes |
JP5351158B2 (en) * | 2007-07-23 | 2013-11-27 | インタートラスト テクノロジーズ コーポレイション | Tethered device system and method |
US9596292B1 (en) * | 2007-08-03 | 2017-03-14 | EMC IP Holding Company LLC | Client-side scripts in a service-oriented API environment |
CN101365128A (en) * | 2007-08-10 | 2009-02-11 | 中兴通讯股份有限公司 | Peer-to-peer network system for synthetic video service |
US7779094B2 (en) * | 2007-08-21 | 2010-08-17 | Juniper Networks, Inc. | Event problem report bundles in XML format |
US8214475B1 (en) * | 2007-08-30 | 2012-07-03 | Amazon Technologies, Inc. | System and method for managing content interest data using peer-to-peer logical mesh networks |
US8290152B2 (en) * | 2007-08-30 | 2012-10-16 | Microsoft Corporation | Management system for web service developer keys |
US9160752B2 (en) * | 2007-08-31 | 2015-10-13 | International Business Machines Corporation | Database authorization rules and component logic authorization rules aggregation |
US7747590B2 (en) * | 2007-08-31 | 2010-06-29 | International Business Machines Corporation | Avoiding redundant computation in service-oriented architectures |
US9807096B2 (en) | 2014-12-18 | 2017-10-31 | Live Nation Entertainment, Inc. | Controlled token distribution to protect against malicious data and resource access |
US8560938B2 (en) | 2008-02-12 | 2013-10-15 | Oracle International Corporation | Multi-layer XML customization |
US8238313B2 (en) * | 2007-09-14 | 2012-08-07 | Intel Corporation | Techniques for wireless personal area network communications with efficient spatial reuse |
US8171117B2 (en) * | 2007-09-14 | 2012-05-01 | Ricoh Co. Ltd. | Workflow manager for a distributed system |
US20090083441A1 (en) * | 2007-09-24 | 2009-03-26 | Microsoft Corporation | Synchronization of web service endpoints in a multi-master synchronization environment |
US20090083762A1 (en) * | 2007-09-24 | 2009-03-26 | Microsoft Corporation | Dynamically mapping an action of a message |
US7836018B2 (en) * | 2007-10-24 | 2010-11-16 | Emc Corporation | Simultaneously accessing file objects through web services and file services |
US20090119121A1 (en) * | 2007-11-02 | 2009-05-07 | Mwstory Co., Ltd. | Peer-to-peer service providing system and method for preventing contents from being illegally distributed |
US9350595B1 (en) * | 2007-12-27 | 2016-05-24 | Emc Corporation | System and method for serializing and deserializing data objects into a single binary stream |
US20090241159A1 (en) * | 2008-03-18 | 2009-09-24 | Avaya Technology Llc | Open cable application platform set-top box (stb) personal profiles and communications applications |
US20090241153A1 (en) * | 2008-03-18 | 2009-09-24 | Avaya Technology Llc | Open cable application platform set-top box (stb) personal profiles and communications applications |
US20090241158A1 (en) * | 2008-03-18 | 2009-09-24 | Avaya Technology Llc | Open cable application platform set-top box (stb) personal profiles and communications applications |
US8453188B2 (en) * | 2008-01-22 | 2013-05-28 | Avaya Inc. | Open cable application platform set-top box (STB) personal profiles and communications applications |
US7904597B2 (en) * | 2008-01-23 | 2011-03-08 | The Chinese University Of Hong Kong | Systems and processes of identifying P2P applications based on behavioral signatures |
WO2009093941A1 (en) * | 2008-01-24 | 2009-07-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for checking aggregated web sevices |
US8819838B2 (en) * | 2008-01-25 | 2014-08-26 | Google Technology Holdings LLC | Piracy prevention in digital rights management systems |
US8538998B2 (en) | 2008-02-12 | 2013-09-17 | Oracle International Corporation | Caching and memory optimizations for multi-layer XML customization |
US8875306B2 (en) | 2008-02-12 | 2014-10-28 | Oracle International Corporation | Customization restrictions for multi-layer XML customization |
US7987163B2 (en) * | 2008-02-12 | 2011-07-26 | Bae Systems Information And Electronic Systems Integration Inc. | Apparatus and method for dynamic web service discovery |
US8966465B2 (en) | 2008-02-12 | 2015-02-24 | Oracle International Corporation | Customization creation and update for multi-layer XML customization |
US8788542B2 (en) | 2008-02-12 | 2014-07-22 | Oracle International Corporation | Customization syntax for multi-layer XML customization |
DE102008002787A1 (en) * | 2008-02-29 | 2009-09-03 | Schneider Electric Gmbh | 4-phase interaction patterns based on port-type protocols for using lifecycles of services provided by service-oriented devices |
US20090253517A1 (en) | 2008-04-04 | 2009-10-08 | Zipzapplay, Inc. | Open game engine and marketplace with associated game editing and creation tools |
US8782604B2 (en) | 2008-04-11 | 2014-07-15 | Oracle International Corporation | Sandbox support for metadata in running applications |
JP2009278223A (en) * | 2008-05-13 | 2009-11-26 | Panasonic Corp | Electronic certification system and secret communication system |
US8095518B2 (en) * | 2008-06-04 | 2012-01-10 | Microsoft Corporation | Translating DRM system requirements |
US8055619B2 (en) * | 2008-06-05 | 2011-11-08 | Novell, Inc. | Mechanisms to support object-oriented version control operations |
US8667031B2 (en) | 2008-06-13 | 2014-03-04 | Oracle International Corporation | Reuse of shared metadata across applications via URL protocol |
US8457034B2 (en) * | 2008-06-17 | 2013-06-04 | Raytheon Company | Airborne communication network |
US20090315766A1 (en) | 2008-06-19 | 2009-12-24 | Microsoft Corporation | Source switching for devices supporting dynamic direction information |
US8700301B2 (en) | 2008-06-19 | 2014-04-15 | Microsoft Corporation | Mobile computing devices, architecture and user interfaces based on dynamic direction information |
US8467991B2 (en) | 2008-06-20 | 2013-06-18 | Microsoft Corporation | Data services based on gesture and location information of device |
US20090315775A1 (en) * | 2008-06-20 | 2009-12-24 | Microsoft Corporation | Mobile computing services based on devices with dynamic direction information |
US20090319166A1 (en) * | 2008-06-20 | 2009-12-24 | Microsoft Corporation | Mobile computing services based on devices with dynamic direction information |
US20090327094A1 (en) * | 2008-06-30 | 2009-12-31 | Microsoft Corporation | Platform independent ecosystem for creation, consumption and trade of user-generated digital content |
US8949713B1 (en) * | 2008-06-30 | 2015-02-03 | Amazon Technologies, Inc. | Version-specific request processing |
US8762313B2 (en) | 2008-07-25 | 2014-06-24 | Liveperson, Inc. | Method and system for creating a predictive model for targeting web-page to a surfer |
US8260846B2 (en) | 2008-07-25 | 2012-09-04 | Liveperson, Inc. | Method and system for providing targeted content to a surfer |
WO2010014539A2 (en) | 2008-07-28 | 2010-02-04 | Sony Corporation | Client device and associated methodology of accessing networked services |
US8655826B1 (en) * | 2008-08-01 | 2014-02-18 | Motion Picture Laboratories, Inc. | Processing and acting on rules for content recognition systems |
US8805844B2 (en) | 2008-08-04 | 2014-08-12 | Liveperson, Inc. | Expert search |
US8863234B2 (en) * | 2008-08-06 | 2014-10-14 | The Boeing Company | Collaborative security and decision making in a service-oriented environment |
KR101614945B1 (en) * | 2008-08-20 | 2016-04-25 | 삼성전자주식회사 | Method and apparatus for protecting of pravacy in home network |
US8219572B2 (en) * | 2008-08-29 | 2012-07-10 | Oracle International Corporation | System and method for searching enterprise application data |
US20100058466A1 (en) * | 2008-09-03 | 2010-03-04 | Dundas Data Visualization, Inc. | Systems and methods for providing security for software applications |
US8996658B2 (en) | 2008-09-03 | 2015-03-31 | Oracle International Corporation | System and method for integration of browser-based thin client applications within desktop rich client architecture |
US8799319B2 (en) | 2008-09-19 | 2014-08-05 | Oracle International Corporation | System and method for meta-data driven, semi-automated generation of web services based on existing applications |
US8850553B2 (en) * | 2008-09-12 | 2014-09-30 | Microsoft Corporation | Service binding |
US8271609B2 (en) * | 2008-09-15 | 2012-09-18 | Oracle International Corporation | Dynamic service invocation and service adaptation in BPEL SOA process |
US8296317B2 (en) * | 2008-09-15 | 2012-10-23 | Oracle International Corporation | Searchable object network |
US8335778B2 (en) * | 2008-09-17 | 2012-12-18 | Oracle International Corporation | System and method for semantic search in an enterprise application |
US9122520B2 (en) | 2008-09-17 | 2015-09-01 | Oracle International Corporation | Generic wait service: pausing a BPEL process |
US20100094674A1 (en) * | 2008-10-14 | 2010-04-15 | Michael Marriner | Supply Chain Management Systems and Methods |
JP4669901B2 (en) * | 2008-10-21 | 2011-04-13 | キヤノン株式会社 | Information processing apparatus, information processing method, and program |
US8640199B2 (en) * | 2008-10-23 | 2014-01-28 | Hewlett-Packard Developmet Company | Network service provision method, network device, network server and network |
US20100205024A1 (en) * | 2008-10-29 | 2010-08-12 | Haggai Shachar | System and method for applying in-depth data mining tools for participating websites |
US9892417B2 (en) | 2008-10-29 | 2018-02-13 | Liveperson, Inc. | System and method for applying tracing tools for network locations |
EP2192514A1 (en) * | 2008-11-26 | 2010-06-02 | Thomson Licensing | Method and system for processing digital content according to a workflow |
US8332654B2 (en) | 2008-12-08 | 2012-12-11 | Oracle International Corporation | Secure framework for invoking server-side APIs using AJAX |
US9124648B2 (en) | 2008-12-09 | 2015-09-01 | Microsoft Technology Licensing, Llc | Soft type binding for distributed systems |
WO2010067551A1 (en) * | 2008-12-10 | 2010-06-17 | 日本電気株式会社 | Shared random number management method and management system in secret communication network |
US8145593B2 (en) | 2008-12-11 | 2012-03-27 | Microsoft Corporation | Framework for web services exposing line of business applications |
US20100153565A1 (en) * | 2008-12-11 | 2010-06-17 | Microsoft Corporation | Connection management in line-of-business |
US8341141B2 (en) * | 2008-12-16 | 2012-12-25 | Krislov Clinton A | Method and system for automated document registration |
US8589372B2 (en) | 2008-12-16 | 2013-11-19 | Clinton A. Krislov | Method and system for automated document registration with cloud computing |
US8914351B2 (en) | 2008-12-16 | 2014-12-16 | Clinton A. Krislov | Method and system for secure automated document registration from social media networks |
US9444823B2 (en) * | 2008-12-24 | 2016-09-13 | Qualcomm Incorporated | Method and apparatus for providing network communication association information to applications and services |
US7849206B2 (en) * | 2009-01-13 | 2010-12-07 | Microsoft Corporation | Service for policy rule specification evaluation and enforcement on multiple communication modes |
US8140556B2 (en) * | 2009-01-20 | 2012-03-20 | Oracle International Corporation | Techniques for automated generation of queries for querying ontologies |
US7962574B2 (en) * | 2009-01-29 | 2011-06-14 | International Business Machines Corporation | Data integration in service oriented architectures |
US8301690B2 (en) * | 2009-02-06 | 2012-10-30 | International Business Machines Corporation | Correlator system for web services |
US20100212016A1 (en) * | 2009-02-18 | 2010-08-19 | Microsoft Corporation | Content protection interoperrability |
WO2010099351A1 (en) * | 2009-02-25 | 2010-09-02 | Aaron Marking | Content distribution with renewable content protection |
US8214401B2 (en) * | 2009-02-26 | 2012-07-03 | Oracle International Corporation | Techniques for automated generation of ontologies for enterprise applications |
US20120036495A2 (en) * | 2009-02-27 | 2012-02-09 | Research In Motion Limited | Method, apparatus and system for supporting polymorphic elements at run-time in portable computing devices |
US8458114B2 (en) * | 2009-03-02 | 2013-06-04 | Analog Devices, Inc. | Analog computation using numerical representations with uncertainty |
CN101499101A (en) * | 2009-03-10 | 2009-08-05 | 腾讯科技(深圳)有限公司 | Method and device for extracting characteristic relationship ring in social network |
US8843435B1 (en) | 2009-03-12 | 2014-09-23 | Pegasystems Inc. | Techniques for dynamic data processing |
WO2010102834A1 (en) * | 2009-03-12 | 2010-09-16 | Nec Europe Ltd. | Method for supporting management and exchange of distributed data of user or an entity |
US8929303B2 (en) * | 2009-04-06 | 2015-01-06 | Samsung Electronics Co., Ltd. | Control and data channels for advanced relay operation |
US20160098298A1 (en) * | 2009-04-24 | 2016-04-07 | Pegasystems Inc. | Methods and apparatus for integrated work management |
US8966005B2 (en) * | 2009-05-01 | 2015-02-24 | Telefonaktiebolatet L M Ericsson (Publ) | Information processing system and method providing a composed service |
WO2010134996A2 (en) | 2009-05-20 | 2010-11-25 | Intertrust Technologies Corporation | Content sharing systems and methods |
BRPI1013002A2 (en) | 2009-05-21 | 2016-03-29 | Intertrust Tech Corp | systems and methods for content delivery |
US8914903B1 (en) | 2009-06-03 | 2014-12-16 | Amdocs Software System Limited | System, method, and computer program for validating receipt of digital content by a client device |
US9602864B2 (en) | 2009-06-08 | 2017-03-21 | Time Warner Cable Enterprises Llc | Media bridge apparatus and methods |
US9866609B2 (en) | 2009-06-08 | 2018-01-09 | Time Warner Cable Enterprises Llc | Methods and apparatus for premises content distribution |
EP2264654A1 (en) * | 2009-06-19 | 2010-12-22 | Software AG | Consistency enforcement system for XML objects stored in an SOA-registry |
US8571994B2 (en) * | 2009-06-26 | 2013-10-29 | Disney Enterprises, Inc. | Method and system for allocating access to digital media content |
US8872767B2 (en) | 2009-07-07 | 2014-10-28 | Microsoft Corporation | System and method for converting gestures into digital graffiti |
CN101599995B (en) * | 2009-07-13 | 2012-01-11 | 中国传媒大学 | Directory distribution method and network architecture orienting to high-concurrency retrieval system |
US10045083B2 (en) | 2009-07-13 | 2018-08-07 | The Directv Group, Inc. | Satellite seeding of a peer-to-peer content distribution network |
EP2456118A4 (en) * | 2009-07-17 | 2013-05-01 | Alcatel Lucent | Digital rights management (drm) method and equipment in small and medium enterprise (sme) and method for providing drm service |
US8478820B2 (en) * | 2009-08-26 | 2013-07-02 | Qualcomm Incorporated | Methods and systems for service discovery management in peer-to-peer networks |
KR101669287B1 (en) * | 2009-09-01 | 2016-11-09 | 삼성전자주식회사 | Method and apparatus for controlling remote user interface device through third remote user interface device |
US9529694B2 (en) * | 2009-09-14 | 2016-12-27 | Oracle International Corporation | Techniques for adaptive trace logging |
US9734037B1 (en) * | 2009-09-15 | 2017-08-15 | Symantec Corporation | Mobile application sampling for performance and network behavior profiling |
US8837726B2 (en) * | 2009-10-16 | 2014-09-16 | Cisco Technology, Inc. | Content protection key encryptor for security providers |
KR101674903B1 (en) * | 2009-10-20 | 2016-11-11 | 삼성전자주식회사 | Method and apparatus for providing service using personal network |
US8478776B2 (en) * | 2009-10-30 | 2013-07-02 | Qualcomm Incorporated | Methods and systems for peer-to-peer network discovery using multi-user diversity |
US8055817B2 (en) * | 2009-10-30 | 2011-11-08 | International Business Machines Corporation | Efficient handling of queued-direct I/O requests and completions |
US8825818B2 (en) * | 2009-11-10 | 2014-09-02 | Qualcomm Incorporated | Host initiated connection to a device |
US20110119479A1 (en) * | 2009-11-17 | 2011-05-19 | Robert Cowie | EOOBE-Application to collect information for new computer and manufacturing process |
US8869108B2 (en) | 2009-11-18 | 2014-10-21 | Oracle International Corporation | Techniques related to customizations for composite applications |
US8631071B2 (en) * | 2009-12-17 | 2014-01-14 | International Business Machines Corporation | Recognition of and support for multiple versions of an enterprise canonical message model |
US9026412B2 (en) * | 2009-12-17 | 2015-05-05 | International Business Machines Corporation | Managing and maintaining scope in a service oriented architecture industry model repository |
US9111004B2 (en) | 2009-12-17 | 2015-08-18 | International Business Machines Corporation | Temporal scope translation of meta-models using semantic web technologies |
US20130232198A1 (en) * | 2009-12-21 | 2013-09-05 | Arbitron Inc. | System and Method for Peer-to-Peer Distribution of Media Exposure Data |
US20110153391A1 (en) * | 2009-12-21 | 2011-06-23 | Michael Tenbrock | Peer-to-peer privacy panel for audience measurement |
US9052919B2 (en) | 2010-01-15 | 2015-06-09 | Apple Inc. | Specialized network fileserver |
US8934645B2 (en) | 2010-01-26 | 2015-01-13 | Apple Inc. | Interaction of sound, silent and mute modes in an electronic device |
US9244965B2 (en) * | 2010-02-22 | 2016-01-26 | Thoughtwire Holdings Corp. | Method and system for sharing data between software systems |
US8730928B2 (en) * | 2010-02-23 | 2014-05-20 | Qualcomm Incorporated | Enhancements for increased spatial reuse in ad-hoc networks |
US8683370B2 (en) | 2010-03-01 | 2014-03-25 | Dundas Data Visualization, Inc. | Systems and methods for generating data visualization dashboards |
US8612633B2 (en) * | 2010-03-31 | 2013-12-17 | Microsoft Corporation | Virtual machine fast emulation assist |
US8965801B2 (en) * | 2010-03-31 | 2015-02-24 | International Business Machines Corporation | Provision of support services as a service |
WO2011127049A1 (en) | 2010-04-07 | 2011-10-13 | Liveperson, Inc. | System and method for dynamically enabling customized web content and applications |
US8570907B2 (en) | 2010-04-07 | 2013-10-29 | Apple Inc. | Multi-network architecture for media data exchange |
US20110252117A1 (en) * | 2010-04-12 | 2011-10-13 | Swee Huat Sng | Devices and Methods for Redirecting a Browser to Access Computer Resource Behind a Network Firewall |
US8868758B2 (en) * | 2010-05-04 | 2014-10-21 | Microsoft Corporation | Provider connection framework |
CN101833506B (en) * | 2010-05-04 | 2012-05-30 | 中国人民解放军国防科学技术大学 | Authentication method of service interface with long transaction characteristics |
US9614641B2 (en) | 2010-05-12 | 2017-04-04 | Qualcomm Incorporated | Resource coordination for peer-to-peer groups through distributed negotiation |
US10657507B2 (en) * | 2010-05-17 | 2020-05-19 | Adobe Inc. | Migration between digital rights management systems without content repackaging |
US8914482B2 (en) | 2010-05-26 | 2014-12-16 | Microsoft Corporation | Translation of technology-agnostic management commands into multiple management protocols |
US8615585B2 (en) | 2010-05-28 | 2013-12-24 | International Business Machines Corporation | Ontology based resource provisioning and management for services |
US8700777B2 (en) | 2010-05-28 | 2014-04-15 | International Business Machines Corporation | Extensible support system for service offerings |
US8423658B2 (en) * | 2010-06-10 | 2013-04-16 | Research In Motion Limited | Method and system to release internet protocol (IP) multimedia subsystem (IMS), session initiation protocol (SIP), IP-connectivity access network (IP-CAN) and radio access network (RAN) networking resources when IP television (IPTV) session is paused |
US8451789B2 (en) | 2010-06-15 | 2013-05-28 | Nokia Corporation | Method to request resources in TV white spaces type environment |
US8874896B2 (en) | 2010-06-18 | 2014-10-28 | Intertrust Technologies Corporation | Secure processing systems and methods |
US9189649B2 (en) * | 2010-06-25 | 2015-11-17 | International Business Machines Corporation | Security model for workflows aggregating third party secure services |
US8595197B2 (en) | 2010-06-29 | 2013-11-26 | International Business Machines Corporation | Message validation in a service-oriented architecture |
CN102143614B (en) * | 2010-07-01 | 2014-02-26 | 华为终端有限公司 | Updating method and home gateway equipment |
US9906838B2 (en) | 2010-07-12 | 2018-02-27 | Time Warner Cable Enterprises Llc | Apparatus and methods for content delivery and message exchange across multiple content delivery networks |
US8799177B1 (en) * | 2010-07-29 | 2014-08-05 | Intuit Inc. | Method and apparatus for building small business graph from electronic business data |
WO2012021729A1 (en) * | 2010-08-11 | 2012-02-16 | Aaron Marking | Simple nonautonomous peering network media |
US8412247B2 (en) | 2010-09-03 | 2013-04-02 | Nokia Corporation | Method for generating a coexistence value to define fair resource share between secondary networks |
US8385286B2 (en) | 2010-09-03 | 2013-02-26 | Nokia Corporation | Resource sharing between secondary networks |
US8711736B2 (en) | 2010-09-16 | 2014-04-29 | Apple Inc. | Audio processing in a multi-participant conference |
US9015493B2 (en) * | 2010-09-16 | 2015-04-21 | Microsoft Technology Licensing, Llc | Multitenant-aware protection service |
US8984034B2 (en) * | 2010-09-28 | 2015-03-17 | Schneider Electric USA, Inc. | Calculation engine and calculation providers |
US20120089902A1 (en) | 2010-10-07 | 2012-04-12 | Dundas Data Visualization, Inc. | Systems and methods for dashboard image generation |
US9563751B1 (en) * | 2010-10-13 | 2017-02-07 | The Boeing Company | License utilization management system service suite |
US20120106364A1 (en) * | 2010-10-29 | 2012-05-03 | Nokia Corporation | Heterogeneous coexistence management in secondary networks |
US10285094B2 (en) | 2010-11-05 | 2019-05-07 | Mark Cummings | Mobile base station network |
US9311108B2 (en) | 2010-11-05 | 2016-04-12 | Mark Cummings | Orchestrating wireless network operations |
US10694402B2 (en) | 2010-11-05 | 2020-06-23 | Mark Cummings | Security orchestration and network immune system deployment framework |
US10687250B2 (en) | 2010-11-05 | 2020-06-16 | Mark Cummings | Mobile base station network |
US10531516B2 (en) | 2010-11-05 | 2020-01-07 | Mark Cummings | Self organizing system to implement emerging topologies |
CN105872950B (en) * | 2010-11-19 | 2020-12-04 | Iot控股公司 | Machine-to-machine (M2M) interface procedure for resource advertisement and de-advertisement |
US8381218B2 (en) | 2010-11-30 | 2013-02-19 | Microsoft Corporation | Managing groups of computing entities |
GB2500537A (en) * | 2010-12-03 | 2013-09-25 | Titus Inc | Method and system of hierarchical metadata management and application |
AU2011340789B2 (en) | 2010-12-08 | 2014-03-27 | Remasys Pty Ltd | End-user performance monitoring for mobile applications |
US8918465B2 (en) * | 2010-12-14 | 2014-12-23 | Liveperson, Inc. | Authentication of service requests initiated from a social networking site |
US9350598B2 (en) | 2010-12-14 | 2016-05-24 | Liveperson, Inc. | Authentication of service requests using a communications initiation feature |
WO2012093835A2 (en) * | 2011-01-03 | 2012-07-12 | 주식회사 케이티 | Apparatus for transmitting delay-allowance contents for mobile p2p service and method thereof |
US20120180108A1 (en) | 2011-01-06 | 2012-07-12 | Dundas Data Visualization, Inc. | Methods and systems for providing a discussion thread to key performance indicator information |
CN102075574B (en) * | 2011-01-07 | 2013-02-06 | 北京邮电大学 | Web-based collaborative learning (WBCL) system and method |
US8989884B2 (en) | 2011-01-11 | 2015-03-24 | Apple Inc. | Automatic audio configuration based on an audio output device |
US8363602B2 (en) | 2011-01-14 | 2013-01-29 | Nokia Corporation | Method, apparatus and computer program product for resource allocation of coexistent secondary networks |
JP5664273B2 (en) | 2011-01-21 | 2015-02-04 | ソニー株式会社 | Wireless communication device, program, and wireless communication system |
US10445113B2 (en) * | 2011-03-01 | 2019-10-15 | International Business Machines Corporation | Method and system for setting the user interface to suit the display screen of an electronic device |
EP2506519A1 (en) * | 2011-03-25 | 2012-10-03 | EADS Deutschland GmbH | Method for determining integrity in an evolutionary collabroative information system |
GB201105765D0 (en) | 2011-04-05 | 2011-05-18 | Visa Europe Ltd | Payment system |
KR20120122616A (en) * | 2011-04-29 | 2012-11-07 | 삼성전자주식회사 | Method and apparatus for providing service |
US20120284804A1 (en) | 2011-05-02 | 2012-11-08 | Authentec, Inc. | System and method for protecting digital contents with digital rights management (drm) |
US9202024B2 (en) * | 2011-05-02 | 2015-12-01 | Inside Secure | Method for playing digital contents projected with a DRM (digital rights management) scheme and corresponding system |
US8514802B2 (en) | 2011-05-04 | 2013-08-20 | Nokia Corporation | Method to evaluate fairness of resource allocations in shared bands |
WO2012157044A1 (en) * | 2011-05-13 | 2012-11-22 | 株式会社日立製作所 | Task flow management method, device, and program |
US8478660B2 (en) * | 2011-05-19 | 2013-07-02 | Telefonica, S.A. | Method and system for improving the selection of services in a service exchange environment |
US9317341B2 (en) | 2011-05-24 | 2016-04-19 | Microsoft Technology Licensing, Llc. | Dynamic attribute resolution for orchestrated management |
US9325814B2 (en) * | 2011-06-02 | 2016-04-26 | Numerex Corp. | Wireless SNMP agent gateway |
WO2013003932A1 (en) * | 2011-07-04 | 2013-01-10 | Research In Motion Limited | System and method for sharing mobile device content |
US20130013358A1 (en) * | 2011-07-08 | 2013-01-10 | Mark Sears | E-commerce content management system for dealer self-routing |
US9131330B2 (en) * | 2011-07-15 | 2015-09-08 | Telefonaktiebolaget L M Ericsson (Publ) | M2M services enablement architecture for cellular access networks |
US8929831B2 (en) | 2011-07-18 | 2015-01-06 | Nokia Corporation | Method, apparatus, and computer program product for wireless network discovery based on geographical location |
CA2842260A1 (en) * | 2011-07-20 | 2013-01-24 | Sonos, Inc. | Web-based music partner systems and methods |
US9270471B2 (en) * | 2011-08-10 | 2016-02-23 | Microsoft Technology Licensing, Llc | Client-client-server authentication |
CN102938878B (en) * | 2011-08-15 | 2016-03-23 | 上海贝尔股份有限公司 | The MBMS information notice method of neighbor cell and corresponding equipment |
JP2013058006A (en) * | 2011-09-07 | 2013-03-28 | Fuji Xerox Co Ltd | Information processor and information processing program |
KR101240552B1 (en) * | 2011-09-26 | 2013-03-11 | 삼성에스디에스 주식회사 | System and method for managing media keys and for transmitting/receiving peer-to-peer messages using the media keys |
CN103959298B (en) * | 2011-09-29 | 2017-04-05 | Lg电子株式会社 | The method, apparatus and system of content are downloaded based on Authority Verification |
US8954942B2 (en) | 2011-09-30 | 2015-02-10 | Oracle International Corporation | Optimizations using a BPEL compiler |
EP2764689A4 (en) * | 2011-10-03 | 2015-04-29 | Thomson Licensing | Method and apparatus for processing content offers in a digital locker system |
US9832649B1 (en) * | 2011-10-12 | 2017-11-28 | Technology Business Management, Limted | Secure ID authentication |
DE102011054842A1 (en) * | 2011-10-27 | 2013-05-02 | Wincor Nixdorf International Gmbh | Device for handling notes of value and / or coins and method for initializing and operating such a device |
CN103117983B (en) * | 2011-11-16 | 2015-11-04 | 中国移动通信集团公司 | The method for designing of data service request answer method and data, services protocol stack |
US20130151589A1 (en) * | 2011-11-17 | 2013-06-13 | Market76 | Computer-based system for use in providing advisory services |
US9019909B2 (en) | 2011-12-06 | 2015-04-28 | Nokia Corporation | Method, apparatus, and computer program product for coexistence management |
US8751800B1 (en) | 2011-12-12 | 2014-06-10 | Google Inc. | DRM provider interoperability |
US9195936B1 (en) | 2011-12-30 | 2015-11-24 | Pegasystems Inc. | System and method for updating or modifying an application without manual coding |
US8943002B2 (en) | 2012-02-10 | 2015-01-27 | Liveperson, Inc. | Analytics driven engagement |
EP2815593A4 (en) | 2012-02-17 | 2015-08-12 | Intertrust Tech Corp | Systems and methods for vehicle policy enforcement |
AU2013200916B2 (en) | 2012-02-20 | 2014-09-11 | Kl Data Security Pty Ltd | Cryptographic Method and System |
WO2013126615A1 (en) * | 2012-02-21 | 2013-08-29 | Pulselocker, Inc. | Method and apparatus for limiting access to data by process or computer function with stateless encryption |
US9621458B2 (en) | 2012-02-21 | 2017-04-11 | Qualcomm Incorporated | Internet routing over a service-oriented architecture bus |
US9350814B2 (en) * | 2012-02-21 | 2016-05-24 | Qualcomm Incorporated | Internet protocol connectivity over a service-oriented architecture bus |
US8953490B2 (en) | 2012-03-02 | 2015-02-10 | Blackberry Limited | Methods and apparatus for use in facilitating Wi-Fi peer-to-peer (P2P) wireless networking |
US8805941B2 (en) | 2012-03-06 | 2014-08-12 | Liveperson, Inc. | Occasionally-connected computing interface |
US9473946B2 (en) | 2012-03-12 | 2016-10-18 | Nokia Technologies Oy | Method, apparatus, and computer program product for temporary release of resources in radio networks |
US8909274B2 (en) | 2012-03-12 | 2014-12-09 | Nokia Corporation | Method, apparatus, and computer program product for resource allocation conflict handling in RF frequency bands |
US9503512B2 (en) | 2012-03-21 | 2016-11-22 | Intertrust Technologies Corporation | Distributed computation systems and methods |
EP2832073A4 (en) * | 2012-03-29 | 2015-12-16 | Intel Corp | Device-to-device tapping service layer |
US8813246B2 (en) | 2012-04-23 | 2014-08-19 | Inside Secure | Method for playing digital contents protected with a DRM (digital right management) scheme and corresponding system |
US9563336B2 (en) | 2012-04-26 | 2017-02-07 | Liveperson, Inc. | Dynamic user interface customization |
US9672196B2 (en) | 2012-05-15 | 2017-06-06 | Liveperson, Inc. | Methods and systems for presenting specialized content using campaign metrics |
US9813496B2 (en) * | 2012-05-23 | 2017-11-07 | Infosys Limited | Method and apparatus for collaborating in a work environment |
EP2860653A4 (en) * | 2012-06-07 | 2016-01-27 | Toshiba Kk | Security adapter program and device |
CN104603813A (en) | 2012-06-11 | 2015-05-06 | 英特托拉斯技术公司 | Data collection and analysis systems and methods |
US9654900B2 (en) | 2012-06-29 | 2017-05-16 | Interdigital Patent Holdings, Inc. | Service-based discovery in networks |
US20140007197A1 (en) * | 2012-06-29 | 2014-01-02 | Michael John Wray | Delegation within a computing environment |
US20140012699A1 (en) | 2012-07-06 | 2014-01-09 | Oracle International Corporation | Service design and order fulfillment system with commercial decoupling |
IN2015KN00242A (en) | 2012-07-20 | 2015-06-12 | Intertrust Tech Corp | |
DE102012015527B4 (en) * | 2012-08-04 | 2017-02-09 | Audi Ag | Method for using a second infotainment system by means of a first infotainment system and vehicle |
US9378073B2 (en) * | 2012-08-14 | 2016-06-28 | International Business Machines Corporation | Remote procedure call for a distributed system |
US8942701B2 (en) | 2012-08-14 | 2015-01-27 | Nokia Corporation | Method, apparatus, and computer program product for transferring responsibility between network controllers managing coexistence in radio frequency spectrum |
US9178771B2 (en) * | 2012-08-23 | 2015-11-03 | Hewlett-Packard Development Company, L.P. | Determining the type of a network tier |
CN102868594B (en) * | 2012-09-12 | 2015-05-27 | 浪潮(北京)电子信息产业有限公司 | Method and device for message processing |
US9363133B2 (en) | 2012-09-28 | 2016-06-07 | Avaya Inc. | Distributed application of enterprise policies to Web Real-Time Communications (WebRTC) interactive sessions, and related methods, systems, and computer-readable media |
US10164929B2 (en) * | 2012-09-28 | 2018-12-25 | Avaya Inc. | Intelligent notification of requests for real-time online interaction via real-time communications and/or markup protocols, and related methods, systems, and computer-readable media |
RU2519470C1 (en) * | 2012-10-17 | 2014-06-10 | Общество с ограниченной ответственностью "Сетевизор" | Method for secure distribution of multimedia information by peer-to-peer decentralised network deployment and decentralised network for realising said method |
US9532224B2 (en) * | 2012-11-05 | 2016-12-27 | Electronics And Telecommunications Research Institute | Method of device-to-device discovery and apparatus thereof |
US9736652B2 (en) | 2012-11-06 | 2017-08-15 | Intertrust Technologies Corporation | Activity recognition systems and methods |
US10598503B2 (en) | 2012-11-07 | 2020-03-24 | Intertrust Technologies Corporation | Vehicle charging path optimization systems and methods |
JP2016504651A (en) | 2012-11-07 | 2016-02-12 | インタートラスト テクノロジーズ コーポレイション | Personalized data management system and method |
US9107089B2 (en) | 2012-11-09 | 2015-08-11 | Nokia Technologies Oy | Method, apparatus, and computer program product for location based query for interferer discovery in coexistence management system |
US9565472B2 (en) | 2012-12-10 | 2017-02-07 | Time Warner Cable Enterprises Llc | Apparatus and methods for content transfer protection |
DE112012007242T5 (en) * | 2012-12-20 | 2016-01-14 | Mitsubishi Electric Corp. | Control system, program transmission device, authentication server, program protection method, program transmission method and program for program transmission device |
US10015293B2 (en) | 2013-02-08 | 2018-07-03 | Iot Holdings, Inc. | Method and apparatus for incorporating an internet of things (IoT) service interface protocol layer in a node |
US20140282786A1 (en) | 2013-03-12 | 2014-09-18 | Time Warner Cable Enterprises Llc | Methods and apparatus for providing and uploading content to personalized network storage |
CN105378774A (en) | 2013-03-12 | 2016-03-02 | 英特托拉斯技术公司 | Secure transaction systems and methods |
US9584544B2 (en) * | 2013-03-12 | 2017-02-28 | Red Hat Israel, Ltd. | Secured logical component for security in a virtual environment |
US9626489B2 (en) | 2013-03-13 | 2017-04-18 | Intertrust Technologies Corporation | Object rendering systems and methods |
US8799053B1 (en) * | 2013-03-13 | 2014-08-05 | Paul R. Goldberg | Secure consumer data exchange method, apparatus, and system therfor |
US9294458B2 (en) | 2013-03-14 | 2016-03-22 | Avaya Inc. | Managing identity provider (IdP) identifiers for web real-time communications (WebRTC) interactive flows, and related methods, systems, and computer-readable media |
US9215075B1 (en) | 2013-03-15 | 2015-12-15 | Poltorak Technologies Llc | System and method for secure relayed communications from an implantable medical device |
US9203813B2 (en) * | 2013-03-15 | 2015-12-01 | Panasonic Intellectual Property Management Co., Ltd. | Content distribution method, content distribution system, source device, and sink device |
US9299049B2 (en) * | 2013-03-15 | 2016-03-29 | Sap Se | Contract-based process integration |
US9066153B2 (en) | 2013-03-15 | 2015-06-23 | Time Warner Cable Enterprises Llc | Apparatus and methods for multicast delivery of content in a content delivery network |
US9130900B2 (en) * | 2013-03-15 | 2015-09-08 | Bao Tran | Assistive agent |
US10368255B2 (en) | 2017-07-25 | 2019-07-30 | Time Warner Cable Enterprises Llc | Methods and apparatus for client-based dynamic control of connections to co-existing radio access networks |
US9716589B2 (en) * | 2013-04-22 | 2017-07-25 | Unisys Corporation | Secured communications arrangement applying internet protocol security |
US9306981B2 (en) | 2013-04-24 | 2016-04-05 | Intertrust Technologies Corporation | Bioinformatic processing systems and methods |
US9300555B2 (en) | 2013-06-05 | 2016-03-29 | Globalfoundries Inc. | Peer-to-peer ad hoc network system for monitoring a presence of members of a group |
US10205624B2 (en) | 2013-06-07 | 2019-02-12 | Avaya Inc. | Bandwidth-efficient archiving of real-time interactive flows, and related methods, systems, and computer-readable media |
CN104243144B (en) * | 2013-06-08 | 2018-03-13 | 科大国盾量子技术股份有限公司 | A kind of communication key distribution method based on Android intelligent mobile terminal |
US10191733B2 (en) | 2013-06-25 | 2019-01-29 | Sap Se | Software change process orchestration in a runtime environment |
US9558460B2 (en) * | 2013-06-28 | 2017-01-31 | Lexmark International Technology Sarl | Methods of analyzing software systems having service components |
US9961052B2 (en) * | 2013-06-28 | 2018-05-01 | Extreme Networks, Inc. | Virtualized host ID key sharing |
US9065969B2 (en) | 2013-06-30 | 2015-06-23 | Avaya Inc. | Scalable web real-time communications (WebRTC) media engines, and related methods, systems, and computer-readable media |
US9525718B2 (en) | 2013-06-30 | 2016-12-20 | Avaya Inc. | Back-to-back virtual web real-time communications (WebRTC) agents, and related methods, systems, and computer-readable media |
US8949998B2 (en) * | 2013-07-01 | 2015-02-03 | Medidata Solutions, Inc. | Method and system for maintaining data in a substantiated state |
US9112840B2 (en) | 2013-07-17 | 2015-08-18 | Avaya Inc. | Verifying privacy of web real-time communications (WebRTC) media channels via corresponding WebRTC data channels, and related methods, systems, and computer-readable media |
US9313568B2 (en) | 2013-07-23 | 2016-04-12 | Chicago Custom Acoustics, Inc. | Custom earphone with dome in the canal |
KR102084104B1 (en) * | 2013-07-25 | 2020-03-03 | 콘비다 와이어리스, 엘엘씨 | End-to-end m2m service layer sessions |
US9614890B2 (en) | 2013-07-31 | 2017-04-04 | Avaya Inc. | Acquiring and correlating web real-time communications (WEBRTC) interactive flow characteristics, and related methods, systems, and computer-readable media |
US9467450B2 (en) * | 2013-08-21 | 2016-10-11 | Medtronic, Inc. | Data driven schema for patient data exchange system |
US9531808B2 (en) | 2013-08-22 | 2016-12-27 | Avaya Inc. | Providing data resource services within enterprise systems for resource level sharing among multiple applications, and related methods, systems, and computer-readable media |
US9363150B2 (en) * | 2013-09-05 | 2016-06-07 | International Business Machines Corporation | Policy driven auto-transitioning framework for governed objects in service registries |
KR20180095126A (en) * | 2013-09-20 | 2018-08-24 | 콘비다 와이어리스, 엘엘씨 | Enhanced m2m content management based on interest |
US10225212B2 (en) | 2013-09-26 | 2019-03-05 | Avaya Inc. | Providing network management based on monitoring quality of service (QOS) characteristics of web real-time communications (WEBRTC) interactive flows, and related methods, systems, and computer-readable media |
US10033693B2 (en) | 2013-10-01 | 2018-07-24 | Nicira, Inc. | Distributed identity-based firewalls |
US9887837B2 (en) * | 2013-10-31 | 2018-02-06 | Verimatrix, Inc. | System and method for synchronized key derivation across multiple conditional access servers |
US10263952B2 (en) | 2013-10-31 | 2019-04-16 | Avaya Inc. | Providing origin insight for web applications via session traversal utilities for network address translation (STUN) messages, and related methods, systems, and computer-readable media |
US9769214B2 (en) | 2013-11-05 | 2017-09-19 | Avaya Inc. | Providing reliable session initiation protocol (SIP) signaling for web real-time communications (WEBRTC) interactive flows, and related methods, systems, and computer-readable media |
CN103595714A (en) * | 2013-11-08 | 2014-02-19 | 福建省视通光电网络有限公司 | Method using WEB service channel to achieve data transmission |
KR101510336B1 (en) * | 2013-11-14 | 2015-04-07 | 현대자동차 주식회사 | Device for inspecting driver assistance system of vehicle |
CN103618795B (en) * | 2013-11-29 | 2018-06-05 | 百度在线网络技术(北京)有限公司 | Document handling method, the client and server of striding equipment |
US9697061B1 (en) | 2013-12-18 | 2017-07-04 | Amazon Technologies, Inc. | Parameter delegation for encapsulated services |
US9922322B2 (en) | 2013-12-19 | 2018-03-20 | Visa International Service Association | Cloud-based transactions with magnetic secure transmission |
US11164176B2 (en) | 2013-12-19 | 2021-11-02 | Visa International Service Association | Limited-use keys and cryptograms |
US10129243B2 (en) | 2013-12-27 | 2018-11-13 | Avaya Inc. | Controlling access to traversal using relays around network address translation (TURN) servers using trusted single-use credentials |
KR101548210B1 (en) * | 2014-01-06 | 2015-08-31 | 고려대학교 산학협력단 | Method for detecting bypass access through anonymous network using round trip time variation |
US9826051B2 (en) * | 2014-01-21 | 2017-11-21 | Amadeus S.A.S. | Content integration framework |
WO2015116855A1 (en) | 2014-01-29 | 2015-08-06 | Intertrust Technologies Corporation | Secure application processing systems and methods |
US11178131B2 (en) * | 2014-03-14 | 2021-11-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Systems and methods related to establishing a temporary trust relationship between a network-based media service and a digital media renderer |
JP5765457B2 (en) * | 2014-03-19 | 2015-08-19 | 株式会社ナカヨ | Information collection method and information terminal |
US11386442B2 (en) | 2014-03-31 | 2022-07-12 | Liveperson, Inc. | Online behavioral predictor |
US10581927B2 (en) | 2014-04-17 | 2020-03-03 | Avaya Inc. | Providing web real-time communications (WebRTC) media services via WebRTC-enabled media servers, and related methods, systems, and computer-readable media |
US9749363B2 (en) | 2014-04-17 | 2017-08-29 | Avaya Inc. | Application of enterprise policies to web real-time communications (WebRTC) interactive sessions using an enterprise session initiation protocol (SIP) engine, and related methods, systems, and computer-readable media |
MX2016013928A (en) * | 2014-04-23 | 2017-04-06 | Remote Media LLC | Smart routing synchronization system and methods for socializing a synthetic rebroadcast and group stream. |
AU2015264124B2 (en) | 2014-05-21 | 2019-05-09 | Visa International Service Association | Offline authentication |
US9621940B2 (en) | 2014-05-29 | 2017-04-11 | Time Warner Cable Enterprises Llc | Apparatus and methods for recording, accessing, and delivering packetized content |
US10162855B2 (en) | 2014-06-09 | 2018-12-25 | Dundas Data Visualization, Inc. | Systems and methods for optimizing data analysis |
US11540148B2 (en) | 2014-06-11 | 2022-12-27 | Time Warner Cable Enterprises Llc | Methods and apparatus for access point location |
WO2015191965A2 (en) * | 2014-06-13 | 2015-12-17 | Convida Wireless, Llc | Automated service profiling and orchestration |
US9215228B1 (en) * | 2014-06-17 | 2015-12-15 | Cisco Technology, Inc. | Authentication of devices having unequal capabilities |
US9912705B2 (en) | 2014-06-24 | 2018-03-06 | Avaya Inc. | Enhancing media characteristics during web real-time communications (WebRTC) interactive sessions by using session initiation protocol (SIP) endpoints, and related methods, systems, and computer-readable media |
US10068012B2 (en) | 2014-06-27 | 2018-09-04 | Sonos, Inc. | Music discovery |
GB2530245A (en) * | 2014-07-15 | 2016-03-23 | Piksel Inc | Controlling delivery of encrypted media assets |
CN104092777B (en) * | 2014-07-29 | 2017-12-26 | 深圳市富途网络科技有限公司 | The method and its system of the layout setting and server sync storage of client |
US9344455B2 (en) * | 2014-07-30 | 2016-05-17 | Motorola Solutions, Inc. | Apparatus and method for sharing a hardware security module interface in a collaborative network |
US9531749B2 (en) | 2014-08-07 | 2016-12-27 | International Business Machines Corporation | Prevention of query overloading in a server application |
US9775029B2 (en) | 2014-08-22 | 2017-09-26 | Visa International Service Association | Embedding cloud-based functionalities in a communication device |
CN105407444A (en) * | 2014-09-05 | 2016-03-16 | 青岛海尔智能家电科技有限公司 | Method and device for gathering responses |
US20160105400A1 (en) * | 2014-10-08 | 2016-04-14 | Time Warner Cable Enterprises Llc | Apparatus and methods for data transfer beteween a plurality of user devices |
US10469396B2 (en) | 2014-10-10 | 2019-11-05 | Pegasystems, Inc. | Event processing with enhanced throughput |
US9781004B2 (en) * | 2014-10-16 | 2017-10-03 | Cisco Technology, Inc. | Discovering and grouping application endpoints in a network environment |
US9935833B2 (en) | 2014-11-05 | 2018-04-03 | Time Warner Cable Enterprises Llc | Methods and apparatus for determining an optimized wireless interface installation configuration |
US20160132317A1 (en) | 2014-11-06 | 2016-05-12 | Intertrust Technologies Corporation | Secure Application Distribution Systems and Methods |
US9609541B2 (en) | 2014-12-31 | 2017-03-28 | Motorola Solutions, Inc. | Method and apparatus for device collaboration via a hybrid network |
WO2016112338A1 (en) | 2015-01-08 | 2016-07-14 | Intertrust Technologies Corporation | Cryptographic systems and methods |
US9401933B1 (en) | 2015-01-20 | 2016-07-26 | Cisco Technology, Inc. | Classification of security policies across multiple security products |
US9521167B2 (en) | 2015-01-20 | 2016-12-13 | Cisco Technology, Inc. | Generalized security policy user interface |
US9571524B2 (en) | 2015-01-20 | 2017-02-14 | Cisco Technology, Inc. | Creation of security policy templates and security policies based on the templates |
US9680875B2 (en) | 2015-01-20 | 2017-06-13 | Cisco Technology, Inc. | Security policy unification across different security products |
US9531757B2 (en) | 2015-01-20 | 2016-12-27 | Cisco Technology, Inc. | Management of security policies across multiple security products |
US10069928B1 (en) * | 2015-01-21 | 2018-09-04 | Amazon Technologies, Inc. | Translating requests/responses between communication channels having different protocols |
MX2017010944A (en) | 2015-02-26 | 2018-07-06 | Sio2 Medical Products Inc | Cycloolefin polymer container with a scratch resistant and anti-static coating. |
US9906604B2 (en) * | 2015-03-09 | 2018-02-27 | Dell Products L.P. | System and method for dynamic discovery of web services for a management console |
US10630686B2 (en) * | 2015-03-12 | 2020-04-21 | Fornetix Llc | Systems and methods for organizing devices in a policy hierarchy |
US20160267481A1 (en) * | 2015-03-13 | 2016-09-15 | Svetoslav Lazarov Gramenov | System and method for distributed money supply |
US10965459B2 (en) | 2015-03-13 | 2021-03-30 | Fornetix Llc | Server-client key escrow for applied key management system and process |
CN104717073B (en) * | 2015-03-19 | 2018-09-18 | 张文 | Personal information shared system and its personal information sharing method and identity identifying method |
US10063375B2 (en) * | 2015-04-20 | 2018-08-28 | Microsoft Technology Licensing, Llc | Isolation of trusted input/output devices |
WO2016172484A1 (en) | 2015-04-23 | 2016-10-27 | Convida Wirless, Llc | Device and method for adding an m2m service |
US9641540B2 (en) | 2015-05-19 | 2017-05-02 | Cisco Technology, Inc. | User interface driven translation, comparison, unification, and deployment of device neutral network security policies |
WO2016196806A1 (en) | 2015-06-02 | 2016-12-08 | Liveperson, Inc. | Dynamic communication routing based on consistency weighting and routing rules |
US10255921B2 (en) * | 2015-07-31 | 2019-04-09 | Google Llc | Managing dialog data providers |
CN106407832B (en) * | 2015-08-03 | 2021-03-09 | 阿里巴巴集团控股有限公司 | Method and equipment for data access control |
US10909186B2 (en) * | 2015-09-30 | 2021-02-02 | Oracle International Corporation | Multi-tenant customizable composites |
US10623514B2 (en) | 2015-10-13 | 2020-04-14 | Home Box Office, Inc. | Resource response expansion |
US10656935B2 (en) | 2015-10-13 | 2020-05-19 | Home Box Office, Inc. | Maintaining and updating software versions via hierarchy |
US10348816B2 (en) | 2015-10-14 | 2019-07-09 | Adp, Llc | Dynamic proxy server |
US10623528B2 (en) | 2015-10-14 | 2020-04-14 | Adp, Llc | Enterprise application ecosystem operating system |
US9860346B2 (en) | 2015-10-14 | 2018-01-02 | Adp, Llc | Dynamic application programming interface builder |
US11171924B2 (en) | 2015-10-14 | 2021-11-09 | Adp, Inc. | Customized web services gateway |
US10317243B2 (en) | 2015-10-15 | 2019-06-11 | Intertrust Technologies Corporation | Sensor information management systems and methods |
US10600442B2 (en) * | 2015-10-20 | 2020-03-24 | Sony Corporation | Information processing device, information processing method, and program |
US9342388B1 (en) * | 2015-12-02 | 2016-05-17 | International Business Machines Corporation | Dynamic queue alias |
US9986578B2 (en) | 2015-12-04 | 2018-05-29 | Time Warner Cable Enterprises Llc | Apparatus and methods for selective data network access |
US10305996B2 (en) * | 2015-12-07 | 2019-05-28 | Prn Productions, Inc. | System, device, and method for service coordination |
US10225084B1 (en) * | 2015-12-29 | 2019-03-05 | EMC IP Holding Company LLC | Method, apparatus and computer program product for securely sharing a content item |
US9992232B2 (en) | 2016-01-14 | 2018-06-05 | Cisco Technology, Inc. | Policy block creation with context-sensitive policy line classification |
US9918345B2 (en) | 2016-01-20 | 2018-03-13 | Time Warner Cable Enterprises Llc | Apparatus and method for wireless network services in moving vehicles |
US10880281B2 (en) | 2016-02-26 | 2020-12-29 | Fornetix Llc | Structure of policies for evaluating key attributes of encryption keys |
US10860086B2 (en) | 2016-02-26 | 2020-12-08 | Fornetix Llc | Policy-enabled encryption keys having complex logical operations |
US10492034B2 (en) | 2016-03-07 | 2019-11-26 | Time Warner Cable Enterprises Llc | Apparatus and methods for dynamic open-access networks |
US20170296458A1 (en) * | 2016-04-14 | 2017-10-19 | The Procter & Gamble Company | Cosmetic composition |
US10762559B2 (en) | 2016-04-15 | 2020-09-01 | Adp, Llc | Management of payroll lending within an enterprise system |
US10187367B2 (en) | 2016-05-11 | 2019-01-22 | Iheartmedia Management Services, Inc. | Licensing authentication via mobile device |
US20170329526A1 (en) * | 2016-05-13 | 2017-11-16 | Hewlett Packard Enterprise Development Lp | Interoperable capabilities |
US10698599B2 (en) | 2016-06-03 | 2020-06-30 | Pegasystems, Inc. | Connecting graphical shapes using gestures |
US10630085B2 (en) | 2016-06-06 | 2020-04-21 | Omnicharge, Inc. | Portable power solutions |
US10476965B1 (en) * | 2016-06-06 | 2019-11-12 | Omnicharge, Inc. | Apparatus, system and method for sharing tangible objects |
US11237595B2 (en) | 2016-06-06 | 2022-02-01 | Omnicharge, Inc. | Portable power solutions |
US10164858B2 (en) | 2016-06-15 | 2018-12-25 | Time Warner Cable Enterprises Llc | Apparatus and methods for monitoring and diagnosing a wireless network |
RU2649788C1 (en) * | 2016-06-16 | 2018-04-04 | Общество С Ограниченной Ответственностью "Яндекс" | Method and system for transaction request processing in distributed data processing systems |
WO2018004596A1 (en) * | 2016-06-30 | 2018-01-04 | Intel Corporation | Technologies for serializable binary data distribution |
US10698647B2 (en) | 2016-07-11 | 2020-06-30 | Pegasystems Inc. | Selective sharing for collaborative application usage |
SG10202110839VA (en) | 2016-07-11 | 2021-11-29 | Visa Int Service Ass | Encryption key exchange process using access device |
WO2018010958A2 (en) * | 2016-07-12 | 2018-01-18 | Deutsche Telekom Ag | Method for detecting and/or identifying data streams within a telecommunications network; system, telecommunications network, and content server entity for detecting and/or identifying data streams within a telecommunications network, program and computer program product |
WO2018010957A1 (en) * | 2016-07-12 | 2018-01-18 | Deutsche Telekom Ag | Method for providing an enhanced level of authentication related to a secure software client application provided by an application distribution entity in order to be transmitted to a client computing device; system, application distribution entity, software client application, and client computing device for providing an enhanced level of authentication related to a secure software client application, program and computer program product |
EP4130998A1 (en) | 2016-08-14 | 2023-02-08 | Liveperson Inc. | Systems and methods for real-time remote control of mobile applications |
US10880284B1 (en) * | 2016-08-19 | 2020-12-29 | Amazon Technologies, Inc. | Repurposing limited functionality devices as authentication factors |
US10044832B2 (en) | 2016-08-30 | 2018-08-07 | Home Box Office, Inc. | Data request multiplexing |
CN106375458B (en) * | 2016-09-08 | 2019-12-13 | 上海银赛计算机科技有限公司 | Service calling system, method and device |
CN106384028A (en) * | 2016-09-12 | 2017-02-08 | 浪潮软件股份有限公司 | Method for realizing unified identity authentication service supporting multiple tenants |
US20200053419A1 (en) * | 2016-10-12 | 2020-02-13 | Koninklijke Kpn N.V. | Enabling a Media Orchestration |
US10719616B2 (en) | 2016-10-25 | 2020-07-21 | Beatport, LLC | Secure content access system |
WO2018097947A2 (en) | 2016-11-03 | 2018-05-31 | Convida Wireless, Llc | Reference signals and control channels in nr |
US10715607B2 (en) * | 2016-12-06 | 2020-07-14 | Nicira, Inc. | Performing context-rich attribute-based services on a host |
CN107025559B (en) | 2017-01-26 | 2020-09-18 | 创新先进技术有限公司 | Service processing method and device |
US11765406B2 (en) | 2017-02-17 | 2023-09-19 | Interdigital Madison Patent Holdings, Sas | Systems and methods for selective object-of-interest zooming in streaming video |
US10826788B2 (en) | 2017-04-20 | 2020-11-03 | Cisco Technology, Inc. | Assurance of quality-of-service configurations in a network |
US10623264B2 (en) | 2017-04-20 | 2020-04-14 | Cisco Technology, Inc. | Policy assurance for service chaining |
US10560328B2 (en) | 2017-04-20 | 2020-02-11 | Cisco Technology, Inc. | Static network policy analysis for networks |
US10698740B2 (en) * | 2017-05-02 | 2020-06-30 | Home Box Office, Inc. | Virtual graph nodes |
US11467868B1 (en) * | 2017-05-03 | 2022-10-11 | Amazon Technologies, Inc. | Service relationship orchestration service |
US20180351788A1 (en) | 2017-05-31 | 2018-12-06 | Cisco Technology, Inc. | Fault localization in large-scale network policy deployment |
US10623271B2 (en) | 2017-05-31 | 2020-04-14 | Cisco Technology, Inc. | Intra-priority class ordering of rules corresponding to a model of network intents |
US10439875B2 (en) | 2017-05-31 | 2019-10-08 | Cisco Technology, Inc. | Identification of conflict rules in a network intent formal equivalence failure |
US10554483B2 (en) | 2017-05-31 | 2020-02-04 | Cisco Technology, Inc. | Network policy analysis for networks |
US10505816B2 (en) | 2017-05-31 | 2019-12-10 | Cisco Technology, Inc. | Semantic analysis to detect shadowing of rules in a model of network intents |
US10812318B2 (en) | 2017-05-31 | 2020-10-20 | Cisco Technology, Inc. | Associating network policy objects with specific faults corresponding to fault localizations in large-scale network deployment |
US10581694B2 (en) | 2017-05-31 | 2020-03-03 | Cisco Technology, Inc. | Generation of counter examples for network intent formal equivalence failures |
US10693738B2 (en) | 2017-05-31 | 2020-06-23 | Cisco Technology, Inc. | Generating device-level logical models for a network |
US10645547B2 (en) | 2017-06-02 | 2020-05-05 | Charter Communications Operating, Llc | Apparatus and methods for providing wireless service in a venue |
US10638361B2 (en) | 2017-06-06 | 2020-04-28 | Charter Communications Operating, Llc | Methods and apparatus for dynamic control of connections to co-existing radio access networks |
US11645131B2 (en) | 2017-06-16 | 2023-05-09 | Cisco Technology, Inc. | Distributed fault code aggregation across application centric dimensions |
US10574513B2 (en) | 2017-06-16 | 2020-02-25 | Cisco Technology, Inc. | Handling controller and node failure scenarios during data collection |
US10547715B2 (en) | 2017-06-16 | 2020-01-28 | Cisco Technology, Inc. | Event generation in response to network intent formal equivalence failures |
US10686669B2 (en) | 2017-06-16 | 2020-06-16 | Cisco Technology, Inc. | Collecting network models and node information from a network |
US10904101B2 (en) | 2017-06-16 | 2021-01-26 | Cisco Technology, Inc. | Shim layer for extracting and prioritizing underlying rules for modeling network intents |
US11469986B2 (en) | 2017-06-16 | 2022-10-11 | Cisco Technology, Inc. | Controlled micro fault injection on a distributed appliance |
US11150973B2 (en) | 2017-06-16 | 2021-10-19 | Cisco Technology, Inc. | Self diagnosing distributed appliance |
US10587621B2 (en) | 2017-06-16 | 2020-03-10 | Cisco Technology, Inc. | System and method for migrating to and maintaining a white-list network security model |
US10498608B2 (en) | 2017-06-16 | 2019-12-03 | Cisco Technology, Inc. | Topology explorer |
US10536337B2 (en) | 2017-06-19 | 2020-01-14 | Cisco Technology, Inc. | Validation of layer 2 interface and VLAN in a networked environment |
US10528444B2 (en) | 2017-06-19 | 2020-01-07 | Cisco Technology, Inc. | Event generation in response to validation between logical level and hardware level |
US11343150B2 (en) | 2017-06-19 | 2022-05-24 | Cisco Technology, Inc. | Validation of learned routes in a network |
US10652102B2 (en) | 2017-06-19 | 2020-05-12 | Cisco Technology, Inc. | Network node memory utilization analysis |
US10341184B2 (en) | 2017-06-19 | 2019-07-02 | Cisco Technology, Inc. | Validation of layer 3 bridge domain subnets in in a network |
US10411996B2 (en) | 2017-06-19 | 2019-09-10 | Cisco Technology, Inc. | Validation of routing information in a network fabric |
US10218572B2 (en) | 2017-06-19 | 2019-02-26 | Cisco Technology, Inc. | Multiprotocol border gateway protocol routing validation |
US10567229B2 (en) | 2017-06-19 | 2020-02-18 | Cisco Technology, Inc. | Validating endpoint configurations between nodes |
US10805160B2 (en) | 2017-06-19 | 2020-10-13 | Cisco Technology, Inc. | Endpoint bridge domain subnet validation |
US10644946B2 (en) | 2017-06-19 | 2020-05-05 | Cisco Technology, Inc. | Detection of overlapping subnets in a network |
US10560355B2 (en) | 2017-06-19 | 2020-02-11 | Cisco Technology, Inc. | Static endpoint validation |
US11283680B2 (en) | 2017-06-19 | 2022-03-22 | Cisco Technology, Inc. | Identifying components for removal in a network configuration |
US10437641B2 (en) | 2017-06-19 | 2019-10-08 | Cisco Technology, Inc. | On-demand processing pipeline interleaved with temporal processing pipeline |
US10700933B2 (en) | 2017-06-19 | 2020-06-30 | Cisco Technology, Inc. | Validating tunnel endpoint addresses in a network fabric |
US10333787B2 (en) | 2017-06-19 | 2019-06-25 | Cisco Technology, Inc. | Validation of L3OUT configuration for communications outside a network |
US10567228B2 (en) | 2017-06-19 | 2020-02-18 | Cisco Technology, Inc. | Validation of cross logical groups in a network |
US10812336B2 (en) | 2017-06-19 | 2020-10-20 | Cisco Technology, Inc. | Validation of bridge domain-L3out association for communication outside a network |
US10348564B2 (en) | 2017-06-19 | 2019-07-09 | Cisco Technology, Inc. | Validation of routing information base-forwarding information base equivalence in a network |
US10673702B2 (en) | 2017-06-19 | 2020-06-02 | Cisco Technology, Inc. | Validation of layer 3 using virtual routing forwarding containers in a network |
US10623259B2 (en) | 2017-06-19 | 2020-04-14 | Cisco Technology, Inc. | Validation of layer 1 interface in a network |
US10554493B2 (en) | 2017-06-19 | 2020-02-04 | Cisco Technology, Inc. | Identifying mismatches between a logical model and node implementation |
US10505817B2 (en) | 2017-06-19 | 2019-12-10 | Cisco Technology, Inc. | Automatically determining an optimal amount of time for analyzing a distributed network environment |
CN107277153B (en) * | 2017-06-30 | 2020-05-26 | 百度在线网络技术(北京)有限公司 | Method, device and server for providing voice service |
US10846387B2 (en) | 2017-07-12 | 2020-11-24 | At&T Intellectual Property I, L.P. | Managing access based on activities of entities |
US10587456B2 (en) | 2017-09-12 | 2020-03-10 | Cisco Technology, Inc. | Event clustering for a network assurance platform |
US10587484B2 (en) | 2017-09-12 | 2020-03-10 | Cisco Technology, Inc. | Anomaly detection and reporting in a network assurance appliance |
US10554477B2 (en) | 2017-09-13 | 2020-02-04 | Cisco Technology, Inc. | Network assurance event aggregator |
US10333833B2 (en) | 2017-09-25 | 2019-06-25 | Cisco Technology, Inc. | Endpoint path assurance |
US11379808B2 (en) * | 2017-10-24 | 2022-07-05 | Spotify Ab | System and method for use of prepare-proceed workflow to orchestrate operations associated with a media content environment |
FR3073998B1 (en) * | 2017-11-23 | 2019-11-01 | In Webo Technologies | DIGITAL METHOD FOR CONTROLLING ACCESS TO AN OBJECT, A RESOURCE OR SERVICE BY A USER |
US10657261B2 (en) | 2017-11-30 | 2020-05-19 | Mocana Corporation | System and method for recording device lifecycle transactions as versioned blocks in a blockchain network using a transaction connector and broker service |
US10057243B1 (en) | 2017-11-30 | 2018-08-21 | Mocana Corporation | System and method for securing data transport between a non-IP endpoint device that is connected to a gateway device and a connected service |
US11102053B2 (en) | 2017-12-05 | 2021-08-24 | Cisco Technology, Inc. | Cross-domain assurance |
CN108108444B (en) * | 2017-12-22 | 2021-12-21 | 国云科技股份有限公司 | Enterprise business unit self-adaptive system and implementation method thereof |
US10873509B2 (en) | 2018-01-17 | 2020-12-22 | Cisco Technology, Inc. | Check-pointing ACI network state and re-execution from a check-pointed state |
US10572495B2 (en) | 2018-02-06 | 2020-02-25 | Cisco Technology Inc. | Network assurance database version compatibility |
US11165874B2 (en) | 2018-03-28 | 2021-11-02 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and apparatus for multi-provider virtual network services |
US11748137B2 (en) * | 2018-03-28 | 2023-09-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and apparatus for multi-provider virtual network services |
US10261775B1 (en) * | 2018-04-17 | 2019-04-16 | Hewlett Packard Enterprise Development Lp | Upgrade orchestrator |
US20190347599A1 (en) * | 2018-05-08 | 2019-11-14 | Palantir Technologies Inc | Systems and methods for routing support tickets |
AU2019271309A1 (en) * | 2018-05-15 | 2020-12-03 | Ixup Ip Pty Ltd | Cryptographic key management |
US11748455B2 (en) * | 2018-05-25 | 2023-09-05 | Intertrust Technologies Corporation | Digital rights management systems and methods using efficient messaging architectures |
US10812315B2 (en) | 2018-06-07 | 2020-10-20 | Cisco Technology, Inc. | Cross-domain network assurance |
US11868321B2 (en) | 2018-06-12 | 2024-01-09 | Salesforce, Inc. | Cryptographically secure multi-tenant data exchange platform |
US11477667B2 (en) | 2018-06-14 | 2022-10-18 | Mark Cummings | Using orchestrators for false positive detection and root cause analysis |
US11019027B2 (en) | 2018-06-27 | 2021-05-25 | Cisco Technology, Inc. | Address translation for external network appliance |
US10659298B1 (en) | 2018-06-27 | 2020-05-19 | Cisco Technology, Inc. | Epoch comparison for network events |
US11218508B2 (en) | 2018-06-27 | 2022-01-04 | Cisco Technology, Inc. | Assurance of security rules in a network |
US10911495B2 (en) | 2018-06-27 | 2021-02-02 | Cisco Technology, Inc. | Assurance of security rules in a network |
US11044273B2 (en) | 2018-06-27 | 2021-06-22 | Cisco Technology, Inc. | Assurance of security rules in a network |
US10904070B2 (en) | 2018-07-11 | 2021-01-26 | Cisco Technology, Inc. | Techniques and interfaces for troubleshooting datacenter networks |
US10826770B2 (en) | 2018-07-26 | 2020-11-03 | Cisco Technology, Inc. | Synthesis of models for networks using automated boolean learning |
US10616072B1 (en) | 2018-07-27 | 2020-04-07 | Cisco Technology, Inc. | Epoch data interface |
US10778652B2 (en) * | 2018-07-31 | 2020-09-15 | Bae Systems Information And Electronic Systems Integration Inc. | Secure computational workflows |
US11048488B2 (en) | 2018-08-14 | 2021-06-29 | Pegasystems, Inc. | Software code optimizer and method |
CN109309712B (en) * | 2018-09-07 | 2022-06-17 | 平安科技(深圳)有限公司 | Data transmission method based on interface asynchronous call, server and storage medium |
US11100091B2 (en) | 2018-09-19 | 2021-08-24 | Salesforce.Com, Inc. | Lightweight node in a multi-tenant blockchain network |
US11157484B2 (en) | 2018-09-19 | 2021-10-26 | Salesforce.Com, Inc. | Advanced smart contract with decentralized ledger in a multi-tenant environment |
US11080247B2 (en) * | 2018-09-19 | 2021-08-03 | Salesforce.Com, Inc. | Field-based peer permissions in a blockchain network |
US11809409B2 (en) | 2018-09-19 | 2023-11-07 | Salesforce, Inc. | Multi-tenant distributed ledger interfaces |
CN109409084B (en) * | 2018-09-21 | 2021-06-25 | 中国科学院信息工程研究所 | Chain type data storage structure for detecting falsified return address |
US10965771B2 (en) * | 2018-09-25 | 2021-03-30 | International Business Machines Corporation | Dynamically switchable transmission data formats in a computer system |
US11871451B2 (en) | 2018-09-27 | 2024-01-09 | Interdigital Patent Holdings, Inc. | Sub-band operations in unlicensed spectrums of new radio |
US11640429B2 (en) | 2018-10-11 | 2023-05-02 | Home Box Office, Inc. | Graph views to improve user interface responsiveness |
US10949327B2 (en) * | 2018-10-19 | 2021-03-16 | Oracle International Corporation | Manipulation of complex variables in orchestration applications |
CN109302416A (en) * | 2018-11-13 | 2019-02-01 | 深圳市华师兄弟文化传播有限公司 | From brand share system |
WO2020117549A1 (en) | 2018-12-06 | 2020-06-11 | Mocana Corporation | System and method for zero touch provisioning of iot devices |
CN109739478B (en) * | 2018-12-24 | 2022-12-06 | 网易(杭州)网络有限公司 | Front-end project automatic construction method and device, storage medium and electronic equipment |
CN109842615B (en) * | 2018-12-29 | 2021-10-15 | 四川航天拓鑫玄武岩实业有限公司 | Communication device and communication method |
CN109739666A (en) * | 2019-01-09 | 2019-05-10 | 广州虎牙信息科技有限公司 | Striding course call method, device, equipment and the storage medium of singleton method |
EP3932003A4 (en) * | 2019-03-01 | 2022-11-30 | SingularDTV GmbH | Decentralized digital content distribution system and process using block chains and encrpyted peer-to-peer network |
CN110113247B (en) * | 2019-04-18 | 2021-07-20 | 深圳市梦网科技发展有限公司 | Rich media information receiving and sending system, sending and displaying method and terminal equipment |
US11321307B2 (en) * | 2019-06-25 | 2022-05-03 | Optum, Inc. | Orchestrated consensus validation for distributed ledgers using heterogeneous validation pools |
CA3084976A1 (en) * | 2019-07-01 | 2021-01-01 | Next Pathway Inc. | System and method for automated source code generation to provide service layer functionality for legacy computing systems in a service-oriented architecture |
TWI714184B (en) * | 2019-07-25 | 2020-12-21 | 中華電信股份有限公司 | Methods for querying multilayer network and pattern matching |
US11469908B2 (en) | 2019-08-07 | 2022-10-11 | Bank Of America Corporation | Equipment onboarding and deployment security system |
CN110535842B (en) * | 2019-08-20 | 2021-11-19 | 之江实验室 | Mimic security system and method based on sampling detection |
CN110768956B (en) * | 2019-09-19 | 2022-09-27 | 苏宁云计算有限公司 | Data service providing method, device, computer equipment and storage medium |
WO2021056069A1 (en) * | 2019-09-25 | 2021-04-01 | Commonwealth Scientific And Industrial Research Organisation | Cryptographic services for browser applications |
GB2588107B (en) | 2019-10-07 | 2022-11-02 | British Telecomm | Secure publish-subscribe communication methods and apparatus |
CN114631086A (en) * | 2019-11-11 | 2022-06-14 | 施耐德电气美国股份有限公司 | Safety data orchestrator for internet of things network |
CN111193720A (en) * | 2019-12-16 | 2020-05-22 | 中国电子科技集团公司第三十研究所 | Trust service adaptation method based on security agent |
US11539718B2 (en) | 2020-01-10 | 2022-12-27 | Vmware, Inc. | Efficiently performing intrusion detection |
US11513817B2 (en) | 2020-03-04 | 2022-11-29 | Kyndryl, Inc. | Preventing disruption within information technology environments |
CN111464652A (en) * | 2020-04-07 | 2020-07-28 | 中国建设银行股份有限公司 | Bank safe deposit box service providing method and device |
DE102020111020A1 (en) * | 2020-04-22 | 2021-10-28 | Endress+Hauser Conducta Gmbh+Co. Kg | Method for checking the authentic origin of electronic modules of a modularly structured field device in automation technology |
US11546315B2 (en) * | 2020-05-28 | 2023-01-03 | Hewlett Packard Enterprise Development Lp | Authentication key-based DLL service |
CN111722946A (en) * | 2020-06-28 | 2020-09-29 | 深圳壹账通智能科技有限公司 | Distributed transaction processing method and device, computer equipment and readable storage medium |
CN113923250B (en) * | 2020-07-07 | 2023-04-07 | 华为技术有限公司 | Method, device and system for assisting network service arrangement |
US20220012102A1 (en) * | 2020-07-07 | 2022-01-13 | Calgary Scientific Inc | Highly scalable, peer-based, real-time agent architecture |
US11290481B2 (en) | 2020-07-09 | 2022-03-29 | Bank Of America Corporation | Security threat detection by converting scripts using validation graphs |
US11368310B2 (en) | 2020-07-11 | 2022-06-21 | Bank Of America Corporation | Data transfer between computing nodes of a distributed computing system |
CN111914435B (en) * | 2020-08-18 | 2022-08-16 | 哈尔滨工业大学 | Multi-party collaborative service value-quality-capability modeling method facing space-time boundary |
US11567945B1 (en) | 2020-08-27 | 2023-01-31 | Pegasystems Inc. | Customized digital content generation systems and methods |
CN111815420B (en) * | 2020-08-28 | 2021-07-06 | 支付宝(杭州)信息技术有限公司 | Matching method, device and equipment based on trusted asset data |
US11734356B2 (en) * | 2020-09-11 | 2023-08-22 | Jpmorgan Chase Bank, N.A. | System and method for implementing an open policy agent bridge |
WO2022072723A1 (en) * | 2020-09-30 | 2022-04-07 | Bytedance Inc. | Picture partitioning in video coding |
US11640565B1 (en) | 2020-11-11 | 2023-05-02 | Wells Fargo Bank, N.A. | Systems and methods for relationship mapping |
US11392573B1 (en) | 2020-11-11 | 2022-07-19 | Wells Fargo Bank, N.A. | Systems and methods for generating and maintaining data objects |
CN112379920A (en) * | 2020-11-17 | 2021-02-19 | 金蝶云科技有限公司 | Compatible method, integrated platform and storage medium for integrated software in ERP system |
US11646866B2 (en) | 2020-11-17 | 2023-05-09 | International Business Machines Corporation | Blockchain based service reservation and delegation |
CN112579087A (en) * | 2020-12-25 | 2021-03-30 | 四川长虹电器股份有限公司 | Development method of cooking machine human-computer interface based on Lua script |
US11456931B1 (en) * | 2021-04-06 | 2022-09-27 | Amdocs Development Limited | System, method and computer program for orchestrating loosely coupled services |
CN113805870B (en) * | 2021-09-18 | 2024-01-30 | 上海熙菱信息技术有限公司 | BFF architecture-based service interface arrangement method and system |
US20230117615A1 (en) * | 2021-10-19 | 2023-04-20 | At&T Intellectual Property I, L.P. | Api driven subscriber ims registration status changes and ims routing steering |
US20230168656A1 (en) * | 2021-11-30 | 2023-06-01 | UiPath, Inc. | Automatically assigning natural language labels to non-conforming behavior of processes |
US11907229B2 (en) * | 2022-03-31 | 2024-02-20 | Gm Cruise Holdings Llc | System and method for platform-independent access bindings |
US12022016B2 (en) | 2022-04-07 | 2024-06-25 | Bank Of America Corporation | System and method for managing exception request blocks in a blockchain network |
US20230359513A1 (en) * | 2022-05-04 | 2023-11-09 | Marsh (USA) Inc. | Orchestration system and method to provide client independent api integration model |
CN114849649B (en) * | 2022-05-05 | 2023-06-02 | 浙江师范大学 | Ion hybridization porous material with zsd topological structure, and preparation method and application thereof |
CN114760290B (en) * | 2022-05-07 | 2024-04-12 | 北京字跳网络技术有限公司 | Application development method and device, electronic equipment and storage medium |
WO2023224680A1 (en) * | 2022-05-18 | 2023-11-23 | Margo Networks Pvt. Ltd. | Peer to peer (p2p) encrypted data transfer/offload system and method |
TWI818798B (en) * | 2022-11-08 | 2023-10-11 | 英業達股份有限公司 | Method for permission management |
Citations (89)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4327508A (en) * | 1980-12-08 | 1982-05-04 | J. I. Case Company | Trencher digging chain sprocket drive |
US5410598A (en) * | 1986-10-14 | 1995-04-25 | Electronic Publishing Resources, Inc. | Database usage metering and protection system and method |
US5414845A (en) * | 1992-06-26 | 1995-05-09 | International Business Machines Corporation | Network-based computer system with improved network scheduling system |
US5530235A (en) * | 1995-02-16 | 1996-06-25 | Xerox Corporation | Interactive contents revealing storage device |
US5629980A (en) * | 1994-11-23 | 1997-05-13 | Xerox Corporation | System for controlling the distribution and use of digital works |
US5634012A (en) * | 1994-11-23 | 1997-05-27 | Xerox Corporation | System for controlling the distribution and use of digital works having a fee reporting mechanism |
US5638443A (en) * | 1994-11-23 | 1997-06-10 | Xerox Corporation | System for controlling the distribution and use of composite digital works |
US5715403A (en) * | 1994-11-23 | 1998-02-03 | Xerox Corporation | System for controlling the distribution and use of digital works having attached usage rights where the usage rights are defined by a usage rights grammar |
US5892900A (en) * | 1996-08-30 | 1999-04-06 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US6023765A (en) * | 1996-12-06 | 2000-02-08 | The United States Of America As Represented By The Secretary Of Commerce | Implementation of role-based access control in multi-level secure systems |
US6044469A (en) * | 1997-08-29 | 2000-03-28 | Preview Software | Software publisher or distributor configurable software security mechanism |
US6052780A (en) * | 1996-09-12 | 2000-04-18 | Open Security Solutions, Llc | Computer system and process for accessing an encrypted and self-decrypting digital information product while restricting access to decrypted digital information |
US6185683B1 (en) * | 1995-02-13 | 2001-02-06 | Intertrust Technologies Corp. | Trusted and secure techniques, systems and methods for item delivery and execution |
US6188995B1 (en) * | 1997-07-28 | 2001-02-13 | Apple Computer, Inc. | Method and apparatus for enforcing software licenses |
US6223291B1 (en) * | 1999-03-26 | 2001-04-24 | Motorola, Inc. | Secure wireless electronic-commerce system with digital product certificates and digital license certificates |
US6226618B1 (en) * | 1998-08-13 | 2001-05-01 | International Business Machines Corporation | Electronic content delivery system |
US20010001147A1 (en) * | 1998-04-22 | 2001-05-10 | Echarge Corporation | Method and apparatus for ordering goods, services and content over an internetwork |
US6233608B1 (en) * | 1997-12-09 | 2001-05-15 | Openwave Systems Inc. | Method and system for securely interacting with managed data from multiple devices |
US6233577B1 (en) * | 1998-02-17 | 2001-05-15 | Phone.Com, Inc. | Centralized certificate management system for two-way interactive communication devices in data networks |
US6240185B1 (en) * | 1996-08-12 | 2001-05-29 | Intertrust Technologies Corporation | Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels |
US20020002674A1 (en) * | 2000-06-29 | 2002-01-03 | Tom Grimes | Digital rights management |
US20020010679A1 (en) * | 2000-07-06 | 2002-01-24 | Felsher David Paul | Information record infrastructure, system and method |
US20020023214A1 (en) * | 1996-08-12 | 2002-02-21 | Intertrust Technologies Corp. | Systems and methods using cryptography to protect secure computing environments |
US20020044657A1 (en) * | 2000-09-07 | 2002-04-18 | Tomoyuki Asano | Information recording device, information playback device, information recording method, information playback method, and information recording medium and program providing medium used therewith |
US20020048369A1 (en) * | 1995-02-13 | 2002-04-25 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US20020059425A1 (en) * | 2000-06-22 | 2002-05-16 | Microsoft Corporation | Distributed computing services platform |
US20030009681A1 (en) * | 2001-07-09 | 2003-01-09 | Shunji Harada | Digital work protection system, recording medium apparatus, transmission apparatus, and playback apparatus |
US20030009423A1 (en) * | 2001-05-31 | 2003-01-09 | Xin Wang | Rights offering and granting |
US20030023856A1 (en) * | 2001-06-13 | 2003-01-30 | Intertrust Technologies Corporation | Software self-checking systems and methods |
US20030028488A1 (en) * | 2001-03-26 | 2003-02-06 | Mohammed Sohail Baig | Supervised license acquisition in a digital rights management system on a computing device |
US20030037139A1 (en) * | 2001-08-20 | 2003-02-20 | Koninklijke Philips Electronics N.V. | Content distribution model |
US20030046244A1 (en) * | 1997-11-06 | 2003-03-06 | Intertrust Technologies Corp. | Methods for matching, selecting, and/or classifying based on rights management and/or other information |
US20030051134A1 (en) * | 2001-08-28 | 2003-03-13 | International Business Machines Corporation | Secure authentication using digital certificates |
US20030055787A1 (en) * | 2001-09-20 | 2003-03-20 | Fujitsu Limited | Electronic settlement method |
US20030061404A1 (en) * | 2001-09-21 | 2003-03-27 | Corel Corporation | Web services gateway |
US20030065956A1 (en) * | 2001-09-28 | 2003-04-03 | Abhijit Belapurkar | Challenge-response data communication protocol |
US20030078891A1 (en) * | 2001-10-18 | 2003-04-24 | Capitant Patrice J. | Systems and methods for providing digital rights management compatibility |
US20030084003A1 (en) * | 2001-04-20 | 2003-05-01 | Intertrust Technologies Corporation | Systems and methods for conducting transactions and communications using a trusted third party |
US20030084172A1 (en) * | 2001-10-29 | 2003-05-01 | Sun Microsystem, Inc., A Delaware Corporation | Identification and privacy in the World Wide Web |
US20040003270A1 (en) * | 2002-06-28 | 2004-01-01 | Microsoft Corporation | Obtaining a signed rights label (SRL) for digital content and obtaining a digital license corresponding to the content based on the SRL in a digital rights management system |
US20040003398A1 (en) * | 2002-06-27 | 2004-01-01 | Donian Philip M. | Method and apparatus for the free licensing of digital media content |
US20040003139A1 (en) * | 2002-06-28 | 2004-01-01 | Microsoft Corporation | Secure server plug-in architecture for digital rights management systems |
US20040024688A1 (en) * | 2000-11-10 | 2004-02-05 | Depeng Bi | Digital content distribution and subscription system |
US20040054630A1 (en) * | 1995-02-13 | 2004-03-18 | Intertrust Technologies Corporation | Systems and methods for secure transaction management and electronic rights protection |
US20040054912A1 (en) * | 2002-09-04 | 2004-03-18 | Daniel Adent | Data stream header object protection |
US20040054894A1 (en) * | 2000-10-11 | 2004-03-18 | Lambert Martin R. | Method for controlling access to protected content |
US20040059951A1 (en) * | 2002-04-25 | 2004-03-25 | Intertrust Technologies Corporation | Secure authentication systems and methods |
US20040073813A1 (en) * | 2002-04-25 | 2004-04-15 | Intertrust Technologies Corporation | Establishing a secure channel with a human user |
US20040088175A1 (en) * | 2002-11-01 | 2004-05-06 | Thomas Messerges | Digital-rights management |
US20040088541A1 (en) * | 2002-11-01 | 2004-05-06 | Thomas Messerges | Digital-rights management system |
US6735253B1 (en) * | 1997-05-16 | 2004-05-11 | The Trustees Of Columbia University In The City Of New York | Methods and architecture for indexing and editing compressed video over the world wide web |
US20040103312A1 (en) * | 2002-11-27 | 2004-05-27 | Thomas Messerges | Domain-based digital-rights management system with easy and secure device enrollment |
US20050004875A1 (en) * | 2001-07-06 | 2005-01-06 | Markku Kontio | Digital rights management in a mobile communications environment |
US6842863B1 (en) * | 1999-11-23 | 2005-01-11 | Microsoft Corporation | Certificate reissuance for checking the status of a certificate in financial transactions |
US20050008163A1 (en) * | 2003-06-02 | 2005-01-13 | Liquid Machines, Inc. | Computer method and apparatus for securely managing data objects in a distributed context |
US20050022227A1 (en) * | 2001-10-29 | 2005-01-27 | Shen Sheng Mei | Apparatus of a baseline dvb-cpcm |
US6850252B1 (en) * | 1999-10-05 | 2005-02-01 | Steven M. Hoffberg | Intelligent electronic appliance system and method |
US20050027871A1 (en) * | 2003-06-05 | 2005-02-03 | William Bradley | Interoperable systems and methods for peer-to-peer service orchestration |
US20050050332A1 (en) * | 1999-06-08 | 2005-03-03 | Intertrust Technologies Corporation | Methods and systems for encoding and protecting data using digital signature and watermarking techniques |
US20050060560A1 (en) * | 1999-12-22 | 2005-03-17 | Intertrust Technologies Corporation | Systems and methods for protecting data secrecy and integrity |
US20050060584A1 (en) * | 1995-02-13 | 2005-03-17 | Intertrust Technologies Corp. | Trusted infrastructure support systems, methods and techniques for secure electronic commerce, electronic transactions, commerce process control and automation, distributed computing, and rights management |
US20050078822A1 (en) * | 2003-10-08 | 2005-04-14 | Eyal Shavit | Secure access and copy protection management system |
US20050086501A1 (en) * | 2002-01-12 | 2005-04-21 | Je-Hak Woo | Method and system for the information protection of digital content |
US20050102513A1 (en) * | 2003-11-10 | 2005-05-12 | Nokia Corporation | Enforcing authorized domains with domain membership vouchers |
US20050108707A1 (en) * | 2003-11-14 | 2005-05-19 | Taylor Thomas M. | Systems and methods for creating and managing a virtual retail store on end-user client computers within a network |
US6985953B1 (en) * | 1998-11-30 | 2006-01-10 | George Mason University | System and apparatus for storage and transfer of secure data on web |
US20060015580A1 (en) * | 2004-07-01 | 2006-01-19 | Home Box Office, A Delaware Corporation | Multimedia content distribution |
US20060021065A1 (en) * | 2002-10-22 | 2006-01-26 | Kamperman Franciscus Lucas A J | Method and device for authorizing content operations |
US20060020784A1 (en) * | 2002-09-23 | 2006-01-26 | Willem Jonker | Certificate based authorized domains |
US6996544B2 (en) * | 2002-02-27 | 2006-02-07 | Imagineer Software, Inc. | Multiple party content distribution system and method with rights management features |
US20060041642A1 (en) * | 2002-09-30 | 2006-02-23 | Koninklijke Philips Electronics, N.V. | Secure proximity verification of a node on a network |
US20060050870A1 (en) * | 2004-07-29 | 2006-03-09 | Kimmel Gerald D | Information-centric security |
US7171558B1 (en) * | 2000-09-22 | 2007-01-30 | International Business Machines Corporation | Transparent digital rights management for extendible content viewers |
US20070074270A1 (en) * | 2005-09-28 | 2007-03-29 | Essential Security Software, Inc. | Method and system for digital rights management of documents |
US7203966B2 (en) * | 2001-06-27 | 2007-04-10 | Microsoft Corporation | Enforcement architecture and method for digital rights management system for roaming a license to a plurality of user devices |
US20070083757A1 (en) * | 2003-11-25 | 2007-04-12 | Toshihisa Nakano | Authentication system |
US7210039B2 (en) * | 2000-09-14 | 2007-04-24 | Phocis Limited | Digital rights management |
US20070098162A1 (en) * | 2005-10-27 | 2007-05-03 | Samsung Electronics Co., Ltd. | Method and apparatus for managing rights of multi-layered multimedia stream by layers |
US7356690B2 (en) * | 2000-12-11 | 2008-04-08 | International Business Machines Corporation | Method and system for managing a distributed trust path locator for public key certificates relating to the trust path of an X.509 attribute certificate |
US7359517B1 (en) * | 2001-10-09 | 2008-04-15 | Adobe Systems Incorporated | Nestable skeleton decryption keys for digital rights management |
US20090007198A1 (en) * | 2004-06-21 | 2009-01-01 | Ben Lavender | Accessing Broadcast Media |
US20090031038A1 (en) * | 2007-07-26 | 2009-01-29 | Realnetworks, Inc. | Adaptive variable fidelity media distribution system and method |
US7487363B2 (en) * | 2001-10-18 | 2009-02-03 | Nokia Corporation | System and method for controlled copying and moving of content between devices and domains based on conditional encryption of content key depending on usage |
US7493289B2 (en) * | 2002-12-13 | 2009-02-17 | Aol Llc | Digital content store system |
US7496757B2 (en) * | 2002-01-14 | 2009-02-24 | International Business Machines Corporation | Software verification system, method and computer program element |
US7509492B2 (en) * | 2001-03-27 | 2009-03-24 | Microsoft Corporation | Distributed scalable cryptographic access control |
US7516331B2 (en) * | 2003-11-26 | 2009-04-07 | International Business Machines Corporation | Tamper-resistant trusted java virtual machine and method of using the same |
US20090112867A1 (en) * | 2007-10-25 | 2009-04-30 | Prasan Roy | Anonymizing Selected Content in a Document |
US7711647B2 (en) * | 2004-06-10 | 2010-05-04 | Akamai Technologies, Inc. | Digital rights management in a distributed network |
Family Cites Families (185)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US476357A (en) | 1892-06-07 | Photograph-holder | ||
US599949A (en) * | 1898-03-01 | Edward a | ||
US4977594A (en) | 1986-10-14 | 1990-12-11 | Electronic Publishing Resources, Inc. | Database usage metering and protection system and method |
US4827508A (en) | 1986-10-14 | 1989-05-02 | Personal Library Software, Inc. | Database usage metering and protection system and method |
US5940504A (en) | 1991-07-01 | 1999-08-17 | Infologic Software, Inc. | Licensing management system and method in which datagrams including an address of a licensee and indicative of use of a licensed product are sent from the licensee's site |
JPH07230380A (en) | 1994-02-15 | 1995-08-29 | Internatl Business Mach Corp <Ibm> | Method and system for controlling utilization of application program |
JP2853727B2 (en) | 1994-02-22 | 1999-02-03 | 日本ビクター株式会社 | Reproduction protection method and protection reproduction device |
JPH07319691A (en) | 1994-03-29 | 1995-12-08 | Toshiba Corp | Resource protective device, privilege protective device, software utilization method controller and software utilization method control system |
US5473692A (en) * | 1994-09-07 | 1995-12-05 | Intel Corporation | Roving software license for a hardware agent |
FR2721722B1 (en) * | 1994-06-22 | 1996-09-13 | France Telecom | Method for producing a matrix of quantum well components of vertical "all optical" structure. |
JPH08263438A (en) | 1994-11-23 | 1996-10-11 | Xerox Corp | Distribution and use control system of digital work and access control method to digital work |
US6948070B1 (en) | 1995-02-13 | 2005-09-20 | Intertrust Technologies Corporation | Systems and methods for secure transaction management and electronic rights protection |
US6658568B1 (en) | 1995-02-13 | 2003-12-02 | Intertrust Technologies Corporation | Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management |
IL113572A (en) * | 1995-05-01 | 1999-03-12 | Metalink Ltd | Symbol decoder |
US5534975A (en) | 1995-05-26 | 1996-07-09 | Xerox Corporation | Document processing system utilizing document service cards to provide document processing services |
US5757915A (en) * | 1995-08-25 | 1998-05-26 | Intel Corporation | Parameterized hash functions for access control |
US5638446A (en) * | 1995-08-28 | 1997-06-10 | Bell Communications Research, Inc. | Method for the secure distribution of electronic files in a distributed environment |
US5774652A (en) * | 1995-09-29 | 1998-06-30 | Smith; Perry | Restricted access computer system |
US6807534B1 (en) | 1995-10-13 | 2004-10-19 | Trustees Of Dartmouth College | System and method for managing copyrighted electronic media |
US5765152A (en) | 1995-10-13 | 1998-06-09 | Trustees Of Dartmouth College | System and method for managing copyrighted electronic media |
US5825883A (en) | 1995-10-31 | 1998-10-20 | Interval Systems, Inc. | Method and apparatus that accounts for usage of digital applications |
AUPN955096A0 (en) * | 1996-04-29 | 1996-05-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Telecommunications information dissemination system |
ES2286833T3 (en) | 1996-05-15 | 2007-12-01 | Intertrust Technologies Corp | METHOD AND APPLIANCE TO ACCESS STORED CONTENTS ON A DVD. |
ES2271958T3 (en) | 1996-09-04 | 2007-04-16 | Intertrust Technologies Corp | RELIABLE SYSTEMS, PROCEDURES AND TECHNOLOGIES FOR INFRASTRUCTURE SUPPORT FOR SAFE ELECTRONIC COMMERCE, ELECTRONIC TRANSACTIONS, CONTROL AND AUTOMATION OF COMMERCIAL PROCEDURES, DISTRIBUTED COMPUTERS AND RIGHTS MANAGEMENT. |
US6006332A (en) | 1996-10-21 | 1999-12-21 | Case Western Reserve University | Rights management system for digital media |
JPH10133955A (en) | 1996-10-29 | 1998-05-22 | Matsushita Electric Ind Co Ltd | Portable medium driving device, its method, cooperative device of portable medium and network, and its method |
US5920861A (en) | 1997-02-25 | 1999-07-06 | Intertrust Technologies Corp. | Techniques for defining using and manipulating rights management data structures |
US5937041A (en) * | 1997-03-10 | 1999-08-10 | Northern Telecom, Limited | System and method for retrieving internet data files using a screen-display telephone terminal |
US5999949A (en) | 1997-03-14 | 1999-12-07 | Crandall; Gary E. | Text file compression system utilizing word terminators |
WO1999001815A1 (en) | 1997-06-09 | 1999-01-14 | Intertrust, Incorporated | Obfuscation techniques for enhancing software security |
US5941951A (en) | 1997-10-31 | 1999-08-24 | International Business Machines Corporation | Methods for real-time deterministic delivery of multimedia data in a client/server system |
US6112181A (en) | 1997-11-06 | 2000-08-29 | Intertrust Technologies Corporation | Systems and methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information |
JP3733715B2 (en) | 1997-11-12 | 2006-01-11 | 富士ゼロックス株式会社 | Document disclosure apparatus, medium storing document disclosure program, and document disclosure method |
US6769019B2 (en) | 1997-12-10 | 2004-07-27 | Xavier Ferguson | Method of background downloading of information from a computer network |
US5991399A (en) | 1997-12-18 | 1999-11-23 | Intel Corporation | Method for securely distributing a conditional use private key to a trusted entity on a remote system |
US7809138B2 (en) | 1999-03-16 | 2010-10-05 | Intertrust Technologies Corporation | Methods and apparatus for persistent control and protection of content |
EP1521467A3 (en) | 1998-03-16 | 2005-04-13 | Intertrust Technologies Corp. | Methods and apparatus for continuous control and protection of media content |
JP3809008B2 (en) * | 1998-03-27 | 2006-08-16 | 株式会社アドバンテスト | Cast Tomato Rei Stocker |
US6223608B1 (en) * | 1998-06-02 | 2001-05-01 | Mitsubishi Denki Kabushiki Kaisha | Torque detector |
US20040107368A1 (en) | 1998-06-04 | 2004-06-03 | Z4 Technologies, Inc. | Method for digital rights management including self activating/self authentication software |
DE69911161T2 (en) * | 1998-07-22 | 2004-04-08 | Matsushita Electric Industrial Co., Ltd., Kadoma | DIGITAL DATA RECORDING DEVICE AND PROCESS FOR COPYRIGHT PROTECTION AND FOR EASIER PLAYBACK OF ENCRYPTED DATA AND CALCULAR READABLE MEDIUM FOR PROGRAM RECORDING |
US6119108A (en) | 1998-10-01 | 2000-09-12 | Aires Systems Corporation | Secure electronic publishing system |
US7058414B1 (en) | 2000-05-26 | 2006-06-06 | Freescale Semiconductor, Inc. | Method and system for enabling device functions based on distance information |
AU3736800A (en) * | 1999-03-10 | 2000-09-28 | Acoustic Information Processing Lab, Llc. | Signal processing methods, devices, and applications for digital rights management |
US7073063B2 (en) * | 1999-03-27 | 2006-07-04 | Microsoft Corporation | Binding a digital license to a portable device or the like in a digital rights management (DRM) system and checking out/checking in the digital license to/from the portable device or the like |
US20020194081A1 (en) * | 1999-04-21 | 2002-12-19 | Perkowski Thomas J. | Internet-based consumer service brand marketing communication system which enables service-providers, retailers, and their respective agents and consumers to carry out service-related functions along the demand side of the retail chain in an integrated manner |
US6883100B1 (en) * | 1999-05-10 | 2005-04-19 | Sun Microsystems, Inc. | Method and system for dynamic issuance of group certificates |
AU6104800A (en) | 1999-07-16 | 2001-02-05 | Intertrust Technologies Corp. | Trusted storage systems and methods |
WO2001010076A2 (en) | 1999-07-29 | 2001-02-08 | Intertrust Technologies Corp. | Systems and methods for protecting secure and insecure computing environments using cryptography |
AU6750700A (en) | 1999-07-30 | 2001-02-19 | Intertrust Technologies Corp. | Methods and systems for transaction record delivery using thresholds and multi-stage protocol |
US20080133417A1 (en) | 1999-10-18 | 2008-06-05 | Emergent Music Llc | System to determine quality through reselling of items |
US6331227B1 (en) * | 1999-12-14 | 2001-12-18 | Epion Corporation | Enhanced etching/smoothing of dielectric surfaces |
US6996720B1 (en) * | 1999-12-17 | 2006-02-07 | Microsoft Corporation | System and method for accessing protected content in a rights-management architecture |
US6772340B1 (en) | 2000-01-14 | 2004-08-03 | Microsoft Corporation | Digital rights management system operating on computing device and having black box tied to computing device |
US7426750B2 (en) * | 2000-02-18 | 2008-09-16 | Verimatrix, Inc. | Network-based content distribution system |
US20010033554A1 (en) | 2000-02-18 | 2001-10-25 | Arun Ayyagari | Proxy-bridge connecting remote users to a limited connectivity network |
IL135555A0 (en) * | 2000-04-09 | 2001-05-20 | Vidius Inc | Preventing unauthorized access to data sent via computer networks |
JP3711866B2 (en) | 2000-04-10 | 2005-11-02 | 日本電気株式会社 | Framework having plug and play function and reconfiguration method thereof |
AU2001255497A1 (en) | 2000-04-18 | 2001-10-30 | Portalplayer, Inc. | Downloaded media protocol integration system and method |
WO2001086462A1 (en) | 2000-05-08 | 2001-11-15 | Leap Wireless International, Inc. | Method of converting html/xml to hdml/wml in real-time for display on mobile devices |
US7313692B2 (en) | 2000-05-19 | 2007-12-25 | Intertrust Technologies Corp. | Trust management systems and methods |
US7496637B2 (en) | 2000-05-31 | 2009-02-24 | Oracle International Corp. | Web service syndication system |
US6961858B2 (en) | 2000-06-16 | 2005-11-01 | Entriq, Inc. | Method and system to secure content for distribution via a network |
US6976164B1 (en) | 2000-07-19 | 2005-12-13 | International Business Machines Corporation | Technique for handling subsequent user identification and password requests with identity change within a certificate-based host session |
EP1189432A3 (en) | 2000-08-14 | 2004-10-20 | Matsushita Electric Industrial Co., Ltd. | A hierarchical encryption scheme for secure distribution of predetermined content |
US7010808B1 (en) | 2000-08-25 | 2006-03-07 | Microsoft Corporation | Binding digital content to a portable storage device or the like in a digital rights management (DRM) system |
US7743259B2 (en) | 2000-08-28 | 2010-06-22 | Contentguard Holdings, Inc. | System and method for digital rights management using a standard rendering engine |
GB0024918D0 (en) | 2000-10-11 | 2000-11-22 | Sealedmedia Ltd | Method of providing java tamperproofing |
SE519748C2 (en) | 2000-10-23 | 2003-04-08 | Volvo Technology Corp | Procedure for checking access rights to an object and the computer program product for performing procedures |
US20030177187A1 (en) | 2000-11-27 | 2003-09-18 | Butterfly.Net. Inc. | Computing grid for massively multi-player online games and other multi-user immersive persistent-state and session-based applications |
JP2002207637A (en) | 2001-01-11 | 2002-07-26 | Hitachi Ltd | Method and device for disclosing information, and information service method |
US20030220880A1 (en) * | 2002-01-17 | 2003-11-27 | Contentguard Holdings, Inc. | Networked services licensing system and method |
AU1547402A (en) * | 2001-02-09 | 2002-08-15 | Sony Corporation | Information processing method/apparatus and program |
GB2372343A (en) | 2001-02-17 | 2002-08-21 | Hewlett Packard Co | Determination of a trust value of a digital certificate |
US7308717B2 (en) | 2001-02-23 | 2007-12-11 | International Business Machines Corporation | System and method for supporting digital rights management in an enhanced Java™ 2 runtime environment |
GB2373136A (en) * | 2001-03-07 | 2002-09-11 | Int Computers Ltd | Distributed computing using wireless mobile devices |
WO2002076003A2 (en) * | 2001-03-19 | 2002-09-26 | Imesh Ltd. | System and method for peer-to-peer file exchange mechanism from multiple sources |
WO2002080067A2 (en) * | 2001-03-29 | 2002-10-10 | Sony Corp | Information processor |
TW569119B (en) * | 2001-03-29 | 2004-01-01 | Sony Corp | Data processing device |
US20020144108A1 (en) | 2001-03-29 | 2002-10-03 | International Business Machines Corporation | Method and system for public-key-based secure authentication to distributed legacy applications |
US20020144283A1 (en) * | 2001-03-30 | 2002-10-03 | Intertainer, Inc. | Content distribution system |
US7580988B2 (en) | 2001-04-05 | 2009-08-25 | Intertrust Technologies Corporation | System and methods for managing the distribution of electronic content |
EP1378105B1 (en) * | 2001-04-12 | 2008-05-21 | Research In Motion Limited | System and method for dynamically pushing information on wireless data communication devices |
US20020157002A1 (en) | 2001-04-18 | 2002-10-24 | Messerges Thomas S. | System and method for secure and convenient management of digital electronic content |
US7043050B2 (en) * | 2001-05-02 | 2006-05-09 | Microsoft Corporation | Software anti-piracy systems and methods utilizing certificates with digital content |
US6934702B2 (en) * | 2001-05-04 | 2005-08-23 | Sun Microsystems, Inc. | Method and system of routing messages in a distributed search network |
US7249100B2 (en) * | 2001-05-15 | 2007-07-24 | Nokia Corporation | Service discovery access to user location |
US7152046B2 (en) | 2001-05-31 | 2006-12-19 | Contentguard Holdings, Inc. | Method and apparatus for tracking status of resource in a system for managing use of the resources |
US6824051B2 (en) | 2001-06-07 | 2004-11-30 | Contentguard Holdings, Inc. | Protected content distribution system |
US6916100B2 (en) * | 2001-06-27 | 2005-07-12 | Donnelly Corporation | Vehicle exterior rearview mirror assembly |
WO2003009112A1 (en) * | 2001-07-17 | 2003-01-30 | Matsushita Electric Industrial Co., Ltd. | Content usage device and network system, and license information acquisition method |
WO2003012609A2 (en) * | 2001-08-01 | 2003-02-13 | Matsushita Electric Industrial Co., Ltd. | Device and method for managing content usage right |
JP2003044436A (en) * | 2001-08-02 | 2003-02-14 | Sony Corp | Authentication processing method, information processor, and computer program |
JP4280036B2 (en) | 2001-08-03 | 2009-06-17 | パナソニック株式会社 | Access right control system |
US7085969B2 (en) * | 2001-08-27 | 2006-08-01 | Industrial Technology Research Institute | Encoding and decoding apparatus and method |
US7035944B2 (en) * | 2001-09-19 | 2006-04-25 | International Business Machines Corporation | Programmatic management of software resources in a content framework environment |
US20030079133A1 (en) | 2001-10-18 | 2003-04-24 | International Business Machines Corporation | Method and system for digital rights management in content distribution application |
US7254614B2 (en) * | 2001-11-20 | 2007-08-07 | Nokia Corporation | Web services push gateway |
US7558759B2 (en) | 2001-11-20 | 2009-07-07 | Contentguard Holdings, Inc. | Systems and methods for creating, manipulating and processing rights and contract expressions using tokenized templates |
JP4664572B2 (en) | 2001-11-27 | 2011-04-06 | 富士通株式会社 | Document distribution method and document management method |
US20030126086A1 (en) * | 2001-12-31 | 2003-07-03 | General Instrument Corporation | Methods and apparatus for digital rights management |
US7088823B2 (en) | 2002-01-09 | 2006-08-08 | International Business Machines Corporation | System and method for secure distribution and evaluation of compressed digital information |
US7603469B2 (en) | 2002-01-15 | 2009-10-13 | International Business Machines Corporation | Provisioning aggregated services in a distributed computing environment |
US20030140119A1 (en) | 2002-01-18 | 2003-07-24 | International Business Machines Corporation | Dynamic service discovery |
US20030145044A1 (en) | 2002-01-28 | 2003-07-31 | Nokia Corporation | Virtual terminal for mobile network interface between mobile terminal and software applications node |
US20030144859A1 (en) * | 2002-01-31 | 2003-07-31 | Meichun Hsu | E-service publication and discovery method and system |
US20030172127A1 (en) * | 2002-02-06 | 2003-09-11 | Northrup Charles J. | Execution of process by references to directory service |
KR100467929B1 (en) | 2002-02-28 | 2005-01-24 | 주식회사 마크애니 | System for protecting and managing digital contents |
US7159224B2 (en) | 2002-04-09 | 2007-01-02 | Sun Microsystems, Inc. | Method, system, and articles of manufacture for providing a servlet container based web service endpoint |
US7472270B2 (en) * | 2002-04-16 | 2008-12-30 | Microsoft Corporation | Secure transmission of digital content between a host and a peripheral by way of a digital rights management (DRM) system |
US8656178B2 (en) | 2002-04-18 | 2014-02-18 | International Business Machines Corporation | Method, system and program product for modifying content usage conditions during content distribution |
US7369851B2 (en) | 2002-04-19 | 2008-05-06 | Hewlett-Packard Development Company, L.P. | Communications network capable of determining SIM card changes in electronic devices |
US7076249B2 (en) * | 2002-05-06 | 2006-07-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for generating management data for drifting mobile radios |
US8611919B2 (en) * | 2002-05-23 | 2013-12-17 | Wounder Gmbh., Llc | System, method, and computer program product for providing location based services and mobile e-commerce |
US7529929B2 (en) | 2002-05-30 | 2009-05-05 | Nokia Corporation | System and method for dynamically enforcing digital rights management rules |
US7296154B2 (en) | 2002-06-24 | 2007-11-13 | Microsoft Corporation | Secure media path methods, systems, and architectures |
AU2002950202A0 (en) | 2002-07-11 | 2002-09-12 | University Of Wollongong | Methods for standard mechanisms for digital item manipulation and handling |
AU2003265866A1 (en) * | 2002-09-03 | 2004-03-29 | Vit Lauermann | Targeted release |
US20040216127A1 (en) * | 2002-09-10 | 2004-10-28 | Chutney Technologies | Method and apparatus for accelerating web services |
US8356067B2 (en) | 2002-10-24 | 2013-01-15 | Intel Corporation | Servicing device aggregates |
US20040143546A1 (en) * | 2002-11-01 | 2004-07-22 | Wood Jeff A. | Easy user activation of electronic commerce services |
US7757075B2 (en) | 2002-11-15 | 2010-07-13 | Microsoft Corporation | State reference |
US20040117490A1 (en) * | 2002-12-13 | 2004-06-17 | General Instrument Corporation | Method and system for providing chaining of rules in a digital rights management system |
JP2006510102A (en) | 2002-12-17 | 2006-03-23 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | System that allows distribution of content |
US8364951B2 (en) * | 2002-12-30 | 2013-01-29 | General Instrument Corporation | System for digital rights management using distributed provisioning and authentication |
KR101016989B1 (en) | 2002-12-30 | 2011-02-28 | 코닌클리케 필립스 일렉트로닉스 엔.브이. | Method of controlling access to a content item, client system, server system and device to perform access control to a content item, a signal for carrying usage rights |
US20040128546A1 (en) * | 2002-12-31 | 2004-07-01 | International Business Machines Corporation | Method and system for attribute exchange in a heterogeneous federated environment |
US8468227B2 (en) | 2002-12-31 | 2013-06-18 | Motorola Solutions, Inc. | System and method for rendering content on multiple devices |
TWI349204B (en) | 2003-01-10 | 2011-09-21 | Panasonic Corp | Group admission system and server and client therefor |
US20040139312A1 (en) * | 2003-01-14 | 2004-07-15 | General Instrument Corporation | Categorization of host security levels based on functionality implemented inside secure hardware |
US7383586B2 (en) * | 2003-01-17 | 2008-06-03 | Microsoft Corporation | File system operation and digital rights management (DRM) |
US20050004873A1 (en) | 2003-02-03 | 2005-01-06 | Robin Pou | Distribution and rights management of digital content |
US7577999B2 (en) * | 2003-02-11 | 2009-08-18 | Microsoft Corporation | Publishing digital content within a defined universe such as an organization in accordance with a digital rights management (DRM) system |
US20040158731A1 (en) | 2003-02-11 | 2004-08-12 | Microsoft Corporation | Publishing digital content within a defined universe such as an organization in accordance with a digital rights management (DRM) system |
US20040230965A1 (en) | 2003-02-28 | 2004-11-18 | Harri Okkonen | Mobile handset network that facilitates interaction between a generic intelligent responsive agent and a service broker server |
US7577964B2 (en) | 2003-02-28 | 2009-08-18 | Hewlett-Packard Development Company, L.P. | System and methods for defining a binding for web-services |
DE10311898B4 (en) | 2003-03-18 | 2005-04-21 | Webasto Ag | Heater for a vehicle |
JP2004287994A (en) | 2003-03-24 | 2004-10-14 | Fuji Xerox Co Ltd | Electronic library server and electronic library service system |
US20040207659A1 (en) * | 2003-04-02 | 2004-10-21 | International Business Machines Corporation | Program creation by combining web services using graphic user interface controls |
US20040205333A1 (en) | 2003-04-14 | 2004-10-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for digital rights management |
US7272228B2 (en) | 2003-06-12 | 2007-09-18 | International Business Machines Corporation | System and method for securing code and ensuring proper execution using state-based encryption |
JP2005012282A (en) | 2003-06-16 | 2005-01-13 | Toshiba Corp | Electronic merchandise distributing system, electronic merchandise receiving terminal, and electronic merchandise distributing method |
US7089594B2 (en) | 2003-07-21 | 2006-08-08 | July Systems, Inc. | Application rights management in a mobile environment |
US8200775B2 (en) | 2005-02-01 | 2012-06-12 | Newsilike Media Group, Inc | Enhanced syndication |
AU2004303120A1 (en) * | 2003-09-05 | 2005-03-17 | Limelight Networks, Inc. | Management of digital content licenses |
US7389273B2 (en) * | 2003-09-25 | 2008-06-17 | Scott Andrew Irwin | System and method for federated rights management |
US7480382B2 (en) | 2003-09-30 | 2009-01-20 | Microsoft Corporation | Image file container |
US7594275B2 (en) | 2003-10-14 | 2009-09-22 | Microsoft Corporation | Digital rights management system |
US20050234735A1 (en) | 2003-11-26 | 2005-10-20 | Williams Jim C | Digital rights management using proximity testing |
US20050192902A1 (en) | 2003-12-05 | 2005-09-01 | Motion Picture Association Of America | Digital rights management using multiple independent parameters |
US20050177516A1 (en) * | 2004-02-06 | 2005-08-11 | Eric Vandewater | System and method of protecting digital content |
KR20070024496A (en) | 2004-02-23 | 2007-03-02 | 힐크레스트 래보래토리스, 인크. | Methods and systems for a secure media computing environment |
JP4350549B2 (en) | 2004-02-25 | 2009-10-21 | 富士通株式会社 | Information processing device for digital rights management |
CA2460467A1 (en) | 2004-03-10 | 2005-09-10 | Metamail Corporation | System and method of trusted publishing |
JP2005259015A (en) | 2004-03-15 | 2005-09-22 | Ricoh Co Ltd | Document disclosure device and system, program, and storage medium |
JP4466148B2 (en) | 2004-03-25 | 2010-05-26 | 株式会社日立製作所 | Content transfer management method, program, and content transfer system for network transfer |
US20050222227A1 (en) * | 2004-04-01 | 2005-10-06 | Pfizer Inc | Oxazole-amine compounds for the treatment of neurodegenerative disorders |
US7437771B2 (en) | 2004-04-19 | 2008-10-14 | Woodcock Washburn Llp | Rendering protected digital content within a network of computing devices or the like |
US20050262568A1 (en) | 2004-05-18 | 2005-11-24 | Hansen Mark D | System and method for managing access to protected content by untrusted applications |
US20050273629A1 (en) | 2004-06-04 | 2005-12-08 | Vitalsource Technologies | System, method and computer program product for providing digital rights management of protected content |
US20050278256A1 (en) | 2004-06-15 | 2005-12-15 | Eric Vandewater | System and method of promoting copy-managed digital content |
AU2005273532B2 (en) | 2004-06-28 | 2011-04-07 | Acano (Uk) Limited | System for proximity determination |
US7559759B2 (en) * | 2004-07-20 | 2009-07-14 | Irwin Research And Development, Inc. | Trim press having an article ejector, article ejecting device with linear drive mechanism, and method |
US20060036554A1 (en) | 2004-08-12 | 2006-02-16 | Microsoft Corporation | Content and license delivery to shared devices |
US7610011B2 (en) | 2004-09-19 | 2009-10-27 | Adam Albrett | Providing alternative programming on a radio in response to user input |
KR100677152B1 (en) | 2004-11-17 | 2007-02-02 | 삼성전자주식회사 | Method for transmitting content in home network using user-binding |
EP1672831A1 (en) | 2004-12-16 | 2006-06-21 | Nagravision S.A. | Method for transmission of digital data in a local network |
JP4622514B2 (en) | 2004-12-28 | 2011-02-02 | 日本電気株式会社 | Document anonymization device, document management device, document anonymization method, and document anonymization program |
JP4510653B2 (en) | 2005-01-31 | 2010-07-28 | キヤノン株式会社 | Layout determining method, apparatus and program |
KR100694104B1 (en) | 2005-02-23 | 2007-03-12 | 삼성전자주식회사 | Method for measuring Round Trip Time and the method for checking proximity using the same |
WO2006095335A2 (en) | 2005-03-07 | 2006-09-14 | Noam Camiel | System and method for a dynamic policies enforced file system for a data storage device |
KR100636232B1 (en) | 2005-04-29 | 2006-10-18 | 삼성전자주식회사 | Method and apparatus for checking proximity between devices using hash chain |
EP1724699A1 (en) | 2005-05-17 | 2006-11-22 | Siemens Aktiengesellschaft | Method and system for gradually degrading the quality of digital content in a DRM system |
US20060294580A1 (en) | 2005-06-28 | 2006-12-28 | Yeh Frank Jr | Administration of access to computer resources on a network |
JP2007066302A (en) | 2005-08-04 | 2007-03-15 | Ricoh Co Ltd | Electronic document having authentication function |
WO2007030920A2 (en) | 2005-09-12 | 2007-03-22 | Sand Box Technologies Inc. | System and method for controlling distribution of electronic information |
WO2007043015A2 (en) | 2005-10-13 | 2007-04-19 | Koninklijke Philips Electronics N.V. | Improved proximity detection method |
KR100757845B1 (en) | 2006-02-13 | 2007-09-11 | (주)잉카엔트웍스 | Method of providing license response to encrypted contents to client apparatus and digital rights management conversion system of enabling the method |
US20070255659A1 (en) * | 2006-05-01 | 2007-11-01 | Wei Yen | System and method for DRM translation |
US7873988B1 (en) | 2006-09-06 | 2011-01-18 | Qurio Holdings, Inc. | System and method for rights propagation and license management in conjunction with distribution of digital content in a social network |
JP2009026013A (en) | 2007-07-18 | 2009-02-05 | Yahoo Japan Corp | Content registration/provision device, content registration/provision control method, and content registration/provision control program |
KR100982059B1 (en) | 2007-09-27 | 2010-09-13 | 주식회사 엘지유플러스 | System and Method for Converting Compatible DRM Contents from Cooperation DRM Contents and Recording Medium for Recording Computer Program of Function Thereof |
CN100555299C (en) | 2007-12-28 | 2009-10-28 | 中国科学院计算技术研究所 | A kind of digital literary property protection method and system |
JP5033658B2 (en) | 2008-01-28 | 2012-09-26 | 株式会社リコー | Electronic document security system |
US8095518B2 (en) | 2008-06-04 | 2012-01-10 | Microsoft Corporation | Translating DRM system requirements |
-
2004
- 2004-06-07 CN CN201110260513.2A patent/CN103001923B/en not_active Expired - Fee Related
- 2004-06-07 CA CA2776354A patent/CA2776354A1/en not_active Abandoned
- 2004-06-07 KR KR1020107007909A patent/KR101030203B1/en not_active IP Right Cessation
- 2004-06-07 EP EP10181095A patent/EP2280524A3/en not_active Withdrawn
- 2004-06-07 KR KR1020087010633A patent/KR100965437B1/en not_active IP Right Cessation
- 2004-06-07 JP JP2006509076A patent/JP5242915B2/en not_active Expired - Fee Related
- 2004-06-07 SG SG200718613-3A patent/SG155065A1/en unknown
- 2004-06-07 EP EP10180088.6A patent/EP2270622B1/en not_active Expired - Lifetime
- 2004-06-07 KR KR1020107024495A patent/KR101024237B1/en not_active IP Right Cessation
- 2004-06-07 BR BRPI0410999-6A patent/BRPI0410999A/en not_active Application Discontinuation
- 2004-06-07 CA CA2528428A patent/CA2528428C/en not_active Expired - Lifetime
- 2004-06-07 WO PCT/US2004/018120 patent/WO2005017654A2/en active Application Filing
- 2004-06-07 AP AP2005003476A patent/AP2005003476A0/en unknown
- 2004-06-07 AU AU2004264582A patent/AU2004264582B2/en not_active Ceased
- 2004-06-07 EP EP04776350.3A patent/EP1629363B1/en not_active Expired - Lifetime
- 2004-06-07 KR KR1020057023383A patent/KR101030941B1/en not_active IP Right Cessation
- 2004-06-07 EA EA200700510A patent/EA015549B1/en not_active IP Right Cessation
- 2004-06-07 EA EA200501896A patent/EA008614B1/en not_active IP Right Cessation
- 2004-06-07 CN CN200480021795.9A patent/CN1860761B/en not_active Expired - Fee Related
- 2004-06-07 US US10/863,551 patent/US8234387B2/en not_active Expired - Fee Related
-
2005
- 2005-12-05 IL IL172366A patent/IL172366A/en not_active IP Right Cessation
-
2007
- 2007-05-17 US US11/804,667 patent/US20070283423A1/en not_active Abandoned
- 2007-07-27 US US11/829,805 patent/US20080301430A1/en not_active Abandoned
- 2007-07-27 US US11/829,774 patent/US20080285757A1/en not_active Abandoned
- 2007-07-27 US US11/829,751 patent/US20080056500A1/en not_active Abandoned
- 2007-07-27 US US11/829,837 patent/US9466054B1/en not_active Expired - Fee Related
- 2007-07-27 US US11/829,809 patent/US20080298591A1/en not_active Abandoned
- 2007-08-20 US US11/894,372 patent/US20080140835A1/en not_active Abandoned
- 2007-08-20 US US11/894,624 patent/US20090094453A1/en not_active Abandoned
- 2007-10-30 US US11/929,937 patent/US20080133731A1/en not_active Abandoned
- 2007-12-12 JP JP2007320348A patent/JP5059577B2/en not_active Expired - Fee Related
-
2009
- 2009-06-30 US US12/459,490 patent/US20100005513A1/en not_active Abandoned
- 2009-06-30 US US12/459,491 patent/US20100017606A1/en not_active Abandoned
- 2009-11-12 US US12/617,164 patent/US9235833B2/en not_active Expired - Fee Related
- 2009-11-17 US US12/620,445 patent/US20100067699A1/en not_active Abandoned
- 2009-11-17 US US12/620,452 patent/US20100070774A1/en not_active Abandoned
-
2010
- 2010-05-27 US US12/789,004 patent/US9424564B2/en not_active Expired - Fee Related
- 2010-06-03 US US12/792,965 patent/US20100250927A1/en not_active Abandoned
- 2010-06-03 US US12/792,952 patent/US9235834B2/en not_active Expired - Fee Related
- 2010-08-12 AU AU2010212301A patent/AU2010212301B2/en not_active Ceased
-
2011
- 2011-10-27 US US13/283,126 patent/US9317843B2/en not_active Expired - Fee Related
- 2011-10-27 US US13/283,313 patent/US20120159643A1/en not_active Abandoned
- 2011-10-27 US US13/283,245 patent/US20120042389A1/en not_active Abandoned
- 2011-11-14 JP JP2011248897A patent/JP2012053913A/en active Pending
-
2012
- 2012-11-14 IL IL223027A patent/IL223027A/en not_active IP Right Cessation
-
2014
- 2014-02-20 JP JP2014030471A patent/JP5731679B2/en not_active Expired - Fee Related
-
2016
- 2016-09-15 US US15/266,928 patent/US20170163645A1/en not_active Abandoned
Patent Citations (98)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4327508A (en) * | 1980-12-08 | 1982-05-04 | J. I. Case Company | Trencher digging chain sprocket drive |
US5410598A (en) * | 1986-10-14 | 1995-04-25 | Electronic Publishing Resources, Inc. | Database usage metering and protection system and method |
US5414845A (en) * | 1992-06-26 | 1995-05-09 | International Business Machines Corporation | Network-based computer system with improved network scheduling system |
US5715403A (en) * | 1994-11-23 | 1998-02-03 | Xerox Corporation | System for controlling the distribution and use of digital works having attached usage rights where the usage rights are defined by a usage rights grammar |
US5629980A (en) * | 1994-11-23 | 1997-05-13 | Xerox Corporation | System for controlling the distribution and use of digital works |
US5634012A (en) * | 1994-11-23 | 1997-05-27 | Xerox Corporation | System for controlling the distribution and use of digital works having a fee reporting mechanism |
US5638443A (en) * | 1994-11-23 | 1997-06-10 | Xerox Corporation | System for controlling the distribution and use of composite digital works |
US20040054630A1 (en) * | 1995-02-13 | 2004-03-18 | Intertrust Technologies Corporation | Systems and methods for secure transaction management and electronic rights protection |
US6363488B1 (en) * | 1995-02-13 | 2002-03-26 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US6237786B1 (en) * | 1995-02-13 | 2001-05-29 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US20050060584A1 (en) * | 1995-02-13 | 2005-03-17 | Intertrust Technologies Corp. | Trusted infrastructure support systems, methods and techniques for secure electronic commerce, electronic transactions, commerce process control and automation, distributed computing, and rights management |
US20020048369A1 (en) * | 1995-02-13 | 2002-04-25 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US6185683B1 (en) * | 1995-02-13 | 2001-02-06 | Intertrust Technologies Corp. | Trusted and secure techniques, systems and methods for item delivery and execution |
US20040103305A1 (en) * | 1995-02-13 | 2004-05-27 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US6389402B1 (en) * | 1995-02-13 | 2002-05-14 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US5530235A (en) * | 1995-02-16 | 1996-06-25 | Xerox Corporation | Interactive contents revealing storage device |
US20020023214A1 (en) * | 1996-08-12 | 2002-02-21 | Intertrust Technologies Corp. | Systems and methods using cryptography to protect secure computing environments |
US6240185B1 (en) * | 1996-08-12 | 2001-05-29 | Intertrust Technologies Corporation | Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels |
US20030041239A1 (en) * | 1996-08-12 | 2003-02-27 | Intertrust Technologies Corp. | Systems and methods using cryptography to protect secure computing environments |
US5892900A (en) * | 1996-08-30 | 1999-04-06 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US6052780A (en) * | 1996-09-12 | 2000-04-18 | Open Security Solutions, Llc | Computer system and process for accessing an encrypted and self-decrypting digital information product while restricting access to decrypted digital information |
US6023765A (en) * | 1996-12-06 | 2000-02-08 | The United States Of America As Represented By The Secretary Of Commerce | Implementation of role-based access control in multi-level secure systems |
US6735253B1 (en) * | 1997-05-16 | 2004-05-11 | The Trustees Of Columbia University In The City Of New York | Methods and architecture for indexing and editing compressed video over the world wide web |
US6188995B1 (en) * | 1997-07-28 | 2001-02-13 | Apple Computer, Inc. | Method and apparatus for enforcing software licenses |
US6044469A (en) * | 1997-08-29 | 2000-03-28 | Preview Software | Software publisher or distributor configurable software security mechanism |
US20030069749A1 (en) * | 1997-11-06 | 2003-04-10 | Intertrust Technologies Corp. | Methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information |
US20030046244A1 (en) * | 1997-11-06 | 2003-03-06 | Intertrust Technologies Corp. | Methods for matching, selecting, and/or classifying based on rights management and/or other information |
US20030069748A1 (en) * | 1997-11-06 | 2003-04-10 | Intertrust Technologies Corp. | Methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information |
US6233608B1 (en) * | 1997-12-09 | 2001-05-15 | Openwave Systems Inc. | Method and system for securely interacting with managed data from multiple devices |
US6233577B1 (en) * | 1998-02-17 | 2001-05-15 | Phone.Com, Inc. | Centralized certificate management system for two-way interactive communication devices in data networks |
US20010001147A1 (en) * | 1998-04-22 | 2001-05-10 | Echarge Corporation | Method and apparatus for ordering goods, services and content over an internetwork |
US6226618B1 (en) * | 1998-08-13 | 2001-05-01 | International Business Machines Corporation | Electronic content delivery system |
US6985953B1 (en) * | 1998-11-30 | 2006-01-10 | George Mason University | System and apparatus for storage and transfer of secure data on web |
US6223291B1 (en) * | 1999-03-26 | 2001-04-24 | Motorola, Inc. | Secure wireless electronic-commerce system with digital product certificates and digital license certificates |
US20050050332A1 (en) * | 1999-06-08 | 2005-03-03 | Intertrust Technologies Corporation | Methods and systems for encoding and protecting data using digital signature and watermarking techniques |
US6850252B1 (en) * | 1999-10-05 | 2005-02-01 | Steven M. Hoffberg | Intelligent electronic appliance system and method |
US6842863B1 (en) * | 1999-11-23 | 2005-01-11 | Microsoft Corporation | Certificate reissuance for checking the status of a certificate in financial transactions |
US20050108555A1 (en) * | 1999-12-22 | 2005-05-19 | Intertrust Technologies Corporation | Systems and methods for protecting data secrecy and integrity |
US20050060560A1 (en) * | 1999-12-22 | 2005-03-17 | Intertrust Technologies Corporation | Systems and methods for protecting data secrecy and integrity |
US20020059425A1 (en) * | 2000-06-22 | 2002-05-16 | Microsoft Corporation | Distributed computing services platform |
US20020002674A1 (en) * | 2000-06-29 | 2002-01-03 | Tom Grimes | Digital rights management |
US20020010679A1 (en) * | 2000-07-06 | 2002-01-24 | Felsher David Paul | Information record infrastructure, system and method |
US20020044657A1 (en) * | 2000-09-07 | 2002-04-18 | Tomoyuki Asano | Information recording device, information playback device, information recording method, information playback method, and information recording medium and program providing medium used therewith |
US7210039B2 (en) * | 2000-09-14 | 2007-04-24 | Phocis Limited | Digital rights management |
US7171558B1 (en) * | 2000-09-22 | 2007-01-30 | International Business Machines Corporation | Transparent digital rights management for extendible content viewers |
US20040054894A1 (en) * | 2000-10-11 | 2004-03-18 | Lambert Martin R. | Method for controlling access to protected content |
US20040024688A1 (en) * | 2000-11-10 | 2004-02-05 | Depeng Bi | Digital content distribution and subscription system |
US7356690B2 (en) * | 2000-12-11 | 2008-04-08 | International Business Machines Corporation | Method and system for managing a distributed trust path locator for public key certificates relating to the trust path of an X.509 attribute certificate |
US20030028488A1 (en) * | 2001-03-26 | 2003-02-06 | Mohammed Sohail Baig | Supervised license acquisition in a digital rights management system on a computing device |
US7509492B2 (en) * | 2001-03-27 | 2009-03-24 | Microsoft Corporation | Distributed scalable cryptographic access control |
US20030084003A1 (en) * | 2001-04-20 | 2003-05-01 | Intertrust Technologies Corporation | Systems and methods for conducting transactions and communications using a trusted third party |
US20030009423A1 (en) * | 2001-05-31 | 2003-01-09 | Xin Wang | Rights offering and granting |
US20030023856A1 (en) * | 2001-06-13 | 2003-01-30 | Intertrust Technologies Corporation | Software self-checking systems and methods |
US7203966B2 (en) * | 2001-06-27 | 2007-04-10 | Microsoft Corporation | Enforcement architecture and method for digital rights management system for roaming a license to a plurality of user devices |
US20050004875A1 (en) * | 2001-07-06 | 2005-01-06 | Markku Kontio | Digital rights management in a mobile communications environment |
US20030009681A1 (en) * | 2001-07-09 | 2003-01-09 | Shunji Harada | Digital work protection system, recording medium apparatus, transmission apparatus, and playback apparatus |
US20030037139A1 (en) * | 2001-08-20 | 2003-02-20 | Koninklijke Philips Electronics N.V. | Content distribution model |
US20030051134A1 (en) * | 2001-08-28 | 2003-03-13 | International Business Machines Corporation | Secure authentication using digital certificates |
US20030055787A1 (en) * | 2001-09-20 | 2003-03-20 | Fujitsu Limited | Electronic settlement method |
US20030061404A1 (en) * | 2001-09-21 | 2003-03-27 | Corel Corporation | Web services gateway |
US20030065956A1 (en) * | 2001-09-28 | 2003-04-03 | Abhijit Belapurkar | Challenge-response data communication protocol |
US7359517B1 (en) * | 2001-10-09 | 2008-04-15 | Adobe Systems Incorporated | Nestable skeleton decryption keys for digital rights management |
US20030078891A1 (en) * | 2001-10-18 | 2003-04-24 | Capitant Patrice J. | Systems and methods for providing digital rights management compatibility |
US7487363B2 (en) * | 2001-10-18 | 2009-02-03 | Nokia Corporation | System and method for controlled copying and moving of content between devices and domains based on conditional encryption of content key depending on usage |
US20030084172A1 (en) * | 2001-10-29 | 2003-05-01 | Sun Microsystem, Inc., A Delaware Corporation | Identification and privacy in the World Wide Web |
US20050022227A1 (en) * | 2001-10-29 | 2005-01-27 | Shen Sheng Mei | Apparatus of a baseline dvb-cpcm |
US20050086501A1 (en) * | 2002-01-12 | 2005-04-21 | Je-Hak Woo | Method and system for the information protection of digital content |
US7484103B2 (en) * | 2002-01-12 | 2009-01-27 | Je-Hak Woo | Method and system for the information protection of digital content |
US7496757B2 (en) * | 2002-01-14 | 2009-02-24 | International Business Machines Corporation | Software verification system, method and computer program element |
US6996544B2 (en) * | 2002-02-27 | 2006-02-07 | Imagineer Software, Inc. | Multiple party content distribution system and method with rights management features |
US20040073813A1 (en) * | 2002-04-25 | 2004-04-15 | Intertrust Technologies Corporation | Establishing a secure channel with a human user |
US20040059951A1 (en) * | 2002-04-25 | 2004-03-25 | Intertrust Technologies Corporation | Secure authentication systems and methods |
US20040003398A1 (en) * | 2002-06-27 | 2004-01-01 | Donian Philip M. | Method and apparatus for the free licensing of digital media content |
US20040003139A1 (en) * | 2002-06-28 | 2004-01-01 | Microsoft Corporation | Secure server plug-in architecture for digital rights management systems |
US20040003270A1 (en) * | 2002-06-28 | 2004-01-01 | Microsoft Corporation | Obtaining a signed rights label (SRL) for digital content and obtaining a digital license corresponding to the content based on the SRL in a digital rights management system |
US20040054912A1 (en) * | 2002-09-04 | 2004-03-18 | Daniel Adent | Data stream header object protection |
US20060020784A1 (en) * | 2002-09-23 | 2006-01-26 | Willem Jonker | Certificate based authorized domains |
US20060041642A1 (en) * | 2002-09-30 | 2006-02-23 | Koninklijke Philips Electronics, N.V. | Secure proximity verification of a node on a network |
US20060021065A1 (en) * | 2002-10-22 | 2006-01-26 | Kamperman Franciscus Lucas A J | Method and device for authorizing content operations |
US20040088541A1 (en) * | 2002-11-01 | 2004-05-06 | Thomas Messerges | Digital-rights management system |
US20040088175A1 (en) * | 2002-11-01 | 2004-05-06 | Thomas Messerges | Digital-rights management |
US20040103312A1 (en) * | 2002-11-27 | 2004-05-27 | Thomas Messerges | Domain-based digital-rights management system with easy and secure device enrollment |
US7493289B2 (en) * | 2002-12-13 | 2009-02-17 | Aol Llc | Digital content store system |
US20050008163A1 (en) * | 2003-06-02 | 2005-01-13 | Liquid Machines, Inc. | Computer method and apparatus for securely managing data objects in a distributed context |
US20050027871A1 (en) * | 2003-06-05 | 2005-02-03 | William Bradley | Interoperable systems and methods for peer-to-peer service orchestration |
US20050078822A1 (en) * | 2003-10-08 | 2005-04-14 | Eyal Shavit | Secure access and copy protection management system |
US20050102513A1 (en) * | 2003-11-10 | 2005-05-12 | Nokia Corporation | Enforcing authorized domains with domain membership vouchers |
US20050108707A1 (en) * | 2003-11-14 | 2005-05-19 | Taylor Thomas M. | Systems and methods for creating and managing a virtual retail store on end-user client computers within a network |
US20070083757A1 (en) * | 2003-11-25 | 2007-04-12 | Toshihisa Nakano | Authentication system |
US7516331B2 (en) * | 2003-11-26 | 2009-04-07 | International Business Machines Corporation | Tamper-resistant trusted java virtual machine and method of using the same |
US7711647B2 (en) * | 2004-06-10 | 2010-05-04 | Akamai Technologies, Inc. | Digital rights management in a distributed network |
US20090007198A1 (en) * | 2004-06-21 | 2009-01-01 | Ben Lavender | Accessing Broadcast Media |
US20060015580A1 (en) * | 2004-07-01 | 2006-01-19 | Home Box Office, A Delaware Corporation | Multimedia content distribution |
US20060050870A1 (en) * | 2004-07-29 | 2006-03-09 | Kimmel Gerald D | Information-centric security |
US20070074270A1 (en) * | 2005-09-28 | 2007-03-29 | Essential Security Software, Inc. | Method and system for digital rights management of documents |
US20070098162A1 (en) * | 2005-10-27 | 2007-05-03 | Samsung Electronics Co., Ltd. | Method and apparatus for managing rights of multi-layered multimedia stream by layers |
US20090031038A1 (en) * | 2007-07-26 | 2009-01-29 | Realnetworks, Inc. | Adaptive variable fidelity media distribution system and method |
US20090112867A1 (en) * | 2007-10-25 | 2009-04-30 | Prasan Roy | Anonymizing Selected Content in a Document |
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8234387B2 (en) | 2003-06-05 | 2012-07-31 | Intertrust Technologies Corp. | Interoperable systems and methods for peer-to-peer service orchestration |
US20100250927A1 (en) * | 2003-06-05 | 2010-09-30 | Intertrust Technologies Corp. | Interoperable systems and methods for peer-to-peer service orchestration |
US9424564B2 (en) | 2003-06-05 | 2016-08-23 | Intertrust Technologies Corporation | Interoperable systems and methods for peer-to-peer service orchestration |
US9317843B2 (en) | 2003-06-05 | 2016-04-19 | Intertrust Technologies Corporation | Interoperable systems and methods for peer-to-peer service orchestration |
US9235834B2 (en) | 2003-06-05 | 2016-01-12 | Intertrust Technologies Corporation | Interoperable systems and methods for peer-to-peer service orchestration |
US9235833B2 (en) | 2003-06-05 | 2016-01-12 | Intertrust Technologies Corporation | Interoperable systems and methods for peer-to-peer service orchestration |
US9466054B1 (en) | 2003-06-05 | 2016-10-11 | Intertrust Technologies Corporation | Interoperable systems and methods for peer-to-peer service orchestration |
US20070283423A1 (en) * | 2003-06-05 | 2007-12-06 | Intertrust Technologies Corp. | Interoperable systems and methods for peer-to-peer service orchestration |
US20090094453A1 (en) * | 2003-06-05 | 2009-04-09 | Intertrust Technologies Corp. | Interoperable systems and methods for peer-to-peer service orchestration |
US20080301430A1 (en) * | 2003-06-05 | 2008-12-04 | Intertrust Technologies Corp. | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US20080056500A1 (en) * | 2003-06-05 | 2008-03-06 | Intertrust Technologies Corp | Interoperable Systems and Methods for Peer-to-Peer Service Orchestration |
US20100005513A1 (en) * | 2003-06-05 | 2010-01-07 | Intertrust Technologies Corp. | Interoperable systems and methods for peer-to-peer service orchestration |
US20050027871A1 (en) * | 2003-06-05 | 2005-02-03 | William Bradley | Interoperable systems and methods for peer-to-peer service orchestration |
US20100131412A1 (en) * | 2003-06-05 | 2010-05-27 | Intertrust Technologies Corporation | Interoperable systems and methods for peer-to-peer service orchestration |
US20100067705A1 (en) * | 2005-10-18 | 2010-03-18 | Intertrust Technologies Corp. | Digital rights management engine systems and methods |
US8688583B2 (en) | 2005-10-18 | 2014-04-01 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US8776216B2 (en) | 2005-10-18 | 2014-07-08 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US20070185815A1 (en) * | 2005-10-18 | 2007-08-09 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US20070185814A1 (en) * | 2005-10-18 | 2007-08-09 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US20070180519A1 (en) * | 2005-10-18 | 2007-08-02 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US20070172041A1 (en) * | 2005-10-18 | 2007-07-26 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US20070100701A1 (en) * | 2005-10-18 | 2007-05-03 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US9626667B2 (en) * | 2005-10-18 | 2017-04-18 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US20070204078A1 (en) * | 2006-02-09 | 2007-08-30 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
US9589110B2 (en) | 2011-04-11 | 2017-03-07 | Intertrust Technologies Corporation | Information security systems and methods |
US10009384B2 (en) | 2011-04-11 | 2018-06-26 | Intertrust Technologies Corporation | Information security systems and methods |
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9317843B2 (en) | Interoperable systems and methods for peer-to-peer service orchestration | |
AU2012202810B2 (en) | Interoperable systems and methods for peer-to-peer service orchestration |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |